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: <aSUh-9fXFGsK_Z1_@aschofie-mobl2.lan>
Date: Mon, 24 Nov 2025 19:26:51 -0800
From: Alison Schofield <alison.schofield@...el.com>
To: Gregory Price <gourry@...rry.net>
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 Mon, Nov 24, 2025 at 03:10:07PM -0500, Gregory Price wrote:
> 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.

The hpa_to_spa fn defined as a root decoder ops is an additional layer for
arch's needing HPA to SPA translation. It's optional. If there is no
hpa_to_spa fn, then it is assumed that the CXL HPA==SPA and that is the
'final answer'  added to the trace log.

Sounds like you are on one of these systems, so maybe you could take a
look at what happens. If your devices support, try to inject and/or
clear poison and see the resulting kernel trace log. There is an
example for that here:
https://github.com/pmem/ndctl/blob/main/test/cxl-poison.sh

-- Alison

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