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

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

[Huacai Chen]

From: Huacai Chen <chenhc@lemote.com>

Add kexec/kdump support for Loongson64 by:
1, Provide Loongson-specific kexec functions: loongson_kexec_prepare(),
   loongson_kexec_shutdown() and loongson_crash_shutdown();
2, Provide Loongson-specific assembly code in kexec_smp_wait();

To start Loongson64, The boot CPU needs 3 parameters:
fw_arg0: the number of arguments in cmdline (i.e., argc).
fw_arg1: structure holds cmdline such as "root=/dev/sda1 console=tty"
         (i.e., argv).
fw_arg2: environment (i.e., envp, additional boot parameters from LEFI).

Non-boot CPUs do not need one parameter as the IPI mailbox base address.
They query their own IPI mailbox to get PC, SP and GP in a loopi, until
the boot CPU brings them up.

loongson_kexec_prepare(): Setup cmdline for kexec/kdump. The kexec/kdump
cmdline comes from kexec's "append" option string. This structure will
be parsed in fw_init_cmdline() of arch/mips/fw/lib/cmdline.c. Both image
->control_code_page and the cmdline need to be in a safe memory region
(memory allocated by the old kernel may be corrupted by the new kernel).
In order to maintain compatibility for the old firmware, the low 2MB is
reserverd and safe for Loongson. So let KEXEC_CTRL_CODE and KEXEC_ARGV_
ADDR be here. LEFI parameters may be corrupted at runtime, so backup it
at mips_reboot_setup(), and then restore it at loongson_kexec_shutdown()
/loongson_crash_shutdown().

loongson_kexec_shutdown(): Wake up all present CPUs and let them go to
reboot_code_buffer. Pass the kexec parameters to kexec_args.

loongson_crash_shutdown(): Pass the kdump parameters to kexec_args.

The assembly part in kexec_smp_wait provide a routine as BIOS does, in
order to keep secondary CPUs in a querying loop.

The layout of low 2MB memory in our design:
0x80000000, the first MB, the first 64K, Exception vectors
0x80010000, the first MB, the second 64K, STR (suspend) data
0x80020000, the first MB, the third and fourth 64K, UEFI HOB
0x80040000, the first MB, the fifth 64K, RT-Thread for SMC
0x80100000, the second MB, the first 64K, KEXEC code
0x80108000, the second MB, the second 64K, KEXEC data

Cc: Eric Biederman <ebiederm@xmission.com>
Signed-off-by: Huacai Chen <chenhuacai@kernel.org>
Signed-off-by: Jinyang He <hejinyang@loongson.cn>
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
---
 V3: Some minor improvements suggested by Jinyang He.

 arch/mips/kernel/relocate_kernel.S |  28 +++++++
 arch/mips/loongson64/reset.c       | 113 +++++++++++++++++++++++++++++
 2 files changed, 141 insertions(+)

diff --git a/arch/mips/kernel/relocate_kernel.S b/arch/mips/kernel/relocate_kernel.S
index ac870893ba2d..f649ffa0f427 100644
--- 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
+	/* s0:prid s1:initfn */
+	/* a0:base t1:cpuid t2:node t9:count */
+	mfc0		t1, CP0_EBASE
+	andi		t1, MIPS_EBASE_CPUNUM
+	dins		a0, t1, 8, 2       /* insert core id*/
+	dext		t2, t1, 2, 2
+	dins		a0, t2, 44, 2      /* insert node id */
+	mfc0		s0, CP0_PRID
+	andi		s0, s0, (PRID_IMP_MASK | PRID_REV_MASK)
+	beq		s0, (PRID_IMP_LOONGSON_64C | PRID_REV_LOONGSON3B_R1), 1f
+	beq		s0, (PRID_IMP_LOONGSON_64C | PRID_REV_LOONGSON3B_R2), 1f
+	b		2f                 /* Loongson-3A1000/3A2000/3A3000/3A4000 */
+1:	dins		a0, t2, 14, 2      /* Loongson-3B1000/3B1500 need bit 15~14 */
+2:	li		t9, 0x100          /* wait for init loop */
+3:	addiu		t9, -1             /* limit mailbox access */
+	bnez		t9, 3b
+	lw		s1, 0x20(a0)       /* check PC as an indicator */
+	beqz		s1, 2b
+	ld		s1, 0x20(a0)       /* get PC via mailbox reg0 */
+	ld		sp, 0x28(a0)       /* get SP via mailbox reg1 */
+	ld		gp, 0x30(a0)       /* get GP via mailbox reg2 */
+	ld		a1, 0x38(a0)
+	jr		s1                 /* jump to initial PC */
+#endif
+
 	j		s1
 	END(kexec_smp_wait)
 #endif
diff --git a/arch/mips/loongson64/reset.c b/arch/mips/loongson64/reset.c
index 3bb8a1ed9348..c97bfdc8c922 100644
--- a/arch/mips/loongson64/reset.c
+++ b/arch/mips/loongson64/reset.c
@@ -6,9 +6,14 @@
  * Copyright (C) 2009 Lemote, Inc.
  * Author: Zhangjin Wu, wuzhangjin@gmail.com
  */
+#include <linux/cpu.h>
+#include <linux/delay.h>
 #include <linux/init.h>
+#include <linux/kexec.h>
 #include <linux/pm.h>
+#include <linux/slab.h>
 
+#include <asm/bootinfo.h>
 #include <asm/idle.h>
 #include <asm/reboot.h>
 
@@ -47,12 +52,120 @@ static void loongson_halt(void)
 	}
 }
 
+#ifdef CONFIG_KEXEC
+
+/* 0X80000000~0X80200000 is safe */
+#define MAX_ARGS	64
+#define KEXEC_CTRL_CODE	0xFFFFFFFF80100000UL
+#define KEXEC_ARGV_ADDR	0xFFFFFFFF80108000UL
+#define KEXEC_ARGV_SIZE	COMMAND_LINE_SIZE
+#define KEXEC_ENVP_SIZE	4800
+
+static int kexec_argc;
+static int kdump_argc;
+static void *kexec_argv;
+static void *kdump_argv;
+static void *kexec_envp;
+
+static int loongson_kexec_prepare(struct kimage *image)
+{
+	int i, argc = 0;
+	unsigned int *argv;
+	char *str, *ptr, *bootloader = "kexec";
+
+	/* argv at offset 0, argv[] at offset KEXEC_ARGV_SIZE/2 */
+	if (image->type == KEXEC_TYPE_DEFAULT)
+		argv = (unsigned int *)kexec_argv;
+	else
+		argv = (unsigned int *)kdump_argv;
+
+	argv[argc++] = (unsigned int)(KEXEC_ARGV_ADDR + KEXEC_ARGV_SIZE/2);
+
+	for (i = 0; i < image->nr_segments; i++) {
+		if (!strncmp(bootloader, (char *)image->segment[i].buf,
+				strlen(bootloader))) {
+			/*
+			 * convert command line string to array
+			 * of parameters (as bootloader does).
+			 */
+			int offt;
+			str = (char *)argv + KEXEC_ARGV_SIZE/2;
+			memcpy(str, image->segment[i].buf, KEXEC_ARGV_SIZE/2);
+			ptr = strchr(str, ' ');
+
+			while (ptr && (argc < MAX_ARGS)) {
+				*ptr = '\0';
+				if (ptr[1] != ' ') {
+					offt = (int)(ptr - str + 1);
+					argv[argc] = KEXEC_ARGV_ADDR + KEXEC_ARGV_SIZE/2 + offt;
+					argc++;
+				}
+				ptr = strchr(ptr + 1, ' ');
+			}
+			break;
+		}
+	}
+
+	if (image->type == KEXEC_TYPE_DEFAULT)
+		kexec_argc = argc;
+	else
+		kdump_argc = argc;
+
+	/* kexec/kdump need a safe page to save reboot_code_buffer */
+	image->control_code_page = virt_to_page((void *)KEXEC_CTRL_CODE);
+
+	return 0;
+}
+
+static void loongson_kexec_shutdown(void)
+{
+#ifdef CONFIG_SMP
+	int cpu;
+
+	/* All CPUs go to reboot_code_buffer */
+	for_each_possible_cpu(cpu)
+		if (!cpu_online(cpu))
+			cpu_device_up(get_cpu_device(cpu));
+#endif
+	kexec_args[0] = kexec_argc;
+	kexec_args[1] = fw_arg1;
+	kexec_args[2] = fw_arg2;
+	secondary_kexec_args[0] = TO_UNCAC(0x3ff01000);
+	memcpy((void *)fw_arg1, kexec_argv, KEXEC_ARGV_SIZE);
+	memcpy((void *)fw_arg2, kexec_envp, KEXEC_ENVP_SIZE);
+}
+
+static void loongson_crash_shutdown(struct pt_regs *regs)
+{
+	default_machine_crash_shutdown(regs);
+	kexec_args[0] = kdump_argc;
+	kexec_args[1] = fw_arg1;
+	kexec_args[2] = fw_arg2;
+	secondary_kexec_args[0] = TO_UNCAC(0x3ff01000);
+	memcpy((void *)fw_arg1, kdump_argv, KEXEC_ARGV_SIZE);
+	memcpy((void *)fw_arg2, kexec_envp, KEXEC_ENVP_SIZE);
+}
+
+#endif
+
 static int __init mips_reboot_setup(void)
 {
 	_machine_restart = loongson_restart;
 	_machine_halt = loongson_halt;
 	pm_power_off = loongson_poweroff;
 
+#ifdef CONFIG_KEXEC
+	kexec_argv = kmalloc(KEXEC_ARGV_SIZE, GFP_KERNEL);
+	kdump_argv = kmalloc(KEXEC_ARGV_SIZE, GFP_KERNEL);
+	kexec_envp = kmalloc(KEXEC_ENVP_SIZE, GFP_KERNEL);
+	fw_arg1 = KEXEC_ARGV_ADDR;
+	memcpy(kexec_envp, (void *)fw_arg2, KEXEC_ENVP_SIZE);
+
+	_machine_kexec_prepare = loongson_kexec_prepare;
+	_machine_kexec_shutdown = loongson_kexec_shutdown;
+	_machine_crash_shutdown = loongson_crash_shutdown;
+#endif
+
 	return 0;
 }
 
