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

[Sean Christopherson <seanjc@google.com>]

On Fri, Sep 04, 2026, Jason Gunthorpe wrote:
> On Tue, Aug 18, 2026 at 09:02:17AM -0700, Sean Christopherson wrote:
> > 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.

From that perspective, what I am proposing actually goes a step further.  I'm
saying don't commit to supporting *any* specific versions in upstream.  Express
the feature requirements in the serialization payloads, and let userspace sort
out what kernels are compatible based on their actual usage.  The kernel may need
to provide additional discovery mechanisms, e.g. so that userspace can probe to
see what is supported, but discovery is usually fairly simple to implement and
maintain.

> 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.

No, the subsystem just needs to make sure that it serializes its data using the
defined ABI (where ABI here means the format of the payload and the meaning of
any flags in the header).  That should be *easier* for maintainers to handle than
trying to support arbitrary versions, because it eliminates subjectivity and
having to make judgment calls or remember magic version numbers.

> 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.

We're in violent agreement on this point, I think we just disagree on how to
express compatibility.

> > 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.

Only because KVM already has a massive ABI surface for save/restore.  If you
want to convince me that magic version numbers are the right approach, then show
me how KVM's existing save/restore support would be made "better" and easier to
maintain by throwing away all of KVM's save/restore uAPI and replacing it with a
versioning scheme.

> 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. 

Have to, or choose to?  I have a very, very hard time believing that it's infeasible
to define a serialization format that is decoupled from kernel internals.

> 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.

Only if the relevant subsystem defined a poor save/restore ABI in the first place.

> 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