Re: [PATCH V3] MIPS: Loongson64: Add kexec/kdump support
From: Jiaxun Yang <jiaxun.yang@flygoat.com>
Date: 2021-01-08 10:16:03
Also in:
kexec
在 2021/1/8 下午6:07, Jinyang He 写道:
Hi, Thomas, On 01/08/2021 01:26 AM, Thomas Bogendoerfer wrote:quoted
quoted
quoted
quoted
--- a/arch/mips/kernel/relocate_kernel.S +++ b/arch/mips/kernel/relocate_kernel.S@@ -6,6 +6,7 @@#include <asm/asm.h> #include <asm/asmmacro.h> +#include <asm/cpu.h> #include <asm/regdef.h> #include <asm/mipsregs.h> #include <asm/stackframe.h>@@ -133,6 +134,33 @@ LEAF(kexec_smp_wait)#else sync #endif + +#ifdef CONFIG_CPU_LOONGSON64Is there a reason why you can't use the already existing infrastructure the way cavium-octeon is doing it ? If you can't please explain why so we can find a way to extend it. But having some sort of poking loongson registers in generic MIPS code is a non starter. Thomas.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.
Hi Jingyang, As I commented before you may reuse play_dead logic in Loongson's smp.c.
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...
It won't be a problem as you can keep all data on-stack without external reference. Thanks. - Jiaxun
Above all just my personal thoughts. Thanks, Jinyang