From: Pratyush Yadav <pratyush@kernel.org>
To: George Guo <dongtai.guo@linux.dev>
Cc: rppt@kernel.org, pasha.tatashin@soleen.com,
pratyush@kernel.org, chenhuacai@kernel.org, ardb@kernel.org,
shuah@kernel.org, ilias.apalodimas@linaro.org,
akpm@linux-foundation.org, baoquan.he@linux.dev,
ruirui.yang@linux.dev, guodongtai@kylinos.cn,
kernel@xen0n.name, graf@amazon.com, liukexin@kylinos.cn,
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: Re: [PATCH v5 2/5] liveupdate: synchronize EFI KHO channel at execution
Date: Tue, 22 Sep 2026 14:48:03 +0200 [thread overview]
Message-ID: <2vxz1pal5u64.fsf@kernel.org> (raw)
In-Reply-To: <20260904100852.26006-3-dongtai.guo@linux.dev> (George Guo's message of "Fri, 4 Sep 2026 18:08:49 +0800")
On Fri, Sep 04 2026, George Guo wrote:
> From: George Guo <guodongtai@kylinos.cn>
>
> The EFI KHO configuration table is a global channel. Updating it while
> a candidate kexec image is still being loaded can leave the channel
> pointing at the failed candidate even though the previous image remains
> installed. Synchronize it instead from the image selected for execution.
Huh? Sorry, I don't understand this is supposed to mean at all. What
failed candidate?
>
> Use the actual scratch payload size rather than its page-aligned segment
> size, and propagate update failures before live-update serialization.
> Keep clearing the channel for cold and crash images best-effort.
Huh? This is word soup and I don't understand what any of this is
supposed to mean.
If you are using a LLM to generate this, please _read_ what the output
is and see if it even is readable to someone else.
And if you are writing this by hand, then take a step back, and consider
if patch reviews can even understand what you are saying.
>
> Signed-off-by: George Guo <guodongtai@kylinos.cn>
> ---
> kernel/crash_core.c | 7 +++++++
> kernel/kexec_core.c | 5 +++++
> kernel/kexec_internal.h | 3 +++
> kernel/liveupdate/kexec_handover.c | 33 ++++++++++++++++++++++++++++++
> 4 files changed, 48 insertions(+)
>
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index 2b36aa9fade0..6166ce4203d3 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -138,6 +138,13 @@ void __noclone __crash_kexec(struct pt_regs *regs)
> if (kexec_crash_image) {
> struct pt_regs fixed_regs;
>
> + /*
> + * A crash image carries no KHO state: clear the
> + * transport so the crash kernel boots cold instead
> + * of reviving from stale state.
> + */
> + (void)kho_sync_channel(kexec_crash_image);
> +
> crash_setup_regs(&fixed_regs, regs);
> crash_save_vmcoreinfo();
> machine_crash_shutdown(&fixed_regs);
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index dc770b9a6d05..147f5b5b23d4 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -1146,6 +1146,11 @@ int kernel_kexec(void)
> goto Unlock;
> }
>
> + /* Synchronize the handover transport with the image being executed. */
> + error = kho_sync_channel(kexec_image);
> + if (error)
> + goto Unlock;
> +
Why are you setting this at kexec time? Why not set it at load time like
every other architecture?
Also what's this "sync channel"? Use simpler words that _actually
describe_ what they do.
> if (!kexec_image->preserve_context) {
> error = liveupdate_reboot();
> if (error)
> diff --git a/kernel/kexec_internal.h b/kernel/kexec_internal.h
> index 228bb88c018b..4d4c2290e85c 100644
> --- a/kernel/kexec_internal.h
> +++ b/kernel/kexec_internal.h
> @@ -46,6 +46,7 @@ struct kexec_buf;
> int kho_locate_mem_hole(struct kexec_buf *kbuf,
> int (*func)(struct resource *, void *));
> int kho_fill_kimage(struct kimage *image);
> +int kho_sync_channel(struct kimage *image);
> #else
> static inline int kho_locate_mem_hole(struct kexec_buf *kbuf,
> int (*func)(struct resource *, void *))
> @@ -54,5 +55,7 @@ static inline int kho_locate_mem_hole(struct kexec_buf *kbuf,
> }
>
> static inline int kho_fill_kimage(struct kimage *image) { return 0; }
> +
> +static inline int kho_sync_channel(struct kimage *image) { return 0; }
> #endif /* CONFIG_KEXEC_HANDOVER */
> #endif /* LINUX_KEXEC_INTERNAL_H */
> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> index 39f489a258d9..3aa5c66dfc6d 100644
> --- a/kernel/liveupdate/kexec_handover.c
> +++ b/kernel/liveupdate/kexec_handover.c
> @@ -14,6 +14,7 @@
> #include <linux/cma.h>
> #include <linux/kmemleak.h>
> #include <linux/count_zeros.h>
> +#include <linux/efi.h>
> #include <linux/kasan.h>
> #include <linux/kexec.h>
> #include <linux/kexec_handover.h>
> @@ -2074,6 +2075,38 @@ int kho_fill_kimage(struct kimage *image)
> return 0;
> }
>
> +/*
> + * Synchronize the handover transport with the image that is about to be
> + * executed. The EFI config table channel is global, while kexec keeps
> + * separate images for a normal reboot and for crash. Write the state of the
> + * selected image immediately before it is executed, rather than while a
> + * candidate image is being loaded, so a failed replacement cannot leave the
> + * channel pointing at that failed image.
> + *
> + * An image loaded through the legacy kexec_load() syscall, a crash image, or
> + * an image loaded while KHO is disabled carries no handover state. Clear the
> + * channel for those images so the next kernel boots cold instead of reviving
> + * from stale state. Clearing is best-effort because an absent channel cannot
> + * affect a cold boot.
> + */
> +int kho_sync_channel(struct kimage *image)
> +{
> + int err;
> +
> + if (!image->kho.fdt || !image->kho.scratch) {
> + efi_kho_update(0, 0, 0, 0);
> + return 0;
> + }
> +
> + err = efi_kho_update(image->kho.fdt, PAGE_SIZE,
> + image->kho.scratch->mem,
> + image->kho.scratch->bufsz);
> + if (err)
> + pr_warn("failed to update EFI config table: %d\n", err);
> +
> + return err;
> +}
> +
> static int kho_walk_scratch(struct kexec_buf *kbuf,
> int (*func)(struct resource *, void *))
> {
--
Regards,
Pratyush Yadav
next prev parent reply other threads:[~2026-09-22 12:48 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 10:08 [PATCH v5 0/5] LoongArch: add KHO support and selftests George Guo
2026-09-04 10:08 ` [PATCH v5 1/5] efi: add a KHO configuration table channel George Guo
2026-09-19 14:15 ` Huacai Chen
2026-09-22 12:26 ` Pratyush Yadav
2026-09-04 10:08 ` [PATCH v5 2/5] liveupdate: synchronize EFI KHO channel at execution George Guo
2026-09-19 14:15 ` Huacai Chen
2026-09-22 12:48 ` Pratyush Yadav [this message]
2026-09-04 10:08 ` [PATCH v5 3/5] liveupdate: kho_block: include linux/mm.h for virt/phys translation George Guo
2026-09-22 12:30 ` Pratyush Yadav
2026-09-04 10:08 ` [PATCH v5 4/5] LoongArch: enable kexec handover (KHO) George Guo
2026-09-04 10:08 ` [PATCH v5 5/5] selftests/kho: add LoongArch vmtest support George Guo
2026-09-06 20:17 ` [PATCH v5 0/5] LoongArch: add KHO support and selftests Mike Rapoport
2026-09-07 1:47 ` Baoquan He
2026-09-07 2:10 ` Baoquan He
2026-09-19 14:15 ` Huacai Chen
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=2vxz1pal5u64.fsf@kernel.org \
--to=pratyush@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=baoquan.he@linux.dev \
--cc=chenhuacai@kernel.org \
--cc=dongtai.guo@linux.dev \
--cc=graf@amazon.com \
--cc=guodongtai@kylinos.cn \
--cc=ilias.apalodimas@linaro.org \
--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=liukexin@kylinos.cn \
--cc=loongarch@lists.linux.dev \
--cc=pasha.tatashin@soleen.com \
--cc=rppt@kernel.org \
--cc=ruirui.yang@linux.dev \
--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
all inboxes | Powered by JetHome®