linux-kernel - Re: [PATCH v4 3/3] Documentation/driver-api/cxl: ACPI PRM Address Translation Support and AMD Zen5 enablement

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: <697a6236185dd_3095100d2@dwillia2-mobl4.notmuch>
Date: Wed, 28 Jan 2026 11:23:34 -0800
From: <dan.j.williams@...el.com>
To: Robert Richter <rrichter@....com>, <dan.j.williams@...el.com>
CC: Alison Schofield <alison.schofield@...el.com>, Vishal Verma
	<vishal.l.verma@...el.com>, Ira Weiny <ira.weiny@...el.com>, Jonathan Cameron
	<jonathan.cameron@...wei.com>, Dave Jiang <dave.jiang@...el.com>, "Davidlohr
 Bueso" <dave@...olabs.net>, Jonathan Corbet <corbet@....net>,
	<linux-cxl@...r.kernel.org>, <linux-kernel@...r.kernel.org>, Gregory Price
	<gourry@...rry.net>, "Fabio M. De Francesco"
	<fabio.m.de.francesco@...ux.intel.com>, Terry Bowman <terry.bowman@....com>,
	Joshua Hahn <joshua.hahnjy@...il.com>, <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v4 3/3] Documentation/driver-api/cxl: ACPI PRM Address
 Translation Support and AMD Zen5 enablement

Robert Richter wrote:
[..]
> the Zen5 machines only use the PRM method as described. They have been
> out for more than a year now with stable firmware. Moving to _DSM
> would require a new firmware release and force all of them to run a
> firmware update.

Ok, so then do not document _DSM as an option in the convention
document. Only document what has been shipped and require anything that
follows to not deviate from that de facto "standard".

I was confused by this convention document offering optionality (direct
PRM or _DSM) and then requiring that the kernel accommodate the less
preferred option (direct PRM). If there are no plans for the only
existing implementation in the ecosystem to support _DSM then simply
require direct PRM forevermore.

> > ...and for the implementation can you update it to only invoke a _DSM
> > and hide the fact that it might be implemented by PRM on the backend?
> 
> Additionally, a kernel implementation change is needed including
> another test and review cycle. As you described, the implementation on
> the BIOS side would probably be a _DSM wrapper in AML added to the
> SSDT that calls the actual PRM handler. An alternative is an ACPI
> quirk injecting that as AML code, but that makes things worse. IMO,
> all this is not worth the effort just to define the interface as _DSM
> only, and then use a wrapper to call it. Plus, there will probably be
> no platforms that adopt this.
> 
> I really would like to see PRM and _DSM coexist in the spec to avoid
> all that. We could restrict the PRM GUID to the one currently used to
> avoid other PRM handlers coming up (if platforms adopt this at all).
> Please consider that.

No, please no coexistence of alternatives. Direct PRM is shipping, catch
Linux up with this singular reality, close the door on future changes in
this space.

If there is ever a "next time" for a different platform concept,
strongly prefer a static table + native driver enabling approach.