[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 at kernel.org> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260803/633189aa/attachment.sig>