Re: [RFC PATCH] liveupdate: list all file handler versions in vmlinux section

[Jason Gunthorpe <jgg@nvidia.com>]

On Mon, Dec 29, 2025 at 10:28:32PM +0100, Pratyush Yadav wrote:
> On Sat, Dec 13 2025, Alexander Graf wrote:
> 
> > Hi Pratyush,
> >
> > On 10.12.25 20:26, Pratyush Yadav wrote:
> >> As live update evolves, there will be a need to update the serialization
> >> formats for the different file types. This could be for adding new
> >> features, for supporting a change in behaviour, or to fix bugs.
> >>
> >> If the current kernel does not understand the same set of versions as
> >> the next kernel, live update will inevitably fail. The next kernel will
> >> be unable to understand the handed over data and will be unable to
> >> restore memory, devices, IOMMU page tables, etc.
> >>
> >> List the set of versions the kernel understands in a section in vmlinux.
> >> This can then be used by userspace tooling to make sure the set of file
> >> descriptors it uses have the same version between both kernels. If there
> >> is a mismatch, the tooling can catch this early and abort live update
> >> before it is too late.
> >>
> >> The versions are listed in a section called ".liveupdate_versions". The
> >> section has a header that contains a magic number and the version of the
> >> data format. The list of version strings directly follow this header.
> >> Only the version strings are listed, and it is up to userspace to map
> >> them to file descriptor types.
> >>
> >> The format of the section has the same ABI rules as the rest of LUO ABI.
> >>
> >> Introduce a LIVEUPDATE_FILE_HANDLER macro that makes it easy to define a
> >> file handler while also adding its version string to the right section.
> >>
> >> Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
> >
> > To support multi-version preservation and resume, how about you add a "profile"
> > hint to the handlers? Then you can tag the handlers with "current" and a
> > "previous". You then expose one section table with supported versions per
> > profile. And that means you can from user space select the local profile to
> > serialize and match that against the target profile of the target system.
> >
> > It also allows you to support more "profiles", such as elaborate downstream
> > version combinations, that upstream will not have to care about.
> 
> So in essence you want to tie the versions into a "version set"? If you
> want to use a new version even for one component, you would create a new
> version set.
> 
> Interesting idea, but I am curious. Do you see a reason for grouping
> versions together in this fashion? Why not let each version be changed
> independently?

I don't quite get the point either..

I think the ELF annotations are intended to give information to the
userspace, but ultimately I think we should just rely on the userspace
to implement anything complicated about compatibility policy.

We also have the issue that not all versions *at runtime* are going to
be supportable. Older versions may be information loosing and cannot
be emitted based on the current system configuration.

So to really make this work you have to dynamically query the current
kernel, and cross that with the elf data from the next and try to
cobble together a working set.

IMHO most likely real users are going to want to latch onto fixed
"profiles" and globally bump the profile cluster wide along with
activating VMMs to consume new features enabled by the newer versions.

There may be an early churn when we bump versions because we are
messing things up, but the long term steady state will probably be new
version = required if new features were used by the VMM

Thus the version used for serializing and the features active in the
VMMs should be linked together by the operator.

Jason