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/
Home Products Support Community News


RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d

To: "Keir Fraser" <keir@xxxxxxxxxxxxx>, "Guy Zana" <guy@xxxxxxxxxxxx>, "Kay, Allen M" <allen.m.kay@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Thu, 31 May 2007 23:10:09 +0800
Delivery-date: Thu, 31 May 2007 08:08:38 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C284A249.FC92%keir@xxxxxxxxxxxxx>
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: Acei7YJ0pr6pL1ntT2Wzdmq3YT+WeAABwdLMABRnVWAADaM8MAADBqQEAAAbqrAAAuWvEQAADOZg
Thread-topic: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d
>From: Keir Fraser [mailto:keir@xxxxxxxxxxxxx]
>Sent: 2007年5月31日 23:03
>On 31/5/07 14:59, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>> But... still one question, seems that current Xen doesn't allow
>> multiple end() methods called for one physical interrupt instance,
>> while a new physical interrupt will happen only as result of end()
>> (EOI for ioapic_new, and unmask RTE for ioapic_old). See below
>> case:
>Yeah, well I haven't looked at how the Neocleus patches actually deal
>this, but I expect they might steal hvm-bound physical irqs completely,
>them off early in do_IRQ() and have bespoke code to deal with them.
>it could be integrated with existing ->ack and ->end methods, actually.
>->end() would be no-op while ->ack() would switch polarity in the IOAPIC
>then EOI the LAPIC. Then the handler function called by do_IRQ() would
>toggle virtual HVM wires.
>Anyhow, integrating with existing Xen IRQ handling subsystem clearly
>isn't a
>rocket-science problem. :-)

Sure. :-) But I'm still thinking the effect to use virtual EOI as de-assertion 
signal, which doesn't require to change polarity in the line frequently. We 
can just add a flag per gsi to indicate whether a physical irq is injected 
on this line. When intercepting HVM EOI, invoke deassert and also jump 
to ->end() if flag is on. Does it work basically?


Xen-devel mailing list

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