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] [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/11.3.3.061214
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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