Attention is currently required from: Ashish Kumar Mishra, Paul Menzel, Sowmya Aralguppe, Subrata Banik, Wonkyu Kim.
Jérémy Compostella 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/40911c81_0d1ee73d?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.