Linux CXL
 help / color / mirror / Atom feed
From: Gregory Price <gourry@gourry.net>
To: Robert Richter <rrichter@amd.com>
Cc: Alison Schofield <alison.schofield@intel.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>
Subject: Re: [PATCH v2 10/15] cxl/region: Use root decoders interleaving parameters to create a region
Date: Mon, 31 Mar 2025 21:59:45 -0400	[thread overview]
Message-ID: <Z-tIkR_bEkDPUyp4@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <20250218132356.1809075-11-rrichter@amd.com>

On Tue, Feb 18, 2025 at 02:23:51PM +0100, Robert Richter wrote:
> @@ -1955,12 +1971,23 @@ static int cxl_port_calc_interleave(struct cxl_port *port,
>  	if (is_cxl_root(port))
>  		return 0;
>  
> -	rc = find_pos_and_ways(port, ctx->hpa_range, &parent_pos, &parent_ways);
> +	rc = find_pos_and_ways(port, ctx->hpa_range, &parent_pos, &parent_ways,
> +			&parent_granularity);
>  	if (rc)
>  		return rc;
>  
>  	ctx->pos = ctx->pos * parent_ways + parent_pos;
>  
> +	if (ctx->interleave_ways)
> +		ctx->interleave_ways *= parent_ways;
> +	else
> +		ctx->interleave_ways = parent_ways;
> +
> +	if (ctx->interleave_granularity)
> +		ctx->interleave_granularity *= ctx->interleave_ways;
> +	else
> +		ctx->interleave_granularity = parent_granularity;
> +
>  	return ctx->pos;
>  }
>  

I have discovered on my Zen5 that either this code is incorrect, or my
decoders are programmed incorrectly.

decoderN.M  |  ig  iw
----------------------
decoder0.0  |  2   256
decoder1.0  |  1   256
decoder3.0  |  1   256
decoder5.0  |  1   256
decoder6.0  |  1   256
region0     |  2   512 <--- Wrong

*Arch quirk aside*, everything except region is as expected.


I finally dropped a bunch of hacks from my branch, and my Zen5 stopped
bringing devices up correctly, with the error:

[]cxl region0: pci0000:d2:port1 cxl_port_setup_targets expected
               iw: 1 ig: 1024   [... snip ...]
[]cxl region0: pci0000:d2:port1 cxl_port_setup_targets got
               iw: 1 ig: 256    [... snip ...]

Sitting here scratching my head how I could possibly end up with an ig
of 1024 with the above set of decoders when I realized the region
inherited interleave_ways/granularity from the ENDPOINT decoder, which
is not exposed to sysfs.

Had to come back around to realize this patch set adds new
ways/granularity fields to the endpoint decoder.

struct cxl_endpoint_decoder {
        struct cxl_decoder cxld;
	...
        int interleave_ways;
        int interleave_granularity;
}

struct cxl_decoder {
	...
        int interleave_ways;
        int interleave_granularity;
}


1) the cxl_endpoint_decoder descriptor needs to be updated to explain
   why these ways/granularity differ from the cxl_decoder inside of the
   cxl_endpoint_decoder.  This is very, very confusing.

   The reason appears to be that the endpoint decoder ways/granularity
   is the region ways/granularity.  So the endpoint decoder is passing
   this information along.

   Makes me think the region creation code should call this directly,
   rather than all this indirection.


2) This calculation appears to just be plain wrong.


static int cxl_endpoint_decoder_initialize(struct cxl_endpoint_decoder *cxled)
{
	ctx = (struct cxl_interleave_context) {
                .hpa_range = &hpa,
        };
	...
        while (iter && parent) {
	        endpoint        host bridge      root
		decoder6.0  ->  decoder3.0   ->  decoder0.0

                /* Convert interleave settings to next port upstream. */
                rc = cxl_port_calc_interleave(iter, &ctx);
		...
	}
	...
	cxled->interleave_ways = ctx.interleave_ways;
        cxled->interleave_granularity = ctx.interleave_granularity;
}

On my setup, I would expect to iterate decoder3.0 and decoder0.0
	decoderN.M  |  ig  iw
	----------------------
	decoder0.0  |  2   256
	decoder3.0  |  1   256

	on entry [iw,ig] = [0,0]
	[parent_ways, parent_gran] -> [1,256]
	[iw * piw, ig * piw]       -> [2,512]


Looking at a normal system, we'd expect this configuration:

decoderN.M  |  ig  iw
----------------------
decoder0.0  |  2   256
decoder1.0  |  1   512
decoder3.0  |  1   512
decoder5.0  |  2   256
decoder6.0  |  2   256

The above code produces the following:
	[1,512]
	[2,1024] <--- still wrong


in cxl_port_setup_targets we have this comment:

        if (is_cxl_root(parent_port)) {
                /*
                 * Root decoder IG is always set to value in CFMWS which
                 * may be different than this region's IG.  We can use the
                 * region's IG here since interleave_granularity_store()
                 * does not allow interleaved host-bridges with
                 * root IG != region IG.
                 */
                parent_ig = p->interleave_granularity;
                parent_iw = cxlrd->cxlsd.cxld.interleave_ways;
	}


Can we not just always report the parent ways/granularity, and skip all
the math?  We'll always iterate to the root, and that's what we want the
region to match, right?