-- 
2.27.0

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

[Huacai Chen]

From: Huacai Chen <chenhc@lemote.com>

Add kexec/kdump support for Loongson64 by:
1, Provide Loongson-specific kexec functions: loongson_kexec_prepare(),
   loongson_kexec_shutdown() and loongson_crash_shutdown();
2, Provide Loongson-specific assembly code in kexec_smp_wait();

To start Loongson64, The boot CPU needs 3 parameters:
fw_arg0: the number of arguments in cmdline (i.e., argc).
fw_arg1: structure holds cmdline such as "root=/dev/sda1 console=tty"
         (i.e., argv).
fw_arg2: environment (i.e., envp, additional boot parameters from LEFI).

Non-boot CPUs do not need one parameter as the IPI mailbox base address.
They query their own IPI mailbox to get PC, SP and GP in a loopi, until
the boot CPU brings them up.

loongson_kexec_prepare(): Setup cmdline for kexec/kdump. The kexec/kdump
cmdline comes from kexec's "append" option string. This structure will
be parsed in fw_init_cmdline() of arch/mips/fw/lib/cmdline.c. Both image
->control_code_page and the cmdline need to be in a safe memory region
(memory allocated by the old kernel may be corrupted by the new kernel).
In order to maintain compatibility for the old firmware, the low 2MB is
reserverd and safe for Loongson. So let KEXEC_CTRL_CODE and KEXEC_ARGV_
ADDR be here. LEFI parameters may be corrupted at runtime, so backup it
at mips_reboot_setup(), and then restore it at loongson_kexec_shutdown()
/loongson_crash_shutdown().

loongson_kexec_shutdown(): Wake up all present CPUs and let them go to
reboot_code_buffer. Pass the kexec parameters to kexec_args.

loongson_crash_shutdown(): Pass the kdump parameters to kexec_args.

The assembly part in kexec_smp_wait provide a routine as BIOS does, in
order to keep secondary CPUs in a querying loop.

The layout of low 2MB memory in our design:
0x80000000, the first MB, the first 64K, Exception vectors
0x80010000, the first MB, the second 64K, STR (suspend) data
0x80020000, the first MB, the third and fourth 64K, UEFI HOB
0x80040000, the first MB, the fifth 64K, RT-Thread for SMC
0x80100000, the second MB, the first 64K, KEXEC code
0x80108000, the second MB, the second 64K, KEXEC data

Cc: Eric Biederman <ebiederm@xmission.com>
Signed-off-by: Huacai Chen <chenhuacai@kernel.org>
Signed-off-by: Jinyang He <hejinyang@loongson.cn>
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
---
 V3: Some minor improvements suggested by Jinyang He.

 arch/mips/kernel/relocate_kernel.S |  28 +++++++
 arch/mips/loongson64/reset.c       | 113 +++++++++++++++++++++++++++++
 2 files changed, 141 insertions(+)

diff --git a/arch/mips/kernel/relocate_kernel.S b/arch/mips/kernel/relocate_kernel.S
index ac870893ba2d..f649ffa0f427 100644
--- 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
+	/* s0:prid s1:initfn */
+	/* a0:base t1:cpuid t2:node t9:count */
+	mfc0		t1, CP0_EBASE
+	andi		t1, MIPS_EBASE_CPUNUM
+	dins		a0, t1, 8, 2       /* insert core id*/
+	dext		t2, t1, 2, 2
+	dins		a0, t2, 44, 2      /* insert node id */
+	mfc0		s0, CP0_PRID
+	andi		s0, s0, (PRID_IMP_MASK | PRID_REV_MASK)
+	beq		s0, (PRID_IMP_LOONGSON_64C | PRID_REV_LOONGSON3B_R1), 1f
+	beq		s0, (PRID_IMP_LOONGSON_64C | PRID_REV_LOONGSON3B_R2), 1f
+	b		2f                 /* Loongson-3A1000/3A2000/3A3000/3A4000 */
+1:	dins		a0, t2, 14, 2      /* Loongson-3B1000/3B1500 need bit 15~14 */
+2:	li		t9, 0x100          /* wait for init loop */
+3:	addiu		t9, -1             /* limit mailbox access */
+	bnez		t9, 3b
+	lw		s1, 0x20(a0)       /* check PC as an indicator */
+	beqz		s1, 2b
+	ld		s1, 0x20(a0)       /* get PC via mailbox reg0 */
+	ld		sp, 0x28(a0)       /* get SP via mailbox reg1 */
+	ld		gp, 0x30(a0)       /* get GP via mailbox reg2 */
+	ld		a1, 0x38(a0)
+	jr		s1                 /* jump to initial PC */
+#endif
+
 	j		s1
 	END(kexec_smp_wait)
 #endif
diff --git a/arch/mips/loongson64/reset.c b/arch/mips/loongson64/reset.c
index 3bb8a1ed9348..c97bfdc8c922 100644
--- a/arch/mips/loongson64/reset.c
+++ b/arch/mips/loongson64/reset.c
@@ -6,9 +6,14 @@
  * Copyright (C) 2009 Lemote, Inc.
  * Author: Zhangjin Wu, wuzhangjin@gmail.com
  */
+#include <linux/cpu.h>
+#include <linux/delay.h>
 #include <linux/init.h>
+#include <linux/kexec.h>
 #include <linux/pm.h>
+#include <linux/slab.h>
 
+#include <asm/bootinfo.h>
 #include <asm/idle.h>
 #include <asm/reboot.h>
 
@@ -47,12 +52,120 @@ static void loongson_halt(void)
 	}
 }
 
+#ifdef CONFIG_KEXEC
+
+/* 0X80000000~0X80200000 is safe */
+#define MAX_ARGS	64
+#define KEXEC_CTRL_CODE	0xFFFFFFFF80100000UL
+#define KEXEC_ARGV_ADDR	0xFFFFFFFF80108000UL
+#define KEXEC_ARGV_SIZE	COMMAND_LINE_SIZE
+#define KEXEC_ENVP_SIZE	4800
+
+static int kexec_argc;
+static int kdump_argc;
+static void *kexec_argv;
+static void *kdump_argv;
+static void *kexec_envp;
+
+static int loongson_kexec_prepare(struct kimage *image)
+{
+	int i, argc = 0;
+	unsigned int *argv;
+	char *str, *ptr, *bootloader = "kexec";
+
+	/* argv at offset 0, argv[] at offset KEXEC_ARGV_SIZE/2 */
+	if (image->type == KEXEC_TYPE_DEFAULT)
+		argv = (unsigned int *)kexec_argv;
+	else
+		argv = (unsigned int *)kdump_argv;
+
+	argv[argc++] = (unsigned int)(KEXEC_ARGV_ADDR + KEXEC_ARGV_SIZE/2);
+
+	for (i = 0; i < image->nr_segments; i++) {
+		if (!strncmp(bootloader, (char *)image->segment[i].buf,
+				strlen(bootloader))) {
+			/*
+			 * convert command line string to array
+			 * of parameters (as bootloader does).
+			 */
+			int offt;
+			str = (char *)argv + KEXEC_ARGV_SIZE/2;
+			memcpy(str, image->segment[i].buf, KEXEC_ARGV_SIZE/2);
+			ptr = strchr(str, ' ');
+
+			while (ptr && (argc < MAX_ARGS)) {
+				*ptr = '\0';
+				if (ptr[1] != ' ') {
+					offt = (int)(ptr - str + 1);
+					argv[argc] = KEXEC_ARGV_ADDR + KEXEC_ARGV_SIZE/2 + offt;
+					argc++;
+				}
+				ptr = strchr(ptr + 1, ' ');
+			}
+			break;
+		}
+	}
+
+	if (image->type == KEXEC_TYPE_DEFAULT)
+		kexec_argc = argc;
+	else
+		kdump_argc = argc;
+
+	/* kexec/kdump need a safe page to save reboot_code_buffer */
+	image->control_code_page = virt_to_page((void *)KEXEC_CTRL_CODE);
+
+	return 0;
+}
+
+static void loongson_kexec_shutdown(void)
+{
+#ifdef CONFIG_SMP
+	int cpu;
+
+	/* All CPUs go to reboot_code_buffer */
+	for_each_possible_cpu(cpu)
+		if (!cpu_online(cpu))
+			cpu_device_up(get_cpu_device(cpu));
+#endif
+	kexec_args[0] = kexec_argc;
+	kexec_args[1] = fw_arg1;
+	kexec_args[2] = fw_arg2;
+	secondary_kexec_args[0] = TO_UNCAC(0x3ff01000);
+	memcpy((void *)fw_arg1, kexec_argv, KEXEC_ARGV_SIZE);
+	memcpy((void *)fw_arg2, kexec_envp, KEXEC_ENVP_SIZE);
+}
+
+static void loongson_crash_shutdown(struct pt_regs *regs)
+{
+	default_machine_crash_shutdown(regs);
+	kexec_args[0] = kdump_argc;
+	kexec_args[1] = fw_arg1;
+	kexec_args[2] = fw_arg2;
+	secondary_kexec_args[0] = TO_UNCAC(0x3ff01000);
+	memcpy((void *)fw_arg1, kdump_argv, KEXEC_ARGV_SIZE);
+	memcpy((void *)fw_arg2, kexec_envp, KEXEC_ENVP_SIZE);
+}
+
+#endif
+
 static int __init mips_reboot_setup(void)
 {
 	_machine_restart = loongson_restart;
 	_machine_halt = loongson_halt;
 	pm_power_off = loongson_poweroff;
 
+#ifdef CONFIG_KEXEC
+	kexec_argv = kmalloc(KEXEC_ARGV_SIZE, GFP_KERNEL);
+	kdump_argv = kmalloc(KEXEC_ARGV_SIZE, GFP_KERNEL);
+	kexec_envp = kmalloc(KEXEC_ENVP_SIZE, GFP_KERNEL);
+	fw_arg1 = KEXEC_ARGV_ADDR;
+	memcpy(kexec_envp, (void *)fw_arg2, KEXEC_ENVP_SIZE);
+
+	_machine_kexec_prepare = loongson_kexec_prepare;
+	_machine_kexec_shutdown = loongson_kexec_shutdown;
+	_machine_crash_shutdown = loongson_crash_shutdown;
+#endif
+
 	return 0;
 }
 
