[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251215132540.00000f1b@huawei.com>
Date: Mon, 15 Dec 2025 13:25:40 +0000
From: Jonathan Cameron <jonathan.cameron@...wei.com>
To: Robert Richter <rrichter@....com>
CC: 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>, Dave Jiang <dave.jiang@...el.com>, "Davidlohr
Bueso" <dave@...olabs.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>
Subject: Re: [PATCH v8 13/13] cxl: Disable HPA/SPA translation handlers for
Normalized addressing
On Tue, 9 Dec 2025 19:06:49 +0100
Robert Richter <rrichter@....com> wrote:
> The root decoder implements callbacks hpa_to_spa and spa_to_hpa to
> perform Host Physical Address (HPA) and System Physical Address
> translations respectively. The callbacks are needed in cases where HPA
> != SPA to convert addresses for tracing and error handling and to
> setup Poison injection. Currently this is used for XOR interleaving.
>
> In AMD Zen5 systems with Normalized addressing, the addresses of
> endpoints are not SPA and those callbacks need to be implemented.
>
> Now, as ACPI PRM translation could be expensive in tracing or error
> handling code paths, do not yet enable this direction of translation
> (hpa_to_spa) to avoid its intensive use. Instead, mark the HPA invalid
> and return an error for this case.
>
> The spa_to_hpa callback will be used in region_offset_to_dpa_result()
> to determine the endpoint by the position in the interleaving
> chunk. With Normalized addressing, the order of endpoints in the
> interleaving chunk is implementation defined. Do not use this approach
> and and return an error instead.
>
> Disable both HPA/SPA translation handlers for Normalized addressing by
> returning an error (ULLONG_MAX).
>
> Signed-off-by: Robert Richter <rrichter@....com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@...wei.com>
I'll be interested to see whether we end up deciding in the long run
that paying the cost of the call is worth while to get more useful
error records. This makes sense for now.
Jonathan
Powered by blists - more mailing lists