Xen devel - May 2007 - [RFC][PATCH 4/6] HVM PCI Passthrough (non-IOMMU)

int.patch:

    - Supports only level-triggered interrupts. Edge interrupts support
will be 
      added shortly (should be fairly simple)
    - Change polarity trick: in order to reflect the external device''s
assertion
      state, the ioapic pin gets its polarity changed whenever an
interrupt
      occur. So an interrupt is generated when the _external_ line is
asserted 
      (then, polarity change is done) and another interrupt when the
_external_ 
      line is deassered (as a result from the polarity change), this
continues 
      repeatedly. 
    - It is implemented by introducing a new hw_interrupt_type, which is
exactly 
      the same as the ioapic_level_type hw_interrupt_type with its end()

      callback replaced (see io_apic.c for more details).
    - State machine:
      Whenever an interrupt occur (both for an assertion or
deassertion):
          1. Ack & Mask the interrupt
          2. Assert/Deassert virtual line of NativeDom (Interrupt
action).
          3. Change pin''s polarity
          4. EOI & Unmask

Signed-off-by: Guy Zana <guy@neocleus.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi, Guy,
	The picture in my mind for polarity change is to change generic 
level-triggered handle flow like:

When interrupt happens,
->ack():
          1. Change pin''s polarity
          2. EOI

Do_IRQ_guest (either event to para-domain, or Assert/Deassert 
virtual wire of HVM domain), or handled by Xen itself

->end():
          No-op

	By this way, you don''t need to mask/unmask and also no need to 
call original level-triggered end() method.

	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.

 	Also your patch miss one important feature to handle shared 
interrupt among domains, which is inevitable before VT-d interrupt 
mapping is fully supported. That part would be tricky, and may need 
change on both xen irq sub-system and virtual interrupt controller. :-)

Thanks,
Kevin
>From: Guy Zana
>Sent: 2007年6月1日 7:06
>
>int.patch:
>
>    - Supports only level-triggered interrupts. Edge interrupts support
>will be
>      added shortly (should be fairly simple)
>    - Change polarity trick: in order to reflect the external
device''s
>assertion
>      state, the ioapic pin gets its polarity changed whenever an
>interrupt
>      occur. So an interrupt is generated when the _external_ line is
>asserted
>      (then, polarity change is done) and another interrupt when the
>_external_
>      line is deassered (as a result from the polarity change), this
>continues
>      repeatedly.
>    - It is implemented by introducing a new hw_interrupt_type, which is
>exactly
>      the same as the ioapic_level_type hw_interrupt_type with its
>end()
>
>      callback replaced (see io_apic.c for more details).
>    - State machine:
>      Whenever an interrupt occur (both for an assertion or
>deassertion):
>          1. Ack & Mask the interrupt
>          2. Assert/Deassert virtual line of NativeDom (Interrupt
>action).
>          3. Change pin''s polarity
>          4. EOI & Unmask
>
>Signed-off-by: Guy Zana <guy@neocleus.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 1/6/07 03:45, "Tian, Kevin" <kevin.tian@intel.com> 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



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk]
>Sent: 2007年6月1日 16:22
>
>On 1/6/07 03:45, "Tian, Kevin" <kevin.tian@intel.com> 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@lists.xensource.com
http://lists.xensource.com/xen-devel

> -----Original Message-----
> From: Tian, Kevin [mailto:kevin.tian@intel.com] 
> Sent: Friday, June 01, 2007 5:45 AM
> To: Guy Zana; xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] [RFC][PATCH 4/6] HVM PCI Passthrough 
> (non-IOMMU)
> 
> Hi, Guy,
> 	The picture in my mind for polarity change is to change 
> generic level-triggered handle flow like:
> 
> When interrupt happens,
> ->ack():
>           1. Change pin''s polarity
>           2. EOI
> 
> Do_IRQ_guest (either event to para-domain, or Assert/Deassert 
> virtual wire of HVM domain), or handled by Xen itself
> 
> ->end():
>           No-op
> 
That''s a good way to go IMO. 
I actually thought about something similar, but being cautious, I tried to make
as few changes as I could to see if it works at first.

Thanks,
Guy.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel