[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
<SI2PR01MB4393772BA4AEF5ABF04E8F3FDC90A@SI2PR01MB4393.apcprd01.prod.exchangelabs.com>
Date: Tue, 27 Jan 2026 13:07:51 +0800
From: Wei Wang <wei.w.wang@...mail.com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: bhelgaas@...gle.com, akpm@...ux-foundation.org, bp@...en8.de,
rdunlap@...radead.org, alex@...zbot.org, kevin.tian@...el.com,
linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
Subject: Re: [PATCH v2 2/2] PCI: Add the enhanced ACS controls check to
pci_acs_flags_enabled()
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.
Powered by blists - more mailing lists