Re: [PATCH v2] cxl/region: Allow 6 & 12 way regions on 3-way HB interleaves

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

On Thu, Mar 06, 2025 at 04:23:35PM -0800, Dan Williams wrote:
> alison.schofield@ wrote:
> > From: Alison Schofield <alison.schofield@intel.com>
> > 
> > The CXL driver requires the granularity of a region and its root
> > decoder to be the same. This is particularly restrictive for 3-way
> > host bridge interleaves where the only spec defined interleave
> > configurations for creating 6-way and 12-way regions on a 3-way HB
> > interleave require mixed granularities.
> > 
> > CXL 3.2 Specification 9.13.1.1:
> > Legal Interleaving Configurations: 12-way, 6-way, and 3-way
> > 
> > Adding support for these new interleaves touches these areas:
> > 
> > 1) User created regions employing "cxl create-region" fail when the
> > CXL CLI tool gets a mixed granularity request. That is addressed in
> > a patch to the ndctl tool.
> > 
> > 2) User created regions employing sysfs directly fail at the sysfs
> > store of the non-matching region granularity. That restriction is
> > lifted here. Note that the driver immediately allows any reasonable
> > 3-way HB granularity, but the region config may still fail later
> > if the ways/gran between region and root decoder are incompatible.
> > 
> > 3) Auto created regions, in which the drivers role is to reflect
> > the BIOS created region and provide RAS support, basically sneak on
> > by. The driver ignores the root decoders granularity and assumes it
> > is the same as the regions. The impact being that endpoint devices
> > appear out of order and DPA to HPA address translations that depend
> > on that order are invalid.
> 
> I.e. that is a bug. The question is do we backport a "fix" to make that
> config start failing per old expectations, or do we backport this patch
> to fix those known configs?
> 

For this specific config -> fix it. For all the others quietly
misassembling -> start failing.  More...

> I would lean to backporting this patch so this needs a Fixes tag.

Thanks for the review Dan. Here's a response in general, and afterwards
responses to your embedded code review comments.

I should have said this was a no switches solution. This is a no
switches solution as that meets the use case needing repair. More
on that below.

I see where this can be more restrictive so as not to let any configs
slip through that are not 100% supported by the CXL driver. Let's
discuss which configs the driver will fully support versus explicitly
reject.

Appended is a list of the 3-6-12 way interleaves described in the CXL
Spec 3.2 Table. The complete list is appended because it's important
to see all the flavors. If we only talk switch, no_switch, or mixed,
no_mixed, combinations are omitted and complexity may be underestimated.
The driver supports 3 of the 11 configs correctly: 3-A, 6-A, 12-A.
Those are the configs with cross-host bridge interleave only.

The driver may pretend to support, but fails on all others. I use the
word 'may' because user created regions fail to create, so there is
no pretending there. It is the auto regions, (BIOS configured regions)
that will appear to be recognized by the CXL driver, but in fact the
assembly is misunderstood and so RAS support is broken.

That pretend is not just for MOD3 regions. Barring a safeguard I've
missed, any auto config with mixed granularity is quietly misassembled.

That suggests a lead in patch here that shuts down the quiet misassembly
of any mixed granularity auto regions. Again, no need to shut it down
for user-created as they are already blocked. User-created regions will
require new allowances.

Which mixed granularity regions require support?

I have a user that needs config 6-B fixed. That is the 6 way region
built on a 3-way Host Bridge Interleave, no switches. It is one of
those that are quietly misassembling as an auto region. Two similar
12-ways configs, 12-B&D come along for minimal additional effort yet
I am not aware of a use case for these.

Proposal is that this patch(set) protects against the mis-assembled
configs and adds support 6-B. That would fully meet the use case at hand
and protect users against the mis-assembled regions.

I do wonder if the shutdown of mis-assembled auto regions might bring
some use cases to light 

I expect I'll work a v3 with the updates noted here while listening
for upstream feedback on driver supported configs.


--------
Section 9.13.1.1
Legal Interleaving Configurations: 12-way, 6-way, and 3-way 

Table 9-8: 3-Way Device-level Interleave at 1GB
3-A:	Cross-host Bridge: 3 way at 1GB
	Host Bridge: No interleaving
	Switch: No interleaving or absent

Table 9-7: 6-Way Device-level Interleave at 1GB
6-A:	Cross-host Bridge: 6 way at 1GB
	Host Bridge: No interleaving
	Switch: No interleaving or absent
6-B:	Cross-host Bridge: 3 way at 2 times 1GB
	Host Bridge: 2 way at 1GB
	Switch: No interleaving
6-C:	Cross-host Bridge: 3 way at 2 times 1GB
	Host Bridge: No interleaving
	Switch: 2 way at 1GB

Table 9-6: 12-Way Device-level Interleave at 1GB
12-A:	Cross-host Bridge: 12 way at 1GB
	Host Bridge: No interleaving
	Switch: No interleaving or absent
12-B:	Cross-host Bridge: 6 way at 2 times 1GB
	Host Bridge: 2 way at 1GB
	Switch: No interleaving or absent
12-C:	Cross-host Bridge: 6 way at 2 times 1GB
	Host Bridge: No interleaving
	Switch: 2 way at 1GB
12-D:	Cross-host Bridge: 3 way at 4 times 1GB
	Host Bridge: 4 way at 1GB
	Switch: No interleaving
12-E:	Cross-host Bridge: 3 way at 4 times 1GB
	Host Bridge: No interleaving
	Switch: 4 way at 1GB
