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: Sun, 03 Feb 2013 15:09:39 -0600
User-agent: Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu)

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