-- 
2.27.0


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

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

[Jinyang He]

On 12/21/2020 08:02 PM, Huacai Chen wrote:

> From: Huacai Chen <chenhc@lemote.com>
>
> Add kexec/kdump support for Loongson64 by:
> 1, Provide Loongson-specific kexec functions: loongson_kexec_prepare(),
>     loongson_kexec_shutdown() and loongson_crash_shutdown();
> 2, Provide Loongson-specific assembly code in kexec_smp_wait();
>
> To start Loongson64, The boot CPU needs 3 parameters:
> fw_arg0: the number of arguments in cmdline (i.e., argc).
> fw_arg1: structure holds cmdline such as "root=/dev/sda1 console=tty"
>           (i.e., argv).
> fw_arg2: environment (i.e., envp, additional boot parameters from LEFI).
>
> Non-boot CPUs do not need one parameter as the IPI mailbox base address.
> They query their own IPI mailbox to get PC, SP and GP in a loopi, until
> the boot CPU brings them up.
>
> loongson_kexec_prepare(): Setup cmdline for kexec/kdump. The kexec/kdump
> cmdline comes from kexec's "append" option string. This structure will
> be parsed in fw_init_cmdline() of arch/mips/fw/lib/cmdline.c. Both image
> ->control_code_page and the cmdline need to be in a safe memory region
> (memory allocated by the old kernel may be corrupted by the new kernel).
> In order to maintain compatibility for the old firmware, the low 2MB is
> reserverd and safe for Loongson. So let KEXEC_CTRL_CODE and KEXEC_ARGV_
> ADDR be here. LEFI parameters may be corrupted at runtime, so backup it
> at mips_reboot_setup(), and then restore it at loongson_kexec_shutdown()
> /loongson_crash_shutdown().
>
> loongson_kexec_shutdown(): Wake up all present CPUs and let them go to
> reboot_code_buffer. Pass the kexec parameters to kexec_args.
>
> loongson_crash_shutdown(): Pass the kdump parameters to kexec_args.
>
> The assembly part in kexec_smp_wait provide a routine as BIOS does, in
> order to keep secondary CPUs in a querying loop.
>
> The layout of low 2MB memory in our design:
> 0x80000000, the first MB, the first 64K, Exception vectors
> 0x80010000, the first MB, the second 64K, STR (suspend) data
> 0x80020000, the first MB, the third and fourth 64K, UEFI HOB
> 0x80040000, the first MB, the fifth 64K, RT-Thread for SMC
> 0x80100000, the second MB, the first 64K, KEXEC code
> 0x80108000, the second MB, the second 64K, KEXEC data
>
> Cc: Eric Biederman <ebiederm@xmission.com>
> Signed-off-by: Huacai Chen <chenhuacai@kernel.org>
> Signed-off-by: Jinyang He <hejinyang@loongson.cn>
> Signed-off-by: Youling Tang <tangyouling@loongson.cn>
> ---
>   V3: Some minor improvements suggested by Jinyang He.
>
>   arch/mips/kernel/relocate_kernel.S |  28 +++++++
>   arch/mips/loongson64/reset.c       | 113 +++++++++++++++++++++++++++++
>   2 files changed, 141 insertions(+)
kexec-tools v2.0.21
3A3000/7A1000 3A4000/7A1000

Test kexec:

# kexec -l vmlinux --append="<cmdline>"
# kexec -e

Result: OK!

Test kdump: We need a capture kernel to dump the panic kernel.
To build the capture kernel:
make loongson3_defconfig and set CONFIG_PROC_VMCORE=y , CONFIG_CRASH_DUMP=y
and CONFIG_PHYSICAL_START=0xffffffff84000000

# kexec -p vmlinux(capture) --append="<cmdline>"
# echo c > /proc/sysrq-trigger

Result: OK!

Tested-by: Jinyang He <hejinyang@loongson.cn>

Thanks, :-)
Jinyang

> diff --git a/arch/mips/kernel/relocate_kernel.S b/arch/mips/kernel/relocate_kernel.S
> index ac870893ba2d..f649ffa0f427 100644
> --- 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
> +	/* s0:prid s1:initfn */
> +	/* a0:base t1:cpuid t2:node t9:count */
> +	mfc0		t1, CP0_EBASE
> +	andi		t1, MIPS_EBASE_CPUNUM
> +	dins		a0, t1, 8, 2       /* insert core id*/
> +	dext		t2, t1, 2, 2
> +	dins		a0, t2, 44, 2      /* insert node id */
> +	mfc0		s0, CP0_PRID
> +	andi		s0, s0, (PRID_IMP_MASK | PRID_REV_MASK)
> +	beq		s0, (PRID_IMP_LOONGSON_64C | PRID_REV_LOONGSON3B_R1), 1f
> +	beq		s0, (PRID_IMP_LOONGSON_64C | PRID_REV_LOONGSON3B_R2), 1f
> +	b		2f                 /* Loongson-3A1000/3A2000/3A3000/3A4000 */
> +1:	dins		a0, t2, 14, 2      /* Loongson-3B1000/3B1500 need bit 15~14 */
> +2:	li		t9, 0x100          /* wait for init loop */
> +3:	addiu		t9, -1             /* limit mailbox access */
> +	bnez		t9, 3b
> +	lw		s1, 0x20(a0)       /* check PC as an indicator */
> +	beqz		s1, 2b
> +	ld		s1, 0x20(a0)       /* get PC via mailbox reg0 */
> +	ld		sp, 0x28(a0)       /* get SP via mailbox reg1 */
> +	ld		gp, 0x30(a0)       /* get GP via mailbox reg2 */
> +	ld		a1, 0x38(a0)
> +	jr		s1                 /* jump to initial PC */
> +#endif
> +
>   	j		s1
>   	END(kexec_smp_wait)
>   #endif
> diff --git a/arch/mips/loongson64/reset.c b/arch/mips/loongson64/reset.c
> index 3bb8a1ed9348..c97bfdc8c922 100644
> --- a/arch/mips/loongson64/reset.c
> +++ b/arch/mips/loongson64/reset.c
> @@ -6,9 +6,14 @@
>    * Copyright (C) 2009 Lemote, Inc.
>    * Author: Zhangjin Wu, wuzhangjin@gmail.com
>    */
> +#include <linux/cpu.h>
> +#include <linux/delay.h>
>   #include <linux/init.h>
> +#include <linux/kexec.h>
>   #include <linux/pm.h>
> +#include <linux/slab.h>
>   
> +#include <asm/bootinfo.h>
>   #include <asm/idle.h>
>   #include <asm/reboot.h>
>   
> @@ -47,12 +52,120 @@ static void loongson_halt(void)
>   	}
>   }
>   
> +#ifdef CONFIG_KEXEC
> +
> +/* 0X80000000~0X80200000 is safe */
> +#define MAX_ARGS	64
> +#define KEXEC_CTRL_CODE	0xFFFFFFFF80100000UL
> +#define KEXEC_ARGV_ADDR	0xFFFFFFFF80108000UL
> +#define KEXEC_ARGV_SIZE	COMMAND_LINE_SIZE
> +#define KEXEC_ENVP_SIZE	4800
> +
> +static int kexec_argc;
> +static int kdump_argc;
> +static void *kexec_argv;
> +static void *kdump_argv;
> +static void *kexec_envp;
> +
> +static int loongson_kexec_prepare(struct kimage *image)
> +{
> +	int i, argc = 0;
> +	unsigned int *argv;
> +	char *str, *ptr, *bootloader = "kexec";
> +
> +	/* argv at offset 0, argv[] at offset KEXEC_ARGV_SIZE/2 */
> +	if (image->type == KEXEC_TYPE_DEFAULT)
> +		argv = (unsigned int *)kexec_argv;
> +	else
> +		argv = (unsigned int *)kdump_argv;
> +
> +	argv[argc++] = (unsigned int)(KEXEC_ARGV_ADDR + KEXEC_ARGV_SIZE/2);
> +
> +	for (i = 0; i < image->nr_segments; i++) {
> +		if (!strncmp(bootloader, (char *)image->segment[i].buf,
> +				strlen(bootloader))) {
> +			/*
> +			 * convert command line string to array
> +			 * of parameters (as bootloader does).
> +			 */
> +			int offt;
> +			str = (char *)argv + KEXEC_ARGV_SIZE/2;
> +			memcpy(str, image->segment[i].buf, KEXEC_ARGV_SIZE/2);
> +			ptr = strchr(str, ' ');
> +
> +			while (ptr && (argc < MAX_ARGS)) {
> +				*ptr = '\0';
> +				if (ptr[1] != ' ') {
> +					offt = (int)(ptr - str + 1);
> +					argv[argc] = KEXEC_ARGV_ADDR + KEXEC_ARGV_SIZE/2 + offt;
> +					argc++;
> +				}
> +				ptr = strchr(ptr + 1, ' ');
> +			}
> +			break;
> +		}
> +	}
> +
> +	if (image->type == KEXEC_TYPE_DEFAULT)
> +		kexec_argc = argc;
> +	else
> +		kdump_argc = argc;
> +
> +	/* kexec/kdump need a safe page to save reboot_code_buffer */
> +	image->control_code_page = virt_to_page((void *)KEXEC_CTRL_CODE);
> +
> +	return 0;
> +}
> +
> +static void loongson_kexec_shutdown(void)
> +{
> +#ifdef CONFIG_SMP
> +	int cpu;
> +
> +	/* All CPUs go to reboot_code_buffer */
> +	for_each_possible_cpu(cpu)
> +		if (!cpu_online(cpu))
> +			cpu_device_up(get_cpu_device(cpu));
> +#endif
> +	kexec_args[0] = kexec_argc;
> +	kexec_args[1] = fw_arg1;
> +	kexec_args[2] = fw_arg2;
> +	secondary_kexec_args[0] = TO_UNCAC(0x3ff01000);
> +	memcpy((void *)fw_arg1, kexec_argv, KEXEC_ARGV_SIZE);
> +	memcpy((void *)fw_arg2, kexec_envp, KEXEC_ENVP_SIZE);
> +}
> +
> +static void loongson_crash_shutdown(struct pt_regs *regs)
> +{
> +	default_machine_crash_shutdown(regs);
> +	kexec_args[0] = kdump_argc;
> +	kexec_args[1] = fw_arg1;
> +	kexec_args[2] = fw_arg2;
> +	secondary_kexec_args[0] = TO_UNCAC(0x3ff01000);
> +	memcpy((void *)fw_arg1, kdump_argv, KEXEC_ARGV_SIZE);
> +	memcpy((void *)fw_arg2, kexec_envp, KEXEC_ENVP_SIZE);
> +}
> +
> +#endif
> +
>   static int __init mips_reboot_setup(void)
>   {
>   	_machine_restart = loongson_restart;
>   	_machine_halt = loongson_halt;
>   	pm_power_off = loongson_poweroff;
>   
> +#ifdef CONFIG_KEXEC
> +	kexec_argv = kmalloc(KEXEC_ARGV_SIZE, GFP_KERNEL);
> +	kdump_argv = kmalloc(KEXEC_ARGV_SIZE, GFP_KERNEL);
> +	kexec_envp = kmalloc(KEXEC_ENVP_SIZE, GFP_KERNEL);
> +	fw_arg1 = KEXEC_ARGV_ADDR;
> +	memcpy(kexec_envp, (void *)fw_arg2, KEXEC_ENVP_SIZE);
> +
> +	_machine_kexec_prepare = loongson_kexec_prepare;
> +	_machine_kexec_shutdown = loongson_kexec_shutdown;
> +	_machine_crash_shutdown = loongson_crash_shutdown;
> +#endif
> +
>   	return 0;
>   }
>   

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

