Allow ATS to be always on for certain ATS-capable devices
Subsystems (4)
cover Allow ATS to be always on for certain ATS-capable devices
PCI ATS function is controlled by IOMMU driver calling pci_enable_ats() and pci_disable_ats() helpers. In general, IOMMU driver only enables ATS, when a translation channel is enabled on a PASID, typically for an SVA use case. When a device's RID is IOMMU bypassed and there is no active PASID running SVA use case, ATS is always disabled.
However, certain pcie devices support non-PASID ATS on its RID, even if the RID is IOMMU bypassed. E.g. CXL.cache capability requires ATS to access the physical memory; some NVIDIA GPUs in non-CXL configuration also support ATS on a bypassed RID.
Provide a helper function to detect CXL.cache capability and scan through a device ID list.
As the initial use case, call the helper in ARM SMMUv3 driver and adapt the driver accordingly with a per-device ats_always_on flag.
This is on Github:
https://github.com/nicolinc/iommufd/commits/pci_ats_always_on-rfcv1/
Nicolin Chen (3):
PCI: Allow ATS to be always on for CXL.cache capable devices
PCI: Allow ATS to be always on for non-CXL NVIDIA GPUs iommu/arm-smmu-v3: Allow ATS to be always on
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 + drivers/pci/pci.h | 9 +++ include/linux/pci-ats.h | 3 + include/uapi/linux/pci_regs.h | 5 ++ drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 74 ++++++++++++++++++--- drivers/pci/ats.c | 45 +++++++++++++ drivers/pci/quirks.c | 23 +++++++ 7 files changed, 149 insertions(+), 11 deletions(-)
Signature · 1 line
2.43.0
RFC PATCH 1/3 PCI: Allow ATS to be always on for CXL.cache capable devices
Controlled by the IOMMU driver, ATS is usually enabled "on demand", when a device requests a translation service from its associated IOMMU HW running on the channel of a given PASID. This is working even when a device has no translation on its RID, i.e. RID is IOMMU bypassed.
On the other hand, certain PCIe device requires non-PASID ATS, when its RID stream is IOMMU bypassed. Call this "always on".
For instance, the CXL spec notes in "3.2.5.13 Memory Type on CXL.cache":
"To source requests on CXL.cache, devices need to get the Host Physical
Address (HPA) from the Host by means of an ATS request on CXL.io."
In other word, the CXL.cache capability relies on ATS. Otherwise, it won't have access to the host physical memory.
Introduce a new pci_ats_always_on() for IOMMU driver to scan a PCI device, to shift ATS policies between "on demand" and "always on".
Add the support for CXL.cache devices first. Non-CXL devices will be added in quirks.c file.
--- include/linux/pci-ats.h | 3 +++ include/uapi/linux/pci_regs.h | 5 ++++ drivers/pci/ats.c | 44 +++++++++++++++++++++++++++++++++++ 3 files changed, 52 insertions(+)
include/linux/pci-ats.h +3 -0
@@ -12,6 +12,7 @@ int pci_prepare_ats(struct pci_dev *dev, int ps);void pci_disable_ats (struct pci_dev *dev);int pci_ats_queue_depth (struct pci_dev *dev);int pci_ats_page_aligned (struct pci_dev *dev); +bool pci_ats_always_on (struct pci_dev *dev);#else /* CONFIG_PCI_ATS */ static inline bool pci_ats_supported (struct pci_dev *d) {return false; }
@@ -24,6 +25,8 @@ static inline int pci_ats_queue_depth(struct pci_dev *d) {return -ENODEV ; }static inline int pci_ats_page_aligned (struct pci_dev *dev) {return 0 ; } +static inline bool pci_ats_always_on (struct pci_dev *dev) +{return false; }#endif /* CONFIG_PCI_ATS */ #ifdef CONFIG_PCI_PRI
include/uapi/linux/pci_regs.h +5 -0
@@ -1258,6 +1258,11 @@#define PCI_DVSEC_CXL_PORT_CTL 0x0c#define PCI_DVSEC_CXL_PORT_CTL_UNMASK_SBR 0x00000001 +/* CXL 2.0 8.1.3: PCIe DVSEC for CXL Device */ +#define CXL_DVSEC_PCIE_DEVICE 0 +#define CXL_DVSEC_CAP_OFFSET 0xA +#define CXL_DVSEC_CACHE_CAPABLE BIT(0) +/* Integrity and Data Encryption Extended Capability */ #define PCI_IDE_CAP 0x04#define PCI_IDE_CAP_LINK 0x1/* Link IDE Stream Supported */
drivers/pci/ats.c +44 -0
50 lines not on this page · raw message
Signature · 1 line
2.43.0
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 4 lines · Nicolin Chen
Controlled by the IOMMU driver, ATS is usually enabled "on demand", when a device requests a translation service from its associated IOMMU HW running on the channel of a given PASID. This is working even when a device has no translation on its RID, i.e. RID is IOMMU bypassed.
I would add here that this is done to allow optimizing devices running in IDENTITY translation as there is no point to using ATS to return the same value as it already has.
Quoted 12 lines
For instance, the CXL spec notes in "3.2.5.13 Memory Type on CXL.cache":
"To source requests on CXL.cache, devices need to get the Host Physical
Address (HPA) from the Host by means of an ATS request on CXL.io."
In other word, the CXL.cache capability relies on ATS. Otherwise, it won't have access to the host physical memory.Introduce a new
pci_ats_always_on()for IOMMU driver to scan a PCI device, to shift ATS policies between "on demand" and "always on".Add the support for CXL.cache devices first. Non-CXL devices will be added in
quirks.cfile.
Quoted 8 lines
Suggested-by Vikram Sethi <[email protected]>Suggested-by Jason Gunthorpe <[email protected]>Signed-off-by Nicolin Chen <[email protected]>--- include/linux/pci-ats.h | 3 +++ include/uapi/linux/pci_regs.h | 5 ++++ drivers/pci/ats.c | 44 +++++++++++++++++++++++++++++++++++ 3 files changed, 52 insertions(+)
This implementation looks OK to me
Thanks,
Jason
RE: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
In reply to Nicolin Chen+Dan. I recalled an offline discussion in which he raised concern on having the kernel blindly enable ATS for cxl.cache device instead of creating a knob for admin to configure from userspace (in case security is viewed more important than functionality, upon allowing DMA to read data out of CPU caches)...
Quoted 133 lines
From: Nicolin Chen <[email protected]>
Sent: Saturday, January 17, 2026 12:57 PMControlled by the IOMMU driver, ATS is usually enabled "on demand", when a
device requests a translation service from its associated IOMMU HW running on the channel of a given PASID. This is working even when a device has no translation on its RID, i.e. RID is IOMMU bypassed.On the other hand, certain PCIe device requires non-PASID ATS, when its RID stream is IOMMU bypassed. Call this "always on".
For instance, the CXL spec notes in "3.2.5.13 Memory Type on CXL.cache":
"To source requests on CXL.cache, devices need to get the Host Physical
Address (HPA) from the Host by means of an ATS request on CXL.io."
In other word, the CXL.cache capability relies on ATS. Otherwise, it won't have access to the host physical memory.Introduce a new
pci_ats_always_on()for IOMMU driver to scan a PCI device, to shift ATS policies between "on demand" and "always on".Add the support for CXL.cache devices first. Non-CXL devices will be added in
quirks.cfile.Suggested-by Vikram Sethi <[email protected]>Suggested-by Jason Gunthorpe <[email protected]>Signed-off-by Nicolin Chen <[email protected]>--- include/linux/pci-ats.h | 3 +++ include/uapi/linux/pci_regs.h | 5 ++++ drivers/pci/ats.c | 44 +++++++++++++++++++++++++++++++++++ 3 files changed, 52 insertions(+)include/linux/pci-ats.h +3
-0@@ -12,6 +12,7 @@ int pci_prepare_ats(struct pci_dev *dev, int ps);void pci_disable_ats (struct pci_dev *dev);int pci_ats_queue_depth (struct pci_dev *dev);int pci_ats_page_aligned (struct pci_dev *dev); +bool pci_ats_always_on (struct pci_dev *dev);#else /* CONFIG_PCI_ATS */ static inline bool pci_ats_supported (struct pci_dev *d) {return false; }@@ -24,6 +25,8 @@ static inline int pci_ats_queue_depth(struct pci_dev *d) {return -ENODEV ; }static inline int pci_ats_page_aligned (struct pci_dev *dev) {return 0 ; } +static inline bool pci_ats_always_on (struct pci_dev *dev) +{return false; }#endif /* CONFIG_PCI_ATS */ #ifdef CONFIG_PCI_PRI include/uapi/linux/pci_regs.h +5
-0@@ -1258,6 +1258,11 @@#define PCI_DVSEC_CXL_PORT_CTL 0x0c#define PCI_DVSEC_CXL_PORT_CTL_UNMASK_SBR 0x00000001 +/* CXL 2.0 8.1.3: PCIe DVSEC for CXL Device */ +#define CXL_DVSEC_PCIE_DEVICE 0 +#define CXL_DVSEC_CAP_OFFSET 0xA +#define CXL_DVSEC_CACHE_CAPABLE BIT(0) +/* Integrity and Data Encryption Extended Capability */ #define PCI_IDE_CAP 0x04#define PCI_IDE_CAP_LINK 0x1/* Link IDE Stream Supported */ drivers/pci/ats.c +2
-0@@ -205,6 +205,50 @@ int pci_ats_page_aligned(struct pci_dev *pdev)return 0 ; } +/* +* CXL r4.0, sec 3.2.5.13 Memory Type on CXL.cache notes: to source requests on
+ * CXL.cache, devices need to get the Host Physical Address (HPA) from the Host
+ * by means of an ATS request on CXL.io.
+ *
+ * In other world, CXL.cache devices cannot access physical memory without ATS.
+ */drivers/pci/ats.c +11
-0+static bool pci_cxl_ats_always_on (struct pci_dev *pdev) +{ +int offset; +u16 cap; + + offset =pci_find_dvsec_capability (pdev,PCI_VENDOR_ID_CXL , +CXL_DVSEC_PCIE_DEVICE ); +if (!offset) +return false; + + pci_read_config_word(pdev, offset + CXL_DVSEC_CAP_OFFSET,&cap);
drivers/pci/ats.c +8
-0+if (cap &CXL_DVSEC_CACHE_CAPABLE ) +return true; + +return false; +} + +/** +* pci_ats_always_on - Whether the PCI device requires ATS to be always enabled
+ * @pdev: the PCI device
+ *
+ * Returns true, if the PCI device requires non-PASID ATS function on an IOMMU
+ * bypassed configuration.
+ */drivers/pci/ats.c +13
-1+bool pci_ats_always_on (struct pci_dev *pdev) +{ +if (pci_ats_disabled () || !pci_ats_supported (pdev)) +return false; + +/* A VF inherits its PF's requirement for ATS function */ +if (pdev->is_virtfn) + pdev =pci_physfn (pdev); + +return pci_cxl_ats_always_on (pdev); +} +EXPORT_SYMBOL_GPL (pci_ats_always_on); +#ifdef CONFIG_PCI_PRI void pci_pri_init (struct pci_dev *pdev) { --2.43.0
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 6 lines · Kevin
+Dan. I recalled an offline discussion in which he raised concern on having the kernel blindly enable ATS for cxl.cache device instead of creating a knob for admin to configure from userspace (in case security is viewed more important than functionality, upon allowing DMA to read data out of CPU caches)...
+CC Linux-cxl
Jonathan
Quoted 135 lines
Quoted 133 lines
From: Nicolin Chen <[email protected]>
Sent: Saturday, January 17, 2026 12:57 PMControlled by the IOMMU driver, ATS is usually enabled "on demand", when a
device requests a translation service from its associated IOMMU HW running on the channel of a given PASID. This is working even when a device has no translation on its RID, i.e. RID is IOMMU bypassed.On the other hand, certain PCIe device requires non-PASID ATS, when its RID stream is IOMMU bypassed. Call this "always on".
For instance, the CXL spec notes in "3.2.5.13 Memory Type on CXL.cache":
"To source requests on CXL.cache, devices need to get the Host Physical
Address (HPA) from the Host by means of an ATS request on CXL.io."
In other word, the CXL.cache capability relies on ATS. Otherwise, it won't have access to the host physical memory.Introduce a new
pci_ats_always_on()for IOMMU driver to scan a PCI device, to shift ATS policies between "on demand" and "always on".Add the support for CXL.cache devices first. Non-CXL devices will be added in
quirks.cfile.Suggested-by Vikram Sethi <[email protected]>Suggested-by Jason Gunthorpe <[email protected]>Signed-off-by Nicolin Chen <[email protected]>--- include/linux/pci-ats.h | 3 +++ include/uapi/linux/pci_regs.h | 5 ++++ drivers/pci/ats.c | 44 +++++++++++++++++++++++++++++++++++ 3 files changed, 52 insertions(+)include/linux/pci-ats.h +3
-0@@ -12,6 +12,7 @@ int pci_prepare_ats(struct pci_dev *dev, int ps);void pci_disable_ats (struct pci_dev *dev);int pci_ats_queue_depth (struct pci_dev *dev);int pci_ats_page_aligned (struct pci_dev *dev); +bool pci_ats_always_on (struct pci_dev *dev);#else /* CONFIG_PCI_ATS */ static inline bool pci_ats_supported (struct pci_dev *d) {return false; }@@ -24,6 +25,8 @@ static inline int pci_ats_queue_depth(struct pci_dev *d) {return -ENODEV ; }static inline int pci_ats_page_aligned (struct pci_dev *dev) {return 0 ; } +static inline bool pci_ats_always_on (struct pci_dev *dev) +{return false; }#endif /* CONFIG_PCI_ATS */ #ifdef CONFIG_PCI_PRI include/uapi/linux/pci_regs.h +5
-0@@ -1258,6 +1258,11 @@#define PCI_DVSEC_CXL_PORT_CTL 0x0c#define PCI_DVSEC_CXL_PORT_CTL_UNMASK_SBR 0x00000001 +/* CXL 2.0 8.1.3: PCIe DVSEC for CXL Device */ +#define CXL_DVSEC_PCIE_DEVICE 0 +#define CXL_DVSEC_CAP_OFFSET 0xA +#define CXL_DVSEC_CACHE_CAPABLE BIT(0) +/* Integrity and Data Encryption Extended Capability */ #define PCI_IDE_CAP 0x04#define PCI_IDE_CAP_LINK 0x1/* Link IDE Stream Supported */ drivers/pci/ats.c +2
-0@@ -205,6 +205,50 @@ int pci_ats_page_aligned(struct pci_dev *pdev)return 0 ; } +/* +* CXL r4.0, sec 3.2.5.13 Memory Type on CXL.cache notes: to source requests on
+ * CXL.cache, devices need to get the Host Physical Address (HPA) from the Host
+ * by means of an ATS request on CXL.io.
+ *
+ * In other world, CXL.cache devices cannot access physical memory without ATS.
+ */drivers/pci/ats.c +11
-0+static bool pci_cxl_ats_always_on (struct pci_dev *pdev) +{ +int offset; +u16 cap; + + offset =pci_find_dvsec_capability (pdev,PCI_VENDOR_ID_CXL , +CXL_DVSEC_PCIE_DEVICE ); +if (!offset) +return false; + + pci_read_config_word(pdev, offset + CXL_DVSEC_CAP_OFFSET,&cap);
drivers/pci/ats.c +8
-0+if (cap &CXL_DVSEC_CACHE_CAPABLE ) +return true; + +return false; +} + +/** +* pci_ats_always_on - Whether the PCI device requires ATS to be always enabled
+ * @pdev: the PCI device
+ *
+ * Returns true, if the PCI device requires non-PASID ATS function on an IOMMU
+ * bypassed configuration.
+ */drivers/pci/ats.c +13
-1+bool pci_ats_always_on (struct pci_dev *pdev) +{ +if (pci_ats_disabled () || !pci_ats_supported (pdev)) +return false; + +/* A VF inherits its PF's requirement for ATS function */ +if (pdev->is_virtfn) + pdev =pci_physfn (pdev); + +return pci_cxl_ats_always_on (pdev); +} +EXPORT_SYMBOL_GPL (pci_ats_always_on); +#ifdef CONFIG_PCI_PRI void pci_pri_init (struct pci_dev *pdev) { --2.43.0
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 11 lines · Jonathan Cameron
Quoted 6 lines · Kevin
+Dan. I recalled an offline discussion in which he raised concern on having the kernel blindly enable ATS for cxl.cache device instead of creating a knob for admin to configure from userspace (in case security is viewed more important than functionality, upon allowing DMA to read data out of CPU caches)...
+CC Linux-cxl
A cxl.cache device supporting ATS will automatically enable ATS today if the kernel option to enable translation is set.
Even if the device is marked untrusted by the PCI layer (eg an external port).
Yes this is effectively a security issue, but it is not really a CXL specific problem.
We might perfer to not enable ATS for untrusted devices and then fail to load drivers for "ats always on" cases.
Or maybe we can enable one of the ATS security features someday, though I wonder if those work for CXL..
Jason
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 10 lines · Jason Gunthorpe
Quoted 9 lines · Jonathan Cameron
Quoted 6 lines · Kevin
+Dan. I recalled an offline discussion in which he raised concern on having the kernel blindly enable ATS for cxl.cache device instead of creating a knob for admin to configure from userspace (in case security is viewed more important than functionality, upon allowing DMA to read data out of CPU caches)...
Quoted 6 lines
Quoted 1 line
+CC Linux-cxl
A cxl.cache device supporting ATS will automatically enable ATS today if the kernel option to enable translation is set.
Even if the device is marked untrusted by the PCI layer (eg an external port).
I don't follow here. The untrusted check is now in pci_ats_supported():
/**
* pci_ats_supported - check if the device can use ATS
* @dev: the PCI device
*
* Returns true if the device supports ATS and is allowed to use it, false
* otherwise.
*/
bool pci_ats_supported(struct pci_dev *dev)
{
if (!dev->ats_cap)
return false;
return (dev->untrusted == 0);
}EXPORT_SYMBOL_GPL(pci_ats_supported);
The iommu drivers (intel/amd/arm-smmuv3) all call pci_ats_supported() before enabling ATS on a device. Anything I missed?
Quoted 9 lines
Yes this is effectively a security issue, but it is not really a CXL specific problem.
We might perfer to not enable ATS for untrusted devices and then fail to load drivers for "ats always on" cases.
Or maybe we can enable one of the ATS security features someday, though I wonder if those work for CXL..
Thanks,
baolu
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 34 lines · Baolu Lu
Quoted 10 lines · Jason Gunthorpe
Quoted 9 lines · Jonathan Cameron
Quoted 6 lines · Kevin
+Dan. I recalled an offline discussion in which he raised concern on having the kernel blindly enable ATS for cxl.cache device instead of creating a knob for admin to configure from userspace (in case security is viewed more important than functionality, upon allowing DMA to read data out of CPU caches)...
Quoted 6 lines
Quoted 1 line
+CC Linux-cxl
A cxl.cache device supporting ATS will automatically enable ATS today if the kernel option to enable translation is set.
Even if the device is marked untrusted by the PCI layer (eg an external port).
I don't follow here. The untrusted check is now in
pci_ats_supported():/**
*pci_ats_supported- check if the device can use ATS
* @dev: the PCI device
*
* Returns true if the device supports ATS and is allowed to use it, false
* otherwise.
*/
boolpci_ats_supported(struct pci_dev *dev){ if (!dev->ats_cap) return false; return (dev->untrusted == 0); }
Quoted 4 lines
EXPORT_SYMBOL_GPL(pci_ats_supported);The iommu drivers (intel/amd/arm-smmuv3) all call
pci_ats_supported()before enabling ATS on a device. Anything I missed?
No, not at all, I forgot about this!
Jason
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
In reply to Jason GunthorpeQuoted 13 lines · Jason Gunthorpe
Quoted 11 lines · Jonathan Cameron
Quoted 6 lines · Kevin
+Dan. I recalled an offline discussion in which he raised concern on having the kernel blindly enable ATS for cxl.cache device instead of creating a knob for admin to configure from userspace (in case security is viewed more important than functionality, upon allowing DMA to read data out of CPU caches)...
+CC Linux-cxl
Quoted 8 lines
A cxl.cache device supporting ATS will automatically enable ATS today if the kernel option to enable translation is set.
Even if the device is marked untrusted by the PCI layer (eg an external port).
Yes this is effectively a security issue, but it is not really a CXL specific problem.
My contention is that it is a worse or at least different problem in the CXL case because now you have a new toolkit in an attack that wants to exfiltrate data from CPU caches.
Quoted 2 lines
We might perfer to not enable ATS for untrusted devices and then fail to load drivers for "ats always on" cases.
The current PCI untrusted flag is not fit for purpose in this new age of PCI device authentication and CXL.cache capable devices.
Quoted 2 lines
Or maybe we can enable one of the ATS security features someday, though I wonder if those work for CXL..
It should work, but before that I do not see the justification to say effectively:
"We have a less than perfect legacy way (PCI untrusted flag) to nod at
ATS security problems. Let us ignore even that for a new class of devices that advertise they can trigger all the old security problems plus new ones."
I do not immediately see what is wrong with requiring userspace policy opt-in. That naturally gets replaced by installing the device's certificate (for native PCI CMA), authenticating the device with the TSM (for PCI IDE), or obviated by secure-ATS if that arrives.
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 20 lines · On Wed, Jan 21, 2026 at 09:44:32PM -0800, [email protected] wrote:
Quoted 19 lines · Jason Gunthorpe
Quoted 11 lines · Jonathan Cameron
Quoted 6 lines · Kevin
+Dan. I recalled an offline discussion in which he raised concern on having the kernel blindly enable ATS for cxl.cache device instead of creating a knob for admin to configure from userspace (in case security is viewed more important than functionality, upon allowing DMA to read data out of CPU caches)...
+CC Linux-cxl
A cxl.cache device supporting ATS will automatically enable ATS today if the kernel option to enable translation is set.
Even if the device is marked untrusted by the PCI layer (eg an external port).
Quoted 6 lines
Quoted 2 lines
Yes this is effectively a security issue, but it is not really a CXL specific problem.
My contention is that it is a worse or at least different problem in the CXL case because now you have a new toolkit in an attack that wants to exfiltrate data from CPU caches.
?? I don't see CXL as meaningfully different than PCI in terms of what data can be accessed with Translated requests. If the IOMMU doesn't block Translated requests the whole systems is open. CXL doesn't make it more open.
Quoted 4 lines
"We have a less than perfect legacy way (PCI untrusted flag) to nod at
ATS security problems. Let us ignore even that for a new class of devices that advertise they can trigger all the old security problems plus new ones."
Ah, I missed that we are already force disabling ATS in this untrusted case, so we should ensure that continues to be the case here too. Nicolin does it need a change?
Quoted 4 lines
I do not immediately see what is wrong with requiring userspace policy opt-in. That naturally gets replaced by installing the device's certificate (for native PCI CMA), authenticating the device with the TSM (for PCI IDE), or obviated by secure-ATS if that arrives.
I think that goes back to the discussion about not loading drivers before validating the device.
It would also make alot of sense to leave the IOMMU blocking until the driver is loaded for these secure situations. The blocking translation should block ATS too.
Then the flow you are describing will work well:
1) At pre-boot the IOMMU will block all DMA including Translated.
2) The OS activates the IOMMU driver and keeps blocking.
3) Instead of immediately binding a default domain the IOMMU core leaves the translation blocking.
4) The OS defers loading the driver to userspace.
5) Userspace measures the device and "accepts" it by loading the driver
6) IOMMU core attaches a non-blocking default domain and activates ATS
Jason
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 9 lines · Jason Gunthorpe
Quoted 4 lines · On Wed, Jan 21, 2026 at 09:44:32PM -0800, [email protected] wrote:
"We have a less than perfect legacy way (PCI untrusted flag) to nod at
ATS security problems. Let us ignore even that for a new class of devices that advertise they can trigger all the old security problems plus new ones."Ah, I missed that we are already force disabling ATS in this untrusted case, so we should ensure that continues to be the case here too. Nicolin does it need a change?
pci_ats_always_on() validates against !pci_ats_supported(pdev), so we ensured that untrusted devices would not be always on.
Perhaps we should highlight in the commit message, as it's a topic?
Nicolin
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 7 lines · Nicolin Chen
Quoted 6 lines · Jason Gunthorpe
Quoted 4 lines · On Wed, Jan 21, 2026 at 09:44:32PM -0800, [email protected] wrote:
"We have a less than perfect legacy way (PCI untrusted flag) to nod at
ATS security problems. Let us ignore even that for a new class of devices that advertise they can trigger all the old security problems plus new ones."
Quoted 8 lines
Quoted 3 lines
Ah, I missed that we are already force disabling ATS in this untrusted case, so we should ensure that continues to be the case here too. Nicolin does it need a change?
pci_ats_always_on()validates against !pci_ats_supported(pdev), so we ensured that untrusted devices would not be always on.Perhaps we should highlight in the commit message, as it's a topic?
Yes
Jason
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
In reply to Jason GunthorpeQuoted 24 lines · Jason Gunthorpe
Quoted 23 lines · On Wed, Jan 21, 2026 at 09:44:32PM -0800, [email protected] wrote:
Quoted 21 lines · Jason Gunthorpe
Quoted 11 lines · Jonathan Cameron
Quoted 6 lines · Kevin
+Dan. I recalled an offline discussion in which he raised concern on having the kernel blindly enable ATS for cxl.cache device instead of creating a knob for admin to configure from userspace (in case security is viewed more important than functionality, upon allowing DMA to read data out of CPU caches)...
+CC Linux-cxl
A cxl.cache device supporting ATS will automatically enable ATS today if the kernel option to enable translation is set.
Even if the device is marked untrusted by the PCI layer (eg an external port).
Yes this is effectively a security issue, but it is not really a CXL specific problem.
Quoted 8 lines
Quoted 3 lines
My contention is that it is a worse or at least different problem in the CXL case because now you have a new toolkit in an attack that wants to exfiltrate data from CPU caches.
?? I don't see CXL as meaningfully different than PCI in terms of what data can be accessed with Translated requests. If the IOMMU doesn't block Translated requests the whole systems is open. CXL doesn't make it more open.
Right, the game is mostly over in the current case, but CXL.cache still deserves to be treated carefully. Consider a world where we do have limitations against requests to HPAs that were never translated for the device. In that scenario the device can help side channel the contents of HPAs it does not otherwise have access by messing with aliased lines it does have access.
At a minimum CXL.cache is not improving the security story, so no time like the present to put a policy mechanism in place that improves upon the PCI untrusted flag.
Quoted 23 lines
Quoted 4 lines
"We have a less than perfect legacy way (PCI untrusted flag) to nod at
ATS security problems. Let us ignore even that for a new class of devices that advertise they can trigger all the old security problems plus new ones."Ah, I missed that we are already force disabling ATS in this untrusted case, so we should ensure that continues to be the case here too. Nicolin does it need a change?
Quoted 4 lines
I do not immediately see what is wrong with requiring userspace policy opt-in. That naturally gets replaced by installing the device's certificate (for native PCI CMA), authenticating the device with the TSM (for PCI IDE), or obviated by secure-ATS if that arrives.
I think that goes back to the discussion about not loading drivers before validating the device.
It would also make alot of sense to leave the IOMMU blocking until the driver is loaded for these secure situations. The blocking translation should block ATS too.
Then the flow you are describing will work well:
Quoted 8 lines
1) At pre-boot the IOMMU will block all DMA including Translated.
2) The OS activates the IOMMU driver and keeps blocking.
3) Instead of immediately binding a default domain the IOMMU core leaves the translation blocking.
4) The OS defers loading the driver to userspace.
5) Userspace measures the device and "accepts" it by loading the driver
6) IOMMU core attaches a non-blocking default domain and activates ATS
That works for me. Give the paranoid the ability to have a point where they can be assured that the shields were not lowered prematurely.
RE: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 29 lines
From: Williams, Dan J <[email protected]>
Sent: Friday, January 23, 2026 3:46 AMQuoted 1 line · Jason Gunthorpe
On Wed, Jan 21, 2026 at 09:44:32PM -0800, [email protected]
Quoted 14 lines · wrote:
Quoted 4 lines
I do not immediately see what is wrong with requiring userspace policy opt-in. That naturally gets replaced by installing the device's certificate (for native PCI CMA), authenticating the device with the TSM (for PCI IDE), or obviated by secure-ATS if that arrives.
I think that goes back to the discussion about not loading drivers before validating the device.
It would also make alot of sense to leave the IOMMU blocking until the driver is loaded for these secure situations. The blocking translation should block ATS too.
Then the flow you are describing will work well:
Quoted 8 lines
1) At pre-boot the IOMMU will block all DMA including Translated.
2) The OS activates the IOMMU driver and keeps blocking.
3) Instead of immediately binding a default domain the IOMMU core leaves the translation blocking.
4) The OS defers loading the driver to userspace.
5) Userspace measures the device and "accepts" it by loading the driver
6) IOMMU core attaches a non-blocking default domain and activates ATS
Quoted 3 lines
That works for me. Give the paranoid the ability to have a point where they can
be assured that the shields were not lowered prematurely.
Jason described the flow as "for these secure situations", i.e. not a general requirement for cxl.cache, but iiuc Dan may instead want userspace policy opt-in to be default (and with CMA/TSM etc. it gets easier)?
Better to clarity the agreement here as the output decides whether to continue what this series tries to do...
At a glance cxl.cache devices have gained ATS enabled automatically in most cases (same as for all other ats-capable PCI devices):
- ARM: ATS is enabled automatically when attaching the default domain to the device in certain configurations, and this series tries to auto enable it in a missing configuration
- AMD: ATS is enabled at domain attach time
- Intel: ATS is enabled when a device is probed by intel-iommu driver (incompatible with the suggested flow)
Given above already shipped in distributions, probably we have to keep them for compatibility (implying this series makes sense to fix a gap in existing policy), then treat the suggested flow as an enhancement for future?
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 29 lines · Kevin
Quoted 29 lines
From: Williams, Dan J <[email protected]>
Sent: Friday, January 23, 2026 3:46 AMQuoted 1 line · Jason Gunthorpe
On Wed, Jan 21, 2026 at 09:44:32PM -0800, [email protected]
Quoted 22 lines · wrote:
Quoted 4 lines
I do not immediately see what is wrong with requiring userspace policy opt-in. That naturally gets replaced by installing the device's certificate (for native PCI CMA), authenticating the device with the TSM (for PCI IDE), or obviated by secure-ATS if that arrives.
I think that goes back to the discussion about not loading drivers before validating the device.
It would also make alot of sense to leave the IOMMU blocking until the driver is loaded for these secure situations. The blocking translation should block ATS too.
Then the flow you are describing will work well:
1) At pre-boot the IOMMU will block all DMA including Translated.
2) The OS activates the IOMMU driver and keeps blocking.
3) Instead of immediately binding a default domain the IOMMU core leaves the translation blocking.
4) The OS defers loading the driver to userspace.
5) Userspace measures the device and "accepts" it by loading the driver
6) IOMMU core attaches a non-blocking default domain and activates ATS
Quoted 7 lines
Quoted 3 lines
That works for me. Give the paranoid the ability to have a point where they can
be assured that the shields were not lowered prematurely.Jason described the flow as "for these secure situations", i.e. not a general requirement for cxl.cache, but iiuc Dan may instead want userspace policy opt-in to be default (and with CMA/TSM etc. it gets easier)?
I think the general strategy has been to push userspace to do security decisions before binding drivers. So we have a plan for confidential compute VMs, and if there is interest then we can probably re-use that plan in all other cases.
Quoted 2 lines
At a glance cxl.cache devices have gained ATS enabled automatically in most cases (same as for all other ats-capable PCI devices):
Yes.
Quoted 3 lines
- ARM: ATS is enabled automatically when attaching the default domain to the device in certain configurations, and this series tries to auto enable it in a missing configuration
Yes, ARM took the position that ATS should be left disabled for IDENTITY both because of SMMU constraints and also because it made some sense that you wouldn't want ATS overhead just to get a 1:1 translation.
Quoted 1 line
- AMD: ATS is enabled at domain attach time
I'd argue this is an error and it should work like ARM
Quoted 2 lines
- Intel: ATS is enabled when a device is probed by intel-iommu driver (incompatible with the suggested flow)
This is definately not a good choice :)
IMHO it is security required that the IOMMU driver block Translated requests while a BLOCKED domain is attached, and while the IOMMU is refusing ATS then device's ATS enable should be disabled.
Quoted 4 lines
Given above already shipped in distributions, probably we have to keep them for compatibility (implying this series makes sense to fix a gap in existing policy), then treat the suggested flow as an enhancement for future?
I don't think we have a compatability issue here, just a security one.
Drivers need to ensure that ATS is disabled at PCI and Translated requestes blocked in IOMMU HW while a BLOCKED domain is attached.
Drivers can choose if they want to enable ATS for IDENTITY or not, (recommend not for performance and consistency).
Jason
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Jason Gunthorpe wrote:
[..]
Quoted 8 lines
Quoted 3 lines
Jason described the flow as "for these secure situations", i.e. not a general requirement for cxl.cache, but iiuc Dan may instead want userspace policy opt-in to be default (and with CMA/TSM etc. it gets easier)?
I think the general strategy has been to push userspace to do security decisions before binding drivers. So we have a plan for confidential compute VMs, and if there is interest then we can probably re-use that plan in all other cases.
Right, if you want to configure a kernel to automatically enable ATS that is choice. But, as distros get more security concious about devices for confidential compute, it would be nice to be able to rely on the same opt-in model for other security concerns like ATS security.
Quoted 5 lines
Quoted 2 lines
At a glance cxl.cache devices have gained ATS enabled automatically in most cases (same as for all other ats-capable PCI devices):
Yes.
Quoted 8 lines
Quoted 3 lines
- ARM: ATS is enabled automatically when attaching the default domain to the device in certain configurations, and this series tries to auto enable it in a missing configuration
Yes, ARM took the position that ATS should be left disabled for IDENTITY both because of SMMU constraints and also because it made some sense that you wouldn't want ATS overhead just to get a 1:1 translation.
Does this mean that ARM already today does not enable ATS until driver attach, or is incremental work needed for that capability?
Quoted 18 lines
Quoted 1 line
- AMD: ATS is enabled at domain attach time
I'd argue this is an error and it should work like ARM
Quoted 2 lines
- Intel: ATS is enabled when a device is probed by intel-iommu driver (incompatible with the suggested flow)
This is definately not a good choice :)
IMHO it is security required that the IOMMU driver block Translated requests while a BLOCKED domain is attached, and while the IOMMU is refusing ATS then device's ATS enable should be disabled.
Quoted 4 lines
Given above already shipped in distributions, probably we have to keep them for compatibility (implying this series makes sense to fix a gap in existing policy), then treat the suggested flow as an enhancement for future?
Quoted 5 lines
I don't think we have a compatability issue here, just a security one.
Drivers need to ensure that ATS is disabled at PCI and Translated requestes blocked in IOMMU HW while a BLOCKED domain is attached.
"Drivers" here meaning IOMMU drivers, right?
Quoted 4 lines
Drivers can choose if they want to enable ATS for IDENTITY or not, (recommend not for performance and consistency).
Jason
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 7 lines · On Tue, Jan 27, 2026 at 04:49:07PM -0800, [email protected] wrote:
Quoted 4 lines
Yes, ARM took the position that ATS should be left disabled for IDENTITY both because of SMMU constraints and also because it made some sense that you wouldn't want ATS overhead just to get a 1:1 translation.
Does this mean that ARM already today does not enable ATS until driver attach, or is incremental work needed for that capability?
All of the iommu drivers setup an iommu translation and enable ATS before any driver is bound.
We would need to do more work in the core to leave the translation blocked when there is no driver. I don't think it is that difficult
Quoted 4 lines
Quoted 2 lines
Drivers need to ensure that ATS is disabled at PCI and Translated requestes blocked in IOMMU HW while a BLOCKED domain is attached.
"Drivers" here meaning IOMMU drivers, right?
Yes
Jason
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 6 lines · Jason Gunthorpe
Quoted 5 lines · On Tue, Jan 27, 2026 at 04:49:07PM -0800, [email protected] wrote:
Quoted 4 lines
Yes, ARM took the position that ATS should be left disabled for IDENTITY both because of SMMU constraints and also because it made some sense that you wouldn't want ATS overhead just to get a 1:1 translation.
Quoted 8 lines
Quoted 2 lines
Does this mean that ARM already today does not enable ATS until driver attach, or is incremental work needed for that capability?
All of the iommu drivers setup an iommu translation and enable ATS before any driver is bound.
We would need to do more work in the core to leave the translation blocked when there is no driver. I don't think it is that difficult
Hmm, not sure if we could use group->domain=NULL as "blocked..
Otherwise, I made a draft:
-----------------------------------------------------------------
drivers/base/dd.c +7 -6
@@ -437,8 +437,6 @@ static int driver_sysfs_add(struct device *dev) {int ret; -bus_notify (dev,BUS_NOTIFY_BIND_DRIVER ); - ret =sysfs_create_link (&dev->driver->p->kobj, &dev->kobj,kobject_name (&dev->kobj));if (ret)
@@ -638,10 +636,12 @@ static int really_probe(struct device *dev, const struct device_driver *drv)if (ret) goto pinctrl_bind_failed; +bus_notify (dev,BUS_NOTIFY_BIND_DRIVER ); +if (dev->bus->dma_configure) { ret = dev->bus->dma_configure (dev);if (ret) - goto pinctrl_bind_failed; + goto bus_notify_bind_failed; } ret =driver_sysfs_add (dev);
@@ -717,9 +717,10 @@ static int really_probe(struct device *dev, const struct device_driver *drv) probe_failed:driver_sysfs_remove (dev); sysfs_failed: -bus_notify (dev,BUS_NOTIFY_DRIVER_NOT_BOUND );if (dev->bus && dev->bus->dma_cleanup) dev->bus->dma_cleanup (dev); +bus_notify_bind_failed: +bus_notify (dev,BUS_NOTIFY_DRIVER_NOT_BOUND ); pinctrl_bind_failed:device_links_no_driver (dev);device_unbind_cleanup (dev);
@@ -1275,8 +1276,6 @@ static void __device_release_driver(struct device *dev, struct device *parent)driver_sysfs_remove (dev); -bus_notify (dev,BUS_NOTIFY_UNBIND_DRIVER ); -pm_runtime_put_sync (dev);device_remove (dev);
@@ -1284,6 +1283,8 @@ static void __device_release_driver(struct device *dev, struct device *parent)if (dev->bus && dev->bus->dma_cleanup) dev->bus->dma_cleanup (dev); +bus_notify (dev,BUS_NOTIFY_UNBIND_DRIVER ); +device_unbind_cleanup (dev);device_links_driver_cleanup (dev);
drivers/iommu/iommu.c +63 -8
106 lines not on this page · raw message
-----------------------------------------------------------------
Thanks
Nicolin
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 10 lines · Nicolin Chen
Quoted 9 lines · Jason Gunthorpe
Quoted 7 lines · On Tue, Jan 27, 2026 at 04:49:07PM -0800, [email protected] wrote:
Quoted 4 lines
Yes, ARM took the position that ATS should be left disabled for IDENTITY both because of SMMU constraints and also because it made some sense that you wouldn't want ATS overhead just to get a 1:1 translation.
Does this mean that ARM already today does not enable ATS until driver attach, or is incremental work needed for that capability?
Quoted 7 lines
Quoted 5 lines
All of the iommu drivers setup an iommu translation and enable ATS before any driver is bound.
We would need to do more work in the core to leave the translation blocked when there is no driver. I don't think it is that difficult
Hmm, not sure if we could use group->domain=NULL as "blocked..
Definately not, we need to use a proper blocked domain.
Quoted 11 lines
drivers/base/dd.c +0
-2@@ -437,8 +437,6 @@ static int driver_sysfs_add(struct device *dev) {int ret; -bus_notify (dev,BUS_NOTIFY_BIND_DRIVER ); - ret =sysfs_create_link (&dev->driver->p->kobj, &dev->kobj,kobject_name (&dev->kobj));if (ret)@@ -638,10 +636,12 @@ static int really_probe(struct device *dev, const struct device_driver *drv)if (ret)
drivers/base/dd.c static int really_probe(struct device *dev, const struct device_driver *drv) · line 645
Quoted 10 lines
drivers/base/dd.c +3
-1goto pinctrl_bind_failed; +bus_notify (dev,BUS_NOTIFY_BIND_DRIVER ); +if (dev->bus->dma_configure) { ret = dev->bus->dma_configure (dev);if (ret) - goto pinctrl_bind_failed; + goto bus_notify_bind_failed; }
We shouldn't need any of these? The dma_configure callback already gets into the iommu code to validate the domain and restrict VFIO, no further callbacks should be needed.
When the iommu driver is probed to the device we can assume no driver is bound and immediately attach the blocked domain.
Jason
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 14 lines · Jason Gunthorpe
Quoted 13 lines · Nicolin Chen
Quoted 12 lines · Jason Gunthorpe
Quoted 7 lines · On Tue, Jan 27, 2026 at 04:49:07PM -0800, [email protected] wrote:
Quoted 4 lines
Yes, ARM took the position that ATS should be left disabled for IDENTITY both because of SMMU constraints and also because it made some sense that you wouldn't want ATS overhead just to get a 1:1 translation.
Does this mean that ARM already today does not enable ATS until driver attach, or is incremental work needed for that capability?
All of the iommu drivers setup an iommu translation and enable ATS before any driver is bound.
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
We would need to do more work in the core to leave the translation blocked when there is no driver. I don't think it is that difficult
Hmm, not sure if we could use group->domain=NULL as "blocked..
Definately not, we need to use a proper blocked domain.
Yea, I suspected so.
Quoted 26 lines
Quoted 11 lines
drivers/base/dd.c +0
-2@@ -437,8 +437,6 @@ static int driver_sysfs_add(struct device *dev) {int ret; -bus_notify (dev,BUS_NOTIFY_BIND_DRIVER ); - ret =sysfs_create_link (&dev->driver->p->kobj, &dev->kobj,kobject_name (&dev->kobj));if (ret)@@ -638,10 +636,12 @@ static int really_probe(struct device *dev, const struct device_driver *drv)if (ret)drivers/base/dd.c static int really_probe(struct device *dev, const struct device_driver *drv) · line 645
Quoted 10 lines
drivers/base/dd.c +3
-1goto pinctrl_bind_failed; +bus_notify (dev,BUS_NOTIFY_BIND_DRIVER ); +if (dev->bus->dma_configure) { ret = dev->bus->dma_configure (dev);if (ret) - goto pinctrl_bind_failed; + goto bus_notify_bind_failed; }We shouldn't need any of these? The
dma_configurecallback already gets into the iommu code to validate the domain and restrict VFIO, no further callbacks should be needed.
Quoted 2 lines
When the iommu driver is probed to the device we can assume no driver is bound and immediately attach the blocked domain.
I was trying to use dev->driver that gets set before dma_configure() and unset after dma_cleanup(). But looks like we could just keep the track of group->owner_cnt in iommu_device_use/unuse_default_domain().
Btw, attaching to IOMMU_DOMAIN_BLOCKED/group->blocking_domain is not allowed in general if require_direct=true. I assume this case can be an exception since there's no point in allowing a device that has no driver yet to access any reserved region?
Thanks
Nicolin
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 4 lines · Nicolin Chen
Btw, attaching to IOMMU_DOMAIN_BLOCKED/group->blocking_domain is not allowed in general if require_direct=true. I assume this case can be an exception since there's no point in allowing a device that has no driver yet to access any reserved region?
If require_direct is set then we have to disable this mechanism..
I'm not sure exactly what to do about this as the require_direct comes from the hypervisor in a CC VM and we probably don't want to give the hypervisor this kind of escape hatch.
Perhaps we need to lock off to failure on CC VMs if this ever happens..
But baremetal should just keep working how it always worked in this case..
Jason
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 12 lines · Jason Gunthorpe
Quoted 4 lines · Nicolin Chen
Btw, attaching to IOMMU_DOMAIN_BLOCKED/group->blocking_domain is not allowed in general if require_direct=true. I assume this case can be an exception since there's no point in allowing a device that has no driver yet to access any reserved region?
If
require_directis set then we have to disable this mechanism..I'm not sure exactly what to do about this as the
require_directcomes from the hypervisor in a CC VM and we probably don't want to give the hypervisor this kind of escape hatch.
Quoted 5 lines
Perhaps we need to lock off to failure on CC VMs if this ever happens..
But baremetal should just keep working how it always worked in this case..
OK. I will put a note in the patch, since it would literally skip any VM case at this moment.
I just realized a corner case, as iommu_probe_device() may attach the device to group->domain if it's set:
https://lore.kernel.org/all/[email protected]/
I am not sure about the use case, but I assume we should skip the blocking_domain as well in this case?
Then, this makes the condition be:
+ if (!dev->driver && !group->domain && !dev->iommu->require_direct) {
+ ret = __iommu_group_alloc_blocking_domain(group);
+ if (ret)
+ goto err_remove_gdev;
+ group->domain = group->blocking_domain;
+ }
Thanks
Nicolin
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 30 lines · Nicolin Chen
Quoted 12 lines · Jason Gunthorpe
Quoted 4 lines · Nicolin Chen
Btw, attaching to IOMMU_DOMAIN_BLOCKED/group->blocking_domain is not allowed in general if require_direct=true. I assume this case can be an exception since there's no point in allowing a device that has no driver yet to access any reserved region?
If
require_directis set then we have to disable this mechanism..I'm not sure exactly what to do about this as the
require_directcomes from the hypervisor in a CC VM and we probably don't want to give the hypervisor this kind of escape hatch.Quoted 5 lines
Perhaps we need to lock off to failure on CC VMs if this ever happens..
But baremetal should just keep working how it always worked in this case..
OK. I will put a note in the patch, since it would literally skip any VM case at this moment.
I just realized a corner case, as
iommu_probe_device()may attach the device togroup->domainif it's set:
https://lore.kernel.org/all/[email protected]/I am not sure about the use case, but I assume we should skip the
blocking_domainas well in this case?Then, this makes the condition be:
drivers/iommu/iommu.c static int __iommu_probe_device(struct device *dev, struct list_head *group_list · line 646
Quoted 6 lines
drivers/iommu/iommu.c +6
-0+if (!dev->driver && !group->domain && !dev->iommu->require_direct) { + ret =__iommu_group_alloc_blocking_domain (group); +if (ret) + goto err_remove_gdev; + group->domain = group->blocking_domain; + }
Just to be clear this is some other project "DMA boot security" and IDK if we need to do it until the CC patches land for user space device binding policy, or someone seriously implements DRTM..
Jason
Robin Murphy
reviewerRe: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
In reply to Jason GunthorpeQuoted 5 lines · Jason Gunthorpe
Quoted 4 lines · Nicolin Chen
Btw, attaching to IOMMU_DOMAIN_BLOCKED/group->blocking_domain is not allowed in general if require_direct=true. I assume this case can be an exception since there's no point in allowing a device that has no driver yet to access any reserved region?
No, the point of RMRs in general is that the device can be assumed to already be accessing them, and that access must be preserved, regardless of whether an OS driver may or may not take over the device later. In fact RMRs with the "Remapping Permitted" flag are only strictly needed *until* an OS driver has taken control over whatever it was that firmware left them doing.
Quoted 11 lines
If
require_directis set then we have to disable this mechanism..I'm not sure exactly what to do about this as the
require_directcomes from the hypervisor in a CC VM and we probably don't want to give the hypervisor this kind of escape hatch.Perhaps we need to lock off to failure on CC VMs if this ever happens..
But baremetal should just keep working how it always worked in this case..
Realistically this combination cannot exist bare-metal, since if the device requires to send ATS TT's to access an RMR then the SMMU would have to be enabled pre-boot, so then the RMR means we cannot ever disable it to reconfigure, so we'd be stuffed from the start...
Even though it's potentially a little more plausible in a VM where the underlying S2 would satisfy ATS, for much the same reason it's still going to look highly suspect from the VM's point of view to be presented with a device whose apparent ability to perform ATS traffic through a supposedly-disabled S1 SMMU must not be disrupted. However I think there would be no point exposing the ATS details to the VM to begin with. It's the host's decision to trust the device to play in the translated PA space and system cache coherency protocol, and no guest would be allowed to mess with those aspects either way, so there seems no obvious good reason for them to know at all.
Thanks,
Robin.
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 10 lines · Robin Murphy
Quoted 5 lines · Jason Gunthorpe
Quoted 4 lines · Nicolin Chen
Btw, attaching to IOMMU_DOMAIN_BLOCKED/group->blocking_domain is not allowed in general if require_direct=true. I assume this case can be an exception since there's no point in allowing a device that has no driver yet to access any reserved region?
No, the point of RMRs in general is that the device can be assumed to already be accessing them, and that access must be preserved, regardless of whether an OS driver may or may not take over the device later.
I see. Thanks for the input.
Quoted 3 lines
In fact RMRs
with the "Remapping Permitted" flag are only strictly needed *until* an OS driver has taken control over whatever it was that firmware left them doing.
Yes. I see that doesn't set require_direct.
Nicolin
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
In reply to Robin MurphyQuoted 4 lines · Robin Murphy
Realistically this combination cannot exist bare-metal, since if the device requires to send ATS TT's to access an RMR then the SMMU would have to be enabled pre-boot, so then the RMR means we cannot ever disable it to reconfigure, so we'd be stuffed from the start...
This thread has gotten mixed up..
First this series as it is has nothing to do with RMRs.
What the latter part is discussing is a future series to implement what I think MS calls "boot DMA security". Meaning we don't get into a position of allowing a device access to OS memory, even through ATS translated requests, until after userspace has approved the device.
This is something that should combine with Dynamic Root of Trust for Measurement, as DRTM is much less useful if DMA can mutate the OS code after the DTRM returns.
It is also meaningful for systems with encrypted PCI where the OS can measure the PCI device before permitting it access to anything.
So... When we do implement this new security mode, what should it do if FW attempts to attack the kernel with these nonsensical RMR configurations? With DRTM we explicitly don't trust the FW for security anymore, so it is a problem.
I strongly suspect the answer is that RMR has to be ignored in this more secure mode.
Quoted 6 lines
However I think there would be no point exposing the ATS details to the VM to begin with. It's the host's decision to trust the device to play in the translated PA space and system cache coherency protocol, and no guest would be allowed to mess with those aspects either way, so there seems no obvious good reason for them to know at all.
If the vSMMU is presented then the guest must be aware of the ATS because only the guest can generate the ATC invalidations for changes in the S1.
Without a vSMMU the ATS can be hidden from the guest.
Jason
Robin Murphy
reviewerRe: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 9 lines · Jason Gunthorpe
Quoted 4 lines · Robin Murphy
Realistically this combination cannot exist bare-metal, since if the device requires to send ATS TT's to access an RMR then the SMMU would have to be enabled pre-boot, so then the RMR means we cannot ever disable it to reconfigure, so we'd be stuffed from the start...
This thread has gotten mixed up..
First this series as it is has nothing to do with RMRs.
I know, but you brought up require_direct so I figured it was worth clarifying that should not in fact impact ATS decisions, since the combination a device requiring ATS while *also* requiring an RMR would be essentially impossible to support given the SMMU architecture, thus we can reasonably assume nobody will do such a thing (or at least do it with any expectation of it ever working).
Quoted 4 lines
What the latter part is discussing is a future series to implement what I think MS calls "boot DMA security". Meaning we don't get into a position of allowing a device access to OS memory, even through ATS translated requests, until after userspace has approved the device.
Pre-boot protection is in the same boat, as things currently stand - an OS could either preserve security (by using GBPA to keep traffic blocked while reconfiguring the rest of the SMMU), *or* have ongoing DMA for a splash screen or whatever; it cannot realistically have both.
Quoted 7 lines
This is something that should combine with Dynamic Root of Trust for Measurement, as DRTM is much less useful if DMA can mutate the OS code after the DTRM returns.
It is also meaningful for systems with encrypted PCI where the OS can measure the PCI device before permitting it access to anything.
Quoted 7 lines
So... When we do implement this new security mode, what should it do if FW attempts to attack the kernel with these nonsensical RMR configurations? With DRTM we explicitly don't trust the FW for security anymore, so it is a problem.
I strongly suspect the answer is that RMR has to be ignored in this more secure mode.
Yes, I think the only valid case for having an RMR and expecting it to work in combination with these other things is if the device has some firmware or preloaded configuration in memory which it will still need to access at that address once an OS driver starts using it, but does not need to access *during* the boot-time handover. Thus it seems fair to still honour the reserved regions upon attaching to a default domain, but not worry too much about being in a transient blocking state in the interim if it's unavoidable for other reasons (at worst maybe just log a warning that we're doing so).
Quoted 10 lines
Quoted 6 lines
However I think there would be no point exposing the ATS details to the VM to begin with. It's the host's decision to trust the device to play in the translated PA space and system cache coherency protocol, and no guest would be allowed to mess with those aspects either way, so there seems no obvious good reason for them to know at all.
If the vSMMU is presented then the guest must be aware of the ATS because only the guest can generate the ATC invalidations for changes in the S1.
Only if you assume DVM or some other mechanism for the guest to issue S1 invalidations directly to the hardware - with an emulated CMDQ we can do whatever we like.
And in fact, I think we actually *have* to if the host has enabled ATS itself, since we cannot assume that a guest is going to choose to use it, thus we cannot rely on the guest issuing ATCIs in order to get the correct behaviour it expects unless and until we've seen it set EATS appropriately in all the corresponding vSTEs. So we would have to forbid DVM, and only allow other direct mechanisms that can be dynamically enabled for as long as the guest configuration matches... Fun.
Thanks,
Robin.
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 8 lines · Robin Murphy
Quoted 2 lines
I strongly suspect the answer is that RMR has to be ignored in this more secure mode.
Yes, I think the only valid case for having an RMR and expecting it to work in combination with these other things is if the device has some firmware or preloaded configuration in memory which it will still need to access at that address once an OS driver starts using it, but does not need to access *during* the boot-time handover.
Splash screens are the most obvious case here where the framebuffer may be in DMA'able memory and must go through the iommu..
At least we are already shipping products where the GPU has DRAM based framebuffer, the GPU requires ATS for alot of functions, but the framebuffer scan out does not use ATS.
Sigh. So that will be exciting to make work at some point.
Quoted 5 lines
Thus it seems fair to still honour the
reserved regions upon attaching to a default domain, but not worry too much about being in a transient blocking state in the interim if it's unavoidable for other reasons (at worst maybe just log a warning that we're doing so).
The interest in the blocking state was to disable ATS.
Maybe another approach would be to have a "RMR blocking" domain which is a paging domain that tells the driver explicitly not to enable ATS for it.
Then we could validate the RMR range is OK and install this special domain and still have security against translated TLPs..
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
However I think there would be no point exposing the ATS details to the VM to begin with. It's the host's decision to trust the device to play in the translated PA space and system cache coherency protocol, and no guest would be allowed to mess with those aspects either way, so there seems no obvious good reason for them to know at all.
Quoted 7 lines
Quoted 3 lines
If the vSMMU is presented then the guest must be aware of the ATS because only the guest can generate the ATC invalidations for changes in the S1.
Only if you assume DVM or some other mechanism for the guest to issue S1 invalidations directly to the hardware - with an emulated CMDQ we can do whatever we like.
With alot of work yes, but that is not the model that is implemented today.
If the hypervisor has to generate a ATC invalidation from an IOTLB invalidation then it also needs a map of ASID to RID&PASID, which it can only build by inspecting all the CD tables. The VMMs in nesting mode don't read the CD tables at all today, so they don't implement this option.
Quoted 5 lines
And in fact, I think we actually *have* to if the host has enabled ATS itself, since we cannot assume that a guest is going to choose to use it, thus we cannot rely on the guest issuing ATCIs in order to get the correct behaviour it expects unless and until we've seen it set EATS appropriately in all the corresponding vSTEs.
Due to the above we've done the reverse, the host does not get to unilaterally decide ATS policy, it follows the guest's vEATS setting so that we never have a situation where the hypervisor has to generate ATC invalidations.
The kernel offers the VMM the freedom to do it either way, but today all the VMMs I'm aware of choose the above path.
Jason
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
In reply to Jason GunthorpeQuoted 7 lines · Jason Gunthorpe
Quoted 4 lines · Nicolin Chen
Btw, attaching to IOMMU_DOMAIN_BLOCKED/group->blocking_domain is not allowed in general if require_direct=true. I assume this case can be an exception since there's no point in allowing a device that has no driver yet to access any reserved region?
If
require_directis set then we have to disable this mechanism..
I found a corner case, which might be another exception here?
Most of dma_configure callback functions don't use default domain when driver_managed_dma is set. And this breaks MSI on pcieports.
So, I am thinking of doing this:
bool is_pci_bridge = dev_is_pci(dev) && pci_is_bridge(to_pci_dev(dev));
[...]
/*
* Block translation requests from a device not bound to a driver yet,
* with two exceptions:
* 1. IOMMU_RESV_DIRECT (require_direct) must guarantee that the
* device always has access to reserved region(s)
* 2. PCI bridges (pcieport, CXL) skip default domain setup in its
* dma_configure callback function due to !driver_managed_dma.
* On the other hand, they require the default domain for MSIs.
*/
if (!dev->driver && !group->domain && !dev->iommu->require_direct &&
!is_pci_bridge) {
ret = __iommu_group_alloc_blocking_domain(group);
if (ret)
goto err_remove_gdev;
group->domain = group->blocking_domain;
}But I am very unsure about the other cases because it could lead to some "regression" due to this new restriction.
That being said, setting driver_managed_dma while relying on the default domain somewhat seems like a bug to me. So it feels that we should fix those drivers instead of making an exception here?
Thanks
Nicolin
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 10 lines · Nicolin Chen
Quoted 7 lines · Jason Gunthorpe
Quoted 4 lines · Nicolin Chen
Btw, attaching to IOMMU_DOMAIN_BLOCKED/group->blocking_domain is not allowed in general if require_direct=true. I assume this case can be an exception since there's no point in allowing a device that has no driver yet to access any reserved region?
If
require_directis set then we have to disable this mechanism..I found a corner case, which might be another exception here?
I don't think this blocking security work needs to be part of this series. We just need to disable the mechanism for untrusted devices.
Quoted 2 lines
Most of
dma_configurecallback functions don't use default domain whendriver_managed_dmais set. And this breaks MSI on pcieports.
The ARM MSI aperture need is some special case here. Those drivers don't use DMA at all so of course they don't have the DMA API setup, but they do use the MSI aperture on ARM.
Broadly here we were talking about blocked domains for unattached drivers, but an empty DMA domain is the same thing and still continues to allow the MSI vectors to work.
So we can reframe this a little bit into more like
if the user requests IDENTITY then the IDENTITY domain is not installed until just before the driver binds. Up until then it is in the DMA domain. Meaning if userspace controls driver binding then unbound drivers have their DMA access blocked by an empty DMA domain.
ie we dynamical shift modes for security.
This would only work on singleton groups.
Jason
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 8 lines · Jason Gunthorpe
Quoted 7 lines · Nicolin Chen
Quoted 6 lines · Jason Gunthorpe
Quoted 4 lines · Nicolin Chen
Btw, attaching to IOMMU_DOMAIN_BLOCKED/group->blocking_domain is not allowed in general if require_direct=true. I assume this case can be an exception since there's no point in allowing a device that has no driver yet to access any reserved region?
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
If
require_directis set then we have to disable this mechanism..I found a corner case, which might be another exception here?
I don't think this blocking security work needs to be part of this series. We just need to disable the mechanism for untrusted devices.
Oh, I thought it should be a prerequisite. I'll separate the patch then.
Quoted 10 lines
Quoted 2 lines
Most of
dma_configurecallback functions don't use default domain whendriver_managed_dmais set. And this breaks MSI on pcieports.The ARM MSI aperture need is some special case here. Those drivers don't use DMA at all so of course they don't have the DMA API setup, but they do use the MSI aperture on ARM.
Broadly here we were talking about blocked domains for unattached drivers, but an empty DMA domain is the same thing and still continues to allow the MSI vectors to work.
I see.
Quoted 6 lines
So we can reframe this a little bit into more like
if the user requests IDENTITY then the IDENTITY domain is not installed until just before the driver binds. Up until then it is in the DMA domain. Meaning if userspace controls driver binding then unbound drivers have their DMA access blocked by an empty DMA domain.
The thing is that those driver_managed_dma callbacks don't call iommu_device_use_default_domain(). So, the iommu core loses the trigger to switch domain from BLOCKED/empty-DMA to DMA/IDENTITY.
The pcieports case via pci_dma_configure() is an example.
My previous approach using BUS_NOTIFY could likely work, but it needed to adjust the timing between BUS_NOTIFY and dev->driver setting.
Thanks
Nicolin
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 3 lines · Nicolin Chen
The thing is that those
driver_managed_dmacallbacks don't calliommu_device_use_default_domain(). So, the iommu core loses the trigger to switch domain from BLOCKED/empty-DMA to DMA/IDENTITY.
But they don't use DMA API at all so it doesn't matter to them.
Your issue is that BLOCKED breaks MSI on ARM. That is fixed by using an empty-DMA API domain as default.
What is missing is to bring back the IDENTITY performance optimization in a secure way.
Jason
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 8 lines · Jason Gunthorpe
Quoted 3 lines · Nicolin Chen
The thing is that those
driver_managed_dmacallbacks don't calliommu_device_use_default_domain(). So, the iommu core loses the trigger to switch domain from BLOCKED/empty-DMA to DMA/IDENTITY.But they don't use DMA API at all so it doesn't matter to them.
Your issue is that BLOCKED breaks MSI on ARM.
Thanks for the hint!
It actually failed in iommu_dma_prepare_msi() due to having an IOMMU_COOKIE_NONE in the blocking_domain.
My implementation sets group->domain to group->blocking_domain, and keeps group->default_domain=NULL to retain the EPROBE_DEFER validation in iommu_device_use_default_domain().
Then in iommu_dma_prepare_msi(), the group->domain now becomes valid so it failed due to its unsupported iommu cookie, which I entirely missed.
I could simply fix this by adding:
@@ -3892,7 +3892,8 @@ int iommu_dma_prepare_msi(struct msi_desc *desc, phys_addr_t msi_addr)
mutex_lock(&group->mutex);
/* An IDENTITY domain must pass through */
- if (group->domain && group->domain->type != IOMMU_DOMAIN_IDENTITY) {
+ if (group->default_domain && group->domain &&
+ group->domain->type != IOMMU_DOMAIN_IDENTITY) {
switch (group->domain->cookie_type) {
case IOMMU_COOKIE_DMA_MSI:
case IOMMU_COOKIE_DMA_IOVA:Quoted 2 lines
That is fixed by using
an empty-DMA API domain as default.
Hmm, even if we set arm_smmu_blocked_domain.type to an empty DMA (IOMMU_DOMAIN_UNMANAGED?), it still doesn't allocate a cookie?
Quoted 2 lines
What is missing is to bring back the IDENTITY performance optimization in a secure way.
I might have got it wrong (from the last part below).
https://lore.kernel.org/linux-iommu/[email protected]/.
You mean to disable ATS on IDENTITY domains?
Thanks
Nicolin
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 7 lines · Nicolin Chen
Quoted 2 lines
What is missing is to bring back the IDENTITY performance optimization in a secure way.
I might have got it wrong (from the last part below).
https://lore.kernel.org/linux-iommu/[email protected]/.You mean to disable ATS on IDENTITY domains?
The objective of this security step is to keep ATS blocked and IDENTITY domains disabled until the userspace has "accepted" the device by binding a driver to it.
The off the cuff suggestion was to just park the device BLOCKED until a driver is bound. This disables ATS and blocks translation.
That doesn't work on ARM because of the MSI issue.
The next suggestion is to park the device in a real DMA domain with an actual page table and DMA API hooked up. Now interrupts will work and the domain is empty so there is no translation. The issue here is the domain doesn't block ATS. We could fix this with some "disable ATS" domain flag.
In either case when the driver is bound and requests that the DMA API start working if the user requested IDENTITY then it has to be switched away from the parked domain to IDENTITY.
A final thought would be to change around the driver managed DMA mechanism a bit to allow drivers to indicate they use IRQs but not DMA, then the bind step could switch from a BLOCKED domain to an empty DMA API domain to allow MSI to work.
Jason
Robin Murphy
reviewerRe: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 9 lines · Jason Gunthorpe
Quoted 7 lines · Nicolin Chen
Quoted 2 lines
What is missing is to bring back the IDENTITY performance optimization in a secure way.
I might have got it wrong (from the last part below).
https://lore.kernel.org/linux-iommu/[email protected]/.You mean to disable ATS on IDENTITY domains?
Quoted 8 lines
The objective of this security step is to keep ATS blocked and IDENTITY domains disabled until the userspace has "accepted" the device by binding a driver to it.
The off the cuff suggestion was to just park the device BLOCKED until a driver is bound. This disables ATS and blocks translation.
That doesn't work on ARM because of the MSI issue.
But is that an issue? Until the device has a driver, surely it shouldn't be expected to send interrupts at all, much less depend on them being received and understood by Linux? The MSI cookie is only populated once a driver actually requests some MSI vectors (since it doesn't know what ITS address(es) may or may not need mapping), so an empty DMA domain is still no better than a true blocking domain in this regard anyway.
Thanks,
Robin.
Quoted 16 lines
The next suggestion is to park the device in a real DMA domain with an actual page table and DMA API hooked up. Now interrupts will work and the domain is empty so there is no translation. The issue here is the domain doesn't block ATS. We could fix this with some "disable ATS" domain flag.
In either case when the driver is bound and requests that the DMA API start working if the user requested IDENTITY then it has to be switched away from the parked domain to IDENTITY.
A final thought would be to change around the driver managed DMA mechanism a bit to allow drivers to indicate they use IRQs but not DMA, then the bind step could switch from a BLOCKED domain to an empty DMA API domain to allow MSI to work.
Jason
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 6 lines · Robin Murphy
But is that an issue? Until the device has a driver, surely it shouldn't be expected to send interrupts at all, much less depend on them being received and understood by Linux? The MSI cookie is only populated once a driver actually requests some MSI vectors (since it doesn't know what ITS address(es) may or may not need mapping), so an empty DMA domain is still no better than a true blocking domain in this regard anyway.
Oh, the issue is the driver_managed_dma flag.
In this mode we do bind a driver but the iommu callbacks at driver bind are not called anymore because that flag says the driver itself will call them later.
Things like PCI port driver that never issue DMA at all will set the flag and never make any calls, while still expecting interrupts to work.
This is why the other option is to rework this somewhat so these drivers still make call in to the iommu and can get an interrupt setup.
All of this is only for multi-device groups where we want to ignore some bad grouping with VFIO on old HW without sufficient ACS. Thinking about it some more I suspect this entire concept has been broken from day 1 in VFIO on ARM. If the iommu_group has two members, port driver and a VFIO device then:
The port driver will start first, install the ITS page in the DMA domain, VFIO will start second an switch the domain to BLOCKED, then to PAGING, and the ITS mapping used by the port driver will be lost.
And nobody will notice this has happened because the interrupts in the port driver are only used for RAS IIRC so the net effect is your system doesn't print AERs anymore.
Jason
Robin Murphy
reviewerRe: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 15 lines · Jason Gunthorpe
Quoted 6 lines · Robin Murphy
But is that an issue? Until the device has a driver, surely it shouldn't be expected to send interrupts at all, much less depend on them being received and understood by Linux? The MSI cookie is only populated once a driver actually requests some MSI vectors (since it doesn't know what ITS address(es) may or may not need mapping), so an empty DMA domain is still no better than a true blocking domain in this regard anyway.
Oh, the issue is the
driver_managed_dmaflag.In this mode we do bind a driver but the iommu callbacks at driver bind are not called anymore because that flag says the driver itself will call them later.
Quoted 7 lines
Things like PCI port driver that never issue DMA at all will set the flag and never make any calls, while still expecting interrupts to work.
This is why the other option is to rework this somewhat so these drivers still make call in to the iommu and can get an interrupt setup.
Or perhaps we handle BUS_NOTIFY_BIND_DRIVER to manage the switch from BLOCKED to (empty) DMA independently from whether the driver subsequently claims the DMA domain or not? That said, I wouldn't have any particular objection to generalising iommu_use_default_domain() into something like iommu_prepare_default_domain(bool managed) either.
Quoted 6 lines
All of this is only for multi-device groups where we want to ignore some bad grouping with VFIO on old HW without sufficient ACS. Thinking about it some more I suspect this entire concept has been broken from day 1 in VFIO on ARM. If the
iommu_grouphas two members, port driver and a VFIO device then:
Quoted 7 lines
The port driver will start first, install the ITS page in the DMA domain, VFIO will start second an switch the domain to BLOCKED, then to PAGING, and the ITS mapping used by the port driver will be lost.
And nobody will notice this has happened because the interrupts in the port driver are only used for RAS IIRC so the net effect is your system doesn't print AERs anymore.
Indeed VFIO's MSI cookie doesn't inherit any existing mappings from the DMA domain, and that wouldn't work anyway since the IOVAs would almost certainly be different. So we'd have to somehow free any existing AER interrupts before the domain switch, then fully re-request and reprogram them afterwards, in both DMA->UNMANAGED and UNMANAGED->DMA directions. Oof...
Thanks,
Robin.
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 8 lines · Robin Murphy
Quoted 7 lines
The port driver will start first, install the ITS page in the DMA domain, VFIO will start second an switch the domain to BLOCKED, then to PAGING, and the ITS mapping used by the port driver will be lost.
And nobody will notice this has happened because the interrupts in the port driver are only used for RAS IIRC so the net effect is your system doesn't print AERs anymore.
Quoted 5 lines
Indeed VFIO's MSI cookie doesn't inherit any existing mappings from the DMA domain, and that wouldn't work anyway since the IOVAs would almost certainly be different. So we'd have to somehow free any existing AER interrupts before the domain switch, then fully re-request and reprogram them afterwards, in both
DMA->UNMANAGEDandUNMANAGED->DMAdirections. Oof...
I'm inclined to say we should disable this VFIO feature if CONFIG_IRQ_MSI_IOMMU is enabled... Better to hard fail then silently loose interrutps.
If that causes problems for people then we should investigate how to fix the MSI.
It is really hard, but perhaps the most elegant solution would be to allow the group members to have unique iommu domains by dis-ambiguating the 'grouping for aliasing' and 'grouping for ACS' cases. Then the portdrv can stay on its DMA domain and everything keeps working for it. That sounds like a monster project...
Jason
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
In reply to Jason GunthorpeQuoted 10 lines · Jason Gunthorpe
On Thu, Feb 19, 2026 at 08:52:56PM -0800, Nicolin Chen wrote:
The next suggestion is to park the device in a real DMA domain with an actual page table and DMA API hooked up. Now interrupts will work and the domain is empty so there is no translation. The issue here is the domain doesn't block ATS. We could fix this with some "disable ATS" domain flag.In either case when the driver is bound and requests that the DMA API start working if the user requested IDENTITY then it has to be switched away from the parked domain to IDENTITY.
Thanks for elaborating. This seems very orthogonal to the issue that driver_managed_dma skips iommu_device_use_default_domain(). (And I see you discussion with Robin.)
Regarding the empty-DMA domain, I have an idea of accommodating ARM cases with an IOMMU_DOMAIN_MSI_ONLY, which is essentially a paging domain that only allows IOMMU_COOKIE_DMA_MSI but blocks everything else.
Quoted 4 lines
A final thought would be to change around the driver managed DMA mechanism a bit to allow drivers to indicate they use IRQs but not DMA, then the bind step could switch from a BLOCKED domain to an empty DMA API domain to allow MSI to work.
Yes, "driver_managed_dma" is so unclear in pcieport case, since its driver doesn't really manage DMA...
A separate flag could be clear. And the IOMMU layer might do an AND operation between driver_uses_msi(?) flag and another IOMMU device-level flag msi_behind_iommu?
Thank you
Nicolin
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 12 lines · Nicolin Chen
Quoted 10 lines · Jason Gunthorpe
On Thu, Feb 19, 2026 at 08:52:56PM -0800, Nicolin Chen wrote:
The next suggestion is to park the device in a real DMA domain with an actual page table and DMA API hooked up. Now interrupts will work and the domain is empty so there is no translation. The issue here is the domain doesn't block ATS. We could fix this with some "disable ATS" domain flag.In either case when the driver is bound and requests that the DMA API start working if the user requested IDENTITY then it has to be switched away from the parked domain to IDENTITY.
Quoted 8 lines
Thanks for elaborating. This seems very orthogonal to the issue that
driver_managed_dmaskipsiommu_device_use_default_domain(). (And I see you discussion with Robin.)Regarding the empty-DMA domain, I have an idea of accommodating ARM cases with an
IOMMU_DOMAIN_MSI_ONLY, which is essentially a paging domain that only allowsIOMMU_COOKIE_DMA_MSIbut blocks everything else.
Yeah, maybe, but also we probably don't need such stringent checks since no driver will be bound while this domain is setup, so the basic DMA domain is fine too.
Quoted 7 lines
Quoted 4 lines
A final thought would be to change around the driver managed DMA mechanism a bit to allow drivers to indicate they use IRQs but not DMA, then the bind step could switch from a BLOCKED domain to an empty DMA API domain to allow MSI to work.
Yes, "
driver_managed_dma" is so unclear in pcieport case, since its driver doesn't really manage DMA...
It should be taken to mean "this device never does DMA when attached to this driver"
Quoted 3 lines
A separate flag could be clear. And the IOMMU layer might do an AND operation between
driver_uses_msi(?)flag and another IOMMU device-level flagmsi_behind_iommu?
Perhaps the bool can become an enum:
NORMAL DMA API
MANUAL DOMAIN MANAGEMENT
NO DMA MSI ONLY
Then the latter can switch to a DMA domain out of blocked on driver binding, and we'd teach VFIO to refuse multi-device groups with MSI ONLY members on ARM because it doesn't work :\
Jason
RE: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
In reply to Jason GunthorpeQuoted 40 lines
From: Jason Gunthorpe <[email protected]>
Sent: Tuesday, January 27, 2026 11:05 PMQuoted 7 lines · Kevin
Quoted 7 lines
From: Williams, Dan J <[email protected]>
Sent: Friday, January 23, 2026 3:46 AMQuoted 1 line · Jason Gunthorpe
On Wed, Jan 21, 2026 at 09:44:32PM -0800, [email protected]
Quoted 1 line · wrote:
Quoted 1 line
I do not immediately see what is wrong with requiring userspace
policy
Quoted 13 lines
Quoted 13 lines
Quoted 13 lines
Quoted 3 lines
opt-in. That naturally gets replaced by installing the device's certificate (for native PCI CMA), authenticating the device with the TSM (for PCI IDE), or obviated by secure-ATS if that arrives.
I think that goes back to the discussion about not loading drivers before validating the device.
It would also make alot of sense to leave the IOMMU blocking until the driver is loaded for these secure situations. The blocking translation should block ATS too.
Then the flow you are describing will work well:
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
1) At pre-boot the IOMMU will block all DMA including Translated.
2) The OS activates the IOMMU driver and keeps blocking.
3) Instead of immediately binding a default domain the IOMMU core leaves the translation blocking.
4) The OS defers loading the driver to userspace.
5) Userspace measures the device and "accepts" it by loading the driver
6) IOMMU core attaches a non-blocking default domain and activatesATS
Quoted 2 lines
Quoted 2 lines
That works for me. Give the paranoid the ability to have a point where
they
Quoted 3 lines
Quoted 2 lines
can
be assured that the shields were not lowered prematurely.
Quoted 8 lines
Quoted 3 lines
Jason described the flow as "for these secure situations", i.e. not a general requirement for cxl.cache, but iiuc Dan may instead want userspace policy opt-in to be default (and with CMA/TSM etc. it gets easier)?
I think the general strategy has been to push userspace to do security decisions before binding drivers. So we have a plan for confidential compute VMs, and if there is interest then we can probably re-use that plan in all other cases.
make sense
Quoted 19 lines
Quoted 3 lines
At a glance cxl.cache devices have gained ATS enabled automatically in most cases (same as for all other ats-capable PCI devices):
Yes.
Quoted 3 lines
- ARM: ATS is enabled automatically when attaching the default domain to the device in certain configurations, and this series tries to auto enable it in a missing configuration
Yes, ARM took the position that ATS should be left disabled for IDENTITY both because of SMMU constraints and also because it made some sense that you wouldn't want ATS overhead just to get a 1:1 translation.
Quoted 1 line
- AMD: ATS is enabled at domain attach time
I'd argue this is an error and it should work like ARM
Quoted 8 lines
Quoted 2 lines
- Intel: ATS is enabled when a device is probed by intel-iommu driver (incompatible with the suggested flow)
This is definately not a good choice :)
IMHO it is security required that the IOMMU driver block Translated requests while a BLOCKED domain is attached, and while the IOMMU is refusing ATS then device's ATS enable should be disabled.
It was made that way by commit 5518f239aff1 ("iommu/vt-d: Move scalable mode ATS enablement to probe path "). The old policy was same as AMD side, and changed to current way so domain change in RID won't affect the ATS requirement for PASIDs.
But I agree BLOCKED is special. Ideally there is no reason to have RID attached to a BLOCKED domain while PASIDs are not blocked... oh, wait
there is one scenario, e.g. VFIO allows domains attached to RID and PASIDs being changed independently. It's a sane situation to have userspace change RID domain via attach/detach/re-attach, while PASID domains are still active. 'detach' will attach RID to a BLOCKED domain, then disabling ATS in that window may break PASIDs.
How does ARM address this scenario? Is it more suitable to have a new interface specific for driver bind/unbind to enable/disable ATS instead of toggling it based on BLOCKED?
Quoted 8 lines
Quoted 5 lines
Given above already shipped in distributions, probably we have to keep them for compatibility (implying this series makes sense to fix a gap in existing policy), then treat the suggested flow as an enhancement for future?
I don't think we have a compatability issue here, just a security one.
'compatibility issue' if auto-enabling is completely removed with userspace opt-in as the only way. But since it's not the case, then yes it's more a security one.
Quoted 8 lines
Drivers need to ensure that ATS is disabled at PCI and Translated requestes blocked in IOMMU HW while a BLOCKED domain is attached.
Drivers can choose if they want to enable ATS for IDENTITY or not, (recommend not for performance and consistency).
Jason
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 5 lines · Kevin
Quoted 5 lines
Quoted 2 lines
- Intel: ATS is enabled when a device is probed by intel-iommu driver (incompatible with the suggested flow)
This is definately not a good choice :)
Quoted 8 lines
Quoted 3 lines
IMHO it is security required that the IOMMU driver block Translated requests while a BLOCKED domain is attached, and while the IOMMU is refusing ATS then device's ATS enable should be disabled.
It was made that way by commit
5518f239aff1("iommu/vt-d: Move scalable mode ATS enablement to probe path "). The old policy was same as AMD side, and changed to current way so domain change in RID won't affect the ATS requirement for PASIDs.
That's a legimiate thing, but always on is a heavy handed solution.
The driver should track what is going on with the PASID and enable ATS if required.
Which also solves this:
Quoted 9 lines
there is one scenario, e.g. VFIO allows domains attached to RID and PASIDs being changed independently. It's a sane situation to have userspace change RID domain via attach/detach/re-attach, while PASID domains are still active. 'detach' will attach RID to a BLOCKED domain, then disabling ATS in that window may break PASIDs.
How does ARM address this scenario? Is it more suitable to have a new interface specific for driver bind/unbind to enable/disable ATS instead of toggling it based on BLOCKED?
And is what SMMUv3 is doing already. With an IDENTITY translation on the RID it starts out with ATS disabled and switches to IDENTITY with ATS enabled when the first PASID appears. Switches back when the PASID goes away.
Jason
RE: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Quoted 13 lines
From: Jason Gunthorpe <[email protected]>
Sent: Wednesday, January 28, 2026 9:12 PMQuoted 9 lines · Kevin
Quoted 8 lines
Quoted 2 lines
- Intel: ATS is enabled when a device is probed by intel-iommu driver (incompatible with the suggested flow)
This is definately not a good choice :)
IMHO it is security required that the IOMMU driver block Translated requests while a BLOCKED domain is attached, and while the IOMMU is refusing ATS then device's ATS enable should be disabled.
Quoted 6 lines
Quoted 4 lines
It was made that way by commit
5518f239aff1("iommu/vt-d: Move scalable mode ATS enablement to probe path "). The old policy was same as AMD side, and changed to current way so domain change in RID won't affect the ATS requirement for PASIDs.That's a legimiate thing, but always on is a heavy handed solution.
yes. at that point the rationale was made purely based on functionality instead of security.
Quoted 12 lines
The driver should track what is going on with the PASID and enable ATS if required.
Which also solves this:
Quoted 5 lines
there is one scenario, e.g. VFIO allows domains attached to RID and PASIDs being changed independently. It's a sane situation to have userspace change RID domain via attach/detach/re-attach, while PASID domains are still active. 'detach' will attach RID to a BLOCKED domain, then disabling ATS in that window may break PASIDs.
Quoted 9 lines
Quoted 3 lines
How does ARM address this scenario? Is it more suitable to have a new interface specific for driver bind/unbind to enable/disable ATS instead of toggling it based on BLOCKED?
And is what SMMUv3 is doing already. With an IDENTITY translation on the RID it starts out with ATS disabled and switches to IDENTITY with ATS enabled when the first PASID appears. Switches back when the PASID goes away.
yes, that should work. In that way the driver binding flow is covered automatically.
Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
In reply to Jason GunthorpeQuoted 17 lines · Jason Gunthorpe
Quoted 10 lines · Jonathan Cameron
Quoted 6 lines · Kevin
+Dan. I recalled an offline discussion in which he raised concern on having the kernel blindly enable ATS for cxl.cache device instead of creating a knob for admin to configure from userspace (in case security is viewed more important than functionality, upon allowing DMA to read data out of CPU caches)...
+CC Linux-cxl
A cxl.cache device supporting ATS will automatically enable ATS today if the kernel option to enable translation is set.
Even if the device is marked untrusted by the PCI layer (eg an external port).
Quoted 8 lines
Yes this is effectively a security issue, but it is not really a CXL specific problem.
We might perfer to not enable ATS for untrusted devices and then fail to load drivers for "ats always on" cases.
Or maybe we can enable one of the ATS security features someday, though I wonder if those work for CXL..
I raised my concerns about CXL.cache and virtualization at LPC: https://lpc.events/event/19/contributions/2173/attachments/1842/3940/LPC_2025_CXL_CACHE.pdf
I expose there some concerns, although I admit some could be due to my twisted understanding of what CXL specs states, but regarding IOMMU/ATS, my view is ATS is not safe enough ... what I guess is a matter of opinion (trusted device based on vendor confirming it is an "official" device not enough for paranoid mode with vendors subjected to governments "agencies" actions/pressures). But this links to what I think Jason points out about ATS security features where the IOMMU hardware can be configured for checking those translated PCIe accesses as well, if the host owner/admin paranoid mind decides so. With CXL cache that is not possible since the route is through a different link and AFAIK, there is no support for something like this by current implementations. I think it could be implemented without impacting the gains from CXL.cache, but that is another story.
So, FWIW, I think it should not be enabled by default.
Thank you,
Alejandro
Quoted 2 lines
Jason
RFC PATCH 2/3 PCI: Allow ATS to be always on for non-CXL NVIDIA GPUs
In reply to Nicolin ChenSome non-CXL NVIDIA GPU devices support non-PASID ATS function when their RIDs are IOMMU bypassed. This is slightly different than the default ATS policy which would only enable ATS on demand: when a non-zero PASID line is enabled in SVA use cases.
Introduce a pci_dev_specific_ats_always_on() quirk function to support a list of IDs for these device. Then, include it pci_ats_always_on().
--- drivers/pci/pci.h | 9 +++++++++ drivers/pci/ats.c | 3 ++- drivers/pci/quirks.c | 23 +++++++++++++++++++++++ 3 files changed, 34 insertions(+), 1 deletion(-)
drivers/pci/pci.h +9 -0
@@ -1032,6 +1032,15 @@ static inline int pci_dev_specific_reset(struct pci_dev *dev, bool probe) }#endif +#if defined(CONFIG_PCI_QUIRKS ) && defined(CONFIG_PCI_ATS ) +bool pci_dev_specific_ats_always_on (struct pci_dev *dev); +#else +static inline bool pci_dev_specific_ats_always_on (struct pci_dev *dev) +{ +return false; +} +#endif +#if defined(CONFIG_PCI_QUIRKS ) && defined(CONFIG_ARM64 )int acpi_get_rc_resources (struct device *dev,const char *hid,u16 segment,struct resource *res);
drivers/pci/ats.c +2 -1
@@ -245,7 +245,8 @@ bool pci_ats_always_on(struct pci_dev *pdev)if (pdev->is_virtfn) pdev =pci_physfn (pdev); -return pci_cxl_ats_always_on (pdev); +return pci_cxl_ats_always_on (pdev) || +pci_dev_specific_ats_always_on (pdev); }EXPORT_SYMBOL_GPL (pci_ats_always_on);
drivers/pci/quirks.c +23 -0
@@ -5654,6 +5654,29 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1457, quirk_intel_e2000_no_ats);DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_INTEL ,0x1459 , quirk_intel_e2000_no_ats);DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_INTEL ,0x145a , quirk_intel_e2000_no_ats);DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_INTEL ,0x145c , quirk_intel_e2000_no_ats); + +static const struct pci_dev_ats_always_on { +u16 vendor; +u16 device; +} pci_dev_ats_always_on[] = { + {PCI_VENDOR_ID_NVIDIA ,0x2e12 , }, + {PCI_VENDOR_ID_NVIDIA ,0x2e2a , }, + {PCI_VENDOR_ID_NVIDIA ,0x2e2b , }, + {0 } +}; + +/* Some non-CXL devices support ATS on RID when it is IOMMU-bypassed */ +bool pci_dev_specific_ats_always_on (struct pci_dev *pdev) +{ +const struct pci_dev_ats_always_on *i; + +for (i = pci_dev_ats_always_on; i->vendor; i++) { +if (i->vendor == pdev->vendor && i->device == pdev->device) +return true; + } + +return false; +}#endif /* CONFIG_PCI_ATS */ /* Freescale PCIe doesn't support MSI in RC mode */
Signature · 1 line
2.43.0
Re: [PATCH RFCv1 2/3] PCI: Allow ATS to be always on for non-CXL NVIDIA GPUs
Quoted 4 lines · Nicolin Chen
Some non-CXL NVIDIA GPU devices support non-PASID ATS function when their RIDs are IOMMU bypassed. This is slightly different than the default ATS policy which would only enable ATS on demand: when a non-zero PASID line is enabled in SVA use cases.
Not support, require non-PASID ATS.
I've been describing these devices as pre-CXL, in that they have many CXL like properties, including what motivated the prior patch, but do not implement the CXL config space.
Quoted 1 line
+/* Some non-CXL devices support ATS on RID when it is IOMMU-bypassed */
Require not support
This also looks OK to me
Jason
Re: [PATCH RFCv1 2/3] PCI: Allow ATS to be always on for non-CXL NVIDIA GPUs
Quoted 8 lines · Jason Gunthorpe
Quoted 4 lines · Nicolin Chen
Some non-CXL NVIDIA GPU devices support non-PASID ATS function when their RIDs are IOMMU bypassed. This is slightly different than the default ATS policy which would only enable ATS on demand: when a non-zero PASID line is enabled in SVA use cases.
Not support, require non-PASID ATS.
Quoted 7 lines
I've been describing these devices as pre-CXL, in that they have many CXL like properties, including what motivated the prior patch, but do not implement the CXL config space.
Quoted 1 line
+/* Some non-CXL devices support ATS on RID when it is IOMMU-bypassed */
Require not support
I will fix these.
Thanks!
Nicolin
RFC PATCH 3/3 iommu/arm-smmu-v3: Allow ATS to be always on
In reply to Nicolin ChenWhen 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, drop the WARN_ON().
--- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 + drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 74 ++++++++++++++++++--- 2 files changed, 64 insertions(+), 11 deletions(-)
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h +1 -0
@@ -850,6 +850,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; };
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +63 -11
131 lines not on this page · raw message
Signature · 1 line
2.43.0
Re: [PATCH RFCv1 3/3] iommu/arm-smmu-v3: Allow ATS to be always on
Quoted 12 lines · Nicolin Chen
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +12
-0+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;
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c static void arm_smmu_remove_master(struct arm_smmu_master *master) · line 3563
Quoted 10 lines
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +10
-0+ +/* +* 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; + }
It looks right, IDK if Will would prefer a formal ARM_SMMU_FEAT_S1DSS though.
Jason
Will Deacon
maintainerRe: [PATCH RFCv1 3/3] iommu/arm-smmu-v3: Allow ATS to be always on
In reply to Nicolin ChenQuoted 54 lines · Nicolin Chen
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_bitsis set to 0. However, s1cdmax must be set to a !0 value in order to keep the S1DSS field effective. Thus, when a master requiresats_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, drop theWARN_ON().Signed-off-by Nicolin Chen <[email protected]>--- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 + drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 74 ++++++++++++++++++--- 2 files changed, 64 insertions(+), 11 deletions(-)drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h +1
-0@@ -850,6 +850,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; };drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +0
-0
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c void arm_smmu_clear_cd(struct arm_smmu_master *master, ioasid_t ssid) · line 1426
Quoted 6 lines
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +1
-1@@ -1422,7 +1422,7 @@ 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)return ;
Should we still warn if !master->ats_always_on?
Quoted 36 lines
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +18
-1arm_smmu_write_cd_entry (master, ssid, cdptr, &target); }@@ -1436,6 +1436,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) ||@@ -3189,7 +3205,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_get_domain_for_dev (master->dev);
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c static void arm_smmu_attach_dev_ste(struct iommu_domain *domain, · line 3227
Quoted 7 lines
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +1
-1@@ -3205,7 +3222,7 @@ static void arm_smmu_attach_dev_ste(struct iommu_domain *domain,struct iommu_domain *old_domain, struct device *dev, struct arm_smmu_ste *ste, - unsigned int s1dss) + unsigned int s1dss, bool ats_always_on) { struct arm_smmu_master *master = dev_iommu_priv_get(dev);
Can we avoid the 'bool' parameter if possible, please? They tend to make the callsites pretty horrible to read and you're already passing the 'struct device *' so you should have the master in hand?
Quoted 51 lines
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +22
-3struct arm_smmu_attach_state state = {@@ -3224,7 +3241,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 @@ -3260,7 +3277,8 @@ static int arm_smmu_attach_dev_identity(struct iommu_domain *domain,arm_smmu_master_clear_vmaster (master);arm_smmu_make_bypass_ste (master->smmu, &ste);arm_smmu_attach_dev_ste (domain, old_domain, dev, &ste, -STRTAB_STE_1_S1DSS_BYPASS ); +STRTAB_STE_1_S1DSS_BYPASS , + master->ats_always_on);return 0 ; }@@ -3283,7 +3301,7 @@ static int arm_smmu_attach_dev_blocked(struct iommu_domain *domain,arm_smmu_master_clear_vmaster (master);arm_smmu_make_abort_ste (&ste);arm_smmu_attach_dev_ste (domain, old_domain, dev, &ste, -STRTAB_STE_1_S1DSS_TERMINATE ); +STRTAB_STE_1_S1DSS_TERMINATE , false);return 0 ; }@@ -3521,6 +3539,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) {
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c static void arm_smmu_remove_master(struct arm_smmu_master *master) · line 3569
Quoted 10 lines
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +10
-0+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;
Were do you allocate the second level entry for ssid 0 if we're using 2-level cd tables?
Will
Re: [PATCH RFCv1 3/3] iommu/arm-smmu-v3: Allow ATS to be always on
Quoted 6 lines · Will Deacon
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c static void arm_smmu_remove_master(struct arm_smmu_master *master) · line 3569
Quoted 3 lines
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +3
-0+ ret =arm_smmu_alloc_cd_tables (master); +if (ret) +return ret;Were do you allocate the second level entry for ssid 0 if we're using 2-level cd tables?
I don't think we need to. The entire design here has a non-valid CD entry for SSID 0.
The spec is really weird here, on one hand it explicitly says that with S1DSS the CD entry is ignored.
On the other hand, you are also required to have a CD table pointer of at least size one for some reason.
So, I think a CD table pointer to a fully invalid L1 table of at least size 1 should be OK?
Or stated another way, why would ie be OK to have a 1 level table with an non-valid CD table entry for SSID0 but not OK to have a 2 level table that returns non-valid at the first walk?
Jason
Re: [PATCH RFCv1 3/3] iommu/arm-smmu-v3: Allow ATS to be always on
Quoted 10 lines · Jason Gunthorpe
Quoted 6 lines · Will Deacon
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c static void arm_smmu_remove_master(struct arm_smmu_master *master) · line 3569
Quoted 3 lines
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +3
-0+ ret =arm_smmu_alloc_cd_tables (master); +if (ret) +return ret;Were do you allocate the second level entry for ssid 0 if we're using 2-level cd tables?
I don't think we need to. The entire design here has a non-valid CD entry for SSID 0.
Hmm, whether we allocate a 2-level cd table would actually depend on the "1 << cd_table->s1cdmax" v.s. CTXDESC_L2_ENTRIES, right?
If the device supports PASID and s1cdmax is large, we should prepare a 2-level cd tables, even if only SSID0 is used at this moment since we have to support !0 pasids via potential SVA domains.
In all Other cases, we would prepare a linear one.
Nicolin
Re: [PATCH RFCv1 3/3] iommu/arm-smmu-v3: Allow ATS to be always on
Quoted 12 lines · Nicolin Chen
Quoted 10 lines · Jason Gunthorpe
Quoted 6 lines · Will Deacon
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c static void arm_smmu_remove_master(struct arm_smmu_master *master) · line 3569
Quoted 3 lines
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +3
-0+ ret =arm_smmu_alloc_cd_tables (master); +if (ret) +return ret;Were do you allocate the second level entry for ssid 0 if we're using 2-level cd tables?
I don't think we need to. The entire design here has a non-valid CD entry for SSID 0.
Quoted 8 lines
Hmm, whether we allocate a 2-level cd table would actually depend on the "1 <<
cd_table->s1cdmax" v.s.CTXDESC_L2_ENTRIES, right?If the device supports PASID and s1cdmax is large, we should prepare a 2-level cd tables, even if only SSID0 is used at this moment since we have to support !0 pasids via potential SVA domains.
In all Other cases, we would prepare a linear one.
Yes, this is what arm_smmu_alloc_cd_tables() is doing.
I think will was questioning if this needs to bearm_smmu_alloc_cd_ptr(master, 0);
To ensure there is some memory under the SSID=0 case, but it seems we don't need that.
Jason
Robin Murphy
reviewerRe: [PATCH RFCv1 3/3] iommu/arm-smmu-v3: Allow ATS to be always on
In reply to Jason GunthorpeQuoted 8 lines · Jason Gunthorpe
Quoted 6 lines · Will Deacon
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c static void arm_smmu_remove_master(struct arm_smmu_master *master) · line 3569
Quoted 3 lines
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +3
-0+ ret =arm_smmu_alloc_cd_tables (master); +if (ret) +return ret;Were do you allocate the second level entry for ssid 0 if we're using 2-level cd tables?
Quoted 8 lines
I don't think we need to. The entire design here has a non-valid CD entry for SSID 0.
The spec is really weird here, on one hand it explicitly says that with S1DSS the CD entry is ignored.
On the other hand, you are also required to have a CD table pointer of at least size one for some reason.
Because it is not possible to enable 0 SubStreams, since that wouldn't make any sense, hence S1CDMax also acts as the "enable SubStreams" control (assuming SSIDSIZE > 0 and it does anything at all - note that strictly we cannot assume this bypass trick is *always* possible, since an SMMU is permitted to support ATS without supporting SubStreams).
Quoted 6 lines
So, I think a CD table pointer to a fully invalid L1 table of at least size 1 should be OK?
Or stated another way, why would ie be OK to have a 1 level table with an non-valid CD table entry for SSID0 but not OK to have a 2 level table that returns non-valid at the first walk?
S1ContextPtr itself is reachable since S1 is enabled, so it cannot point to nonsense. But the S1DSS==Bypass behaviour does state:
"Note: Such a transaction does not fetch a CD, and therefore does not report F_CD_FETCH, C_BAD_CD or a stage 2 Translation-related fault with CLASS == CD."
So if we're not intending to actually allow traffic on the SubStream(s), then it should be fine to use either a 1-level table of invalid CDs, or a 2-level format with an empty L1CD table to gracefully terminate any config prefetches.
Thanks,
Robin.
Re: [PATCH RFCv1 3/3] iommu/arm-smmu-v3: Allow ATS to be always on
Quoted 3 lines · Robin Murphy
(assuming SSIDSIZE > 0 and it does anything at all - note that strictly we cannot assume this bypass trick is *always* possible, since an SMMU is permitted to support ATS without supporting SubStreams).
Yes, I think Nicolin has captured those conditions in computing it... We don't have a logic to disable bypass in that case though.
Quoted 7 lines
Quoted 6 lines
So, I think a CD table pointer to a fully invalid L1 table of at least size 1 should be OK?
Or stated another way, why would ie be OK to have a 1 level table with an non-valid CD table entry for SSID0 but not OK to have a 2 level table that returns non-valid at the first walk?
Quoted 6 lines
S1ContextPtr itself is reachable since S1 is enabled, so it cannot point to nonsense. But the S1DSS==Bypass behaviour does state:
"Note: Such a transaction does not fetch a CD, and therefore does not report
F_CD_FETCH,C_BAD_CDor a stage 2 Translation-related fault with CLASS == CD."
Yes
However, taken together:
* S1CDMax is set to substream 0 only
* S1DSS is set such that "does not fetch a CD" for SSID = 0
* SSID >0 doesn't fetch CDs because of S1CDMax
Then it seems to be saying that it will never use S1ContextPtr? ie it is IGNORED?
Quoted 4 lines
So if we're not intending to actually allow traffic on the SubStream(s), then it should be fine to use either a 1-level table of invalid CDs, or a 2-level format with an empty L1CD table to gracefully terminate any config prefetches.
Yes, so arm_smmu_alloc_cd_tables() is fine since it creates a valid value for S1ContextPtr such that any future use can happen without changing S1ContextPtr.
Jason
Will Deacon
maintainerRe: [PATCH RFCv1 3/3] iommu/arm-smmu-v3: Allow ATS to be always on
Quoted 24 lines · Jason Gunthorpe
Quoted 3 lines · Robin Murphy
(assuming SSIDSIZE > 0 and it does anything at all - note that strictly we cannot assume this bypass trick is *always* possible, since an SMMU is permitted to support ATS without supporting SubStreams).
Yes, I think Nicolin has captured those conditions in computing it... We don't have a logic to disable bypass in that case though.
Quoted 7 lines
Quoted 6 lines
So, I think a CD table pointer to a fully invalid L1 table of at least size 1 should be OK?
Or stated another way, why would ie be OK to have a 1 level table with an non-valid CD table entry for SSID0 but not OK to have a 2 level table that returns non-valid at the first walk?
Quoted 6 lines
S1ContextPtr itself is reachable since S1 is enabled, so it cannot point to nonsense. But the S1DSS==Bypass behaviour does state:
"Note: Such a transaction does not fetch a CD, and therefore does not report
F_CD_FETCH,C_BAD_CDor a stage 2 Translation-related fault with CLASS == CD."Yes
Quoted 7 lines
However, taken together:
* S1CDMax is set to substream 0 only
* S1DSS is set such that "does not fetch a CD" for SSID = 0
* SSID >0 doesn't fetch CDs because of S1CDMaxThen it seems to be saying that it will never use S1ContextPtr? ie it is IGNORED?
Right, I think the critical question is whether that setting of S1DSS (0b01) means that STE.S1ContextPtr is considered "invalid". The spec doesn't call this out explicitly but the "translation procedure charts" seem to indicate that it doesn't use the CD for anything...
It would be good to get some clarification from Arm about this particular case.
Will
Robin Murphy
reviewerRe: [PATCH RFCv1 3/3] iommu/arm-smmu-v3: Allow ATS to be always on
Quoted 33 lines · Will Deacon
Quoted 24 lines · Jason Gunthorpe
Quoted 3 lines · Robin Murphy
(assuming SSIDSIZE > 0 and it does anything at all - note that strictly we cannot assume this bypass trick is *always* possible, since an SMMU is permitted to support ATS without supporting SubStreams).
Yes, I think Nicolin has captured those conditions in computing it... We don't have a logic to disable bypass in that case though.
Quoted 7 lines
Quoted 6 lines
So, I think a CD table pointer to a fully invalid L1 table of at least size 1 should be OK?
Or stated another way, why would ie be OK to have a 1 level table with an non-valid CD table entry for SSID0 but not OK to have a 2 level table that returns non-valid at the first walk?
Quoted 6 lines
S1ContextPtr itself is reachable since S1 is enabled, so it cannot point to nonsense. But the S1DSS==Bypass behaviour does state:
"Note: Such a transaction does not fetch a CD, and therefore does not report
F_CD_FETCH,C_BAD_CDor a stage 2 Translation-related fault with CLASS == CD."Yes
Quoted 7 lines
However, taken together:
* S1CDMax is set to substream 0 only
* S1DSS is set such that "does not fetch a CD" for SSID = 0
* SSID >0 doesn't fetch CDs because of S1CDMaxThen it seems to be saying that it will never use S1ContextPtr? ie it is IGNORED?
Quoted 7 lines
Right, I think the critical question is whether that setting of S1DSS (0b01) means that STE.S1ContextPtr is considered "invalid". The spec doesn't call this out explicitly but the "translation procedure charts" seem to indicate that it doesn't use the CD for anything...
It would be good to get some clarification from Arm about this particular case.
No, STE.S1ContextPtr itself is "valid" since S1 is enabled. No CD fetch will occur for no-SubStreamID transactions that are bypassed by S1DSS, but the SMMU is permitted to attempt to speculatively fetch CDs for the enabled SubStreamID(s). Those fetches do not have to reach a valid CD if the SubStream is not actually in use, much like we don't have to fully populate a 2-level Stream table for StreamID ranges we don't care about either.
Don't confuse S1DSS==1 (bypass) with the S1DSS==2 behaviour we use in other cases - the latter is "Use CD 0 for no-SubstreamID traffic" which makes SubStreamID 0 invalid to use. However in the bypass case (and also S1DSS==0 where no-SubstreamID traffic is blocked entirely), SubStreamID 0 remains perfectly valid and usable (we just still won't ever use it in Linux due to the middle case).
Thanks,
Robin.
Will Deacon
maintainerRe: [PATCH RFCv1 3/3] iommu/arm-smmu-v3: Allow ATS to be always on
Quoted 49 lines · Robin Murphy
Quoted 33 lines · Will Deacon
Quoted 24 lines · Jason Gunthorpe
Quoted 3 lines · Robin Murphy
(assuming SSIDSIZE > 0 and it does anything at all - note that strictly we cannot assume this bypass trick is *always* possible, since an SMMU is permitted to support ATS without supporting SubStreams).
Yes, I think Nicolin has captured those conditions in computing it... We don't have a logic to disable bypass in that case though.
Quoted 7 lines
Quoted 6 lines
So, I think a CD table pointer to a fully invalid L1 table of at least size 1 should be OK?
Or stated another way, why would ie be OK to have a 1 level table with an non-valid CD table entry for SSID0 but not OK to have a 2 level table that returns non-valid at the first walk?
Quoted 6 lines
S1ContextPtr itself is reachable since S1 is enabled, so it cannot point to nonsense. But the S1DSS==Bypass behaviour does state:
"Note: Such a transaction does not fetch a CD, and therefore does not report
F_CD_FETCH,C_BAD_CDor a stage 2 Translation-related fault with CLASS == CD."Yes
Quoted 7 lines
However, taken together:
* S1CDMax is set to substream 0 only
* S1DSS is set such that "does not fetch a CD" for SSID = 0
* SSID >0 doesn't fetch CDs because of S1CDMaxThen it seems to be saying that it will never use S1ContextPtr? ie it is IGNORED?
Quoted 7 lines
Right, I think the critical question is whether that setting of S1DSS (0b01) means that STE.S1ContextPtr is considered "invalid". The spec doesn't call this out explicitly but the "translation procedure charts" seem to indicate that it doesn't use the CD for anything...
It would be good to get some clarification from Arm about this particular case.
No, STE.S1ContextPtr itself is "valid" since S1 is enabled. No CD fetch will occur for no-SubStreamID transactions that are bypassed by S1DSS, but the SMMU is permitted to attempt to speculatively fetch CDs for the enabled SubStreamID(s). Those fetches do not have to reach a valid CD if the SubStream is not actually in use, much like we don't have to fully populate a 2-level Stream table for StreamID ranges we don't care about either.
Quoted 6 lines
Don't confuse S1DSS==1 (bypass) with the S1DSS==2 behaviour we use in other cases - the latter is "Use CD 0 for no-SubstreamID traffic" which makes SubStreamID 0 invalid to use. However in the bypass case (and also S1DSS==0 where no-SubstreamID traffic is blocked entirely), SubStreamID 0 remains perfectly valid and usable (we just still won't ever use it in Linux due to the middle case).
Argh, I had conflated a transaction using SSID 0 vs a transaction without a substream at all. So I think this makes sense now...
Thanks,
Will
Re: [PATCH RFCv1 3/3] iommu/arm-smmu-v3: Allow ATS to be always on
Quoted 2 lines · Will Deacon
Argh, I had conflated a transaction using SSID 0 vs a transaction without a substream at all. So I think this makes sense now...
Yeah, it is bit subtle, but as a SW choice the iommu subsystem reserves PASID 0/SSID 0 as the "untagged" translation.
Several HW's force this in their implementation (ie AMD)
ARM however includes a "Substream Valid" in the input bus. Linux doesn't use the combination "Substream Valid, SSID=0", that should never occur.
If it wrongly does happen then IDENTITY will generate a fault, either C_BAD_CD (due to it being non-valid) or C_BAD_SUBSTREAMID (due to S1CDMax disabling substreams).
While PAGING will either fault with C_BAD_SUBSTREAMID (S2 paging domain) or success when S1DSS=b10.
Jason
Re: [PATCH RFCv1 3/3] iommu/arm-smmu-v3: Allow ATS to be always on
In reply to Will DeaconQuoted 10 lines · Will Deacon
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c void arm_smmu_clear_cd(struct arm_smmu_master *master, ioasid_t ssid) · line 1426
Quoted 7 lines · Nicolin Chen
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +1
-1@@ -1422,7 +1422,7 @@ 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)return ;Should we still warn if !master->ats_always_on?
Hmm, yes. I'll fix this.
Quoted 4 lines
Quoted 4 lines
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +0
-0@@ -3205,7 +3222,7 @@ static void arm_smmu_attach_dev_ste(struct iommu_domain *domain,struct iommu_domain *old_domain, struct device *dev, struct arm_smmu_ste *ste,
Quoted 8 lines
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c static void arm_smmu_attach_dev_ste(struct iommu_domain *domain, · line 3227
Quoted 4 lines
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +1
-1- unsigned int s1dss) + unsigned int s1dss, bool ats_always_on) {struct arm_smmu_master *master =dev_iommu_priv_get (dev);Can we avoid the 'bool' parameter if possible, please? They tend to make the callsites pretty horrible to read and you're already passing the 'struct device *' so you should have the master in hand?
Trying to set ats_always_on=false for blocked domain here:
@@ -3260,7 +3277,8 @@ static int arm_smmu_attach_dev_identity(struct iommu_domain *domain,
arm_smmu_attach_dev_ste(domain, old_domain, dev, &ste, STRTAB_STE_1_S1DSS_BYPASS, master->ats_always_on); @@ -3283,7 +3301,7 @@ static int arm_smmu_attach_dev_blocked(struct iommu_domain *domain, arm_smmu_attach_dev_ste(domain, old_domain, dev, &ste, STRTAB_STE_1_S1DSS_TERMINATE, false);
But I think we could do that by combining master->ats_always_on with the s1dss. I will drop the "bool".
Thanks
Nicolin