12-F:	Cross-host Bridge: 3 way at 4 times 1GB
	Host Bridge: 2 way at 1GB
	Switch: 2 way at 2 times 1GB
12-G:	Cross-host Bridge: 3 way at 4 times 1GB
	Host Bridge: 2 way at 2 times 1GB
	Switch: 2 way at 1GB


> 
> > Here the driver stops making that same
> > granularity assumption and checks for an allowable granularity.
> > 
> > A new helper, interleave_granularity_allow(), is used in both the
> > user and auto creation path to allow the newly supported configs.
> 
> Minor but the function is not performing an "allow" operation it is
> evaluating an "allowed" condition, so I would have expected this to be
> named:
> 
>     is_interleave_granularity_allowed()
> 

got it.


> > Another new helper, gran_multiple(), is used in sorting, target
> > list searching, and distance calculations, supporting the new
> > root granularity to region granularity multiples.
> > 
> > And, as noted in 2), there's an added check to see if the
> > selected sysfs ways/gran make sense when considered together.
> > 
> > Signed-off-by: Alison Schofield <alison.schofield@intel.com>
> > ---
> > 
> > Changes in v2:
> > - Allow exactly 2*ig or 4*ig in interleave_granularity_allow()(DaveJ)
> > - Remove needless !root_decoder_gran check in gran_multiple()(Ming)
> > - Update spec references to 3.2 (DaveJ)
> > - Commit log grammar cleanup (DaveJ)
> > - Describe param 'multiple' in cxl_calc_interleave_pos() (lkp)
> > 
> > 
> >  drivers/cxl/core/region.c | 104 +++++++++++++++++++++++++++++++-------
> >  1 file changed, 85 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
> > index 8537b6a9ca18..cc2687407a3e 100644
> > --- a/drivers/cxl/core/region.c
> > +++ b/drivers/cxl/core/region.c
> > @@ -532,6 +532,31 @@ static ssize_t interleave_granularity_show(struct device *dev,
> >  	return rc;
> >  }
> >  
> > +static bool interleave_granularity_allow(struct cxl_decoder *cxld, u16 ig)
> 
> I don't like that this function takes a plain 'struct cxl_decoder *',
> this function is only relevant for root decoders so make that clear by
> requring that it is passed a 'struct cxl_root_decoder *'. Yes, it means
> redoing the "cxld = &cxlrd->cxlsd.cxld" conversion.
> 

got it: s/cxl_decoder/cxl_root_decoder


> > +{
> > +	/*
> > +	 * When the host-bridge is interleaved, disallow region granularity
> > +	 * != root granularity with the exception of 3-way HB interleaves.
> > +	 * Allow the CXL Spec defined 3-way HB interleaves that can only be
> > +	 * configured when host-bridge interleave is greater that the
> > +	 * region interleave. (CXL 3.2 Specification 9.13.1.1)
> > +	 * Allow 2+2+2 interleave where HB gran is 2 * region granularity
> > +	 *	 4+4+4 interleave where HB gran is 4 * region granularity
> 
> Only an Intel person might understand X+X+X notation topology notation.
> Just describe these configs in plain english.

Can do.

> 
>     Allow 6 endpoints across 3 host-bridges when the root-decoder
>     granularity is 2x region granularity.
> 
>     Allow 12 endpoints across 3 host-bridges when the root-decoder 
>     granularity is 4x region granularity.
> 
> The problem is that this comment assumes direct-attached endpoints. If
> you had switches between a host-bridge and endpoints then the region
> granularity is not valid to compare to the root decoder granularity.
> 

Yes it does.

> > +	 *
> > +	 * Regions with a granularity greater than the root interleave result
> > +	 * in invalid DPA translations (invalid to support).
> > +	 */
> > +	if (cxld->interleave_ways > 1 && ig != cxld->interleave_granularity) {
> > +		if (cxld->interleave_ways != 3)
> > +			return false;
> > +
> > +		if (cxld->interleave_granularity != 2 * ig &&
> > +		    cxld->interleave_granularity != 4 * ig)
> > +			return false;
> > +	}
> > +	return true;
> > +}
> > +

snip

> > @@ -1347,12 +1382,17 @@ static int cxl_port_setup_targets(struct cxl_port *port,
> >  		 * always 1 as every index targets a different host-bridge. At
> >  		 * each subsequent switch level those ports map every Nth region
> >  		 * position where N is the width of the switch == distance.
> > +		 *
> > +		 * With the introduction of mixed granularities in 3-way HB
> > +		 * interleaves, divide N by a multiple that represents the root
> > +		 * decoder to region granularity.
> 
> I go into more detail later, but region granularity is not relevant when
> switches are present.

No switches present. I take another look to see if any of this
doesn't clearly preclude switches.

> 
> > +	/*
> > +	 * Protect against improper gran mixes on 3-way HB interleave
> > +	 * Expect decoder gran*ways == region gran*ways
> > +	 */
> > +	if (cxlrd->cxlsd.cxld.interleave_ways == 3) {
> > +		if ((cxlrd->cxlsd.cxld.interleave_granularity * 3) !=
> > +		    (p->interleave_ways * p->interleave_granularity)) {
> 
> When switches are present p->interleave_ways and
> p->interleave_granularity are not relevant for 3-way validation. For
> example imagine an x3 HB, with x6 switches, and x12 endpoints. The mixed
> granularity is resolved at the switch level, not the region level.

No switches.