Hi, Jiaxun, On Fri, Jan 8, 2021 at 6:15 PM Jiaxun Yang <jiaxun.yang@xxxxxxxxxxx> wrote: > > 在 2021/1/8 下午6:07, Jinyang He 写道: > > Hi, Thomas, > > > > On 01/08/2021 01:26 AM, Thomas Bogendoerfer wrote: > >>>>> --- 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_LOONGSON64 > >> Is 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. As I said before, only the control page is safe during kexec, so we cannot reuse smp.c. If BIOS provides play_dead(), that is also a safe region, but currently there is no runtime service from BIOS. Huacai > > - Jiaxun > > > > > Above all just my personal thoughts. > > > > Thanks, > > Jinyang > > >
