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: Anthony Liguori
Subject: Re: [Qemu-devel] Headsup: windows virtio networking does not work on current git
Date: Mon, 04 Feb 2013 08:41:21 -0600
User-agent: Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu)

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.

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
>> > > 
>> > > 



reply via email to

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