RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 907348 - virtio win network driver broken with extended config space
Summary: virtio win network driver broken with extended config space
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Peter Krempa
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 907160 983321 1107942 1150869
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-02-04 07:50 UTC by Michael S. Tsirkin
Modified: 2014-10-09 05:42 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 907160
Environment:
Last Closed: 2013-02-11 11:21:31 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.