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

[Mykola Kvach <xakep.amatop@xxxxxxxxx>]

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?
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?

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

Thanks,
Mykola