USB HID driver fails to recognize input devices

Udo Steinberg udo at ...121...
Fri Jul 20 22:54:35 CEST 2012


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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.genode.org/pipermail/users/attachments/20120720/67a47359/attachment.sig>


More information about the users mailing list