From: Pratyush Yadav <pratyush@kernel.org>
To: Logan Odell <loganodell@google.com>
Cc: arnd@arndb.de, pasha.tatashin@soleen.com, rppt@kernel.org,
pratyush@kernel.org, graf@amazon.com,
akpm@linux-foundation.org, pbonzini@redhat.com, maz@kernel.org,
oupton@kernel.org, seanjc@google.com, bhelgaas@google.com,
alex@shazbot.org, jgg@nvidia.com, kevin.tian@intel.com,
dwmw2@infradead.org, baolu.lu@linux.intel.com, joro@8bytes.org,
will@kernel.org, robin.murphy@arm.com,
linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
kexec@lists.infradead.org, linux-mm@kvack.org,
kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
kvmarm@lists.linux.dev, linux-pci@vger.kernel.org,
iommu@lists.linux.dev
Subject: Re: [RFC PATCH 2/3] luo: Export feature support to vmlinux section
Date: Thu, 15 Oct 2026 15:05:26 +0200 [thread overview]
Message-ID: <2vxzv773glm1.fsf@kernel.org> (raw)
In-Reply-To: <20260903023452.721732-3-loganodell@google.com> (Logan Odell's message of "Wed, 2 Sep 2026 19:34:51 -0700")
Hi Logan,
On Wed, Sep 02 2026, Logan Odell wrote:
> Create a liveupdate_features section that contains the feature
> information for a given liveupdate component. Add the LUO component
> first. These can be compared between two kernels to determine live
> update compatibility. Features marked as required in the running kernel
> will need to have that feature marked as supported in the next kernel to
> be eligible for compatibility.
>
> Suggested-by: Pratyush Yadav <pratyush@kernel.org>
> Signed-off-by: Logan Odell <loganodell@google.com>
I was thinking about this a bit more. We don't really ship the vmlinux
directly. On x86 it is a PE/COFF image, on arm64 the Image format strips
ELF information and is a raw binary file.
So this information would not be accessible to the kexec loader/luod. So
perhaps as part of the build we parse the section and output a file with
the versions? And then it can be packaged with the likes of System.map
for example?
> ---
> include/asm-generic/vmlinux.lds.h | 12 +++++++++++
> include/linux/kho/abi/luo.h | 34 +++++++++++++++++++++++++++++++
> include/linux/liveupdate.h | 12 +++++++++++
> kernel/liveupdate/luo_core.c | 16 +++++++++++++++
> 4 files changed, 74 insertions(+)
>
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index 5659f4b5a125..aed4e282a78c 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -359,6 +359,17 @@
> #define THERMAL_TABLE(name)
> #endif
>
> +#ifdef CONFIG_LIVEUPDATE
> +#define LIVEUPDATE_FEATURES \
> + . = ALIGN(8); \
> + .liveupdate_features : AT(ADDR(.liveupdate_features) - LOAD_OFFSET) { \
> + KEEP(*(.liveupdate_sec_hdr)) \
> + KEEP(*(.liveupdate_features)) \
> + }
> +#else
> +#define LIVEUPDATE_FEATURES
> +#endif
> +
> #define KERNEL_DTB() \
> STRUCT_ALIGN(); \
> __dtb_start = .; \
> @@ -554,6 +565,7 @@
> RO_EXCEPTION_TABLE \
> NOTES \
> BTF \
> + LIVEUPDATE_FEATURES \
> \
> . = ALIGN((align)); \
> __end_rodata = .;
> diff --git a/include/linux/kho/abi/luo.h b/include/linux/kho/abi/luo.h
> index 0a7662a0cf9a..5b25e1b48cf5 100644
> --- a/include/linux/kho/abi/luo.h
> +++ b/include/linux/kho/abi/luo.h
> @@ -230,4 +230,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 ('LVUP').
> + * @version: Version of the header format.
> + *
> + * This struct is the header for the vmlinux section ".liveupdate_features". The
> + * section contains the list of feature/version entries that the kernel supports.
> + */
> +struct liveupdate_ver_hdr {
> + u32 magic;
> + u32 version;
Should we do feature flags along with the version to extend in
backwards-compatible way?
> +} __packed;
> +
> +/**
> + * struct liveupdate_feature_entry - Live update feature/version entry
> + * @name: Name of the subsystem or feature ("luo" for core).
> + * @feat_bytes: Number of bytes covered by supp, req, and active bitmaps (e.g. 8).
> + * @reserved: Reserved / padding for alignment.
> + * @supp: Bitmask of supported features.
> + * @req: Bitmask of required features.
> + * @active: Bitmask of active features.
> + */
How should we model FLB dependencies here? And how do we export FLB
capabilities?
> +struct liveupdate_feature_entry {
> + char name[LIVEUPDATE_HNDL_COMPAT_LENGTH];
> + u32 feat_bytes;
> + u32 reserved;
> + u64 supp;
> + u64 req;
> + u64 active;
> +} __packed;
> +
> #endif /* _LINUX_KHO_ABI_LUO_H */
> diff --git a/include/linux/liveupdate.h b/include/linux/liveupdate.h
> index 6051abc0612c..e058df23fed1 100644
> --- a/include/linux/liveupdate.h
> +++ b/include/linux/liveupdate.h
> @@ -229,6 +229,16 @@ struct liveupdate_flb {
>
> #ifdef CONFIG_LIVEUPDATE
>
> +#define LIVEUPDATE_FEATURE_ENTRY(_id, _name, _supp, _req, _active) \
> + static const struct liveupdate_feature_entry __lu_feat_##_id \
> + __used __section(".liveupdate_features") __aligned(8) = { \
> + .name = _name, \
> + .feat_bytes = sizeof(u64), \
> + .supp = (_supp), \
> + .req = (_req), \
> + .active = (_active), \
> + }
> +
> /* Return true if live update orchestrator is enabled */
> bool liveupdate_enabled(void);
>
> @@ -259,6 +269,8 @@ int liveupdate_get_token_outgoing(struct liveupdate_session *s,
>
> #else /* CONFIG_LIVEUPDATE */
>
> +#define LIVEUPDATE_FEATURE_ENTRY(_id, _name, _supp, _req, _active)
> +
> static inline bool liveupdate_enabled(void)
> {
> return false;
> diff --git a/kernel/liveupdate/luo_core.c b/kernel/liveupdate/luo_core.c
> index 6add1ecc463f..27413f895174 100644
> --- a/kernel/liveupdate/luo_core.c
> +++ b/kernel/liveupdate/luo_core.c
> @@ -64,6 +64,22 @@
> #include "kexec_handover_internal.h"
> #include "luo_internal.h"
>
> +/*
> + * This is the header for the ".liveupdate_features" section in vmlinux.
> + * The linker makes sure that this header precedes the entries.
> + */
> +static const struct liveupdate_ver_hdr ver_hdr
> + __used __section(".liveupdate_sec_hdr") __aligned(8) = {
> + .magic = LIVEUPDATE_VER_HDR_MAGIC,
> + .version = LIVEUPDATE_VER_HDR_VER,
> +};
> +
> +/* Core LUO features */
> +LIVEUPDATE_FEATURE_ENTRY(luo_core, "luo",
> + LUO_CORE_FEATURES_SUPP,
> + LUO_CORE_FEATURES_REQ,
> + LUO_CORE_FEATURES_ACTIVE);
> +
> static struct {
> bool enabled;
> struct luo_ser *luo_ser_out;
--
Regards,
Pratyush Yadav
next prev parent reply other threads:[~2026-10-15 13:05 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 2:34 [RFC PATCH 0/3] liveupdate: Move to feature flags for LUO and memfd ABI compatibility Logan Odell
2026-09-03 2:34 ` [RFC PATCH 1/3] luo: Move to feature flags instead of compatibility strings Logan Odell
2026-09-03 2:43 ` sashiko-bot
2026-10-15 12:21 ` Pratyush Yadav
2026-10-15 15:07 ` tarunsahu
2026-09-03 2:34 ` [RFC PATCH 2/3] luo: Export feature support to vmlinux section Logan Odell
2026-09-03 2:44 ` sashiko-bot
2026-10-15 13:05 ` Pratyush Yadav [this message]
2026-09-03 2:34 ` [RFC PATCH 3/3] luo: memfd: Move to feature flags instead of compatibility strings Logan Odell
2026-09-03 2:47 ` sashiko-bot
2026-09-04 16:00 ` [RFC PATCH 0/3] liveupdate: Move to feature flags for LUO and memfd ABI compatibility Jason Gunthorpe
2026-09-04 22:24 ` David Matlack
2026-09-05 1:24 ` Jason Gunthorpe
2026-09-10 0:58 ` Sean Christopherson
2026-09-10 14:34 ` Jason Gunthorpe
2026-09-10 15:35 ` Sean Christopherson
2026-09-10 17:12 ` Jason Gunthorpe
2026-09-10 21:27 ` David Matlack
2026-09-10 22:18 ` Jason Gunthorpe
2026-09-10 22:42 ` Sean Christopherson
2026-09-10 22:57 ` Jason Gunthorpe
2026-09-11 10:27 ` David Woodhouse
2026-09-11 13:44 ` Sean Christopherson
2026-09-11 14:30 ` Jason Gunthorpe
2026-09-11 17:16 ` Paolo Bonzini
2026-09-11 18:26 ` Jason Gunthorpe
2026-09-11 16:57 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2vxzv773glm1.fsf@kernel.org \
--to=pratyush@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alex@shazbot.org \
--cc=arnd@arndb.de \
--cc=baolu.lu@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=dwmw2@infradead.org \
--cc=graf@amazon.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kexec@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-pci@vger.kernel.org \
--cc=loganodell@google.com \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=pasha.tatashin@soleen.com \
--cc=pbonzini@redhat.com \
--cc=robin.murphy@arm.com \
--cc=rppt@kernel.org \
--cc=seanjc@google.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox