Re: [PATCH] Documentation: KVM: Document guest-visible compatibility expectations

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 2432 bytes --]

On Mon, 2026-05-11 at 17:14 +0200, Paolo Bonzini wrote:
> On 5/11/26 10:57, David Woodhouse wrote:
> > From: David Woodhouse <dwmw@amazon.co.uk>
> > 
> > Document the expectation that KVM maintains guest-visible compatibility
> > across host kernel upgrades and rollbacks.  Specifically:
> > 
> >   - State saved/restored via KVM ioctls must be sufficient for live
> >     migration (and live update) between kernel versions.
> > 
> >   - Where a new kernel introduces a guest-visible change, it provides a
> >     mechanism for userspace to select the previous behaviour.
> > 
> >   - This allows both forward migration (upgrade) and backward migration
> >     (rollback) of guests.
> > 
> > These expectations have been implicitly required on x86 but were not
> > explicitly documented. Harmonise the expectations across all of KVM.
> 
> One big part of achieving this on x86 is the handling of CPUID.  Despite 
> all the mess that KVM_SET_CPUID2 is (and sometimes the underlying 
> architecture too, as Jim Mattson would certainly agree), KVM is 
> generally able to provide a consistent view of its configuration to the 
> guest.  This doesn't quite extend to compatibility across vendors, but 
> it does work across processor generations from either Intel or AMD.

Right. For x86 this is largely covered by CPUID. If you launch a guest
on a new kernel, using the same CPUID bits as an older kernel, then
your guest will mostly not see anything new. And will be migratable to
that older kernel without issue.

Not *everything* is in CPUID; one recent exception that comes to mind
is the SUPPRESS_EOI_BROADCAST quirk. But on x86 we preserve the
existing behaviour of older kernels — even when that behaviour doesn't
make much sense, as with SUPPRESS_EOI_BROADCAST where older KVM would
*advertise* the feature, but not actually *implement* it. Nevertheless,
that remains the default behaviour of future kernels unless userspace
explicitly opts in to fully enable (or disable) the feature.

But this documentation update isn't even asking for that compatible-by-
default behaviour, even though that is the right thing to do. It's only
asking that it be *possible* to reinstate the old behaviour, for
userspace that *knows* about the change and explicitly wants to go back
to the old way to remain compatible.

And sadly, KVM/arm64 doesn't even meet *that* low bar.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]