[PATCH v2 0/2] PCI: Add support for ACS Enhanced Capability

[PATCH v2 0/2] PCI: Add support for ACS Enhanced Capability

[Wei Wang]

This patchset adds support for the Access Control Services (ACS) Enhanced
Capability, introduced with PCIe Gen 5. The ACS Enhanced Capability
provides additional access control features that improve device isolation
— particularly important in virtualization scenarios where devices are
passed through to different virtual machines (VMs). Strong isolation is
critical to ensure security between devices assigned to different VMs and
the host.

In Linux, device grouping assumes that devices in separate IOMMU groups
are properly isolated. To uphold this assumption, the enhanced ACS
controls are enabled by default on hardware that supports the PCI_ACS_ECAP
capability. As with other basic ACS access controls, these new controls
can be configured via the config_acs= boot parameter.

Support for checking the enhanced ACS controls on Root and Downstream
Ports has been added to pci_acs_enabled(). On devices that support
PCI_ACS_ECAP, these controls must be properly enabled. To maintain
compatibility with legacy devices that lack PCI_ACS_ECAP support,
pci_acs_enabled() skips the check and logs a warning to indicate that
isolation may be incomplete.

v1->v2 changes:
- Enabled all enhanced ACS controls by default, rather than just Unclaimed
  Request Redirect (which addressed the primary issue we encountered).
- Added checks for enhanced ACS controls on Root and Downstream Ports in
  pci_acs_enabled() to ensure proper enablement when grouping devices or
  enabling features such as IOMMU PASID.

Thanks to Jason Gunthorpe for reviewing the patchset.

Wei Wang (2):
  PCI: Enable the enhanced ACS controls introduced by PCI_ACS_ECAP
  PCI: Add the enhanced ACS controls check to pci_acs_flags_enabled()

 .../admin-guide/kernel-parameters.txt         | 23 ++++--
 drivers/pci/pci.c                             | 80 ++++++++++++++++++-
 include/uapi/linux/pci_regs.h                 |  7 ++
 3 files changed, 102 insertions(+), 8 deletions(-)


base-commit: e3b32dcb9f23e3c3927ef3eec6a5842a988fb574
-- 
2.51.0

[PATCH v2 1/2] PCI: Enable the enhanced ACS controls introduced by PCI_ACS_ECAP

[Wei Wang]

The ACS Enhanced Capability introduces several new access controls to
improve device isolation. These new controls are particularly important
for device passthrough in virtualization scenarios.

For example, a DMA transaction from a device may target a guest physical
address that lies within the memory aperture of the switch's upstream
port, but not within any memory aperture or BAR space of a downstream
port. In such cases, the switch would generate an Unsupported Request (UR)
response to the device, which is undesirable. Enabling Unclaimed Request
Redirect Control ensures that these DMA requests are forwarded upstream
instead of being rejected.

The ACS DSP and USP Memory Target Access Control and ACS I/O Request
Blocking features similarly enhance device isolation. Device grouping in
Linux assumes that devices are properly isolated. Therefore, enable these
controls by default if PCI_ACS_ECAP is supported by the hardware. As with
other basic ACS access controls, these new controls can be configured via
the config_acs= boot parameter.

Signed-off-by: Wei Wang <wei.w.wang@hotmail.com>
---
 .../admin-guide/kernel-parameters.txt         | 23 +++++++++++++------
 drivers/pci/pci.c                             | 13 ++++++++++-
 include/uapi/linux/pci_regs.h                 |  7 ++++++
 3 files changed, 35 insertions(+), 8 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 5637bb35cb75..8f99f6d728b9 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5261,13 +5261,22 @@ Kernel parameters
 				flags.
 
 				ACS Flags is defined as follows:
