Hi, for the past days, I had a look at the issue of classic MSIs (ie. not MSI-X) under non-Linux I-pipe domains. Actually, the path that matters most, IRQ delivery, is perfectly OK as is: just a simple ack on the APIC and a NOP on completion.
Problematic are IRQ enable/disable (which automatically includes setup/cleanup) and affinity updates. The point is that we specified at least the first two services to be usable from RT context as well. That's a nice-to-have with fast IRQ chips, but its a nightmare with others. Classic MSI belongs to the latter category. So we basically have two main options now, each having two variants: 1) disallow IRQ enabled/disable over non-root contexts 1a) confine this to certain IRQs like MSI or 1b) make it a generic API property 2) provide ipipe_irq_mask/unmask services and use them in Xenomai 2a) for MSI, either to map them on a software mask or 2b) to map them on MSI-specific services that bypass the ordinary [un]mask_msi_irq and use hardened ones (*) I would prefer to go for the cheaper option 1), probably 1a) as we have non-MSI users out there that do disable/enable trickery from RT contexts. Unfortunately, also 1a) will require some new interface between I-pipe and Xenomai to inform the user about the limited usability of enable/disable and likely even enforce it at Xenomai level. Comments, ideas? Jan (*) Previously posted patches to address the MSI issue by hardening both pci_config_lock and pci_lock likely failed as the latter is of too broad scope, including wake_up_all. -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux _______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core