Re: [RFC PATCH 0/3] liveupdate: Move to feature flags for LUO and memfd ABI compatibility

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Sep 11, 2026 at 07:16:23PM +0200, Paolo Bonzini wrote:

> Rather, forwards kexec *must* work (again, that's nothing but a variant of
> "we don't break userspace") and for backwards kexec, well, you must know
> what you're doing.

Again, I strongly disagree with this MUST. This is not a variant of
"we don't break userspace". It is internal kabi and the kernel gets to
decide which versions it supports. There are no promises here. It is
not a breaking change to say we won't support A->B.

Community needs to agree on what these parameters are. I've been clear
my stake in the ground is same stable version only as a starting point.

This is typical in the industry, nobody does live update where you can
jump ahead multiple years of versions. Sequential releases only is
very normal.

> QEMU has been doing backwards live migration forever, and QEMU is a
> gnarly C program that has grown by accretion as we were learning all
> this stuff, so it's not impossible at all.

I agree it is not impossible, you can always make things harder and
more complicated to keep it working. I don't want the kernel to turn
into a "gnarly C program" because we over engineered this.

> It's not easy, but you aren't even trying to do it right in the kernel. You

Right, I've been pretty clear about this, I want to start with
same-stable-version only and if that works out then consider if we
want to do more.

I am not doing this for any sort of technical reason. Not because it
is impossible, but because it is HARD. I do not want to force anyone
to take on hard and difficult projects like this for a niche feature
only a few CSPs are likely to use. If we take this approach LUO will
fail because maintainers will be scared to take on this extra work and
simply won't merge LUO patches.

There needs to be some balance that we can try this out and see if a
broader use case develops before we commit to doing the hardest
possible version of it.

A niche feature only for CSPs like live update must not become a boat
anchor on kernel progress!

> fact!  It's just that you're solving for the wrong complexity, and only
> partially so because (if I'm not wrong) there's still the question of how to
> bring the manifest of kernel B into kernel A.

There is a proposal to encode information into ELF sections. Feature
flags should flow through there just fine, I think.

I have not seen a proposal to re-inject this information back into the
A kernel as a 'restriction' so it fails luo instead of producing
something unsupported.

Jason