From: Jonathan Cameron <jonathan.cameron@huawei.com>
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>,
Dave Jiang <dave.jiang@intel.com>,
"Davidlohr Bueso" <dave@stgolabs.net>,
<linux-cxl@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
Gregory Price <gourry@gourry.net>,
"Terry Bowman" <terry.bowman@amd.com>,
Joshua Hahn <joshua.hahnjy@gmail.com>
Subject: Re: [PATCH] cxl/region: Support multi-level interleaving with smaller granularities for lower levels
Date: Tue, 28 Oct 2025 14:27:27 +0000 [thread overview]
Message-ID: <20251028142727.00003f91@huawei.com> (raw)
In-Reply-To: <20251028094754.72816-1-rrichter@amd.com>
On Tue, 28 Oct 2025 10:47:53 +0100
Robert Richter <rrichter@amd.com> wrote:
> The CXL specification supports multi-level interleaving "as long as
> all the levels use different, but consecutive, HPA bits to select the
> target and no Interleave Set has more than 8 devices" (from 3.2).
>
> Currently the kernel expects that a decoder's "interleave granularity
> is a multiple of @parent_port granularity". That is, the granularity
> of a lower level is bigger than those of the parent and uses the outer
> HPA bits as selector. It works e.g. for the following 8-way config:
>
> * cross-link (cross-hostbridge config in CFMWS):
> * 4-way
> * 256 granularity
> * Selector: HPA[8:9]
> * sub-link (CXL Host bridge config of the HDM):
> * 2-way
> * 1024 granularity
> * Selector: HPA[10]
>
> Now, if the outer HPA bits are used for the cross-hostbridge, an 8-way
> config could look like this:
>
> * cross-link (cross-hostbridge config in CFMWS):
> * 4-way
> * 512 granularity
> * Selector: HPA[9:10]
> * sub-link (CXL Host bridge config of the HDM):
> * 2-way
> * 256 granularity
> * Selector: HPA[8]
>
> The enumeration of decoders for this configuration fails then with
> following error:
>
> cxl region0: pci0000:00:port1 cxl_port_setup_targets expected iw: 2 ig: 1024 [mem 0x10000000000-0x1ffffffffff flags 0x200]
> cxl region0: pci0000:00:port1 cxl_port_setup_targets got iw: 2 ig: 256 state: enabled 0x10000000000:0x1ffffffffff
> cxl_port endpoint12: failed to attach decoder12.0 to region0: -6
>
> Note that this happens only if firmware is setting up the decoders
> (CXL_REGION_F_AUTO). For userspace region assembly the granularities
> are chosen to increase from root down to the lower levels. That is,
> outer HPA bits are always used for lower interleaving levels.
>
> Rework the implementation to also support multi-level interleaving
> with smaller granularities for lower levels. Determine the interleave
> set of autodetected decoders. Check that it is a subset of the root
> interleave.
>
> The HPA selector bits are extracted for all decoders of the set and
> checked that there is no overlap and bits are consecutive. All
> decoders can be programmed now to use any bit range within the
> region's target selector.
>
> Signed-off-by: Robert Richter <rrichter@amd.com>
We debated this back when the original support was added. At the time the
discussion pretty much concluded there was no reason anyone would ever actually
do this because it mostly doesn't provide much/any performance benefit and
might result in significantly worse performance by not spreading out accesses as
early as possible.
So do we have any idea why a bios is doing this? Something about the
host interconnect?
Thanks,
Jonathan
next prev parent reply other threads:[~2025-10-28 14:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-28 9:47 [PATCH] cxl/region: Support multi-level interleaving with smaller granularities for lower levels Robert Richter
2025-10-28 14:27 ` Jonathan Cameron [this message]
2025-10-29 9:53 ` Robert Richter
2025-10-29 16:44 ` Alejandro Lucero Palau
2025-10-31 7:03 ` kernel test robot
2025-10-31 13:42 ` Gregory Price
2026-03-12 16:35 ` Vishal Aslot
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=20251028142727.00003f91@huawei.com \
--to=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=gourry@gourry.net \
--cc=ira.weiny@intel.com \
--cc=joshua.hahnjy@gmail.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