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] [PATCH 2/3][RFC] MSI/MSI-X support fordom0/driver domain

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH 2/3][RFC] MSI/MSI-X support fordom0/driver domain
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Mon, 28 May 2007 20:03:47 +0800
Delivery-date: Mon, 28 May 2007 05:02:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2808005.800C%Keir.Fraser@xxxxxxxxxxxx>
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: Aceg/mz7PRs/d4jlSeu7V67d+hYswQACriSgAACTnuAAAZF9OQAB6/ZAAAEo6AYAAAay8A==
Thread-topic: [Xen-devel] [PATCH 2/3][RFC] MSI/MSI-X support fordom0/driver domain
>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
>Sent: 2007年5月28日 19:48
>On 28/5/07 12:33, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>> I have the concern on xen to be involved in pirq allocation. Consider
>> the current case where pirq == irq, for INTx type devices of dom0, the
>> pirq number is always derived from ACPI table though static, and Xen
>> doesn't know such static number before dom0 requests to bind. How
>> about a MSI device enabled before an INTx only device? Also xen
>> doesn't know the pirq number to be used in the future like hotplug
>> case.
>Xen doesn't give a crap about the pirq namespace, except for subtle
>semantics associated with legacy isa irqs 0-15. Or at least, what little
>care it does have can (and likely will) be removed. So it's up to dom0
>whether it wants its pirq namespace to correspond to BIOS-assigned
>usual Linux allocation scheme, GSI space, or whatever. This interface
>let dom0 control how MSI and INTx is plumbed into its pirq space, if
>what it wants. Other domUs will have no need for an association
>their pirq namespace and physical hardware/bios irq numbering -- in this
>case it may make sense to leave it to Xen to do the allocation. But even
>here, the interface as I described it would allow dom0 to have control
>domU allocation too if it wants it.
> -- Keir

OK, I agree it's flexible and extensible. But is there any real usage 
model pushing on this? For example, is it better for pciback instance 
to allocate pirq space for domU? Pciback can select whether 
passthrough real irq number or allocate from a new space for 
target domain. To let Xen allocate instead makes it complex.

Also do we support mixed allocation policy to a given domain, 
when using suggested interface. For example, once one domain 
has BIOS-assigned scheme, it can't request Xen for auto-allocation. 
Or else it's difficult and complex for domain and Xen to sit on same 
page for shared allocation policy. Maybe we need some per-domain 
flag to control such allocation policy?


Xen-devel mailing list