Bug 741715

Summary: pci passthrough always requests guest GSI 0
Product: [Fedora] Fedora Reporter: Roman Kagan <rkagan>
Component: qemuAssignee: Fedora Virtualization Maintainers <virt-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 15CC: amit.shah, berrange, crobinso, dougsland, dwmw2, ehabkost, itamar, jaswinder, jforbes, knoel, scottt.tw, tburke, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
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:
Cloudforms Team: ---

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


How reproducible:


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:

1155 void pci_default_write_config(PCIDevice *d, uint32_t addr, uint32_t val, int l)
1156 {
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();

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.