[Jinyang He]

On 12/21/2020 08:02 PM, Huacai Chen wrote:

> From: Huacai Chen <chenhc@lemote.com>
>
> Add kexec/kdump support for Loongson64 by:
> 1, Provide Loongson-specific kexec functions: loongson_kexec_prepare(),
>     loongson_kexec_shutdown() and loongson_crash_shutdown();
> 2, Provide Loongson-specific assembly code in kexec_smp_wait();
>
> To start Loongson64, The boot CPU needs 3 parameters:
> fw_arg0: the number of arguments in cmdline (i.e., argc).
> fw_arg1: structure holds cmdline such as "root=/dev/sda1 console=tty"
>           (i.e., argv).
> fw_arg2: environment (i.e., envp, additional boot parameters from LEFI).
>
> Non-boot CPUs do not need one parameter as the IPI mailbox base address.
> They query their own IPI mailbox to get PC, SP and GP in a loopi, until
> the boot CPU brings them up.
>
> loongson_kexec_prepare(): Setup cmdline for kexec/kdump. The kexec/kdump
> cmdline comes from kexec's "append" option string. This structure will
> be parsed in fw_init_cmdline() of arch/mips/fw/lib/cmdline.c. Both image
> ->control_code_page and the cmdline need to be in a safe memory region
> (memory allocated by the old kernel may be corrupted by the new kernel).
> In order to maintain compatibility for the old firmware, the low 2MB is
> reserverd and safe for Loongson. So let KEXEC_CTRL_CODE and KEXEC_ARGV_
> ADDR be here. LEFI parameters may be corrupted at runtime, so backup it
> at mips_reboot_setup(), and then restore it at loongson_kexec_shutdown()
> /loongson_crash_shutdown().
>
> loongson_kexec_shutdown(): Wake up all present CPUs and let them go to
> reboot_code_buffer. Pass the kexec parameters to kexec_args.
>
> loongson_crash_shutdown(): Pass the kdump parameters to kexec_args.
>
> The assembly part in kexec_smp_wait provide a routine as BIOS does, in
> order to keep secondary CPUs in a querying loop.
>
> The layout of low 2MB memory in our design:
> 0x80000000, the first MB, the first 64K, Exception vectors
> 0x80010000, the first MB, the second 64K, STR (suspend) data
> 0x80020000, the first MB, the third and fourth 64K, UEFI HOB
> 0x80040000, the first MB, the fifth 64K, RT-Thread for SMC
> 0x80100000, the second MB, the first 64K, KEXEC code
> 0x80108000, the second MB, the second 64K, KEXEC data
>
> Cc: Eric Biederman <ebiederm@xmission.com>
> Signed-off-by: Huacai Chen <chenhuacai@kernel.org>
> Signed-off-by: Jinyang He <hejinyang@loongson.cn>
> Signed-off-by: Youling Tang <tangyouling@loongson.cn>
> ---
>   V3: Some minor improvements suggested by Jinyang He.
>
>   arch/mips/kernel/relocate_kernel.S |  28 +++++++
>   arch/mips/loongson64/reset.c       | 113 +++++++++++++++++++++++++++++
>   2 files changed, 141 insertions(+)
kexec-tools v2.0.21
3A3000/7A1000 3A4000/7A1000

Test kexec:

# kexec -l vmlinux --append="<cmdline>"
# kexec -e

Result: OK!

Test kdump: We need a capture kernel to dump the panic kernel.
To build the capture kernel:
make loongson3_defconfig and set CONFIG_PROC_VMCORE=y , CONFIG_CRASH_DUMP=y
and CONFIG_PHYSICAL_START=0xffffffff84000000

# kexec -p vmlinux(capture) --append="<cmdline>"
# echo c > /proc/sysrq-trigger

Result: OK!

Tested-by: Jinyang He <hejinyang@loongson.cn>

Thanks, :-)
Jinyang

> diff --git a/arch/mips/kernel/relocate_kernel.S b/arch/mips/kernel/relocate_kernel.S
> index ac870893ba2d..f649ffa0f427 100644
> --- 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
> +	/* s0:prid s1:initfn */
> +	/* a0:base t1:cpuid t2:node t9:count */
> +	mfc0		t1, CP0_EBASE
> +	andi		t1, MIPS_EBASE_CPUNUM
> +	dins		a0, t1, 8, 2       /* insert core id*/
> +	dext		t2, t1, 2, 2
> +	dins		a0, t2, 44, 2      /* insert node id */
> +	mfc0		s0, CP0_PRID
> +	andi		s0, s0, (PRID_IMP_MASK | PRID_REV_MASK)
> +	beq		s0, (PRID_IMP_LOONGSON_64C | PRID_REV_LOONGSON3B_R1), 1f
> +	beq		s0, (PRID_IMP_LOONGSON_64C | PRID_REV_LOONGSON3B_R2), 1f
> +	b		2f                 /* Loongson-3A1000/3A2000/3A3000/3A4000 */
> +1:	dins		a0, t2, 14, 2      /* Loongson-3B1000/3B1500 need bit 15~14 */
> +2:	li		t9, 0x100          /* wait for init loop */
> +3:	addiu		t9, -1             /* limit mailbox access */
> +	bnez		t9, 3b
> +	lw		s1, 0x20(a0)       /* check PC as an indicator */
> +	beqz		s1, 2b
> +	ld		s1, 0x20(a0)       /* get PC via mailbox reg0 */
> +	ld		sp, 0x28(a0)       /* get SP via mailbox reg1 */
> +	ld		gp, 0x30(a0)       /* get GP via mailbox reg2 */
> +	ld		a1, 0x38(a0)
> +	jr		s1                 /* jump to initial PC */
> +#endif
> +
>   	j		s1
>   	END(kexec_smp_wait)
>   #endif
> diff --git a/arch/mips/loongson64/reset.c b/arch/mips/loongson64/reset.c
> index 3bb8a1ed9348..c97bfdc8c922 100644
> --- a/arch/mips/loongson64/reset.c
> +++ b/arch/mips/loongson64/reset.c
> @@ -6,9 +6,14 @@
>    * Copyright (C) 2009 Lemote, Inc.
>    * Author: Zhangjin Wu, wuzhangjin@gmail.com
>    */
> +#include <linux/cpu.h>
> +#include <linux/delay.h>
>   #include <linux/init.h>
> +#include <linux/kexec.h>
>   #include <linux/pm.h>
> +#include <linux/slab.h>
>   
> +#include <asm/bootinfo.h>
>   #include <asm/idle.h>
>   #include <asm/reboot.h>
>   
> @@ -47,12 +52,120 @@ static void loongson_halt(void)
>   	}
>   }
>   
> +#ifdef CONFIG_KEXEC
> +
> +/* 0X80000000~0X80200000 is safe */
> +#define MAX_ARGS	64
> +#define KEXEC_CTRL_CODE	0xFFFFFFFF80100000UL
> +#define KEXEC_ARGV_ADDR	0xFFFFFFFF80108000UL
> +#define KEXEC_ARGV_SIZE	COMMAND_LINE_SIZE
> +#define KEXEC_ENVP_SIZE	4800
> +
> +static int kexec_argc;
> +static int kdump_argc;
> +static void *kexec_argv;
> +static void *kdump_argv;
> +static void *kexec_envp;
> +
> +static int loongson_kexec_prepare(struct kimage *image)
> +{
> +	int i, argc = 0;
> +	unsigned int *argv;
> +	char *str, *ptr, *bootloader = "kexec";
> +
> +	/* argv at offset 0, argv[] at offset KEXEC_ARGV_SIZE/2 */
> +	if (image->type == KEXEC_TYPE_DEFAULT)
> +		argv = (unsigned int *)kexec_argv;
> +	else
> +		argv = (unsigned int *)kdump_argv;
> +
> +	argv[argc++] = (unsigned int)(KEXEC_ARGV_ADDR + KEXEC_ARGV_SIZE/2);
> +
> +	for (i = 0; i < image->nr_segments; i++) {
> +		if (!strncmp(bootloader, (char *)image->segment[i].buf,
> +				strlen(bootloader))) {
> +			/*
> +			 * convert command line string to array
> +			 * of parameters (as bootloader does).
> +			 */
> +			int offt;
> +			str = (char *)argv + KEXEC_ARGV_SIZE/2;
> +			memcpy(str, image->segment[i].buf, KEXEC_ARGV_SIZE/2);
> +			ptr = strchr(str, ' ');
> +
> +			while (ptr && (argc < MAX_ARGS)) {
> +				*ptr = '\0';
> +				if (ptr[1] != ' ') {
> +					offt = (int)(ptr - str + 1);
> +					argv[argc] = KEXEC_ARGV_ADDR + KEXEC_ARGV_SIZE/2 + offt;
> +					argc++;
> +				}
> +				ptr = strchr(ptr + 1, ' ');
> +			}
> +			break;
> +		}
> +	}
> +
> +	if (image->type == KEXEC_TYPE_DEFAULT)
> +		kexec_argc = argc;
> +	else
> +		kdump_argc = argc;
> +
> +	/* kexec/kdump need a safe page to save reboot_code_buffer */
> +	image->control_code_page = virt_to_page((void *)KEXEC_CTRL_CODE);
> +
> +	return 0;
> +}
> +
> +static void loongson_kexec_shutdown(void)
> +{
> +#ifdef CONFIG_SMP
> +	int cpu;
> +
> +	/* All CPUs go to reboot_code_buffer */
> +	for_each_possible_cpu(cpu)
> +		if (!cpu_online(cpu))
> +			cpu_device_up(get_cpu_device(cpu));
> +#endif
> +	kexec_args[0] = kexec_argc;
> +	kexec_args[1] = fw_arg1;
> +	kexec_args[2] = fw_arg2;
> +	secondary_kexec_args[0] = TO_UNCAC(0x3ff01000);
> +	memcpy((void *)fw_arg1, kexec_argv, KEXEC_ARGV_SIZE);
> +	memcpy((void *)fw_arg2, kexec_envp, KEXEC_ENVP_SIZE);
> +}
> +
> +static void loongson_crash_shutdown(struct pt_regs *regs)
> +{
> +	default_machine_crash_shutdown(regs);
> +	kexec_args[0] = kdump_argc;
> +	kexec_args[1] = fw_arg1;
> +	kexec_args[2] = fw_arg2;
> +	secondary_kexec_args[0] = TO_UNCAC(0x3ff01000);
> +	memcpy((void *)fw_arg1, kdump_argv, KEXEC_ARGV_SIZE);
> +	memcpy((void *)fw_arg2, kexec_envp, KEXEC_ENVP_SIZE);
> +}
> +
> +#endif
> +
>   static int __init mips_reboot_setup(void)
>   {
>   	_machine_restart = loongson_restart;
>   	_machine_halt = loongson_halt;
>   	pm_power_off = loongson_poweroff;
>   
> +#ifdef CONFIG_KEXEC
> +	kexec_argv = kmalloc(KEXEC_ARGV_SIZE, GFP_KERNEL);
> +	kdump_argv = kmalloc(KEXEC_ARGV_SIZE, GFP_KERNEL);
> +	kexec_envp = kmalloc(KEXEC_ENVP_SIZE, GFP_KERNEL);
> +	fw_arg1 = KEXEC_ARGV_ADDR;
> +	memcpy(kexec_envp, (void *)fw_arg2, KEXEC_ENVP_SIZE);
> +
> +	_machine_kexec_prepare = loongson_kexec_prepare;
> +	_machine_kexec_shutdown = loongson_kexec_shutdown;
> +	_machine_crash_shutdown = loongson_crash_shutdown;
> +#endif
> +
>   	return 0;
>   }
>   


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

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

