| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] [RFC][PATCH 4/6] HVM PCI Passthrough (non-IOMMU)
>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
>Sent: 2007年6月1日 16:22
>
>On 1/6/07 03:45, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>
>> My knowledge about 'boot interrupt' issue is related to EOI
>> masked RTE entry on some chipset, and not sure the influence of
>> polarity change. Then ioapic_acknew may be replaced by this way
>> which is more efficient if working. Two times interrupt may be still
>> better than EOI-in-end which blocks other pending interrupt, and the
>> 2nd interrupt should be quick since only xen internal status is touched.
>
>That's a dubious claim imo. Doubling the rate of interrupts for high-rate
>devices is not going to be a performance win, particularly if the interrupts
>often require a VMEXIT/VMENTRY round trip. However,
>ioapic_ack=new is kind
>of gross, so if we were confident that high-rate devices were able to use
>MSIs, or if I can be convinced that the VT-d approach of re-vectoring the
>RTE is robust and applicable to any generic IOAPIC, then I would be
>quite
>happy to kill off ioapic_ack=new.
>
> -- Keir
Unless high-rate devices are MSI capable as you said, it's very likely
for them to suffer two-interrupts penalty when sharing irq line with
HVM-owned devices, if polarity-switch is used. Maybe we can add
some protection at control panel to prevent such sharing case happen,
for example, to identify class for high speed devices and then avoid or
warn any device sharing same irq to be assigned to HVM guest?
BTW, just confirmed with Xiaohui that current VT-d patch doesn't
have VIOAPIC EOI approach and shared irq support is not ready
yet.
Thanks,
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home