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

[Jason Gunthorpe <jgg@nvidia.com>]

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