Message-ID: <aMfRYdsWJlvrB_sf@rric.localdomain>
Date: Mon, 15 Sep 2025 10:42:09 +0200
From: Robert Richter <rrichter@....com>
To: Dave Jiang <dave.jiang@...el.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>,
	Jonathan Cameron <Jonathan.Cameron@...wei.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 v3 00/11] cxl: ACPI PRM Address Translation Support and
 AMD Zen5 enablement

On 12.09.25 08:45:37, Dave Jiang wrote:
> 
> 
> On 9/12/25 7:45 AM, Robert Richter wrote:
> > This patch set adds support for address translation using ACPI PRM and
> > enables this for AMD Zen5 platforms. This is another new appoach in
> > response to earlier attempts to implement CXL address translation:
> > 
> >  * v1: [1] and the comments on it, esp. Dan's [2],
> >  * v2: [3] and comments on [4], esp. Dave's [5]
> > 
> > This version 3 addresses the requests to reduce the number of patches
> > to a minimum and also to remove platform specific implementations
> > allowing the Documentation of CXL Address Translation Support in the
> > Kernel's "Compute Express Link: Linux Conventions" document and an
> > update of the CXL specification in the longterm. This patch submission
> > will be the base for a documention patch that describes CXL Address
> > Translation support accordingly. The documentation patch will be sent
> > in the very next step.
> > 
> > The CXL driver currently does not implement address translation which
> > assumes the host physical addresses (HPA) and system physical
> > addresses (SPA) are equal.
> > 
> > Systems with different HPA and SPA addresses need address translation.
> > If this is the case, the hardware addresses esp. used in the HDM
> > decoder configurations are different to the system's or parent port
> > address ranges. E.g. AMD Zen5 systems may be configured to use
> > 'Normalized addresses'. Then, CXL endpoints have their own physical
> > address base which is not the same as the SPA used by the CXL host
> > bridge. Thus, addresses need to be translated from the endpoint's to
> > its CXL host bridge's address range.
> > 
> > To enable address translation, the endpoint's HPA range must be
> > translated to the CXL host bridge's address range. A callback is
> > introduced to translate a decoder's HPA to the next parent port's
> > address range. This allows the enablement of address translation for
> > individual ports as needed. The callback is then used to determine the
> > region parameters which includes the SPA translated address range of
> > the endpoint decoder and the interleaving configuration. This is
> > stored in struct cxl_region which allows an endpoint decoder to
> > determine that parameters based on its assigned region.
> > 
> > Note that only auto-discovery of decoders is supported. Thus, decoders
> > are locked and cannot be configured manually.
> 
> Hi Robert, thanks for reworking this.
> 

> What happens with the manual configured path if only auto-discovery
> is supported? Things don't work? It works with no translation
> needed? Platform will lock all decoders and not allow manual
> configuration for CXL devices?

Endpoints, root ports and bridges are always pre-configured by
firmware in this case. A manual setup is not supported. That is why
the endpoints are locked to prevent the kernel from reconfiguring the
decoders, see:

 [PATCH v3 09/11] cxl/region: Lock decoders that need address translation

-Robert

Powered by blists - more mailing lists