On Mon, 2026-05-11 at 17:14 +0200, Paolo Bonzini wrote: > On 5/11/26 10:57, David Woodhouse wrote: > > From: David Woodhouse <[email protected]> > > > > 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.
smime.p7s
Description: S/MIME cryptographic signature
