mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chen Pei <cp0613@linux.alibaba.com>
To: pjw@kernel.org, palmer@dabbelt.com, alex@ghiti.fr,
	rppt@kernel.org, pasha.tatashin@soleen.com, pratyush@kernel.org,
	graf@amazon.com, shuah@kernel.org
Cc: guoren@kernel.org, linux-riscv@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org, kexec@lists.infradead.org
Subject: [PATCH v2 1/5] kho: Do not translate the handover FDT address in is_kho_boot()
Date: Tue,  3 Nov 2026 16:09:22 +0800	[thread overview]
Message-ID: <20261103080926.2079-2-cp0613@linux.alibaba.com> (raw)
In-Reply-To: <20261103080926.2079-1-cp0613@linux.alibaba.com>

is_kho_boot() only has to say whether a handover FDT was recorded, but
it asks kho_get_fdt() for one and so converts kho_in.fdt_phys with
phys_to_virt() just to throw the pointer away. Both callers use it as a
boolean and never dereference the result.

On riscv64 that conversion is not valid yet when efi_init() reaches it:
setup_vm() leaves kernel_map.va_pa_offset at 0 and setup_bootmem()
assigns it later, so a handover boot that came through UEFI panics in
linear_mapping_pa_to_va(). Only debug builds fail -- without
CONFIG_DEBUG_VIRTUAL __va() degenerates to "phys + 0" and the boolean
stays correct -- but the panic also goes unnoticed without an earlycon.

Check the physical address instead. Nothing needs the translation, and
architectures stay free to bring their linear mapping up whenever they
like.

Fixes: d6d511639185 ("kexec: introduce is_kho_boot()")
Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
---

Tested on qemu-system-riscv64 (virt, -cpu max, TCG): edk2
RISCV_VIRT_CODE.fd/VARS.fd on pflash with OpenSBI fw_dynamic.bin below
it, and a GPT disk holding an ESP with grub plus the kernel and an ext4
partition as rootfs.  Kernel config is riscv defconfig plus
DEBUG_KERNEL, DEBUG_VIRTUAL, KEXEC_FILE, KEXEC_HANDOVER and the kho
selftest fragment; the outgoing kernel gets "kho=on" and the kho
selftest init does kexec_file_load() followed by reboot(RB_KEXEC).

Before, the first handover panics.  earlycon= is needed to see it: the
BUG precedes console registration, so without an earlycon the machine
goes silent right after kexec.

  KHO: found kexec handover data.
  efi: EFI v2.7 by EDK II
  kernel BUG at arch/riscv/mm/physaddr.c:47!
  epc : linear_mapping_pa_to_va+0x1c/0x1e
   ra : is_kho_boot+0x18/0x28

After, the same setup keeps handing over until the window closes, 29
consecutive boots and no BUG.

  KHO: found kexec handover data.
  KHO: exec from: 7.4.0-rc1-next-20261102-00005-gfca49e548231 (count 29)

 kernel/liveupdate/kexec_handover.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
index 6f1f55fe3181..6ab181de345c 100644
--- a/kernel/liveupdate/kexec_handover.c
+++ b/kernel/liveupdate/kexec_handover.c
@@ -1643,7 +1643,7 @@ EXPORT_SYMBOL_GPL(kho_restore_free);
  */
 bool is_kho_boot(void)
 {
-	return !!kho_get_fdt();
+	return kho_in.fdt_phys != 0;
 }
 EXPORT_SYMBOL_GPL(is_kho_boot);
 
-- 
2.50.1


  reply	other threads:[~2026-11-03  8:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-03  8:09 [PATCH v2 0/5] riscv: Enable kexec handover and live update Chen Pei
2026-11-03  8:09 ` Chen Pei [this message]
2026-11-03  8:09 ` [PATCH v2 2/5] riscv: Call early_ioremap_setup() before parsing the DTB Chen Pei
2026-11-03  8:09 ` [PATCH v2 3/5] riscv: Add support for kexec handover (KHO) Chen Pei
2026-11-03  8:09 ` [PATCH v2 4/5] selftests: kho: Add riscv support Chen Pei
2026-11-03  8:09 ` [PATCH v2 5/5] selftests: liveupdate: " Chen Pei

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=20261103080926.2079-2-cp0613@linux.alibaba.com \
    --to=cp0613@linux.alibaba.com \
    --cc=alex@ghiti.fr \
    --cc=graf@amazon.com \
    --cc=guoren@kernel.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=pasha.tatashin@soleen.com \
    --cc=pjw@kernel.org \
    --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

all inboxes | Powered by JetHome®