Re: [PATCH v6 01/16] iommu/dma: Prepare MSI physical address lists

[Andrew Jones]

Hi Robin,

On Fri, Oct 02, 2026 at 05:21:18PM +0100, Robin Murphy wrote:
> You already end up adding what is effectively a RISC-V-specific
> entrypoint, so you may as well just carry that all the way through to
> its own effectively RISC-V-specific implementation

The list API came out of the v4[1] discussion with Jason. Preparing the
targets as one contiguous IOVA range lets the MSI descriptor cache the
base and IMSIC compose the address as base + CPU offset. That got
rid of the separate domain-local lookup table and its lifetime handling,
which I think was a worthwhile improvement.

I'd like to keep that model. I'm open to splitting the implementation,
but most of the added code seems necessary to prepare multiple targets
together, regardless of whether the list is fixed.

> it should merely be a case of whether a) this is the first call for
> the given cookie so everything needs mapping, or b) it's not the
> first call, so everything must already be mapped and we can just
> return the IOVA.

For DMA-IOMMU, yes, remembering the base would let us drop the range
matching. We'd still need the contiguous IOVA allocation, mapping loop,
rollback on failure, and locking across the whole operation.

For iommufd, there are also separate things to track: whether the context
has allocated IOVAs for the set, whether a particular HWPT has those
mappings installed, and whether a group needs them installed when its
domain is replaced. Having one fixed list doesn't by itself remove
that bookkeeping.

The current IMSIC caller does always supply the same list. We could make
that a requirement, but we'd need to define its scope: per cookie for
DMA-IOMMU, and how it applies across groups and HWPTs for iommufd. The
current interface instead takes an ordered list and provides contiguous
IOVAs for it; the range matching makes reuse honor that contract.

> At very worst, a separate hook to just pre-populate msi_page_list
> with a regular page for each IMSIC address [...] could probably
> suffice without any other major structural changes

Is the main concern the range matching, or the shared mapping path
itself? Apart from lookup, both paths need much the same allocation,
mapping, locking, cleanup, and descriptor handling. Keeping those
separate seems likely to duplicate code, while factoring them into
shared helpers seems likely to bring us back towards a list-based
mapping helper.

We could handle lookup of existing mappings separately for the single-page
and list cases while sharing the allocation and mapping code. But I'm not
yet seeing a substantial overall simplification from requiring a fixed
list. Is there more bookkeeping you have in mind that could go away with
that restriction?

[1] https://lore.kernel.org/all/20260820214150.545737-3-andrew.jones@xxxxxxxxxxxxxxxx/

Thanks,
drew