lkml.org 
[lkml]   [2020]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] MIPS: Loongson64: Add kexec/kdump support
From
Date
On 09/17/2020 10:21 PM, Jiaxun Yang wrote:
>
>
> 在 2020/9/17 20:41, Jinyang He 写道:
>> Hi, Huacai,
>>
>>
>> On 09/16/2020 01:39 PM, Huacai Chen wrote:
>>> Hi, Jinyang,
>>>
>>> On Tue, Sep 15, 2020 at 10:17 PM Jinyang He <hejinyang@loongson.cn>
>>> wrote:
>>>>
>>>>
>>>> On 09/16/2020 09:33 AM, Jiaxun Yang wrote:
>>>>> 于 2020年9月15日 GMT+08:00 下午9:07:43, Jinyang He
>>>>> <hejinyang@loongson.cn> 写到:
>>>>>> Add loongson_kexec_prepare(), loongson_kexec_shutdown() and
>>>>>> loongson_kexec_crashdown() for passing the parameters of kexec_args.
>>>>>>
>>>>>> To start loongson64, CPU0 needs 3 parameters:
>>>>>> fw_arg0: the number of cmd.
>>>>>> fw_arg1: cmd structure which seems strange, the cmd array[index]'s
>>>>>> value is cmd string's address, index >= 1.
>>>>>> fw_arg2: environment.
>>>>>>
>>>>>> Secondary CPUs do not need parameter at once. They query their
>>>>>> mailbox to get PC, SP and GP in a loop before CPU0 brings them up
>>>>>> and passes these parameters via mailbox.
>>>>>>
>>>>>> loongson_kexec_prepare(): Alloc new memory to save cmd for kexec.
>>>>>> Combine the kexec append option string as cmd structure, and the cmd
>>>>>> struct will be parsed in fw_init_cmdline() of
>>>>>> arch/mips/fw/lib/cmdline.c.
>>>>>> image->control_code_page need pointing to a safe memory page. In
>>>>>> order to
>>>>>> maintain compatibility for the old firmware the low 2MB is reserverd
>>>>>> and safe for Loongson. So let it points here.
>>>>>>
>>>>>> 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 provide a way like BIOS doing to keep secondary
>>>>>> CPUs in a querying loop.
>>>>>>
>>>>>> This patch referenced [1][2][3].
>>>>>>
>>>>>> [1] arch/mips/cavium-octeon/setup.c
>>>>>> [2] https://patchwork.kernel.org/patch/10799217/
>>>>>> [3]
>>>>>> https://gitee.com/loongsonlab/qemu/blob/master/hw/mips/loongson3a_rom.h
>>>>>>
>>>>>>
>>>>>> Co-developed-by: Youling Tang <tangyouling@loongson.cn>
>>>>>> Signed-off-by: Youling Tang <tangyouling@loongson.cn>
>>>>>> Signed-off-by: Jinyang He <hejinyang@loongson.cn>
>>>>>> ---
>>>>>> arch/mips/kernel/relocate_kernel.S | 19 ++++++++
>>>>>> arch/mips/loongson64/reset.c | 88
>>>>>> ++++++++++++++++++++++++++++++++++++++
>>>>>> 2 files changed, 107 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/mips/kernel/relocate_kernel.S
>>>>>> b/arch/mips/kernel/relocate_kernel.S
>>>>>> index ac87089..061cbfb 100644
>>>>>> --- a/arch/mips/kernel/relocate_kernel.S
>>>>>> +++ b/arch/mips/kernel/relocate_kernel.S
>>>>>> @@ -133,6 +133,25 @@ LEAF(kexec_smp_wait)
>>>>>> #else
>>>>>> sync
>>>>>> #endif
>>>>>> +
>>>>>> +#ifdef CONFIG_CPU_LOONGSON64
>>>>>> +#define MAILBOX_BASE 0x900000003ff01000
>>>>> Please avoid hardcoded SMP information. You're breaking Loongson
>>>>> 3B support.
>>>>>
>>>> Ok, I see. Since my machine is Loongson 3A. I'll send v2
>>>> after I test it in 3B.
>>> 1, My original version can work on both Loongson-3A and Loongson-3B,
>>> why you modify my patch and hadn't discuss with me?
>>>
>>> 2, With this single patch both kexec and kdump cannot work reliably,
>>> because kexec need this patch:
>>> https://patchwork.kernel.org/patch/11695929/
>>>
>>> and kdump need my first patch in my original version:
>>> https://patchwork.kernel.org/patch/10799215/
>>>
>>> You may argue that you have tested. Yes, I believe that, I'm not
>>> saying that you haven't test, and I'm not saying that your patch
>>> cannot work, I'm just saying that your patch is not robust.
>>>
>>> 3, I'm the original author and paying attention to kexec/kdump
>>> continuosly, I will send a new version once the above two patches be
>>> accepted. But you re-send my patch without any communication with me,
>>> why you so impatient?
>>>
>>> Huacai
>>>
>>
>> 1, Your original version:
>> https://patchwork.kernel.org/patch/10799217/
>>
>> This patch can work on Loongson-3A, I tested it.
>>
>> But it works wrong after the follow behaviors,
>> kexec -l vmlinux --append=cmdline_kexec
>> kexec -p vmlinux --append=cmdline_kdump
>> kexec -e
>>
>> It works but cmdline_kdump merged cmdline_kexec.
>>
>> And this patch memcpy from fw_arg2 to kexec_envp and later memcpy from
>> kexec_envp to fw_arg2 when fw_arg2 was not changed, it's redundant.
>>
>> However, I have not Loongson-3B now, and did not test it. For this
>> patch,
>> does it work well on Loongson-3B3000/Loongson-3B4000?
>
> Hi Jingyang,
>
> Well for Loongson-3B I meant 3B1000/3B1500, which have different layout
> of SMP registers. For 3B3000/3B4000 everyone know they're just different
> branding to the same silicon.

