5:36 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."
V1 -> V2:
Remove unnecessary overline above header text in patch 2.
V2 -> V3:
Fix commit message in patch 1,2;
Use 'space' instead of 'region' for vmemmap description in patch 2.
V3 -> V4:
Remove unnecessary kernel space export:
KASAN_SHADOW_START ~ KASAN_SHADOW_END,
ADDRESS_SPACE_END
Xianting Tian (2):
RISC-V: Add arch_crash_save_vmcoreinfo support
Documentation: kdump: describe VMCOREINFO export for RISCV64
.../admin-guide/kdump/vmcoreinfo.rst | 30 ++++++++++++++++++
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
5:36 a.m.
New subject: [PATCH V4 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support
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(a)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
9:08 p.m.
New subject: [PATCH V4 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support
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(a)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)".
9:17 p.m.
New subject: [PATCH V4 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support
在 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(a)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.
10:05 p.m.
New subject: [PATCH V4 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support
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(a)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()?
11:40 p.m.
New subject: [PATCH V4 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support
在 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(a)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.
4:08 a.m.
New subject: [PATCH V4 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support
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(a)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.
4:25 a.m.
New subject: [PATCH V4 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support
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(a)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.
>
4:44 a.m.
New subject: [PATCH V4 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support
在 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(a)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.
>>
7:05 a.m.
New subject: [PATCH V4 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support
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(a)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.
> > >
8:47 a.m.
New subject: [PATCH V4 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support
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(a)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.
> > > >
>
9:24 a.m.
New subject: [PATCH V4 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support
在 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(a)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.
>>>>>
3:57 a.m.
New subject: [PATCH V4 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support
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(a)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.
> > > > >
> >
>
4:10 a.m.
New subject: [PATCH V4 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support
在 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(a)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.
>>>>>>
9:22 a.m.
New subject: [PATCH V4 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support
在 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(a)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.
>>>>
9:35 a.m.
New subject: [PATCH V4 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support
Tested-by: Guo Ren <guoren(a)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(a)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(a)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
--
Best Regards
Guo Ren
5:36 a.m.
New subject: [PATCH V4 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64
The following interrelated definitions and ranges are needed by the kdump
crash tool, which are exported by "arch/riscv/kernel/crash_core.c":
VA_BITS,
PAGE_OFFSET,
phys_ram_base,
KERNEL_LINK_ADDR,
MODULES_VADDR ~ MODULES_END,
VMALLOC_START ~ VMALLOC_END,
VMEMMAP_START ~ VMEMMAP_END,
Document these RISCV64 exports above.
Signed-off-by: Xianting Tian <xianting.tian(a)linux.alibaba.com>
---
.../admin-guide/kdump/vmcoreinfo.rst | 29 +++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst
b/Documentation/admin-guide/kdump/vmcoreinfo.rst
index 6726f439958c..86fd88492870 100644
--- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
+++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
@@ -595,3 +595,32 @@ 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 the 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|KERNEL_LINK_ADDR
+----------------------------------------------------------------------------------------------
+
+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 space, used for struct page array.
+ * KERNEL_LINK_ADDR : start address of Kernel link and BPF
--
2.17.1
8:56 p.m.
New subject: [PATCH V4 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64
On 10/19/22 17:36, Xianting Tian wrote:
The following interrelated definitions and ranges are needed by the
kdump
crash tool, which are exported by "arch/riscv/kernel/crash_core.c":
VA_BITS,
PAGE_OFFSET,
phys_ram_base,
KERNEL_LINK_ADDR,
MODULES_VADDR ~ MODULES_END,
VMALLOC_START ~ VMALLOC_END,
VMEMMAP_START ~ VMEMMAP_END,
Document these RISCV64 exports above.
Signed-off-by: Xianting Tian <xianting.tian(a)linux.alibaba.com>
Hi Xianting,
Seems like you forgot to keep carrying my Reviewed-by from v3 [1].
Anyway, here it goes...
Reviewed-by: Bagas Sanjaya <bagasdotme(a)gmail.com>
Thanks.
[1]:
https://lore.kernel.org/linux-doc/20221018081755.6214-3-xianting.tian@lin...
--
An old man doll... just what I always wanted! - Clara
9:26 p.m.
New subject: [PATCH V4 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64
在 2022/10/20 上午9:56, Bagas Sanjaya 写道:
On 10/19/22 17:36, Xianting Tian wrote:
> The following interrelated definitions and ranges are needed by the kdump
> crash tool, which are exported by "arch/riscv/kernel/crash_core.c":
> VA_BITS,
> PAGE_OFFSET,
> phys_ram_base,
> KERNEL_LINK_ADDR,
> MODULES_VADDR ~ MODULES_END,
> VMALLOC_START ~ VMALLOC_END,
> VMEMMAP_START ~ VMEMMAP_END,
>
> Document these RISCV64 exports above.
>
> Signed-off-by: Xianting Tian <xianting.tian(a)linux.alibaba.com>
Hi Xianting,
Seems like you forgot to keep carrying my Reviewed-by from v3 [1].
Anyway, here it goes...
Reviewed-by: Bagas Sanjaya <bagasdotme(a)gmail.com>
Sorry, I forgot... :(
757
days inactive
769
days old
devel@lists.crash-utility.osci.io
18 comments
6 participants
participants (6)
-
Bagas Sanjaya -
Baoquan He -
Conor Dooley -
Conor Dooley -
Guo Ren -
Xianting Tian