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).
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).