OK, I see. Thank you.

>>
>> 3, I try to fix Loongson64 kexec function since I joined the community.
>> I fell sorry to not do enough research on Loongson64 kexec. My first
>> patch:
>> https://patchwork.kernel.org/patch/11684849/
>
> I'm glad to see Loongson staff joining the community and enhance our
> code.
> It is common practice to investigate historical changes before do
> something
> to the upstream code :-)
>
>>
>> It fixed problem about "Crash kernel" which can be traced back to
>> linux-5.4.
>> At that time, I thought there is no developer work on Kexec. Thus, I
>> did a
>> lot on Kexec. Are you really continuosly paying attention to
>> kexec/kdump?
>> With the exploring and developing deep, I found your patch several
>> days ago
>> after I did a draft patch witch referenced:
>> arch/mips/cavium-octeon/setup.c
>> https://gitee.com/loongsonlab/qemu/blob/master/hw/mips/loongson3a_rom.h
>>
>> There is no doubt that your patch gives me confidence and suggestion
>> while
>> it gives me worry. As a newcomer, I do not know if should communicate
>> with
>> you since your patch was committed one year ago. And now it may be a
>> good
>> chance to do some communication.
>
> You should *always* try to *credit* others properly, that's the first
> thing.
> Communication is optional but highly recommanded.
>
> Recently I can smell there are some tensions raised between the
> community and
> the Loongson company, mainly about GPL violation and Loongson's attitude
> towards the community. Personaly I don't hold any hostility to Loongosn's
> practice in the community but I'd also like to see Loongson show their
> respect
> to the community.

I have replied to Yanjie:
https://lore.kernel.org/patchwork/patch/1306401/#1502870

>
> Thanks.
>
> - Jiaxun
>
>>
>> Thanks,
>>
>> - Jinyang.
>>

\
 
 \ /
  Last update: 2020-09-18 08:21    [W:0.182 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site