[PATCH v2 2/2] KVM: arm64: Block ID register changes after we rely on the values

[Marc Zyngier]

On Mon, 03 Aug 2026 23:53:54 +0100,
Mark Brown <broonie at kernel.org> wrote:
> 
> In commit c5bac1ef7df6b ("KVM: arm64: Move existing feature disabling
> over to FGU infrastructure") a check was added to suppress duplicate
> recalculation of FGUs based on a flag KVM_ARCH_FLAG_FGU_INITIALIZED. This
> flag is set when we complete kvm_calculate_traps(), which is called from
> kvm_arch_vcpu_run_pid_change(). There are several points where that
> function could fail after we have calculated FGUs (eg, due to an invalid
> timer configuration). If this happens then userspace will still be able
> to write to the ID registers, writes to which are gated on
> KVM_ARCH_FLAG_HAS_RAN_ONCE being set. This in turn means that the FGU
> configuration for a running guest may not match the ID register
> configuration.
> 
> This will result in issues based on the hypervisor assuming a consistent
> configuration, for example it allows the creation of guests which have
> untrapped access to system registers which are not context switched for
> the guest.
> 
> A similar issue exists in kvm_init_nv_sysregs() where once sysreg_masks
> is allocated the RES0/RES1 masks for registers are fixed based on the ID
> register values at the time the function ran, and also for copying the
> implementation ID registers to the hypervisor for pKVM.
> 
> There is a further issue with vGIC setup, creating a vGIC includes
> updating the ID registers to reflect the GIC configuration. We refuse
> to create a vGIC after the first vCPU has run but if a vCPU fails its
> first run we may already have finalized the ID register values.
> 
> Avoid these issues by adding a new flag that we set when we finalize the
> system registers, blocking ID register changes after that has been set
> even if something fails later on. Do this in kvm_vm_finalize_sys_regs(),
> this is where we finalize the GIC fields in the ID registers and happens
> before we do the FGU and RES0/1 setup. A VMM which tries to create an
> irqchip after failing to run a vCPU will now get -EBUSY rather than a
> likely misconfigured guest. Userspace is not expected to try to run a
> guest that fails to start, never mind try to repair the guest
> configuration after doing so, so this is not expected to have any impact
> on practical users.

We already have KVM_ARCH_FLAG_ID_REGS_INITIALIZED. Why do we need
another flag for something that appears to be similar? Why can't we
broaden the scope of the existing flag to cover the above?

	M.

-- 
Without deviation from the norm, progress is not possible.