linux-kernel - Re: [PATCH v6 00/11] 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: <aSS7n40Hmiaf7ibc@gourry-fedora-PF4VCD3F>
Date: Mon, 24 Nov 2025 15:10:07 -0500
From: Gregory Price <gourry@...rry.net>
To: Alison Schofield <alison.schofield@...el.com>
Cc: Robert Richter <rrichter@....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>, linux-cxl@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	"Fabio M. De Francesco" <fabio.m.de.francesco@...ux.intel.com>,
	Terry Bowman <terry.bowman@....com>,
	Joshua Hahn <joshua.hahnjy@...il.com>
Subject: Re: [PATCH v6 00/11] cxl: ACPI PRM Address Translation Support and
 AMD Zen5 enablement

On Sun, Nov 23, 2025 at 05:14:05PM -0800, Alison Schofield wrote:
> On Mon, Nov 17, 2025 at 03:58:40PM +0100, Robert Richter wrote:
> > On 14.11.25 12:01:29, Alison Schofield wrote:
> > 
> > > Does this work 'as is', no changes required, to support DPA->SPA
> > > (used in CXL Events) or SPA->DPA (used in poison by region offset)?
> > 
> > The PRM handler could be used for to-SPA translations, but it might
> > not fit well to other users such as profiling, tracing and error
> > handling. Those users are executing in a critical path from a
> > performance or stability point of view. Performing a firmware call
> > could cause problems here. Since the to-DPA translation is missing
> > too, a different approach to solve address translation might work
> > better, such as examining the region parameters. The kernel's address
> > translation library could possibly be extended and used too. That
> > needs to be figured out. Also, my main focus for the patches is region
> > enablement.
> 
> If address translations are not supported/supportable, a quick exit
> on any attempt (DPA->SPA or SPA->DPA) with this config seems needed. 
>
> Better to fail and report ULLONG_MAX than leave open the possibility
> of adding the wrong address to trace events or using the wrong address
> in poison by region offset action.
> 
> Maybe you already know that it fails gracefully? If so, then it comes
> down to documenting the limitation.
>


IIRC the to_spa() function wouldn't be populated (will be NULL) if this
is the case, so you wouldn't even be able to call the translation
function.

This was hit in a prior version of the set where I saw it fail on a
system using System Address mode instead of Normalized Address mode.

~Gregory