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

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

[Jason Gunthorpe]

iommupt always supports the semantics required for DMA-FQ, when drivers
are converted to use it they automatically get support.

Detect iommpt directly instead of using IOMMU_CAP_DEFERRED_FLUSH and
remove IOMMU_CAP_DEFERRED_FLUSH from converted drivers.

This will also enable DMA-FQ on RISC-V.

Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
 drivers/iommu/amd/iommu.c   |  2 --
 drivers/iommu/dma-iommu.c   | 13 ++++++++++++-
 drivers/iommu/intel/iommu.c |  2 --
 3 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 528ebdd26d71c9..daa9eac1184748 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -2991,8 +2991,6 @@ static bool amd_iommu_capable(struct device *dev, enum iommu_cap cap)
 		return amdr_ivrs_remap_support;
 	case IOMMU_CAP_ENFORCE_CACHE_COHERENCY:
 		return true;
-	case IOMMU_CAP_DEFERRED_FLUSH:
-		return true;
 	case IOMMU_CAP_DIRTY_TRACKING: {
 		struct amd_iommu *iommu = get_amd_iommu_from_dev(dev);
 
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 5dac64be61bb27..fbed93f8bf0adb 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -14,6 +14,7 @@
 #include <linux/device.h>
 #include <linux/dma-direct.h>
 #include <linux/dma-map-ops.h>
+#include <linux/generic_pt/iommu.h>
 #include <linux/gfp.h>
 #include <linux/huge_mm.h>
 #include <linux/iommu.h>
@@ -648,6 +649,15 @@ static void iommu_dma_init_options(struct iommu_dma_options *options,
 	}
 }
 
