When a device's default substream attaches to an identity domain, the SMMU
driver currently sets the device's STE between two modes:
Mode 1: Cfg=Translate, S1DSS=Bypass, EATS=1
Mode 2: Cfg=bypass (EATS is ignored by HW)
When there is an active PASID (non-default substream), mode 1 is used. And
when there is no PASID support or no active PASID, mode 2 is used.
The driver will also downgrade an STE from mode 1 to mode 2, when the last
active substream becomes inactive.
However, there are PCIe devices that demand ATS to be always on. For these
devices, their STEs have to use the mode 1 as HW ignores EATS with mode 2.
Change the driver accordingly:
- always use the mode 1
- never downgrade to mode 2
- allocate and retain a CD table (see note below)
Note that these devices might not support PASID, i.e. doing non-PASID ATS.
In such a case, the ssid_bits is set to 0. However, s1cdmax must be set to
a !0 value in order to keep the S1DSS field effective. Thus, when a master
requires ats_always_on, set its s1cdmax to minimal 1, meaning the CD table
will have a dummy entry (SSID=1) that will be never used.
Now, for these device, arm_smmu_cdtab_allocated() will always return true,
v.s. false prior to this change. When its default substream is attached to
an IDENTITY domain, its first CD is NULL in the table, which is a totally
valid case. Thus, add "!master->ats_always_on" to the condition.
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 +
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 73 ++++++++++++++++++---
2 files changed, 66 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index 3c6d65d36164f..f966d474b61fd 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -848,6 +848,7 @@ struct arm_smmu_master {
bool ats_enabled : 1;
bool ste_ats_enabled : 1;
bool stall_enabled;
+ bool ats_always_on;
unsigned int ssid_bits;
unsigned int iopf_refcount;
};
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 4d00d796f0783..69d40918bc22f 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1482,8 +1482,11 @@ void arm_smmu_clear_cd(struct arm_smmu_master *master, ioasid_t ssid)
if (!arm_smmu_cdtab_allocated(&master->cd_table))
return;
cdptr = arm_smmu_get_cd_ptr(master, ssid);
- if (WARN_ON(!cdptr))
+ if (!cdptr) {
+ /* Only ats_always_on allows a NULL CD on default substream */
+ WARN_ON(!master->ats_always_on || ssid);
return;
+ }
arm_smmu_write_cd_entry(master, ssid, cdptr, &target);
}
@@ -1496,6 +1499,22 @@ static int arm_smmu_alloc_cd_tables(struct arm_smmu_master *master)
struct arm_smmu_ctx_desc_cfg *cd_table = &master->cd_table;
cd_table->s1cdmax = master->ssid_bits;
+
+ /*
+ * When a device doesn't support PASID (non default SSID), ssid_bits is
+ * set to 0. This also sets S1CDMAX to 0, which disables the substreams
+ * and ignores the S1DSS field.
+ *
+ * On the other hand, if a device demands ATS to be always on even when
+ * its default substream is IOMMU bypassed, it has to use EATS that is
+ * only effective with an STE (CFG=S1translate, S1DSS=Bypass). For such
+ * use cases, S1CDMAX has to be !0, in order to make use of S1DSS/EATS.
+ *
+ * Set S1CDMAX no lower than 1. This would add a dummy substream in the
+ * CD table but it should never be used by an actual CD.
+ */
+ if (master->ats_always_on)
+ cd_table->s1cdmax = max_t(u8, cd_table->s1cdmax, 1);
max_contexts = 1 << cd_table->s1cdmax;
if (!(smmu->features & ARM_SMMU_FEAT_2_LVL_CDTAB) ||
@@ -3250,7 +3269,8 @@ static int arm_smmu_blocking_set_dev_pasid(struct iommu_domain *new_domain,
* When the last user of the CD table goes away downgrade the STE back
* to a non-cd_table one, by re-attaching its sid_domain.
*/
- if (!arm_smmu_ssids_in_use(&master->cd_table)) {
+ if (!master->ats_always_on &&
+ !arm_smmu_ssids_in_use(&master->cd_table)) {
struct iommu_domain *sid_domain =
iommu_driver_get_domain_for_dev(master->dev);
@@ -3274,7 +3294,10 @@ static void arm_smmu_attach_dev_ste(struct iommu_domain *domain,
.old_domain = old_domain,
.ssid = IOMMU_NO_PASID,
};
+ bool ats_always_on = false;
+ if (master->ats_always_on && s1dss != STRTAB_STE_1_S1DSS_TERMINATE)
+ ats_always_on = true;
/*
* Do not allow any ASID to be changed while are working on the STE,
* otherwise we could miss invalidations.
@@ -3285,7 +3308,7 @@ static void arm_smmu_attach_dev_ste(struct iommu_domain *domain,
* If the CD table is not in use we can use the provided STE, otherwise
* we use a cdtable STE with the provided S1DSS.
*/
- if (arm_smmu_ssids_in_use(&master->cd_table)) {
+ if (ats_always_on || arm_smmu_ssids_in_use(&master->cd_table)) {
/*
* If a CD table has to be present then we need to run with ATS
* on because we have to assume a PASID is using ATS. For
@@ -3581,6 +3604,40 @@ static void arm_smmu_remove_master(struct arm_smmu_master *master)
kfree(master->streams);
}
+static int arm_smmu_master_prepare_ats(struct arm_smmu_master *master)
+{
+ bool s1p = master->smmu->features & ARM_SMMU_FEAT_TRANS_S1;
+ unsigned int stu = __ffs(master->smmu->pgsize_bitmap);
+ struct pci_dev *pdev = to_pci_dev(master->dev);
+ int ret;
+
+ if (!arm_smmu_ats_supported(master))
+ return 0;
+
+ if (!pci_ats_always_on(pdev))
+ goto out_prepare;
+
+ /*
+ * S1DSS is required for ATS to be always on for identity domain cases.
+ * However, the S1DSS field is ignored if !IDR0_S1P or !IDR1_SSIDSIZE.
+ */
+ if (!s1p || !master->smmu->ssid_bits) {
+ dev_info_once(master->dev,
+ "SMMU doesn't support ATS to be always on\n");
+ goto out_prepare;
+ }
+
+ master->ats_always_on = true;
+
+ ret = arm_smmu_alloc_cd_tables(master);
+ if (ret)
+ return ret;
+
+out_prepare:
+ pci_prepare_ats(pdev, stu);
+ return 0;
+}
+
static struct iommu_device *arm_smmu_probe_device(struct device *dev)
{
int ret;
@@ -3629,14 +3686,14 @@ static struct iommu_device *arm_smmu_probe_device(struct device *dev)
smmu->features & ARM_SMMU_FEAT_STALL_FORCE)
master->stall_enabled = true;
- if (dev_is_pci(dev)) {
- unsigned int stu = __ffs(smmu->pgsize_bitmap);
-
- pci_prepare_ats(to_pci_dev(dev), stu);
- }
+ ret = arm_smmu_master_prepare_ats(master);
+ if (ret)
+ goto err_disable_pasid;
return &smmu->iommu;
+err_disable_pasid:
+ arm_smmu_disable_pasid(master);
err_free_master:
kfree(master);
return ERR_PTR(ret);
--
2.43.0On Mon, 23 Feb 2026 14:52:22 -0800 Nicolin Chen <nicolinc@nvidia.com> wrote: > When a device's default substream attaches to an identity domain, the SMMU > driver currently sets the device's STE between two modes: > > Mode 1: Cfg=Translate, S1DSS=Bypass, EATS=1 > Mode 2: Cfg=bypass (EATS is ignored by HW) > > When there is an active PASID (non-default substream), mode 1 is used. And > when there is no PASID support or no active PASID, mode 2 is used. > > The driver will also downgrade an STE from mode 1 to mode 2, when the last > active substream becomes inactive. > > However, there are PCIe devices that demand ATS to be always on. For these > devices, their STEs have to use the mode 1 as HW ignores EATS with mode 2. > > Change the driver accordingly: > - always use the mode 1 > - never downgrade to mode 2 > - allocate and retain a CD table (see note below) > > Note that these devices might not support PASID, i.e. doing non-PASID ATS. > In such a case, the ssid_bits is set to 0. However, s1cdmax must be set to > a !0 value in order to keep the S1DSS field effective. Thus, when a master > requires ats_always_on, set its s1cdmax to minimal 1, meaning the CD table > will have a dummy entry (SSID=1) that will be never used. > > Now, for these device, arm_smmu_cdtab_allocated() will always return true, > v.s. false prior to this change. When its default substream is attached to > an IDENTITY domain, its first CD is NULL in the table, which is a totally > valid case. Thus, add "!master->ats_always_on" to the condition. > > Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> In my head at least, it would be nice if a driver had to explicitly opt in to this behavior. The presence of CXL.cache support for instance doesn't actually mean the driver is going to enable it. However it is probably harmless so lets go with this as path of least resistance. One trivial thing inline (ignore if you like!) Otherwise LGTM Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> > 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 4d00d796f0783..69d40918bc22f 100644 > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > @@ -3274,7 +3294,10 @@ static void arm_smmu_attach_dev_ste(struct iommu_domain *domain, > .old_domain = old_domain, > .ssid = IOMMU_NO_PASID, > }; > + bool ats_always_on = false; > > + if (master->ats_always_on && s1dss != STRTAB_STE_1_S1DSS_TERMINATE) > + ats_always_on = true; Maybe flatten this to not do the off then on dance. bool ats_always_on = master->ats_always_on && s1dss != STRTAB_STE_1_S1DSS_TERMINATE;
On Tue, Feb 24, 2026 at 12:06:15PM +0000, Jonathan Cameron wrote: > In my head at least, it would be nice if a driver had to explicitly opt in > to this behavior. The presence of CXL.cache support for instance doesn't > actually mean the driver is going to enable it. However it is probably > harmless so lets go with this as path of least resistance. That same remark applies to ATS in general, we have no idea if the device is going to use it when turned on or not.. Generally Linux has taken the approach of almost always enabling ATS if the device offers the PCIe capability. The purpose of this series is to close of the few "almost" cases so it is always on. Jason
On Tue, 24 Feb 2026 10:51:02 -0400 Jason Gunthorpe <jgg@nvidia.com> wrote: > On Tue, Feb 24, 2026 at 12:06:15PM +0000, Jonathan Cameron wrote: > > > In my head at least, it would be nice if a driver had to explicitly opt in > > to this behavior. The presence of CXL.cache support for instance doesn't > > actually mean the driver is going to enable it. However it is probably > > harmless so lets go with this as path of least resistance. > > That same remark applies to ATS in general, we have no idea if the > device is going to use it when turned on or not.. Yup. Understood. That's the bit that smells bad to me. > > Generally Linux has taken the approach of almost always enabling ATS > if the device offers the PCIe capability. > > The purpose of this series is to close of the few "almost" cases so it > is always on. Absolutely understood. I just took the opportunity to moan! J > > Jason >
On Tue, Feb 24, 2026 at 03:57:42PM +0000, Jonathan Cameron wrote: > On Tue, 24 Feb 2026 10:51:02 -0400 > Jason Gunthorpe <jgg@nvidia.com> wrote: > > > On Tue, Feb 24, 2026 at 12:06:15PM +0000, Jonathan Cameron wrote: > > > > > In my head at least, it would be nice if a driver had to explicitly opt in > > > to this behavior. The presence of CXL.cache support for instance doesn't > > > actually mean the driver is going to enable it. However it is probably > > > harmless so lets go with this as path of least resistance. > > > > That same remark applies to ATS in general, we have no idea if the > > device is going to use it when turned on or not.. > > Yup. Understood. That's the bit that smells bad to me. Do you have thoughts on when this is a problem (aside from device pre-acceptance security already discussed)? So far I haven't heard complaining on this point.. Jason
On Tue, 24 Feb 2026 12:09:47 -0400 Jason Gunthorpe <jgg@nvidia.com> wrote: > On Tue, Feb 24, 2026 at 03:57:42PM +0000, Jonathan Cameron wrote: > > On Tue, 24 Feb 2026 10:51:02 -0400 > > Jason Gunthorpe <jgg@nvidia.com> wrote: > > > > > On Tue, Feb 24, 2026 at 12:06:15PM +0000, Jonathan Cameron wrote: > > > > > > > In my head at least, it would be nice if a driver had to explicitly opt in > > > > to this behavior. The presence of CXL.cache support for instance doesn't > > > > actually mean the driver is going to enable it. However it is probably > > > > harmless so lets go with this as path of least resistance. > > > > > > That same remark applies to ATS in general, we have no idea if the > > > device is going to use it when turned on or not.. > > > > Yup. Understood. That's the bit that smells bad to me. > > Do you have thoughts on when this is a problem (aside from device > pre-acceptance security already discussed)? So far I haven't heard > complaining on this point.. Nothing explicit. It was a very minor smells wrong moan on basis of assumptions of what an IOMMU is doing in the way of ATS checking if we have a malicious device. So principle of not turning anything on we don't know we need. Jonathan > > Jason >
© 2016 - 2026 Red Hat, Inc.