Linux PCI subsystem development
 help / color / mirror / Atom feed
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

  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