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: <aXs0jW3dK6IwtXwZ@rric.localdomain>
Date: Thu, 29 Jan 2026 11:21:01 +0100
From: Robert Richter <rrichter@....com>
To: 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

On 28.01.26 11:23:34, dan.j.williams@...el.com wrote:
> 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".

Ok, thanks, will update the documentation.

> 
> 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.

Oh, I thought you were aware of the existing PRM implementation and
then wanted me to specify _DSM in the spec, so I started with that.

> 
> > > ...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.

Understood.

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

The translation algorithms are not trivial, see around AMD_ATL and in
drivers/ras/amd/atl/. For CXL, PCIe comes into play in addition to
handle that.

Anyway, thanks for your quick response. Will send a v5.

-Robert