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] Multiple IRQ's in HVM for Windows

To: James Harper <james.harper@xxxxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Multiple IRQ's in HVM for Windows
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Sat, 27 Dec 2008 10:22:58 +0000
Cc:
Delivery-date: Sat, 27 Dec 2008 02:23:31 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AEC6C66638C05B468B556EA548C1A77D015500EF@trantor>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AclnCjPkeAYvm5WbTaqM+PmGGNFiHQAIdYQ3AAU6BeAAATbLsQAADYFAAADLT9kALf9OEAABLL7gAAAL4JAAAN6snAAABoKQAADccJA=
Thread-topic: [Xen-devel] Multiple IRQ's in HVM for Windows
User-agent: Microsoft-Entourage/12.15.0.081119
On 27/12/2008 10:03, "James Harper" <james.harper@xxxxxxxxxxxxxxxx> wrote:

> The driver for the xen platform PCI device is a 'bus driver' under
> windows, and enumerates child devices. When it enumerates a child
> device, I can say 'and allocate me an interrupt line'.

So these child devices don't have to have a physical manifestation in PCI
space? And you can really request an arbitrary IRQ and then you are expected
to plumb it through? That sounds weird, but actually quite helpful for us.

Probably we'd implement it with an hvm_op to associate an event channel with
an IO-APIC pin or a local APIC vector. If implemented as wire-OR into a set
of IO-APIC pins, we'd need logic to deassert wires when event channels
become not-pending, before the wire gets resampled by the PIC/IO-APIC. It's
all easier if we can directly deliver to a LAPIC vector because those are
inherently edge-triggered / message-based (which I think is what we really
want; although it's more complicated if we need to be able to share a LAPIC
vector among several event channels without 'losing' edges).

 -- Keir



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