On Thu, Feb 05 2026, Peter Maydell <[email protected]> wrote: > On Wed, 4 Feb 2026 at 13:32, Cornelia Huck <[email protected]> wrote: >> RFC because there are still some open questions: > >> - There's a slight disagreement between the current code (providing 16 >> entries for CCSIDR_EL1) and the KVM code (providing (7 cache levels) * >> (data/unified, instruction) = 14 entries.) With FEAT_MTE2, we might be >> needing 7 more entries. > > This is because architecturally the CCSELR_EL1 register is: > bit 4 : TnD (tag-not-data) > bits [3:1] : level > bit 0 : InD (instruction-not-data) > > but the 'level' field has 0b111 as Reserved, and KVM doesn't > (currently) handle the FEAT_MTE2 TnD bit, so from KVM's point > of view only 0..13 are valid values here. > > The architecture says that if you set CSSELR_EL1 to an invalid > setting then reading CCSIDR_EL1 can be: > * a NOP > * UNDEF > * return an UNKNOWN value > > For TCG we opted to permit any indexes 0..15, so that we treat > the architecturally invalid 0b1110 and 0b1111 the same way as > we treat "you picked a level this particular CPU doesn't implement" > (and return a 0 from our cpu->cssidr[] array). Otherwise we would > have had to add an extra check for "and level isn't invalid".
That makes sense. > > TCG also doesn't do anything with the FEAT_MTE2 TnD bit: looks > like we missed that functionality when we added MTE2 emulation. > Setting TnD and InD at once isn't a valid combination, so we > could either extend our cpu->ccsidr[] array to 32 words (and > live with 8 of the extras being unused), or else add a new > 8-word array for the MTE tag-cache ID values. Whatever we do, it would be easiest if KVM and TCG followed a similar approach, so we don't end up having to special case the code. As KVM also supports setting (virtual) CCSIDR_EL1 values, I think just extending the array would be easiest, so that QEMU can just keep everything in one place.
