On Tue, Nov 30, 2021 at 10:23:16PM +0100, Thomas Gleixner wrote: > > If this doesn't become an irq_chip what other way is there to properly > > program the addr/data pair as drivers/ntb/msi.c is doing? > > That's not the question. This surely will be a separate irq chip and a > separate irqdomain. OK > The real problem is where to store the MSI descriptors because the PCI > device has its own real PCI/MSI-X interrupts which means it still shares > the storage space. Er.. I never realized that just looking at the patches :| That is relevant to all real "IMS" users. IDXD escaped this because it, IMHO, wrongly used the mdev with the IRQ layer. The mdev is purely a messy artifact of VFIO, it should not be required to make the IRQ layers work. I don't think it makes sense that the msi_desc would point to a mdev, the iommu layer consumes the msi_desc_to_dev(), it really should point to the physical device that originates the message with a proper iommu ops/data/etc. > I'm currently tending to partition the index space in the xarray: > > 0x00000000 - 0x0000ffff PCI/MSI-X > 0x00010000 - 0x0001ffff NTB It is OK, with some xarray work it can be range allocating & reserving so that the msi_domain_alloc_irqs() flows can carve out chunks of the number space.. Another view is the msi_domain_alloc_irqs() flows should have their own xarrays.. > which is feasible now with the range modifications and way simpler to do > with xarray than with the linked list. Indeed! Regards, Jason