[Huacai Chen]

Hi, Thomas,

On Tue, Dec 22, 2020 at 2:41 PM Jinyang He <hejinyang@loongson.cn> wrote:
>
> On 12/21/2020 08:02 PM, Huacai Chen wrote:
>
> > From: Huacai Chen <chenhc@lemote.com>
> >
> > Add kexec/kdump support for Loongson64 by:
> > 1, Provide Loongson-specific kexec functions: loongson_kexec_prepare(),
> >     loongson_kexec_shutdown() and loongson_crash_shutdown();
> > 2, Provide Loongson-specific assembly code in kexec_smp_wait();
> >
> > To start Loongson64, The boot CPU needs 3 parameters:
> > fw_arg0: the number of arguments in cmdline (i.e., argc).
> > fw_arg1: structure holds cmdline such as "root=/dev/sda1 console=tty"
> >           (i.e., argv).
> > fw_arg2: environment (i.e., envp, additional boot parameters from LEFI).
> >
> > Non-boot CPUs do not need one parameter as the IPI mailbox base address.
> > They query their own IPI mailbox to get PC, SP and GP in a loopi, until
> > the boot CPU brings them up.
> >
> > loongson_kexec_prepare(): Setup cmdline for kexec/kdump. The kexec/kdump
> > cmdline comes from kexec's "append" option string. This structure will
> > be parsed in fw_init_cmdline() of arch/mips/fw/lib/cmdline.c. Both image
> > ->control_code_page and the cmdline need to be in a safe memory region
> > (memory allocated by the old kernel may be corrupted by the new kernel).
> > In order to maintain compatibility for the old firmware, the low 2MB is
> > reserverd and safe for Loongson. So let KEXEC_CTRL_CODE and KEXEC_ARGV_
> > ADDR be here. LEFI parameters may be corrupted at runtime, so backup it
> > at mips_reboot_setup(), and then restore it at loongson_kexec_shutdown()
> > /loongson_crash_shutdown().
> >
> > loongson_kexec_shutdown(): Wake up all present CPUs and let them go to
> > reboot_code_buffer. Pass the kexec parameters to kexec_args.
> >
> > loongson_crash_shutdown(): Pass the kdump parameters to kexec_args.
> >
> > The assembly part in kexec_smp_wait provide a routine as BIOS does, in
> > order to keep secondary CPUs in a querying loop.
> >
> > The layout of low 2MB memory in our design:
> > 0x80000000, the first MB, the first 64K, Exception vectors
> > 0x80010000, the first MB, the second 64K, STR (suspend) data
> > 0x80020000, the first MB, the third and fourth 64K, UEFI HOB
> > 0x80040000, the first MB, the fifth 64K, RT-Thread for SMC
> > 0x80100000, the second MB, the first 64K, KEXEC code
> > 0x80108000, the second MB, the second 64K, KEXEC data
> >
> > Cc: Eric Biederman <ebiederm@xmission.com>
> > Signed-off-by: Huacai Chen <chenhuacai@kernel.org>
> > Signed-off-by: Jinyang He <hejinyang@loongson.cn>
> > Signed-off-by: Youling Tang <tangyouling@loongson.cn>
> > ---
> >   V3: Some minor improvements suggested by Jinyang He.
> >
> >   arch/mips/kernel/relocate_kernel.S |  28 +++++++
> >   arch/mips/loongson64/reset.c       | 113 +++++++++++++++++++++++++++++
> >   2 files changed, 141 insertions(+)
> kexec-tools v2.0.21
> 3A3000/7A1000 3A4000/7A1000
>
> Test kexec:
>
> # kexec -l vmlinux --append="<cmdline>"
> # kexec -e
>
> Result: OK!
>
> Test kdump: We need a capture kernel to dump the panic kernel.
> To build the capture kernel:
> make loongson3_defconfig and set CONFIG_PROC_VMCORE=y , CONFIG_CRASH_DUMP=y
> and CONFIG_PHYSICAL_START=0xffffffff84000000
>
> # kexec -p vmlinux(capture) --append="<cmdline>"
> # echo c > /proc/sysrq-trigger
>
> Result: OK!
>
> Tested-by: Jinyang He <hejinyang@loongson.cn>
>
> Thanks, :-)
> Jinyang
Any comments?

