Linux EFI development
 help / color / mirror / Atom feed
From: George Guo <dongtai.guo@linux.dev>
To: chenhuacai@kernel.org, rppt@kernel.org,
	pasha.tatashin@soleen.com, pratyush@kernel.org, shuah@kernel.org,
	ardb@kernel.org
Cc: guodongtai@kylinos.cn, kernel@xen0n.name, graf@amazon.com,
	loongarch@lists.linux.dev, linux-kernel@vger.kernel.org,
	kexec@lists.infradead.org, linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org, linux-efi@vger.kernel.org
Subject: [PATCH v4 1/4] efi: add a KHO configuration table GUID
Date: Fri,  7 Aug 2026 18:37:11 +0800	[thread overview]
Message-ID: <20260807103714.33074-2-dongtai.guo@linux.dev> (raw)
In-Reply-To: <20260807103714.33074-1-dongtai.guo@linux.dev>

From: George Guo <guodongtai@kylinos.cn>

Kexec Handover (KHO) passes the address of its state FDT and of its
scratch area from the current kernel to the next one.  On architectures
that boot with a device tree, the current kernel writes the
linux,kho-fdt and linux,kho-scratch properties into /chosen, and the next
kernel reads them back in early_init_dt_check_kho().

Architectures that boot through EFI without a device tree have no such
channel.  LoongArch is one of them: its efistub passes the EFI system
table and the command line to the core kernel directly and never creates
an FDT.  x86 has the same problem and carries the state out of band
instead, in a struct kho_data in the setup_data chain of its boot
protocol.

Add an out-of-band channel for EFI: a LINUX_EFI_KHO_TABLE_GUID
configuration table entry, under a randomly generated GUID, pointing at a
struct linux_efi_kho_data.  The
current kernel loads the structure and an extended configuration table as
kexec segments, then switches the EFI system table to the new table
before jumping.  The next kernel finds the entry by GUID and calls
kho_populate().

The structure carries no version field.  An incompatible change to the
layout must use a new GUID, which is the usual rule for EFI configuration
tables.  The handover payload itself is versioned separately, by the
compatible string of the KHO state FDT that kho_populate() checks.

This patch adds the definitions only.  LoongArch is the first user; any
other EFI architecture without a boot FDT can use the same channel.

Signed-off-by: George Guo <guodongtai@kylinos.cn>
---
 include/linux/efi.h | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/include/linux/efi.h b/include/linux/efi.h
index ccbc35479684..789ab9e4312a 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -422,6 +422,7 @@ void efi_native_runtime_setup(void);
 #define LINUX_EFI_COCO_SECRET_AREA_GUID		EFI_GUID(0xadf956ad, 0xe98c, 0x484c,  0xae, 0x11, 0xb5, 0x1c, 0x7d, 0x33, 0x64, 0x47)
 #define LINUX_EFI_BOOT_MEMMAP_GUID		EFI_GUID(0x800f683f, 0xd08b, 0x423a,  0xa2, 0x93, 0x96, 0x5c, 0x3c, 0x6f, 0xe2, 0xb4)
 #define LINUX_EFI_UNACCEPTED_MEM_TABLE_GUID	EFI_GUID(0xd5d1de3c, 0x105c, 0x44f9,  0x9e, 0xa9, 0xbc, 0xef, 0x98, 0x12, 0x00, 0x31)
+#define LINUX_EFI_KHO_TABLE_GUID		EFI_GUID(0xc941b6c7, 0x7b3f, 0x4af6,  0x9e, 0x50, 0xfc, 0xb3, 0xa8, 0x86, 0x8a, 0x17)
 
 #define RISCV_EFI_BOOT_PROTOCOL_GUID		EFI_GUID(0xccd15fec, 0x6f73, 0x4eec,  0x83, 0x95, 0x3e, 0x69, 0xe4, 0xb9, 0x40, 0xbf)
 
@@ -1271,6 +1272,29 @@ struct linux_efi_memreserve {
 
 void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size);
 
+/*
+ * The LINUX_EFI_KHO_TABLE_GUID config table points to this structure.  It
+ * carries the kexec handover (KHO) state from the current kernel to the next
+ * one: the addresses of the KHO state FDT and of the scratch area.
+ *
+ * This is the handover channel for architectures that boot through EFI without
+ * a device tree, where the /chosen linux,kho-fdt and linux,kho-scratch
+ * properties read by early_init_dt_check_kho() are not available.  The current
+ * kernel loads the structure and an extended configuration table as kexec
+ * segments; the next kernel finds it by GUID and calls kho_populate().
+ *
+ * The layout is an ABI between the two kernels and is fixed.  It carries no
+ * version field: an incompatible change must use a new GUID, and the handover
+ * payload itself is versioned separately by the compatible string of the KHO
+ * state FDT, which kho_populate() checks.
+ */
+struct linux_efi_kho_data {
+	u64 fdt_addr;
+	u64 fdt_size;
+	u64 scratch_addr;
+	u64 scratch_size;
+} __packed;
+
 /*
  * The LINUX_EFI_MOK_VARIABLE_TABLE_GUID config table can be provided
  * to the kernel by an EFI boot loader. The table contains a packed
-- 
2.53.0


  reply	other threads:[~2026-08-07 10:38 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-07 10:37 [PATCH v4 0/4] LoongArch: add KHO support and selftests George Guo
2026-08-07 10:37 ` George Guo [this message]
2026-08-07 10:37 ` [PATCH v4 2/4] LoongArch: kexec: add KHO support George Guo
2026-08-07 10:37 ` [PATCH v4 3/4] liveupdate: luo_session: include linux/mm.h for virt/phys translation George Guo
2026-08-07 10:37 ` [PATCH v4 4/4] selftests/kho: add LoongArch vmtest support George Guo

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=20260807103714.33074-2-dongtai.guo@linux.dev \
    --to=dongtai.guo@linux.dev \
    --cc=ardb@kernel.org \
    --cc=chenhuacai@kernel.org \
    --cc=graf@amazon.com \
    --cc=guodongtai@kylinos.cn \
    --cc=kernel@xen0n.name \
    --cc=kexec@lists.infradead.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=loongarch@lists.linux.dev \
    --cc=pasha.tatashin@soleen.com \
    --cc=pratyush@kernel.org \
    --cc=rppt@kernel.org \
    --cc=shuah@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