When I was reviewing Sebastian's CTR_EL0 series it occurred to me that our handling of feature ID registers local to a vCPU is quite poor. For VM-wide feature ID registers we ensure they get initialized once for the lifetime of a VM. On the other hand, vCPU-local feature ID registers get re-initialized on every vCPU reset, potentially clobbering the values userspace set up. MPIDR_EL1 and CLIDR_EL1 are the only registers in this space that we allow userspace to modify for now. Clobbering the value of MPIDR_EL1 has some disastrous side effects as the compressed index used by the MPIDR-to-vCPU lookup table assumes MPIDR_EL1 is immutable after KVM_RUN. Series + reproducer test case to address the problem of KVM wiping out userspace changes to these registers. Note that there are still some differences between VM and vCPU scoped feature ID registers from the perspective of userspace. We do not allow the value of VM-scope registers to change after KVM_RUN, but vCPU registers remain mutable. Fixing this is no problem, but given the recent theme of UAPI breakage in this area I focused only on the internal issue fo now. Applies to 6.9-rc3 Oliver Upton (7): KVM: arm64: Rename is_id_reg() to imply VM scope KVM: arm64: Reset VM feature ID regs from kvm_reset_sys_regs() KVM: arm64: Only reset vCPU-scoped feature ID regs once KVM: selftests: Rename helper in set_id_regs to imply VM scope KVM: selftests: Store expected register value in set_id_regs KVM: arm64: Test that feature ID regs survive a reset KVM: selftests: Test vCPU-scoped feature ID registers arch/arm64/include/asm/kvm_host.h | 2 + arch/arm64/kvm/arm.c | 5 - arch/arm64/kvm/sys_regs.c | 62 +++++---- .../selftests/kvm/aarch64/set_id_regs.c | 123 +++++++++++++++--- 4 files changed, 142 insertions(+), 50 deletions(-) base-commit: fec50db7033ea478773b159e0e2efb135270e3b7 -- 2.45.0.rc1.225.g2a3ae87e7f-goog
