[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |