On 01/20/2021 05:08 AM, Thomas Bogendoerfer wrote:

On Fri, Jan 08, 2021 at 06:07:39PM +0800, Jinyang He wrote:

quoted

Unlike the cavium-octeon platform, the Loongson64 platform needs some
changes. Before the kernel starts, (before entering the kernel_entry), each
CPU has its own state (the SMP system). For Loongson64, only the boot CPU
will enter the kernel_entry, and other CPUs will query their mailbox value
in a loop. This is what the BIOS does for the CPU. Here is different from
cavium-octeon. All CPUs will enter the kernel_entry on cavium-octeon
platform. Then the kernel_entry_setup, the co-CPUs will enter the query
loop. I saw the kernel_entry_setup of other platforms, such as ip27, malta,
and generic. They are not like cavium-octeon and the co-CPUs entering the
loop may be earlier than entering kernel_entry. So I have reason to guess
that most SMP system platform CPUs are similar to Loongson64.

relocate_kernel.S is like BIOS doing s omething for the CPU. It allows the
boot CPU to start from the new kernel_entry and makes the co-CPUs enter a
loop. The already existing infrastructure may be more suitable for non-smp
platforms. Although we can do something with plat_smp_ops.kexec_nonboot_cpu,
more new problems will arise in that case. The kexec process actually runs
on a copy of relocate_kernel.S, which will bring a lot of problems...

Above all just my personal thoughts.

thank you for describing current state. So it looks like kexec and SMP
is probably only working for Octeon and maybe some MIPS VPE based SMP
systems, but not with "real" cores.

How about the patch below as preparation for your loongson64 kexec patch ?
You only need to put write a kexec_smp_wait_final macro and the rest of
your patch stays the same...

Thomas.

Thank you for this patch. By applying your patch and the revised Huacai's
patch, kexec works well on the Loongson-3A4000. I compared the assembly
code, too. It's the same as the previous patch doing. I think it's correct.
Huacai, how do you think about it?

Thanks, :-)
Jinyang