From: Dave Young <dyoung@redhat.com>
To: Brian Mak <makb@juniper.net>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Andrew Morton <akpm@linux-foundation.org>,
Baoquan He <bhe@redhat.com>, Rob Herring <robh@kernel.org>,
Saravana Kannan <saravanak@google.com>,
x86@kernel.org, kexec@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RESEND] x86/kexec: Carry forward the boot DTB on kexec
Date: Wed, 30 Jul 2025 15:31:59 +0800 [thread overview]
Message-ID: <aInKb8qr689ytM41@darkstar.users.ipa.redhat.com> (raw)
In-Reply-To: <20250729182142.4875-1-makb@juniper.net>
On Tue, Jul 29, 2025 at 11:21:42AM -0700, Brian Mak wrote:
> The kexec_file_load syscall on x86 currently does not support passing
> a device tree blob to the new kernel.
>
> To add support for this, we copy the behavior of ARM64 and PowerPC and
> copy the current boot's device tree blob for use in the new kernel. We
> do this on x86 by passing the device tree blob as a setup_data entry in
> accordance with the x86 boot protocol.
>
> Signed-off-by: Brian Mak <makb@juniper.net>
> ---
> arch/x86/kernel/kexec-bzimage64.c | 46 +++++++++++++++++++++++++++++--
> 1 file changed, 43 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
> index 24a41f0e0cf1..c24536c25f98 100644
> --- a/arch/x86/kernel/kexec-bzimage64.c
> +++ b/arch/x86/kernel/kexec-bzimage64.c
> @@ -16,6 +16,8 @@
> #include <linux/kexec.h>
> #include <linux/kernel.h>
> #include <linux/mm.h>
> +#include <linux/libfdt.h>
> +#include <linux/of_fdt.h>
> #include <linux/efi.h>
> #include <linux/random.h>
>
> @@ -212,6 +214,28 @@ setup_efi_state(struct boot_params *params, unsigned long params_load_addr,
> }
> #endif /* CONFIG_EFI */
>
> +#ifdef CONFIG_OF_FLATTREE
> +static void setup_dtb(struct boot_params *params,
> + unsigned long params_load_addr,
> + unsigned int dtb_setup_data_offset)
> +{
> + struct setup_data *sd = (void *)params + dtb_setup_data_offset;
> + unsigned long setup_data_phys, dtb_len;
> +
> + dtb_len = fdt_totalsize(initial_boot_params);
> + sd->type = SETUP_DTB;
> + sd->len = dtb_len;
> +
> + /* Carry over current boot DTB with setup_data */
> + memcpy(sd->data, initial_boot_params, dtb_len);
> +
> + /* Add setup data */
> + setup_data_phys = params_load_addr + dtb_setup_data_offset;
> + sd->next = params->hdr.setup_data;
> + params->hdr.setup_data = setup_data_phys;
> +}
> +#endif /* CONFIG_OF_FLATTREE */
> +
> static void
> setup_ima_state(const struct kimage *image, struct boot_params *params,
> unsigned long params_load_addr,
> @@ -336,6 +360,16 @@ setup_boot_parameters(struct kimage *image, struct boot_params *params,
> sizeof(struct efi_setup_data);
> #endif
>
> +#ifdef CONFIG_OF_FLATTREE
> + if (initial_boot_params) {
> + setup_dtb(params, params_load_addr, setup_data_offset);
> + setup_data_offset += sizeof(struct setup_data) +
> + fdt_totalsize(initial_boot_params);
I suppose current boot dtb should be valid for the current runnning
kernel, if you use kexec to load another kernel the next kexec reboot
could fail due to unmatching dtb.
Make this unconditionally could break the previous working kexec?
> + } else {
> + pr_info("No DTB\n");
pr_debug sounds better.
> + }
> +#endif
> +
> if (IS_ENABLED(CONFIG_IMA_KEXEC)) {
> /* Setup IMA log buffer state */
> setup_ima_state(image, params, params_load_addr,
> @@ -529,6 +563,12 @@ static void *bzImage64_load(struct kimage *image, char *kernel,
> sizeof(struct setup_data) +
> RNG_SEED_LENGTH;
>
> +#ifdef CONFIG_OF_FLATTREE
> + if (initial_boot_params)
> + kbuf.bufsz += sizeof(struct setup_data) +
> + fdt_totalsize(initial_boot_params);
> +#endif
> +
> if (IS_ENABLED(CONFIG_IMA_KEXEC))
> kbuf.bufsz += sizeof(struct setup_data) +
> sizeof(struct ima_setup_data);
> @@ -537,7 +577,7 @@ static void *bzImage64_load(struct kimage *image, char *kernel,
> kbuf.bufsz += sizeof(struct setup_data) +
> sizeof(struct kho_data);
>
> - params = kzalloc(kbuf.bufsz, GFP_KERNEL);
> + params = kvzalloc(kbuf.bufsz, GFP_KERNEL);
> if (!params)
> return ERR_PTR(-ENOMEM);
> efi_map_offset = params_cmdline_sz;
> @@ -647,7 +687,7 @@ static void *bzImage64_load(struct kimage *image, char *kernel,
> return ldata;
>
> out_free_params:
> - kfree(params);
> + kvfree(params);
> return ERR_PTR(ret);
> }
>
> @@ -659,7 +699,7 @@ static int bzImage64_cleanup(void *loader_data)
> if (!ldata)
> return 0;
>
> - kfree(ldata->bootparams_buf);
> + kvfree(ldata->bootparams_buf);
> ldata->bootparams_buf = NULL;
>
> return 0;
>
> base-commit: d7b8f8e20813f0179d8ef519541a3527e7661d3a
> --
> 2.25.1
>
Thanks
Dave
next prev parent reply other threads:[~2025-07-30 7:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-29 18:21 [PATCH RESEND] x86/kexec: Carry forward the boot DTB on kexec Brian Mak
2025-07-30 7:31 ` Dave Young [this message]
2025-07-30 17:02 ` Brian Mak
2025-07-31 9:27 ` Dave Young
2025-08-01 0:24 ` Brian Mak
2025-08-01 3:02 ` Baoquan He
2025-08-01 19:24 ` Brian Mak
2025-08-03 4:05 ` Baoquan He
2025-08-05 23:12 ` Brian Mak
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=aInKb8qr689ytM41@darkstar.users.ipa.redhat.com \
--to=dyoung@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=devicetree@vger.kernel.org \
--cc=hpa@zytor.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=makb@juniper.net \
--cc=mingo@redhat.com \
--cc=robh@kernel.org \
--cc=saravanak@google.com \
--cc=tglx@linutronix.de \
--cc=x86@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;
as well as URLs for NNTP newsgroup(s).