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

[David Woodhouse]

On Thu, 2026-09-10 at 19:57 -0300, 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, just the version should have the
> feature mechanism layered under it? I'm fine with that

Seems reasonable. I'd note that downgrade support *is* important though.

So where possible, those new features which are inherently incompatible
should be opt-out. That way the admin can disable them when first
upgrading to a new kernel version, and enable them only in a
*subsequent* update, once that new kernel version has actually rolled
out successfully.

Again, it's OK if we sometimes can't manage that, but not if it happens
just because of poor design, as Sean said above.

The thing that *really* concerns me here though, is latency. When we
pause guests and kexec underneath them, every *millisecond* is
perceived as steal time. I worry that we're designing handover
protocols to look *pretty*, and not necessarily go *fast* enough.

I'd really love to see these patch series come in with benchmarks.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6179 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/kexec/attachments/20260911/e49beb91/attachment.p7s>