On Tue, 2010-11-09 at 09:01 +0100, Jan Kiszka wrote: > Am 07.11.2010 17:22, Jan Kiszka wrote: > > Am 07.11.2010 16:15, Philippe Gerum wrote: > >> The following patches implements the teardown approach. The basic idea > >> is: > >> - neither break nor improve old setups with legacy I-pipe patches not > >> providing the revised ipipe_control_irq call. > >> - fix the SMP race when detaching interrupts. > > > > Looks good. > > This actually causes one regression: I've just learned that people are > already happily using MSIs with Xenomai in the field. This is perfectly > fine as long as you don't fiddle with rtdm_irq_disable/enable in > non-root contexts or while hard IRQs are disable. The latter requirement > would be violated by this fix now.
What we could do is handle this corner-case in the ipipe directly, going for a nop when IRQs are off on a per-arch basis only to please those users, because I don't think we can generally tell people that using MSI is fine right now with respect to the above limitations. Besides, we can't enable CONFIG_PCI_MSI at all on powerpc 83xx yet (I suspect most other powerpc platforms are broken the same way), this simply causes a lockup at boot. So more work is really needed all over the place for having MSI officially supported in Xenomai. > > I've evaluated hardening MSI disable/enable in further details in the > meantime. But after collecting information about the latency impacts of > accessing PCI devices' config spaces during some KVM pass-through work, > I finally had to give up this path. What remains (besides restricting > the irq_disable/enable usage) is a software-maintained mask, but that > also requires updated I-pipe patches and refactorings on Xenomai's HAL. I agree that trying to fit the PCI config accesses over the primary domain would be just insane, I see way too many intricacies and room for deadly issues as well. -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
