search for: hvm_dpci_eoi

Keir, It''s a resending patch for the timeout mechanism to deal with the shared interrupt issue for vt-d enabled hvm guest. We modify the patch following your comments last time and make some other small fix: 1) We don''t touch the locking around the hvm_dpci_eoi(). 2) Remove the HZ from the TIME_OUT_PERIOD macro which may confuse others. 3) Add some explanation to the return value for the hvm_pci_intx_assert(), and the has_timer parameter for the hvm_dpci_eoi. We have tested it with shared interrupt between dom0/HVM(pcie/disk) and HVM/HVM(pc...

...(XEN) intel-iommu.c:1271:d0 domain_context_unmap_one_2:bdf = 0:2:0 (XEN) intel-iommu.c:1186:d0 domain_context_mapping:PCI: bdf = 0:2:0 (XEN) domctl.c:552:d0 XEN_DOMCTL_assign_device: bdf = 0:2:0 (XEN) io.c:115:d0 XEN_DOMCTL_irq_mapping: m_irq = 14 device = 2 intx = 0 (XEN) io.c:157:d0 hvm_dpci_eoi:: device 2 intx 0 (XEN) io.c:157:d32767 hvm_dpci_eoi:: device 2 intx 0 (XEN) io.c:157:d32767 hvm_dpci_eoi:: device 2 intx 0 (XEN) HVM1: HVM Loader (XEN) HVM1: Detected Xen v3.2-unstable (XEN) HVM1: Writing SMBIOS tables ... (XEN) HVM1: Loading ROMBIOS ... (XEN) HVM1: 8972 bytes...

Attached is a patch for shared interrupt between dom0 and HVM domain for vtd. Most of problem is caused by that we should inject interrupt to both domains and the physical interrupt deassertion then may be delayed by the device assigned to the HVM. The patch adds a timer, and the time out value is sufficient large to tolerant the delaying used to wait for the physical interrupt deassertion.

patch revision history ---------------------- v1: Initial patch to handle this issue involving changing the hypercall interface v2:Totally handled inside hypervisor. v3:Change some logics of handling msi-x pending unmask operations. v4:Some changes related to coding style according to Andrew Cooper''s comments v5:Some changes according to Jan''s comments, including a) remove