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

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Aug 18, 2026 at 09:02:17AM -0700, Sean Christopherson wrote:
> On Tue, Aug 18, 2026, Pratyush Yadav wrote:
> > Hi Sean,
> > 
> > On Mon, Aug 17 2026, Sean Christopherson wrote:
> > 
> > > On Sat, Aug 15, 2026, Pratyush Yadav wrote:
> > >> On Wed, Aug 12 2026, Sean Christopherson wrote:
> > >> > On Wed, Aug 12, 2026, Pratyush Yadav wrote:
> > >> 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.
> > 
> > Let's step back a bit. I don't think backwards compatibility in the
> > _ABI_ is all that important in live update's context. What is important
> > is that our users are able to live update from kernel version X to Y.
> > The line format the kernel uses to describe its state is an
> > implementation detail. Our users never see it.
> 
> The rule is thou shalt not break userspace.  Whether or not the
> breakage is the result of an explicit ABI change is irrelevant.

I argued strongly for this simpler approach, I will write here the
reasoning I gave.

Firstly, "live update" is not uABI per-say. It is not "userspace
breaking", and it is not a "regression". It is an internal kernel
mechanism to allow the kernel to self-upgrade. In the industry it is
typical any of these hitless update/patch/etc schemes to only work
between a few tightly controlled version pairs.

Asking upstream to carry a full matrix of every single version pair
ever released is massive over-engineering and cost on upstream
maintainers. Refusing to do this is not a uABI breakage, it is not a
regression, it is simply a lack of a feature.

I think upstream should start by agreeing to only support forward
going upgrades within a single stable branch. If live update becomes a
success then maybe we could do from a stable branch to the immediate
next stable branch too. I don't know.

This alone is already much more powerful than live patching.

The balancing issue here is the impact on the kernel subsystems
adopting luo. Every time you change anything about the internal
function of the subystem you now have to go test a massive version
pair matrix to make sure everything works? No thanks.

Luo is very invasive and a huge PITA at the best of times. It doesn't
need to be even worse.

> It's probably fine for Google and other large companies that tightly
> control their kernels and use cases, and have the resources to
> juggle the resulting complexity, e.g. have kernel engineers on staff
> to track feature and dependencies, coordinate and plan kernel
> upgrades, etc.

Every downstream that wants to support luo is going to necessarily
severely restrict the version pairs that can work. Like a RH type
distro may only support it for 9.1.x -> 9.1.x+1 - they can carry the
cost of figuring out how to manage their patching and compatability
matrix on their own with the tools upstream provides.

> engineers on staff to help them thread the needle you describe
> above.  And if supporting live update as a general feature for all
> users of the kernel isn't being factored into design considerations,
> then that needs to change, otherwise this is all dead in the water.

General uses can use upstream and do CVE upgrades within a single
stable branch. That's good enough, lets start there. We don't need to
boil the ocean.

> I also don't see the point.  Maintaining a rigid save/restore ABI is
> annoying, but it's not _hard_ (or at least, not _that_ hard),
> especially if there's a set

I was told KVM had the smallest luo footprint of everything, so
perhaps your perspective is different.

In other places luo becomes coupled to the internal datastructures of
the kernel, we literally have to preserve lots of kernel memory
utterly unchanged without any kind of serialization at all. This
inevitably creates restrictions on the evolution of the kernel in
general if we can no longer change in-kernel architecture because it
would make some data structure incompatible with a kernel 10 years
old.

There is also a need for *downgrade*. Meaning the N+1 kernel has to
strictly emulate the limitations and capabilities of the N kernel so
it can be rolled back. Can you imagine the nightmare of trying to
codify the feature progression for every single kernel release forever
in some impossible scheme to enable this? Again, no thanks.

So, what upstream can reasonably do, that still provides real value
without severely burdening every subsystem, is upgrades within a
stable kernel branch only.

If some distro or CSP wants to do more, they can deal with it. They
have a far, far simpler problem because they can exactly lock down
their version pairs to a very small universe. They don't need a single
kernel that can emulate 10 different releases of behaviors
concurrently.

Jason