[PATCH 0/2] iommu: Report effective PCIe ATS support status

[PATCH 0/2] iommu: Report effective PCIe ATS support status

[Shameer Kolothum]

PCIe ATS may be disabled by platform firmware, root complex limitations,
or host kernel policy, even when a device advertises the ATS capability
in its PCI config space.

Userspace currently cannot determine whether ATS is effectively supported
for a device. This may lead to incorrect assumptions when ATS appears
present in PCI config space but is disabled by the platform, e.g., in use
cases such as VFIO device pass-through.

This series introduces IOMMU_CAP_PCI_ATS_NOT_SUPPORTED to allow drivers to
report when ATS is not supported for a device, and extends iommufd to
expose this information via IOMMU_GET_HW_INFO.

The negative capability is chosen for backward compatibility: on older
kernels the flag will be absent and userspace will retain the existing
behaviour (i.e. assume ATS is usable if advertised).

Please see the related QEMU discussion for SMMUv3 accelerator use case
here[0].

Please take a look and let me know.

Thanks,
Shameer

[0] https://lore.kernel.org/qemu-devel/CH3PR12MB7548515EDA96BD03F64DCAA2AB62A@CH3PR12MB7548.namprd12.prod.outlook.com/

Shameer Kolothum (2):
  iommu: Add device ATS not supported capability
  iommufd: Report ATS not supported status via IOMMU_GET_HW_INFO

 include/linux/iommu.h                       | 2 ++
 include/uapi/linux/iommufd.h                | 3 +++
 drivers/iommu/amd/iommu.c                   | 6 ++++++
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 +++
 drivers/iommu/intel/iommu.c                 | 2 ++
 drivers/iommu/iommufd/device.c              | 3 +++
 6 files changed, 19 insertions(+)

-- 
2.43.0

[PATCH 1/2] iommu: Add device ATS not supported capability

[Shameer Kolothum]

PCIe ATS may be disabled by platform firmware, root complex limitations,
or kernel policy even when a device advertises the ATS capability in its
PCI configuration space.

Add a new IOMMU_CAP_PCI_ATS_NOT_SUPPORTED capability to allow IOMMU
drivers to report the effective ATS decision for a device.

When this capability is returned true for a device, ATS is not
supported and not used for that device, regardless of the presence
of the PCI ATS capability.

A subsequent patch will extend iommufd to expose the effective ATS
status to userspace.

Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
---
 include/linux/iommu.h                       | 2 ++
 drivers/iommu/amd/iommu.c                   | 6 ++++++
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 +++
 drivers/iommu/intel/iommu.c                 | 2 ++
 4 files changed, 13 insertions(+)

diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 54b8b48c762e..f40ecdc5d761 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -271,6 +271,8 @@ enum iommu_cap {
 	 */
 	IOMMU_CAP_DEFERRED_FLUSH,
 	IOMMU_CAP_DIRTY_TRACKING,	/* IOMMU supports dirty tracking */
+	/* ATS is not supported and not used on this device */
+	IOMMU_CAP_PCI_ATS_NOT_SUPPORTED,
 };
 
 /* These are the possible reserved region types */
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 81c4d7733872..aa4399b6b6db 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -2985,6 +2985,12 @@ static bool amd_iommu_capable(struct device *dev, enum iommu_cap cap)
 
 		return amd_iommu_hd_support(iommu);
 	}
+	case IOMMU_CAP_PCI_ATS_NOT_SUPPORTED: {
+		struct iommu_dev_data *dev_data = dev_iommu_priv_get(dev);
+
+		return !(amd_iommu_iotlb_sup &&
+			 (dev_data->flags & AMD_IOMMU_DEVICE_FLAG_ATS_SUP));
+	}
 	default:
 		break;
 	}
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 4d00d796f078..c20d2454ca14 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -107,6 +107,7 @@ static const char * const event_class_str[] = {
 };
 
 static int arm_smmu_alloc_cd_tables(struct arm_smmu_master *master);
