Attention is currently required from: Furquan Shaikh, Tim Wawrzynczak, Patrick Rudolph. Subrata Banik has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/51251 )
Change subject: soc/intel/common/block/cpu: Update the comments ......................................................................
Patch Set 2:
(1 comment)
File src/soc/intel/common/block/cpu/car/cache_as_ram.S:
https://review.coreboot.org/c/coreboot/+/51251/comment/4c0ca0bc_0a858868 PS2, Line 418: back up the number of ways of LLC to protect from eviction
What i have noticed, this block is never getting executed as CF=0 in ...
On the platform that you are testing, what are the values for:
- Way size => I need to print that
- CONFIG_DCACHE_RAM_SIZE => https://github.com/coreboot/coreboot/blob/master/src/soc/intel/alderlake/Kco...
If you are seeing CF=0 always, it could mean that the DCACHE_RAM_SIZE is smaller than the way size. Or am I missing something here?
You are right on the logic but DCACHE_RAM_SIZE is too big i believe frim way size. In ADL, we have increase DCACHE_RAM_SIZE to 768KB if still DCACHE_RAM_SIZE is lesser then i doubt about case for earlier generations.
However, irrespective of whether the data occupies a single way or multiple ways, when control reaches line 416, eax is supposed to contain the non-eviction mask (which would be 0x1 for 1 data way, 0x3 for 2 data ways and so on). Hence, the original comment is correct.
Ideally, we don't need to calculate the non-eviction mask, we just need to calculate the data ways we want to protect and program the same into 0xC92/0x1892/0xC85.
I do not understand this comment. MSR 0xc92 is the LLC way mask. You cannot program number of ways in that MSR. It has to be a way mask.
yes, we are programming the mask only https://review.coreboot.org/c/coreboot/+/48344/4/src/soc/intel/common/block/...
i think the problem is that, i wanted to remove the mask calculation from here and add all mask calculation in below code. https://review.coreboot.org/c/coreboot/+/48344/4/src/soc/intel/common/block/... which can be avoided. then that way, 0xc92/0x1892/0xc85 can all have mask assigned.
mov %ebx, %ecx // ebx has no. of data way movl $0x01, %eax shl %cl, %eax subl $0x01, %eax
I will clean up the code.
Same is true for 0x1892. I have no clue what 0xc85 is and so I cannot comment if it is the same as 0xc92 and 0x1892.
Yes,
Set MSR 0xC92 CBO_CR_IA_COS_WAYS_2 = 2 ^ Number of data ways -1 Set MSR 0x1892 IA32_CR_SF_QOS_MASK_2 = 2 ^ Number of data ways -1 Set MSR 0xC85 L3_Protected_ways = 2 ^ Number of data ways -1