[PATCH V2 0/2] Improve vmcoreinfo and memory layout dump

[PATCH V2 0/2] Improve vmcoreinfo and memory layout dump

[Xianting Tian]

This patch series are the improvements for vmcoreinfo and memory
layout dump.

The first patch(1/2) is to add VM layout to vmcoreinfo, which can
simlify the development of crash tool as ARM64 already did
(arch/arm64/kernel/crash_core.c).

The second patch(2/2) is to add MODULES to memory layout dump.

Changes v1 -> v2:
 patch 1: add VA_BITS to vmcoreinfo as ARM64 does, not satp_mode.
	  crash tool can read VA_BITS to determin the pagetable
	  levels.
 patch 1,2: As MODULES area is only defined when CONFIG_64BIT=y for
	    riscv64, so only use MODULES area when CONFIG_64BIT=y. 
 
Xianting Tian (2):
  RISC-V: Add arch_crash_save_vmcoreinfo support
  riscv: Add modules to virtual kernel memory layout dump

 arch/riscv/kernel/Makefile     |  1 +
 arch/riscv/kernel/crash_core.c | 28 ++++++++++++++++++++++++++++
 arch/riscv/mm/init.c           |  3 +++
 3 files changed, 32 insertions(+)
 create mode 100644 arch/riscv/kernel/crash_core.c

-- 
2.17.1

[PATCH V2 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support

[Xianting Tian]

Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC,
VMEMMAP and KERNEL_LINK_ADDR ranges), satp mode and ram base to vmcore.

Default pagetable levels and PAGE_OFFSET aren't same for different kernel
version as below. For default pagetable levels, it sets sv57 on defaultly
in latest kernel and do fallback to try to set sv48 on boot time if sv57
is not supported in current hardware.

For ram base, the default value is 0x80200000 for qemu riscv64 env, 0x200000
for riscv64 SoC platform(eg, SoC platform of RISC-V XuanTie 910 CPU).

 * Linux Kernel 5.18 ~
 *      PGTABLE_LEVELS = 5
 *      PAGE_OFFSET = 0xff60000000000000
 * Linux Kernel 5.17 ~
 *      PGTABLE_LEVELS = 4
 *      PAGE_OFFSET = 0xffffaf8000000000
 * Linux Kernel 4.19 ~
 *      PGTABLE_LEVELS = 3
 *      PAGE_OFFSET = 0xffffffe000000000

Since these configurations change from time to time and version to version,
it is preferable to export them via vmcoreinfo than to change the crash's
code frequently, it can simplify the development of crash tool.

Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
---
 arch/riscv/kernel/Makefile     |  1 +
 arch/riscv/kernel/crash_core.c | 28 ++++++++++++++++++++++++++++
 2 files changed, 29 insertions(+)
 create mode 100644 arch/riscv/kernel/crash_core.c

diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index c71d6591d539..54e4183db080 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)		+= kgdb.o
 obj-$(CONFIG_KEXEC)		+= 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..c096904dd0f3
--- /dev/null
+++ b/arch/riscv/kernel/crash_core.c
@@ -0,0 +1,28 @@
+// 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);
+
+	/* Please note VMCOREINFO_NUMBER() uses "%d", not "%x" */
+	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);
+
+	if (IS_ENABLED(CONFIG_64BIT)) {
+		vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
+		vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
+#ifdef CONFIG_KASAN
+		vmcoreinfo_append_str("NUMBER(KASAN_SHADOW_START)=0x%lx\n", KASAN_SHADOW_START);
+		vmcoreinfo_append_str("NUMBER(KASAN_SHADOW_END)=0x%lx\n", KASAN_SHADOW_END);
+#endif
+		vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
+		vmcoreinfo_append_str("NUMBER(ADDRESS_SPACE_END)=0x%lx\n", ADDRESS_SPACE_END);
+	}
+}
-- 
2.17.1

[PATCH V2 2/2] riscv: Add modules to virtual kernel memory layout dump