+static bool arm_smmu_ats_supported(struct arm_smmu_master *master);
 
 static void parse_driver_options(struct arm_smmu_device *smmu)
 {
@@ -2494,6 +2495,8 @@ static bool arm_smmu_capable(struct device *dev, enum iommu_cap cap)
 		return true;
 	case IOMMU_CAP_DIRTY_TRACKING:
 		return arm_smmu_dbm_capable(master->smmu);
+	case IOMMU_CAP_PCI_ATS_NOT_SUPPORTED:
+		return !arm_smmu_ats_supported(master);
 	default:
 		return false;
 	}
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index ef7613b177b9..0be69695e88a 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -3220,6 +3220,8 @@ static bool intel_iommu_capable(struct device *dev, enum iommu_cap cap)
 		return ecap_sc_support(info->iommu->ecap);
 	case IOMMU_CAP_DIRTY_TRACKING:
 		return ssads_supported(info->iommu);
+	case IOMMU_CAP_PCI_ATS_NOT_SUPPORTED:
+		return !info->ats_supported;
 	default:
 		return false;
 	}
-- 
2.43.0

[PATCH 2/2] iommufd: Report ATS not supported status via IOMMU_GET_HW_INFO

[Shameer Kolothum]

If the IOMMU driver reports that ATS is not supported for a device, set
the IOMMU_HW_CAP_PCI_ATS_NOT_SUPPORTED flag in the returned hardware
capabilities.

When this flag is set, ATS is not supported and not used for the device.

Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
---
 include/uapi/linux/iommufd.h   | 3 +++
 drivers/iommu/iommufd/device.c | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/include/uapi/linux/iommufd.h b/include/uapi/linux/iommufd.h
