Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Pratyush Yadav <pratyush@kernel.org>
To: George Guo <dongtai.guo@linux.dev>
Cc: Huacai Chen <chenhuacai@kernel.org>,
	 Mike Rapoport <rppt@kernel.org>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	 Pratyush Yadav <pratyush@kernel.org>,
	 Shuah Khan <shuah@kernel.org>,
	 George Guo <guodongtai@kylinos.cn>,
	 WANG Xuerui <kernel@xen0n.name>,
	 Alexander Graf <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,
	 Kexin Liu <liukexin@kylinos.cn>
Subject: Re: [PATCH v3 1/3] LoongArch: kexec: add KHO support for FDT-based
Date: Mon, 13 Jul 2026 15:53:17 +0200	[thread overview]
Message-ID: <2vxzjyqzj8s2.fsf@kernel.org> (raw)
In-Reply-To: <20260601093930.112758-1-dongtai.guo@linux.dev> (George Guo's message of "Mon, 1 Jun 2026 17:39:28 +0800")

On Mon, Jun 01 2026, George Guo wrote:

> From: George Guo <guodongtai@kylinos.cn>
>
> Enable Kexec Handover (KHO) on LoongArch64 for FDT-based systems.
>
> - Kconfig: select ARCH_SUPPORTS_KEXEC_HANDOVER for CONFIG_64BIT
> - kexec.h: add fdt/fdt_mem fields to kimage_arch to hold the KHO FDT
>   kexec segment virtual and physical addresses
> - machine_kexec_file.c: add kho_load_fdt() which copies the running
>   kernel's FDT (initial_boot_params), appends linux,kho-fdt and
>   linux,kho-scratch properties to /chosen, and loads the result as a
>   kexec segment; called from load_other_segments().  Returns -EINVAL
>   when initial_boot_params is NULL (ACPI-only boot) since that path
>   requires separate handling.
> - machine_kexec.c: before jumping to the new kernel, update the
>   DEVICE_TREE_GUID entry in the EFI config table to point to the KHO
>   FDT segment so the second kernel finds it via efi_fdt_pointer() and
>   early_init_dt_check_kho() calls kho_populate()
>
> Co-developed-by: Kexin Liu <liukexin@kylinos.cn>
> Signed-off-by: Kexin Liu <liukexin@kylinos.cn>
> Signed-off-by: George Guo <guodongtai@kylinos.cn>
> ---
>  arch/loongarch/Kconfig                     |   3 +
>  arch/loongarch/include/asm/kexec.h         |   4 +
>  arch/loongarch/kernel/machine_kexec.c      |  27 +++++
>  arch/loongarch/kernel/machine_kexec_file.c | 118 +++++++++++++++++++++
>  4 files changed, 152 insertions(+)
>
> diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig
> index 606597da46b8..d494418545f5 100644
> --- a/arch/loongarch/Kconfig
> +++ b/arch/loongarch/Kconfig
> @@ -684,6 +684,9 @@ config ARCH_SUPPORTS_KEXEC
>  config ARCH_SUPPORTS_KEXEC_FILE
>  	def_bool 64BIT
>  
> +config ARCH_SUPPORTS_KEXEC_HANDOVER
> +	def_bool 64BIT
> +
>  config ARCH_SELECTS_KEXEC_FILE
>  	def_bool 64BIT
>  	depends on KEXEC_FILE
> diff --git a/arch/loongarch/include/asm/kexec.h b/arch/loongarch/include/asm/kexec.h
> index 209fa43222e1..adf54bfcdd49 100644
> --- a/arch/loongarch/include/asm/kexec.h
> +++ b/arch/loongarch/include/asm/kexec.h
> @@ -39,6 +39,10 @@ struct kimage_arch {
>  	unsigned long efi_boot;
>  	unsigned long cmdline_ptr;
>  	unsigned long systable_ptr;
> +#ifdef CONFIG_KEXEC_HANDOVER
> +	void *fdt;		/* virtual address of KHO FDT segment buffer */
> +	unsigned long fdt_mem;	/* physical address of KHO FDT segment */
> +#endif
>  };
>  
>  #ifdef CONFIG_KEXEC_FILE
> diff --git a/arch/loongarch/kernel/machine_kexec.c b/arch/loongarch/kernel/machine_kexec.c
> index ad27fef098f1..98529c71d001 100644
> --- a/arch/loongarch/kernel/machine_kexec.c
> +++ b/arch/loongarch/kernel/machine_kexec.c
> @@ -6,6 +6,7 @@
>   */
>  #include <linux/compiler.h>
>  #include <linux/cpu.h>
> +#include <linux/efi.h>
>  #include <linux/kexec.h>
>  #include <linux/crash_dump.h>
>  #include <linux/delay.h>
> @@ -289,6 +290,32 @@ void machine_kexec(struct kimage *image)
>  	pr_notice("We will call new kernel at 0x%lx\n", start_addr);
>  	pr_notice("Bye ...\n");
>  
> +#ifdef CONFIG_KEXEC_HANDOVER
> +	/*
> +	 * Point the EFI FDTPTR config table entry at the modified FDT so the
> +	 * second kernel picks up the linux,kho-fdt and linux,kho-scratch
> +	 * properties via early_init_dt_check_kho().
> +	 */
> +	if (internal->fdt_mem) {
> +		/*
> +		 * FDT-based system: DEVICE_TREE_GUID already exists in the EFI
> +		 * config table; just update its pointer to our KHO FDT.
> +		 */
> +		efi_system_table_t *st =
> +			(efi_system_table_t *)TO_CACHE(systable_ptr);
> +		efi_config_table_t *ct =
> +			(efi_config_table_t *)TO_CACHE((unsigned long)st->tables);
> +		unsigned long i;
> +
> +		for (i = 0; i < st->nr_tables; i++) {
> +			if (!efi_guidcmp(ct[i].guid, DEVICE_TREE_GUID)) {
> +				ct[i].table = (void *)internal->fdt_mem;
> +				break;
> +			}
> +		}
> +	}
> +#endif

Honestly this and the ACPI stuff looks worse to me than what your
previous version did. Now I am not an expert on EFI and architecture
stuff, and know nothing about Loongarch, but to me this looks hacky and
I am not sure if it is doing the right thing.

I think you should get some alignment with Loongarch maintainers on what
the kexec boot protocol looks like. It looked odd to me, but if the
Loongarch maintainers are fine with using the kernel cmdline for
bootloader to pass data to the kernel, then I think we should go back to
that.

Huacai, do you have any thoughts? For KHO we essentially need a way for
the pre-kexec kernel to tell the post-kexec kernel about a blob of
memory that has some information it can use. For x86, we do that via
setup data. See arch/x86/include/uapi/asm/setup_data.h and struct
kho_data for example. On arm64, we use the boot FDT's /chosen node. See
kho_add_chosen() in drivers/of/kexec.c.

Ideally, all device tree platforms should use the FDT path. But
Loongarch also has ACPI only and I don't know what a good idea for that
is.

So, do you have any suggestions on where to best place a pointer to this
blob of data on Loongarch? v1 of this series put it in the kernel
commandline, but I found that odd and asked if it can be done via DT
instead. But to me, this code looks even more hacky.

> +
>  	/* Make reboot code buffer available to the boot CPU. */
>  	flush_cache_all();
>  
[...]

-- 
Regards,
Pratyush Yadav


  parent reply	other threads:[~2026-07-13 13:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-01  9:28 [PATCH v3 0/3] LoongArch: add KHO support and selftests George Guo
     [not found] ` <20260601093930.112758-1-dongtai.guo@linux.dev>
2026-06-01  9:39   ` [PATCH v3 3/3] selftests/kho: add LoongArch vmtest support George Guo
2026-06-14 10:23     ` Mike Rapoport
2026-07-13 13:53   ` Pratyush Yadav [this message]
2026-07-14 12:17     ` [PATCH v3 1/3] LoongArch: kexec: add KHO support for FDT-based Huacai Chen
2026-06-09 14:39 ` [PATCH v3 0/3] LoongArch: add KHO support and selftests George Guo
2026-06-09 15:55   ` Pratyush Yadav

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