Huacai
>
> > diff --git a/arch/mips/kernel/relocate_kernel.S b/arch/mips/kernel/relocate_kernel.S
> > index ac870893ba2d..f649ffa0f427 100644
> > --- 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
> > +     /* s0:prid s1:initfn */
> > +     /* a0:base t1:cpuid t2:node t9:count */
> > +     mfc0            t1, CP0_EBASE
> > +     andi            t1, MIPS_EBASE_CPUNUM
> > +     dins            a0, t1, 8, 2       /* insert core id*/
> > +     dext            t2, t1, 2, 2
> > +     dins            a0, t2, 44, 2      /* insert node id */
> > +     mfc0            s0, CP0_PRID
> > +     andi            s0, s0, (PRID_IMP_MASK | PRID_REV_MASK)
> > +     beq             s0, (PRID_IMP_LOONGSON_64C | PRID_REV_LOONGSON3B_R1), 1f
> > +     beq             s0, (PRID_IMP_LOONGSON_64C | PRID_REV_LOONGSON3B_R2), 1f
> > +     b               2f                 /* Loongson-3A1000/3A2000/3A3000/3A4000 */
> > +1:   dins            a0, t2, 14, 2      /* Loongson-3B1000/3B1500 need bit 15~14 */
> > +2:   li              t9, 0x100          /* wait for init loop */
> > +3:   addiu           t9, -1             /* limit mailbox access */
> > +     bnez            t9, 3b
> > +     lw              s1, 0x20(a0)       /* check PC as an indicator */
> > +     beqz            s1, 2b
> > +     ld              s1, 0x20(a0)       /* get PC via mailbox reg0 */
> > +     ld              sp, 0x28(a0)       /* get SP via mailbox reg1 */
> > +     ld              gp, 0x30(a0)       /* get GP via mailbox reg2 */
> > +     ld              a1, 0x38(a0)
> > +     jr              s1                 /* jump to initial PC */
> > +#endif
> > +
> >       j               s1
> >       END(kexec_smp_wait)
> >   #endif
> > diff --git a/arch/mips/loongson64/reset.c b/arch/mips/loongson64/reset.c
> > index 3bb8a1ed9348..c97bfdc8c922 100644
> > --- a/arch/mips/loongson64/reset.c
> > +++ b/arch/mips/loongson64/reset.c
> > @@ -6,9 +6,14 @@
> >    * Copyright (C) 2009 Lemote, Inc.
> >    * Author: Zhangjin Wu, wuzhangjin@gmail.com
> >    */
> > +#include <linux/cpu.h>
> > +#include <linux/delay.h>
> >   #include <linux/init.h>
> > +#include <linux/kexec.h>
> >   #include <linux/pm.h>
> > +#include <linux/slab.h>
> >
> > +#include <asm/bootinfo.h>
> >   #include <asm/idle.h>
> >   #include <asm/reboot.h>
> >
> > @@ -47,12 +52,120 @@ static void loongson_halt(void)
> >       }
> >   }
> >
> > +#ifdef CONFIG_KEXEC
> > +
> > +/* 0X80000000~0X80200000 is safe */
> > +#define MAX_ARGS     64
> > +#define KEXEC_CTRL_CODE      0xFFFFFFFF80100000UL
> > +#define KEXEC_ARGV_ADDR      0xFFFFFFFF80108000UL
> > +#define KEXEC_ARGV_SIZE      COMMAND_LINE_SIZE
> > +#define KEXEC_ENVP_SIZE      4800
> > +
> > +static int kexec_argc;
> > +static int kdump_argc;
> > +static void *kexec_argv;
> > +static void *kdump_argv;
> > +static void *kexec_envp;
> > +
> > +static int loongson_kexec_prepare(struct kimage *image)
> > +{
> > +     int i, argc = 0;
> > +     unsigned int *argv;
> > +     char *str, *ptr, *bootloader = "kexec";
> > +
> > +     /* argv at offset 0, argv[] at offset KEXEC_ARGV_SIZE/2 */
> > +     if (image->type == KEXEC_TYPE_DEFAULT)
> > +             argv = (unsigned int *)kexec_argv;
> > +     else
> > +             argv = (unsigned int *)kdump_argv;
> > +
> > +     argv[argc++] = (unsigned int)(KEXEC_ARGV_ADDR + KEXEC_ARGV_SIZE/2);
> > +
> > +     for (i = 0; i < image->nr_segments; i++) {
> > +             if (!strncmp(bootloader, (char *)image->segment[i].buf,
> > +                             strlen(bootloader))) {
> > +                     /*
> > +                      * convert command line string to array
> > +                      * of parameters (as bootloader does).
> > +                      */
> > +                     int offt;
> > +                     str = (char *)argv + KEXEC_ARGV_SIZE/2;
> > +                     memcpy(str, image->segment[i].buf, KEXEC_ARGV_SIZE/2);
> > +                     ptr = strchr(str, ' ');
> > +
> > +                     while (ptr && (argc < MAX_ARGS)) {
> > +                             *ptr = '\0';
> > +                             if (ptr[1] != ' ') {
> > +                                     offt = (int)(ptr - str + 1);
> > +                                     argv[argc] = KEXEC_ARGV_ADDR + KEXEC_ARGV_SIZE/2 + offt;
> > +                                     argc++;
> > +                             }
> > +                             ptr = strchr(ptr + 1, ' ');
> > +                     }
> > +                     break;
> > +             }
> > +     }
> > +
> > +     if (image->type == KEXEC_TYPE_DEFAULT)
> > +             kexec_argc = argc;
> > +     else
> > +             kdump_argc = argc;
> > +
> > +     /* kexec/kdump need a safe page to save reboot_code_buffer */
> > +     image->control_code_page = virt_to_page((void *)KEXEC_CTRL_CODE);
> > +
> > +     return 0;
> > +}
> > +
> > +static void loongson_kexec_shutdown(void)
> > +{
> > +#ifdef CONFIG_SMP
> > +     int cpu;
> > +
> > +     /* All CPUs go to reboot_code_buffer */
> > +     for_each_possible_cpu(cpu)
> > +             if (!cpu_online(cpu))
> > +                     cpu_device_up(get_cpu_device(cpu));
> > +#endif
> > +     kexec_args[0] = kexec_argc;
> > +     kexec_args[1] = fw_arg1;
> > +     kexec_args[2] = fw_arg2;
> > +     secondary_kexec_args[0] = TO_UNCAC(0x3ff01000);
> > +     memcpy((void *)fw_arg1, kexec_argv, KEXEC_ARGV_SIZE);
> > +     memcpy((void *)fw_arg2, kexec_envp, KEXEC_ENVP_SIZE);
> > +}
> > +
> > +static void loongson_crash_shutdown(struct pt_regs *regs)
> > +{
> > +     default_machine_crash_shutdown(regs);
> > +     kexec_args[0] = kdump_argc;
> > +     kexec_args[1] = fw_arg1;
> > +     kexec_args[2] = fw_arg2;
> > +     secondary_kexec_args[0] = TO_UNCAC(0x3ff01000);
> > +     memcpy((void *)fw_arg1, kdump_argv, KEXEC_ARGV_SIZE);
> > +     memcpy((void *)fw_arg2, kexec_envp, KEXEC_ENVP_SIZE);
> > +}
> > +
> > +#endif
> > +
> >   static int __init mips_reboot_setup(void)
> >   {
> >       _machine_restart = loongson_restart;
> >       _machine_halt = loongson_halt;
> >       pm_power_off = loongson_poweroff;
> >
> > +#ifdef CONFIG_KEXEC
> > +     kexec_argv = kmalloc(KEXEC_ARGV_SIZE, GFP_KERNEL);
> > +     kdump_argv = kmalloc(KEXEC_ARGV_SIZE, GFP_KERNEL);
> > +     kexec_envp = kmalloc(KEXEC_ENVP_SIZE, GFP_KERNEL);
> > +     fw_arg1 = KEXEC_ARGV_ADDR;
> > +     memcpy(kexec_envp, (void *)fw_arg2, KEXEC_ENVP_SIZE);
> > +
> > +     _machine_kexec_prepare = loongson_kexec_prepare;
> > +     _machine_kexec_shutdown = loongson_kexec_shutdown;
> > +     _machine_crash_shutdown = loongson_crash_shutdown;
> > +#endif
> > +
> >       return 0;
> >   }
> >
>

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

[Huacai Chen]

Hi, Thomas,

On Tue, Dec 22, 2020 at 2:41 PM Jinyang He <hejinyang@loongson.cn> wrote:
>
> On 12/21/2020 08:02 PM, Huacai Chen wrote:
>
> > From: Huacai Chen <chenhc@lemote.com>
> >
> > Add kexec/kdump support for Loongson64 by:
> > 1, Provide Loongson-specific kexec functions: loongson_kexec_prepare(),
> >     loongson_kexec_shutdown() and loongson_crash_shutdown();
> > 2, Provide Loongson-specific assembly code in kexec_smp_wait();
> >
> > To start Loongson64, The boot CPU needs 3 parameters:
> > fw_arg0: the number of arguments in cmdline (i.e., argc).
> > fw_arg1: structure holds cmdline such as "root=/dev/sda1 console=tty"
> >           (i.e., argv).
> > fw_arg2: environment (i.e., envp, additional boot parameters from LEFI).
> >
> > Non-boot CPUs do not need one parameter as the IPI mailbox base address.
> > They query their own IPI mailbox to get PC, SP and GP in a loopi, until
> > the boot CPU brings them up.
> >
> > loongson_kexec_prepare(): Setup cmdline for kexec/kdump. The kexec/kdump
> > cmdline comes from kexec's "append" option string. This structure will
> > be parsed in fw_init_cmdline() of arch/mips/fw/lib/cmdline.c. Both image
> > ->control_code_page and the cmdline need to be in a safe memory region
> > (memory allocated by the old kernel may be corrupted by the new kernel).
> > In order to maintain compatibility for the old firmware, the low 2MB is
> > reserverd and safe for Loongson. So let KEXEC_CTRL_CODE and KEXEC_ARGV_
> > ADDR be here. LEFI parameters may be corrupted at runtime, so backup it
> > at mips_reboot_setup(), and then restore it at loongson_kexec_shutdown()
> > /loongson_crash_shutdown().
> >
> > loongson_kexec_shutdown(): Wake up all present CPUs and let them go to
> > reboot_code_buffer. Pass the kexec parameters to kexec_args.
> >
> > loongson_crash_shutdown(): Pass the kdump parameters to kexec_args.
> >
> > The assembly part in kexec_smp_wait provide a routine as BIOS does, in
> > order to keep secondary CPUs in a querying loop.
> >
> > The layout of low 2MB memory in our design:
> > 0x80000000, the first MB, the first 64K, Exception vectors
> > 0x80010000, the first MB, the second 64K, STR (suspend) data
> > 0x80020000, the first MB, the third and fourth 64K, UEFI HOB
> > 0x80040000, the first MB, the fifth 64K, RT-Thread for SMC
> > 0x80100000, the second MB, the first 64K, KEXEC code
> > 0x80108000, the second MB, the second 64K, KEXEC data
> >
> > Cc: Eric Biederman <ebiederm@xmission.com>
> > Signed-off-by: Huacai Chen <chenhuacai@kernel.org>
> > Signed-off-by: Jinyang He <hejinyang@loongson.cn>
> > Signed-off-by: Youling Tang <tangyouling@loongson.cn>
> > ---
> >   V3: Some minor improvements suggested by Jinyang He.
> >
> >   arch/mips/kernel/relocate_kernel.S |  28 +++++++
> >   arch/mips/loongson64/reset.c       | 113 +++++++++++++++++++++++++++++
> >   2 files changed, 141 insertions(+)
> kexec-tools v2.0.21
> 3A3000/7A1000 3A4000/7A1000
>
> Test kexec:
>
> # kexec -l vmlinux --append="<cmdline>"
> # kexec -e
>
> Result: OK!
>
> Test kdump: We need a capture kernel to dump the panic kernel.
> To build the capture kernel:
> make loongson3_defconfig and set CONFIG_PROC_VMCORE=y , CONFIG_CRASH_DUMP=y
> and CONFIG_PHYSICAL_START=0xffffffff84000000
>
> # kexec -p vmlinux(capture) --append="<cmdline>"
> # echo c > /proc/sysrq-trigger
>
> Result: OK!
>
> Tested-by: Jinyang He <hejinyang@loongson.cn>
>
> Thanks, :-)
> Jinyang
Any comments?

