On Wed, Feb 06, 2013 at 10:33:41AM +1030, Rusty Russell wrote: > Anthony Liguori <anth...@codemonkey.ws> writes: > > Rusty Russell <ru...@rustcorp.com.au> 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
