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

Re: [Xen-devel] MSI and VT-d interrupt remapping



On 6/3/08 21:07, "Espen Skoglund" <espen.skoglund@xxxxxxxxxxxxx> wrote:

> If an MSI capable device was able to make use of the above feature,
> the device could be set up to generate different interrupts depending
> on where the incoming interrupt was to be handled.  For example,
> incoming data for a particular guest could trigger an interrupt on the
> processor where that guest is running.  Obviously, a dom0-like backend
> driver would not be involved in the actual event delivery in these
> situations.  The event would be delivered directly to the frontend.
> 
> The necessary changes would enable a device driver for an MSI capable
> device to allocate a range of pirqs and bind these to different
> frontends.

The only tricky bit here is deciding what the interface should be to the
hypervisor to specify these allocation constraints.

Another thought though: there's no good reqson for Xen to scatter its
irq-vector allocations across the vector space. That's a holdover from
classic-Pentium-era systems, which could lose interrupts if too many got
'queued up' at any single priority level. So we could actually allocate our
vectors contiguously, making it much more likely that you could successfully
allocate a contiguous range even without remapping.

However, I guess you want to be able to specify different target APICs for
different vectors too, so again it comes back to: what should the guest
interface to irq-remapping hardware be?

 -- Keir



_______________________________________________
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®.