Re: [DISCUSS] xen/arm: CLIDR Ctype scan order in get_llc_way_size()

["Orzel, Michal" <michal.orzel@xxxxxxx>]

On 13/01/2026 08:00, Mykola Kvach wrote:
> Hi all,
> 
> While investigating current Xen code, I noticed that get_llc_way_size()
> scans CLIDR_EL1 Cache Type (CtypeN) fields in reverse order to locate
> a unified cache level.
> 
> According to the Arm ARM (DDI 0487J.a, D19.2.27):
> 
> If software reads the Cache Type fields from Ctype1 upwards, once it has
> seen a value of 000, no caches that can be managed using the architected
> cache maintenance instructions that operate by set/way exist at
> further-out levels of the hierarchy. So, for example, if Ctype3 is the
> first Cache Type field with a value of 000, the values of Ctype4 to
> Ctype7 must be ignored.
> 
> This reads to me as an architectural constraint on software: fields above
> the first 0b000 are not architecturally meaningful for decisions (regardless
> of what bit patterns might appear there in a given implementation). With our
> current reverse scan, we could (at least in theory) mis-detect a "unified
> cache" at a level whose Ctype field is required to be ignored.
> 
> Discussion points:
> 1. Is the reverse scan intentional? In particular, do we rely on the
> assumption that Ctype fields above the first 0b000 are effectively
> RES0 in practice, or that they may legitimately describe caches which
> exist but are not manageable via the architected set/way maintenance
> instructions?
It is intentional in the sense that it makes the implementation easier
but it looks like we did not pay too much attention to the statement you 
provided.

> 2. Would it be more correct to scan from Ctype1 upwards and stop at the
> first 0b000, tracking the outermost unified cache seen prior to that
> point?
Maybe it would. At the same time I don't necessarily view this as a hard
requirement (the sentence starts from "IF the software reads from upwards" which
does not mean that reading downwards should not be done). I'm ok if you want to
change the implementation.

>
> If there is agreement, I can send a small fix patch with "Fixes:" adjusting
> the scan order/termination accordingly.
> 
> Thanks,
> Mykola

~Michal