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

[Jason Gunthorpe]

On Fri, Sep 11, 2026 at 06:44:50AM -0700, Sean Christopherson wrote:
> On Thu, Sep 10, 2026, Jason Gunthorpe wrote:
> > On Thu, Sep 10, 2026 at 03:42:36PM -0700, Sean Christopherson wrote:
> > > On Thu, Sep 10, 2026, Jason Gunthorpe wrote:
> > > > Sean's initial email was asking for strict never-break ABI compatability
> > > > rules on top, and that is what I've been reacting to.
> > > 
> > > No, I was never asking for that.  I think we just have a different interpretation
> > > of ABI, or rather are talking about different pieces of ABI.
> > > 
> > > I am still asking for never-break serialization format compatibility, i.e. the
> > > more literal save/restore ABI.  I'm not asking for full backwards/forwards
> > > compatibility across all kernels version, i.e. the higher level "kernel" ABI.
> > > 
> > > To phrase things differently: I am a-ok if kernels are inherently incompatible
> > > because they fundamentally operate differently and/or support different features.
> > > I am not ok if we end up with incompatible kernels because the save/restore
> > > interfaces and payloads are poorly designed, lack abstraction, etc.  
> > 
> > I can more agree with this, it is mostly what I thought we'd end up
> > doing anyhow with version numbers and growing the structs not
> > replacing them.
> > 
> > So you still end up with a version label (string I guess?) because we
> > can break it from time to time, 
>    
> Why bother with a label/string?  I don't understand what it buys us; I see only
> pain.  Make the features discoverable and punt on all of the "is this pile of
> insanity my company has created compatible with this other pile of insanity?" to
> layers above the kernel.

It is one layer above, the serialization ends up with 10 memfds a
couple iommus, kvm, pci device, etc, etch. Each one starts with a
string label saying what it even is - to dispatch it to the proper
de-serialization code, then some detail about where it is (eg a handle
to recover a FD later) and then the actual object serialization
data itself.

So the features are fine to handle the ABI within the object and a
memfd-v1, memfd-v2 is fine to handle labeling the object within the
stream and gives us an option to reboot the ABI if some reason comes
up someday.

If features are a perfect success then we will never need to go beyond
memfd-v1. I'm just saying we should have the option and plan for it.

Jason