-				  bit-0 : ACS Source Validation
-				  bit-1 : ACS Translation Blocking
-				  bit-2 : ACS P2P Request Redirect
-				  bit-3 : ACS P2P Completion Redirect
-				  bit-4 : ACS Upstream Forwarding
-				  bit-5 : ACS P2P Egress Control
-				  bit-6 : ACS Direct Translated P2P
+				  bit-0     : ACS Source Validation
+				  bit-1     : ACS Translation Blocking
+				  bit-2     : ACS P2P Request Redirect
+				  bit-3     : ACS P2P Completion Redirect
+				  bit-4     : ACS Upstream Forwarding
+				  bit-5     : ACS P2P Egress Control
+				  bit-6     : ACS Direct Translated P2P
+				  bit-7     : ACS I/O Request Blocking
+				  bit-9:8   : ACS DSP Memory Target Access Ctrl
+				      00    : Direct Request access enabled
+				      01    : Request blocking enabled
+				      10    : Request redirect enabled
+				      11    : Reserved
+				  bit-11:10 : ACS USP Memory Target Access Ctrl
+				              Same encoding as bit-9:8
+				  bit-12    : ACS Unclaimed Request Redirect Ctrl
 				Each bit can be marked as:
 				  '0' – force disabled
 				  '1' – force enabled
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 382ce8992387..c4cf835ec8ba 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -948,7 +948,10 @@ static void __pci_config_acs(struct pci_dev *dev, struct pci_acs *caps,
 		}
 
 		if (mask & ~(PCI_ACS_SV | PCI_ACS_TB | PCI_ACS_RR | PCI_ACS_CR |
-			    PCI_ACS_UF | PCI_ACS_EC | PCI_ACS_DT)) {
+			    PCI_ACS_UF | PCI_ACS_EC | PCI_ACS_DT | PCI_ACS_IB |
+			    PCI_ACS_DMAC_RB | PCI_ACS_DMAC_RR |
+			    PCI_ACS_UMAC_RB | PCI_ACS_UMAC_RR |
+			    PCI_ACS_URRC)) {
 			pci_err(dev, "Invalid ACS flags specified\n");
 			return;
 		}
@@ -1008,6 +1011,14 @@ static void pci_std_enable_acs(struct pci_dev *dev, struct pci_acs *caps)
 	/* Upstream Forwarding */
 	caps->ctrl |= (caps->cap & PCI_ACS_UF);
 
+	/*
+	 * Downstream and Upstream Port Memory Target Access Redirect,
+	 * Redirect Unclaimed Request Redirect Control
+	 */
+	if (caps->cap & PCI_ACS_ECAP)
+		caps->ctrl |= PCI_ACS_DMAC_RR | PCI_ACS_UMAC_RR |
+			      PCI_ACS_URRC | PCI_ACS_IB;
+
 	/* Enable Translation Blocking for external devices and noats */
 	if (pci_ats_disabled() || dev->external_facing || dev->untrusted)
 		caps->ctrl |= (caps->cap & PCI_ACS_TB);
diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
index 3add74ae2594..2b026aa91647 100644
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -1011,6 +1011,7 @@
 
 /* Access Control Service */
 #define PCI_ACS_CAP		0x04	/* ACS Capability Register */
+#define  PCI_ACS_ECAP		0x0080  /* ACS Enhanced Capability */
 #define  PCI_ACS_SV		0x0001	/* Source Validation */
 #define  PCI_ACS_TB		0x0002	/* Translation Blocking */
 #define  PCI_ACS_RR		0x0004	/* P2P Request Redirect */
@@ -1018,6 +1019,12 @@
 #define  PCI_ACS_UF		0x0010	/* Upstream Forwarding */
 #define  PCI_ACS_EC		0x0020	/* P2P Egress Control */
 #define  PCI_ACS_DT		0x0040	/* Direct Translated P2P */
+#define  PCI_ACS_IB		0x0080	/* I/O Request Blocking */
+#define  PCI_ACS_DMAC_RB	0x0100  /* DSP Memory Target Access Blocking */
+#define  PCI_ACS_DMAC_RR	0x0200  /* DSP Memory Target Access Redirect */
+#define  PCI_ACS_UMAC_RB	0x0400  /* USP Memory Target Access Blocking */
+#define  PCI_ACS_UMAC_RR	0x0800  /* USP Memory Target Access Redirect */
+#define  PCI_ACS_URRC		0x1000	/* Unclaimed Request Redirect Ctrl */
 #define PCI_ACS_EGRESS_BITS	0x05	/* ACS Egress Control Vector Size */
 #define PCI_ACS_CTRL		0x06	/* ACS Control Register */
 #define PCI_ACS_EGRESS_CTL_V	0x08	/* ACS Egress Control Vector */
-- 
2.51.0

[PATCH v2 2/2] PCI: Add the enhanced ACS controls check to pci_acs_flags_enabled()

[Wei Wang]

The enhanced ACS controls introduced by PCIe Gen 5 ensures better device
isolation. On devices that support the PCI_ACS_ECAP capability, the
controls are required to be enabled properly:
- ACS I/O Request Blocking needs to be enabled to avoid unintended
  upstream I/O requests.
