WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Guy Zana" <guy@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [RFC][PATCH 4/6] HVM PCI Passthrough (non-IOMMU)
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Fri, 1 Jun 2007 10:45:22 +0800
Delivery-date: Thu, 31 May 2007 19:43:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <9392A06CB0FDC847B3A530B3DC174E7B02A95EE2@xxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acej2E1juVhMSFpbRnuzdID01/diyQAG1qiQ
Thread-topic: [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

        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@xxxxxxxxxxxx>

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

<Prev in Thread] Current Thread [Next in Thread>