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

Andrew Jones <[email protected]>
Newsgroups org.infradead.lists.linux-riscv,dev.linux.lists.iommu,org.kernel.vger.linux-kernel
Message-ID <zygm4qm3fjv57nsgcectwikfa3cdnidxnhv55nxv4b6l2kllrs@dt36j4p3zhoa>
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.

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

ARM calls iommu_dma_prepare_msi() from ITS since there is no SMMU
irqdomain and ITS owns the MSI target. 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.

Thanks,
drew

_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.