Huacai
>
> > diff --git a/arch/mips/kernel/relocate_kernel.S b/arch/mips/kernel/relocate_kernel.S
> > index ac870893ba2d..f649ffa0f427 100644
> > --- 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
> > +     /* s0:prid s1:initfn */
> > +     /* a0:base t1:cpuid t2:node t9:count */
> > +     mfc0            t1, CP0_EBASE
> > +     andi            t1, MIPS_EBASE_CPUNUM
> > +     dins            a0, t1, 8, 2       /* insert core id*/
> > +     dext            t2, t1, 2, 2
> > +     dins            a0, t2, 44, 2      /* insert node id */
> > +     mfc0            s0, CP0_PRID
> > +     andi            s0, s0, (PRID_IMP_MASK | PRID_REV_MASK)
> > +     beq             s0, (PRID_IMP_LOONGSON_64C | PRID_REV_LOONGSON3B_R1), 1f
> > +     beq             s0, (PRID_IMP_LOONGSON_64C | PRID_REV_LOONGSON3B_R2), 1f
> > +     b               2f                 /* Loongson-3A1000/3A2000/3A3000/3A4000 */
> > +1:   dins            a0, t2, 14, 2      /* Loongson-3B1000/3B1500 need bit 15~14 */
> > +2:   li              t9, 0x100          /* wait for init loop */
> > +3:   addiu           t9, -1             /* limit mailbox access */
> > +     bnez            t9, 3b
> > +     lw              s1, 0x20(a0)       /* check PC as an indicator */
> > +     beqz            s1, 2b
> > +     ld              s1, 0x20(a0)       /* get PC via mailbox reg0 */
> > +     ld              sp, 0x28(a0)       /* get SP via mailbox reg1 */
> > +     ld              gp, 0x30(a0)       /* get GP via mailbox reg2 */
> > +     ld              a1, 0x38(a0)
> > +     jr              s1                 /* jump to initial PC */
> > +#endif
> > +
> >       j               s1
> >       END(kexec_smp_wait)
> >   #endif
> > diff --git a/arch/mips/loongson64/reset.c b/arch/mips/loongson64/reset.c
> > index 3bb8a1ed9348..c97bfdc8c922 100644
> > --- a/arch/mips/loongson64/reset.c
> > +++ b/arch/mips/loongson64/reset.c
> > @@ -6,9 +6,14 @@
> >    * Copyright (C) 2009 Lemote, Inc.
> >    * Author: Zhangjin Wu, wuzhangjin@gmail.com
> >    */
> > +#include <linux/cpu.h>
> > +#include <linux/delay.h>
> >   #include <linux/init.h>
> > +#include <linux/kexec.h>
> >   #include <linux/pm.h>
> > +#include <linux/slab.h>
> >
> > +#include <asm/bootinfo.h>
> >   #include <asm/idle.h>
> >   #include <asm/reboot.h>
> >
> > @@ -47,12 +52,120 @@ static void loongson_halt(void)
> >       }
> >   }
> >
> > +#ifdef CONFIG_KEXEC
> > +
> > +/* 0X80000000~0X80200000 is safe */
> > +#define MAX_ARGS     64
> > +#define KEXEC_CTRL_CODE      0xFFFFFFFF80100000UL
> > +#define KEXEC_ARGV_ADDR      0xFFFFFFFF80108000UL
> > +#define KEXEC_ARGV_SIZE      COMMAND_LINE_SIZE
> > +#define KEXEC_ENVP_SIZE      4800
> > +
> > +static int kexec_argc;
> > +static int kdump_argc;
> > +static void *kexec_argv;
> > +static void *kdump_argv;
> > +static void *kexec_envp;
> > +
> > +static int loongson_kexec_prepare(struct kimage *image)
> > +{
> > +     int i, argc = 0;
> > +     unsigned int *argv;
> > +     char *str, *ptr, *bootloader = "kexec";
> > +
> > +     /* argv at offset 0, argv[] at offset KEXEC_ARGV_SIZE/2 */
> > +     if (image->type == KEXEC_TYPE_DEFAULT)
> > +             argv = (unsigned int *)kexec_argv;
> > +     else
> > +             argv = (unsigned int *)kdump_argv;
> > +
> > +     argv[argc++] = (unsigned int)(KEXEC_ARGV_ADDR + KEXEC_ARGV_SIZE/2);
> > +
> > +     for (i = 0; i < image->nr_segments; i++) {
> > +             if (!strncmp(bootloader, (char *)image->segment[i].buf,
> > +                             strlen(bootloader))) {
> > +                     /*
> > +                      * convert command line string to array
> > +                      * of parameters (as bootloader does).
> > +                      */
> > +                     int offt;
> > +                     str = (char *)argv + KEXEC_ARGV_SIZE/2;
> > +                     memcpy(str, image->segment[i].buf, KEXEC_ARGV_SIZE/2);
> > +                     ptr = strchr(str, ' ');
> > +
> > +                     while (ptr && (argc < MAX_ARGS)) {
> > +                             *ptr = '\0';
> > +                             if (ptr[1] != ' ') {
> > +                                     offt = (int)(ptr - str + 1);
> > +                                     argv[argc] = KEXEC_ARGV_ADDR + KEXEC_ARGV_SIZE/2 + offt;
> > +                                     argc++;
> > +                             }
> > +                             ptr = strchr(ptr + 1, ' ');
> > +                     }
> > +                     break;
> > +             }
> > +     }
> > +
> > +     if (image->type == KEXEC_TYPE_DEFAULT)
> > +             kexec_argc = argc;
> > +     else
> > +             kdump_argc = argc;
> > +
> > +     /* kexec/kdump need a safe page to save reboot_code_buffer */
> > +     image->control_code_page = virt_to_page((void *)KEXEC_CTRL_CODE);
> > +
> > +     return 0;
> > +}
> > +
> > +static void loongson_kexec_shutdown(void)
> > +{
> > +#ifdef CONFIG_SMP
> > +     int cpu;
> > +
> > +     /* All CPUs go to reboot_code_buffer */
> > +     for_each_possible_cpu(cpu)
> > +             if (!cpu_online(cpu))
> > +                     cpu_device_up(get_cpu_device(cpu));
> > +#endif
> > +     kexec_args[0] = kexec_argc;
> > +     kexec_args[1] = fw_arg1;
> > +     kexec_args[2] = fw_arg2;
> > +     secondary_kexec_args[0] = TO_UNCAC(0x3ff01000);
> > +     memcpy((void *)fw_arg1, kexec_argv, KEXEC_ARGV_SIZE);
> > +     memcpy((void *)fw_arg2, kexec_envp, KEXEC_ENVP_SIZE);
> > +}
> > +
> > +static void loongson_crash_shutdown(struct pt_regs *regs)
> > +{
> > +     default_machine_crash_shutdown(regs);
> > +     kexec_args[0] = kdump_argc;
> > +     kexec_args[1] = fw_arg1;
> > +     kexec_args[2] = fw_arg2;
> > +     secondary_kexec_args[0] = TO_UNCAC(0x3ff01000);
> > +     memcpy((void *)fw_arg1, kdump_argv, KEXEC_ARGV_SIZE);
> > +     memcpy((void *)fw_arg2, kexec_envp, KEXEC_ENVP_SIZE);
> > +}
> > +
> > +#endif
> > +
> >   static int __init mips_reboot_setup(void)
> >   {
> >       _machine_restart = loongson_restart;
> >       _machine_halt = loongson_halt;
> >       pm_power_off = loongson_poweroff;
> >
> > +#ifdef CONFIG_KEXEC
> > +     kexec_argv = kmalloc(KEXEC_ARGV_SIZE, GFP_KERNEL);
> > +     kdump_argv = kmalloc(KEXEC_ARGV_SIZE, GFP_KERNEL);
> > +     kexec_envp = kmalloc(KEXEC_ENVP_SIZE, GFP_KERNEL);
> > +     fw_arg1 = KEXEC_ARGV_ADDR;
> > +     memcpy(kexec_envp, (void *)fw_arg2, KEXEC_ENVP_SIZE);
> > +
> > +     _machine_kexec_prepare = loongson_kexec_prepare;
> > +     _machine_kexec_shutdown = loongson_kexec_shutdown;
> > +     _machine_crash_shutdown = loongson_crash_shutdown;
> > +#endif
> > +
> >       return 0;
> >   }
> >
>

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

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

[Thomas Bogendoerfer]

On Thu, Dec 31, 2020 at 09:23:33AM +0800, Huacai Chen wrote:
> > Thanks, :-)
> > Jinyang
> Any comments?

sure...

> > > --- 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.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

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

[Thomas Bogendoerfer]

On Thu, Dec 31, 2020 at 09:23:33AM +0800, Huacai Chen wrote:
> > Thanks, :-)
> > Jinyang
> Any comments?

sure...

> > > --- 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.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

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

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

