qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Headsup: windows virtio networking does not work on cur


From: Rusty Russell
Subject: Re: [Qemu-devel] Headsup: windows virtio networking does not work on current git
Date: Wed, 06 Feb 2013 10:33:41 +1030
User-agent: Notmuch/0.14 (http://notmuchmail.org) Emacs/23.4.1 (i686-pc-linux-gnu)

Anthony Liguori <address@hidden> writes:
> Rusty Russell <address@hidden> writes:
>> If I could find a way, I'd like to create some code as an appendix to
>> the virtio spec which would torture test each driver and/or device by
>> configuring it in strange ways.  But that's pure speculation at this
>> point.
>
> It wouldn't be so hard to add a torture parameter to the virtio
> implementation in QEMU that would do silly things that were still within
> the bounds of the specification.  Larger config sizes, advertisement of
> unknown feature bits, etc.

My thought is that alongside the spec we provide two libraries for each
device class: a device-side and a driver-side.  Each one gets fed an
integer (which controls which craziness it does) and you test against
each variant.

For testing qemu, we could either put sew this test code into Linux,
or hack it into qemu and pretend it was guest-driven (handwave).

>> In practice, we'd want to formalize it into a string and a version, and
>> hope the version gets bumped appropriately.  Because it'll actually be
>> used for bug detection.
>
> Sure.
>
>> But AFAICT that would be useless in this case.  We really want to know about
>> the guest before we even start it.
>
> We can't just prepare to fight yesterday's wars :-)

s/just/even/.

> We'd want to know the string before we expose host features.  That's
> easy.

Absolutely.  But we'd need a virtio2-like spec change, which insisted
that the driver write this version number somewhere before inspecting
any other field.  Or?

> How we expose config space in virtio2 is a separate discussion.  If we
> take a list approach like you've talked about before, it would be much
> harder for drivers to assume anything about the BAR size for config
> since the size would always be different.

I think it's the same discussion.  Strings are hard: how about a 16 bit
implementation id (don't clash with others) and a 16 bit version number
(increment as driver changes).

Should we also loosen revid to be a version number for the device?  It's
only 8 bits though, so perhaps new config fields are better.

Cheers,
Rusty.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]