Re: [PATCH v4 05/11] KVM: LUO: Support VM preservation across live updates

[Sean Christopherson <seanjc@google.com>]

On Sat, Aug 15, 2026, Pratyush Yadav wrote:
> On Wed, Aug 12 2026, Sean Christopherson wrote:
> > On Wed, Aug 12, 2026, Pratyush Yadav wrote:
> >> This is ABI between kernels. It needs to be stable-ish so you can move
> >> from one kernel version to another. At the same time, unlike userspace
> >> ABI, it can change.
> >
> > Uh, yeah, so KVM has been managing such immutable ABI for practically its entire
> > existence.  KVM's save/restore uAPI has exactly what you're describing: serialization
> > ABI that needs to be backwards and forwards compatible between different kernels
> > in order to support both upgrade and rollback scenarios via live migration.
> 
> I think there is a slight difference between KVM's save/resture uAPI and
> live update's ABI. With KVM's uAPI, you need to maintain strict
> backwards compatibility because userspace reads what you output. So if
> you change the layout, userspace will interpret it wrong and might
> break.
> 
> With live update, the ABI never gets to userspace. It is used to talk
> between kernels directly. So if you do break that, your userspace keeps
> working fine, you just might not be able to live update to the
> incompatible kernel.
> 
> So with live update, we don't need to keep backwards compatibility in
> the ABI forever. Of course, it is good to minimize changes, but we have
> more freedom to change it.

Ah.  So this is the heart of the disconnect.  I very strongly disagree with the
statement that live update doesn't need to support backwards compatibility.  I
can totally believe that the folks working on live update are ok breaking backwards
compatibility because their use cases are "fine" with such breakage.  And I can
also believe live update as an upstream kernel feature being developed by those
same folks is also ok with breaking backwards compatibility.

But with my upstream KVM maintainer hat on, I am not ok with that.  I did not agree
to support a world where KVM is allowed to break backwards compatibility, so long
as it's done "carefully" or whatever.  If y'all want to deal with the resulting
complexity, that's fine by me, but you'll be doing it without KVM.

I totally understand that exploratory work and initial development is best done
in private and/or in a small working groups.  But decisions that will significantly
impact multiple subsystems need to be made *with* those subystems.  I mean,
obviously it's possible to make a decision in a small group and then "publish"
the result later, but then as is happening here, the community and subsystem
maintainers like me may refuse to play ball if they disagree.

To be very clear, for any KVM live update support that doesn't guarantee backwards
compatibility (allowing that bugs happen), a very firm:

NAK