[Xianting Tian]

Modules always live before the kernel, MODULES_END is fixed but
MODULES_VADDR isn't fixed, it depends on the kernel size.
Let's add it to virtual kernel memory layout dump.

As MODULES is only defined for CONFIG_64BIT, so we dump it when
CONFIG_64BIT.

eg,
MODULES_VADDR - MODULES_END
0xffffffff01133000 - 0xffffffff80000000

Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
---
 arch/riscv/mm/init.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index d466ec670e1f..bbc9431e9042 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -135,6 +135,9 @@ static void __init print_vm_layout(void)
 		(unsigned long)VMEMMAP_END);
 	print_ml("vmalloc", (unsigned long)VMALLOC_START,
 		(unsigned long)VMALLOC_END);
+	if (IS_ENABLED(CONFIG_64BIT))
+		print_ml("modules", (unsigned long)MODULES_VADDR,
+			(unsigned long)MODULES_END);
 	print_ml("lowmem", (unsigned long)PAGE_OFFSET,
 		(unsigned long)high_memory);
 	if (IS_ENABLED(CONFIG_64BIT)) {
-- 
2.17.1

Re: [PATCH V2 2/2] riscv: Add modules to virtual kernel memory layout dump

[Arnd Bergmann]

On Thu, Jul 14, 2022 at 4:59 AM Xianting Tian
<xianting.tian@linux.alibaba.com> wrote:
>
> As MODULES is only defined for CONFIG_64BIT, so we dump it when
> CONFIG_64BIT.

Doesn't this cause a compile-time error on 32-bit?

>                 (unsigned long)VMEMMAP_END);
>         print_ml("vmalloc", (unsigned long)VMALLOC_START,
>                 (unsigned long)VMALLOC_END);
> +       if (IS_ENABLED(CONFIG_64BIT))
> +               print_ml("modules", (unsigned long)MODULES_VADDR,
> +                       (unsigned long)MODULES_END);

The IS_ENABLED() check prevents the line from getting executed, but
unlike an #ifdef it still relies on it to be parsable.

         Arnd

Re: [PATCH V2 2/2] riscv: Add modules to virtual kernel memory layout dump

[Xianting Tian]

在 2022/7/14 下午4:24, Arnd Bergmann 写道:
> On Thu, Jul 14, 2022 at 4:59 AM Xianting Tian
> <xianting.tian@linux.alibaba.com> wrote:
>> As MODULES is only defined for CONFIG_64BIT, so we dump it when
>> CONFIG_64BIT.
> Doesn't this cause a compile-time error on 32-bit?
I tested, rv32 compile is OK.
>
>>                  (unsigned long)VMEMMAP_END);
>>          print_ml("vmalloc", (unsigned long)VMALLOC_START,
>>                  (unsigned long)VMALLOC_END);
>> +       if (IS_ENABLED(CONFIG_64BIT))
>> +               print_ml("modules", (unsigned long)MODULES_VADDR,
>> +                       (unsigned long)MODULES_END);
> The IS_ENABLED() check prevents the line from getting executed, but
> unlike an #ifdef it still relies on it to be parsable.
Thanks, I will use #ifdef instead of IS_ENABLED
>
>           Arnd

Re: [PATCH V2 2/2] riscv: Add modules to virtual kernel memory layout dump

[Heiko Stübner]

Am Donnerstag, 14. Juli 2022, 11:17:26 CEST schrieb Xianting Tian:
> 
> 在 2022/7/14 下午4:24, Arnd Bergmann 写道:
> > On Thu, Jul 14, 2022 at 4:59 AM Xianting Tian
> > <xianting.tian@linux.alibaba.com> wrote:
> >> As MODULES is only defined for CONFIG_64BIT, so we dump it when
> >> CONFIG_64BIT.
> > Doesn't this cause a compile-time error on 32-bit?
> I tested, rv32 compile is OK.

