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]Question about qemu interrupt deliver.

To: "Xu, Anthony" <anthony.xu@xxxxxxxxx>, Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel]Question about qemu interrupt deliver.
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Wed, 29 Nov 2006 10:20:40 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 29 Nov 2006 02:20:46 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <51CFAB8CB6883745AE7B93B3E084EBE207DD72@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: AccTi/UCWhQFxKqBSYWUgXBidhb4LgAAe01hAAAWaeAABHI+Wg==
Thread-topic: [Xen-devel]Question about qemu interrupt deliver.
User-agent: Microsoft-Entourage/11.2.5.060620
On 29/11/06 08:21, "Xu, Anthony" <anthony.xu@xxxxxxxxx> wrote:

> How about the second one?
> #define hvm_pci_intx_gsi(dev, intx)  \
>     (((((dev)<<2) + ((dev)>>3) + (intx)) & 31) + 16)
> 
> Why this logic is implemented inside hypervisor?

Since the hypervisor exposes a device-level interface for interrupt
assertion, the mapping from device INTx line to GSI naturally ends up in the
hypervisor. This makes sense IMO -- GSIs can be shared and to correctly
implement wire-OR semantics the guest needs to disambiguate which devices
are (or are not) asserting a particular GSI at any time. Obviously all
interrupt-capable PCI devices are currently implemented in qemu-dm so this
could be worked around and a GSI-level interface exposed by Xen. But I think
putting it in Xen is cleaner and more flexible long term. There is always
the option of allowing the mapping to be dynamically specified to Xen in
future (e.g., hvmloader could make a choice, install the appropriate ACPI
DSDT and use a new hypercall to dynamically modify PCI->link and PCI->GSI
information). It's not clear that level of flexibility will be warranted
though -- 32 non-legacy GSIs should be plenty to avoid sharing even with a
static barber-pole INTx->GSI mapping.

 -- Keir


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