From: George Guo <dongtai.guo@linux.dev>
To: pratyush@kernel.org
Cc: rppt@kernel.org, pasha.tatashin@soleen.com,
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,
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: Wed, 21 Oct 2026 14:11:05 +0800 [thread overview]
Message-ID: <20261021061105.3697-1-dongtai.guo@linux.dev> (raw)
In-Reply-To: <2vxz1pal5u64.fsf@kernel.org>
Hi Pratyush,
You are right about the text, and I am sorry. I used an LLM to help
write this series. I meant to check every commit message and comment
word by word myself before sending, but I made a mistake and sent v5
to the list before doing that check. That is my fault, and it cost you
time trying to read it.
For v6 I am rewriting the messages and checking every line myself before
sending.
On Tue, Sep 22 2026, Pratyush Yadav wrote:
> > 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?
Rewritten in v6.
> Why are you setting this at kexec time? Why not set it at load time like
> every other architecture?
Other architectures store the KHO addresses in the loaded image itself,
so each image has its own copy.
The EFI table is shared, but the normal and the crash image can both be
loaded, and they need different contents: the normal kernel needs the
KHO addresses, the crash kernel must find the table zeroed. Whatever is
written at load time is wrong for one of them. For example, after
"kexec -l" with KHO and then "kexec -p", a panic boots the crash kernel
with KHO addresses that were meant for the normal kernel.
kernel_kexec() and __crash_kexec() know which image is about to run, so
v6 writes the table there: filled from that image, or zeroed if it has
no KHO state.
> Also what's this "sync channel"? Use simpler words that _actually
> describe_ what they do.
Renamed to kho_update_efi_table() in v6.
> > 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.
Rewritten in v6.
Thanks,
George
next prev parent reply other threads:[~2026-10-21 6:11 UTC|newest]
Thread overview: 18+ 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-10-21 3:33 ` George Guo
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
2026-10-21 6:11 ` George Guo [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-28 2:30 ` George Guo
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=20261021061105.3697-1-dongtai.guo@linux.dev \
--to=dongtai.guo@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=baoquan.he@linux.dev \
--cc=chenhuacai@kernel.org \
--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=loongarch@lists.linux.dev \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
--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