On Mon, Nov 29, 2021 at 04:52:35PM -0700, Logan Gunthorpe wrote: > > > On 2021-11-29 4:31 p.m., Jason Gunthorpe wrote: > > On Mon, Nov 29, 2021 at 03:27:20PM -0700, Logan Gunthorpe wrote: > > > >> In most cases, the NTB code needs more interrupts than the hardware > >> actually provides for in its MSI-X table. That's what PCI_IRQ_VIRTUAL is > >> for: it allows the driver to request more interrupts than the hardware > >> advertises (ie. pci_msix_vec_count()). These extra interrupts are > >> created, but get flagged with msi_attrib.is_virtual which ensures > >> functions that program the MSI-X table don't try to write past the end > >> of the hardware's table. > > > > AFAICT what you've described is what Intel is calling IMS in other > > contexts. > > > > IMS is fundamentally a way to control MSI interrupt descriptors that > > are not accessed through PCI SIG compliant means. In this case the NTB > > driver has to do its magic to relay the addr/data pairs to the real > > MSI storage in the hidden devices. > > With current applications, it isn't that there is real "MSI storage" > anywhere; the device on the other side of the bridge is always another > Linux host which holds the address (or rather mw offset) and data in > memory to use when it needs to trigger the interrupt of the other > machine. Sure, that is fine "MSI Storage". The triggering device only needs to store the addr/data pair someplace to be "MSI Storage". Jason
