From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34636) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U26oq-0005ls-LJ for qemu-devel@nongnu.org; Sun, 03 Feb 2013 16:09:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U26oo-0007Cu-No for qemu-devel@nongnu.org; Sun, 03 Feb 2013 16:09:44 -0500 Received: from mail-ob0-f182.google.com ([209.85.214.182]:49108) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U26oo-0007Cd-JP for qemu-devel@nongnu.org; Sun, 03 Feb 2013 16:09:42 -0500 Received: by mail-ob0-f182.google.com with SMTP id va7so5673721obc.41 for ; Sun, 03 Feb 2013 13:09:41 -0800 (PST) From: Anthony Liguori In-Reply-To: <510E8BD4.9000505@msgid.tls.msk.ru> References: <510C2327.5080707@msgid.tls.msk.ru> <510C25F2.8000406@msgid.tls.msk.ru> <87fw1fbwk7.fsf@codemonkey.ws> <510C28BD.7050701@msgid.tls.msk.ru> <87zjznagbd.fsf@codemonkey.ws> <510D09C2.6050905@redhat.com> <1359835708.1968.3.camel@localhost> <87halu1fic.fsf@codemonkey.ws> <401C01B3-F93C-4804-8208-D1D6F62285AC@redhat.com> <510E8BD4.9000505@msgid.tls.msk.ru> Date: Sun, 03 Feb 2013 15:09:39 -0600 Message-ID: <87vca9gl4c.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] Headsup: windows virtio networking does not work on current git List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Tokarev , Yan Vugenfirer Cc: qemu-devel , Jason Wang , Rusty Russell , Vadim Rozenfeld , "Michael S. Tsirkin" Michael Tokarev 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