- ACS DSP and USP Memory Target Access Control needs to be set with
  Request Redirect or Request Blocking to ensure the Downstream and
  and Upstream Port memory resource ranges are not accessed by upstream
  memory requests.
- ACS Unclaimed Request Redirect needs to be enabled to ensure accesses to
  areas that lies within a Switch's Upstream Port memory apertures but not
  within any Downstream Port memory apertures get redirected.

To maintain compatibility with legacy devices that lack PCI_ACS_ECAP
support, pci_acs_enabled() skips checking for the capability and logs a
warning to indicate that isolation may be incomplete.

Signed-off-by: Wei Wang <wei.w.wang@hotmail.com>
---
 drivers/pci/pci.c | 67 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 67 insertions(+)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index c4cf835ec8ba..ff974ced90aa 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3527,6 +3527,56 @@ void pci_configure_ari(struct pci_dev *dev)
 	}
 }
 
+static bool pci_dev_has_memory_bars(struct pci_dev *pdev)
+{
+	int i;
+
+	for (i = 0; i <= PCI_ROM_RESOURCE; i++) {
+		if (pci_resource_flags(pdev, i) & IORESOURCE_MEM)
+			return true;
+	}
+
+	return false;
+}
+
+static bool pci_acs_ecap_enabled(struct pci_dev *pdev, u16 ctrl)
+{
+	struct pci_dev *usp_pdev = pci_upstream_bridge(pdev);
+	u16 mask = PCI_ACS_DMAC_RB | PCI_ACS_DMAC_RR;
+
+	/*
+	 * For ACS DSP/USP Memory Target Access Control, either Request
+	 * Redirect or Request Blocking must be enabled to enforce isolation.
+	 * According to PCIe spec 6.2, the DSP Memory Target Access is
+	 * applicable to both Root Ports and Switch Upstream Ports that have
+	 * applicable Memory BAR space to protect. So if the device does not
+	 * have a Memory BAR, it skips the check.
+	 */
+	if (pci_dev_has_memory_bars(pdev) &&
+	    (ctrl & mask) != PCI_ACS_DMAC_RB &&
+	    (ctrl & mask) != PCI_ACS_DMAC_RR)
+		return false;
+
+	mask = PCI_ACS_UMAC_RB | PCI_ACS_UMAC_RR;
+	/*
+	 * The USP Memory Target Access is only applicable to downstream ports
+	 * that have applicable Memory BAR space in the Switch Upstream Port to
+	 * protect. Root Ports, which have usp_pdev set to NULL, will skip the
+	 * check.
+	 */
+	if (usp_pdev && pci_dev_has_memory_bars(usp_pdev) &&
+	    (ctrl & mask) != PCI_ACS_UMAC_RB &&
+	    (ctrl & mask) != PCI_ACS_UMAC_RR)
+		return false;
+
+	/* PCI_ACS_URRC is applicable to Downstream Ports only.  */
+	if (usp_pdev && !(ctrl & PCI_ACS_URRC))
+		return false;
+
+	/* PCI_ACS_IB is applicable to both Root and Downstream Ports. */
+	return !!(ctrl & PCI_ACS_IB);
+}
+
 static bool pci_acs_flags_enabled(struct pci_dev *pdev, u16 acs_flags)
 {
 	int pos;
@@ -3545,6 +3595,21 @@ static bool pci_acs_flags_enabled(struct pci_dev *pdev, u16 acs_flags)
 	acs_flags &= (cap | PCI_ACS_EC);
 
 	pci_read_config_word(pdev, pos + PCI_ACS_CTRL, &ctrl);
+
+	if (acs_flags & PCI_ACS_ECAP) {
+		if (!(cap & PCI_ACS_ECAP))
+			pci_warn(pdev, "device doesn't support ACS_ECAP\n");
+		else if (!pci_acs_ecap_enabled(pdev, ctrl))
+			return false;
+
+		/*
+		 * The check for the required controls in PCI_ACS_ECAP has
+		 * passed. Clear the ECAP flag and continue to check the
+		 * basic ACS controls.
+		 */
+		acs_flags &= ~PCI_ACS_ECAP;
+	}
+
 	return (ctrl & acs_flags) == acs_flags;
 }
 
