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

[Vadim Rozenfeld]

On Mon, 2013-02-04 at 08:41 -0600, Anthony Liguori wrote:
> Vadim Rozenfeld <address@hidden> 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.
Right, nobody can force you to change the revision id. It's just a good
engineering practice to increase RevID every time the HW interface has
changed, and you expect some compatibility issue between the new HW and
old drivers. In this case, if Windows cannot locate the INF file which
matches the new device identification strings, it just reports that it
cannot find a suitable driver.  
> 
> But adding feature bits an altering the config size doesn't constitute a
> change in the software interface IMHO.

I agree, feature bits are good. The only one problem with them, is that
driver usually doesn't have access to PCI space during the driver
loading phase.
Best regards,
Vadim.
 
> 
> 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
> >> > > 
> >> > >