On Tue, 6 Feb 2024 at 20:34, Richard Henderson <richard.hender...@linaro.org> wrote: > > On 2/6/24 23:29, Peter Maydell wrote: > > We support two different encodings for the AArch32 IMPDEF > > CBAR register -- older cores like the Cortex A9, A7, A15 > > have this at 4, c15, c0, 0; newer cores like the > > Cortex A35, A53, A57 and A72 have it at 1 c15 c0 0. > > > > When we implemented this we picked which encoding to > > use based on whether the CPU set ARM_FEATURE_AARCH64. > > However this isn't right for three cases: > > * the qemu-system-arm 'max' CPU, which is supposed to be > > a variant on a Cortex-A57; it ought to use the same > > encoding the A57 does and which the AArch64 'max' > > exposes to AArch32 guest code > > * the Cortex-R52, which is AArch32-only but has the CBAR > > at the newer encoding (and where we incorrectly are > > not yet setting ARM_FEATURE_CBAR_RO anyway) > > * any possible future support for other v8 AArch32 > > only CPUs, or for supporting "boot the CPU into > > AArch32 mode" on our existing cores like the A57 etc > > > > Make the decision of the encoding be based on whether > > the CPU implements the ARM_FEATURE_V8 flag instead. > > > > This changes the behaviour only for the qemu-system-arm > > '-cpu max'. We don't expect anybody to be relying on the > > old behaviour because: > > * it's not what the real hardware Cortex-A57 does > > (and that's what our ID register claims we are) > > Not even that, because max resets MIDR.
qemu-system-aarch64 max does (in aarch64_max_tcg_initfn(), yes; but qemu-system-arm max is set up in arm_max_initfn() in cpu32.c, and that sets cpu->midr = 0x411fd070 (which is the same as A57's MIDR)... > Anyway, > Reviewed-by: Richard Henderson <richard.hender...@linaro.org> thanks -- PMM
