On Fri, 20 Jul 2012 12:22:37 -0700 Julian Stecklina (JS) wrote:
JS> One quick addition to this: If you guys implement that, be sure to test JS> it on a box that actually has Interrupt Remapping support. The kernel JS> will hide the difference (it magically returns the correct MSI JS> address/value pair to program), but if it works on a box with Interrupt JS> Remapping support, you are sure that you did everything correctly.
An application doesn't need to know if interrupt remapping is enabled or not. It just has program the MSI values given by the hypervisor into the device (if the device uses MSI rather than IOAPIC).
I think what Julian is hinting at, is, that incorrect code that appears to work on machines without interrupt remapping will fail once it runs on a machine with interrupt remapping. As with DMA remapping, this is due to the tighter restrictions enforced by the hypervisor. To be on the safe side, an applications that configures or uses interrupts must: 1) use assign_pci for each interrupt prior to using it 2) use the MSI values returned by assign_gsi, rather than making up your own
JS> Udo, is there an easy way to figure out, if a system supports Interrupt JS> Remapping short of looking into ACPI tables?
You could infer that from looking at the MSI data provided by the hypervisor. Or the hypervisor could announce it in the HIP. But like I said, userland doesn't really need to know.
JS> > (I'm thinking about adding some code to the hypervisor, causing sem_down to JS> > fail on an interrupt semaphore unless the interrupt has been configured JS> > using assign_gsi.) JS> JS> +1 from me. That would cause broken code to fail early.
The reason I haven't done it yet, is, that it adds a branch to every sem_down on an interrupt semaphore, which is overhead you pay every time, just to get some additional checking at initialization time.