index 1dafbc552d37..d85a2d3e1b40 100644
--- a/include/uapi/linux/iommufd.h
+++ b/include/uapi/linux/iommufd.h
@@ -695,11 +695,14 @@ enum iommu_hw_info_type {
  * @IOMMU_HW_CAP_PCI_PASID_PRIV: Privileged Mode Supported, user ignores it
  *                               when the struct
  *                               iommu_hw_info::out_max_pasid_log2 is zero.
+ * @IOMMU_HW_CAP_PCI_ATS_NOT_SUPPORTED: ATS is not supported and not used on
+ *                                      this device.
  */
 enum iommufd_hw_capabilities {
 	IOMMU_HW_CAP_DIRTY_TRACKING = 1 << 0,
 	IOMMU_HW_CAP_PCI_PASID_EXEC = 1 << 1,
 	IOMMU_HW_CAP_PCI_PASID_PRIV = 1 << 2,
+	IOMMU_HW_CAP_PCI_ATS_NOT_SUPPORTED = 1 << 3,
 };
 
 /**
diff --git a/drivers/iommu/iommufd/device.c b/drivers/iommu/iommufd/device.c
index 344d620cdecc..2e98818806c0 100644
--- a/drivers/iommu/iommufd/device.c
+++ b/drivers/iommu/iommufd/device.c
@@ -1624,6 +1624,9 @@ int iommufd_get_hw_info(struct iommufd_ucmd *ucmd)
 	if (device_iommu_capable(idev->dev, IOMMU_CAP_DIRTY_TRACKING))
 		cmd->out_capabilities |= IOMMU_HW_CAP_DIRTY_TRACKING;
 
+	if (device_iommu_capable(idev->dev, IOMMU_CAP_PCI_ATS_NOT_SUPPORTED))
+		cmd->out_capabilities |= IOMMU_HW_CAP_PCI_ATS_NOT_SUPPORTED;
+
 	cmd->out_max_pasid_log2 = 0;
 	/*
 	 * Currently, all iommu drivers enable PASID in the probe_device()
-- 
2.43.0

Re: [PATCH 1/2] iommu: Add device ATS not supported capability

[Samiullah Khawaja]

On Tue, Mar 03, 2026 at 03:03:47PM +0000, Shameer Kolothum wrote:
>PCIe ATS may be disabled by platform firmware, root complex limitations,
>or kernel policy even when a device advertises the ATS capability in its
>PCI configuration space.
>
>Add a new IOMMU_CAP_PCI_ATS_NOT_SUPPORTED capability to allow IOMMU
>drivers to report the effective ATS decision for a device.

nit: Maybe have IOMMU_CAP_PCI_ATS_SUPPORTED instead of the negative
variant of the capability. As this will affect only new users who might
check this capability so this does not really have to be negative.
>
>When this capability is returned true for a device, ATS is not
>supported and not used for that device, regardless of the presence
>of the PCI ATS capability.
>
>A subsequent patch will extend iommufd to expose the effective ATS
>status to userspace.
>
>Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
>Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
>---
> include/linux/iommu.h                       | 2 ++
> drivers/iommu/amd/iommu.c                   | 6 ++++++
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 +++
> drivers/iommu/intel/iommu.c                 | 2 ++
> 4 files changed, 13 insertions(+)
>
>diff --git a/include/linux/iommu.h b/include/linux/iommu.h
>index 54b8b48c762e..f40ecdc5d761 100644
>--- a/include/linux/iommu.h
>+++ b/include/linux/iommu.h
>@@ -271,6 +271,8 @@ enum iommu_cap {
> 	 */
> 	IOMMU_CAP_DEFERRED_FLUSH,
> 	IOMMU_CAP_DIRTY_TRACKING,	/* IOMMU supports dirty tracking */
>+	/* ATS is not supported and not used on this device */
>+	IOMMU_CAP_PCI_ATS_NOT_SUPPORTED,
> };
>
> /* These are the possible reserved region types */
>diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
>index 81c4d7733872..aa4399b6b6db 100644
>--- a/drivers/iommu/amd/iommu.c
>+++ b/drivers/iommu/amd/iommu.c
>@@ -2985,6 +2985,12 @@ static bool amd_iommu_capable(struct device *dev, enum iommu_cap cap)
>
> 		return amd_iommu_hd_support(iommu);
> 	}
>+	case IOMMU_CAP_PCI_ATS_NOT_SUPPORTED: {
>+		struct iommu_dev_data *dev_data = dev_iommu_priv_get(dev);
>+
>+		return !(amd_iommu_iotlb_sup &&
>+			 (dev_data->flags & AMD_IOMMU_DEVICE_FLAG_ATS_SUP));
>+	}
> 	default:
> 		break;
> 	}
>diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>index 4d00d796f078..c20d2454ca14 100644
>--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>@@ -107,6 +107,7 @@ static const char * const event_class_str[] = {
> };
>
> static int arm_smmu_alloc_cd_tables(struct arm_smmu_master *master);
>+static bool arm_smmu_ats_supported(struct arm_smmu_master *master);
>
> static void parse_driver_options(struct arm_smmu_device *smmu)
> {
>@@ -2494,6 +2495,8 @@ static bool arm_smmu_capable(struct device *dev, enum iommu_cap cap)
> 		return true;
> 	case IOMMU_CAP_DIRTY_TRACKING:
> 		return arm_smmu_dbm_capable(master->smmu);
>+	case IOMMU_CAP_PCI_ATS_NOT_SUPPORTED:
>+		return !arm_smmu_ats_supported(master);
> 	default:
> 		return false;
> 	}
>diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
>index ef7613b177b9..0be69695e88a 100644
>--- a/drivers/iommu/intel/iommu.c
>+++ b/drivers/iommu/intel/iommu.c
>@@ -3220,6 +3220,8 @@ static bool intel_iommu_capable(struct device *dev, enum iommu_cap cap)
> 		return ecap_sc_support(info->iommu->ecap);
> 	case IOMMU_CAP_DIRTY_TRACKING:
> 		return ssads_supported(info->iommu);
>+	case IOMMU_CAP_PCI_ATS_NOT_SUPPORTED:
>+		return !info->ats_supported;
> 	default:
> 		return false;
> 	}
>-- 
>2.43.0
>
>