Better yet, can we not just do this in the region creation code, rather
than having the endpoint carry it through to the region for some reason?
Avoid adding the duplicate ways/granularity field all together.

~Gregory

  parent reply	other threads:[~2025-04-01  1:59 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-18 13:23 [PATCH v2 00/15] cxl: Address translation support, part 2: Generic support and AMD Zen5 platform enablement Robert Richter
2025-02-18 13:23 ` [PATCH v2 01/15] cxl: Modify address translation callback for generic use Robert Richter
2025-02-20 16:00   ` Gregory Price
2025-02-20 21:03     ` Dave Jiang
2025-02-18 13:23 ` [PATCH v2 02/15] cxl: Introduce callback to translate an HPA range from a port to its parent Robert Richter
2025-02-20 21:19   ` Dave Jiang
2025-02-18 13:23 ` [PATCH v2 03/15] cxl/region: Factor out code for interleaving calculations Robert Richter
2025-02-20 16:28   ` Gregory Price
2025-02-20 16:41     ` Gregory Price
2025-03-14 12:45   ` Jonathan Cameron
2025-02-18 13:23 ` [PATCH v2 04/15] cxl/region: Calculate endpoint's region position during init Robert Richter
2025-02-19 23:32   ` Gregory Price
2025-02-20 17:31   ` Gregory Price
2025-02-20 21:56   ` Dave Jiang
2025-04-04  4:38   ` Gregory Price
2025-04-04 15:36   ` [PATCH] cxl/region: Continue recalculating position during sort Gregory Price
2025-04-04 17:22     ` Gregory Price
2025-04-05  2:35   ` [PATCH] cxl region: recalculate interleave pos during region probe Gregory Price
2025-04-08 15:30     ` Gregory Price
2025-02-18 13:23 ` [PATCH v2 05/15] cxl/region: Calculate and store the SPA range of an endpoint Robert Richter
2025-02-20 18:42   ` Gregory Price
2025-02-20 22:31   ` Dave Jiang
2025-02-20 22:37     ` Gregory Price
2025-03-14 12:41   ` Jonathan Cameron
2025-02-18 13:23 ` [PATCH v2 06/15] cxl/region: Use endpoint's HPA range to find the port's decoder Robert Richter
2025-04-24  0:28   ` Gregory Price
2025-04-24 21:49     ` Gregory Price
2025-04-24 23:46       ` Gregory Price
2025-02-18 13:23 ` [PATCH v2 07/15] cxl/region: Use translated HPA ranges " Robert Richter
2025-02-20 19:13   ` Gregory Price
2025-02-18 13:23 ` [PATCH v2 08/15] cxl/region: Use the endpoint's SPA range to find a region Robert Richter
2025-02-20 19:28   ` Gregory Price
2025-03-14 12:45   ` Jonathan Cameron
2025-04-08 15:45   ` Gregory Price
2025-02-18 13:23 ` [PATCH v2 09/15] cxl/region: Use the endpoint's SPA range to create " Robert Richter
2025-02-20 19:31   ` Gregory Price
2025-03-14 12:46   ` Jonathan Cameron
2025-04-08 15:50   ` Gregory Price
2025-02-18 13:23 ` [PATCH v2 10/15] cxl/region: Use root decoders interleaving parameters " Robert Richter
2025-02-20 19:43   ` Gregory Price
2025-03-14 12:49   ` Jonathan Cameron
2025-04-01  1:59   ` Gregory Price [this message]
2025-04-01  5:26     ` Gregory Price
2025-04-01 18:03   ` Gregory Price
2025-02-18 13:23 ` [PATCH v2 11/15] cxl/region: Use the endpoint's SPA range to check " Robert Richter
2025-02-20 19:50   ` Gregory Price
2025-04-08 15:54   ` Gregory Price
2025-02-18 13:23 ` [PATCH v2 12/15] cxl/region: Lock decoders that need address translation Robert Richter
2025-02-20 19:57   ` Gregory Price
2025-02-18 13:23 ` [PATCH v2 13/15] cxl/x86: Prepare for architectural platform setup Robert Richter
2025-02-20 19:57   ` Gregory Price
2025-02-18 13:23 ` [PATCH v2 14/15] cxl/amd: Enable Zen5 address translation using ACPI PRMT Robert Richter
2025-02-21  0:40   ` Dave Jiang
2025-03-14 13:01   ` Jonathan Cameron
2025-04-05  2:38   ` [PATCH] [HACK] drop zen5_init checks due to segfault Gregory Price
2025-05-13 21:10     ` Robert Richter
2025-06-17 20:33       ` Joshua Hahn
2025-06-24  5:43         ` Robert Richter
2025-06-24 21:46           ` Joshua Hahn
2025-02-18 13:23 ` [PATCH v2 15/15] MAINTAINERS: CXL: Add entry for AMD platform support (CXL_AMD) Robert Richter
2025-02-20  1:00 ` [PATCH v2 00/15] cxl: Address translation support, part 2: Generic support and AMD Zen5 platform enablement Gregory Price

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=Z-tIkR_bEkDPUyp4@gourry-fedora-PF4VCD3F \
    --to=gourry@gourry.net \
    --cc=Jonathan.Cameron@huawei.com \
    --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=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