Re: [PATCH v4 02/21] iommufd: Add iommufd_sw_map_msi()

[Andrew Jones]

On Fri, Aug 21, 2026 at 01:12:56PM -0300, Jason Gunthorpe wrote:
> On Fri, Aug 21, 2026 at 05:18:49PM +0200, Andrew Jones wrote:
> > On Fri, Aug 21, 2026 at 11:31:55AM -0300, Jason Gunthorpe wrote:
> > > On Fri, Aug 21, 2026 at 04:23:22PM +0200, Andrew Jones wrote:
> > > > > But RISC-V IOMMU is also not involved in interrupt translation. Beyond
> > > > > it could remap the PAs which represent the CPUs, but you are not using
> > > > > it that way since it is statically setup.
> > > > > 
> > > > > So I'm not sure why the iommu gets an IR? Isn't it the same as ARM
> > > > > where the IMSIC itself just has a wack of PAs it needs to access so it
> > > > > calls iommu_dma_prepare_msi() to do it?
> > > > 
> > > > Right, this series is only remapping IMSIC PAs, not using the IOMMU MSI
> > > > table. The MSI table must be disabled when second-stage translation is
> > > > Bare, so it cannot be used for the host mappings here. It will be needed
> > > > for guest interrupt files (the irqbypass series I'm also working on),
> > > > where this IR irqdomain can then intercept irq_set_vcpu_affinity().
> > > > Also, keeping the MSI setup in this IR irqdomain avoids putting IOMMU
> > > > mapping knowledge in the IMSIC driver.
> > > 
> > > It's ok for the IMSIC driver to call iommu_dma_prepare_msi(), that's
> > > the architecutre of this at least.
> > > 
> > > Until you get to adding something more complicated, eg irqbypass, I'd
> > > suggest keeping this series simple.
> > > 
> > > I guess I would wonder why the IOMMU needs to be involved in changing
> > > the mapping down the road, why not just reprogram the MSI-X address?
> > >
> > 
> > For guest interrupts the MSI-X address is a guest IMSIC address.
> > Reprogramming it handles a guest reroute, but not vcpu migration (the
> > guest address stays the same while its host backing moves between
> > guest interrupt files and MRIFs). 
> 
> Linux isn't prepared to have a guest controlled MSI-X addr,
> AFAIK. I've wanted this for a long time but we are not there..
> 
> Does riscv absolutely require this? I suppose you have a new problem
> where you don't know what affinity the guest is selecting when it
> provides a MSI-X addr as you don't know what physical IMSIC page is
> under its S1 IOVA?

The IOMMU MSI table operates after S1, so it matches the resulting IMSIC
GPA. With a vIOMMU, the guest may use any MSI IOVA that its S1 maps to
that GPA. With S1 Bare, the device uses the GPA directly. In either case
the hypervisor provides the guest IMSIC topology and the guest interrupt
file or MRIF target needed to program the MSI table (through the IRQ
domain).

> 
> > The IOMMU driver updates that mapping through "the hypervisor to
> > IOMMU driver interface", a.k.a. the IRQ domain's
> > irq_set_vcpu_affinity() callback. That mapping cannot be prepared
> > ahead of time because only the hypervisor knows the target, and it
> > may change later.
> 
> Nicolin has a series that worked toward making ARM work properly, it
> is not at all like this and it isn't done with remapping domains.

I'll look it up.

> 
> You want to preserve the guests physical MSI-X info directly and plub
> through the proper mapping so that the S1 -> S2 translation setup by
> the guest actually works right.
> 
> If you don't do that then you can just have Linux adjust the MSI-X
> addr like intel does and use the RMR trick from ARM to get the IMSIC
> pages into the S1 IOVA. Still no need for a remapping domain.
> 
> It's so complex, so I think you will have an easier time doing tiny
> small steps at a time..
>

Right, I have a working prototype where the hypervisor manages the MSI
table through the IOMMU driver's IR irqdomain with
irq_set_vcpu_affinity(). Splitting that into upstreamable steps is what
I'm working on now.

Thanks,
drew