linux-kernel - [PATCH v2 0/1] Re: [PATCH] drivers/pci: Allow attaching AER to non-RP devices that support MSI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251208112545.21315-1-darnshah@amazon.de>
Date: Mon, 8 Dec 2025 11:25:44 +0000
From: Darshit Shah <darnshah@...zon.de>
To: <lukas@...ner.de>
CC: <Jonthan.Cameron@...wei.com>, <bhelgaas@...gle.com>, <darnir@....org>,
	<darnshah@...zon.de>, <feng.tang@...ux.alibaba.com>,
	<kwilczynski@...nel.org>, <linux-kernel@...r.kernel.org>,
	<linux-pci@...r.kernel.org>, <nh-open-source@...zon.com>,
	<sathyanarayanan.kuppuswamy@...ux.intel.com>
Subject: [PATCH v2 0/1] Re: [PATCH] drivers/pci: Allow attaching AER to non-RP devices that support MSI

On 28.11.25 18:07, Lukas Wunner wrote:
> On Fri, Nov 28, 2025 at 12:20:53PM +0000, Darshit Shah wrote:
>> Previously portdrv tried to prevent non-Root Port (RP) and non-Root
>> Complex Event Collector (RCEC) devices from enabling AER capability.
>> This was done because some switches enable AER but do not support MSI.
> 
> The AER driver only binds to RPs and RCECs, see aer_probe():
> 
> 	if ((pci_pcie_type(port) != PCI_EXP_TYPE_RC_EC) &&
> 	    (pci_pcie_type(port) != PCI_EXP_TYPE_ROOT_PORT))
> 		return -ENODEV;
> 
> So there's no point in adding PCIE_PORT_SERVICE_AER to "services"
> for other port types (as your patch does).

I agree that adding PCIE_PORT_SERVICE_AER to "services" for switches is
not useful.

> 
>> However, it is possible to have switches upstream of an endpoint that
>> support MSI and AER. Without AER capability being enabled on such
>> a switch, portdrv will refuse to enable the DPC capability as well,
>> preventing a PCIe error on an endpoint from being handled by the switch.
> 
> I assume you're referring to this clause in get_port_device_capability():
> 
> 	if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
> 	    pci_aer_available() &&
> 	    (pcie_ports_dpc_native || (services & PCIE_PORT_SERVICE_AER)))
> 		services |= PCIE_PORT_SERVICE_DPC;
> 
> Presumably on your system, BIOS doesn't grant AER handling to the OS
> upon _OSC negotiation?  Is there a BIOS knob to change that?

On my system, BIOS does grant AER handling to the OS with _OSC negotiation.

2025-12-06 23:15:40.172000 kern INFO [    0.590601] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
2025-12-06 23:15:40.172000 kern INFO [    0.590607] acpi PNP0A08:00: _OSC: platform does not support [LTR]
2025-12-06 23:15:40.172000 kern INFO [    0.590610] acpi PNP0A08:00: _OSC: OS now controls [PME AER PCIeCapability]

> Alternatively, does passing "pcie_ports=dpc-native" fix the issue?
> If it does, why do you need the patch instead of using the command line
> option?

Given that my firmware correctly negotiates and hands over control of AER
to Linux, we should not need to use a quirk to enable DPC support.

What seems to be happening instead is that portdrv has misinterpreted the
Implementation Note in PCIe r5.0 6.2.10 that states:
  "It is recommended that platform firmware and operating systems always link
  the control of DPC to the control of Advanced Error Reporting"

This does not mean that AER is working on each PCIe device that wants to enable
DPC. Rather that the OS is considered to have control over DPC, if it also has
control over AER for the host bridge upstream of the device.

Thus, I claim that the following checks are incorrect:

	if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
	    pci_aer_available() &&
	    (pcie_ports_dpc_native || (services & PCIE_PORT_SERVICE_AER)))
		services |= PCIE_PORT_SERVICE_DPC;

PCIE_PORT_SERVICE_AER will only ever be enabled on RP and RCEC devices.
However, PCIE_PORT_SERVICE_DPC should be allowed on non-RP devices. In fact,
that is exactly where it is needed, since the switch upstream of an endpoint
device is required to generate the DPC signal. A fixed version of this check
would instead look like:

	if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) &&
	    pci_aer_available() &&
	    (pcie_ports_dpc_native || host->native_aer)
		services |= PCIE_PORT_SERVICE_DPC;

That is, we should allow binding PCIE_PORT_SERVICE_DPC to a device, if:

* The device advertises the DPC capability
* AER has not been disabled for Linux through the command line
* Linux has control of AER (and DPC) for the host bridge above the device
  * _OR_ `pcie_ports=dpc-native` was used on the command line

Coming next is an updated patch based on this.

-- 
2.47.3




Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Christof Hellmis
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597