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

From: Marc Zyngier <maz@kernel.org>
To: Oliver Upton <oupton@google.com>
Cc: Andrew Jones <drjones@redhat.com>,
	kvmarm@lists.cs.columbia.edu, pshier@google.com,
	ricarkol@google.com, rananta@google.com, reijiw@google.com,
	jingzhangos@google.com, kvm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, james.morse@arm.com,
	Alexandru.Elisei@arm.com, suzuki.poulose@arm.com,
	Peter Maydell <peter.maydell@linaro.org>
Subject: Re: KVM/arm64: Guest ABI changes do not appear rollback-safe
Date: Thu, 30 Sep 2021 08:32:25 +0100	[thread overview]
Message-ID: <87ilyitt6e.wl-maz@kernel.org> (raw)
In-Reply-To: <CAOQ_Qsg2dKLLanSx6nMbC1Er9DSO3peLVEAJNvU1ZcRVmwaXgQ@mail.gmail.com>

Hi Oliver,

On Wed, 29 Sep 2021 19:22:05 +0100,
Oliver Upton <oupton@google.com> wrote:
> 
> I have some lingering thoughts on this subject since we last spoke and
> wanted to discuss.
> 
> I'm having a hard time figuring out how a VMM should handle a new
> hypercall identity register introduced on a newer kernel. In order to
> maintain guest ABI, the VMM would need to know about that register and
> zero it when restoring an older guest.

Just as it would need to be able to discover any new system register
exposed by default, as it happens at all times. Which is why we have a
way to discover all the registers, architected or not.

> Perhaps instead we could reserve a range of firmware registers as the
> 'hypercall identity' registers. Implement all of them as RAZ/WI by
> default, encouraging userspace to zero these registers away for older
> VMs but still allowing an old userspace to pick up new KVM features.
> Doing so would align the hypercall identity registers with the feature
> ID registers from the architecture.

The range already exists in the form of the "coprocessor" 0x14. I
don't see the need to expose it as RAZ/WI, however. If userspace
doesn't know about how this pseudo-register works, it won't be able to
program it anyway.

I don't buy the parallel with the ID-regs either. They are RAZ/WI by
default so that they don't UNDEF at runtime. The meaning of a RAZ
id-register is also well defined (feature not implemented), and the
CPU cannot write to them. In a way, the ID-regs *are* the enumeration
mechanism.

Our firmware registers don't follow the same rules. Userspace can
write to them, and there is no such "not implemented" rule (case in
point, PSCI). We also have a separate enumeration mechanism
(GET_ONE_REG), which is (more or less) designed for userspace to find
what is implemented.

For these reasons, I don't immediately see the point of advertising a
set of registers ahead of time, before userspace grows an
understanding of what these registers mean.

Thanks,

	M.

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