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

From: Jason Gunthorpe <jgg@nvidia.com>
To: Andrew Jones <andrew.jones@oss.qualcomm.com>
Cc: linux-riscv@lists.infradead.org, iommu@lists.linux.dev,
	linux-kernel@vger.kernel.org, tomasz.jeznach@linux.dev,
	tjeznach@rivosinc.com, joro@8bytes.org, will@kernel.org,
	robin.murphy@arm.com, pjw@kernel.org, palmer@dabbelt.com,
	anup@brainfault.org, tglx@kernel.org, kevin.tian@intel.com,
	fangyu.yu@linux.alibaba.com
Subject: Re: [PATCH v4 02/21] iommufd: Add iommufd_sw_map_msi()
Date: Fri, 21 Aug 2026 11:00:33 -0300	[thread overview]
Message-ID: <20260821140033.GH244917@nvidia.com> (raw)
In-Reply-To: <zygm4qm3fjv57nsgcectwikfa3cdnidxnhv55nxv4b6l2kllrs@dt36j4p3zhoa>

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?

Jason

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv