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

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.

Thanks,
George