Message-ID: <86sed5j0db.fsf@kernel.org>
Date: Sat, 20 Dec 2025 12:30:40 +0900
From: Pratyush Yadav <pratyush@...nel.org>
To: Evangelos Petrongonas <epetron@...zon.de>
Cc: Pratyush Yadav <pratyush@...nel.org>,  Arnd Bergmann <arnd@...db.de>,
  Pasha Tatashin <pasha.tatashin@...een.com>,  Mike Rapoport
 <rppt@...nel.org>,  Andrew Morton <akpm@...ux-foundation.org>,  Dan
 Carpenter <dan.carpenter@...aro.org>,  Jason Gunthorpe <jgg@...dia.com>,
  Samiullah Khawaja <skhawaja@...gle.com>,  David Matlack
 <dmatlack@...gle.com>,  David Rientjes <rientjes@...gle.com>,  Jason Miu
 <jasonmiu@...gle.com>,  <linux-arch@...r.kernel.org>,
  <linux-kernel@...r.kernel.org>,  <linux-mm@...ck.org>,
  <kexec@...ts.infradead.org>
Subject: Re: [RFC PATCH] liveupdate: list all file handler versions in
 vmlinux section

On Tue, Dec 16 2025, Evangelos Petrongonas wrote:

> On Thu, Dec 11, 2025 at 01:26:22PM +0900 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@...nel.org>
>> ---
>> 
>> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
>> index e04d56a5332e..a474c9529a5f 100644
>> --- a/include/asm-generic/vmlinux.lds.h
>> +++ b/include/asm-generic/vmlinux.lds.h
>> @@ -342,6 +342,17 @@ defined(CONFIG_AUTOFDO_CLANG) || defined(CONFIG_PROPELLER_CLANG)
>>  #define THERMAL_TABLE(name)
>>  #endif
>>  
>> +#ifdef CONFIG_LIVEUPDATE
>> +#define LIVEUPDATE_VERSIONS						\
>> +	. = ALIGN(8);							\
>> +	.liveupdate_versions : AT(ADDR(.liveupdate_versions) - LOAD_OFFSET) {	\
>> +		KEEP(*(.liveupdate_sec_hdr))				\
>> +		KEEP(*(.liveupdate_versions))				\
>> +	}
>> +#else
>> +#define LIVEUPDATE_VERSIONS
>> +#endif
>> +
>>  #define KERNEL_DTB()							\
>>  	STRUCT_ALIGN();							\
>>  	__dtb_start = .;						\
>> @@ -544,6 +555,7 @@ defined(CONFIG_AUTOFDO_CLANG) || defined(CONFIG_PROPELLER_CLANG)
>>  	RO_EXCEPTION_TABLE						\
>>  	NOTES								\
>>  	BTF								\
>> +	LIVEUPDATE_VERSIONS						\
>>  									\
>>  	. = ALIGN((align));						\
>>  	__end_rodata = .;
>> diff --git a/include/linux/kho/abi/luo.h b/include/linux/kho/abi/luo.h
>> index 4a1cc6a5f3f8..57ef75695f62 100644
>> --- a/include/linux/kho/abi/luo.h
>> +++ b/include/linux/kho/abi/luo.h
>> @@ -244,4 +244,38 @@ struct luo_flb_ser {
>>  #define LIVEUPDATE_TEST_FLB_COMPATIBLE(i)	"liveupdate-test-flb-v" #i
>>  #endif
>>  
>> +#define LIVEUPDATE_VER_HDR_MAGIC 0x4c565550 /* 'LVUP' */
>> +#define LIVEUPDATE_VER_HDR_VER   1
>> +
>> +/**
>> + * struct liveupdate_ver_hdr - Header of vmlinux section with version lists
>> + * @magic:     Magic number.
>> + * @version:   Version of the header format.
>> + *
>> + * This struct is the header for the vmlinux section ".liveupdate_versions". The
>> + * section contains the list of file handler versions that the kernel can
>> + * support.
>> + */
>> +struct liveupdate_ver_hdr {
>> +	u32 magic;
>> +	u32 version;
>> +};
>
> I believe we are going to have two main classes of LUO objects that are
> going to participate in Liveupdates, when it comes to their criticality
>
> - Core/Mandatory components. Theese components are necessary for the
> kexec to be succesfull. Think components like IOMMU page tables, as
> you have mentioned.
>
> - Acceleration/Optional Components. As we strive to minimise the blackout
> time, we will trying to persist more and more state across kexec, that
> are currently being initialised from scratch during boot. Thing of
> certain optimisation like PCI onboarding (at least parts of it)
> and the PCI Config Space Cache. If theese components are incompatible
> between versions, we might still want to proceed, with the LU, at the
> cost of increased blackout time.
>
> I believe it will be quite usefull to be able to have the ability
> to differentiate between the two.

I agree that it would be useful. But I've been thinking about this for a
bit. I think it will be hard for the kernel to judge what is a mandatory
component and what is an optional one. There might be some setups where
you would deem some PCI devices as mandatory and some as optional. I
don't think we should even try to encode that kind of policy in the
kernel.

So I think we need a UAPI for userspace to tell us what is mandatory.
That is more UAPI exposure. Dunno if now is the right time to take
that, before we know more how this works out in practice...

[...]

-- 
Regards,
Pratyush Yadav

Powered by blists - more mailing lists