> >>                  (unsigned long)VMEMMAP_END);
> >>          print_ml("vmalloc", (unsigned long)VMALLOC_START,
> >>                  (unsigned long)VMALLOC_END);
> >> +       if (IS_ENABLED(CONFIG_64BIT))
> >> +               print_ml("modules", (unsigned long)MODULES_VADDR,
> >> +                       (unsigned long)MODULES_END);
> > The IS_ENABLED() check prevents the line from getting executed, but
> > unlike an #ifdef it still relies on it to be parsable.
> Thanks, I will use #ifdef instead of IS_ENABLED

Patch1 also has that issue with the

      if (IS_ENABLED(CONFIG_64BIT)) {
              vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
              vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
      ....


module_alloc falls back to a weak variant [0] which is the same as the riscv variant
only then using VMALLOC_START - VMALLOC_END as range, as the riscv-variant
conditional to CONFIG_64BIT.

I'm wondering if it wouldn't be easier in the long run to just define
MODULES_VADDR, MODULES_END for 32bit to use these values and get rid of
the CONFIG_64BIT ifdef we already have for MODULES (and new ones we are
introducing now).


Heiko


[0] https://elixir.bootlin.com/linux/latest/source/kernel/module.c#L2835

Re: [PATCH V2 2/2] riscv: Add modules to virtual kernel memory layout dump

[Xianting Tian]

在 2022/7/14 下午5:46, Heiko Stübner 写道:
> Am Donnerstag, 14. Juli 2022, 11:17:26 CEST schrieb Xianting Tian:
>> 在 2022/7/14 下午4:24, Arnd Bergmann 写道:
>>> On Thu, Jul 14, 2022 at 4:59 AM Xianting Tian
>>> <xianting.tian@linux.alibaba.com> wrote:
>>>> As MODULES is only defined for CONFIG_64BIT, so we dump it when
>>>> CONFIG_64BIT.
>>> Doesn't this cause a compile-time error on 32-bit?
>> I tested, rv32 compile is OK.
>>>>                   (unsigned long)VMEMMAP_END);
>>>>           print_ml("vmalloc", (unsigned long)VMALLOC_START,
>>>>                   (unsigned long)VMALLOC_END);
>>>> +       if (IS_ENABLED(CONFIG_64BIT))
>>>> +               print_ml("modules", (unsigned long)MODULES_VADDR,
>>>> +                       (unsigned long)MODULES_END);
>>> The IS_ENABLED() check prevents the line from getting executed, but
>>> unlike an #ifdef it still relies on it to be parsable.
>> Thanks, I will use #ifdef instead of IS_ENABLED
> Patch1 also has that issue with the
thanks, I will modify it in V3.
>
>        if (IS_ENABLED(CONFIG_64BIT)) {
>                vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
>                vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
>        ....
>
>
> module_alloc falls back to a weak variant [0] which is the same as the riscv variant
> only then using VMALLOC_START - VMALLOC_END as range, as the riscv-variant
> conditional to CONFIG_64BIT.

yes, I ever checked, actually before 5.13, it doesn't define MODULES 
area but use VMALLOC for modules,

crash> mod
      MODULE       NAME           BASE           SIZE  OBJECT FILE
ffffffdf8167f280  galcore  ffffffdf81646000  3075841  (not loaded)  
[CONFIG_KALLSYMS]

[    0.000000]      vmalloc : 0xffffffd000000000 - 0xffffffdfffffffff   
(65535 MB)

>
> I'm wondering if it wouldn't be easier in the long run to just define
> MODULES_VADDR, MODULES_END for 32bit to use these values and get rid of
> the CONFIG_64BIT ifdef we already have for MODULES (and new ones we are
> introducing now).
>
>
> Heiko
>
>
> [0] https://elixir.bootlin.com/linux/latest/source/kernel/module.c#L2835
>
>

Re: [PATCH V2 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support

[Xianting Tian]

在 2022/10/18 下午3:19, Conor.Dooley@microchip.com 写道:
> On 18/10/2022 03:28, Xianting Tian wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>
>> 在 2022/10/18 上午3:54, Conor Dooley 写道:
>>
>>> On Fri, Oct 14, 2022 at 09:41:38PM +0800, Xianting Tian wrote:
>>>>    * Linux Kernel 5.18 ~
>>>>    *      PGTABLE_LEVELS = 5
>>>>    *      PAGE_OFFSET = 0xff60000000000000
>>>>    * Linux Kernel 5.17 ~
>>>>    *      PGTABLE_LEVELS = 4
>>>>    *      PAGE_OFFSET = 0xffffaf8000000000
>>>>    * Linux Kernel 4.19 ~
>>>>    *      PGTABLE_LEVELS = 3
>>>>    *      PAGE_OFFSET = 0xffffffe000000000
>>>>
>>>> Since these configurations change from time to time and version to version,
>>>> it is preferable to export them via vmcoreinfo than to change the crash's
>>>> code frequently, it can simplify the development of crash tool.
>>>>
>>>> Signed-off-by: Xianting Tian<xianting.tian@linux.alibaba.com>
>>>> ---
>>>>    arch/riscv/kernel/Makefile     |  1 +
>>>>    arch/riscv/kernel/crash_core.c | 29 +++++++++++++++++++++++++++++
>>>>    2 files changed, 30 insertions(+)
>>>>    create mode 100644 arch/riscv/kernel/crash_core.c
>>>>
>>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
>>>> index db6e4b1294ba..4cf303a779ab 100644
>>>> --- a/arch/riscv/kernel/Makefile
>>>> +++ b/arch/riscv/kernel/Makefile
>>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)		+= kgdb.o
>>>>    obj-$(CONFIG_KEXEC_CORE)	+= kexec_relocate.o crash_save_regs.o machine_kexec.o
>>>>    obj-$(CONFIG_KEXEC_FILE)	+= elf_kexec.o machine_kexec_file.o
>>>>    obj-$(CONFIG_CRASH_DUMP)	+= crash_dump.o
>>>> +obj-$(CONFIG_CRASH_CORE)	+= crash_core.o
>>>>    
>>>>    obj-$(CONFIG_JUMP_LABEL)	+= jump_label.o
>>>>    
>>>> diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c
>>>> new file mode 100644
>>>> index 000000000000..8d7f5ff108da
>>>> --- /dev/null
>>>> +++ b/arch/riscv/kernel/crash_core.c
>>>> @@ -0,0 +1,29 @@
>>>> +// SPDX-License-Identifier: GPL-2.0-only
>>>> +
>>>> +#include <linux/crash_core.h>
>>>> +#include <linux/pagemap.h>
>>>> +
>>>> +void arch_crash_save_vmcoreinfo(void)
>>>> +{
>>>> +	VMCOREINFO_NUMBER(VA_BITS);
>>>> +	VMCOREINFO_NUMBER(phys_ram_base);
>>>> +
>>>> +	vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
>>>> +	vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
>>>> +	vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
>>>> +	vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
>>>> +	vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
>>>> +#ifdef CONFIG_64BIT
>>>> +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
>>>> +	vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
>>>> +#endif
>>>> +
>>>> +	if (IS_ENABLED(CONFIG_64BIT)) {
>>> You've already got a #ifdef CONFIG_64BIT above, is there a reason why
>>> you'd use the IS_ENABLED here rather than merge this with the above
>>> section? I'm a big fan of IS_ENABLED but I'm not sure what it adds here,
>>> maybe you can show me the light :)
>> The IS_ENABLED() check prevents the line from getting executed, but
>> unlike an #ifdef it relies on it to be parsable.
> Hey Xianting,
> Firstly, neither this nor the other version of this message made it to
> the mailing list - and since I usually use lei to get my mails that is
> a bit of a problem :(

Sorry, I don't know why,  I just reply via Thunderbird.

But git send-mail is right, I will send V3 soon.

>
> Yeah, I know that that is what IS_ENABLED() does, it's just in this
> situation it does not look very intentional & more like disjoint bits
> of copy-paste. It's fine though, leave it as it is.
OK, thanks
>
> Thanks,
> Conor.
>
>> I wrote this arch_crash_save_vmcoreinfo() func with reference to this: static void __init print_vm_layout(void) // arch/riscv/mm/init.c
>> {
>>           pr_notice("Virtual kernel memory layout:\n");
>>           print_ml("fixmap", (unsigned long)FIXADDR_START,
>>                   (unsigned long)FIXADDR_TOP);
>>           print_ml("pci io", (unsigned long)PCI_IO_START,
>>                   (unsigned long)PCI_IO_END);
>>           print_ml("vmemmap", (unsigned long)VMEMMAP_START,
>>                   (unsigned long)VMEMMAP_END);
>>           print_ml("vmalloc", (unsigned long)VMALLOC_START,
>>                   (unsigned long)VMALLOC_END);
>> #ifdef CONFIG_64BIT
>>           print_ml("modules", (unsigned long)MODULES_VADDR,
>>                   (unsigned long)MODULES_END);
>> #endif
>>           print_ml("lowmem", (unsigned long)PAGE_OFFSET,
>>                   (unsigned long)high_memory);
>>           if (IS_ENABLED(CONFIG_64BIT)) {
>> #ifdef CONFIG_KASAN
>>                   print_ml("kasan", KASAN_SHADOW_START, KASAN_SHADOW_END);
>> #endif
>>
>>                   print_ml("kernel", (unsigned long)KERNEL_LINK_ADDR,
>>                            (unsigned long)ADDRESS_SPACE_END);
>>           }
>> }
>>
>>> Thanks,
>>> Conor.
>>>
>>>
>>>> +#ifdef CONFIG_KASAN
>>>> +		vmcoreinfo_append_str("NUMBER(KASAN_SHADOW_START)=0x%lx\n", KASAN_SHADOW_START);
>>>> +		vmcoreinfo_append_str("NUMBER(KASAN_SHADOW_END)=0x%lx\n", KASAN_SHADOW_END);
>>>> +#endif
>>>> +		vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
>>>> +		vmcoreinfo_append_str("NUMBER(ADDRESS_SPACE_END)=0x%lx\n", ADDRESS_SPACE_END);
>>>> +	}
>>>> +}
>>>> -- 
>>>> 2.17.1
>>>>
>>>>

Re: [PATCH V2 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support

[Conor.Dooley]

On 18/10/2022 03:28, Xianting Tian wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> 在 2022/10/18 上午3:54, Conor Dooley 写道:
> 
>> On Fri, Oct 14, 2022 at 09:41:38PM +0800, Xianting Tian wrote:

>>>   * Linux Kernel 5.18 ~
>>>   *      PGTABLE_LEVELS = 5
>>>   *      PAGE_OFFSET = 0xff60000000000000
>>>   * Linux Kernel 5.17 ~
>>>   *      PGTABLE_LEVELS = 4
>>>   *      PAGE_OFFSET = 0xffffaf8000000000
>>>   * Linux Kernel 4.19 ~
>>>   *      PGTABLE_LEVELS = 3
>>>   *      PAGE_OFFSET = 0xffffffe000000000
>>>
>>> Since these configurations change from time to time and version to version,
>>> it is preferable to export them via vmcoreinfo than to change the crash's
>>> code frequently, it can simplify the development of crash tool.
>>>
>>> Signed-off-by: Xianting Tian<xianting.tian@linux.alibaba.com>
>>> ---
>>>   arch/riscv/kernel/Makefile     |  1 +
>>>   arch/riscv/kernel/crash_core.c | 29 +++++++++++++++++++++++++++++
>>>   2 files changed, 30 insertions(+)
>>>   create mode 100644 arch/riscv/kernel/crash_core.c
>>>
>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
>>> index db6e4b1294ba..4cf303a779ab 100644
>>> --- a/arch/riscv/kernel/Makefile
>>> +++ b/arch/riscv/kernel/Makefile
>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)		+= kgdb.o
>>>   obj-$(CONFIG_KEXEC_CORE)	+= kexec_relocate.o crash_save_regs.o machine_kexec.o
>>>   obj-$(CONFIG_KEXEC_FILE)	+= elf_kexec.o machine_kexec_file.o
>>>   obj-$(CONFIG_CRASH_DUMP)	+= crash_dump.o
>>> +obj-$(CONFIG_CRASH_CORE)	+= crash_core.o
>>>   
>>>   obj-$(CONFIG_JUMP_LABEL)	+= jump_label.o
>>>   
>>> diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c
>>> new file mode 100644
>>> index 000000000000..8d7f5ff108da
>>> --- /dev/null
>>> +++ b/arch/riscv/kernel/crash_core.c
>>> @@ -0,0 +1,29 @@
>>> +// SPDX-License-Identifier: GPL-2.0-only
>>> +
>>> +#include <linux/crash_core.h>
>>> +#include <linux/pagemap.h>
>>> +
>>> +void arch_crash_save_vmcoreinfo(void)
>>> +{
>>> +	VMCOREINFO_NUMBER(VA_BITS);
>>> +	VMCOREINFO_NUMBER(phys_ram_base);
>>> +
>>> +	vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
>>> +	vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
>>> +	vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
>>> +	vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
>>> +	vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
>>> +#ifdef CONFIG_64BIT
>>> +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
>>> +	vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
>>> +#endif
>>> +
>>> +	if (IS_ENABLED(CONFIG_64BIT)) {
>> You've already got a #ifdef CONFIG_64BIT above, is there a reason why
>> you'd use the IS_ENABLED here rather than merge this with the above
>> section? I'm a big fan of IS_ENABLED but I'm not sure what it adds here,
>> maybe you can show me the light :)
> The IS_ENABLED() check prevents the line from getting executed, but
> unlike an #ifdef it relies on it to be parsable.

Hey Xianting,
Firstly, neither this nor the other version of this message made it to
the mailing list - and since I usually use lei to get my mails that is
a bit of a problem :(

Yeah, I know that that is what IS_ENABLED() does, it's just in this
situation it does not look very intentional & more like disjoint bits
of copy-paste. It's fine though, leave it as it is.

Thanks,
Conor.

> 
> I wrote this arch_crash_save_vmcoreinfo() func with reference to this: static void __init print_vm_layout(void) // arch/riscv/mm/init.c
> {
>          pr_notice("Virtual kernel memory layout:\n");
>          print_ml("fixmap", (unsigned long)FIXADDR_START,
>                  (unsigned long)FIXADDR_TOP);
>          print_ml("pci io", (unsigned long)PCI_IO_START,
>                  (unsigned long)PCI_IO_END);
>          print_ml("vmemmap", (unsigned long)VMEMMAP_START,
>                  (unsigned long)VMEMMAP_END);
>          print_ml("vmalloc", (unsigned long)VMALLOC_START,
>                  (unsigned long)VMALLOC_END);
> #ifdef CONFIG_64BIT
>          print_ml("modules", (unsigned long)MODULES_VADDR,
>                  (unsigned long)MODULES_END);
> #endif
>          print_ml("lowmem", (unsigned long)PAGE_OFFSET,
>                  (unsigned long)high_memory);
>          if (IS_ENABLED(CONFIG_64BIT)) {
> #ifdef CONFIG_KASAN
>                  print_ml("kasan", KASAN_SHADOW_START, KASAN_SHADOW_END);
> #endif
> 
>                  print_ml("kernel", (unsigned long)KERNEL_LINK_ADDR,
>                           (unsigned long)ADDRESS_SPACE_END);
>          }
> }
> 
>> Thanks,
>> Conor.
>>
>>
>>> +#ifdef CONFIG_KASAN
>>> +		vmcoreinfo_append_str("NUMBER(KASAN_SHADOW_START)=0x%lx\n", KASAN_SHADOW_START);
>>> +		vmcoreinfo_append_str("NUMBER(KASAN_SHADOW_END)=0x%lx\n", KASAN_SHADOW_END);
>>> +#endif
>>> +		vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
>>> +		vmcoreinfo_append_str("NUMBER(ADDRESS_SPACE_END)=0x%lx\n", ADDRESS_SPACE_END);
>>> +	}
>>> +}
>>> -- 
>>> 2.17.1
>>>
>>>

Re: [PATCH V2 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support

[Conor Dooley]

On Fri, Oct 14, 2022 at 09:41:38PM +0800, Xianting Tian wrote:
> Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC,
> VMEMMAP and KERNEL_LINK_ADDR ranges), va bits and ram base for vmcore.
> 
> Default pagetable levels and PAGE_OFFSET aren't same for different kernel
> version as below. For default pagetable levels, it sets sv57 on defaultly
> in latest kernel and do fallback to try to set sv48 on boot time if sv57
> is not supported in current hardware.

nit: This would read better as "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, 0x200000
> for riscv64 SoC platform(eg, SoC platform of RISC-V XuanTie 910 CPU).

The second part of this sentence I'm not really sure that that is true,
I think you should reword it to something like "...for qemu riscv64 and,
for example, is 0x200000 on the XuanTie 910 CPU." and avoid applying
that number blanketly for other SoCs.
> 
>  * Linux Kernel 5.18 ~
>  *      PGTABLE_LEVELS = 5
>  *      PAGE_OFFSET = 0xff60000000000000
>  * Linux Kernel 5.17 ~
>  *      PGTABLE_LEVELS = 4
>  *      PAGE_OFFSET = 0xffffaf8000000000
>  * Linux Kernel 4.19 ~
>  *      PGTABLE_LEVELS = 3
>  *      PAGE_OFFSET = 0xffffffe000000000
> 
> Since these configurations change from time to time and version to version,
> it is preferable to export them via vmcoreinfo than to change the crash's
> code frequently, it can simplify the development of crash tool.
> 
> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> ---
>  arch/riscv/kernel/Makefile     |  1 +
>  arch/riscv/kernel/crash_core.c | 29 +++++++++++++++++++++++++++++
>  2 files changed, 30 insertions(+)
>  create mode 100644 arch/riscv/kernel/crash_core.c
> 
> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> index db6e4b1294ba..4cf303a779ab 100644
> --- a/arch/riscv/kernel/Makefile
> +++ b/arch/riscv/kernel/Makefile
> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)		+= kgdb.o
>  obj-$(CONFIG_KEXEC_CORE)	+= kexec_relocate.o crash_save_regs.o machine_kexec.o
>  obj-$(CONFIG_KEXEC_FILE)	+= elf_kexec.o machine_kexec_file.o
>  obj-$(CONFIG_CRASH_DUMP)	+= crash_dump.o
> +obj-$(CONFIG_CRASH_CORE)	+= crash_core.o
>  
>  obj-$(CONFIG_JUMP_LABEL)	+= jump_label.o
>  
> diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c
> new file mode 100644
> index 000000000000..8d7f5ff108da
> --- /dev/null
> +++ b/arch/riscv/kernel/crash_core.c
> @@ -0,0 +1,29 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include <linux/crash_core.h>
> +#include <linux/pagemap.h>
> +
> +void arch_crash_save_vmcoreinfo(void)
> +{
> +	VMCOREINFO_NUMBER(VA_BITS);
> +	VMCOREINFO_NUMBER(phys_ram_base);
> +
> +	vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
> +	vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
> +	vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
> +	vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
> +	vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
> +#ifdef CONFIG_64BIT
> +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
> +	vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
> +#endif
> +
> +	if (IS_ENABLED(CONFIG_64BIT)) {

You've already got a #ifdef CONFIG_64BIT above, is there a reason why
you'd use the IS_ENABLED here rather than merge this with the above
section? I'm a big fan of IS_ENABLED but I'm not sure what it adds here,
maybe you can show me the light :)

Thanks,
Conor.


> +#ifdef CONFIG_KASAN
> +		vmcoreinfo_append_str("NUMBER(KASAN_SHADOW_START)=0x%lx\n", KASAN_SHADOW_START);
> +		vmcoreinfo_append_str("NUMBER(KASAN_SHADOW_END)=0x%lx\n", KASAN_SHADOW_END);
> +#endif
> +		vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
> +		vmcoreinfo_append_str("NUMBER(ADDRESS_SPACE_END)=0x%lx\n", ADDRESS_SPACE_END);
> +	}
> +}
> -- 
> 2.17.1
> 
> 

