On Thu, 2 Oct 2025 at 11:16, Peter Maydell <[email protected]> wrote: > > If we create a normally-AArch64 CPU and configure it with > aarch64=off, this will by default leave all the AArch64 ID register > values in its ARMISARegisters struct untouched. That in turn means > that tests of cpu_isar_feature(aa64_something, cpu) will return true. > > Until now we have had a design policy that you shouldn't check an > aa64_ feature unless you know that the CPU has AArch64; but this is > quite fragile as it's easy to forget and only causes a problem in the > corner case where AArch64 was turned off. In particular, when we > extend the ability to disable AArch64 from only KVM to also TCG there > are many more aa64 feature check points which we would otherwise have > to audit for whether they needed to be guarded with a check on > ARM_FEATURE_AARCH64. > > Instead, make the CPU realize function zero out all the 64-bit ID > registers if the CPU doesn't have AArch64; this will make aa64_ > feature tests generally return false.
I did some testing, and this doesn't break a KVM AArch32 vcpu, so in that sense it's OK, but it is a bit odd, because from KVM's point of view the 64-bit ID registers still exist and must have their correct values (especially, for VM state load/save). This works because save/load goes through the cpreg arrays, and doesn't affect cpu->isar. But it means that QEMU has a different idea of the ID regs than KVM does. So I think the better approach here is that we do only clear these ID registers for the TCG case. For TCG, an aarch64=off CPU really does not have any aarch64 at all. For the other accelerators (which is probably only ever going to be KVM), an aarch64=off CPU is one which has AArch64 at a higher EL, it's just the VM can never get to that higher EL. That seems like enough of a difference to justify treating them differently here (i.e. only call arm_clear_aarch64_idregs() if tcg_enabled().) thanks -- PMM
