From: Gregory Price <gourry@gourry.net>
To: Alison Schofield <alison.schofield@intel.com>
Cc: Robert Richter <rrichter@amd.com>,
Vishal Verma <vishal.l.verma@intel.com>,
Ira Weiny <ira.weiny@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
Jonathan Cameron <jonathan.cameron@huawei.com>,
Dave Jiang <dave.jiang@intel.com>,
Davidlohr Bueso <dave@stgolabs.net>,
linux-cxl@vger.kernel.org, linux-kernel@vger.kernel.org,
"Fabio M. De Francesco" <fabio.m.de.francesco@linux.intel.com>,
Terry Bowman <terry.bowman@amd.com>,
Joshua Hahn <joshua.hahnjy@gmail.com>
Subject: Re: [PATCH v6 00/11] cxl: ACPI PRM Address Translation Support and AMD Zen5 enablement
Date: Mon, 24 Nov 2025 15:10:07 -0500 [thread overview]
Message-ID: <aSS7n40Hmiaf7ibc@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <aSOxXX7xX4jYqqvF@aschofie-mobl2.lan>
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
next prev parent reply other threads:[~2025-11-24 20:10 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-14 0:40 Robert Richter
2025-11-14 0:40 ` [PATCH v6 01/11] cxl/region: Rename misleading variable name @hpa to @hpa_range Robert Richter
2025-11-14 0:40 ` [PATCH v6 02/11] cxl/region: Store root decoder in struct cxl_region Robert Richter
2025-11-14 0:40 ` [PATCH v6 03/11] cxl/region: Store HPA range " Robert Richter
2025-11-14 0:40 ` [PATCH v6 04/11] cxl: Simplify cxl_root_ops allocation and handling Robert Richter
2025-11-14 0:40 ` [PATCH v6 05/11] cxl/region: Separate region parameter setup and region construction Robert Richter
2025-11-14 0:40 ` [PATCH v6 06/11] cxl/region: Add @hpa_range argument to function cxl_calc_interleave_pos() Robert Richter
2025-11-14 0:40 ` [PATCH v6 07/11] cxl/region: Use region data to get the root decoder Robert Richter
2025-11-14 0:40 ` [PATCH v6 08/11] cxl: Introduce callback for HPA address ranges translation Robert Richter
2025-11-14 0:40 ` [PATCH v6 09/11] cxl/acpi: Prepare use of EFI runtime services Robert Richter
2025-11-14 0:40 ` [PATCH v6 10/11] cxl: Enable AMD Zen5 address translation using ACPI PRMT Robert Richter
2025-11-14 0:40 ` [PATCH v6 11/11] cxl/atl: Lock decoders that need address translation Robert Richter
2025-11-14 20:01 ` [PATCH v6 00/11] cxl: ACPI PRM Address Translation Support and AMD Zen5 enablement Alison Schofield
2025-11-17 14:58 ` Robert Richter
2025-11-24 1:14 ` Alison Schofield
2025-11-24 20:10 ` Gregory Price [this message]
2025-11-25 3:26 ` Alison Schofield
2025-11-25 13:54 ` Gregory Price
2025-11-25 16:37 ` Alison Schofield
2025-11-25 21:04 ` Gregory Price
2025-12-04 4:22 ` Alison Schofield
2025-12-05 10:02 ` Robert Richter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aSS7n40Hmiaf7ibc@gourry-fedora-PF4VCD3F \
--to=gourry@gourry.net \
--cc=alison.schofield@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=fabio.m.de.francesco@linux.intel.com \
--cc=ira.weiny@intel.com \
--cc=jonathan.cameron@huawei.com \
--cc=joshua.hahnjy@gmail.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rrichter@amd.com \
--cc=terry.bowman@amd.com \
--cc=vishal.l.verma@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®