@@ -3603,6 +3668,8 @@ bool pci_acs_enabled(struct pci_dev *pdev, u16 acs_flags)
 	 */
 	case PCI_EXP_TYPE_DOWNSTREAM:
 	case PCI_EXP_TYPE_ROOT_PORT:
+		/* PCI_ACS_ECAP applies to Root and Downstream ports only */
+		acs_flags |= PCI_ACS_ECAP;
 		return pci_acs_flags_enabled(pdev, acs_flags);
 	/*
 	 * PCIe 3.0, 6.12.1.2 specifies ACS capabilities that should be
-- 
2.51.0

Re: [PATCH v2 2/2] PCI: Add the enhanced ACS controls check to pci_acs_flags_enabled()

[Jason Gunthorpe]

On Fri, Jan 23, 2026 at 09:49:43AM +0800, Wei Wang wrote:
> The enhanced ACS controls introduced by PCIe Gen 5 ensures better device
> isolation. On devices that support the PCI_ACS_ECAP capability, the
> controls are required to be enabled properly:
> - ACS I/O Request Blocking needs to be enabled to avoid unintended
>   upstream I/O requests.
> - ACS DSP and USP Memory Target Access Control needs to be set with
>   Request Redirect or Request Blocking to ensure the Downstream and
>   and Upstream Port memory resource ranges are not accessed by upstream
>   memory requests.
> - ACS Unclaimed Request Redirect needs to be enabled to ensure accesses to
>   areas that lies within a Switch's Upstream Port memory apertures but not
>   within any Downstream Port memory apertures get redirected.
> 
> To maintain compatibility with legacy devices that lack PCI_ACS_ECAP
> support, pci_acs_enabled() skips checking for the capability and logs a
> warning to indicate that isolation may be incomplete.

That's every existing system, please don't do that.

The issue with ECAP is the way PCI SIG re-defined what Linux has been
doing forever as unsafe.

Jason

> 
> Signed-off-by: Wei Wang <wei.w.wang@hotmail.com>
> ---
>  drivers/pci/pci.c | 67 +++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 67 insertions(+)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index c4cf835ec8ba..ff974ced90aa 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3527,6 +3527,56 @@ void pci_configure_ari(struct pci_dev *dev)
>  	}
>  }
>  
> +static bool pci_dev_has_memory_bars(struct pci_dev *pdev)
> +{
> +	int i;
> +
> +	for (i = 0; i <= PCI_ROM_RESOURCE; i++) {
> +		if (pci_resource_flags(pdev, i) & IORESOURCE_MEM)
> +			return true;
> +	}
> +
> +	return false;
> +}
> +
> +static bool pci_acs_ecap_enabled(struct pci_dev *pdev, u16 ctrl)
> +{
> +	struct pci_dev *usp_pdev = pci_upstream_bridge(pdev);
> +	u16 mask = PCI_ACS_DMAC_RB | PCI_ACS_DMAC_RR;
> +
> +	/*
> +	 * For ACS DSP/USP Memory Target Access Control, either Request
> +	 * Redirect or Request Blocking must be enabled to enforce isolation.
> +	 * According to PCIe spec 6.2, the DSP Memory Target Access is
> +	 * applicable to both Root Ports and Switch Upstream Ports that have
> +	 * applicable Memory BAR space to protect. So if the device does not
> +	 * have a Memory BAR, it skips the check.
> +	 */

This doesn't make sense, the special cases PCI sig clarified only have
to do with switches that have MMIO on their USP/DSP and a case where
the DSP aperture isn't covered by all the USPs.

These tests shouldn't be done outside a usp/dsp context.

You can look at what I drafted earlier here:

https://lore.kernel.org/all/0-v3-8827cc7fc4e0+23f-pcie_switch_groups_jgg@nvidia.com/

Jason

Re: [PATCH v2 2/2] PCI: Add the enhanced ACS controls check to pci_acs_flags_enabled()

[Wei Wang]

