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

[Jiaxun Yang]

在 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

Thanks.

- Jiaxun

>
> Huacai
>> - Jiaxun
>>
>>> Above all just my personal thoughts.
>>>
>>> Thanks,
>>> Jinyang
>>>