[S] Change in coreboot[main]: soc/intel/common/block/cpu: Add Kconfig for effective way size for NEM+

[Subrata Banik (Code Review)]

Attention is currently required from: Ashish Kumar Mishra, Jérémy Compostella, Paul Menzel, Sowmya Aralguppe, Wonkyu Kim.

Subrata Banik has posted comments on this change by Jérémy Compostella. ( https://review.coreboot.org/c/coreboot/+/83946?usp=email )

Change subject: soc/intel/common/block/cpu: Add Kconfig for effective way size for NEM+
......................................................................

Patch Set 13:

(1 comment)

Commit Message:

https://review.coreboot.org/c/coreboot/+/83946/comment/22b65de6_10186f47?usp... :
PS13, Line 23: The issue addressed by this commit can be observed with the following
             : experiment: using a 18 MB LLC SKU, set `DCACHE_RAM_SIZE` to
             : 0x400000 (4 MB).
> > But my question is where is the doc to refer to understand the formula to calculate the eff_way_size (Therefore, we instead compute the effective way size as the biggest of power of two of the way size which works across all three platforms.) I don't see any document that explains the logic mentioned by you in the commit section? that we should only keep the most significant bit position and mask rest to determine the effective way size.
>
> On Alder Lake, the External Design Specification #627270 "3.5.2 No-Eviction Mode (NEM) Sizes" provides a way to compute the effective cache size (and effective way size) by reading the number of CBO using MSR 0x396. I would not qualify this section of the documentation to be crystal clear but the idea is there.
>
> Since Meteor Lake does not have this MSR, the recommendation is to compute the effective cache size following CNDA 1433518 page 15 and determine the NEM size based on the power of 2 of bank number. This CL is implementing the same principle (also aligned with MTL HAS): 1- consider the effective way size for NEM size computation instead of the way size. 2- Compute the effective way size as the biggest power of two of the way size.

i hope you are referring to the section "As an illustration, if a particular SKU features 6 banks totaling 18MB, the NEM would be configured to use 4
banks, which equates to 12MB."

1. it talks about specific SoC sku and i assume this is SoC cache internal logic and nothing requires to configure by FW/SW for lowing the NEM size. For example: with b/306677879, my learning is that, if the NEM is not power of two, we can still get the benefit read into entire NEM range but the range that is > power_of_2 won't be map into DRAM while we are tearing down. By following your logic, we would be limiting the NEM size to smaller window compare to what max we could still use for read benefit (assuming CAR range is configured as WP). This is what we did using https://review.coreboot.org/c/coreboot/+/81269

2. As per above example from Intel doc, it says that the number of NEM bank will  be check again the power_of_2 and not the LLC size. for example: NEM bank 6 is not power 2 hence, limit it to 4 and each bank has 3MB so, the LLC size would be 12MB

3. Looking at your logic in same example of 18MB of LLC (which is not power_of_2), you are ending up reserving the most significant 1 and masking rest would mean, the LLC size will be 16MB. Now trying to fit that into NEM bank (3MB/port). You won't be able to do it. 16MB/3MB=~5.33 (which is not power of 2)

4. The better logic would be to find the NEM bank count and then check if it's power_of_2 or not.