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: Yan Vugenfirer
Subject: Re: [Qemu-devel] Headsup: windows virtio networking does not work on current git
Date: Mon, 4 Feb 2013 14:00:46 +0200

On Feb 4, 2013, at 1:30 AM, Vadim Rozenfeld wrote:

> On Sun, 2013-02-03 at 15:09 -0600, Anthony Liguori wrote:
>> Michael Tokarev <address@hidden> writes:
>> 
>>> 03.02.2013 17:23, Yan Vugenfirer wrote:
>>> 
>>>>> If it helps, mq changes the config size from 8 to 16 bytes.  If the
>>>>> driver was making an assumption about an 8-byte config size, that's
>>>>> likely what the problem is.
>>>>> 
>>>> That's exactly the problem.
>>> 
>>> So what do we do?  It isn't nice to break existing setups.
>>> Maybe mq can be disabled by default (together with Antony's
>>> patch) until fixed drivers will be more widely available?
>> 
>> I've got a patch that does exactly like this.  It's pretty ugly though
>> because of the relationship between virtio-pci and virtio-net.  I'm
>> going to try to see if I can find a cleaner way to do it on Monday.
>> 
>> I'm also contemplating just disabling mq by default.  Since a special
>> command line is needed to enable it anyway (on the backend), having to
>> specify mq=on for the device doesn't seem so bad.
>> 
>> But yeah, we don't want Windows guests to break with -M pc by default so
>> we should do something to work around it.
>> 
>> N.B. this is a pretty nasty bug in the guest driver.  Any new virtio-net
>> feature is going to trigger it (not just multiqueue).  So while pc-1.3
>> will work forever with this guest image, it's pretty much guaranteed to
>> break at some point in the future.
>> 
>>> It's easy to turn off mq by default and turn it on when
>>> needed...
>>> 
>>> The problem now is that it isn't obvious why your existing
>>> setup breaks when you upgrade.  While when you especially
>>> play with mq, you may look at options available around it...
>> 
>> If we ever to get virtio2, a really handy feature to have would be a
>> driver identification string.  Even if was only informative (and not
> 
> Why not just use revision id for that?

That's what would be expected from real HW if size of the BAR is changed.

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