+static bool iommu_domain_supports_fq(struct device *dev,
+				     struct iommu_domain *domain)
+{
+	/* iommupt always supports DMA-FQ */
+	if (iommupt_from_domain(domain))
+		return true;
+	return device_iommu_capable(dev, IOMMU_CAP_DEFERRED_FLUSH);
+}
+
 /**
  * iommu_dma_init_domain - Initialise a DMA mapping domain
  * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie()
@@ -706,7 +716,8 @@ static int iommu_dma_init_domain(struct iommu_domain *domain, struct device *dev
 
 	/* If the FQ fails we can simply fall back to strict mode */
 	if (domain->type == IOMMU_DOMAIN_DMA_FQ &&
-	    (!device_iommu_capable(dev, IOMMU_CAP_DEFERRED_FLUSH) || iommu_dma_init_fq(domain)))
+	    (!iommu_domain_supports_fq(dev, domain) ||
+	     iommu_dma_init_fq(domain)))
 		domain->type = IOMMU_DOMAIN_DMA;
 
 	return iova_reserve_iommu_regions(dev, domain);
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 5dca8e525c73c8..80b183e207e59b 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -3212,8 +3212,6 @@ static bool intel_iommu_capable(struct device *dev, enum iommu_cap cap)
 
 	switch (cap) {
 	case IOMMU_CAP_CACHE_COHERENCY:
-	case IOMMU_CAP_DEFERRED_FLUSH:
-		return true;
 	case IOMMU_CAP_PRE_BOOT_PROTECTION:
 		return dmar_platform_optin();
 	case IOMMU_CAP_ENFORCE_CACHE_COHERENCY:

base-commit: 447597c362ec566082b75688f2a8883771c066d5
-- 
2.43.0

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

[Tian, Kevin]

> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Friday, March 27, 2026 3:31 AM
> 
> iommupt always supports the semantics required for DMA-FQ, when drivers
> are converted to use it they automatically get support.
> 
> Detect iommpt directly instead of using IOMMU_CAP_DEFERRED_FLUSH and
> remove IOMMU_CAP_DEFERRED_FLUSH from converted drivers.
> 
> This will also enable DMA-FQ on RISC-V.
> 
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>

Reviewed-by: Kevin Tian <kevin.tian@intel.com>

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

[Robin Murphy]

On 2026-03-26 7:30 pm, Jason Gunthorpe wrote:
> iommupt always supports the semantics required for DMA-FQ, when drivers
> are converted to use it they automatically get support.
> 
> Detect iommpt directly instead of using IOMMU_CAP_DEFERRED_FLUSH and
> remove IOMMU_CAP_DEFERRED_FLUSH from converted drivers.
> 
> This will also enable DMA-FQ on RISC-V.

I'd much prefer to just add the cap to the RISC-V driver so it's 
obvious, rather than deliberately introduce a fiddly inconsistency. 
Besides, having iommu-dma poke directly at driver-specific internal 
implementation details seems exactly the kind of layering violation 
you're normally the first to object to.

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.

Thanks,
Robin.

> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> ---
>   drivers/iommu/amd/iommu.c   |  2 --
>   drivers/iommu/dma-iommu.c   | 13 ++++++++++++-
>   drivers/iommu/intel/iommu.c |  2 --
>   3 files changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
> index 528ebdd26d71c9..daa9eac1184748 100644
> --- a/drivers/iommu/amd/iommu.c
> +++ b/drivers/iommu/amd/iommu.c
> @@ -2991,8 +2991,6 @@ static bool amd_iommu_capable(struct device *dev, enum iommu_cap cap)
>   		return amdr_ivrs_remap_support;
>   	case IOMMU_CAP_ENFORCE_CACHE_COHERENCY:
>   		return true;
> -	case IOMMU_CAP_DEFERRED_FLUSH:
> -		return true;
>   	case IOMMU_CAP_DIRTY_TRACKING: {
>   		struct amd_iommu *iommu = get_amd_iommu_from_dev(dev);
>   
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 5dac64be61bb27..fbed93f8bf0adb 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -14,6 +14,7 @@
>   #include <linux/device.h>
>   #include <linux/dma-direct.h>
>   #include <linux/dma-map-ops.h>
> +#include <linux/generic_pt/iommu.h>
>   #include <linux/gfp.h>
>   #include <linux/huge_mm.h>
>   #include <linux/iommu.h>
> @@ -648,6 +649,15 @@ static void iommu_dma_init_options(struct iommu_dma_options *options,
>   	}
>   }
>   
> +static bool iommu_domain_supports_fq(struct device *dev,
> +				     struct iommu_domain *domain)
> +{
> +	/* iommupt always supports DMA-FQ */
> +	if (iommupt_from_domain(domain))
> +		return true;
> +	return device_iommu_capable(dev, IOMMU_CAP_DEFERRED_FLUSH);
> +}
> +
>   /**
>    * iommu_dma_init_domain - Initialise a DMA mapping domain
>    * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie()
> @@ -706,7 +716,8 @@ static int iommu_dma_init_domain(struct iommu_domain *domain, struct device *dev
>   
>   	/* If the FQ fails we can simply fall back to strict mode */
>   	if (domain->type == IOMMU_DOMAIN_DMA_FQ &&
> -	    (!device_iommu_capable(dev, IOMMU_CAP_DEFERRED_FLUSH) || iommu_dma_init_fq(domain)))
> +	    (!iommu_domain_supports_fq(dev, domain) ||
> +	     iommu_dma_init_fq(domain)))
>   		domain->type = IOMMU_DOMAIN_DMA;
>   
>   	return iova_reserve_iommu_regions(dev, domain);
> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> index 5dca8e525c73c8..80b183e207e59b 100644
> --- a/drivers/iommu/intel/iommu.c
> +++ b/drivers/iommu/intel/iommu.c
> @@ -3212,8 +3212,6 @@ static bool intel_iommu_capable(struct device *dev, enum iommu_cap cap)
>   
>   	switch (cap) {
>   	case IOMMU_CAP_CACHE_COHERENCY:
> -	case IOMMU_CAP_DEFERRED_FLUSH:
> -		return true;
>   	case IOMMU_CAP_PRE_BOOT_PROTECTION:
>   		return dmar_platform_optin();
>   	case IOMMU_CAP_ENFORCE_CACHE_COHERENCY:
> 
> base-commit: 447597c362ec566082b75688f2a8883771c066d5

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

[Jason Gunthorpe]

On Wed, Apr 01, 2026 at 01:53:05PM +0100, Robin Murphy wrote:
> On 2026-03-26 7:30 pm, Jason Gunthorpe wrote:
> > iommupt always supports the semantics required for DMA-FQ, when drivers
> > are converted to use it they automatically get support.
> > 
> > Detect iommpt directly instead of using IOMMU_CAP_DEFERRED_FLUSH and
> > remove IOMMU_CAP_DEFERRED_FLUSH from converted drivers.
> > 
> > This will also enable DMA-FQ on RISC-V.
> 
> I'd much prefer to just add the cap to the RISC-V driver so it's obvious,
> rather than deliberately introduce a fiddly inconsistency. Besides, having
> iommu-dma poke directly at driver-specific internal implementation details
> seems exactly the kind of layering violation you're normally the first to
> object to.

I don't view it as a "driver-specific internal" - generic pt is part
of the core API surface. It is fine to have it and the core code be
coupled together. So I don't like bouncing through the driver to get
information the core already has direct access to...

Like the map/unmap flow run differently now for generic pt and I think
we will keep building things in. My intention is that generic pt will
be mandatory to access certain new features and functions.

But I don't care so much, we can't eliminate IOMMU_CAP_DEFERRED_FLUSH
entirely, this would have just contained it to the para-virt drivers
that can never use generic pt.

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

RISCV does seem to have some gap here.

Jason

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

[Will Deacon]

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.

Will

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

[Jason Gunthorpe]

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