[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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>
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • 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
>scheme,
>usual Linux allocation scheme, GSI space, or whatever. This interface
>will
>let dom0 control how MSI and INTx is plumbed into its pirq space, if
>that's
>what it wants. Other domUs will have no need for an association
>between
>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
>over
>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?

Thanks,
Kevin

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.