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

[Andrew Jones]

On Fri, Aug 21, 2026 at 11:00:33AM -0300, Jason Gunthorpe wrote:
> On Fri, Aug 21, 2026 at 03:47:17PM +0200, Andrew Jones wrote:
> > On Fri, Aug 21, 2026 at 09:02:04AM -0300, Jason Gunthorpe wrote:
> > > On Fri, Aug 21, 2026 at 01:07:03PM +0200, Andrew Jones wrote:
> > > 
> > > > > What I rather expected was for riscv to have a PA window that is very
> > > > > big and not just one page, eg adjust iommu_dma_prepare_msi() so you
> > > > > can pass in the entire PA space that you need for the affinity
> > > > > changes. Maybe this is a list of phys_addr_t ?
> > > > 
> > > > That's more or less what this series does. 
> > > 
> > > But it does it in a completely different way, and I'm struggling to
> > > see any justification for this.
> > > 
> > > Again, just pass your list of PAs to iommu_dma_prepare_msi() from the
> > > irq domain seems like the easiest and most ARM aligned thing.
> > > 
> > > When you need a new IOVA for an affinity change the PA's are already
> > > mapped a simple offset calculation is that is needed.
> > 
> > Ah, I see what I missed. The proposed batched API would guarantee a
> > contiguous IOVA range, so the descriptor could cache the IOVA base and
> > then the riscv IR compose-msi-msg could simply compute its target off
> > that base. That would indeed eliminate msi_iova[] and all its complexity.
> 
> Yeah, that is pretty simple like that
> 
> Then you just need to teach everything downstream to have a list of
> phys not a single phys and thats an easy to understand delta
> 
> > ARM calls iommu_dma_prepare_msi() from ITS since there is no SMMU
> > irqdomain and ITS owns the MSI target.
> 
> Right SMMU is not involved in interrupt translation
> 
> > This series adds a RISC-V IOMMU IR irqdomain to replace the IMSIC PA
> > with the corresponding IOVA, so the IR domain's alloc callback is
> > the right place to create the mappings through common
> > DMA-IOMMU/iommufd code.
> 
> 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.

Thanks,
drew