From: Jiaxun Yang <jiaxun.yang@flygoat.com> To: Jinyang He <hejinyang@loongson.cn>, Thomas Bogendoerfer <tsbogend@alpha.franken.de>, Huacai Chen <chenhuacai@kernel.org> Cc: Eric Biederman <ebiederm@xmission.com>, Dave Young <dyoung@redhat.com>, Baoquan He <bhe@redhat.com>, Vivek Goyal <vgoyal@redhat.com>, "open list:MIPS" <linux-mips@vger.kernel.org>, kexec@lists.infradead.org, Youling Tang <tangyouling@loongson.cn> Subject: Re: [PATCH V3] MIPS: Loongson64: Add kexec/kdump support Date: Fri, 8 Jan 2021 18:15:44 +0800 [thread overview] Message-ID: <13b3f842-61e8-db13-67ff-7d2a9d894484@flygoat.com> (raw) In-Reply-To: <1085845b-2c5a-dbb6-62b7-28b55aeacb4c@loongson.cn> 在 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 >
WARNING: multiple messages have this Message-ID (diff)
From: Jiaxun Yang <jiaxun.yang@flygoat.com> To: Jinyang He <hejinyang@loongson.cn>, Thomas Bogendoerfer <tsbogend@alpha.franken.de>, Huacai Chen <chenhuacai@kernel.org> Cc: Baoquan He <bhe@redhat.com>, Youling Tang <tangyouling@loongson.cn>, kexec@lists.infradead.org, "open list:MIPS" <linux-mips@vger.kernel.org>, Eric Biederman <ebiederm@xmission.com>, Dave Young <dyoung@redhat.com>, Vivek Goyal <vgoyal@redhat.com> Subject: Re: [PATCH V3] MIPS: Loongson64: Add kexec/kdump support Date: Fri, 8 Jan 2021 18:15:44 +0800 [thread overview] Message-ID: <13b3f842-61e8-db13-67ff-7d2a9d894484@flygoat.com> (raw) In-Reply-To: <1085845b-2c5a-dbb6-62b7-28b55aeacb4c@loongson.cn> 在 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
next prev parent reply other threads:[~2021-01-08 10:16 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-21 12:02 [PATCH V3] MIPS: Loongson64: Add kexec/kdump support Huacai Chen 2020-12-21 12:02 ` Huacai Chen 2020-12-22 6:41 ` Jinyang He 2020-12-22 6:41 ` Jinyang He 2020-12-31 1:23 ` Huacai Chen 2020-12-31 1:23 ` Huacai Chen 2021-01-07 17:26 ` Thomas Bogendoerfer 2021-01-07 17:26 ` Thomas Bogendoerfer 2021-01-08 10:07 ` Jinyang He 2021-01-08 10:07 ` Jinyang He 2021-01-08 10:15 ` Jiaxun Yang [this message] 2021-01-08 10:15 ` Jiaxun Yang 2021-01-09 1:36 ` Huacai Chen 2021-01-09 1:36 ` Huacai Chen 2021-01-09 7:38 ` Jiaxun Yang 2021-01-09 7:38 ` Jiaxun Yang 2021-01-17 4:24 ` Huacai Chen 2021-01-17 4:24 ` Huacai Chen 2021-01-19 21:08 ` Thomas Bogendoerfer 2021-01-19 21:08 ` Thomas Bogendoerfer 2021-01-20 1:49 ` Jinyang He 2021-01-20 1:49 ` Jinyang He
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=13b3f842-61e8-db13-67ff-7d2a9d894484@flygoat.com \ --to=jiaxun.yang@flygoat.com \ --cc=bhe@redhat.com \ --cc=chenhuacai@kernel.org \ --cc=dyoung@redhat.com \ --cc=ebiederm@xmission.com \ --cc=hejinyang@loongson.cn \ --cc=kexec@lists.infradead.org \ --cc=linux-mips@vger.kernel.org \ --cc=tangyouling@loongson.cn \ --cc=tsbogend@alpha.franken.de \ --cc=vgoyal@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.