Bug 741715 - pci passthrough always requests guest GSI 0
pci passthrough always requests guest GSI 0
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
15
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Fedora Virtualization Maintainers
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-27 14:02 EDT by Roman Kagan
Modified: 2013-01-09 19:23 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-28 19:56:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Roman Kagan 2011-09-27 14:02:33 EDT
Description of problem:

When running VM with direct assignment of a host PCI device (EHCI controller) on a VT-d capable machine, the device remains unusable in the guest.

Windows 7 guest fails to complete booting; Fedora 15 guest succeeds and even enumerates the controller but sees nothing attached to it.

qemu and kernel irq thread [irq/19-kvm:0000...] use up the CPU.


Version-Release number of selected component (if applicable):

qemu-system-x86-0.14.0-7.fc15.x86_64

How reproducible:

100%

Steps to Reproduce:
1. unbind echi driver and bind pci-stub to the device
2. run qemu with an installed guest, assigning this device:
# qemu-kvm ... -device pci-assign,id=ehci_host7,host=0000:00:1d.7
  
Actual results:

Windows VM gets stuck before login propmt.  Linux VM boots but the assigned device doesn't work.

Expected results:

VMs boot and the assigned device works.

Additional info:

I was able to identify the reason:

No matter what interrupt is assigned to the device in the guest, in the host qemu always requests guest GSI 0.  As a result, any activity on the device triggers a storm of "timer" interrupts instead of the respective guest device interrupt.

This misassignment, in turn, happens as follows: when the guest updates the interrupt assignment by writing to the piix3 bridge config space, qemu is supposed to update the kvm's association of guest interrupts with assigned devices:

hw/pci.c:
1155 void pci_default_write_config(PCIDevice *d, uint32_t addr, uint32_t val, int l)
1156 {
...
1168 #ifdef CONFIG_KVM_DEVICE_ASSIGNMENT
1169     if (kvm_enabled() && kvm_irqchip_in_kernel() &&
1170         addr >= PIIX_CONFIG_IRQ_ROUTE &&
1171         addr < PIIX_CONFIG_IRQ_ROUTE + 4)
1172         assigned_dev_update_irqs();
1173 #endif /* CONFIG_KVM_DEVICE_ASSIGNMENT */

However, due to a twist in qemu configuration system, this file doesn't include, directly or not, config-target.h where CONFIG_KVM_DEVICE_ASSIGNMENT is defined.  As a result, the call to assigned_dev_update_irqs() silently isn't compiled in, and the device is left with the guest interrupt it was initialized with, i.e. 0.

The fix should be trivial for someone more familiar with qemu configuration system.

The problem seems to be present till now (i.e. qemu-0.15).
Comment 1 Roman Kagan 2012-01-16 05:45:20 EST
FWIW in qemu-system-x86-0.15.1-3.fc16.x86_64 the problem is resolved.
Comment 2 Fedora Admin XMLRPC Client 2012-03-15 13:54:14 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 3 Cole Robinson 2012-05-28 19:56:21 EDT
F15 is end of life in a month, so since this is fixed in F16 per Comment #1, just closing as CURRENTRELEASE.

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