Re: [PATCH] iommu/dma: Always allow DMA-FQ when iommupt provides the iommu_domain

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Apr 03, 2026 at 10:16:34AM +0100, Will Deacon wrote:
> On Wed, Apr 01, 2026 at 10:13:49AM -0300, Jason Gunthorpe wrote:
> > On Wed, Apr 01, 2026 at 01:53:05PM +0100, Robin Murphy wrote:
> > > Note that IOMMU_CAP_CACHE_COHERENCY is also arguably a property of
> > > generic_pt, in as much as all its users are default-coherent with
> > > IOMMU_CACHE implied, but again RISC_V doesn't report that where AMD and
> > > Intel do.
> > 
> > Hmm.. Currently generic_pt doesn't have any idea if IOMMU_CACHE is
> > supported and working in HW. All the implemented formats ignore
> > IOMMU_CACHE entirely, they use IOMMU_MMIO to build any any non-caching
> > PTE.
> > 
> > SMMUv3 will be unlike the other three and needs
> > IOMMU_CAP_CACHE_COHERENCY.  IDK if ARM should be writing non-caching
> > PTEs for non-coherent DMA, it doesn't now..
> 
> Sorry, but I'm not sure I follow here. The driver just honours
> IOMMU_CACHE when writing the ptes and dma_info_to_prot() sets that
> according to whether or not the device is coherent. I'd prefer not to
> have the SMMU driver second-guess the DMA API around what is best for
> the endpoint.

The three drivers using iommupt right now only have two kinds of PTE,
cached and non-cached. IOMMU_MMIO selects the non-cached version
otherwise it is always cached. They don't have the idea of a '0'
value.

ARM does, so it has three kinds of PTE for each stage:
 - 0           -> ARM_LPAE_PTE_MEMATTR_NC or ARM_LPAE_MAIR_ATTR_IDX_NC
 - IOMMU_CACHE -> ARM_LPAE_PTE_MEMATTR_FWB_WB/OIWB or ARM_LPAE_MAIR_ATTR_IDX_CACHE
 - IOMMU_MMIO  -> ARM_LPAE_PTE_MEMATTR_DEV or ARM_LPAE_MAIR_ATTR_IDX_DEV

dma_info_to_prot() does make ARM do sensible things, but the other
arches ignore that and write a cachable IOPTE anyhow.

IOMMU_CAP_CACHE_COHERENCY is supposed to mean that IOMMU_CACHE works
fully in HW, so it should not be true if the iommu HW ignores the
cachable PTE.

Jason