Re: [PATCH v2] cxl: core/region - ignore interleave granularity when ways=1

[Zhijian Li (Fujitsu)]

Hi Dan

I am grateful for your prompt response.


On 03/04/2025 12:42, Dan Williams wrote:
> Zhijian Li (Fujitsu) wrote:
>> Hi Gregory and CXL community
>> Cc Goto-san
>>
>>                 |                                   |
>>            decoder9.0                           decoder10.0
>>           IW:1 IG:1024                          IW:1 IG:1024
> 
> Why 1024? Yes, the value does not matter, but attempting 1024 feels more
> like a unit test than a production use case.

I am uncertain, it appears to be this way when we get the device.
I presume it should not be a side effect in no-interleaving case.


Thank you for your answers to these questions. Your reply has truly
cleared up my confusion. Once again, thank you!

Thanks
Zhijian

>>
>> My question are:
>> Q1: whether "granularity is a don't care if not interleaving" is applied to
>> all HDM decoders(including root decoder and HDM decoder)
> 
> All decoders.> 
>> In current cxl cli , it will not show any interleave_granularity at all when ways==1(no-interleaving)
>> $ cxl list -PDE | grep granularity  # show nothing when ways==1
> 
> Right, because the value theoretically has no functional impact in the
> ways==1 case. However, it errantly ends up having practical impact in
> these corners cases where code performs granularity comparisons without
> considering that ways may be 1.
> 
>> Per the CXL Spec r3.1
>> IG: "The number of consecutive bytes that are assigned to each target in the Target List."
>> Q2: Does this imply a configuration where the number of ways>1?
> 
> Right, the granularity is the boundary at which the decoder switches to
> the next target in the target list. When ways=1 granularity can be
> infinity or zero by that definition.
> 
>> Q3: Does the IG also represent the device's capabilities? When programming, should one also
>> consider whether the device supports it?
> 
> Yes, see bits [9:8] in the CXL HDM Decoder Capability Register (CXL 3.2
> 8.2.4.20.1). So even though the math should not matter, I would still
> expect the driver to try to be careful to make sure that IG+8 is less
> than the address-bit max.

> 
>> If "granularity is a don't care if not interleaving" is true, how about below changes
> 
> Part of me says, "yes, that should be ok", another part of me says "what
> is the practical benefit of allowing any granularity to be specified?".
> 
> So the fix from Gregory is limited to the case of "whoops, the platform
> BIOS thought this was a good idea even though it does not matter in
> practice, teach Linux to be lenient in this case.".
> 
> The proposal to accept that in all case allows user-created regions to
> have odd large granularity sizes in the iw=1 case, and I am skeptical
> it is worth supporting that now.