Xiaohui and Kevin will be out for about a week for
national holiday. I have looked into the issues you
raised:
1) Looks like irq_lock changes in
vioapic_update_EOI() and hvm_dpci_eoi() are not needed. You can go ahead
and remove them.
2) The change for hvm_pci_intx_assert() seems to be
needed by vmx/vmx_dirq_assist(). It is passing the return value of
viopic_irq_positive_edge() to convey info such as whether the interrupt is
masked or not. In vmx_dpirq_assist(), the return value is used to
determine whether to deassert the interrupt or wait for the interrupt for some
more time. If the return value is 0, it mean the interrupt is still
masked by the guest - guest is not ready to accept interrupt yet - so it
deasserts the interrupt.
My test shows it handles shared interrupt cases
including ioapic_ack=new (by temporarily commenting out ioapic_ack_new = 0)
pretty well thus fixes a major deficiency in PCI passthru
functionality.
Allen
Why does the irq_lock need to be released before
taking the desc->lock in pirq_guest_eoi()? What does the new return
boolean from hvm_pci_intx_assert() mean?
-- Keir
On
30/9/07 08:29, "Xin, Xiaohui" <xiaohui.xin@xxxxxxxxx>
wrote:
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.
The patch works well with the
situation that SATA disk shares interrupt with PCIe NIC.
And for vtd=1,
the ioapic_ack=new method also works
well.
Signed-off-by: Xin,
Xiaohui<xiaohui.xin@xxxxxxxxx
Signed-off-by: Kevin Tian
<kevin.tian@xxxxxxxxx>
_______________________________________________
Xen-devel
mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
