Michael Tokarev <m...@tls.msk.ru> 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