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

On 2026-09-10 02:12 PM, Jason Gunthorpe wrote:

On Thu, Sep 10, 2026 at 08:35:54AM -0700, Sean Christopherson wrote:

quoted

I guess maybe we have a different definition of ABI? 

I'm not saying that upstream has to be 100% forwards and backwards compatible.
I'm saying the serialization payload itself should communicate what features are
effectively required.  I.e. *if* there are incompatibilities, they should be
naturally expressed in the serialization format, not communicated out-of-band
through magic numbers.

The ABI strings were introduced specifically because extension makes
the actual compatibility indeterminate by userspace. 

Keep in mind the actual goal here. Someone has kernel A and they need
to blind kexec into kernel B and NOT have the machine explode, or all
the VMs sitting on it lost.

Meaning you must have a way to determine before the kexec if kernel A
is producing something B will *accept*. Accept is not "parse and fail
with EOPNOTSUPP" like most uapi schems. Aceept means bring in and
actually fully support and use.

So how do you solve this problem? You MUST declare in some kind of
manifest exactly what ABIs are supported, in some way.

I think this series solves this problem in a fairly clean way without
relying on version numbers.

Each ABI is now extensible with a set of structured featured flags that
are exposed to userspace. Userspace can inspect the flags that the
kernel supports and confirm the next kernel also supports them.

I think there is still room for improvement, like determining what
features are used at runtime rather than statically at compile time, or
allowing userspace to disable use of certain features to control
compatability, but I think these things can be built into this type of
model.

quoted

The scenario you describe fits exactly with what I am proposing.  

It does not. What is really wanted here is to tell kernel A to only
support ABI 1 for memfd and so kernel A will fail to serialize if it
cannot do it because a newer seal flag was used.

We do not want to succeed to serialize then fail to accept after
kexec and have a dead machine.

This is not anything like a normal uapi compatability problem.

quoted

actually starts using the new sealing flag, the CSP can downgrade to
older kernels at will.  And if the user cares about downgrading,
then they need to prevent the flag from being used until the new
kernel is rollback-safe and deployed to enough hosts to prevent
stockout.

Yeah, CSP broadly has to do exactly this across a wide range of
topics. It is a further reason why this feature is not exactly usable
by a "mainstream" user :\

quoted

quoted

This is why I think the very idea we can support any version pair is
too much to ask for. We should focus on supporting a small set of
version pairs and not making it too invasive or hard in the kernel or
on the maintainers.

Thus live update within a stable branch only is my proposal for
upstream support.

If it really succeeds at that and it becomes very popular, then let's
discuss upstreaming doing additional version combinations.

Why on earth would we have version numbers in the first place?  IMO, monotically
increasing version numbers are flat out the worst way to communicate
features.

As above, discoverablility is a key requirement.

Each version number is a very specific upstream defined ABI, in the
sense if kernel A emits version X and kernel B accepts version X then
kexec *must* work.

You can make some manifest in other more complicated ways, but I'm
deeply skeptical that is really going to bring any value. It feels
like it is just increasing the testing matrix :\

The value I see of the flag-based approach over the version-based
approach is:

 - Each component can have one ABI struct that extends over time and one
   serialization/deserialization routines, rather than N for the N
   supported current versions. Supporting multiple versions within a
   single kernel would be required for upgrade/downgrade. Maybe there is
   a way to make the multi-versioning support maintainable but it seems
   like it will be messy to me.

 - Features can be managed individually. Let's say a downstream user
   wants to use a new upstream feature. If we had a versioning model
   they would have to backport the entire version delta from their
   current kernel to that feature upstream. With flags they can backport
   and use an individual feature.

I agree testing matrix becomes more complex but maybe that can be
mitigated with your suggestion that upstream only "officially" supports
(i.e. tests) some constrained version sets like within a stable branch?

quoted

quoted

quoted

I could see things like HugeTLB not working if someone booted the kernel with
support for only 1GiB pages and then tried to feed it payload with sub-1GiB ranges.
But to me, those sorts of things fall into the "well yeah, don't do that" category.

Okay, how about worse, todays kernel has hugetlbfs and there are
patches around to luo serialize that. Lots and lots of talks about a
post-hugetlbfs world out there.

And?  Adding a compatibility layer to a future kernel so that it
understands an incoming HugeTLBFS payload should be trivial.

From my experience that's optimistic :(

quoted

quoted

Do we want to constrain what is possible to ensure we accomodate this
hugetlbfs serialization? I vote no.

In what way is providing strong ABI guarantees for individual components
constraining HugeTBLFS serialization?

I bet it will. Other things we've looked at seemed to be like that.
Even the above about "yall screwed up" with memfd has the problem
already. I don't believe we can ever do this so right that it won't be
constraining to the kernel internals.

quoted

quoted

Do we want to reject the hugetlbfs serialization until we have a year
of debate outlining every possible ABI scenario? I also vote no.

That's a bit of a strawman argument.  Is designing a forward-looking ABI easy?
No, but IMO "a year" is a massive exaggeration of the effort required to come up
with a scheme that can survive a variety of plausible upgrade/downgrade scenarios.

Have you tried to get anything merged into the kernel lately? I've got
lots of uncontroversial stuff pushed out past 4 months already. Some
luo patches are close to a year already and don't even have any
controversy.

quoted

And again, I'm not saying we have to support infinite compatibility.  

Okay, I said same stable branch only, do you have some wider
limitation in mind?

quoted

quoted

Should we make a downgrade round trip a downstream problem? I think
so!

Hard NAK.  There will inevitably be boundaries that cannot be crossed, but I am
not at all ok punting on downgrades.  To me, that's basically saying "we want to
add just enough support upstream so that it's not too painful to carry full support
out-of-tree".  That completely goes against the spirit of open source and upstream
Linux, and I want no part of it.

I generally agree with you sentiment, but I think this is a unique
case. I've asked around a fair bit, this is sufficiently complicated,
requires alot of userspace that the CSPs are not open sourcing so has
a very minimal usage foot print out side their world. I found one
other possible user that might be more open source oriented..

So, if I was feeling unreasonable I'd say stay out of the upstream
kernel entirely.

Though, I think this could grow and maybe some open source ecosystem
will develop around it. I don't know. I'm willing to give it a
chance.

HOWEVER upstream is not some kind of free outsourcing for the CSP's
proprietary forks! Do not ask maintainers to do significant and
burdensome work that only a CSP is ever going to consume and can only
really work in a closed proprietary environment. There is no "spirit
of open source" in that kind of demand. I will be NAKing anything like
that in my subsystems, I am not signing up to do live update stable
ABI so the CSPs alone can have a better proprietary product.

This is how I come to my conclusion that upstream should support same
stable branch only at this point. It minimizes the burden, it is a
decent trail of the technology, and if things go well with a quality
open ecosystem then sure, upstream can change its mind.

Jason