Bug 907348

Summary:	virtio win network driver broken with extended config space
Product:	Red Hat Enterprise Linux 7	Reporter:	Michael S. Tsirkin <mst>
Component:	libvirt	Assignee:	Peter Krempa <pkrempa>
Status:	CLOSED CANTFIX	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.0	CC:	acathrow, bcao, bsarathy, dyasny, dyuan, gsun, honzhang, juzhang, michen, mzhan, pkrempa, rwu, yvugenfi
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	907160	Environment:
Last Closed:	2013-02-11 11:21:31 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	907160, 983321, 1107942, 1150869
Bug Blocks:

Comment 2 Peter Krempa 2013-02-08 16:24:33 UTC

(In reply to comment #0)
> This gust driver bug will need libvirt workaround.
> libvirt must detect drivers from 6.4 and older and
> disable mq.

Libvirt isn't able to detect the type of OS of the guest nor drivers in use and shouldn't be doing that.

> 
> +++ This bug was initially created as a clone of Bug #907160 +++
> 
> Description of problem:
> virtio win network driver assumes config space size is 32 bytes.
> This breaks with future extensions such as multiqueue.
> It should assume >= 32 instead.
> 
> 
> Version-Release number of selected component (if applicable):
> 22 Jan 2013
> 
> How reproducible:
> always
> 
> Steps to Reproduce:
> 1. check out qemu  v1.4.0-rc0
> 3. start guest and load virtio win drivers
>   
> Actual results:
> Windows displays a yellow exclamation mark near the virtio-net device and
> says it can't start the device (Code 10).
> 
> 
> Expected results:
> Windows driver starts and works as expected.
> 
> Additional info:
> qemu-1.4 will include work around where using -M pc-1.3 will
> let driver load.

Hm, if the 1.3 machine type doesn't trigger the bug, the compatibility will be preserved as long as the user doesn't change the machine type. If the user does change the machine type he/she must bear the consequences as it's comparable to a hardware change where incompatible drivers can be expected.

> Besides -M pc-1.3, another work around would be:
> 
>   -global virtio-net-pci.mq=off
> 

If pc-1.3 and older don't break the driver, this approach isn't needed as it won't break older configurations.

So these are the options:
1) In case the driver doesn't break for older machine types libvirt is be okay regarding the compatibility. In that case this bug is "CANTFIX" as libvirt can't and shouldn't care about the guest.

2) In case the driver breaks for some already released machine types it should be fixed in qemu or we will need to disable multiqueue completely by default and let the user enable it on request.

Additionally a bug should be filed to allow control of this feature.

Comment 3 Michael S. Tsirkin 2013-02-10 15:43:07 UTC

> Libvirt isn't able to detect the type of OS of the guest nor drivers in use and shouldn't be doing that.

Libvirt supplies the virtio drivers to be installed to guest.

Comment 4 Peter Krempa 2013-02-11 11:21:31 UTC

(In reply to comment #3)
> > Libvirt isn't able to detect the type of OS of the guest nor drivers in use and shouldn't be doing that.
> 
> Libvirt supplies the virtio drivers to be installed to guest.

No libvirt is not doing this. This is the job of the management application built on top of libvirt.

As qemu is working as expected with the older machine types and the compatibility is not broken.

I filed bug https://bugzilla.redhat.com/show_bug.cgi?id=909874 to track addition of configuration options for multiqueue support.

As of the initial request to solve this issue libvirt can't detect the OS run in the guest and act appropriately thus I'm closing this bug as CANTFIX. Additionaly no compatibility with previously defined machines is broken.