On 1/23/26 10:51 PM, Jason Gunthorpe wrote:
> On Fri, Jan 23, 2026 at 09:49:43AM +0800, Wei Wang wrote:
>> The enhanced ACS controls introduced by PCIe Gen 5 ensures better device
>> isolation. On devices that support the PCI_ACS_ECAP capability, the
>> controls are required to be enabled properly:
>> - ACS I/O Request Blocking needs to be enabled to avoid unintended
>>    upstream I/O requests.
>> - ACS DSP and USP Memory Target Access Control needs to be set with
>>    Request Redirect or Request Blocking to ensure the Downstream and
>>    and Upstream Port memory resource ranges are not accessed by upstream
>>    memory requests.
>> - ACS Unclaimed Request Redirect needs to be enabled to ensure accesses to
>>    areas that lies within a Switch's Upstream Port memory apertures but not
>>    within any Downstream Port memory apertures get redirected.
>>
>> To maintain compatibility with legacy devices that lack PCI_ACS_ECAP
>> support, pci_acs_enabled() skips checking for the capability and logs a
>> warning to indicate that isolation may be incomplete.
> 
> That's every existing system, please don't do that.
> 
> The issue with ECAP is the way PCI SIG re-defined what Linux has been
> doing forever as unsafe.

My viewpoint is that there are known bugs with the legacy ACS defined in 
PCIe Gen 4, and PCIe Gen 5 attempts to address them through new controls 
in the Enhanced Capability (ECAP). From the Linux perspective, we just 
need to adapt accordingly to ensure 'better' isolation.

That's why I was considering adding a warning log to inform users that 
these legacy bugs may still be present. In practice, these issues 
primarily affect virtual machine scenarios. The host kernel isn't 
impacted as the USP/DSP holes and MMIOs are marked as reserved regions, 
which are skipped during IOVA allocation.

The warning is intended to raise awareness for users, so they can make 
informed decisions about continuing with this setup.

