Messages in this thread | | | Date | Tue, 30 Nov 2021 20:17:48 -0400 | From | Jason Gunthorpe <> | Subject | Re: [patch 21/32] NTB/msi: Convert to msi_on_each_desc() |
| |
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
| |