Vadim Rozenfeld <vroze...@redhat.com> writes: > On Mon, 2013-02-04 at 14:22 +0200, Michael S. Tsirkin wrote: >> On Mon, Feb 04, 2013 at 02:00:46PM +0200, Yan Vugenfirer wrote: >> > >> virtio spec is very explicit that revision never changes: >> "The device must also have a Revision ID of 0 to match this >> specification." > > With all my respect to the virtio spec, let me point that Windows lives > by different rules: > http://msdn.microsoft.com/en-us/library/windows/hardware/gg463287.aspx
That's a useful link, thanks. I don't see anything in that link that would strictly require us to change the revision ID. It seems to focus on when the "software interface changes". I take that to mean, "change the revision ID if an old driver wouldn't work anymore" which makes complete sense. But adding feature bits an altering the config size doesn't constitute a change in the software interface IMHO. Regards, Anthony Liguori > > >> It also explicitly documents the use of feature bits for >> adding new fields: >> >> "In particular, new fields in the device configuration header are >> indicated by offering a feature bit, so the guest can check before >> accessing that part of the configuration space. >> >> This allows for forwards and backwards compatibility: if the device is >> enhanced with a new feature bit, older guests will not write that >> feature bit back to the Guest Features field and it can go into >> backwards compatibility mode. Similarly, if a guest is enhanced with a >> feature that the device doesn't support, it will not see that feature >> bit in the Device Features field and can go into backwards compatibility >> mode (or, for poor implementations, set the FAILED Device Status bit). >> " >> >> I really don't see how this can be interpreted except as a >> promise to add fields and a requirement for guest drivers >> to be forward compatible. >> >> > > It really can be very useful, at >> > > least for virtio Windows drivers. >> > > BTW, Yan already fixed this problem in the Windows driver code. So we >> > > can make a new build and make it public. But it probably will not be >> > > WHQL'ed in the nearest future. >> > > >> > >> authoritative, we've had a lot of issues like this and being able to >> > >> make work arounds conditional on the driver identification string would >> > >> be nice. >> > >> >> > >> Regards, >> > >> >> > >> Anthony Liguori >> > >> >> > >>> >> > >>> How difficult it is to fix it in win driver? >> > >>> >> > >>> Thanks, >> > >>> >> > >>> /mjt >> > > >> > >
