Re: [PATCH v4 0/2] LoongArch: kexec: avoid clobbering the QEMU FDT

[Huacai Chen]

Hi, George,

On Thu, Jul 2, 2026 at 12:00 AM George Guo <dongtai.guo@xxxxxxxxx> wrote:
>
> This series fixes two ways the LoongArch kexec path can clobber the
> firmware-provided FDT that QEMU places at physical 0x100000, which made the
> second kernel boot silently (earlycon auto-detection reads a corrupted FDT).
>
> Patch 1 moves the relocation trampoline off the hardcoded 0x100000 onto the
> kexec core's control_code_page (as arm64/riscv do), so machine_kexec_prepare()
> no longer overwrites the FDT.
>
> Patch 2 removes the remaining fixed command-line address (KEXEC_CMDLINE_ADDR,
> 0x108000).  QEMU's machine FDT declares fdt_totalsize = 1MB and thus claims the
> whole [0x100000, 0x200000) upper half of the reserved 2MB, so 0x108000 lives
> inside the FDT and only survives because the FDT's real content is small
> (~3.6KB) and 0x108000 falls in the trailing slack.  The command line is passed
> to the second kernel in register a1, not at a fixed address, so it is loaded
> into its own kexec segment instead, removing the overlap regardless of FDT
> size.
>
> This addresses the two questions raised on the v3 trampoline patch [1]:
>  - "how to avoid the cmdline overlapping FDT" -> patch 2.
>  - "how to avoid the control page being corrupted by the new kernel" -> the
>    trampoline is executed only by the current kernel and is dead once the new
>    kernel starts, so being overwritten afterwards is harmless; the kexec core
Who told you the trampoline is dead code? All non-boot CPUs are
running in the trampoline, you can use maxcpus=1 to go to the new
kernel, and do something, and then hotplug the non-boot CPUs at any
time.

The trampoline should live all the time for safety, ARM and RISC-V
both have the trouble, especially when memory is small.

And I don't want to hear "If others can do something but LoongArch
can't, then LoongArch has a drawback; if others can't do something but
LoongArch can, then it is useless".

BTW,  you have never replied to my comments, all you have done is
submit new versions again and again. Who told you to do things like
this? You want to take your ill code again and again, or your employer
counts the number of your E-mails in the mailist as the amount of your
work?



Huacai

>    also keeps the control page outside every relocation destination, so it
>    cannot be corrupted during relocation.  The command line is different (it is
>    read by the new kernel), which is why only the trampoline uses the core page.
>
> Tested with tools/testing/selftests/kho/vmtest.sh on LoongArch (QEMU,
> kexec_file_load): the second kernel boots with the full command line and
> earlycon, and KHO restore succeeds.
>
> This series depends on [2] ("LoongArch: kexec: Fix address space mismatch in
> command line lookup"), whose char head[] change patch 2 builds on.
>
> [1] https://lore.kernel.org/all/20260604114106.391502-1-dongtai.guo@xxxxxxxxx/
> [2] https://lore.kernel.org/all/20260701023747.56221-1-dongtai.guo@xxxxxxxxx/
>
> Changes in v4:
>  - Add patch 2: load the command line in its own kexec segment, dropping the
>    fixed KEXEC_CMDLINE_ADDR that overlaps the QEMU FDT (addresses the command
>    line concern from the v3 review).
>  - Patch 1 (relocation trampoline): drop the KEXEC_CMDLINE_ADDR comment added
>    in v3 that claimed 0x108000 does not overlap the FDT (it does; patch 2
>    removes the fixed address entirely).  No functional change otherwise.
>
> v3: https://lore.kernel.org/all/20260604114106.391502-1-dongtai.guo@xxxxxxxxx/
> v2: https://lore.kernel.org/all/20260601033820.38805-1-dongtai.guo@xxxxxxxxx/
> v1: https://lore.kernel.org/all/20260528135828.196953-1-dongtai.guo@xxxxxxxxx/
>
> George Guo (2):
>   LoongArch: kexec: use core control page for relocation trampoline to
>     avoid QEMU FDT conflict
>   LoongArch: kexec: load the command line in its own segment
>
>  arch/loongarch/include/asm/kexec.h         |  1 +
>  arch/loongarch/kernel/machine_kexec.c      | 38 ++++++++++------------
>  arch/loongarch/kernel/machine_kexec_file.c | 33 +++++++++++++++++--
>  3 files changed, 49 insertions(+), 23 deletions(-)
>
> --
> 2.25.1
>