2:48 a.m.
As disscussed in below patch set, the patch of 'describe VMCOREINFO export in
Documentation'
need to update according to Bagas's comments.
https://lore.kernel.org/linux-riscv/22AAF52E-8CC8-4D11-99CB-88DE4D113444@...
As others patches in above patch set already applied, so this patch set only contains
below two
patches.
------
Changes:
Fix commit message in patch 2: use "Document these RISCV64 exports above"
instead of
"This patch just add the description of VMCOREINFO export for RISCV64."
Xianting Tian (2):
RISC-V: Add arch_crash_save_vmcoreinfo support
Documentation: kdump: describe VMCOREINFO export for RISCV64
.../admin-guide/kdump/vmcoreinfo.rst | 31 +++++++++++++++++++
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/crash_core.c | 29 +++++++++++++++++
3 files changed, 61 insertions(+)
create mode 100644 arch/riscv/kernel/crash_core.c
--
2.17.1
2:48 a.m.
New subject: [PATCH 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support
Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC,
VMEMMAP and KERNEL_LINK_ADDR ranges), va bits and ram base for vmcore.
Default pagetable levels and PAGE_OFFSET aren't same for different kernel
version as below. For default pagetable levels, it sets sv57 on defaultly
in latest kernel and do fallback to try to set sv48 on boot time if sv57
is not supported in current hardware.
For ram base, the default value is 0x80200000 for qemu riscv64 env, 0x200000
for riscv64 SoC platform(eg, SoC platform of RISC-V 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(a)linux.alibaba.com>
---
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/crash_core.c | 29 +++++++++++++++++++++++++++++
2 files changed, 30 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..8d7f5ff108da
--- /dev/null
+++ b/arch/riscv/kernel/crash_core.c
@@ -0,0 +1,29 @@
+// 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)) {
+#ifdef CONFIG_KASAN
+ vmcoreinfo_append_str("NUMBER(KASAN_SHADOW_START)=0x%lx\n",
KASAN_SHADOW_START);
+ vmcoreinfo_append_str("NUMBER(KASAN_SHADOW_END)=0x%lx\n", KASAN_SHADOW_END);
+#endif
+ vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
+ vmcoreinfo_append_str("NUMBER(ADDRESS_SPACE_END)=0x%lx\n",
ADDRESS_SPACE_END);
+ }
+}
--
2.17.1
2:48 a.m.
New subject: [PATCH 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64
The following interrelated definitions and ranges are needed by the kdump
crash tool, they are exported by "arch/riscv/kernel/crash_core.c":
VA_BITS,
PAGE_OFFSET,
phys_ram_base,
MODULES_VADDR ~ MODULES_END,
VMALLOC_START ~ VMALLOC_END,
VMEMMAP_START ~ VMEMMAP_END,
KASAN_SHADOW_START ~ KASAN_SHADOW_END,
KERNEL_LINK_ADDR ~ ADDRESS_SPACE_END
Document these RISCV64 exports above.
Signed-off-by: Xianting Tian <xianting.tian(a)linux.alibaba.com>
---
.../admin-guide/kdump/vmcoreinfo.rst | 31 +++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst
b/Documentation/admin-guide/kdump/vmcoreinfo.rst
index 6726f439958c..6c7a1728de22 100644
--- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
+++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
@@ -595,3 +595,34 @@ X2TLB
-----
Indicates whether the crashed kernel enabled SH extended mode.
+
+RISCV64
+=======
+
+VA_BITS
+-------
+
+The maximum number of bits for virtual addresses. Used to compute the
+virtual memory ranges.
+
+PAGE_OFFSET
+-----------
+
+Indicates the virtual kernel start address of direct-mapped RAM region.
+
+phys_ram_base
+-------------
+
+Indicates the start physical RAM address.
+
+----------------------------------------------------------------------------------------------------------------------------------------------------
+MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END|KASAN_SHADOW_START|KASAN_SHADOW_END|KERNEL_LINK_ADDR|ADDRESS_SPACE_END
+----------------------------------------------------------------------------------------------------------------------------------------------------
+
+Used to get the correct ranges:
+
+ * MODULES_VADDR ~ MODULES_END : Kernel module space.
+ * VMALLOC_START ~ VMALLOC_END : vmalloc() / ioremap() space.
+ * VMEMMAP_START ~ VMEMMAP_END : vmemmap region, used for struct page array.
+ * KASAN_SHADOW_START ~ KASAN_SHADOW_END : kasan shadow space.
+ * KERNEL_LINK_ADDR ~ ADDRESS_SPACE_END : Kernel link and BPF space.
--
2.17.1
8:01 a.m.
New subject: [PATCH 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64
On Fri, Oct 14, 2022 at 03:48:10PM +0800, Xianting Tian wrote:
The following interrelated definitions and ranges are needed by the
kdump
crash tool, they are exported by "arch/riscv/kernel/crash_core.c":
VA_BITS,
PAGE_OFFSET,
phys_ram_base,
MODULES_VADDR ~ MODULES_END,
VMALLOC_START ~ VMALLOC_END,
VMEMMAP_START ~ VMEMMAP_END,
KASAN_SHADOW_START ~ KASAN_SHADOW_END,
KERNEL_LINK_ADDR ~ ADDRESS_SPACE_END
Document these RISCV64 exports above.
The patch description LGTM, thanks.
+----------------------------------------------------------------------------------------------------------------------------------------------------
+MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END|KASAN_SHADOW_START|KASAN_SHADOW_END|KERNEL_LINK_ADDR|ADDRESS_SPACE_END
+----------------------------------------------------------------------------------------------------------------------------------------------------
The overline above header text is unnecessary, so I have to strip it:
---- >8 ----
diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst
b/Documentation/admin-guide/kdump/vmcoreinfo.rst
index 6c7a1728de220e..8e2e164cf3db49 100644
--- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
+++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
@@ -615,7 +615,6 @@ phys_ram_base
Indicates the start physical RAM address.
-----------------------------------------------------------------------------------------------------------------------------------------------------
MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END|KASAN_SHADOW_START|KASAN_SHADOW_END|KERNEL_LINK_ADDR|ADDRESS_SPACE_END
----------------------------------------------------------------------------------------------------------------------------------------------------
Thanks.
--
An old man doll... just what I always wanted! - Clara
8:10 a.m.
New subject: [PATCH 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64
Hey Bagas,
On Fri, Oct 14, 2022 at 08:01:32PM +0700, Bagas Sanjaya wrote:
On Fri, Oct 14, 2022 at 03:48:10PM +0800, Xianting Tian wrote:
> The following interrelated definitions and ranges are needed by the kdump
> crash tool, they are exported by "arch/riscv/kernel/crash_core.c":
> VA_BITS,
> PAGE_OFFSET,
> phys_ram_base,
> MODULES_VADDR ~ MODULES_END,
> VMALLOC_START ~ VMALLOC_END,
> VMEMMAP_START ~ VMEMMAP_END,
> KASAN_SHADOW_START ~ KASAN_SHADOW_END,
> KERNEL_LINK_ADDR ~ ADDRESS_SPACE_END
>
> Document these RISCV64 exports above.
>
The patch description LGTM, thanks.
>
+----------------------------------------------------------------------------------------------------------------------------------------------------
>
+MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END|KASAN_SHADOW_START|KASAN_SHADOW_END|KERNEL_LINK_ADDR|ADDRESS_SPACE_END
>
+----------------------------------------------------------------------------------------------------------------------------------------------------
The overline above header text is unnecessary, so I have to strip it:
---- >8 ----
diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst
b/Documentation/admin-guide/kdump/vmcoreinfo.rst
index 6c7a1728de220e..8e2e164cf3db49 100644
--- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
+++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
@@ -615,7 +615,6 @@ phys_ram_base
Indicates the start physical RAM address.
-----------------------------------------------------------------------------------------------------------------------------------------------------
MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END|KASAN_SHADOW_START|KASAN_SHADOW_END|KERNEL_LINK_ADDR|ADDRESS_SPACE_END
----------------------------------------------------------------------------------------------------------------------------------------------------
Without whitespace highlighting, your change threw me for a sec.. But
yeah, having the overline is inconsistent with other headings in the
doc.
What I wanted to ask about was the linelength as I don't know anything
about rst. Is it possible to avoid having the ~150 character line or is
that a necessary evil?
Thanks,
Conor.
Thanks.
--
An old man doll... just what I always wanted! - Clara
8:23 a.m.
New subject: [PATCH 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64
On 10/14/22 20:10, Conor Dooley wrote:
Without whitespace highlighting, your change threw me for a sec..
But
yeah, having the overline is inconsistent with other headings in the
doc.
What I wanted to ask about was the linelength as I don't know anything
about rst. Is it possible to avoid having the ~150 character line or is
that a necessary evil?
I think the section describes correct range exports; however since there
are many such ranges with distinct purposes, it is better to split the
section into multiple sections describing each range.
If we go without splitting, the 150-character header is necessary (I don't
know how to split the header text line without trigger any warnings).
Thanks.
--
An old man doll... just what I always wanted! - Clara
8:44 a.m.
New subject: [PATCH 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64
在 2022/10/14 下午9:23, Bagas Sanjaya 写道:
On 10/14/22 20:10, Conor Dooley wrote:
> Without whitespace highlighting, your change threw me for a sec.. But
> yeah, having the overline is inconsistent with other headings in the
> doc.
>
> What I wanted to ask about was the linelength as I don't know anything
> about rst. Is it possible to avoid having the ~150 character line or is
> that a necessary evil?
>
I think the section describes correct range exports; however since there
are many such ranges with distinct purposes, it is better to split the
section into multiple sections describing each range.
If we go without splitting, the 150-character header is necessary (I don't
know how to split the header text line without trigger any warnings).
thanks, I send V2 patch, please help review.
https://lkml.org/lkml/2022/10/14/447
Thanks.
626
days inactive
626
days old
devel@lists.crash-utility.osci.io
6 comments
3 participants
participants (3)
-
Bagas Sanjaya -
Conor Dooley -
Xianting Tian