Message ID | 20221019103623.7008-2-xianting.tian@linux.alibaba.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp264704wrs; Wed, 19 Oct 2022 04:20:45 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5p6j9L0Zhbkn3nq2QNZZjh+Ew1Ea72XVNFLNSpLS8pFOckRnSmH834XRZUu7TW4AR0STJ5 X-Received: by 2002:a05:6402:1e88:b0:45d:88f:4b99 with SMTP id f8-20020a0564021e8800b0045d088f4b99mr7068463edf.236.1666178444894; Wed, 19 Oct 2022 04:20:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666178444; cv=none; d=google.com; s=arc-20160816; b=zwH0Ts36jD3TRjVqapLGl43XrOsdcI8BxzzSDKiDKjY8MgZH/X+UIbnA0o4XqzfenP kIA8kPIGvG0jB+F0EXfLnd6Wf/uWldAOM65/7yky/wuy164RQfDaRimn0+mrNHM4ClXT veB2dZWZn1kjIGVmYx2qZFx8EfRm6iabGIk7WsrSmZVejRmOsl/0yaDVcP/kM1PpgqSA UC0fsnkPWfGqa31KJbaeE+mEcB1zuw+KcIGzbwp457GbJUGQ+CYbo+RyFpFb7dgz/iZI UXY8zsvXPNy6eg5oQ6seCLM/CPEbfjBQfjvCY3seaCj9KOUMFZI8/AfZF5MfzOSYus25 oQsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:in-reply-to:message-id:date:subject :cc:to:from; bh=30sTVKmYOFohNo2T1PrQnUa6q1YZPw2rQ6+WvsWXDjI=; b=iji7yheR4U+wjVl3znSacYzrAZUQoxAwfSxVi46FKHlGATFc+HBKmnAipaC57iKaiU qUdOxpITR+pmUcvgj+mELiLzaLar6oCov0nyltgXsM1lhf+PmiVXgOKbscAfEeb6QaGb pCWrs0Aw86re1+DMakbNCf/NBzMTB3B46vPfFP0y/dx5KvI+YT2Lawp0Ve0m+rg13KIE H6Ux+OqsrNsbc5FeuDVU0cW+Fw9l05125mgD/+FY8rtzF+RMs7pg7pLH2OsPHBXqUwBT Dwx1LWxxBmicgORuF/Y4nknORXSyTH/E0UeXl3uDKN9GNCRK5CU8td8iMZFcaPwQtuUV lkyw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hq8-20020a1709073f0800b0078c37681f89si17274908ejc.650.2022.10.19.04.20.16; Wed, 19 Oct 2022 04:20:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233491AbiJSLKT (ORCPT <rfc822;samuel.l.nystrom@gmail.com> + 99 others); Wed, 19 Oct 2022 07:10:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44438 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234758AbiJSLJK (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 19 Oct 2022 07:09:10 -0400 Received: from out30-56.freemail.mail.aliyun.com (out30-56.freemail.mail.aliyun.com [115.124.30.56]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 97B4817FD5D; Wed, 19 Oct 2022 03:37:59 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R111e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046059;MF=xianting.tian@linux.alibaba.com;NM=1;PH=DS;RN=25;SR=0;TI=SMTPD_---0VSaNssl_1666175795; Received: from localhost.localdomain(mailfrom:xianting.tian@linux.alibaba.com fp:SMTPD_---0VSaNssl_1666175795) by smtp.aliyun-inc.com; Wed, 19 Oct 2022 18:36:36 +0800 From: Xianting Tian <xianting.tian@linux.alibaba.com> To: paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, anup@brainfault.org, heiko@sntech.de, guoren@kernel.org, mick@ics.forth.gr, alexandre.ghiti@canonical.com, bhe@redhat.com, vgoyal@redhat.com, dyoung@redhat.com, corbet@lwn.net, Conor.Dooley@microchip.com, bagasdotme@gmail.com, k-hagio-ab@nec.com, lijiang@redhat.com Cc: kexec@lists.infradead.org, linux-doc@vger.kernel.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, crash-utility@redhat.com, heinrich.schuchardt@canonical.com, hschauhan@nulltrace.org, yixun.lan@gmail.com, Xianting Tian <xianting.tian@linux.alibaba.com> Subject: [PATCH V4 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support Date: Wed, 19 Oct 2022 18:36:22 +0800 Message-Id: <20221019103623.7008-2-xianting.tian@linux.alibaba.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20221019103623.7008-1-xianting.tian@linux.alibaba.com> References: <20221019103623.7008-1-xianting.tian@linux.alibaba.com> X-Spam-Status: No, score=-9.9 required=5.0 tests=BAYES_00, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747114729026677294?= X-GMAIL-MSGID: =?utf-8?q?1747114729026677294?= |
Series |
Support VMCOREINFO export for RISCV64
|
|
Commit Message
Xianting Tian
Oct. 19, 2022, 10:36 a.m. UTC
Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC,
VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore.
Default pagetable levels and PAGE_OFFSET aren't same for different kernel
version as below. For pagetable levels, it sets sv57 by default and falls
back to setting sv48 at boot time if sv57 is not supported by the hardware.
For ram base, the default value is 0x80200000 for qemu riscv64 env and,
for example, is 0x200000 on the XuanTie 910 CPU.
* Linux Kernel 5.18 ~
* PGTABLE_LEVELS = 5
* PAGE_OFFSET = 0xff60000000000000
* Linux Kernel 5.17 ~
* PGTABLE_LEVELS = 4
* PAGE_OFFSET = 0xffffaf8000000000
* Linux Kernel 4.19 ~
* PGTABLE_LEVELS = 3
* PAGE_OFFSET = 0xffffffe000000000
Since these configurations change from time to time and version to version,
it is preferable to export them via vmcoreinfo than to change the crash's
code frequently, it can simplify the development of crash tool.
Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
---
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
2 files changed, 24 insertions(+)
create mode 100644 arch/riscv/kernel/crash_core.c
Comments
On 10/19/22 at 06:36pm, Xianting Tian wrote: > Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC, > VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore. > > Default pagetable levels and PAGE_OFFSET aren't same for different kernel > version as below. For pagetable levels, it sets sv57 by default and falls > back to setting sv48 at boot time if sv57 is not supported by the hardware. > > For ram base, the default value is 0x80200000 for qemu riscv64 env and, > for example, is 0x200000 on the XuanTie 910 CPU. > > * Linux Kernel 5.18 ~ > * PGTABLE_LEVELS = 5 > * PAGE_OFFSET = 0xff60000000000000 > * Linux Kernel 5.17 ~ > * PGTABLE_LEVELS = 4 > * PAGE_OFFSET = 0xffffaf8000000000 > * Linux Kernel 4.19 ~ > * PGTABLE_LEVELS = 3 > * PAGE_OFFSET = 0xffffffe000000000 > > Since these configurations change from time to time and version to version, > it is preferable to export them via vmcoreinfo than to change the crash's > code frequently, it can simplify the development of crash tool. > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> > --- > arch/riscv/kernel/Makefile | 1 + > arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++ > 2 files changed, 24 insertions(+) > create mode 100644 arch/riscv/kernel/crash_core.c > > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile > index db6e4b1294ba..4cf303a779ab 100644 > --- a/arch/riscv/kernel/Makefile > +++ b/arch/riscv/kernel/Makefile > @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB) += kgdb.o > obj-$(CONFIG_KEXEC_CORE) += kexec_relocate.o crash_save_regs.o machine_kexec.o > obj-$(CONFIG_KEXEC_FILE) += elf_kexec.o machine_kexec_file.o > obj-$(CONFIG_CRASH_DUMP) += crash_dump.o > +obj-$(CONFIG_CRASH_CORE) += crash_core.o > > obj-$(CONFIG_JUMP_LABEL) += jump_label.o > > diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c > new file mode 100644 > index 000000000000..3e889d0ed7bd > --- /dev/null > +++ b/arch/riscv/kernel/crash_core.c > @@ -0,0 +1,23 @@ > +// SPDX-License-Identifier: GPL-2.0-only > + > +#include <linux/crash_core.h> > +#include <linux/pagemap.h> > + > +void arch_crash_save_vmcoreinfo(void) > +{ > + VMCOREINFO_NUMBER(VA_BITS); > + VMCOREINFO_NUMBER(phys_ram_base); > + > + vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET); > + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START); > + vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END); > + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START); > + vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END); > +#ifdef CONFIG_64BIT > + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR); > + vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END); > +#endif > + > + if (IS_ENABLED(CONFIG_64BIT)) > + vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR); Wondering why you don't put KERNEL_LINK_ADDR exporting into the above ifdeffery scope, with that you can save one line of "IS_ENABLED(CONFIG_64BIT)".
在 2022/10/20 上午10:08, Baoquan He 写道: > On 10/19/22 at 06:36pm, Xianting Tian wrote: >> Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC, >> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore. >> >> Default pagetable levels and PAGE_OFFSET aren't same for different kernel >> version as below. For pagetable levels, it sets sv57 by default and falls >> back to setting sv48 at boot time if sv57 is not supported by the hardware. >> >> For ram base, the default value is 0x80200000 for qemu riscv64 env and, >> for example, is 0x200000 on the XuanTie 910 CPU. >> >> * Linux Kernel 5.18 ~ >> * PGTABLE_LEVELS = 5 >> * PAGE_OFFSET = 0xff60000000000000 >> * Linux Kernel 5.17 ~ >> * PGTABLE_LEVELS = 4 >> * PAGE_OFFSET = 0xffffaf8000000000 >> * Linux Kernel 4.19 ~ >> * PGTABLE_LEVELS = 3 >> * PAGE_OFFSET = 0xffffffe000000000 >> >> Since these configurations change from time to time and version to version, >> it is preferable to export them via vmcoreinfo than to change the crash's >> code frequently, it can simplify the development of crash tool. >> >> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> >> --- >> arch/riscv/kernel/Makefile | 1 + >> arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++ >> 2 files changed, 24 insertions(+) >> create mode 100644 arch/riscv/kernel/crash_core.c >> >> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile >> index db6e4b1294ba..4cf303a779ab 100644 >> --- a/arch/riscv/kernel/Makefile >> +++ b/arch/riscv/kernel/Makefile >> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB) += kgdb.o >> obj-$(CONFIG_KEXEC_CORE) += kexec_relocate.o crash_save_regs.o machine_kexec.o >> obj-$(CONFIG_KEXEC_FILE) += elf_kexec.o machine_kexec_file.o >> obj-$(CONFIG_CRASH_DUMP) += crash_dump.o >> +obj-$(CONFIG_CRASH_CORE) += crash_core.o >> >> obj-$(CONFIG_JUMP_LABEL) += jump_label.o >> >> diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c >> new file mode 100644 >> index 000000000000..3e889d0ed7bd >> --- /dev/null >> +++ b/arch/riscv/kernel/crash_core.c >> @@ -0,0 +1,23 @@ >> +// SPDX-License-Identifier: GPL-2.0-only >> + >> +#include <linux/crash_core.h> >> +#include <linux/pagemap.h> >> + >> +void arch_crash_save_vmcoreinfo(void) >> +{ >> + VMCOREINFO_NUMBER(VA_BITS); >> + VMCOREINFO_NUMBER(phys_ram_base); >> + >> + vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET); >> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START); >> + vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END); >> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START); >> + vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END); >> +#ifdef CONFIG_64BIT >> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR); >> + vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END); >> +#endif >> + >> + if (IS_ENABLED(CONFIG_64BIT)) >> + vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR); > Wondering why you don't put KERNEL_LINK_ADDR exporting into the above > ifdeffery scope, with that you can save one line of "IS_ENABLED(CONFIG_64BIT)". I followed the rule in print_vm_layout() of arch/riscv/mm/init.c, which used IS_ENABLED when print the value of KERNEL_LINK_ADDR.
On 10/20/22 at 10:17am, Xianting Tian wrote: > > 在 2022/10/20 上午10:08, Baoquan He 写道: > > On 10/19/22 at 06:36pm, Xianting Tian wrote: > > > Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC, > > > VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore. > > > > > > Default pagetable levels and PAGE_OFFSET aren't same for different kernel > > > version as below. For pagetable levels, it sets sv57 by default and falls > > > back to setting sv48 at boot time if sv57 is not supported by the hardware. > > > > > > For ram base, the default value is 0x80200000 for qemu riscv64 env and, > > > for example, is 0x200000 on the XuanTie 910 CPU. > > > > > > * Linux Kernel 5.18 ~ > > > * PGTABLE_LEVELS = 5 > > > * PAGE_OFFSET = 0xff60000000000000 > > > * Linux Kernel 5.17 ~ > > > * PGTABLE_LEVELS = 4 > > > * PAGE_OFFSET = 0xffffaf8000000000 > > > * Linux Kernel 4.19 ~ > > > * PGTABLE_LEVELS = 3 > > > * PAGE_OFFSET = 0xffffffe000000000 > > > > > > Since these configurations change from time to time and version to version, > > > it is preferable to export them via vmcoreinfo than to change the crash's > > > code frequently, it can simplify the development of crash tool. > > > > > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> > > > --- > > > arch/riscv/kernel/Makefile | 1 + > > > arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++ > > > 2 files changed, 24 insertions(+) > > > create mode 100644 arch/riscv/kernel/crash_core.c > > > > > > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile > > > index db6e4b1294ba..4cf303a779ab 100644 > > > --- a/arch/riscv/kernel/Makefile > > > +++ b/arch/riscv/kernel/Makefile > > > @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB) += kgdb.o > > > obj-$(CONFIG_KEXEC_CORE) += kexec_relocate.o crash_save_regs.o machine_kexec.o > > > obj-$(CONFIG_KEXEC_FILE) += elf_kexec.o machine_kexec_file.o > > > obj-$(CONFIG_CRASH_DUMP) += crash_dump.o > > > +obj-$(CONFIG_CRASH_CORE) += crash_core.o > > > obj-$(CONFIG_JUMP_LABEL) += jump_label.o > > > diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c > > > new file mode 100644 > > > index 000000000000..3e889d0ed7bd > > > --- /dev/null > > > +++ b/arch/riscv/kernel/crash_core.c > > > @@ -0,0 +1,23 @@ > > > +// SPDX-License-Identifier: GPL-2.0-only > > > + > > > +#include <linux/crash_core.h> > > > +#include <linux/pagemap.h> > > > + > > > +void arch_crash_save_vmcoreinfo(void) > > > +{ > > > + VMCOREINFO_NUMBER(VA_BITS); > > > + VMCOREINFO_NUMBER(phys_ram_base); > > > + > > > + vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET); > > > + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START); > > > + vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END); > > > + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START); > > > + vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END); > > > +#ifdef CONFIG_64BIT > > > + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR); > > > + vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END); > > > +#endif > > > + > > > + if (IS_ENABLED(CONFIG_64BIT)) > > > + vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR); > > Wondering why you don't put KERNEL_LINK_ADDR exporting into the above > > ifdeffery scope, with that you can save one line of "IS_ENABLED(CONFIG_64BIT)". > I followed the rule in print_vm_layout() of arch/riscv/mm/init.c, which used > IS_ENABLED when print the value of KERNEL_LINK_ADDR. > I see. There's PAGE_OFFSET in the middle. Thanks. print_ml("lowmem", (unsigned long)PAGE_OFFSET, (unsigned long)high_memory) So now, do you think if it's necessary to have another IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
在 2022/10/20 上午11:05, Baoquan He 写道: > On 10/20/22 at 10:17am, Xianting Tian wrote: >> 在 2022/10/20 上午10:08, Baoquan He 写道: >>> On 10/19/22 at 06:36pm, Xianting Tian wrote: >>>> Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC, >>>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore. >>>> >>>> Default pagetable levels and PAGE_OFFSET aren't same for different kernel >>>> version as below. For pagetable levels, it sets sv57 by default and falls >>>> back to setting sv48 at boot time if sv57 is not supported by the hardware. >>>> >>>> For ram base, the default value is 0x80200000 for qemu riscv64 env and, >>>> for example, is 0x200000 on the XuanTie 910 CPU. >>>> >>>> * Linux Kernel 5.18 ~ >>>> * PGTABLE_LEVELS = 5 >>>> * PAGE_OFFSET = 0xff60000000000000 >>>> * Linux Kernel 5.17 ~ >>>> * PGTABLE_LEVELS = 4 >>>> * PAGE_OFFSET = 0xffffaf8000000000 >>>> * Linux Kernel 4.19 ~ >>>> * PGTABLE_LEVELS = 3 >>>> * PAGE_OFFSET = 0xffffffe000000000 >>>> >>>> Since these configurations change from time to time and version to version, >>>> it is preferable to export them via vmcoreinfo than to change the crash's >>>> code frequently, it can simplify the development of crash tool. >>>> >>>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> >>>> --- >>>> arch/riscv/kernel/Makefile | 1 + >>>> arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++ >>>> 2 files changed, 24 insertions(+) >>>> create mode 100644 arch/riscv/kernel/crash_core.c >>>> >>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile >>>> index db6e4b1294ba..4cf303a779ab 100644 >>>> --- a/arch/riscv/kernel/Makefile >>>> +++ b/arch/riscv/kernel/Makefile >>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB) += kgdb.o >>>> obj-$(CONFIG_KEXEC_CORE) += kexec_relocate.o crash_save_regs.o machine_kexec.o >>>> obj-$(CONFIG_KEXEC_FILE) += elf_kexec.o machine_kexec_file.o >>>> obj-$(CONFIG_CRASH_DUMP) += crash_dump.o >>>> +obj-$(CONFIG_CRASH_CORE) += crash_core.o >>>> obj-$(CONFIG_JUMP_LABEL) += jump_label.o >>>> diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c >>>> new file mode 100644 >>>> index 000000000000..3e889d0ed7bd >>>> --- /dev/null >>>> +++ b/arch/riscv/kernel/crash_core.c >>>> @@ -0,0 +1,23 @@ >>>> +// SPDX-License-Identifier: GPL-2.0-only >>>> + >>>> +#include <linux/crash_core.h> >>>> +#include <linux/pagemap.h> >>>> + >>>> +void arch_crash_save_vmcoreinfo(void) >>>> +{ >>>> + VMCOREINFO_NUMBER(VA_BITS); >>>> + VMCOREINFO_NUMBER(phys_ram_base); >>>> + >>>> + vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET); >>>> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START); >>>> + vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END); >>>> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START); >>>> + vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END); >>>> +#ifdef CONFIG_64BIT >>>> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR); >>>> + vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END); >>>> +#endif >>>> + >>>> + if (IS_ENABLED(CONFIG_64BIT)) >>>> + vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR); >>> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above >>> ifdeffery scope, with that you can save one line of "IS_ENABLED(CONFIG_64BIT)". >> I followed the rule in print_vm_layout() of arch/riscv/mm/init.c, which used >> IS_ENABLED when print the value of KERNEL_LINK_ADDR. >> > I see. There's PAGE_OFFSET in the middle. Thanks. > > print_ml("lowmem", (unsigned long)PAGE_OFFSET, > (unsigned long)high_memory) > > So now, do you think if it's necessary to have another > IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()? For which MACRO? I think current code for PAGE_OFFSET is OK.
Tested-by: Guo Ren <guoren@kernel.org> Don't forget the another two kdump fixups [1] [1] https://lore.kernel.org/all/20221020141603.2856206-3-guoren@kernel.org/ Only the patch without [1]: crash> help -r CPU 0: [OFFLINE] CPU 1: epc : ffffffff80009ff0 ra : ffffffff800b789a sp : ff2000001098bb40 gp : ffffffff815fca60 tp : ff60000004680000 t0 : 6666666666663c5b t1 : 0000000000000000 t2 : 666666666666663c s0 : ff2000001098bc90 s1 : ffffffff81600798 a0 : ff2000001098bb48 a1 : 0000000000000000 a2 : 0000000000000000 a3 : 0000000000000001 a4 : 0000000000000000 a5 : ff60000004690800 a6 : 0000000000000000 a7 : 0000000000000000 s2 : ff2000001098bb48 s3 : ffffffff81093ec8 s4 : ffffffff816004ac s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80e7f720 s8 : 00fffffffffff3f0 s9 : 0000000000000007 s10: 00aaaaaaaab98700 s11: 0000000000000001 t3 : ffffffff819a8097 t4 : ffffffff819a8097 t5 : ffffffff819a8098 t6 : ff2000001098b9a8 CPU 2: [OFFLINE] CPU 3: [OFFLINE] The patch with [1]: crash> help -r CPU 0: epc : ffffffff80003f34 ra : ffffffff808caa7c sp : ffffffff81403eb0 gp : ffffffff815fcb48 tp : ffffffff81413400 t0 : 0000000000000000 t1 : 0000000000000000 t2 : 0000000000000000 s0 : ffffffff81403ec0 s1 : 0000000000000000 a0 : 0000000000000000 a1 : 0000000000000000 a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000 a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000 s2 : ffffffff816001c8 s3 : ffffffff81600370 s4 : ffffffff80c32e18 s5 : ffffffff819d3018 s6 : ffffffff810e2110 s7 : 0000000000000000 s8 : 0000000000000000 s9 : 0000000080039eac s10: 0000000000000000 s11: 0000000000000000 t3 : 0000000000000000 t4 : 0000000000000000 t5 : 0000000000000000 t6 : 0000000000000000 CPU 1: epc : ffffffff80003f34 ra : ffffffff808caa7c sp : ff2000000068bf30 gp : ffffffff815fcb48 tp : ff6000000240d400 t0 : 0000000000000000 t1 : 0000000000000000 t2 : 0000000000000000 s0 : ff2000000068bf40 s1 : 0000000000000001 a0 : 0000000000000000 a1 : 0000000000000000 a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000 a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000 s2 : ffffffff816001c8 s3 : ffffffff81600370 s4 : ffffffff80c32e18 s5 : ffffffff819d3018 s6 : ffffffff810e2110 s7 : 0000000000000000 s8 : 0000000000000000 s9 : 0000000080039ea8 s10: 0000000000000000 s11: 0000000000000000 t3 : 0000000000000000 t4 : 0000000000000000 t5 : 0000000000000000 t6 : 0000000000000000 CPU 2: epc : ffffffff80003f34 ra : ffffffff808caa7c sp : ff20000000693f30 gp : ffffffff815fcb48 tp : ff6000000240e900 t0 : 0000000000000000 t1 : 0000000000000000 t2 : 0000000000000000 s0 : ff20000000693f40 s1 : 0000000000000002 a0 : 0000000000000000 a1 : 0000000000000000 a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000 a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000 s2 : ffffffff816001c8 s3 : ffffffff81600370 s4 : ffffffff80c32e18 s5 : ffffffff819d3018 s6 : ffffffff810e2110 s7 : 0000000000000000 s8 : 0000000000000000 s9 : 0000000080039eb0 s10: 0000000000000000 s11: 0000000000000000 t3 : 0000000000000000 t4 : 0000000000000000 t5 : 0000000000000000 t6 : 0000000000000000 CPU 3: epc : ffffffff8000a1e4 ra : ffffffff800b7bba sp : ff200000109bbb40 gp : ffffffff815fcb48 tp : ff6000000373aa00 t0 : 6666666666663c5b t1 : 0000000000000000 t2 : 666666666666663c s0 : ff200000109bbc90 s1 : ffffffff816007a0 a0 : ff200000109bbb48 a1 : 0000000000000000 a2 : 0000000000000000 a3 : 0000000000000001 a4 : 0000000000000000 a5 : ff60000002c61c00 a6 : 0000000000000000 a7 : 0000000000000000 s2 : ff200000109bbb48 s3 : ffffffff810941a8 s4 : ffffffff816004b4 s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80e7f7a0 s8 : 00fffffffffff3f0 s9 : 0000000000000007 s10: 00aaaaaaaab98700 s11: 0000000000000001 t3 : ffffffff819a8097 t4 : ffffffff819a8097 t5 : ffffffff819a8098 t6 : ff200000109bb9a8 On Wed, Oct 19, 2022 at 6:36 PM Xianting Tian <xianting.tian@linux.alibaba.com> wrote: > > Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC, > VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore. > > Default pagetable levels and PAGE_OFFSET aren't same for different kernel > version as below. For pagetable levels, it sets sv57 by default and falls > back to setting sv48 at boot time if sv57 is not supported by the hardware. > > For ram base, the default value is 0x80200000 for qemu riscv64 env and, > for example, is 0x200000 on the XuanTie 910 CPU. > > * Linux Kernel 5.18 ~ > * PGTABLE_LEVELS = 5 > * PAGE_OFFSET = 0xff60000000000000 > * Linux Kernel 5.17 ~ > * PGTABLE_LEVELS = 4 > * PAGE_OFFSET = 0xffffaf8000000000 > * Linux Kernel 4.19 ~ > * PGTABLE_LEVELS = 3 > * PAGE_OFFSET = 0xffffffe000000000 > > Since these configurations change from time to time and version to version, > it is preferable to export them via vmcoreinfo than to change the crash's > code frequently, it can simplify the development of crash tool. > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> > --- > arch/riscv/kernel/Makefile | 1 + > arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++ > 2 files changed, 24 insertions(+) > create mode 100644 arch/riscv/kernel/crash_core.c > > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile > index db6e4b1294ba..4cf303a779ab 100644 > --- a/arch/riscv/kernel/Makefile > +++ b/arch/riscv/kernel/Makefile > @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB) += kgdb.o > obj-$(CONFIG_KEXEC_CORE) += kexec_relocate.o crash_save_regs.o machine_kexec.o > obj-$(CONFIG_KEXEC_FILE) += elf_kexec.o machine_kexec_file.o > obj-$(CONFIG_CRASH_DUMP) += crash_dump.o > +obj-$(CONFIG_CRASH_CORE) += crash_core.o > > obj-$(CONFIG_JUMP_LABEL) += jump_label.o > > diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c > new file mode 100644 > index 000000000000..3e889d0ed7bd > --- /dev/null > +++ b/arch/riscv/kernel/crash_core.c > @@ -0,0 +1,23 @@ > +// SPDX-License-Identifier: GPL-2.0-only > + > +#include <linux/crash_core.h> > +#include <linux/pagemap.h> > + > +void arch_crash_save_vmcoreinfo(void) > +{ > + VMCOREINFO_NUMBER(VA_BITS); > + VMCOREINFO_NUMBER(phys_ram_base); > + > + vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET); > + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START); > + vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END); > + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START); > + vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END); > +#ifdef CONFIG_64BIT > + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR); > + vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END); > +#endif > + > + if (IS_ENABLED(CONFIG_64BIT)) > + vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR); > +} > -- > 2.17.1 >
Hi Palmer, Conor Is this version OK for you? Do you plan to apply this patch set? thanks 在 2022/10/20 下午12:40, Xianting Tian 写道: > > 在 2022/10/20 上午11:05, Baoquan He 写道: >> On 10/20/22 at 10:17am, Xianting Tian wrote: >>> 在 2022/10/20 上午10:08, Baoquan He 写道: >>>> On 10/19/22 at 06:36pm, Xianting Tian wrote: >>>>> Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, >>>>> VMALLOC, >>>>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for >>>>> vmcore. >>>>> >>>>> Default pagetable levels and PAGE_OFFSET aren't same for different >>>>> kernel >>>>> version as below. For pagetable levels, it sets sv57 by default >>>>> and falls >>>>> back to setting sv48 at boot time if sv57 is not supported by the >>>>> hardware. >>>>> >>>>> For ram base, the default value is 0x80200000 for qemu riscv64 env >>>>> and, >>>>> for example, is 0x200000 on the XuanTie 910 CPU. >>>>> >>>>> * Linux Kernel 5.18 ~ >>>>> * PGTABLE_LEVELS = 5 >>>>> * PAGE_OFFSET = 0xff60000000000000 >>>>> * Linux Kernel 5.17 ~ >>>>> * PGTABLE_LEVELS = 4 >>>>> * PAGE_OFFSET = 0xffffaf8000000000 >>>>> * Linux Kernel 4.19 ~ >>>>> * PGTABLE_LEVELS = 3 >>>>> * PAGE_OFFSET = 0xffffffe000000000 >>>>> >>>>> Since these configurations change from time to time and version to >>>>> version, >>>>> it is preferable to export them via vmcoreinfo than to change the >>>>> crash's >>>>> code frequently, it can simplify the development of crash tool. >>>>> >>>>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> >>>>> --- >>>>> arch/riscv/kernel/Makefile | 1 + >>>>> arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++ >>>>> 2 files changed, 24 insertions(+) >>>>> create mode 100644 arch/riscv/kernel/crash_core.c >>>>> >>>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile >>>>> index db6e4b1294ba..4cf303a779ab 100644 >>>>> --- a/arch/riscv/kernel/Makefile >>>>> +++ b/arch/riscv/kernel/Makefile >>>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB) += kgdb.o >>>>> obj-$(CONFIG_KEXEC_CORE) += kexec_relocate.o >>>>> crash_save_regs.o machine_kexec.o >>>>> obj-$(CONFIG_KEXEC_FILE) += elf_kexec.o machine_kexec_file.o >>>>> obj-$(CONFIG_CRASH_DUMP) += crash_dump.o >>>>> +obj-$(CONFIG_CRASH_CORE) += crash_core.o >>>>> obj-$(CONFIG_JUMP_LABEL) += jump_label.o >>>>> diff --git a/arch/riscv/kernel/crash_core.c >>>>> b/arch/riscv/kernel/crash_core.c >>>>> new file mode 100644 >>>>> index 000000000000..3e889d0ed7bd >>>>> --- /dev/null >>>>> +++ b/arch/riscv/kernel/crash_core.c >>>>> @@ -0,0 +1,23 @@ >>>>> +// SPDX-License-Identifier: GPL-2.0-only >>>>> + >>>>> +#include <linux/crash_core.h> >>>>> +#include <linux/pagemap.h> >>>>> + >>>>> +void arch_crash_save_vmcoreinfo(void) >>>>> +{ >>>>> + VMCOREINFO_NUMBER(VA_BITS); >>>>> + VMCOREINFO_NUMBER(phys_ram_base); >>>>> + >>>>> + vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", >>>>> PAGE_OFFSET); >>>>> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", >>>>> VMALLOC_START); >>>>> + vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", >>>>> VMALLOC_END); >>>>> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", >>>>> VMEMMAP_START); >>>>> + vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", >>>>> VMEMMAP_END); >>>>> +#ifdef CONFIG_64BIT >>>>> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", >>>>> MODULES_VADDR); >>>>> + vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", >>>>> MODULES_END); >>>>> +#endif >>>>> + >>>>> + if (IS_ENABLED(CONFIG_64BIT)) >>>>> + vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", >>>>> KERNEL_LINK_ADDR); >>>> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above >>>> ifdeffery scope, with that you can save one line of >>>> "IS_ENABLED(CONFIG_64BIT)". >>> I followed the rule in print_vm_layout() of arch/riscv/mm/init.c, >>> which used >>> IS_ENABLED when print the value of KERNEL_LINK_ADDR. >>> >> I see. There's PAGE_OFFSET in the middle. Thanks. >> >> print_ml("lowmem", (unsigned long)PAGE_OFFSET, >> (unsigned long)high_memory) >> >> So now, do you think if it's necessary to have another >> IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()? > > For which MACRO? I think current code for PAGE_OFFSET is OK. >
On Wed, Oct 26, 2022 at 05:08:11PM +0800, Xianting Tian wrote: > Hi Palmer, Conor > > Is this version OK for you? The weird ifdef/IS_ENABLED thing was the only comment I had. It's a bit odd & I notice Baoquan brought it up too. I didn't (and won't) give you a reviewed by on these patches because I don't understand the area well enough. The general nitpickery seems to be sorted though. Thanks, Conor. > > 在 2022/10/20 下午12:40, Xianting Tian 写道: > > > > 在 2022/10/20 上午11:05, Baoquan He 写道: > > > On 10/20/22 at 10:17am, Xianting Tian wrote: > > > > 在 2022/10/20 上午10:08, Baoquan He 写道: > > > > > On 10/19/22 at 06:36pm, Xianting Tian wrote: > > > > > > Add arch_crash_save_vmcoreinfo(), which exports VM > > > > > > layout(MODULES, VMALLOC, > > > > > > VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram > > > > > > base for vmcore. > > > > > > > > > > > > Default pagetable levels and PAGE_OFFSET aren't same for > > > > > > different kernel > > > > > > version as below. For pagetable levels, it sets sv57 by > > > > > > default and falls > > > > > > back to setting sv48 at boot time if sv57 is not > > > > > > supported by the hardware. > > > > > > > > > > > > For ram base, the default value is 0x80200000 for qemu > > > > > > riscv64 env and, > > > > > > for example, is 0x200000 on the XuanTie 910 CPU. > > > > > > > > > > > > * Linux Kernel 5.18 ~ > > > > > > * PGTABLE_LEVELS = 5 > > > > > > * PAGE_OFFSET = 0xff60000000000000 > > > > > > * Linux Kernel 5.17 ~ > > > > > > * PGTABLE_LEVELS = 4 > > > > > > * PAGE_OFFSET = 0xffffaf8000000000 > > > > > > * Linux Kernel 4.19 ~ > > > > > > * PGTABLE_LEVELS = 3 > > > > > > * PAGE_OFFSET = 0xffffffe000000000 > > > > > > > > > > > > Since these configurations change from time to time and > > > > > > version to version, > > > > > > it is preferable to export them via vmcoreinfo than to > > > > > > change the crash's > > > > > > code frequently, it can simplify the development of crash tool. > > > > > > > > > > > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> > > > > > > --- > > > > > > arch/riscv/kernel/Makefile | 1 + > > > > > > arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++ > > > > > > 2 files changed, 24 insertions(+) > > > > > > create mode 100644 arch/riscv/kernel/crash_core.c > > > > > > > > > > > > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile > > > > > > index db6e4b1294ba..4cf303a779ab 100644 > > > > > > --- a/arch/riscv/kernel/Makefile > > > > > > +++ b/arch/riscv/kernel/Makefile > > > > > > @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB) += kgdb.o > > > > > > obj-$(CONFIG_KEXEC_CORE) += kexec_relocate.o > > > > > > crash_save_regs.o machine_kexec.o > > > > > > obj-$(CONFIG_KEXEC_FILE) += elf_kexec.o machine_kexec_file.o > > > > > > obj-$(CONFIG_CRASH_DUMP) += crash_dump.o > > > > > > +obj-$(CONFIG_CRASH_CORE) += crash_core.o > > > > > > obj-$(CONFIG_JUMP_LABEL) += jump_label.o > > > > > > diff --git a/arch/riscv/kernel/crash_core.c > > > > > > b/arch/riscv/kernel/crash_core.c > > > > > > new file mode 100644 > > > > > > index 000000000000..3e889d0ed7bd > > > > > > --- /dev/null > > > > > > +++ b/arch/riscv/kernel/crash_core.c > > > > > > @@ -0,0 +1,23 @@ > > > > > > +// SPDX-License-Identifier: GPL-2.0-only > > > > > > + > > > > > > +#include <linux/crash_core.h> > > > > > > +#include <linux/pagemap.h> > > > > > > + > > > > > > +void arch_crash_save_vmcoreinfo(void) > > > > > > +{ > > > > > > + VMCOREINFO_NUMBER(VA_BITS); > > > > > > + VMCOREINFO_NUMBER(phys_ram_base); > > > > > > + > > > > > > + > > > > > > vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", > > > > > > PAGE_OFFSET); > > > > > > + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", > > > > > > VMALLOC_START); > > > > > > + > > > > > > vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", > > > > > > VMALLOC_END); > > > > > > + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", > > > > > > VMEMMAP_START); > > > > > > + > > > > > > vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", > > > > > > VMEMMAP_END); > > > > > > +#ifdef CONFIG_64BIT > > > > > > + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", > > > > > > MODULES_VADDR); > > > > > > + > > > > > > vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", > > > > > > MODULES_END); > > > > > > +#endif > > > > > > + > > > > > > + if (IS_ENABLED(CONFIG_64BIT)) > > > > > > + > > > > > > vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", > > > > > > KERNEL_LINK_ADDR); > > > > > Wondering why you don't put KERNEL_LINK_ADDR exporting into the above > > > > > ifdeffery scope, with that you can save one line of > > > > > "IS_ENABLED(CONFIG_64BIT)". > > > > I followed the rule in print_vm_layout() of > > > > arch/riscv/mm/init.c, which used > > > > IS_ENABLED when print the value of KERNEL_LINK_ADDR. > > > > > > > I see. There's PAGE_OFFSET in the middle. Thanks. > > > > > > print_ml("lowmem", (unsigned long)PAGE_OFFSET, > > > (unsigned long)high_memory) > > > > > > So now, do you think if it's necessary to have another > > > IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()? > > > > For which MACRO? I think current code for PAGE_OFFSET is OK. > >
在 2022/10/26 下午5:25, Conor Dooley 写道: > On Wed, Oct 26, 2022 at 05:08:11PM +0800, Xianting Tian wrote: >> Hi Palmer, Conor >> >> Is this version OK for you? > The weird ifdef/IS_ENABLED thing was the only comment I had. It's a bit > odd & I notice Baoquan brought it up too. I didn't (and won't) give you > a reviewed by on these patches because I don't understand the area well > enough. The general nitpickery seems to be sorted though. I checked the KERNEL_LINK_ADDR definition of riscv, it is valid for CONFIG_64BIT and !CONFIG_64BIT. Maybe we can remove IS_ENABLED(CONFIG_64BIT) arch/riscv/include/asm/pgtable.h #define ADDRESS_SPACE_END (UL(-1)) #ifdef CONFIG_64BIT /* Leave 2GB for kernel and BPF at the end of the address space */ #define KERNEL_LINK_ADDR (ADDRESS_SPACE_END - SZ_2G + 1) #else #define KERNEL_LINK_ADDR PAGE_OFFSET #endif arch/riscv/include/asm/page.h #ifdef CONFIG_64BIT #ifdef CONFIG_MMU #define PAGE_OFFSET kernel_map.page_offset #else #define PAGE_OFFSET _AC(CONFIG_PAGE_OFFSET, UL) #endif /* * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address space so * define the PAGE_OFFSET value for SV39. */ #define PAGE_OFFSET_L4 _AC(0xffffaf8000000000, UL) #define PAGE_OFFSET_L3 _AC(0xffffffd800000000, UL) #else #define PAGE_OFFSET _AC(CONFIG_PAGE_OFFSET, UL) #endif /* CONFIG_64BIT */ > > Thanks, > Conor. > >> 在 2022/10/20 下午12:40, Xianting Tian 写道: >>> 在 2022/10/20 上午11:05, Baoquan He 写道: >>>> On 10/20/22 at 10:17am, Xianting Tian wrote: >>>>> 在 2022/10/20 上午10:08, Baoquan He 写道: >>>>>> On 10/19/22 at 06:36pm, Xianting Tian wrote: >>>>>>> Add arch_crash_save_vmcoreinfo(), which exports VM >>>>>>> layout(MODULES, VMALLOC, >>>>>>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram >>>>>>> base for vmcore. >>>>>>> >>>>>>> Default pagetable levels and PAGE_OFFSET aren't same for >>>>>>> different kernel >>>>>>> version as below. For pagetable levels, it sets sv57 by >>>>>>> default and falls >>>>>>> back to setting sv48 at boot time if sv57 is not >>>>>>> supported by the hardware. >>>>>>> >>>>>>> For ram base, the default value is 0x80200000 for qemu >>>>>>> riscv64 env and, >>>>>>> for example, is 0x200000 on the XuanTie 910 CPU. >>>>>>> >>>>>>> * Linux Kernel 5.18 ~ >>>>>>> * PGTABLE_LEVELS = 5 >>>>>>> * PAGE_OFFSET = 0xff60000000000000 >>>>>>> * Linux Kernel 5.17 ~ >>>>>>> * PGTABLE_LEVELS = 4 >>>>>>> * PAGE_OFFSET = 0xffffaf8000000000 >>>>>>> * Linux Kernel 4.19 ~ >>>>>>> * PGTABLE_LEVELS = 3 >>>>>>> * PAGE_OFFSET = 0xffffffe000000000 >>>>>>> >>>>>>> Since these configurations change from time to time and >>>>>>> version to version, >>>>>>> it is preferable to export them via vmcoreinfo than to >>>>>>> change the crash's >>>>>>> code frequently, it can simplify the development of crash tool. >>>>>>> >>>>>>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> >>>>>>> --- >>>>>>> arch/riscv/kernel/Makefile | 1 + >>>>>>> arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++ >>>>>>> 2 files changed, 24 insertions(+) >>>>>>> create mode 100644 arch/riscv/kernel/crash_core.c >>>>>>> >>>>>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile >>>>>>> index db6e4b1294ba..4cf303a779ab 100644 >>>>>>> --- a/arch/riscv/kernel/Makefile >>>>>>> +++ b/arch/riscv/kernel/Makefile >>>>>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB) += kgdb.o >>>>>>> obj-$(CONFIG_KEXEC_CORE) += kexec_relocate.o >>>>>>> crash_save_regs.o machine_kexec.o >>>>>>> obj-$(CONFIG_KEXEC_FILE) += elf_kexec.o machine_kexec_file.o >>>>>>> obj-$(CONFIG_CRASH_DUMP) += crash_dump.o >>>>>>> +obj-$(CONFIG_CRASH_CORE) += crash_core.o >>>>>>> obj-$(CONFIG_JUMP_LABEL) += jump_label.o >>>>>>> diff --git a/arch/riscv/kernel/crash_core.c >>>>>>> b/arch/riscv/kernel/crash_core.c >>>>>>> new file mode 100644 >>>>>>> index 000000000000..3e889d0ed7bd >>>>>>> --- /dev/null >>>>>>> +++ b/arch/riscv/kernel/crash_core.c >>>>>>> @@ -0,0 +1,23 @@ >>>>>>> +// SPDX-License-Identifier: GPL-2.0-only >>>>>>> + >>>>>>> +#include <linux/crash_core.h> >>>>>>> +#include <linux/pagemap.h> >>>>>>> + >>>>>>> +void arch_crash_save_vmcoreinfo(void) >>>>>>> +{ >>>>>>> + VMCOREINFO_NUMBER(VA_BITS); >>>>>>> + VMCOREINFO_NUMBER(phys_ram_base); >>>>>>> + >>>>>>> + >>>>>>> vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", >>>>>>> PAGE_OFFSET); >>>>>>> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", >>>>>>> VMALLOC_START); >>>>>>> + >>>>>>> vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", >>>>>>> VMALLOC_END); >>>>>>> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", >>>>>>> VMEMMAP_START); >>>>>>> + >>>>>>> vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", >>>>>>> VMEMMAP_END); >>>>>>> +#ifdef CONFIG_64BIT >>>>>>> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", >>>>>>> MODULES_VADDR); >>>>>>> + >>>>>>> vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", >>>>>>> MODULES_END); >>>>>>> +#endif >>>>>>> + >>>>>>> + if (IS_ENABLED(CONFIG_64BIT)) >>>>>>> + >>>>>>> vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", >>>>>>> KERNEL_LINK_ADDR); >>>>>> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above >>>>>> ifdeffery scope, with that you can save one line of >>>>>> "IS_ENABLED(CONFIG_64BIT)". >>>>> I followed the rule in print_vm_layout() of >>>>> arch/riscv/mm/init.c, which used >>>>> IS_ENABLED when print the value of KERNEL_LINK_ADDR. >>>>> >>>> I see. There's PAGE_OFFSET in the middle. Thanks. >>>> >>>> print_ml("lowmem", (unsigned long)PAGE_OFFSET, >>>> (unsigned long)high_memory) >>>> >>>> So now, do you think if it's necessary to have another >>>> IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()? >>> For which MACRO? I think current code for PAGE_OFFSET is OK. >>>
Hi Xianting, On 10/26/22 at 05:44pm, Xianting Tian wrote: > > 在 2022/10/26 下午5:25, Conor Dooley 写道: > > On Wed, Oct 26, 2022 at 05:08:11PM +0800, Xianting Tian wrote: > > > Hi Palmer, Conor > > > > > > Is this version OK for you? > > The weird ifdef/IS_ENABLED thing was the only comment I had. It's a bit > > odd & I notice Baoquan brought it up too. I didn't (and won't) give you > > a reviewed by on these patches because I don't understand the area well > > enough. The general nitpickery seems to be sorted though. > > I checked the KERNEL_LINK_ADDR definition of riscv, it is valid for > CONFIG_64BIT and !CONFIG_64BIT. This series looks good to me. My only minor concern is if we can make the arch_crash_save_vmcoreinfo() as below. I don't understand why we have to have the CONFIG_64BIT ifdeffery and the IS_ENABLED(CONFIG_64BIT) between two adjacent code blocks. Not sure if we are saying the same thing. +void arch_crash_save_vmcoreinfo(void) +{ + VMCOREINFO_NUMBER(VA_BITS); + VMCOREINFO_NUMBER(phys_ram_base); + + vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET); + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START); + vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END); + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START); + vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END); +#ifdef CONFIG_64BIT + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR); + vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END); + vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR); +#endif +} > > Maybe we can remove IS_ENABLED(CONFIG_64BIT) > > arch/riscv/include/asm/pgtable.h > #define ADDRESS_SPACE_END (UL(-1)) > #ifdef CONFIG_64BIT > /* Leave 2GB for kernel and BPF at the end of the address space */ > #define KERNEL_LINK_ADDR (ADDRESS_SPACE_END - SZ_2G + 1) > #else > #define KERNEL_LINK_ADDR PAGE_OFFSET > #endif > > arch/riscv/include/asm/page.h > #ifdef CONFIG_64BIT > #ifdef CONFIG_MMU > #define PAGE_OFFSET kernel_map.page_offset > #else > #define PAGE_OFFSET _AC(CONFIG_PAGE_OFFSET, UL) > #endif > /* > * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address space so > * define the PAGE_OFFSET value for SV39. > */ > #define PAGE_OFFSET_L4 _AC(0xffffaf8000000000, UL) > #define PAGE_OFFSET_L3 _AC(0xffffffd800000000, UL) > #else > #define PAGE_OFFSET _AC(CONFIG_PAGE_OFFSET, UL) > #endif /* CONFIG_64BIT */ > > > > > Thanks, > > Conor. > > > > > 在 2022/10/20 下午12:40, Xianting Tian 写道: > > > > 在 2022/10/20 上午11:05, Baoquan He 写道: > > > > > On 10/20/22 at 10:17am, Xianting Tian wrote: > > > > > > 在 2022/10/20 上午10:08, Baoquan He 写道: > > > > > > > On 10/19/22 at 06:36pm, Xianting Tian wrote: > > > > > > > > Add arch_crash_save_vmcoreinfo(), which exports VM > > > > > > > > layout(MODULES, VMALLOC, > > > > > > > > VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram > > > > > > > > base for vmcore. > > > > > > > > > > > > > > > > Default pagetable levels and PAGE_OFFSET aren't same for > > > > > > > > different kernel > > > > > > > > version as below. For pagetable levels, it sets sv57 by > > > > > > > > default and falls > > > > > > > > back to setting sv48 at boot time if sv57 is not > > > > > > > > supported by the hardware. > > > > > > > > > > > > > > > > For ram base, the default value is 0x80200000 for qemu > > > > > > > > riscv64 env and, > > > > > > > > for example, is 0x200000 on the XuanTie 910 CPU. > > > > > > > > > > > > > > > > * Linux Kernel 5.18 ~ > > > > > > > > * PGTABLE_LEVELS = 5 > > > > > > > > * PAGE_OFFSET = 0xff60000000000000 > > > > > > > > * Linux Kernel 5.17 ~ > > > > > > > > * PGTABLE_LEVELS = 4 > > > > > > > > * PAGE_OFFSET = 0xffffaf8000000000 > > > > > > > > * Linux Kernel 4.19 ~ > > > > > > > > * PGTABLE_LEVELS = 3 > > > > > > > > * PAGE_OFFSET = 0xffffffe000000000 > > > > > > > > > > > > > > > > Since these configurations change from time to time and > > > > > > > > version to version, > > > > > > > > it is preferable to export them via vmcoreinfo than to > > > > > > > > change the crash's > > > > > > > > code frequently, it can simplify the development of crash tool. > > > > > > > > > > > > > > > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> > > > > > > > > --- > > > > > > > > arch/riscv/kernel/Makefile | 1 + > > > > > > > > arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++ > > > > > > > > 2 files changed, 24 insertions(+) > > > > > > > > create mode 100644 arch/riscv/kernel/crash_core.c > > > > > > > > > > > > > > > > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile > > > > > > > > index db6e4b1294ba..4cf303a779ab 100644 > > > > > > > > --- a/arch/riscv/kernel/Makefile > > > > > > > > +++ b/arch/riscv/kernel/Makefile > > > > > > > > @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB) += kgdb.o > > > > > > > > obj-$(CONFIG_KEXEC_CORE) += kexec_relocate.o > > > > > > > > crash_save_regs.o machine_kexec.o > > > > > > > > obj-$(CONFIG_KEXEC_FILE) += elf_kexec.o machine_kexec_file.o > > > > > > > > obj-$(CONFIG_CRASH_DUMP) += crash_dump.o > > > > > > > > +obj-$(CONFIG_CRASH_CORE) += crash_core.o > > > > > > > > obj-$(CONFIG_JUMP_LABEL) += jump_label.o > > > > > > > > diff --git a/arch/riscv/kernel/crash_core.c > > > > > > > > b/arch/riscv/kernel/crash_core.c > > > > > > > > new file mode 100644 > > > > > > > > index 000000000000..3e889d0ed7bd > > > > > > > > --- /dev/null > > > > > > > > +++ b/arch/riscv/kernel/crash_core.c > > > > > > > > @@ -0,0 +1,23 @@ > > > > > > > > +// SPDX-License-Identifier: GPL-2.0-only > > > > > > > > + > > > > > > > > +#include <linux/crash_core.h> > > > > > > > > +#include <linux/pagemap.h> > > > > > > > > + > > > > > > > > +void arch_crash_save_vmcoreinfo(void) > > > > > > > > +{ > > > > > > > > + VMCOREINFO_NUMBER(VA_BITS); > > > > > > > > + VMCOREINFO_NUMBER(phys_ram_base); > > > > > > > > + > > > > > > > > + > > > > > > > > vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", > > > > > > > > PAGE_OFFSET); > > > > > > > > + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", > > > > > > > > VMALLOC_START); > > > > > > > > + > > > > > > > > vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", > > > > > > > > VMALLOC_END); > > > > > > > > + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", > > > > > > > > VMEMMAP_START); > > > > > > > > + > > > > > > > > vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", > > > > > > > > VMEMMAP_END); > > > > > > > > +#ifdef CONFIG_64BIT > > > > > > > > + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", > > > > > > > > MODULES_VADDR); > > > > > > > > + > > > > > > > > vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", > > > > > > > > MODULES_END); > > > > > > > > +#endif > > > > > > > > + > > > > > > > > + if (IS_ENABLED(CONFIG_64BIT)) > > > > > > > > + > > > > > > > > vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", > > > > > > > > KERNEL_LINK_ADDR); > > > > > > > Wondering why you don't put KERNEL_LINK_ADDR exporting into the above > > > > > > > ifdeffery scope, with that you can save one line of > > > > > > > "IS_ENABLED(CONFIG_64BIT)". > > > > > > I followed the rule in print_vm_layout() of > > > > > > arch/riscv/mm/init.c, which used > > > > > > IS_ENABLED when print the value of KERNEL_LINK_ADDR. > > > > > > > > > > > I see. There's PAGE_OFFSET in the middle. Thanks. > > > > > > > > > > print_ml("lowmem", (unsigned long)PAGE_OFFSET, > > > > > (unsigned long)high_memory) > > > > > > > > > > So now, do you think if it's necessary to have another > > > > > IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()? > > > > For which MACRO? I think current code for PAGE_OFFSET is OK. > > > > >
On Wed, Oct 26, 2022 at 08:05:41PM +0800, Baoquan He wrote: > Hi Xianting, > > On 10/26/22 at 05:44pm, Xianting Tian wrote: > > > > 在 2022/10/26 下午5:25, Conor Dooley 写道: > > > On Wed, Oct 26, 2022 at 05:08:11PM +0800, Xianting Tian wrote: > > > > Hi Palmer, Conor > > > > > > > > Is this version OK for you? > > > The weird ifdef/IS_ENABLED thing was the only comment I had. It's a bit > > > odd & I notice Baoquan brought it up too. I didn't (and won't) give you > > > a reviewed by on these patches because I don't understand the area well > > > enough. The general nitpickery seems to be sorted though. > > > > I checked the KERNEL_LINK_ADDR definition of riscv, it is valid for > > CONFIG_64BIT and !CONFIG_64BIT. > > This series looks good to me. My only minor concern is if we can make > the arch_crash_save_vmcoreinfo() as below. I don't understand why we > have to have the CONFIG_64BIT ifdeffery and the IS_ENABLED(CONFIG_64BIT) > between two adjacent code blocks. Not sure if we are saying the same > thing. I think we can just go and drop the IS_ENABLED(). From looking at it last time, one bit is compileable (but not usable) for !64BIT and the other isn't hence the IS_ENABLED(). I think it would make sense to drop the IS_ENABLED() - I don't think we're too likely to hit some compile testing edge cases that IS_ENABLED() would help with & only having one makes the code look a lot less odd and a lot more intentional. > > +void arch_crash_save_vmcoreinfo(void) > +{ > + VMCOREINFO_NUMBER(VA_BITS); > + VMCOREINFO_NUMBER(phys_ram_base); > + > + vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET); > + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START); > + vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END); > + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START); > + vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END); > +#ifdef CONFIG_64BIT > + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR); > + vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END); > + vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR); > +#endif > +} > > > > > Maybe we can remove IS_ENABLED(CONFIG_64BIT) > > > > arch/riscv/include/asm/pgtable.h > > #define ADDRESS_SPACE_END (UL(-1)) > > #ifdef CONFIG_64BIT > > /* Leave 2GB for kernel and BPF at the end of the address space */ > > #define KERNEL_LINK_ADDR (ADDRESS_SPACE_END - SZ_2G + 1) > > #else > > #define KERNEL_LINK_ADDR PAGE_OFFSET > > #endif > > > > arch/riscv/include/asm/page.h > > #ifdef CONFIG_64BIT > > #ifdef CONFIG_MMU > > #define PAGE_OFFSET kernel_map.page_offset > > #else > > #define PAGE_OFFSET _AC(CONFIG_PAGE_OFFSET, UL) > > #endif > > /* > > * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address space so > > * define the PAGE_OFFSET value for SV39. > > */ > > #define PAGE_OFFSET_L4 _AC(0xffffaf8000000000, UL) > > #define PAGE_OFFSET_L3 _AC(0xffffffd800000000, UL) > > #else > > #define PAGE_OFFSET _AC(CONFIG_PAGE_OFFSET, UL) > > #endif /* CONFIG_64BIT */ > > > > > > > > Thanks, > > > Conor. > > > > > > > 在 2022/10/20 下午12:40, Xianting Tian 写道: > > > > > 在 2022/10/20 上午11:05, Baoquan He 写道: > > > > > > On 10/20/22 at 10:17am, Xianting Tian wrote: > > > > > > > 在 2022/10/20 上午10:08, Baoquan He 写道: > > > > > > > > On 10/19/22 at 06:36pm, Xianting Tian wrote: > > > > > > > > > Add arch_crash_save_vmcoreinfo(), which exports VM > > > > > > > > > layout(MODULES, VMALLOC, > > > > > > > > > VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram > > > > > > > > > base for vmcore. > > > > > > > > > > > > > > > > > > Default pagetable levels and PAGE_OFFSET aren't same for > > > > > > > > > different kernel > > > > > > > > > version as below. For pagetable levels, it sets sv57 by > > > > > > > > > default and falls > > > > > > > > > back to setting sv48 at boot time if sv57 is not > > > > > > > > > supported by the hardware. > > > > > > > > > > > > > > > > > > For ram base, the default value is 0x80200000 for qemu > > > > > > > > > riscv64 env and, > > > > > > > > > for example, is 0x200000 on the XuanTie 910 CPU. > > > > > > > > > > > > > > > > > > * Linux Kernel 5.18 ~ > > > > > > > > > * PGTABLE_LEVELS = 5 > > > > > > > > > * PAGE_OFFSET = 0xff60000000000000 > > > > > > > > > * Linux Kernel 5.17 ~ > > > > > > > > > * PGTABLE_LEVELS = 4 > > > > > > > > > * PAGE_OFFSET = 0xffffaf8000000000 > > > > > > > > > * Linux Kernel 4.19 ~ > > > > > > > > > * PGTABLE_LEVELS = 3 > > > > > > > > > * PAGE_OFFSET = 0xffffffe000000000 > > > > > > > > > > > > > > > > > > Since these configurations change from time to time and > > > > > > > > > version to version, > > > > > > > > > it is preferable to export them via vmcoreinfo than to > > > > > > > > > change the crash's > > > > > > > > > code frequently, it can simplify the development of crash tool. > > > > > > > > > > > > > > > > > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> > > > > > > > > > --- > > > > > > > > > arch/riscv/kernel/Makefile | 1 + > > > > > > > > > arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++ > > > > > > > > > 2 files changed, 24 insertions(+) > > > > > > > > > create mode 100644 arch/riscv/kernel/crash_core.c > > > > > > > > > > > > > > > > > > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile > > > > > > > > > index db6e4b1294ba..4cf303a779ab 100644 > > > > > > > > > --- a/arch/riscv/kernel/Makefile > > > > > > > > > +++ b/arch/riscv/kernel/Makefile > > > > > > > > > @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB) += kgdb.o > > > > > > > > > obj-$(CONFIG_KEXEC_CORE) += kexec_relocate.o > > > > > > > > > crash_save_regs.o machine_kexec.o > > > > > > > > > obj-$(CONFIG_KEXEC_FILE) += elf_kexec.o machine_kexec_file.o > > > > > > > > > obj-$(CONFIG_CRASH_DUMP) += crash_dump.o > > > > > > > > > +obj-$(CONFIG_CRASH_CORE) += crash_core.o > > > > > > > > > obj-$(CONFIG_JUMP_LABEL) += jump_label.o > > > > > > > > > diff --git a/arch/riscv/kernel/crash_core.c > > > > > > > > > b/arch/riscv/kernel/crash_core.c > > > > > > > > > new file mode 100644 > > > > > > > > > index 000000000000..3e889d0ed7bd > > > > > > > > > --- /dev/null > > > > > > > > > +++ b/arch/riscv/kernel/crash_core.c > > > > > > > > > @@ -0,0 +1,23 @@ > > > > > > > > > +// SPDX-License-Identifier: GPL-2.0-only > > > > > > > > > + > > > > > > > > > +#include <linux/crash_core.h> > > > > > > > > > +#include <linux/pagemap.h> > > > > > > > > > + > > > > > > > > > +void arch_crash_save_vmcoreinfo(void) > > > > > > > > > +{ > > > > > > > > > + VMCOREINFO_NUMBER(VA_BITS); > > > > > > > > > + VMCOREINFO_NUMBER(phys_ram_base); > > > > > > > > > + > > > > > > > > > + > > > > > > > > > vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", > > > > > > > > > PAGE_OFFSET); > > > > > > > > > + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", > > > > > > > > > VMALLOC_START); > > > > > > > > > + > > > > > > > > > vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", > > > > > > > > > VMALLOC_END); > > > > > > > > > + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", > > > > > > > > > VMEMMAP_START); > > > > > > > > > + > > > > > > > > > vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", > > > > > > > > > VMEMMAP_END); > > > > > > > > > +#ifdef CONFIG_64BIT > > > > > > > > > + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", > > > > > > > > > MODULES_VADDR); > > > > > > > > > + > > > > > > > > > vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", > > > > > > > > > MODULES_END); > > > > > > > > > +#endif > > > > > > > > > + > > > > > > > > > + if (IS_ENABLED(CONFIG_64BIT)) > > > > > > > > > + > > > > > > > > > vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", > > > > > > > > > KERNEL_LINK_ADDR); > > > > > > > > Wondering why you don't put KERNEL_LINK_ADDR exporting into the above > > > > > > > > ifdeffery scope, with that you can save one line of > > > > > > > > "IS_ENABLED(CONFIG_64BIT)". > > > > > > > I followed the rule in print_vm_layout() of > > > > > > > arch/riscv/mm/init.c, which used > > > > > > > IS_ENABLED when print the value of KERNEL_LINK_ADDR. > > > > > > > > > > > > > I see. There's PAGE_OFFSET in the middle. Thanks. > > > > > > > > > > > > print_ml("lowmem", (unsigned long)PAGE_OFFSET, > > > > > > (unsigned long)high_memory) > > > > > > > > > > > > So now, do you think if it's necessary to have another > > > > > > IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()? > > > > > For which MACRO? I think current code for PAGE_OFFSET is OK. > > > > > > > >
在 2022/10/26 下午8:05, Baoquan He 写道: > Hi Xianting, > > On 10/26/22 at 05:44pm, Xianting Tian wrote: >> 在 2022/10/26 下午5:25, Conor Dooley 写道: >>> On Wed, Oct 26, 2022 at 05:08:11PM +0800, Xianting Tian wrote: >>>> Hi Palmer, Conor >>>> >>>> Is this version OK for you? >>> The weird ifdef/IS_ENABLED thing was the only comment I had. It's a bit >>> odd & I notice Baoquan brought it up too. I didn't (and won't) give you >>> a reviewed by on these patches because I don't understand the area well >>> enough. The general nitpickery seems to be sorted though. >> I checked the KERNEL_LINK_ADDR definition of riscv, it is valid for >> CONFIG_64BIT and !CONFIG_64BIT. > This series looks good to me. My only minor concern is if we can make > the arch_crash_save_vmcoreinfo() as below. I don't understand why we > have to have the CONFIG_64BIT ifdeffery and the IS_ENABLED(CONFIG_64BIT) > between two adjacent code blocks. Not sure if we are saying the same > thing. KERNEL_LINK_ADDR is valid for both CONFIG_64BIT and !CONFIG_64BIT, but MODULES_VADDR is only defined when CONFIG_64BIT. I tend to agree only remove IS_ENABLED, thanks For riscv: #ifdef CONFIG_64BIT /* Leave 2GB for kernel and BPF at the end of the address space */ #define KERNEL_LINK_ADDR (ADDRESS_SPACE_END - SZ_2G + 1) #else #define KERNEL_LINK_ADDR PAGE_OFFSET #endif > > +void arch_crash_save_vmcoreinfo(void) > +{ > + VMCOREINFO_NUMBER(VA_BITS); > + VMCOREINFO_NUMBER(phys_ram_base); > + > + vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET); > + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START); > + vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END); > + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START); > + vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END); > +#ifdef CONFIG_64BIT > + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR); > + vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END); > + vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR); > +#endif > +} > >> Maybe we can remove IS_ENABLED(CONFIG_64BIT) >> >> arch/riscv/include/asm/pgtable.h >> #define ADDRESS_SPACE_END (UL(-1)) >> #ifdef CONFIG_64BIT >> /* Leave 2GB for kernel and BPF at the end of the address space */ >> #define KERNEL_LINK_ADDR (ADDRESS_SPACE_END - SZ_2G + 1) >> #else >> #define KERNEL_LINK_ADDR PAGE_OFFSET >> #endif >> >> arch/riscv/include/asm/page.h >> #ifdef CONFIG_64BIT >> #ifdef CONFIG_MMU >> #define PAGE_OFFSET kernel_map.page_offset >> #else >> #define PAGE_OFFSET _AC(CONFIG_PAGE_OFFSET, UL) >> #endif >> /* >> * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address space so >> * define the PAGE_OFFSET value for SV39. >> */ >> #define PAGE_OFFSET_L4 _AC(0xffffaf8000000000, UL) >> #define PAGE_OFFSET_L3 _AC(0xffffffd800000000, UL) >> #else >> #define PAGE_OFFSET _AC(CONFIG_PAGE_OFFSET, UL) >> #endif /* CONFIG_64BIT */ >> >>> Thanks, >>> Conor. >>> >>>> 在 2022/10/20 下午12:40, Xianting Tian 写道: >>>>> 在 2022/10/20 上午11:05, Baoquan He 写道: >>>>>> On 10/20/22 at 10:17am, Xianting Tian wrote: >>>>>>> 在 2022/10/20 上午10:08, Baoquan He 写道: >>>>>>>> On 10/19/22 at 06:36pm, Xianting Tian wrote: >>>>>>>>> Add arch_crash_save_vmcoreinfo(), which exports VM >>>>>>>>> layout(MODULES, VMALLOC, >>>>>>>>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram >>>>>>>>> base for vmcore. >>>>>>>>> >>>>>>>>> Default pagetable levels and PAGE_OFFSET aren't same for >>>>>>>>> different kernel >>>>>>>>> version as below. For pagetable levels, it sets sv57 by >>>>>>>>> default and falls >>>>>>>>> back to setting sv48 at boot time if sv57 is not >>>>>>>>> supported by the hardware. >>>>>>>>> >>>>>>>>> For ram base, the default value is 0x80200000 for qemu >>>>>>>>> riscv64 env and, >>>>>>>>> for example, is 0x200000 on the XuanTie 910 CPU. >>>>>>>>> >>>>>>>>> * Linux Kernel 5.18 ~ >>>>>>>>> * PGTABLE_LEVELS = 5 >>>>>>>>> * PAGE_OFFSET = 0xff60000000000000 >>>>>>>>> * Linux Kernel 5.17 ~ >>>>>>>>> * PGTABLE_LEVELS = 4 >>>>>>>>> * PAGE_OFFSET = 0xffffaf8000000000 >>>>>>>>> * Linux Kernel 4.19 ~ >>>>>>>>> * PGTABLE_LEVELS = 3 >>>>>>>>> * PAGE_OFFSET = 0xffffffe000000000 >>>>>>>>> >>>>>>>>> Since these configurations change from time to time and >>>>>>>>> version to version, >>>>>>>>> it is preferable to export them via vmcoreinfo than to >>>>>>>>> change the crash's >>>>>>>>> code frequently, it can simplify the development of crash tool. >>>>>>>>> >>>>>>>>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> >>>>>>>>> --- >>>>>>>>> arch/riscv/kernel/Makefile | 1 + >>>>>>>>> arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++ >>>>>>>>> 2 files changed, 24 insertions(+) >>>>>>>>> create mode 100644 arch/riscv/kernel/crash_core.c >>>>>>>>> >>>>>>>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile >>>>>>>>> index db6e4b1294ba..4cf303a779ab 100644 >>>>>>>>> --- a/arch/riscv/kernel/Makefile >>>>>>>>> +++ b/arch/riscv/kernel/Makefile >>>>>>>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB) += kgdb.o >>>>>>>>> obj-$(CONFIG_KEXEC_CORE) += kexec_relocate.o >>>>>>>>> crash_save_regs.o machine_kexec.o >>>>>>>>> obj-$(CONFIG_KEXEC_FILE) += elf_kexec.o machine_kexec_file.o >>>>>>>>> obj-$(CONFIG_CRASH_DUMP) += crash_dump.o >>>>>>>>> +obj-$(CONFIG_CRASH_CORE) += crash_core.o >>>>>>>>> obj-$(CONFIG_JUMP_LABEL) += jump_label.o >>>>>>>>> diff --git a/arch/riscv/kernel/crash_core.c >>>>>>>>> b/arch/riscv/kernel/crash_core.c >>>>>>>>> new file mode 100644 >>>>>>>>> index 000000000000..3e889d0ed7bd >>>>>>>>> --- /dev/null >>>>>>>>> +++ b/arch/riscv/kernel/crash_core.c >>>>>>>>> @@ -0,0 +1,23 @@ >>>>>>>>> +// SPDX-License-Identifier: GPL-2.0-only >>>>>>>>> + >>>>>>>>> +#include <linux/crash_core.h> >>>>>>>>> +#include <linux/pagemap.h> >>>>>>>>> + >>>>>>>>> +void arch_crash_save_vmcoreinfo(void) >>>>>>>>> +{ >>>>>>>>> + VMCOREINFO_NUMBER(VA_BITS); >>>>>>>>> + VMCOREINFO_NUMBER(phys_ram_base); >>>>>>>>> + >>>>>>>>> + >>>>>>>>> vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", >>>>>>>>> PAGE_OFFSET); >>>>>>>>> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", >>>>>>>>> VMALLOC_START); >>>>>>>>> + >>>>>>>>> vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", >>>>>>>>> VMALLOC_END); >>>>>>>>> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", >>>>>>>>> VMEMMAP_START); >>>>>>>>> + >>>>>>>>> vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", >>>>>>>>> VMEMMAP_END); >>>>>>>>> +#ifdef CONFIG_64BIT >>>>>>>>> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", >>>>>>>>> MODULES_VADDR); >>>>>>>>> + >>>>>>>>> vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", >>>>>>>>> MODULES_END); >>>>>>>>> +#endif >>>>>>>>> + >>>>>>>>> + if (IS_ENABLED(CONFIG_64BIT)) >>>>>>>>> + >>>>>>>>> vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", >>>>>>>>> KERNEL_LINK_ADDR); >>>>>>>> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above >>>>>>>> ifdeffery scope, with that you can save one line of >>>>>>>> "IS_ENABLED(CONFIG_64BIT)". >>>>>>> I followed the rule in print_vm_layout() of >>>>>>> arch/riscv/mm/init.c, which used >>>>>>> IS_ENABLED when print the value of KERNEL_LINK_ADDR. >>>>>>> >>>>>> I see. There's PAGE_OFFSET in the middle. Thanks. >>>>>> >>>>>> print_ml("lowmem", (unsigned long)PAGE_OFFSET, >>>>>> (unsigned long)high_memory) >>>>>> >>>>>> So now, do you think if it's necessary to have another >>>>>> IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()? >>>>> For which MACRO? I think current code for PAGE_OFFSET is OK. >>>>>
在 2022/10/26 下午9:47, Conor Dooley 写道: > On Wed, Oct 26, 2022 at 08:05:41PM +0800, Baoquan He wrote: >> Hi Xianting, >> >> On 10/26/22 at 05:44pm, Xianting Tian wrote: >>> 在 2022/10/26 下午5:25, Conor Dooley 写道: >>>> On Wed, Oct 26, 2022 at 05:08:11PM +0800, Xianting Tian wrote: >>>>> Hi Palmer, Conor >>>>> >>>>> Is this version OK for you? >>>> The weird ifdef/IS_ENABLED thing was the only comment I had. It's a bit >>>> odd & I notice Baoquan brought it up too. I didn't (and won't) give you >>>> a reviewed by on these patches because I don't understand the area well >>>> enough. The general nitpickery seems to be sorted though. >>> I checked the KERNEL_LINK_ADDR definition of riscv, it is valid for >>> CONFIG_64BIT and !CONFIG_64BIT. >> This series looks good to me. My only minor concern is if we can make >> the arch_crash_save_vmcoreinfo() as below. I don't understand why we >> have to have the CONFIG_64BIT ifdeffery and the IS_ENABLED(CONFIG_64BIT) >> between two adjacent code blocks. Not sure if we are saying the same >> thing. > I think we can just go and drop the IS_ENABLED(). From looking at it > last time, one bit is compileable (but not usable) for !64BIT and the > other isn't hence the IS_ENABLED(). I think it would make sense to drop > the IS_ENABLED() - I don't think we're too likely to hit some compile > testing edge cases that IS_ENABLED() would help with & only having one > makes the code look a lot less odd and a lot more intentional. thanks, I will send V5 patch for review. > >> +void arch_crash_save_vmcoreinfo(void) >> +{ >> + VMCOREINFO_NUMBER(VA_BITS); >> + VMCOREINFO_NUMBER(phys_ram_base); >> + >> + vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET); >> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START); >> + vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END); >> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START); >> + vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END); >> +#ifdef CONFIG_64BIT >> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR); >> + vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END); >> + vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR); >> +#endif >> +} >> >>> Maybe we can remove IS_ENABLED(CONFIG_64BIT) >>> >>> arch/riscv/include/asm/pgtable.h >>> #define ADDRESS_SPACE_END (UL(-1)) >>> #ifdef CONFIG_64BIT >>> /* Leave 2GB for kernel and BPF at the end of the address space */ >>> #define KERNEL_LINK_ADDR (ADDRESS_SPACE_END - SZ_2G + 1) >>> #else >>> #define KERNEL_LINK_ADDR PAGE_OFFSET >>> #endif >>> >>> arch/riscv/include/asm/page.h >>> #ifdef CONFIG_64BIT >>> #ifdef CONFIG_MMU >>> #define PAGE_OFFSET kernel_map.page_offset >>> #else >>> #define PAGE_OFFSET _AC(CONFIG_PAGE_OFFSET, UL) >>> #endif >>> /* >>> * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address space so >>> * define the PAGE_OFFSET value for SV39. >>> */ >>> #define PAGE_OFFSET_L4 _AC(0xffffaf8000000000, UL) >>> #define PAGE_OFFSET_L3 _AC(0xffffffd800000000, UL) >>> #else >>> #define PAGE_OFFSET _AC(CONFIG_PAGE_OFFSET, UL) >>> #endif /* CONFIG_64BIT */ >>> >>>> Thanks, >>>> Conor. >>>> >>>>> 在 2022/10/20 下午12:40, Xianting Tian 写道: >>>>>> 在 2022/10/20 上午11:05, Baoquan He 写道: >>>>>>> On 10/20/22 at 10:17am, Xianting Tian wrote: >>>>>>>> 在 2022/10/20 上午10:08, Baoquan He 写道: >>>>>>>>> On 10/19/22 at 06:36pm, Xianting Tian wrote: >>>>>>>>>> Add arch_crash_save_vmcoreinfo(), which exports VM >>>>>>>>>> layout(MODULES, VMALLOC, >>>>>>>>>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram >>>>>>>>>> base for vmcore. >>>>>>>>>> >>>>>>>>>> Default pagetable levels and PAGE_OFFSET aren't same for >>>>>>>>>> different kernel >>>>>>>>>> version as below. For pagetable levels, it sets sv57 by >>>>>>>>>> default and falls >>>>>>>>>> back to setting sv48 at boot time if sv57 is not >>>>>>>>>> supported by the hardware. >>>>>>>>>> >>>>>>>>>> For ram base, the default value is 0x80200000 for qemu >>>>>>>>>> riscv64 env and, >>>>>>>>>> for example, is 0x200000 on the XuanTie 910 CPU. >>>>>>>>>> >>>>>>>>>> * Linux Kernel 5.18 ~ >>>>>>>>>> * PGTABLE_LEVELS = 5 >>>>>>>>>> * PAGE_OFFSET = 0xff60000000000000 >>>>>>>>>> * Linux Kernel 5.17 ~ >>>>>>>>>> * PGTABLE_LEVELS = 4 >>>>>>>>>> * PAGE_OFFSET = 0xffffaf8000000000 >>>>>>>>>> * Linux Kernel 4.19 ~ >>>>>>>>>> * PGTABLE_LEVELS = 3 >>>>>>>>>> * PAGE_OFFSET = 0xffffffe000000000 >>>>>>>>>> >>>>>>>>>> Since these configurations change from time to time and >>>>>>>>>> version to version, >>>>>>>>>> it is preferable to export them via vmcoreinfo than to >>>>>>>>>> change the crash's >>>>>>>>>> code frequently, it can simplify the development of crash tool. >>>>>>>>>> >>>>>>>>>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> >>>>>>>>>> --- >>>>>>>>>> arch/riscv/kernel/Makefile | 1 + >>>>>>>>>> arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++ >>>>>>>>>> 2 files changed, 24 insertions(+) >>>>>>>>>> create mode 100644 arch/riscv/kernel/crash_core.c >>>>>>>>>> >>>>>>>>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile >>>>>>>>>> index db6e4b1294ba..4cf303a779ab 100644 >>>>>>>>>> --- a/arch/riscv/kernel/Makefile >>>>>>>>>> +++ b/arch/riscv/kernel/Makefile >>>>>>>>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB) += kgdb.o >>>>>>>>>> obj-$(CONFIG_KEXEC_CORE) += kexec_relocate.o >>>>>>>>>> crash_save_regs.o machine_kexec.o >>>>>>>>>> obj-$(CONFIG_KEXEC_FILE) += elf_kexec.o machine_kexec_file.o >>>>>>>>>> obj-$(CONFIG_CRASH_DUMP) += crash_dump.o >>>>>>>>>> +obj-$(CONFIG_CRASH_CORE) += crash_core.o >>>>>>>>>> obj-$(CONFIG_JUMP_LABEL) += jump_label.o >>>>>>>>>> diff --git a/arch/riscv/kernel/crash_core.c >>>>>>>>>> b/arch/riscv/kernel/crash_core.c >>>>>>>>>> new file mode 100644 >>>>>>>>>> index 000000000000..3e889d0ed7bd >>>>>>>>>> --- /dev/null >>>>>>>>>> +++ b/arch/riscv/kernel/crash_core.c >>>>>>>>>> @@ -0,0 +1,23 @@ >>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0-only >>>>>>>>>> + >>>>>>>>>> +#include <linux/crash_core.h> >>>>>>>>>> +#include <linux/pagemap.h> >>>>>>>>>> + >>>>>>>>>> +void arch_crash_save_vmcoreinfo(void) >>>>>>>>>> +{ >>>>>>>>>> + VMCOREINFO_NUMBER(VA_BITS); >>>>>>>>>> + VMCOREINFO_NUMBER(phys_ram_base); >>>>>>>>>> + >>>>>>>>>> + >>>>>>>>>> vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", >>>>>>>>>> PAGE_OFFSET); >>>>>>>>>> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", >>>>>>>>>> VMALLOC_START); >>>>>>>>>> + >>>>>>>>>> vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", >>>>>>>>>> VMALLOC_END); >>>>>>>>>> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", >>>>>>>>>> VMEMMAP_START); >>>>>>>>>> + >>>>>>>>>> vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", >>>>>>>>>> VMEMMAP_END); >>>>>>>>>> +#ifdef CONFIG_64BIT >>>>>>>>>> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", >>>>>>>>>> MODULES_VADDR); >>>>>>>>>> + >>>>>>>>>> vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", >>>>>>>>>> MODULES_END); >>>>>>>>>> +#endif >>>>>>>>>> + >>>>>>>>>> + if (IS_ENABLED(CONFIG_64BIT)) >>>>>>>>>> + >>>>>>>>>> vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", >>>>>>>>>> KERNEL_LINK_ADDR); >>>>>>>>> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above >>>>>>>>> ifdeffery scope, with that you can save one line of >>>>>>>>> "IS_ENABLED(CONFIG_64BIT)". >>>>>>>> I followed the rule in print_vm_layout() of >>>>>>>> arch/riscv/mm/init.c, which used >>>>>>>> IS_ENABLED when print the value of KERNEL_LINK_ADDR. >>>>>>>> >>>>>>> I see. There's PAGE_OFFSET in the middle. Thanks. >>>>>>> >>>>>>> print_ml("lowmem", (unsigned long)PAGE_OFFSET, >>>>>>> (unsigned long)high_memory) >>>>>>> >>>>>>> So now, do you think if it's necessary to have another >>>>>>> IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()? >>>>>> For which MACRO? I think current code for PAGE_OFFSET is OK. >>>>>>
On 10/26/22 at 02:47pm, Conor Dooley wrote: > On Wed, Oct 26, 2022 at 08:05:41PM +0800, Baoquan He wrote: > > Hi Xianting, > > > > On 10/26/22 at 05:44pm, Xianting Tian wrote: > > > > > > 在 2022/10/26 下午5:25, Conor Dooley 写道: > > > > On Wed, Oct 26, 2022 at 05:08:11PM +0800, Xianting Tian wrote: > > > > > Hi Palmer, Conor > > > > > > > > > > Is this version OK for you? > > > > The weird ifdef/IS_ENABLED thing was the only comment I had. It's a bit > > > > odd & I notice Baoquan brought it up too. I didn't (and won't) give you > > > > a reviewed by on these patches because I don't understand the area well > > > > enough. The general nitpickery seems to be sorted though. > > > > > > I checked the KERNEL_LINK_ADDR definition of riscv, it is valid for > > > CONFIG_64BIT and !CONFIG_64BIT. > > > > This series looks good to me. My only minor concern is if we can make > > the arch_crash_save_vmcoreinfo() as below. I don't understand why we > > have to have the CONFIG_64BIT ifdeffery and the IS_ENABLED(CONFIG_64BIT) > > between two adjacent code blocks. Not sure if we are saying the same > > thing. > > I think we can just go and drop the IS_ENABLED(). From looking at it > last time, one bit is compileable (but not usable) for !64BIT and the > other isn't hence the IS_ENABLED(). I think it would make sense to drop > the IS_ENABLED() - I don't think we're too likely to hit some compile > testing edge cases that IS_ENABLED() would help with & only having one > makes the code look a lot less odd and a lot more intentional. I check risc-v code again, and agree we can drop the IS_ENABLED checking to export KERNEL_LINK_ADDR anyway. We can surely deduce KERNEL_LINK_ADDR in userspace e.g makedumpfile/Crash, while it seems no harm to get it from the vmcoreinfo directly. As for the difference between "#ifdef CONFIG_64BIT" and "if (IS_ENABLED(CONFIG_64BIT))", I haven't got what's the Xianting's point. Below is the IS_ENABLED definition in include/linux/kconfig.h, it's truly different than #ifdef, while the change we are discussing here is not related. /* * IS_ENABLED(CONFIG_FOO) evaluates to 1 if CONFIG_FOO is set to 'y' or 'm', * 0 otherwise. Note that CONFIG_FOO=y results in "#define CONFIG_FOO 1" in * autoconf.h, while CONFIG_FOO=m results in "#define CONFIG_FOO_MODULE 1". */ #define IS_ENABLED(option) __or(IS_BUILTIN(option), IS_MODULE(option)) > > > > > +void arch_crash_save_vmcoreinfo(void) > > +{ > > + VMCOREINFO_NUMBER(VA_BITS); > > + VMCOREINFO_NUMBER(phys_ram_base); > > + > > + vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET); > > + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START); > > + vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END); > > + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START); > > + vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END); > > +#ifdef CONFIG_64BIT > > + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR); > > + vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END); > > + vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR); > > +#endif > > +} > > > > > > > > Maybe we can remove IS_ENABLED(CONFIG_64BIT) > > > > > > arch/riscv/include/asm/pgtable.h > > > #define ADDRESS_SPACE_END (UL(-1)) > > > #ifdef CONFIG_64BIT > > > /* Leave 2GB for kernel and BPF at the end of the address space */ > > > #define KERNEL_LINK_ADDR (ADDRESS_SPACE_END - SZ_2G + 1) > > > #else > > > #define KERNEL_LINK_ADDR PAGE_OFFSET > > > #endif > > > > > > arch/riscv/include/asm/page.h > > > #ifdef CONFIG_64BIT > > > #ifdef CONFIG_MMU > > > #define PAGE_OFFSET kernel_map.page_offset > > > #else > > > #define PAGE_OFFSET _AC(CONFIG_PAGE_OFFSET, UL) > > > #endif > > > /* > > > * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address space so > > > * define the PAGE_OFFSET value for SV39. > > > */ > > > #define PAGE_OFFSET_L4 _AC(0xffffaf8000000000, UL) > > > #define PAGE_OFFSET_L3 _AC(0xffffffd800000000, UL) > > > #else > > > #define PAGE_OFFSET _AC(CONFIG_PAGE_OFFSET, UL) > > > #endif /* CONFIG_64BIT */ > > > > > > > > > > > Thanks, > > > > Conor. > > > > > > > > > 在 2022/10/20 下午12:40, Xianting Tian 写道: > > > > > > 在 2022/10/20 上午11:05, Baoquan He 写道: > > > > > > > On 10/20/22 at 10:17am, Xianting Tian wrote: > > > > > > > > 在 2022/10/20 上午10:08, Baoquan He 写道: > > > > > > > > > On 10/19/22 at 06:36pm, Xianting Tian wrote: > > > > > > > > > > Add arch_crash_save_vmcoreinfo(), which exports VM > > > > > > > > > > layout(MODULES, VMALLOC, > > > > > > > > > > VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram > > > > > > > > > > base for vmcore. > > > > > > > > > > > > > > > > > > > > Default pagetable levels and PAGE_OFFSET aren't same for > > > > > > > > > > different kernel > > > > > > > > > > version as below. For pagetable levels, it sets sv57 by > > > > > > > > > > default and falls > > > > > > > > > > back to setting sv48 at boot time if sv57 is not > > > > > > > > > > supported by the hardware. > > > > > > > > > > > > > > > > > > > > For ram base, the default value is 0x80200000 for qemu > > > > > > > > > > riscv64 env and, > > > > > > > > > > for example, is 0x200000 on the XuanTie 910 CPU. > > > > > > > > > > > > > > > > > > > > * Linux Kernel 5.18 ~ > > > > > > > > > > * PGTABLE_LEVELS = 5 > > > > > > > > > > * PAGE_OFFSET = 0xff60000000000000 > > > > > > > > > > * Linux Kernel 5.17 ~ > > > > > > > > > > * PGTABLE_LEVELS = 4 > > > > > > > > > > * PAGE_OFFSET = 0xffffaf8000000000 > > > > > > > > > > * Linux Kernel 4.19 ~ > > > > > > > > > > * PGTABLE_LEVELS = 3 > > > > > > > > > > * PAGE_OFFSET = 0xffffffe000000000 > > > > > > > > > > > > > > > > > > > > Since these configurations change from time to time and > > > > > > > > > > version to version, > > > > > > > > > > it is preferable to export them via vmcoreinfo than to > > > > > > > > > > change the crash's > > > > > > > > > > code frequently, it can simplify the development of crash tool. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> > > > > > > > > > > --- > > > > > > > > > > arch/riscv/kernel/Makefile | 1 + > > > > > > > > > > arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++ > > > > > > > > > > 2 files changed, 24 insertions(+) > > > > > > > > > > create mode 100644 arch/riscv/kernel/crash_core.c > > > > > > > > > > > > > > > > > > > > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile > > > > > > > > > > index db6e4b1294ba..4cf303a779ab 100644 > > > > > > > > > > --- a/arch/riscv/kernel/Makefile > > > > > > > > > > +++ b/arch/riscv/kernel/Makefile > > > > > > > > > > @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB) += kgdb.o > > > > > > > > > > obj-$(CONFIG_KEXEC_CORE) += kexec_relocate.o > > > > > > > > > > crash_save_regs.o machine_kexec.o > > > > > > > > > > obj-$(CONFIG_KEXEC_FILE) += elf_kexec.o machine_kexec_file.o > > > > > > > > > > obj-$(CONFIG_CRASH_DUMP) += crash_dump.o > > > > > > > > > > +obj-$(CONFIG_CRASH_CORE) += crash_core.o > > > > > > > > > > obj-$(CONFIG_JUMP_LABEL) += jump_label.o > > > > > > > > > > diff --git a/arch/riscv/kernel/crash_core.c > > > > > > > > > > b/arch/riscv/kernel/crash_core.c > > > > > > > > > > new file mode 100644 > > > > > > > > > > index 000000000000..3e889d0ed7bd > > > > > > > > > > --- /dev/null > > > > > > > > > > +++ b/arch/riscv/kernel/crash_core.c > > > > > > > > > > @@ -0,0 +1,23 @@ > > > > > > > > > > +// SPDX-License-Identifier: GPL-2.0-only > > > > > > > > > > + > > > > > > > > > > +#include <linux/crash_core.h> > > > > > > > > > > +#include <linux/pagemap.h> > > > > > > > > > > + > > > > > > > > > > +void arch_crash_save_vmcoreinfo(void) > > > > > > > > > > +{ > > > > > > > > > > + VMCOREINFO_NUMBER(VA_BITS); > > > > > > > > > > + VMCOREINFO_NUMBER(phys_ram_base); > > > > > > > > > > + > > > > > > > > > > + > > > > > > > > > > vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", > > > > > > > > > > PAGE_OFFSET); > > > > > > > > > > + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", > > > > > > > > > > VMALLOC_START); > > > > > > > > > > + > > > > > > > > > > vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", > > > > > > > > > > VMALLOC_END); > > > > > > > > > > + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", > > > > > > > > > > VMEMMAP_START); > > > > > > > > > > + > > > > > > > > > > vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", > > > > > > > > > > VMEMMAP_END); > > > > > > > > > > +#ifdef CONFIG_64BIT > > > > > > > > > > + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", > > > > > > > > > > MODULES_VADDR); > > > > > > > > > > + > > > > > > > > > > vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", > > > > > > > > > > MODULES_END); > > > > > > > > > > +#endif > > > > > > > > > > + > > > > > > > > > > + if (IS_ENABLED(CONFIG_64BIT)) > > > > > > > > > > + > > > > > > > > > > vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", > > > > > > > > > > KERNEL_LINK_ADDR); > > > > > > > > > Wondering why you don't put KERNEL_LINK_ADDR exporting into the above > > > > > > > > > ifdeffery scope, with that you can save one line of > > > > > > > > > "IS_ENABLED(CONFIG_64BIT)". > > > > > > > > I followed the rule in print_vm_layout() of > > > > > > > > arch/riscv/mm/init.c, which used > > > > > > > > IS_ENABLED when print the value of KERNEL_LINK_ADDR. > > > > > > > > > > > > > > > I see. There's PAGE_OFFSET in the middle. Thanks. > > > > > > > > > > > > > > print_ml("lowmem", (unsigned long)PAGE_OFFSET, > > > > > > > (unsigned long)high_memory) > > > > > > > > > > > > > > So now, do you think if it's necessary to have another > > > > > > > IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()? > > > > > > For which MACRO? I think current code for PAGE_OFFSET is OK. > > > > > > > > > > > >
在 2022/10/31 下午4:57, Baoquan He 写道: > On 10/26/22 at 02:47pm, Conor Dooley wrote: >> On Wed, Oct 26, 2022 at 08:05:41PM +0800, Baoquan He wrote: >>> Hi Xianting, >>> >>> On 10/26/22 at 05:44pm, Xianting Tian wrote: >>>> 在 2022/10/26 下午5:25, Conor Dooley 写道: >>>>> On Wed, Oct 26, 2022 at 05:08:11PM +0800, Xianting Tian wrote: >>>>>> Hi Palmer, Conor >>>>>> >>>>>> Is this version OK for you? >>>>> The weird ifdef/IS_ENABLED thing was the only comment I had. It's a bit >>>>> odd & I notice Baoquan brought it up too. I didn't (and won't) give you >>>>> a reviewed by on these patches because I don't understand the area well >>>>> enough. The general nitpickery seems to be sorted though. >>>> I checked the KERNEL_LINK_ADDR definition of riscv, it is valid for >>>> CONFIG_64BIT and !CONFIG_64BIT. >>> This series looks good to me. My only minor concern is if we can make >>> the arch_crash_save_vmcoreinfo() as below. I don't understand why we >>> have to have the CONFIG_64BIT ifdeffery and the IS_ENABLED(CONFIG_64BIT) >>> between two adjacent code blocks. Not sure if we are saying the same >>> thing. >> I think we can just go and drop the IS_ENABLED(). From looking at it >> last time, one bit is compileable (but not usable) for !64BIT and the >> other isn't hence the IS_ENABLED(). I think it would make sense to drop >> the IS_ENABLED() - I don't think we're too likely to hit some compile >> testing edge cases that IS_ENABLED() would help with & only having one >> makes the code look a lot less odd and a lot more intentional. > I check risc-v code again, and agree we can drop the IS_ENABLED checking > to export KERNEL_LINK_ADDR anyway. We can surely deduce > KERNEL_LINK_ADDR in userspace e.g makedumpfile/Crash, while it seems no > harm to get it from the vmcoreinfo directly. thanks Baoquan for the confirm, please help give the Revied-by and promote the patch set to be applied to Linux 6.1 :) > > As for the difference between "#ifdef CONFIG_64BIT" and > "if (IS_ENABLED(CONFIG_64BIT))", I haven't got what's the Xianting's > point. Below is the IS_ENABLED definition in include/linux/kconfig.h, > it's truly different than #ifdef, while the change we are discussing > here is not related. > > /* > * IS_ENABLED(CONFIG_FOO) evaluates to 1 if CONFIG_FOO is set to 'y' or 'm', > * 0 otherwise. Note that CONFIG_FOO=y results in "#define CONFIG_FOO 1" in > * autoconf.h, while CONFIG_FOO=m results in "#define CONFIG_FOO_MODULE 1". > */ > #define IS_ENABLED(option) __or(IS_BUILTIN(option), IS_MODULE(option)) > >>> +void arch_crash_save_vmcoreinfo(void) >>> +{ >>> + VMCOREINFO_NUMBER(VA_BITS); >>> + VMCOREINFO_NUMBER(phys_ram_base); >>> + >>> + vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET); >>> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START); >>> + vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END); >>> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START); >>> + vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END); >>> +#ifdef CONFIG_64BIT >>> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR); >>> + vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END); >>> + vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR); >>> +#endif >>> +} >>> >>>> Maybe we can remove IS_ENABLED(CONFIG_64BIT) >>>> >>>> arch/riscv/include/asm/pgtable.h >>>> #define ADDRESS_SPACE_END (UL(-1)) >>>> #ifdef CONFIG_64BIT >>>> /* Leave 2GB for kernel and BPF at the end of the address space */ >>>> #define KERNEL_LINK_ADDR (ADDRESS_SPACE_END - SZ_2G + 1) >>>> #else >>>> #define KERNEL_LINK_ADDR PAGE_OFFSET >>>> #endif >>>> >>>> arch/riscv/include/asm/page.h >>>> #ifdef CONFIG_64BIT >>>> #ifdef CONFIG_MMU >>>> #define PAGE_OFFSET kernel_map.page_offset >>>> #else >>>> #define PAGE_OFFSET _AC(CONFIG_PAGE_OFFSET, UL) >>>> #endif >>>> /* >>>> * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address space so >>>> * define the PAGE_OFFSET value for SV39. >>>> */ >>>> #define PAGE_OFFSET_L4 _AC(0xffffaf8000000000, UL) >>>> #define PAGE_OFFSET_L3 _AC(0xffffffd800000000, UL) >>>> #else >>>> #define PAGE_OFFSET _AC(CONFIG_PAGE_OFFSET, UL) >>>> #endif /* CONFIG_64BIT */ >>>> >>>>> Thanks, >>>>> Conor. >>>>> >>>>>> 在 2022/10/20 下午12:40, Xianting Tian 写道: >>>>>>> 在 2022/10/20 上午11:05, Baoquan He 写道: >>>>>>>> On 10/20/22 at 10:17am, Xianting Tian wrote: >>>>>>>>> 在 2022/10/20 上午10:08, Baoquan He 写道: >>>>>>>>>> On 10/19/22 at 06:36pm, Xianting Tian wrote: >>>>>>>>>>> Add arch_crash_save_vmcoreinfo(), which exports VM >>>>>>>>>>> layout(MODULES, VMALLOC, >>>>>>>>>>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram >>>>>>>>>>> base for vmcore. >>>>>>>>>>> >>>>>>>>>>> Default pagetable levels and PAGE_OFFSET aren't same for >>>>>>>>>>> different kernel >>>>>>>>>>> version as below. For pagetable levels, it sets sv57 by >>>>>>>>>>> default and falls >>>>>>>>>>> back to setting sv48 at boot time if sv57 is not >>>>>>>>>>> supported by the hardware. >>>>>>>>>>> >>>>>>>>>>> For ram base, the default value is 0x80200000 for qemu >>>>>>>>>>> riscv64 env and, >>>>>>>>>>> for example, is 0x200000 on the XuanTie 910 CPU. >>>>>>>>>>> >>>>>>>>>>> * Linux Kernel 5.18 ~ >>>>>>>>>>> * PGTABLE_LEVELS = 5 >>>>>>>>>>> * PAGE_OFFSET = 0xff60000000000000 >>>>>>>>>>> * Linux Kernel 5.17 ~ >>>>>>>>>>> * PGTABLE_LEVELS = 4 >>>>>>>>>>> * PAGE_OFFSET = 0xffffaf8000000000 >>>>>>>>>>> * Linux Kernel 4.19 ~ >>>>>>>>>>> * PGTABLE_LEVELS = 3 >>>>>>>>>>> * PAGE_OFFSET = 0xffffffe000000000 >>>>>>>>>>> >>>>>>>>>>> Since these configurations change from time to time and >>>>>>>>>>> version to version, >>>>>>>>>>> it is preferable to export them via vmcoreinfo than to >>>>>>>>>>> change the crash's >>>>>>>>>>> code frequently, it can simplify the development of crash tool. >>>>>>>>>>> >>>>>>>>>>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> >>>>>>>>>>> --- >>>>>>>>>>> arch/riscv/kernel/Makefile | 1 + >>>>>>>>>>> arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++ >>>>>>>>>>> 2 files changed, 24 insertions(+) >>>>>>>>>>> create mode 100644 arch/riscv/kernel/crash_core.c >>>>>>>>>>> >>>>>>>>>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile >>>>>>>>>>> index db6e4b1294ba..4cf303a779ab 100644 >>>>>>>>>>> --- a/arch/riscv/kernel/Makefile >>>>>>>>>>> +++ b/arch/riscv/kernel/Makefile >>>>>>>>>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB) += kgdb.o >>>>>>>>>>> obj-$(CONFIG_KEXEC_CORE) += kexec_relocate.o >>>>>>>>>>> crash_save_regs.o machine_kexec.o >>>>>>>>>>> obj-$(CONFIG_KEXEC_FILE) += elf_kexec.o machine_kexec_file.o >>>>>>>>>>> obj-$(CONFIG_CRASH_DUMP) += crash_dump.o >>>>>>>>>>> +obj-$(CONFIG_CRASH_CORE) += crash_core.o >>>>>>>>>>> obj-$(CONFIG_JUMP_LABEL) += jump_label.o >>>>>>>>>>> diff --git a/arch/riscv/kernel/crash_core.c >>>>>>>>>>> b/arch/riscv/kernel/crash_core.c >>>>>>>>>>> new file mode 100644 >>>>>>>>>>> index 000000000000..3e889d0ed7bd >>>>>>>>>>> --- /dev/null >>>>>>>>>>> +++ b/arch/riscv/kernel/crash_core.c >>>>>>>>>>> @@ -0,0 +1,23 @@ >>>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0-only >>>>>>>>>>> + >>>>>>>>>>> +#include <linux/crash_core.h> >>>>>>>>>>> +#include <linux/pagemap.h> >>>>>>>>>>> + >>>>>>>>>>> +void arch_crash_save_vmcoreinfo(void) >>>>>>>>>>> +{ >>>>>>>>>>> + VMCOREINFO_NUMBER(VA_BITS); >>>>>>>>>>> + VMCOREINFO_NUMBER(phys_ram_base); >>>>>>>>>>> + >>>>>>>>>>> + >>>>>>>>>>> vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", >>>>>>>>>>> PAGE_OFFSET); >>>>>>>>>>> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", >>>>>>>>>>> VMALLOC_START); >>>>>>>>>>> + >>>>>>>>>>> vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", >>>>>>>>>>> VMALLOC_END); >>>>>>>>>>> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", >>>>>>>>>>> VMEMMAP_START); >>>>>>>>>>> + >>>>>>>>>>> vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", >>>>>>>>>>> VMEMMAP_END); >>>>>>>>>>> +#ifdef CONFIG_64BIT >>>>>>>>>>> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", >>>>>>>>>>> MODULES_VADDR); >>>>>>>>>>> + >>>>>>>>>>> vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", >>>>>>>>>>> MODULES_END); >>>>>>>>>>> +#endif >>>>>>>>>>> + >>>>>>>>>>> + if (IS_ENABLED(CONFIG_64BIT)) >>>>>>>>>>> + >>>>>>>>>>> vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", >>>>>>>>>>> KERNEL_LINK_ADDR); >>>>>>>>>> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above >>>>>>>>>> ifdeffery scope, with that you can save one line of >>>>>>>>>> "IS_ENABLED(CONFIG_64BIT)". >>>>>>>>> I followed the rule in print_vm_layout() of >>>>>>>>> arch/riscv/mm/init.c, which used >>>>>>>>> IS_ENABLED when print the value of KERNEL_LINK_ADDR. >>>>>>>>> >>>>>>>> I see. There's PAGE_OFFSET in the middle. Thanks. >>>>>>>> >>>>>>>> print_ml("lowmem", (unsigned long)PAGE_OFFSET, >>>>>>>> (unsigned long)high_memory) >>>>>>>> >>>>>>>> So now, do you think if it's necessary to have another >>>>>>>> IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()? >>>>>>> For which MACRO? I think current code for PAGE_OFFSET is OK. >>>>>>>
diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile index db6e4b1294ba..4cf303a779ab 100644 --- a/arch/riscv/kernel/Makefile +++ b/arch/riscv/kernel/Makefile @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB) += kgdb.o obj-$(CONFIG_KEXEC_CORE) += kexec_relocate.o crash_save_regs.o machine_kexec.o obj-$(CONFIG_KEXEC_FILE) += elf_kexec.o machine_kexec_file.o obj-$(CONFIG_CRASH_DUMP) += crash_dump.o +obj-$(CONFIG_CRASH_CORE) += crash_core.o obj-$(CONFIG_JUMP_LABEL) += jump_label.o diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c new file mode 100644 index 000000000000..3e889d0ed7bd --- /dev/null +++ b/arch/riscv/kernel/crash_core.c @@ -0,0 +1,23 @@ +// SPDX-License-Identifier: GPL-2.0-only + +#include <linux/crash_core.h> +#include <linux/pagemap.h> + +void arch_crash_save_vmcoreinfo(void) +{ + VMCOREINFO_NUMBER(VA_BITS); + VMCOREINFO_NUMBER(phys_ram_base); + + vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET); + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START); + vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END); + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START); + vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END); +#ifdef CONFIG_64BIT + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR); + vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END); +#endif + + if (IS_ENABLED(CONFIG_64BIT)) + vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR); +}