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

[Jason Gunthorpe]

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.

No weridness in domain allocation, no messing with irq stuff in a
finalize function, no hackery to iommufd.

> There's no big PA window
> because the IMSIC PAs aren't generally contiguous. iommu_dma_map_msi()
> factors the mapping operation out of iommu_dma_prepare_msi() and returns
> each IOVA directly. A batched list API would be possible, but it would
> only move the loop.

But it keeps the entire flow consistent. Trying to pre-map MSIs and
mangle all sorts of things in the riscv driver is undoing the
generalization and what is expected to be be common code.

I don't want to see any mapping of msi in the rsicv iommu driver at
all, that should be the most important design point.

Jason