Re: [PATCH v3 2/4] cxl: Restore XOR'd position bits during address translation

[Dan Williams <dan.j.williams@intel.com>]

alison.schofield@ wrote:
> From: Alison Schofield <alison.schofield@intel.com>
> 
> When a device reports a DPA in events like poison, general_media,
> and dram, the driver translates that DPA back to an HPA. Presently,
> the CXL driver translation only considers the Modulo position and
> will report the wrong HPA for XOR configured root decoders.
> 
> Add a helper function that restores the XOR'd bits during DPA->HPA
> address translation. Plumb a root decoder callback to the new helper
> when XOR interleave arithmetic is in use. For Modulo arithmetic, just
> let the callback be NULL - as in no extra work required.
> 
> Upon completion of a DPA->HPA translation a couple of checks are
> performed on the result. One simply confirms that the calculated
> HPA is within the address range of the region. That test is useful
> for both Modulo and XOR interleave arithmetic decodes.
> 
> A second check confirms that the HPA is within an expected chunk
> based on the endpoints position in the region and the region
> granularity. An XOR decode disrupts the Modulo pattern making the
> chunk check useless.
> 
> To align the checks with the proper decode, pull the region range
> check inline and use the helper to do the chunk check for Modulo
> decodes only.
> 
> A cxl-test unit test of address translations is in upstream review.
> 
> Fixes: 28a3ae4ff66c ("cxl/trace: Add an HPA to cxl_poison trace events")
> Signed-off-by: Alison Schofield <alison.schofield@intel.com>
> Tested-by: Diego Garcia Rodriguez <diego.garcia.rodriguez@intel.com>
> ---
>  drivers/cxl/acpi.c        | 48 ++++++++++++++++++++++++++++++++++++---
>  drivers/cxl/core/port.c   |  5 +++-
>  drivers/cxl/core/region.c | 22 ++++++++++--------
>  drivers/cxl/cxl.h         |  6 ++++-
>  4 files changed, 67 insertions(+), 14 deletions(-)
> 
[..]
> diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> index 603c0120cff8..3678235fc9ce 100644
> --- a/drivers/cxl/cxl.h
> +++ b/drivers/cxl/cxl.h
> @@ -434,12 +434,14 @@ struct cxl_switch_decoder {
>  struct cxl_root_decoder;
>  typedef struct cxl_dport *(*cxl_calc_hb_fn)(struct cxl_root_decoder *cxlrd,
>  					    int pos);
> +typedef u64 (*cxl_translate_fn)(struct cxl_root_decoder *cxlrd, u64 hpa);
>  
>  /**
>   * struct cxl_root_decoder - Static platform CXL address decoder
>   * @res: host / parent resource for region allocations
>   * @region_id: region id for next region provisioning event
>   * @calc_hb: which host bridge covers the n'th position by granularity
> + * @translate: decoder specific address translation function
>   * @platform_data: platform specific configuration data
>   * @range_lock: sync region autodiscovery by address range
>   * @qos_class: QoS performance class cookie
> @@ -449,6 +451,7 @@ struct cxl_root_decoder {
>  	struct resource *res;
>  	atomic_t region_id;
>  	cxl_calc_hb_fn calc_hb;
> +	cxl_translate_fn translate;

So the cxl_translate() => cxl_dpa_to_hpa() rename was good, but now this
name sticks out as not right because this routine is not doing dpa to
hpa translation. It is doing extended translation after the modulo
translation completes. It builds on the assumption that all address
decode below host-bridges is only modulo math, but that once the HPA
reaches the host-bridge it goes through a second stage translation.

In other parts of the driver this host-bridge level address has been
referred to as an SPA. Most times HPAs and SPAs are identical, but with
XOR math, or with AMD platforms like this [1], there is CXL HPA to
platform SPA translation.

All that said, lets call this method hpa_to_spa() and document it as

@hpa_to_spa: translate CXL host-physical-address to Platform system-physical-address

...then the code reads better:

    if (!cxlrd->hpa_to_spa)

...then it is clear that this root decoder is not doing anything outside
of standard CXL address translation that all switch and device-endpoint
decoders support.

With that rename you can add:

Reviewed-by: Dan Willliams <dan.j.williams@intel.com>

[1]: https://lore.kernel.org/all/20240216160113.407141-1-rrichter@amd.com/