[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.

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...

Above all just my personal thoughts.

Thanks,
Jinyang

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

[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.

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...

Above all just my personal thoughts.

Thanks,
Jinyang


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

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

[Jiaxun Yang]

在 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.

- Jiaxun

>
> Above all just my personal thoughts.
>
> Thanks,
> Jinyang
>

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

[Jiaxun Yang]

在 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.

- Jiaxun

>
> Above all just my personal thoughts.
>
> Thanks,
> Jinyang
>


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

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

[Huacai Chen]

Hi, Jiaxun,

On Fri, Jan 8, 2021 at 6:15 PM Jiaxun Yang <jiaxun.yang@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.

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

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

[Huacai Chen]

Hi, Jiaxun,

On Fri, Jan 8, 2021 at 6:15 PM Jiaxun Yang <jiaxun.yang@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.

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

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

Re: [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@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
>>>

Re: [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@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
>>>


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

Re: [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@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@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
> >>>
>

Re: [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@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@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
> >>>
>

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

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

[Thomas Bogendoerfer]

On Fri, Jan 08, 2021 at 06:07:39PM +0800, Jinyang He wrote:
> 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.
> 
> 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...
> 
> Above all just my personal thoughts.

thank you for describing current state. So it looks like kexec and SMP
is probably only working for Octeon and maybe some MIPS VPE based SMP
systems, but not with "real" cores.

How about the patch below as preparation for your loongson64 kexec patch ?
You only need to put write a kexec_smp_wait_final macro and the rest of
your patch stays the same...

Thomas.


From 81d3e1e24a0dae48f310b8d819d625f88139ef9b Mon Sep 17 00:00:00 2001
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Date: Tue, 19 Jan 2021 21:58:55 +0100
Subject: [PATCH] MIPS: Use macro for kexec_smp_wait specials

Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
---
 .../include/asm/mach-cavium-octeon/kernel-entry-init.h   | 8 ++++++++
 arch/mips/kernel/relocate_kernel.S                       | 9 ++++-----
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h b/arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h
index c38b38ce5a3d..b071a7353ee1 100644
--- a/arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h
+++ b/arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h
@@ -157,4 +157,12 @@
 	.macro	smp_slave_setup
 	.endm
 
+#define USE_KEXEC_SMP_WAIT_FINAL
+	.macro  kexec_smp_wait_final
+	.set push
+	.set noreorder
+	synci		0($0)
+	.set pop
+	.endm
+
 #endif /* __ASM_MACH_CAVIUM_OCTEON_KERNEL_ENTRY_H */
diff --git a/arch/mips/kernel/relocate_kernel.S b/arch/mips/kernel/relocate_kernel.S
index ac870893ba2d..f3c908abdbb8 100644
--- a/arch/mips/kernel/relocate_kernel.S
+++ b/arch/mips/kernel/relocate_kernel.S
@@ -11,6 +11,8 @@
 #include <asm/stackframe.h>
 #include <asm/addrspace.h>
 
+#include <kernel-entry-init.h>
+
 LEAF(relocate_new_kernel)
 	PTR_L a0,	arg0
 	PTR_L a1,	arg1
@@ -125,11 +127,8 @@ LEAF(kexec_smp_wait)
 1:	LONG_L		s0, (t0)
 	bne		s0, zero,1b
 
-#ifdef CONFIG_CPU_CAVIUM_OCTEON
-	.set push
-	.set noreorder
-	synci		0($0)
-	.set pop
+#ifdef USE_KEXEC_SMP_WAIT_FINAL
+	kexec_smp_wait_final
 #else
 	sync
 #endif
-- 
2.29.2


-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

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

[Thomas Bogendoerfer]

On Fri, Jan 08, 2021 at 06:07:39PM +0800, Jinyang He wrote:
> 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.
> 
> 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...
> 
> Above all just my personal thoughts.

thank you for describing current state. So it looks like kexec and SMP
is probably only working for Octeon and maybe some MIPS VPE based SMP
systems, but not with "real" cores.

How about the patch below as preparation for your loongson64 kexec patch ?
You only need to put write a kexec_smp_wait_final macro and the rest of
your patch stays the same...

Thomas.


From 81d3e1e24a0dae48f310b8d819d625f88139ef9b Mon Sep 17 00:00:00 2001
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Date: Tue, 19 Jan 2021 21:58:55 +0100
Subject: [PATCH] MIPS: Use macro for kexec_smp_wait specials

Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
---
 .../include/asm/mach-cavium-octeon/kernel-entry-init.h   | 8 ++++++++
 arch/mips/kernel/relocate_kernel.S                       | 9 ++++-----
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h b/arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h
index c38b38ce5a3d..b071a7353ee1 100644
--- a/arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h
+++ b/arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h
@@ -157,4 +157,12 @@
 	.macro	smp_slave_setup
 	.endm
 
+#define USE_KEXEC_SMP_WAIT_FINAL
+	.macro  kexec_smp_wait_final
+	.set push
+	.set noreorder
+	synci		0($0)
+	.set pop
+	.endm
+
 #endif /* __ASM_MACH_CAVIUM_OCTEON_KERNEL_ENTRY_H */
diff --git a/arch/mips/kernel/relocate_kernel.S b/arch/mips/kernel/relocate_kernel.S
index ac870893ba2d..f3c908abdbb8 100644
--- a/arch/mips/kernel/relocate_kernel.S
+++ b/arch/mips/kernel/relocate_kernel.S
@@ -11,6 +11,8 @@
 #include <asm/stackframe.h>
 #include <asm/addrspace.h>
 
+#include <kernel-entry-init.h>
+
 LEAF(relocate_new_kernel)
 	PTR_L a0,	arg0
 	PTR_L a1,	arg1
@@ -125,11 +127,8 @@ LEAF(kexec_smp_wait)
 1:	LONG_L		s0, (t0)
 	bne		s0, zero,1b
 
-#ifdef CONFIG_CPU_CAVIUM_OCTEON
-	.set push
-	.set noreorder
-	synci		0($0)
-	.set pop
+#ifdef USE_KEXEC_SMP_WAIT_FINAL
+	kexec_smp_wait_final
 #else
 	sync
 #endif
-- 
2.29.2


-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

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

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

[Jinyang He]

On 01/20/2021 05:08 AM, Thomas Bogendoerfer wrote:

> On Fri, Jan 08, 2021 at 06:07:39PM +0800, Jinyang He wrote:
>> 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.
>>
>> 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...
>>
>> Above all just my personal thoughts.
> thank you for describing current state. So it looks like kexec and SMP
> is probably only working for Octeon and maybe some MIPS VPE based SMP
> systems, but not with "real" cores.
>
> How about the patch below as preparation for your loongson64 kexec patch ?
> You only need to put write a kexec_smp_wait_final macro and the rest of
> your patch stays the same...
>
> Thomas.

Thank you for this patch. By applying your patch and the revised Huacai's
patch, kexec works well on the Loongson-3A4000. I compared the assembly
code, too. It's the same as the previous patch doing. I think it's correct.
Huacai, how do you think about it?

Thanks, :-)
Jinyang
>
>  From 81d3e1e24a0dae48f310b8d819d625f88139ef9b Mon Sep 17 00:00:00 2001
> From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Date: Tue, 19 Jan 2021 21:58:55 +0100
> Subject: [PATCH] MIPS: Use macro for kexec_smp_wait specials
>
> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> ---
>   .../include/asm/mach-cavium-octeon/kernel-entry-init.h   | 8 ++++++++
>   arch/mips/kernel/relocate_kernel.S                       | 9 ++++-----
>   2 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h b/arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h
> index c38b38ce5a3d..b071a7353ee1 100644
> --- a/arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h
> +++ b/arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h
> @@ -157,4 +157,12 @@
>   	.macro	smp_slave_setup
>   	.endm
>   
> +#define USE_KEXEC_SMP_WAIT_FINAL
> +	.macro  kexec_smp_wait_final
> +	.set push
> +	.set noreorder
> +	synci		0($0)
> +	.set pop
> +	.endm
> +
>   #endif /* __ASM_MACH_CAVIUM_OCTEON_KERNEL_ENTRY_H */
> diff --git a/arch/mips/kernel/relocate_kernel.S b/arch/mips/kernel/relocate_kernel.S
> index ac870893ba2d..f3c908abdbb8 100644
> --- a/arch/mips/kernel/relocate_kernel.S
> +++ b/arch/mips/kernel/relocate_kernel.S
> @@ -11,6 +11,8 @@
>   #include <asm/stackframe.h>
>   #include <asm/addrspace.h>
>   
> +#include <kernel-entry-init.h>
> +
>   LEAF(relocate_new_kernel)
>   	PTR_L a0,	arg0
>   	PTR_L a1,	arg1
> @@ -125,11 +127,8 @@ LEAF(kexec_smp_wait)
>   1:	LONG_L		s0, (t0)
>   	bne		s0, zero,1b
>   
> -#ifdef CONFIG_CPU_CAVIUM_OCTEON
> -	.set push
> -	.set noreorder
> -	synci		0($0)
> -	.set pop
> +#ifdef USE_KEXEC_SMP_WAIT_FINAL
> +	kexec_smp_wait_final
>   #else
>   	sync
>   #endif

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

[Jinyang He]

On 01/20/2021 05:08 AM, Thomas Bogendoerfer wrote:

> On Fri, Jan 08, 2021 at 06:07:39PM +0800, Jinyang He wrote:
>> 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.
>>
>> 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...
>>
>> Above all just my personal thoughts.
> thank you for describing current state. So it looks like kexec and SMP
> is probably only working for Octeon and maybe some MIPS VPE based SMP
> systems, but not with "real" cores.
>
> How about the patch below as preparation for your loongson64 kexec patch ?
> You only need to put write a kexec_smp_wait_final macro and the rest of
> your patch stays the same...
>
> Thomas.

Thank you for this patch. By applying your patch and the revised Huacai's
patch, kexec works well on the Loongson-3A4000. I compared the assembly
code, too. It's the same as the previous patch doing. I think it's correct.
Huacai, how do you think about it?

Thanks, :-)
Jinyang
>
>  From 81d3e1e24a0dae48f310b8d819d625f88139ef9b Mon Sep 17 00:00:00 2001
> From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Date: Tue, 19 Jan 2021 21:58:55 +0100
> Subject: [PATCH] MIPS: Use macro for kexec_smp_wait specials
>
> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> ---
>   .../include/asm/mach-cavium-octeon/kernel-entry-init.h   | 8 ++++++++
>   arch/mips/kernel/relocate_kernel.S                       | 9 ++++-----
>   2 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h b/arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h
> index c38b38ce5a3d..b071a7353ee1 100644
> --- a/arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h
> +++ b/arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h
> @@ -157,4 +157,12 @@
>   	.macro	smp_slave_setup
>   	.endm
>   
> +#define USE_KEXEC_SMP_WAIT_FINAL
> +	.macro  kexec_smp_wait_final
> +	.set push
> +	.set noreorder
> +	synci		0($0)
> +	.set pop
> +	.endm
> +
>   #endif /* __ASM_MACH_CAVIUM_OCTEON_KERNEL_ENTRY_H */
> diff --git a/arch/mips/kernel/relocate_kernel.S b/arch/mips/kernel/relocate_kernel.S
> index ac870893ba2d..f3c908abdbb8 100644
> --- a/arch/mips/kernel/relocate_kernel.S
> +++ b/arch/mips/kernel/relocate_kernel.S
> @@ -11,6 +11,8 @@
>   #include <asm/stackframe.h>
>   #include <asm/addrspace.h>
>   
> +#include <kernel-entry-init.h>
> +
>   LEAF(relocate_new_kernel)
>   	PTR_L a0,	arg0
>   	PTR_L a1,	arg1
> @@ -125,11 +127,8 @@ LEAF(kexec_smp_wait)
>   1:	LONG_L		s0, (t0)
>   	bne		s0, zero,1b
>   
> -#ifdef CONFIG_CPU_CAVIUM_OCTEON
> -	.set push
> -	.set noreorder
> -	synci		0($0)
> -	.set pop
> +#ifdef USE_KEXEC_SMP_WAIT_FINAL
> +	kexec_smp_wait_final
>   #else
>   	sync
>   #endif


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