KVM/arm64: Guest ABI changes do not appear rollback-safe

[Marc Zyngier]

On Tue, 08 Feb 2022 16:58:26 +0000,
Sean Christopherson <seanjc at google.com> wrote:
> 
> On Tue, Feb 08, 2022, Oliver Upton wrote:
> > Hi Marc,
> > 
> > On Tue, Feb 8, 2022 at 1:46 AM Marc Zyngier <maz at kernel.org> wrote:
> > > > > KVM currently restricts the vcpu features to be unified across vcpus,
> > > > > but that's only an implementation choice.
> > > >
> > > > But that implementation choice has become ABI, no? How could support
> > > > for asymmetry be added without requiring userspace opt-in or breaking
> > > > existing VMMs that depend on feature unification?
> > >
> > > Of course, you'd need some sort of advertising of this new behaviour.
> > >
> > > One thing I would like to add to the current state of thing is an
> > > indication of whether the effects of a sysreg being written from
> > > userspace are global or local to a vcpu. You'd need a new capability,
> > > and an extra flag added to the encoding of each register.
> > 
> > Ah. I think that is a much more reasonable fit then. VMMs unaware of
> > this can continue to migrate new bits (albeit at the cost of
> > potentially higher lock contention for the per-VM stuff), and those
> > that do can reap the benefits of writing such attributes exactly once.
> 
> But the "proper" usage is no different than adding support for
> VM-scoped variants of KVM_{G,S}ET_ONE_REG and friends, and a
> VM-scoped variant is conceptually a lot cleaner IMO.  And making
> them truly VM-scoped means KVM can do things like support sysregs
> that are immutable after vCPUs are created.

It is different, because your approach requires you to update all the
existing VMMs to find out which register is of which kind. Not to
mention that global sysregs are an absolute oddity in the face of the
architecture (there is none in the base architecture).

> So long as KVM defaults to '0' for all such registers, lack of
> migration support in userspace that isn't aware of the new API,
> i.e. doesn't do KVM_GET_REG_LIST at a VM-scope, is a nop because
> said userspace also won't modify the registers in the first place.

We want any VMM that correctly uses the API today to seamlessly be
able to save/restore any new feature. QEMU does that, and it should
continue to work no matter what new feature we add to the list.

	M.

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