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

[Vadim Rozenfeld]

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