Re: [PATCH v2 0/2] KVM: arm64: ID register finalisation fixes
Fuad Tabba <[email protected]> Tue, 4 Aug 2026 10:30:19 +0100
| Newsgroups | dev.linux.lists.kvmarm,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CA+EHjTxNcZrS8vPrrymJq_FZHUenrvxOd3aJ+WB7Fn8qY0NkKA@mail.gmail.com> |
Hi Mark, On Mon, 3 Aug 2026 at 23:54, Mark Brown <[email protected]> wrote: > > While looking at some feature enablement I noticed that there are some > scenarios where we can end up with an inconsistently configured vCPU due > to finalizing configuration based on ID registers before we have blocked > writes to the ID registers. This series aims to clean up these issues. > > Signed-off-by: Mark Brown <[email protected]> I didn't want to hold this for the broader coverage you suggested, so here is a focused test for the failed-first-run path [1]. It fails without this series. Tested on top of v7.2-rc5 under QEMU: boot tests, plus the set_id_regs, vgic_init and get-reg-list selftests, the last also under nested virt (-M vhe, kvm-arm.mode=nested). For the series: Reviewed-by: Fuad Tabba <[email protected]> Tested-by: Fuad Tabba <[email protected]> Cheers, /fuad [1] https://lore.kernel.org/all/[email protected]/ > --- > Changes in v2: > - Also replace the kvm_vm_has_ran_once() usage in kvm_set_vm_id_rg() and > kvm_vm_finalize_sys_regs() with kvm_id_regs_final(). > - Link to v1: https://patch.msgid.link/[email protected] > > --- > Mark Brown (2): > KVM: arm64: Finalize guest-wide sysregs prior to per-vCPU sysregs > KVM: arm64: Block ID register changes after we rely on the values > > arch/arm64/include/asm/kvm_host.h | 8 ++++++ > arch/arm64/kvm/arm.c | 2 +- > arch/arm64/kvm/sys_regs.c | 57 ++++++++++++++++++++++++--------------- > arch/arm64/kvm/sys_regs.h | 2 +- > arch/arm64/kvm/vgic/vgic-init.c | 6 ++--- > 5 files changed, 48 insertions(+), 27 deletions(-) > --- > base-commit: f5098b6bae761e346ebcd9da7f95622c04733cff > change-id: 20260729-kvm-arm64-idreg-final-77cbc46b558a > > Best regards, > -- > Mark Brown <[email protected]> >