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

[Jason Gunthorpe]

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 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.

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..

Jason