[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: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Mon, 28 May 2007 13:40:47 +0100
  • Delivery-date: Mon, 28 May 2007 05:37:01 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Aceg/mz7PRs/d4jlSeu7V67d+hYswQACriSgAACTnuAAAZF9OQAB6/ZAAAEo6AYAAAay8AAA4oLCAAAAikAAAO1vKw==
  • Thread-topic: [Xen-devel] [PATCH 2/3][RFC] MSI/MSI-X support fordom0/driver domain

On 28/5/07 13:29, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:

> 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?

You may be right. I just like to keep the hypervisor interfaces as flexible
as possible, to avoid unnecessarily baking in assumptions based on their
initial usage. It's a pretty small issue actually, since we can get the same
behaviour by dom0 attempting to map onto pirqs from zero upwards until it
finds one that isn't already in use.

 -- Keir

Xen-devel mailing list



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