Hi, Jiaxun, On Sat, Jan 9, 2021 at 3:38 PM Jiaxun Yang <jiaxun.yang@xxxxxxxxxxx> wrote: > > 在 2021/1/9 上午9:36, Huacai Chen 写道: > > 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. > > Sorry, ignored the overlap case :-( > > Jumping to 0xbfc00000 to use firmware boot vector seems a little bit > overkill. > > But we'd better delivery it into platform folder, just like > kernel-entry-init.h Even if we move something to kernel-entry-init.h, we still need to modify arch/mips/kernel/relocate_kernel.S. Huacai > > Thanks. > > - Jiaxun > > > > > Huacai > >> - Jiaxun > >> > >>> Above all just my personal thoughts. > >>> > >>> Thanks, > >>> Jinyang > >>> > _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
