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

[Michael S. Tsirkin]

On Wed, Feb 06, 2013 at 10:33:41AM +1030, Rusty Russell wrote:
> 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.

Maybe we should ask for some centrally assigned vendor id?
We could ask IANA to keep the database.

-- 
MST