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: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, 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: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Thu, 31 May 2007 16:03:21 +0100
Delivery-date: Thu, 31 May 2007 08:01:48 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <D470B4E54465E3469E2ABBC5AFAC390F013B1EB1@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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+WeAABwdLMABRnVWAADaM8MAADBqQEAAAbqrAAAuWvEQ==
Thread-topic: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d
User-agent: Microsoft-Entourage/
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 with
this, but I expect they might steal hvm-bound physical irqs completely, hook
them off early in do_IRQ() and have bespoke code to deal with them. Possibly
it could be integrated with existing ->ack and ->end methods, actually.
->end() would be no-op while ->ack() would switch polarity in the IOAPIC and
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. :-)

 -- Keir

Xen-devel mailing list

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