Thanks,
Sami

Re: [PATCH 1/2] iommu: Add device ATS not supported capability

[Jason Gunthorpe]

On Tue, Mar 03, 2026 at 10:42:48PM +0000, Samiullah Khawaja wrote:
> On Tue, Mar 03, 2026 at 03:03:47PM +0000, Shameer Kolothum wrote:
> > PCIe ATS may be disabled by platform firmware, root complex limitations,
> > or kernel policy even when a device advertises the ATS capability in its
> > PCI configuration space.
> > 
> > Add a new IOMMU_CAP_PCI_ATS_NOT_SUPPORTED capability to allow IOMMU
> > drivers to report the effective ATS decision for a device.
> 
> nit: Maybe have IOMMU_CAP_PCI_ATS_SUPPORTED instead of the negative
> variant of the capability. As this will affect only new users who might
> check this capability so this does not really have to be negative.

It is deliberately negative for UAPI reasons.

Currently all userspace should assume ATS is supported.

The negative means new userspace that is sensitive will still work
correctly on old and new kernels that both return 0 as meaning ATS is
supported.

Perhaps this should be touched on in the commit message.

Jason

Re: [PATCH 1/2] iommu: Add device ATS not supported capability

[Samiullah Khawaja]

On Tue, Mar 03, 2026 at 07:28:35PM -0400, Jason Gunthorpe wrote:
>On Tue, Mar 03, 2026 at 10:42:48PM +0000, Samiullah Khawaja wrote:
>> On Tue, Mar 03, 2026 at 03:03:47PM +0000, Shameer Kolothum wrote:
>> > PCIe ATS may be disabled by platform firmware, root complex limitations,
>> > or kernel policy even when a device advertises the ATS capability in its
>> > PCI configuration space.
>> >
>> > Add a new IOMMU_CAP_PCI_ATS_NOT_SUPPORTED capability to allow IOMMU
>> > drivers to report the effective ATS decision for a device.
>>
>> nit: Maybe have IOMMU_CAP_PCI_ATS_SUPPORTED instead of the negative
>> variant of the capability. As this will affect only new users who might
>> check this capability so this does not really have to be negative.
>
>It is deliberately negative for UAPI reasons.
>
>Currently all userspace should assume ATS is supported.
>
>The negative means new userspace that is sensitive will still work
>correctly on old and new kernels that both return 0 as meaning ATS is
>supported.

Ah yes, for old userspace missing cap means ATS is supported.
>
>Perhaps this should be touched on in the commit message.

+1
>
>Jason

Re: [PATCH 2/2] iommufd: Report ATS not supported status via IOMMU_GET_HW_INFO

[Samiullah Khawaja]

