[PATCH V3] MIPS: Loongson64: Add kexec/kdump support

[Huacai Chen]

Hi, Jiaxun,

On Sat, Jan 9, 2021 at 3:38 PM Jiaxun Yang <jiaxun.yang at flygoat.com> wrote:
>
> 在 2021/1/9 上午9:36, Huacai Chen 写道:
> > Hi, Jiaxun,
> >
> > On Fri, Jan 8, 2021 at 6:15 PM Jiaxun Yang <jiaxun.yang at flygoat.com> 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
> >>>
>