Re: [PATCH 2/3] cxl/region: Introduce HPA to DPA address translation

[Alison Schofield <alison.schofield@intel.com>]

On Wed, Jun 25, 2025 at 03:49:37PM -0700, Dave Jiang wrote:
> 
> 
> On 6/23/25 5:53 PM, alison.schofield@intel.com wrote:
> > From: Alison Schofield <alison.schofield@intel.com>
> > 
> > Add infrastructure to translate Host Physical Addresses (HPA) to Device
> > Physical Addresses (DPA) within CXL regions. This capability is being
> > introduced for use by follow-on patches that will add poison inject
> > and clear operations at the region level.
> > 
> > The HPA-to-DPA translation process involves several steps:
> > 1. Apply root decoder transformations (HPA to SPA) if configured
> > 2. Calculate the relative offset within the region's address space
> > 3. Decode the interleave position using the region's interleave ways
> >    and granularity settings
> > 4. Identify the target memdev based on the decoded position
> > 5. Compute the final DPA by adding the decoded offset to the memdev's
> >    DPA base address
> > 
> > It is Step 1 above that makes this a driver level operation and not
> > work we can push to user space. Rather than exporting the XOR maps for
> > root decoders configured with XOR interleave, the driver performs this
> > complex calculation for the user.
> > 
> > While not immediately apparent in this diff, broader examination of
> > the region.c code shows that this work is basically the reverse of
> > previous work where a DPA is translated to an HPA. This is notable
> > because it demonstrates that these calculations reuse existing logic
> > rather than introducing new algorithms.
> 
> Are there any public documentations (or spec section) on explaining the translation you can point to for each of the function segments?

Yes. Will include in the v2 update.  Also, as I mentioned in reply to
Jonathan, I've backed away from the just reverse the dpa->hpa
messaging. The reason is that the spec defines exactly what to do
for hpa->dpa - which is what we are doing here. It's simpler to just
look at that, rather than to reverse what we reversed for dpa->hpa.
Clear as mud ?!

> 
> > 
> > Signed-off-by: Alison Schofield <alison.schofield@intel.com>
> > ---
> >  drivers/cxl/core/region.c | 85 +++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 85 insertions(+)
> > 
> > diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
> > index 6e5e1460068d..d2d904c4b427 100644
> > --- a/drivers/cxl/core/region.c
> > +++ b/drivers/cxl/core/region.c
> > @@ -2972,6 +2972,91 @@ u64 cxl_dpa_to_hpa(struct cxl_region *cxlr, const struct cxl_memdev *cxlmd,
> >  	return hpa;
> >  }
> >  
> > +struct hpa_decode_result {
> > +	u64 dpa_offset;
> > +	int pos;
> > +};
> > +
> > +struct cxl_dpa_result {
> > +	u64 dpa;
> > +	struct cxl_memdev *cxlmd;
> > +};
> > +
> > +static struct hpa_decode_result decode_hpa_to_dpa(u64 hpa_offset, u8 eiw,
> 
> While this is totally valid in C, I'm not big fan on returning a struct. The compiler copies the result from the function's stack to the variable of the caller function. Can we just pass in the addr of the caller's struct to write back and avoid that copy? We are not writing Rust code in CXL yet. :) 
> 

Done with the func that remains in v2. (One got folded into the other)