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

[Huacai Chen]

On Thu, Jul 9, 2026 at 8:48 PM George Guo <dongtai.guo at linux.dev> wrote:
>
> Hi Huacai,
>
> Thanks for the correction, and I am sorry for the way I handled this.
>
> > 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.
>
> You are right, and I was wrong to call the trampoline dead once the new
> kernel starts.  The non-boot CPUs spin in kexec_smp_wait inside the
> trampoline buffer and only leave it when the new kernel brings them
> online, so with maxcpus=1 they stay there until a later CPU hotplug.
> The buffer has to stay valid the whole time.
>
> That breaks my patch 1.  control_code_page is allocated by the kexec
> core and is not reserved in the new kernel, so the new kernel can reuse
> that page while the non-boot CPUs are still spinning in it, and small
> memory makes that more likely.  The fixed KEXEC_CONTROL_CODE at 0x100000
> avoided this because the first 2MB is memblock_reserve()d in both
> kernels; its only problem was that it overlaps QEMU's machine FDT at
> 0x100000.  So my Q2 answer in the cover letter was also wrong, and "as
> arm64/riscv do" does not apply here.
>
> So the trampoline still needs to live in the cross-kexec reserved first
> 2MB, just not on top of the FDT.  The FDT declares fdt_totalsize 1MB and
> covers [0x100000, 0x200000), so the room left is below 0x100000.
>
> Do you have a different fix in mind? I would like to agree on the
> direction with you before I send anything.
>
> > BTW,  you have never replied to my comments, all you have done is
> > submit new versions again and again.
>
> That is fair, and it was my mistake.  I should have replied to your
> review in the thread and discussed it before sending a new version,
> instead of putting my answers in a cover letter.  I will reply to
> comments first from now on.
>
> I will hold the series until we settle the trampoline approach.
I had proposed a reasonable solution as early as in v1.

Huacai

>
> Thanks,
> George