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

[Mark Brown]

On Sun, Aug 02, 2026 at 06:13:38PM +0100, Fuad Tabba wrote:
> On Fri, 31 Jul 2026 at 21:46, Mark Brown <broonie@xxxxxxxxxx> wrote:

> The flag fixes this. One consistency point: set_id_reg() and
> set_imp_id_reg() now gate on the new flag, but
> kvm_vm_finalize_sys_regs() still returns early on
> kvm_vm_has_ran_once(), and so does the KVM_BUG_ON() in
> kvm_set_vm_id_reg(). Could both move to kvm_id_regs_final(), so one
> predicate expresses the invariant? If so I think they would need to
> move together, since on a retried first run kvm_vm_finalize_sys_regs()
> re-runs and re-writes the ID regs via kvm_set_vm_id_reg(), so
> switching only the BUG_ON would trip it.

Yeah, I think that's sensible.  I think I was thinking we might want to
add non-ID register stuff at some point, but we don't currently have any
of that and the ID register stuff that is there ought to be joined up.

> Separately, would a selftest for that failed-run path be worth adding,
> checking that KVM_SET_ONE_REG on an ID reg and KVM_CREATE_DEVICE both
> return -EBUSY?

It feels like there's a general gap here with ordering and interactions
during VM setup, both with the API calls and ideally also with
combinations of features.  Covering that is probably much more
beneficial than a focused test for the specific issue, that'd catch
recurrences of the specific mechanism but it'd be easy for it to miss
something else that causes the ID registers to change.

Attachment: signature.asc
Description: PGP signature