> 
> Jason
> 
>>
>> Signed-off-by: Wei Wang <wei.w.wang@hotmail.com>
>> ---
>>   drivers/pci/pci.c | 67 +++++++++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 67 insertions(+)
>>
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index c4cf835ec8ba..ff974ced90aa 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -3527,6 +3527,56 @@ void pci_configure_ari(struct pci_dev *dev)
>>   	}
>>   }
>>   
>> +static bool pci_dev_has_memory_bars(struct pci_dev *pdev)
>> +{
>> +	int i;
>> +
>> +	for (i = 0; i <= PCI_ROM_RESOURCE; i++) {
>> +		if (pci_resource_flags(pdev, i) & IORESOURCE_MEM)
>> +			return true;
>> +	}
>> +
>> +	return false;
>> +}
>> +
>> +static bool pci_acs_ecap_enabled(struct pci_dev *pdev, u16 ctrl)
>> +{
>> +	struct pci_dev *usp_pdev = pci_upstream_bridge(pdev);
>> +	u16 mask = PCI_ACS_DMAC_RB | PCI_ACS_DMAC_RR;
>> +
>> +	/*
>> +	 * For ACS DSP/USP Memory Target Access Control, either Request
>> +	 * Redirect or Request Blocking must be enabled to enforce isolation.
>> +	 * According to PCIe spec 6.2, the DSP Memory Target Access is
>> +	 * applicable to both Root Ports and Switch Upstream Ports that have
>> +	 * applicable Memory BAR space to protect. So if the device does not
>> +	 * have a Memory BAR, it skips the check.
>> +	 */
> 
> This doesn't make sense, the special cases PCI sig clarified only have
> to do with switches that have MMIO on their USP/DSP and a case where
> the DSP aperture isn't covered by all the USPs.
> 

Do you have a link to the clarification from PCI sig?

In PCIe Spec 7.0, the ACS DSP Memory Target Access Control field is 
still explicitly required for Root Ports and Switch Downstream Ports 
when the ACS Enhanced Capability bit is set

For USP Memory Target Access Control, the spec does not list Root Ports 
as requiring this field.

> These tests shouldn't be done outside a usp/dsp context.

It might not be difficult to tweak the implementation for this (just 
skip Root Port in the check).
(Curious to read the clarification from PCI sig first)

> 
> You can look at what I drafted earlier here:
> 
> https://lore.kernel.org/all/0-v3-8827cc7fc4e0+23f-pcie_switch_groups_jgg@nvidia.com/

IIUC the implementation also applied the DSP Memory Target Access 
Control check to the Root Port?

Re: [PATCH v2 2/2] PCI: Add the enhanced ACS controls check to pci_acs_flags_enabled()

[Jason Gunthorpe]

On Mon, Jan 26, 2026 at 05:10:18PM +0800, Wei Wang wrote:
> On 1/23/26 10:51 PM, Jason Gunthorpe wrote:
> > On Fri, Jan 23, 2026 at 09:49:43AM +0800, Wei Wang wrote:
> > > The enhanced ACS controls introduced by PCIe Gen 5 ensures better device
> > > isolation. On devices that support the PCI_ACS_ECAP capability, the
> > > controls are required to be enabled properly:
> > > - ACS I/O Request Blocking needs to be enabled to avoid unintended
> > >    upstream I/O requests.
> > > - ACS DSP and USP Memory Target Access Control needs to be set with
> > >    Request Redirect or Request Blocking to ensure the Downstream and
> > >    and Upstream Port memory resource ranges are not accessed by upstream
> > >    memory requests.
> > > - ACS Unclaimed Request Redirect needs to be enabled to ensure accesses to
> > >    areas that lies within a Switch's Upstream Port memory apertures but not
> > >    within any Downstream Port memory apertures get redirected.
> > > 
> > > To maintain compatibility with legacy devices that lack PCI_ACS_ECAP
> > > support, pci_acs_enabled() skips checking for the capability and logs a
> > > warning to indicate that isolation may be incomplete.
> > 
> > That's every existing system, please don't do that.
> > 
> > The issue with ECAP is the way PCI SIG re-defined what Linux has been
> > doing forever as unsafe.
> 
> My viewpoint is that there are known bugs with the legacy ACS defined in
> PCIe Gen 4, and PCIe Gen 5 attempts to address them through new controls in
> the Enhanced Capability (ECAP). From the Linux perspective, we just need to
> adapt accordingly to ensure 'better' isolation.

No, there are not "bugs", there is a gap where a very rare and narrow
HW configuration was not specified. The vast majority of systems don't
even hit this gap, and when they do switches that are safe and secure
to use with Linux do the right thing..

> The warning is intended to raise awareness for users, so they can make
> informed decisions about continuing with this setup.

Then print warnings only in known bad cases by detecting the holes and
evaluating the quirks database if the device malfunctions. That's
hard, so I would just skip the print..

Jason

Re: [PATCH v2 2/2] PCI: Add the enhanced ACS controls check to pci_acs_flags_enabled()

[Wei Wang]

On 1/27/26 2:01 AM, Jason Gunthorpe wrote:
> On Mon, Jan 26, 2026 at 05:10:18PM +0800, Wei Wang wrote:
>> On 1/23/26 10:51 PM, Jason Gunthorpe wrote:
>>> On Fri, Jan 23, 2026 at 09:49:43AM +0800, Wei Wang wrote:
>>>> The enhanced ACS controls introduced by PCIe Gen 5 ensures better device
>>>> isolation. On devices that support the PCI_ACS_ECAP capability, the
>>>> controls are required to be enabled properly:
>>>> - ACS I/O Request Blocking needs to be enabled to avoid unintended
>>>>     upstream I/O requests.
>>>> - ACS DSP and USP Memory Target Access Control needs to be set with
>>>>     Request Redirect or Request Blocking to ensure the Downstream and
>>>>     and Upstream Port memory resource ranges are not accessed by upstream
>>>>     memory requests.
>>>> - ACS Unclaimed Request Redirect needs to be enabled to ensure accesses to
>>>>     areas that lies within a Switch's Upstream Port memory apertures but not
>>>>     within any Downstream Port memory apertures get redirected.
>>>>
>>>> To maintain compatibility with legacy devices that lack PCI_ACS_ECAP
>>>> support, pci_acs_enabled() skips checking for the capability and logs a
>>>> warning to indicate that isolation may be incomplete.
>>>
>>> That's every existing system, please don't do that.
>>>
>>> The issue with ECAP is the way PCI SIG re-defined what Linux has been
>>> doing forever as unsafe.
>>
>> My viewpoint is that there are known bugs with the legacy ACS defined in
>> PCIe Gen 4, and PCIe Gen 5 attempts to address them through new controls in
>> the Enhanced Capability (ECAP). From the Linux perspective, we just need to
>> adapt accordingly to ensure 'better' isolation.
> 
> No, there are not "bugs", there is a gap where a very rare and narrow
> HW configuration was not specified. The vast majority of systems don't
> even hit this gap, and when they do switches that are safe and secure
> to use with Linux do the right thing..
> 
>> The warning is intended to raise awareness for users, so they can make
>> informed decisions about continuing with this setup.
> 
> Then print warnings only in known bad cases by detecting the holes and
> evaluating the quirks database if the device malfunctions. That's
> hard, so I would just skip the print..

OK, I'll drop the warning.