Red Hat Bugzilla – Bug 741715
pci passthrough always requests guest GSI 0
Last modified: 2013-01-09 19:23:32 EST
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):
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
Windows VM gets stuck before login propmt. Linux VM boots but the assigned device doesn't work.
VMs boot and the assigned device works.
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:
1155 void pci_default_write_config(PCIDevice *d, uint32_t addr, uint32_t val, int l)
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)
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).
FWIW in qemu-system-x86-0.15.1-3.fc16.x86_64 the problem is resolved.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
F15 is end of life in a month, so since this is fixed in F16 per Comment #1, just closing as CURRENTRELEASE.