On Tue, Mar 03, 2026 at 03:03:48PM +0000, Shameer Kolothum wrote:
>If the IOMMU driver reports that ATS is not supported for a device, set
>the IOMMU_HW_CAP_PCI_ATS_NOT_SUPPORTED flag in the returned hardware
>capabilities.
>
>When this flag is set, ATS is not supported and not used for the device.
>
>Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
>---
> include/uapi/linux/iommufd.h   | 3 +++
> drivers/iommu/iommufd/device.c | 3 +++
> 2 files changed, 6 insertions(+)
>
>diff --git a/include/uapi/linux/iommufd.h b/include/uapi/linux/iommufd.h
>index 1dafbc552d37..d85a2d3e1b40 100644
>--- a/include/uapi/linux/iommufd.h
>+++ b/include/uapi/linux/iommufd.h
>@@ -695,11 +695,14 @@ enum iommu_hw_info_type {
>  * @IOMMU_HW_CAP_PCI_PASID_PRIV: Privileged Mode Supported, user ignores it
>  *                               when the struct
>  *                               iommu_hw_info::out_max_pasid_log2 is zero.
>+ * @IOMMU_HW_CAP_PCI_ATS_NOT_SUPPORTED: ATS is not supported and not used on
>+ *                                      this device.
>  */
> enum iommufd_hw_capabilities {
> 	IOMMU_HW_CAP_DIRTY_TRACKING = 1 << 0,
> 	IOMMU_HW_CAP_PCI_PASID_EXEC = 1 << 1,
> 	IOMMU_HW_CAP_PCI_PASID_PRIV = 1 << 2,
>+	IOMMU_HW_CAP_PCI_ATS_NOT_SUPPORTED = 1 << 3,
> };
>
> /**
>diff --git a/drivers/iommu/iommufd/device.c b/drivers/iommu/iommufd/device.c
>index 344d620cdecc..2e98818806c0 100644
>--- a/drivers/iommu/iommufd/device.c
>+++ b/drivers/iommu/iommufd/device.c
>@@ -1624,6 +1624,9 @@ int iommufd_get_hw_info(struct iommufd_ucmd *ucmd)
> 	if (device_iommu_capable(idev->dev, IOMMU_CAP_DIRTY_TRACKING))
> 		cmd->out_capabilities |= IOMMU_HW_CAP_DIRTY_TRACKING;
>
>+	if (device_iommu_capable(idev->dev, IOMMU_CAP_PCI_ATS_NOT_SUPPORTED))
>+		cmd->out_capabilities |= IOMMU_HW_CAP_PCI_ATS_NOT_SUPPORTED;
>+
> 	cmd->out_max_pasid_log2 = 0;
> 	/*
> 	 * Currently, all iommu drivers enable PASID in the probe_device()
>-- 
>2.43.0
>
>

Reviewed-by: Samiullah Khawaja <skhawaja@google.com>

RE: [PATCH 1/2] iommu: Add device ATS not supported capability

[Shameer Kolothum Thodi]

> -----Original Message-----
> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: 03 March 2026 23:29
> To: Samiullah Khawaja <skhawaja@google.com>
> Cc: Shameer Kolothum Thodi <skolothumtho@nvidia.com>;
> iommu@lists.linux.dev; linux-kernel@vger.kernel.org; joro@8bytes.org;
> will@kernel.org; robin.murphy@arm.com; baolu.lu@linux.intel.com;
> kevin.tian@intel.com; Nicolin Chen <nicolinc@nvidia.com>; Nathan Chen
> <nathanc@nvidia.com>; Matt Ochs <mochs@nvidia.com>; Krishnakant Jaju
> <kjaju@nvidia.com>
> Subject: Re: [PATCH 1/2] iommu: Add device ATS not supported capability
> 
> On Tue, Mar 03, 2026 at 10:42:48PM +0000, Samiullah Khawaja wrote:
> > On Tue, Mar 03, 2026 at 03:03:47PM +0000, Shameer Kolothum wrote:
> > > PCIe ATS may be disabled by platform firmware, root complex limitations,
> > > or kernel policy even when a device advertises the ATS capability in its
> > > PCI configuration space.
> > >
> > > Add a new IOMMU_CAP_PCI_ATS_NOT_SUPPORTED capability to allow
> IOMMU
> > > drivers to report the effective ATS decision for a device.
> >
> > nit: Maybe have IOMMU_CAP_PCI_ATS_SUPPORTED instead of the negative
> > variant of the capability. As this will affect only new users who might
> > check this capability so this does not really have to be negative.
> 
> It is deliberately negative for UAPI reasons.
> 
> Currently all userspace should assume ATS is supported.
> 
> The negative means new userspace that is sensitive will still work
> correctly on old and new kernels that both return 0 as meaning ATS is
> supported.
> 
> Perhaps this should be touched on in the commit message.

Right, this is mentioned in the cover letter. I will update the commit
message as well.

Thanks,
Shameer

Re: [PATCH 1/2] iommu: Add device ATS not supported capability

[Jason Gunthorpe]

On Tue, Mar 03, 2026 at 03:03:47PM +0000, Shameer Kolothum wrote:
> PCIe ATS may be disabled by platform firmware, root complex limitations,
> or kernel policy even when a device advertises the ATS capability in its
> PCI configuration space.
> 
> Add a new IOMMU_CAP_PCI_ATS_NOT_SUPPORTED capability to allow IOMMU
> drivers to report the effective ATS decision for a device.
> 
> When this capability is returned true for a device, ATS is not
> supported and not used for that device, regardless of the presence
> of the PCI ATS capability.
> 
> A subsequent patch will extend iommufd to expose the effective ATS
> status to userspace.
> 
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
> ---
>  include/linux/iommu.h                       | 2 ++
>  drivers/iommu/amd/iommu.c                   | 6 ++++++
>  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 +++
>  drivers/iommu/intel/iommu.c                 | 2 ++
>  4 files changed, 13 insertions(+)
> 
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 54b8b48c762e..f40ecdc5d761 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -271,6 +271,8 @@ enum iommu_cap {
>  	 */
>  	IOMMU_CAP_DEFERRED_FLUSH,
>  	IOMMU_CAP_DIRTY_TRACKING,	/* IOMMU supports dirty tracking */
> +	/* ATS is not supported and not used on this device */
> +	IOMMU_CAP_PCI_ATS_NOT_SUPPORTED,

I think this one we should invert so it has saner semantics in-kernel
and for the drivers.

IOMMU_CAP_PCI_ATS_SUPPORTED

And then if not implemented it follows the usual cap protocol meaning
the iommu driver does nto support ATS.

It can be inverted by iommufd for the uapi.

Looks OK otherwise

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 1/2] iommu: Add device ATS not supported capability

