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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aXoJPP00R7qblx-o@rric.localdomain>
Date: Wed, 28 Jan 2026 14:03:57 +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

Dan,

On 27.01.26 11:01:36, dan.j.williams@...el.com wrote:
> Robert Richter wrote:
> > This adds a convention document for the following patch series:
> > 
> >  cxl: ACPI PRM Address Translation Support and AMD Zen5 enablement
> > 
> > Version 7 and later:
> > 
> >  https://lore.kernel.org/linux-cxl/20251114213931.30754-1-rrichter@amd.com/
> > 
> > Link: https://lore.kernel.org/linux-cxl/20251114213931.30754-1-rrichter@amd.com/
> > Reviewed-by: Gregory Price <gourry@...rry.net>
> > Reviewed-by: Dave Jiang <dave.jiang@...el.com>
> > Reviewed-by: Alison Schofield <alison.schofield@...el.com>
> > Reviewed-by: Jonathan Cameron <jonathan.cameron@...wei.com>
> > Acked-by: Dan Williams <dan.j.williams@...el.com>
> > Signed-off-by: Robert Richter <rrichter@....com>
> > ---
> [..]
> > +Detailed Description of the Change
> > +----------------------------------
> > +
> > +The following describes the necessary changes to the *CXL 3.2 specification*
> > +[#cxl-spec-3.2]_:
> > +
> > +Add the following paragraph to the end of the section:
> > +
> > +**8.2.4.20 CXL HDM Decoder Capability Structure**
> > +
> > +"A device may use an HPA space that is not common to other components of the
> > +host domain. The platform is responsible for address translation when crossing
> > +HPA spaces. The Operating System must determine the interleaving configuration
> > +and perform address translation to the HPA ranges of the HDM decoders as
> > +needed. The translation mechanism is host-specific and implementation dependent.
> > +
> > +The platform may provide an interface that can be used by the Operating System
> > +to translate a DPA and determine its corresponding SPA, such as a Platform
> > +Runtime Mechanism (PRM) handler or a Device-Specific Method (_DSM).
> 
> Optionality is not a standard. Linux does not want to consider different
> vendors making different choices. One mechanism per concept is the
> expectation.
> 
> In this case PRM is an implementation detail behind a _DSM calling
> convention. I would much prefer if this implementation did not directly
> invoke a PRM handler and was instead always fronted by a _DSM. For
> example, one way to avoid the pains of PRM would be to implement it as an
> AML method. That is not possible if Linux is directly invoking PRM.
> 
> With the change to drop the mention of PRM and just document the _DSM
> protocol you can add:
> 
> Reviewed-by: Dan Williams <dan.j.williams@...el.com>

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.

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

Thanks,

-Robert