linux-kernel - Re: [PATCH V3 1/2] PCI/ASPM: Add host-bridge API to override default ASPM/CLKPM link state

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <2fo64esrc5v5vj46iff2ptgcthaeahwicuzug46popwqrryfsi@yt62sqsnv4e3>
Date: Sun, 31 Aug 2025 18:28:53 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: "David E. Box" <david.e.box@...ux.intel.com>, rafael@...nel.org, 
	bhelgaas@...gle.com, vicamo.yang@...onical.com, kenny@...ix.com, 
	ilpo.jarvinen@...ux.intel.com, nirmal.patel@...ux.intel.com, linux-pm@...r.kernel.org, 
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V3 1/2] PCI/ASPM: Add host-bridge API to override default
 ASPM/CLKPM link state

On Thu, Aug 28, 2025 at 03:43:45PM GMT, Bjorn Helgaas wrote:
> On Mon, Aug 25, 2025 at 01:35:22PM -0700, David E. Box wrote:
> > Synthetic PCIe hierarchies, such as those created by Intel VMD, are not
> > enumerated by firmware and do not receive BIOS-provided ASPM or CLKPM
> > defaults. Devices in such domains may therefore run without the intended
> > power management.
> > 
> > Add a host-bridge mechanism that lets controller drivers supply their own
> > defaults. A new aspm_default_link_state field in struct pci_host_bridge is
> > set via pci_host_set_default_pcie_link_state(). During link initialization,
> > if this field is non-zero, ASPM and CLKPM defaults come from it instead of
> > BIOS.
> > 
> > This enables drivers like VMD to align link power management with platform
> > expectations and avoids embedding controller-specific quirks in ASPM core
> > logic.
> 
> I think this kind of sidesteps the real issue.  Drivers for host
> controllers or PCI devices should tell us about *broken* things, but
> not about things advertised by the hardware and available for use.
> 
> The only documented policy controls I'm aware of for ASPM are:
> 
>   - FADT "PCIe ASPM Controls" bit ("if set, OS must not enable ASPM
>     control on this platform")
> 
>   - _OSC negotiation for control of the PCIe Capability (OS is only
>     allowed to write PCI_EXP_LNKCTL if platform has granted control to
>     the OS)
> 
> I think what we *should* be doing is enabling ASPM when it's
> advertised, subject to those platform policy controls and user choices
> like CONFIG_PCIEASPM_PERFORMANCE/POWERSAVE/etc and sysfs attributes.
> 
> So basically I think link->aspm_default should be PCIE_LINK_STATE_ALL
> without drivers doing anything at all.  Maybe we have to carve out
> exceptions, e.g., "VMD hierarchies are exempt from _OSC," or "devices
> on x86 systems before 2026 can't enable more ASPM than BIOS did," or
> whatever.  Is there any baby step we can make in that direction?
> 

I'm not sure about the ACPI world, but for devicetree platforms, BIOS or the
bootloader won't configure ASPM for the devices (mostly). So the baby step would
be to set PCIE_LINK_STATE_ALL for all devicetree platforms :)

We did similar thing for enabling D3Hot for bridges earlier:
a5fb3ff63287 ("PCI: Allow PCI bridges to go to D3Hot on all non-x86")

- Mani

-- 
மணிவண்ணன் சதாசிவம்