[Jason Gunthorpe]

On Tue, Mar 03, 2026 at 03:03:47PM +0000, Shameer Kolothum wrote:
> @@ -271,6 +271,8 @@ enum iommu_cap {
>  	 */
>  	IOMMU_CAP_DEFERRED_FLUSH,
>  	IOMMU_CAP_DIRTY_TRACKING,	/* IOMMU supports dirty tracking */
> +	/* ATS is not supported and not used on this device */
> +	IOMMU_CAP_PCI_ATS_NOT_SUPPORTED,

Actually, on second thought, the kdoc should have more details about
what supported means.

Does this mean ATS is available and could be turned on ?

Or does it mean ATS is on *right now* ?

The drivers should be changing ATS dynamically depending on what
domain is attached.

I think the implementation follows the first option?

Jason

Re: [PATCH 2/2] iommufd: Report ATS not supported status via IOMMU_GET_HW_INFO

[Jason Gunthorpe]

On Tue, Mar 03, 2026 at 03:03:48PM +0000, Shameer Kolothum wrote:
> If the IOMMU driver reports that ATS is not supported for a device, set
> the IOMMU_HW_CAP_PCI_ATS_NOT_SUPPORTED flag in the returned hardware
> capabilities.
> 
> When this flag is set, ATS is not supported and not used for the device.
> 
> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
> ---
>  include/uapi/linux/iommufd.h   | 3 +++
>  drivers/iommu/iommufd/device.c | 3 +++
>  2 files changed, 6 insertions(+)

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

> diff --git a/include/uapi/linux/iommufd.h b/include/uapi/linux/iommufd.h
> index 1dafbc552d37..d85a2d3e1b40 100644
> --- a/include/uapi/linux/iommufd.h
> +++ b/include/uapi/linux/iommufd.h
> @@ -695,11 +695,14 @@ enum iommu_hw_info_type {
>   * @IOMMU_HW_CAP_PCI_PASID_PRIV: Privileged Mode Supported, user ignores it
>   *                               when the struct
>   *                               iommu_hw_info::out_max_pasid_log2 is zero.
> + * @IOMMU_HW_CAP_PCI_ATS_NOT_SUPPORTED: ATS is not supported and not used on
> + *                                      this device.

Same comment to clarify what this means. Does it mean ATS can be
turned on if the right HWPT is attached, or does it mean ATS is on
right now.

Jason

RE: [PATCH 1/2] iommu: Add device ATS not supported capability

[Shameer Kolothum Thodi]

> -----Original Message-----
> From: Jason Gunthorpe <jgg@ziepe.ca>
> Sent: 13 March 2026 16:49
> To: Shameer Kolothum Thodi <skolothumtho@nvidia.com>
> Cc: iommu@lists.linux.dev; linux-kernel@vger.kernel.org; joro@8bytes.org;
> will@kernel.org; robin.murphy@arm.com; baolu.lu@linux.intel.com;
> kevin.tian@intel.com; Nicolin Chen <nicolinc@nvidia.com>; Nathan Chen
> <nathanc@nvidia.com>; Matt Ochs <mochs@nvidia.com>; Krishnakant Jaju
> <kjaju@nvidia.com>
> Subject: Re: [PATCH 1/2] iommu: Add device ATS not supported capability
> 
> External email: Use caution opening links or attachments
> 
> 
> On Tue, Mar 03, 2026 at 03:03:47PM +0000, Shameer Kolothum wrote:
> > @@ -271,6 +271,8 @@ enum iommu_cap {
> >        */
> >       IOMMU_CAP_DEFERRED_FLUSH,
> >       IOMMU_CAP_DIRTY_TRACKING,       /* IOMMU supports dirty tracking */
> > +     /* ATS is not supported and not used on this device */
> > +     IOMMU_CAP_PCI_ATS_NOT_SUPPORTED,
> 
> Actually, on second thought, the kdoc should have more details about what
> supported means.
> 
> Does this mean ATS is available and could be turned on ?
> 
> Or does it mean ATS is on *right now* ?
> 
> The drivers should be changing ATS dynamically depending on what domain is
> attached.
> 
> I think the implementation follows the first option?

Yes. If we change it to IOMMU_CAP_PCI_ATS_SUPPORTED, it means ATS is
available and could be turned on. Will update.

Thanks,
Shameer

RE: [PATCH 2/2] iommufd: Report ATS not supported status via IOMMU_GET_HW_INFO

[Shameer Kolothum Thodi]

> -----Original Message-----
> From: Jason Gunthorpe <jgg@ziepe.ca>
> Sent: 13 March 2026 16:51
> To: Shameer Kolothum Thodi <skolothumtho@nvidia.com>
> Cc: iommu@lists.linux.dev; linux-kernel@vger.kernel.org; joro@8bytes.org;
> will@kernel.org; robin.murphy@arm.com; baolu.lu@linux.intel.com;
> kevin.tian@intel.com; Nicolin Chen <nicolinc@nvidia.com>; Nathan Chen
> <nathanc@nvidia.com>; Matt Ochs <mochs@nvidia.com>; Krishnakant Jaju
> <kjaju@nvidia.com>
> Subject: Re: [PATCH 2/2] iommufd: Report ATS not supported status via
> IOMMU_GET_HW_INFO
> 
> External email: Use caution opening links or attachments
> 
> 
> On Tue, Mar 03, 2026 at 03:03:48PM +0000, Shameer Kolothum wrote:
> > If the IOMMU driver reports that ATS is not supported for a device, set
> > the IOMMU_HW_CAP_PCI_ATS_NOT_SUPPORTED flag in the returned
> hardware
> > capabilities.
> >
> > When this flag is set, ATS is not supported and not used for the device.
> >
> > Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
> > ---
> >  include/uapi/linux/iommufd.h   | 3 +++
> >  drivers/iommu/iommufd/device.c | 3 +++
> >  2 files changed, 6 insertions(+)
> 
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> 
> > diff --git a/include/uapi/linux/iommufd.h b/include/uapi/linux/iommufd.h
> > index 1dafbc552d37..d85a2d3e1b40 100644
> > --- a/include/uapi/linux/iommufd.h
> > +++ b/include/uapi/linux/iommufd.h
> > @@ -695,11 +695,14 @@ enum iommu_hw_info_type {
> >   * @IOMMU_HW_CAP_PCI_PASID_PRIV: Privileged Mode Supported, user
> ignores it
> >   *                               when the struct
> >   *                               iommu_hw_info::out_max_pasid_log2 is zero.
> > + * @IOMMU_HW_CAP_PCI_ATS_NOT_SUPPORTED: ATS is not supported
> and not used on
> > + *                                      this device.
> 
> Same comment to clarify what this means. Does it mean ATS can be
> turned on if the right HWPT is attached, or does it mean ATS is on
> right now.

Since this one is negative : ATS is not supported and cannot be used.

Thanks,
Shameer

RE: [PATCH 2/2] iommufd: Report ATS not supported status via IOMMU_GET_HW_INFO

[Tian, Kevin]

> From: Shameer Kolothum Thodi <skolothumtho@nvidia.com>
> Sent: Saturday, March 14, 2026 12:57 AM
> 
> > -----Original Message-----
> > From: Jason Gunthorpe <jgg@ziepe.ca>
> > Sent: 13 March 2026 16:51
> > To: Shameer Kolothum Thodi <skolothumtho@nvidia.com>
> > Cc: iommu@lists.linux.dev; linux-kernel@vger.kernel.org; joro@8bytes.org;
> > will@kernel.org; robin.murphy@arm.com; baolu.lu@linux.intel.com;
> > kevin.tian@intel.com; Nicolin Chen <nicolinc@nvidia.com>; Nathan Chen
> > <nathanc@nvidia.com>; Matt Ochs <mochs@nvidia.com>; Krishnakant Jaju
> > <kjaju@nvidia.com>
> > Subject: Re: [PATCH 2/2] iommufd: Report ATS not supported status via
> > IOMMU_GET_HW_INFO
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Tue, Mar 03, 2026 at 03:03:48PM +0000, Shameer Kolothum wrote:
> > > If the IOMMU driver reports that ATS is not supported for a device, set
> > > the IOMMU_HW_CAP_PCI_ATS_NOT_SUPPORTED flag in the returned
> > hardware
> > > capabilities.
> > >
> > > When this flag is set, ATS is not supported and not used for the device.
> > >
> > > Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
> > > ---
> > >  include/uapi/linux/iommufd.h   | 3 +++
> > >  drivers/iommu/iommufd/device.c | 3 +++
> > >  2 files changed, 6 insertions(+)
> >
> > Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> >
> > > diff --git a/include/uapi/linux/iommufd.h
> b/include/uapi/linux/iommufd.h
> > > index 1dafbc552d37..d85a2d3e1b40 100644
> > > --- a/include/uapi/linux/iommufd.h
> > > +++ b/include/uapi/linux/iommufd.h
> > > @@ -695,11 +695,14 @@ enum iommu_hw_info_type {
> > >   * @IOMMU_HW_CAP_PCI_PASID_PRIV: Privileged Mode Supported,
> user
> > ignores it
> > >   *                               when the struct
> > >   *                               iommu_hw_info::out_max_pasid_log2 is zero.
> > > + * @IOMMU_HW_CAP_PCI_ATS_NOT_SUPPORTED: ATS is not supported
> > and not used on
> > > + *                                      this device.
> >
> > Same comment to clarify what this means. Does it mean ATS can be
> > turned on if the right HWPT is attached, or does it mean ATS is on
> > right now.
> 
> Since this one is negative : ATS is not supported and cannot be used.
> 

If ATS is not supported by hw, it certainly cannot be used.

If ATS is supported in hw but disallowed by firmware or kernel policy,
that's "cannot be used".

I'd replace 'and' with 'or' to cover both cases.

and you could add one clarification that when this flag is cleared
ATS will be turned on when the right HWPT is attached. Then the
behavior with this bit set or cleared is both deterministic to userspace.