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: <69790b8ff40bd_1d6f100c5@dwillia2-mobl4.notmuch>
Date: Tue, 27 Jan 2026 11:01:36 -0800
From: <dan.j.williams@...el.com>
To: Robert Richter <rrichter@....com>, Alison Schofield
	<alison.schofield@...el.com>, Vishal Verma <vishal.l.verma@...el.com>, "Ira
 Weiny" <ira.weiny@...el.com>, Dan Williams <dan.j.williams@...el.com>,
	Jonathan Cameron <jonathan.cameron@...wei.com>, Dave Jiang
	<dave.jiang@...el.com>, Davidlohr Bueso <dave@...olabs.net>, Jonathan Corbet
	<corbet@....net>
CC: <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>, Robert Richter <rrichter@....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:
> 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>

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