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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



在 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

Thanks.

- Jiaxun


Huacai
- Jiaxun

Above all just my personal thoughts.

Thanks,
Jinyang



_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec




[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux