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] [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:29:14 +0800
Delivery-date: Mon, 28 May 2007 05:27:32 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2808622.8019%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/ZAAAEo6AYAAAay8AAA4oLCAAAAikA=
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日 20:14
>
>On 28/5/07 13:03, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>
>> 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?
>
>I think you're making this more complicated than it really is. My
>preference
>for Xen doing the allocation for domUs is only because: what if there are
>more places than just pciback that can assign device irqs to domUs?
>The
>implementation complexity in Xen of supporting both allocation methods
>is
>tiny: presumably in either case we will maintain an array of pirqs per
>domain (maybe 0-255?) and in the case of Xen doing the allocation it just
>has to do a find-first-unused-pirq search. Trivial. Even if it doesn't have
>any users in the first instance (because we decide to let domU see real
>bios
>numbers, or whatever), it's a simple service to provide in case it's useful
>in future.
>
> -- Keir

Let me re-open the case a bit. :-)

I understand your point, and yes that's an easy implementation. My 
small concern now is just whether it's worthy to pull Xen into resource 
allocation for which Xen has nothing reference at all. Shouldn't the 
components to assign device irq better does the allocation based on 
its own policy? For current stage, HVM domain has device model to 
provide 'pirq' layout and driver domainU has pciback. Even when later 
there're other places to assign device irqs, I think it's still responsibility 
of that place to construct the pirq name space for domU. For example, 
how about the simple Xen pirq allocation policy doesn't satisfy the 
special requirement of that place, like a special prime-number style 
(just kidding)? If such simple, but no-use from Xen POV, interface 
doesn't have users now and also may not address all possibilities in 
the future, do we need that indeed?

P.S. I'm not against now, and just not used to the style a bit. :-)

Thanks,
Kevin

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