[PATCH V2 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support

[Xianting Tian]

Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC,
VMEMMAP and KERNEL_LINK_ADDR ranges), va bits and ram base for vmcore.

Default pagetable levels and PAGE_OFFSET aren't same for different kernel
version as below. For default pagetable levels, it sets sv57 on defaultly
in latest kernel and do fallback to try to set sv48 on boot time if sv57
is not supported in current hardware.

For ram base, the default value is 0x80200000 for qemu riscv64 env, 0x200000
for riscv64 SoC platform(eg, SoC platform of RISC-V XuanTie 910 CPU).

 * Linux Kernel 5.18 ~
 *      PGTABLE_LEVELS = 5
 *      PAGE_OFFSET = 0xff60000000000000
 * Linux Kernel 5.17 ~
 *      PGTABLE_LEVELS = 4
 *      PAGE_OFFSET = 0xffffaf8000000000
 * Linux Kernel 4.19 ~
 *      PGTABLE_LEVELS = 3
 *      PAGE_OFFSET = 0xffffffe000000000

Since these configurations change from time to time and version to version,
it is preferable to export them via vmcoreinfo than to change the crash's
code frequently, it can simplify the development of crash tool.

Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
---
 arch/riscv/kernel/Makefile     |  1 +
 arch/riscv/kernel/crash_core.c | 29 +++++++++++++++++++++++++++++
 2 files changed, 30 insertions(+)
 create mode 100644 arch/riscv/kernel/crash_core.c

diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index db6e4b1294ba..4cf303a779ab 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)		+= kgdb.o
 obj-$(CONFIG_KEXEC_CORE)	+= kexec_relocate.o crash_save_regs.o machine_kexec.o
 obj-$(CONFIG_KEXEC_FILE)	+= elf_kexec.o machine_kexec_file.o
 obj-$(CONFIG_CRASH_DUMP)	+= crash_dump.o
+obj-$(CONFIG_CRASH_CORE)	+= crash_core.o
 
 obj-$(CONFIG_JUMP_LABEL)	+= jump_label.o
 
diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c
new file mode 100644
index 000000000000..8d7f5ff108da
--- /dev/null
+++ b/arch/riscv/kernel/crash_core.c
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include <linux/crash_core.h>
+#include <linux/pagemap.h>
+
+void arch_crash_save_vmcoreinfo(void)
+{
+	VMCOREINFO_NUMBER(VA_BITS);
+	VMCOREINFO_NUMBER(phys_ram_base);
+
+	vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
+	vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
+	vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
+	vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
+	vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
+#ifdef CONFIG_64BIT
+	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
+	vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
+#endif
+
+	if (IS_ENABLED(CONFIG_64BIT)) {
+#ifdef CONFIG_KASAN
+		vmcoreinfo_append_str("NUMBER(KASAN_SHADOW_START)=0x%lx\n", KASAN_SHADOW_START);
+		vmcoreinfo_append_str("NUMBER(KASAN_SHADOW_END)=0x%lx\n", KASAN_SHADOW_END);
+#endif
+		vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
+		vmcoreinfo_append_str("NUMBER(ADDRESS_SPACE_END)=0x%lx\n", ADDRESS_SPACE_END);
+	}
+}
-- 
2.17.1