[PATCH V4 0/2] Support VMCOREINFO export for RISCV64

[PATCH V4 0/2] Support VMCOREINFO export for RISCV64

[Xianting Tian]

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@kernel.org/

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


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH V4 0/2] Support VMCOREINFO export for RISCV64

[Xianting Tian]

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@kernel.org/

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


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH V4 0/2] Support VMCOREINFO export for RISCV64

[Xianting Tian]

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@kernel.org/

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

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

[Xianting Tian]

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

Default pagetable levels and PAGE_OFFSET aren't same for different kernel
version as below. For pagetable levels, it sets sv57 by default and falls
back to setting sv48 at boot time if sv57 is not supported by the hardware.

For ram base, the default value is 0x80200000 for qemu riscv64 env and,
for example, is 0x200000 on the XuanTie 910 CPU.

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

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

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

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


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Xianting Tian]

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

Default pagetable levels and PAGE_OFFSET aren't same for different kernel
version as below. For pagetable levels, it sets sv57 by default and falls
back to setting sv48 at boot time if sv57 is not supported by the hardware.

For ram base, the default value is 0x80200000 for qemu riscv64 env and,
for example, is 0x200000 on the XuanTie 910 CPU.

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

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

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

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


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

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

[Xianting Tian]

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

Default pagetable levels and PAGE_OFFSET aren't same for different kernel
version as below. For pagetable levels, it sets sv57 by default and falls
back to setting sv48 at boot time if sv57 is not supported by the hardware.

For ram base, the default value is 0x80200000 for qemu riscv64 env and,
for example, is 0x200000 on the XuanTie 910 CPU.

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

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

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

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

[PATCH V4 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64

[Xianting Tian]

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@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


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH V4 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64

[Xianting Tian]

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@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


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH V4 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64

[Xianting Tian]

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@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

Re: [PATCH V4 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64

[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@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@gmail.com>

Thanks.

[1]: https://lore.kernel.org/linux-doc/20221018081755.6214-3-xianting.tian@linux.alibaba.com/

-- 
An old man doll... just what I always wanted! - Clara

Re: [PATCH V4 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64

[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@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@gmail.com>

Thanks.

[1]: https://lore.kernel.org/linux-doc/20221018081755.6214-3-xianting.tian@linux.alibaba.com/

-- 
An old man doll... just what I always wanted! - Clara


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH V4 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64

[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@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@gmail.com>

Thanks.

[1]: https://lore.kernel.org/linux-doc/20221018081755.6214-3-xianting.tian@linux.alibaba.com/

-- 
An old man doll... just what I always wanted! - Clara


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

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

[Baoquan He]

On 10/19/22 at 06:36pm, Xianting Tian wrote:
> Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC,
> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore.
> 
> Default pagetable levels and PAGE_OFFSET aren't same for different kernel
> version as below. For pagetable levels, it sets sv57 by default and falls
> back to setting sv48 at boot time if sv57 is not supported by the hardware.
> 
> For ram base, the default value is 0x80200000 for qemu riscv64 env and,
> for example, is 0x200000 on the XuanTie 910 CPU.
> 
>  * Linux Kernel 5.18 ~
>  *      PGTABLE_LEVELS = 5
>  *      PAGE_OFFSET = 0xff60000000000000
>  * Linux Kernel 5.17 ~
>  *      PGTABLE_LEVELS = 4
>  *      PAGE_OFFSET = 0xffffaf8000000000
>  * Linux Kernel 4.19 ~
>  *      PGTABLE_LEVELS = 3
>  *      PAGE_OFFSET = 0xffffffe000000000
> 
> Since these configurations change from time to time and version to version,
> it is preferable to export them via vmcoreinfo than to change the crash's
> code frequently, it can simplify the development of crash tool.
> 
> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> ---
>  arch/riscv/kernel/Makefile     |  1 +
>  arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>  2 files changed, 24 insertions(+)
>  create mode 100644 arch/riscv/kernel/crash_core.c
> 
> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> index db6e4b1294ba..4cf303a779ab 100644
> --- a/arch/riscv/kernel/Makefile
> +++ b/arch/riscv/kernel/Makefile
> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)		+= kgdb.o
>  obj-$(CONFIG_KEXEC_CORE)	+= kexec_relocate.o crash_save_regs.o machine_kexec.o
>  obj-$(CONFIG_KEXEC_FILE)	+= elf_kexec.o machine_kexec_file.o
>  obj-$(CONFIG_CRASH_DUMP)	+= crash_dump.o
> +obj-$(CONFIG_CRASH_CORE)	+= crash_core.o
>  
>  obj-$(CONFIG_JUMP_LABEL)	+= jump_label.o
>  
> diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c
> new file mode 100644
> index 000000000000..3e889d0ed7bd
> --- /dev/null
> +++ b/arch/riscv/kernel/crash_core.c
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include <linux/crash_core.h>
> +#include <linux/pagemap.h>
> +
> +void arch_crash_save_vmcoreinfo(void)
> +{
> +	VMCOREINFO_NUMBER(VA_BITS);
> +	VMCOREINFO_NUMBER(phys_ram_base);
> +
> +	vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
> +	vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
> +	vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
> +	vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
> +	vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
> +#ifdef CONFIG_64BIT
> +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
> +	vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
> +#endif
> +
> +	if (IS_ENABLED(CONFIG_64BIT))
> +		vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);

Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
ifdeffery scope, with that you can save one line of "IS_ENABLED(CONFIG_64BIT)".

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

[Baoquan He]

On 10/19/22 at 06:36pm, Xianting Tian wrote:
> Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC,
> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore.
> 
> Default pagetable levels and PAGE_OFFSET aren't same for different kernel
> version as below. For pagetable levels, it sets sv57 by default and falls
> back to setting sv48 at boot time if sv57 is not supported by the hardware.
> 
> For ram base, the default value is 0x80200000 for qemu riscv64 env and,
> for example, is 0x200000 on the XuanTie 910 CPU.
> 
>  * Linux Kernel 5.18 ~
>  *      PGTABLE_LEVELS = 5
>  *      PAGE_OFFSET = 0xff60000000000000
>  * Linux Kernel 5.17 ~
>  *      PGTABLE_LEVELS = 4
>  *      PAGE_OFFSET = 0xffffaf8000000000
>  * Linux Kernel 4.19 ~
>  *      PGTABLE_LEVELS = 3
>  *      PAGE_OFFSET = 0xffffffe000000000
> 
> Since these configurations change from time to time and version to version,
> it is preferable to export them via vmcoreinfo than to change the crash's
> code frequently, it can simplify the development of crash tool.
> 
> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> ---
>  arch/riscv/kernel/Makefile     |  1 +
>  arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>  2 files changed, 24 insertions(+)
>  create mode 100644 arch/riscv/kernel/crash_core.c
> 
> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> index db6e4b1294ba..4cf303a779ab 100644
> --- a/arch/riscv/kernel/Makefile
> +++ b/arch/riscv/kernel/Makefile
> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)		+= kgdb.o
>  obj-$(CONFIG_KEXEC_CORE)	+= kexec_relocate.o crash_save_regs.o machine_kexec.o
>  obj-$(CONFIG_KEXEC_FILE)	+= elf_kexec.o machine_kexec_file.o
>  obj-$(CONFIG_CRASH_DUMP)	+= crash_dump.o
> +obj-$(CONFIG_CRASH_CORE)	+= crash_core.o
>  
>  obj-$(CONFIG_JUMP_LABEL)	+= jump_label.o
>  
> diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c
> new file mode 100644
> index 000000000000..3e889d0ed7bd
> --- /dev/null
> +++ b/arch/riscv/kernel/crash_core.c
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include <linux/crash_core.h>
> +#include <linux/pagemap.h>
> +
> +void arch_crash_save_vmcoreinfo(void)
> +{
> +	VMCOREINFO_NUMBER(VA_BITS);
> +	VMCOREINFO_NUMBER(phys_ram_base);
> +
> +	vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
> +	vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
> +	vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
> +	vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
> +	vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
> +#ifdef CONFIG_64BIT
> +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
> +	vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
> +#endif
> +
> +	if (IS_ENABLED(CONFIG_64BIT))
> +		vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);

Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
ifdeffery scope, with that you can save one line of "IS_ENABLED(CONFIG_64BIT)".


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Baoquan He]

On 10/19/22 at 06:36pm, Xianting Tian wrote:
> Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC,
> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore.
> 
> Default pagetable levels and PAGE_OFFSET aren't same for different kernel
> version as below. For pagetable levels, it sets sv57 by default and falls
> back to setting sv48 at boot time if sv57 is not supported by the hardware.
> 
> For ram base, the default value is 0x80200000 for qemu riscv64 env and,
> for example, is 0x200000 on the XuanTie 910 CPU.
> 
>  * Linux Kernel 5.18 ~
>  *      PGTABLE_LEVELS = 5
>  *      PAGE_OFFSET = 0xff60000000000000
>  * Linux Kernel 5.17 ~
>  *      PGTABLE_LEVELS = 4
>  *      PAGE_OFFSET = 0xffffaf8000000000
>  * Linux Kernel 4.19 ~
>  *      PGTABLE_LEVELS = 3
>  *      PAGE_OFFSET = 0xffffffe000000000
> 
> Since these configurations change from time to time and version to version,
> it is preferable to export them via vmcoreinfo than to change the crash's
> code frequently, it can simplify the development of crash tool.
> 
> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> ---
>  arch/riscv/kernel/Makefile     |  1 +
>  arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>  2 files changed, 24 insertions(+)
>  create mode 100644 arch/riscv/kernel/crash_core.c
> 
> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> index db6e4b1294ba..4cf303a779ab 100644
> --- a/arch/riscv/kernel/Makefile
> +++ b/arch/riscv/kernel/Makefile
> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)		+= kgdb.o
>  obj-$(CONFIG_KEXEC_CORE)	+= kexec_relocate.o crash_save_regs.o machine_kexec.o
>  obj-$(CONFIG_KEXEC_FILE)	+= elf_kexec.o machine_kexec_file.o
>  obj-$(CONFIG_CRASH_DUMP)	+= crash_dump.o
> +obj-$(CONFIG_CRASH_CORE)	+= crash_core.o
>  
>  obj-$(CONFIG_JUMP_LABEL)	+= jump_label.o
>  
> diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c
> new file mode 100644
> index 000000000000..3e889d0ed7bd
> --- /dev/null
> +++ b/arch/riscv/kernel/crash_core.c
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include <linux/crash_core.h>
> +#include <linux/pagemap.h>
> +
> +void arch_crash_save_vmcoreinfo(void)
> +{
> +	VMCOREINFO_NUMBER(VA_BITS);
> +	VMCOREINFO_NUMBER(phys_ram_base);
> +
> +	vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
> +	vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
> +	vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
> +	vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
> +	vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
> +#ifdef CONFIG_64BIT
> +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
> +	vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
> +#endif
> +
> +	if (IS_ENABLED(CONFIG_64BIT))
> +		vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);

Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
ifdeffery scope, with that you can save one line of "IS_ENABLED(CONFIG_64BIT)".


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

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

[Xianting Tian]

在 2022/10/20 上午10:08, Baoquan He 写道:
> On 10/19/22 at 06:36pm, Xianting Tian wrote:
>> Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC,
>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore.
>>
>> Default pagetable levels and PAGE_OFFSET aren't same for different kernel
>> version as below. For pagetable levels, it sets sv57 by default and falls
>> back to setting sv48 at boot time if sv57 is not supported by the hardware.
>>
>> For ram base, the default value is 0x80200000 for qemu riscv64 env and,
>> for example, is 0x200000 on the XuanTie 910 CPU.
>>
>>   * Linux Kernel 5.18 ~
>>   *      PGTABLE_LEVELS = 5
>>   *      PAGE_OFFSET = 0xff60000000000000
>>   * Linux Kernel 5.17 ~
>>   *      PGTABLE_LEVELS = 4
>>   *      PAGE_OFFSET = 0xffffaf8000000000
>>   * Linux Kernel 4.19 ~
>>   *      PGTABLE_LEVELS = 3
>>   *      PAGE_OFFSET = 0xffffffe000000000
>>
>> Since these configurations change from time to time and version to version,
>> it is preferable to export them via vmcoreinfo than to change the crash's
>> code frequently, it can simplify the development of crash tool.
>>
>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
>> ---
>>   arch/riscv/kernel/Makefile     |  1 +
>>   arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>>   2 files changed, 24 insertions(+)
>>   create mode 100644 arch/riscv/kernel/crash_core.c
>>
>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
>> index db6e4b1294ba..4cf303a779ab 100644
>> --- a/arch/riscv/kernel/Makefile
>> +++ b/arch/riscv/kernel/Makefile
>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)		+= kgdb.o
>>   obj-$(CONFIG_KEXEC_CORE)	+= kexec_relocate.o crash_save_regs.o machine_kexec.o
>>   obj-$(CONFIG_KEXEC_FILE)	+= elf_kexec.o machine_kexec_file.o
>>   obj-$(CONFIG_CRASH_DUMP)	+= crash_dump.o
>> +obj-$(CONFIG_CRASH_CORE)	+= crash_core.o
>>   
>>   obj-$(CONFIG_JUMP_LABEL)	+= jump_label.o
>>   
>> diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c
>> new file mode 100644
>> index 000000000000..3e889d0ed7bd
>> --- /dev/null
>> +++ b/arch/riscv/kernel/crash_core.c
>> @@ -0,0 +1,23 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +
>> +#include <linux/crash_core.h>
>> +#include <linux/pagemap.h>
>> +
>> +void arch_crash_save_vmcoreinfo(void)
>> +{
>> +	VMCOREINFO_NUMBER(VA_BITS);
>> +	VMCOREINFO_NUMBER(phys_ram_base);
>> +
>> +	vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
>> +	vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
>> +	vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
>> +	vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
>> +	vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
>> +#ifdef CONFIG_64BIT
>> +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
>> +	vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
>> +#endif
>> +
>> +	if (IS_ENABLED(CONFIG_64BIT))
>> +		vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
> ifdeffery scope, with that you can save one line of "IS_ENABLED(CONFIG_64BIT)".
I followed the rule in print_vm_layout() of arch/riscv/mm/init.c, which 
used IS_ENABLED when print the value of KERNEL_LINK_ADDR.

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

[Xianting Tian]

在 2022/10/20 上午10:08, Baoquan He 写道:
> On 10/19/22 at 06:36pm, Xianting Tian wrote:
>> Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC,
>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore.
>>
>> Default pagetable levels and PAGE_OFFSET aren't same for different kernel
>> version as below. For pagetable levels, it sets sv57 by default and falls
>> back to setting sv48 at boot time if sv57 is not supported by the hardware.
>>
>> For ram base, the default value is 0x80200000 for qemu riscv64 env and,
>> for example, is 0x200000 on the XuanTie 910 CPU.
>>
>>   * Linux Kernel 5.18 ~
>>   *      PGTABLE_LEVELS = 5
>>   *      PAGE_OFFSET = 0xff60000000000000
>>   * Linux Kernel 5.17 ~
>>   *      PGTABLE_LEVELS = 4
>>   *      PAGE_OFFSET = 0xffffaf8000000000
>>   * Linux Kernel 4.19 ~
>>   *      PGTABLE_LEVELS = 3
>>   *      PAGE_OFFSET = 0xffffffe000000000
>>
>> Since these configurations change from time to time and version to version,
>> it is preferable to export them via vmcoreinfo than to change the crash's
>> code frequently, it can simplify the development of crash tool.
>>
>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
>> ---
>>   arch/riscv/kernel/Makefile     |  1 +
>>   arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>>   2 files changed, 24 insertions(+)
>>   create mode 100644 arch/riscv/kernel/crash_core.c
>>
>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
>> index db6e4b1294ba..4cf303a779ab 100644
>> --- a/arch/riscv/kernel/Makefile
>> +++ b/arch/riscv/kernel/Makefile
>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)		+= kgdb.o
>>   obj-$(CONFIG_KEXEC_CORE)	+= kexec_relocate.o crash_save_regs.o machine_kexec.o
>>   obj-$(CONFIG_KEXEC_FILE)	+= elf_kexec.o machine_kexec_file.o
>>   obj-$(CONFIG_CRASH_DUMP)	+= crash_dump.o
>> +obj-$(CONFIG_CRASH_CORE)	+= crash_core.o
>>   
>>   obj-$(CONFIG_JUMP_LABEL)	+= jump_label.o
>>   
>> diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c
>> new file mode 100644
>> index 000000000000..3e889d0ed7bd
>> --- /dev/null
>> +++ b/arch/riscv/kernel/crash_core.c
>> @@ -0,0 +1,23 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +
>> +#include <linux/crash_core.h>
>> +#include <linux/pagemap.h>
>> +
>> +void arch_crash_save_vmcoreinfo(void)
>> +{
>> +	VMCOREINFO_NUMBER(VA_BITS);
>> +	VMCOREINFO_NUMBER(phys_ram_base);
>> +
>> +	vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
>> +	vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
>> +	vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
>> +	vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
>> +	vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
>> +#ifdef CONFIG_64BIT
>> +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
>> +	vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
>> +#endif
>> +
>> +	if (IS_ENABLED(CONFIG_64BIT))
>> +		vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
> ifdeffery scope, with that you can save one line of "IS_ENABLED(CONFIG_64BIT)".
I followed the rule in print_vm_layout() of arch/riscv/mm/init.c, which 
used IS_ENABLED when print the value of KERNEL_LINK_ADDR.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Xianting Tian]

在 2022/10/20 上午10:08, Baoquan He 写道:
> On 10/19/22 at 06:36pm, Xianting Tian wrote:
>> Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC,
>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore.
>>
>> Default pagetable levels and PAGE_OFFSET aren't same for different kernel
>> version as below. For pagetable levels, it sets sv57 by default and falls
>> back to setting sv48 at boot time if sv57 is not supported by the hardware.
>>
>> For ram base, the default value is 0x80200000 for qemu riscv64 env and,
>> for example, is 0x200000 on the XuanTie 910 CPU.
>>
>>   * Linux Kernel 5.18 ~
>>   *      PGTABLE_LEVELS = 5
>>   *      PAGE_OFFSET = 0xff60000000000000
>>   * Linux Kernel 5.17 ~
>>   *      PGTABLE_LEVELS = 4
>>   *      PAGE_OFFSET = 0xffffaf8000000000
>>   * Linux Kernel 4.19 ~
>>   *      PGTABLE_LEVELS = 3
>>   *      PAGE_OFFSET = 0xffffffe000000000
>>
>> Since these configurations change from time to time and version to version,
>> it is preferable to export them via vmcoreinfo than to change the crash's
>> code frequently, it can simplify the development of crash tool.
>>
>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
>> ---
>>   arch/riscv/kernel/Makefile     |  1 +
>>   arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>>   2 files changed, 24 insertions(+)
>>   create mode 100644 arch/riscv/kernel/crash_core.c
>>
>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
>> index db6e4b1294ba..4cf303a779ab 100644
>> --- a/arch/riscv/kernel/Makefile
>> +++ b/arch/riscv/kernel/Makefile
>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)		+= kgdb.o
>>   obj-$(CONFIG_KEXEC_CORE)	+= kexec_relocate.o crash_save_regs.o machine_kexec.o
>>   obj-$(CONFIG_KEXEC_FILE)	+= elf_kexec.o machine_kexec_file.o
>>   obj-$(CONFIG_CRASH_DUMP)	+= crash_dump.o
>> +obj-$(CONFIG_CRASH_CORE)	+= crash_core.o
>>   
>>   obj-$(CONFIG_JUMP_LABEL)	+= jump_label.o
>>   
>> diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c
>> new file mode 100644
>> index 000000000000..3e889d0ed7bd
>> --- /dev/null
>> +++ b/arch/riscv/kernel/crash_core.c
>> @@ -0,0 +1,23 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +
>> +#include <linux/crash_core.h>
>> +#include <linux/pagemap.h>
>> +
>> +void arch_crash_save_vmcoreinfo(void)
>> +{
>> +	VMCOREINFO_NUMBER(VA_BITS);
>> +	VMCOREINFO_NUMBER(phys_ram_base);
>> +
>> +	vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
>> +	vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
>> +	vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
>> +	vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
>> +	vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
>> +#ifdef CONFIG_64BIT
>> +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
>> +	vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
>> +#endif
>> +
>> +	if (IS_ENABLED(CONFIG_64BIT))
>> +		vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
> ifdeffery scope, with that you can save one line of "IS_ENABLED(CONFIG_64BIT)".
I followed the rule in print_vm_layout() of arch/riscv/mm/init.c, which 
used IS_ENABLED when print the value of KERNEL_LINK_ADDR.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH V4 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64

[Xianting Tian]

在 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@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@gmail.com>
Sorry, I forgot... :(
>
> Thanks.
>
> [1]: https://lore.kernel.org/linux-doc/20221018081755.6214-3-xianting.tian@linux.alibaba.com/
>

Re: [PATCH V4 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64

[Xianting Tian]

在 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@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@gmail.com>
Sorry, I forgot... :(
>
> Thanks.
>
> [1]: https://lore.kernel.org/linux-doc/20221018081755.6214-3-xianting.tian@linux.alibaba.com/
>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH V4 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64

[Xianting Tian]

在 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@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@gmail.com>
Sorry, I forgot... :(
>
> Thanks.
>
> [1]: https://lore.kernel.org/linux-doc/20221018081755.6214-3-xianting.tian@linux.alibaba.com/
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

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

[Baoquan He]

On 10/20/22 at 10:17am, Xianting Tian wrote:
> 
> 在 2022/10/20 上午10:08, Baoquan He 写道:
> > On 10/19/22 at 06:36pm, Xianting Tian wrote:
> > > Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC,
> > > VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore.
> > > 
> > > Default pagetable levels and PAGE_OFFSET aren't same for different kernel
> > > version as below. For pagetable levels, it sets sv57 by default and falls
> > > back to setting sv48 at boot time if sv57 is not supported by the hardware.
> > > 
> > > For ram base, the default value is 0x80200000 for qemu riscv64 env and,
> > > for example, is 0x200000 on the XuanTie 910 CPU.
> > > 
> > >   * Linux Kernel 5.18 ~
> > >   *      PGTABLE_LEVELS = 5
> > >   *      PAGE_OFFSET = 0xff60000000000000
> > >   * Linux Kernel 5.17 ~
> > >   *      PGTABLE_LEVELS = 4
> > >   *      PAGE_OFFSET = 0xffffaf8000000000
> > >   * Linux Kernel 4.19 ~
> > >   *      PGTABLE_LEVELS = 3
> > >   *      PAGE_OFFSET = 0xffffffe000000000
> > > 
> > > Since these configurations change from time to time and version to version,
> > > it is preferable to export them via vmcoreinfo than to change the crash's
> > > code frequently, it can simplify the development of crash tool.
> > > 
> > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> > > ---
> > >   arch/riscv/kernel/Makefile     |  1 +
> > >   arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
> > >   2 files changed, 24 insertions(+)
> > >   create mode 100644 arch/riscv/kernel/crash_core.c
> > > 
> > > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> > > index db6e4b1294ba..4cf303a779ab 100644
> > > --- a/arch/riscv/kernel/Makefile
> > > +++ b/arch/riscv/kernel/Makefile
> > > @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)		+= kgdb.o
> > >   obj-$(CONFIG_KEXEC_CORE)	+= kexec_relocate.o crash_save_regs.o machine_kexec.o
> > >   obj-$(CONFIG_KEXEC_FILE)	+= elf_kexec.o machine_kexec_file.o
> > >   obj-$(CONFIG_CRASH_DUMP)	+= crash_dump.o
> > > +obj-$(CONFIG_CRASH_CORE)	+= crash_core.o
> > >   obj-$(CONFIG_JUMP_LABEL)	+= jump_label.o
> > > diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c
> > > new file mode 100644
> > > index 000000000000..3e889d0ed7bd
> > > --- /dev/null
> > > +++ b/arch/riscv/kernel/crash_core.c
> > > @@ -0,0 +1,23 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +
> > > +#include <linux/crash_core.h>
> > > +#include <linux/pagemap.h>
> > > +
> > > +void arch_crash_save_vmcoreinfo(void)
> > > +{
> > > +	VMCOREINFO_NUMBER(VA_BITS);
> > > +	VMCOREINFO_NUMBER(phys_ram_base);
> > > +
> > > +	vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
> > > +	vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
> > > +	vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
> > > +	vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
> > > +	vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
> > > +#ifdef CONFIG_64BIT
> > > +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
> > > +	vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
> > > +#endif
> > > +
> > > +	if (IS_ENABLED(CONFIG_64BIT))
> > > +		vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
> > Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
> > ifdeffery scope, with that you can save one line of "IS_ENABLED(CONFIG_64BIT)".
> I followed the rule in print_vm_layout() of arch/riscv/mm/init.c, which used
> IS_ENABLED when print the value of KERNEL_LINK_ADDR.
> 

I see. There's PAGE_OFFSET in the middle. Thanks.

        print_ml("lowmem", (unsigned long)PAGE_OFFSET,
                (unsigned long)high_memory)

So now, do you think if it's necessary to have another
IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?

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

[Baoquan He]

On 10/20/22 at 10:17am, Xianting Tian wrote:
> 
> 在 2022/10/20 上午10:08, Baoquan He 写道:
> > On 10/19/22 at 06:36pm, Xianting Tian wrote:
> > > Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC,
> > > VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore.
> > > 
> > > Default pagetable levels and PAGE_OFFSET aren't same for different kernel
> > > version as below. For pagetable levels, it sets sv57 by default and falls
> > > back to setting sv48 at boot time if sv57 is not supported by the hardware.
> > > 
> > > For ram base, the default value is 0x80200000 for qemu riscv64 env and,
> > > for example, is 0x200000 on the XuanTie 910 CPU.
> > > 
> > >   * Linux Kernel 5.18 ~
> > >   *      PGTABLE_LEVELS = 5
> > >   *      PAGE_OFFSET = 0xff60000000000000
> > >   * Linux Kernel 5.17 ~
> > >   *      PGTABLE_LEVELS = 4
> > >   *      PAGE_OFFSET = 0xffffaf8000000000
> > >   * Linux Kernel 4.19 ~
> > >   *      PGTABLE_LEVELS = 3
> > >   *      PAGE_OFFSET = 0xffffffe000000000
> > > 
> > > Since these configurations change from time to time and version to version,
> > > it is preferable to export them via vmcoreinfo than to change the crash's
> > > code frequently, it can simplify the development of crash tool.
> > > 
> > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> > > ---
> > >   arch/riscv/kernel/Makefile     |  1 +
> > >   arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
> > >   2 files changed, 24 insertions(+)
> > >   create mode 100644 arch/riscv/kernel/crash_core.c
> > > 
> > > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> > > index db6e4b1294ba..4cf303a779ab 100644
> > > --- a/arch/riscv/kernel/Makefile
> > > +++ b/arch/riscv/kernel/Makefile
> > > @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)		+= kgdb.o
> > >   obj-$(CONFIG_KEXEC_CORE)	+= kexec_relocate.o crash_save_regs.o machine_kexec.o
> > >   obj-$(CONFIG_KEXEC_FILE)	+= elf_kexec.o machine_kexec_file.o
> > >   obj-$(CONFIG_CRASH_DUMP)	+= crash_dump.o
> > > +obj-$(CONFIG_CRASH_CORE)	+= crash_core.o
> > >   obj-$(CONFIG_JUMP_LABEL)	+= jump_label.o
> > > diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c
> > > new file mode 100644
> > > index 000000000000..3e889d0ed7bd
> > > --- /dev/null
> > > +++ b/arch/riscv/kernel/crash_core.c
> > > @@ -0,0 +1,23 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +
> > > +#include <linux/crash_core.h>
> > > +#include <linux/pagemap.h>
> > > +
> > > +void arch_crash_save_vmcoreinfo(void)
> > > +{
> > > +	VMCOREINFO_NUMBER(VA_BITS);
> > > +	VMCOREINFO_NUMBER(phys_ram_base);
> > > +
> > > +	vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
> > > +	vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
> > > +	vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
> > > +	vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
> > > +	vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
> > > +#ifdef CONFIG_64BIT
> > > +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
> > > +	vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
> > > +#endif
> > > +
> > > +	if (IS_ENABLED(CONFIG_64BIT))
> > > +		vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
> > Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
> > ifdeffery scope, with that you can save one line of "IS_ENABLED(CONFIG_64BIT)".
> I followed the rule in print_vm_layout() of arch/riscv/mm/init.c, which used
> IS_ENABLED when print the value of KERNEL_LINK_ADDR.
> 

I see. There's PAGE_OFFSET in the middle. Thanks.

        print_ml("lowmem", (unsigned long)PAGE_OFFSET,
                (unsigned long)high_memory)

So now, do you think if it's necessary to have another
IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Baoquan He]

On 10/20/22 at 10:17am, Xianting Tian wrote:
> 
> 在 2022/10/20 上午10:08, Baoquan He 写道:
> > On 10/19/22 at 06:36pm, Xianting Tian wrote:
> > > Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC,
> > > VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore.
> > > 
> > > Default pagetable levels and PAGE_OFFSET aren't same for different kernel
> > > version as below. For pagetable levels, it sets sv57 by default and falls
> > > back to setting sv48 at boot time if sv57 is not supported by the hardware.
> > > 
> > > For ram base, the default value is 0x80200000 for qemu riscv64 env and,
> > > for example, is 0x200000 on the XuanTie 910 CPU.
> > > 
> > >   * Linux Kernel 5.18 ~
> > >   *      PGTABLE_LEVELS = 5
> > >   *      PAGE_OFFSET = 0xff60000000000000
> > >   * Linux Kernel 5.17 ~
> > >   *      PGTABLE_LEVELS = 4
> > >   *      PAGE_OFFSET = 0xffffaf8000000000
> > >   * Linux Kernel 4.19 ~
> > >   *      PGTABLE_LEVELS = 3
> > >   *      PAGE_OFFSET = 0xffffffe000000000
> > > 
> > > Since these configurations change from time to time and version to version,
> > > it is preferable to export them via vmcoreinfo than to change the crash's
> > > code frequently, it can simplify the development of crash tool.
> > > 
> > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> > > ---
> > >   arch/riscv/kernel/Makefile     |  1 +
> > >   arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
> > >   2 files changed, 24 insertions(+)
> > >   create mode 100644 arch/riscv/kernel/crash_core.c
> > > 
> > > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> > > index db6e4b1294ba..4cf303a779ab 100644
> > > --- a/arch/riscv/kernel/Makefile
> > > +++ b/arch/riscv/kernel/Makefile
> > > @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)		+= kgdb.o
> > >   obj-$(CONFIG_KEXEC_CORE)	+= kexec_relocate.o crash_save_regs.o machine_kexec.o
> > >   obj-$(CONFIG_KEXEC_FILE)	+= elf_kexec.o machine_kexec_file.o
> > >   obj-$(CONFIG_CRASH_DUMP)	+= crash_dump.o
> > > +obj-$(CONFIG_CRASH_CORE)	+= crash_core.o
> > >   obj-$(CONFIG_JUMP_LABEL)	+= jump_label.o
> > > diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c
> > > new file mode 100644
> > > index 000000000000..3e889d0ed7bd
> > > --- /dev/null
> > > +++ b/arch/riscv/kernel/crash_core.c
> > > @@ -0,0 +1,23 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +
> > > +#include <linux/crash_core.h>
> > > +#include <linux/pagemap.h>
> > > +
> > > +void arch_crash_save_vmcoreinfo(void)
> > > +{
> > > +	VMCOREINFO_NUMBER(VA_BITS);
> > > +	VMCOREINFO_NUMBER(phys_ram_base);
> > > +
> > > +	vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
> > > +	vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
> > > +	vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
> > > +	vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
> > > +	vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
> > > +#ifdef CONFIG_64BIT
> > > +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
> > > +	vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
> > > +#endif
> > > +
> > > +	if (IS_ENABLED(CONFIG_64BIT))
> > > +		vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
> > Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
> > ifdeffery scope, with that you can save one line of "IS_ENABLED(CONFIG_64BIT)".
> I followed the rule in print_vm_layout() of arch/riscv/mm/init.c, which used
> IS_ENABLED when print the value of KERNEL_LINK_ADDR.
> 

I see. There's PAGE_OFFSET in the middle. Thanks.

        print_ml("lowmem", (unsigned long)PAGE_OFFSET,
                (unsigned long)high_memory)

So now, do you think if it's necessary to have another
IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

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

[Xianting Tian]

在 2022/10/20 上午11:05, Baoquan He 写道:
> On 10/20/22 at 10:17am, Xianting Tian wrote:
>> 在 2022/10/20 上午10:08, Baoquan He 写道:
>>> On 10/19/22 at 06:36pm, Xianting Tian wrote:
>>>> Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC,
>>>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore.
>>>>
>>>> Default pagetable levels and PAGE_OFFSET aren't same for different kernel
>>>> version as below. For pagetable levels, it sets sv57 by default and falls
>>>> back to setting sv48 at boot time if sv57 is not supported by the hardware.
>>>>
>>>> For ram base, the default value is 0x80200000 for qemu riscv64 env and,
>>>> for example, is 0x200000 on the XuanTie 910 CPU.
>>>>
>>>>    * Linux Kernel 5.18 ~
>>>>    *      PGTABLE_LEVELS = 5
>>>>    *      PAGE_OFFSET = 0xff60000000000000
>>>>    * Linux Kernel 5.17 ~
>>>>    *      PGTABLE_LEVELS = 4
>>>>    *      PAGE_OFFSET = 0xffffaf8000000000
>>>>    * Linux Kernel 4.19 ~
>>>>    *      PGTABLE_LEVELS = 3
>>>>    *      PAGE_OFFSET = 0xffffffe000000000
>>>>
>>>> Since these configurations change from time to time and version to version,
>>>> it is preferable to export them via vmcoreinfo than to change the crash's
>>>> code frequently, it can simplify the development of crash tool.
>>>>
>>>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
>>>> ---
>>>>    arch/riscv/kernel/Makefile     |  1 +
>>>>    arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>>>>    2 files changed, 24 insertions(+)
>>>>    create mode 100644 arch/riscv/kernel/crash_core.c
>>>>
>>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
>>>> index db6e4b1294ba..4cf303a779ab 100644
>>>> --- a/arch/riscv/kernel/Makefile
>>>> +++ b/arch/riscv/kernel/Makefile
>>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)		+= kgdb.o
>>>>    obj-$(CONFIG_KEXEC_CORE)	+= kexec_relocate.o crash_save_regs.o machine_kexec.o
>>>>    obj-$(CONFIG_KEXEC_FILE)	+= elf_kexec.o machine_kexec_file.o
>>>>    obj-$(CONFIG_CRASH_DUMP)	+= crash_dump.o
>>>> +obj-$(CONFIG_CRASH_CORE)	+= crash_core.o
>>>>    obj-$(CONFIG_JUMP_LABEL)	+= jump_label.o
>>>> diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c
>>>> new file mode 100644
>>>> index 000000000000..3e889d0ed7bd
>>>> --- /dev/null
>>>> +++ b/arch/riscv/kernel/crash_core.c
>>>> @@ -0,0 +1,23 @@
>>>> +// SPDX-License-Identifier: GPL-2.0-only
>>>> +
>>>> +#include <linux/crash_core.h>
>>>> +#include <linux/pagemap.h>
>>>> +
>>>> +void arch_crash_save_vmcoreinfo(void)
>>>> +{
>>>> +	VMCOREINFO_NUMBER(VA_BITS);
>>>> +	VMCOREINFO_NUMBER(phys_ram_base);
>>>> +
>>>> +	vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
>>>> +	vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
>>>> +	vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
>>>> +	vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
>>>> +	vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
>>>> +#ifdef CONFIG_64BIT
>>>> +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
>>>> +	vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
>>>> +#endif
>>>> +
>>>> +	if (IS_ENABLED(CONFIG_64BIT))
>>>> +		vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
>>> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
>>> ifdeffery scope, with that you can save one line of "IS_ENABLED(CONFIG_64BIT)".
>> I followed the rule in print_vm_layout() of arch/riscv/mm/init.c, which used
>> IS_ENABLED when print the value of KERNEL_LINK_ADDR.
>>
> I see. There's PAGE_OFFSET in the middle. Thanks.
>
>          print_ml("lowmem", (unsigned long)PAGE_OFFSET,
>                  (unsigned long)high_memory)
>
> So now, do you think if it's necessary to have another
> IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?

For which MACRO?  I think current code for PAGE_OFFSET is OK.

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

[Xianting Tian]

在 2022/10/20 上午11:05, Baoquan He 写道:
> On 10/20/22 at 10:17am, Xianting Tian wrote:
>> 在 2022/10/20 上午10:08, Baoquan He 写道:
>>> On 10/19/22 at 06:36pm, Xianting Tian wrote:
>>>> Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC,
>>>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore.
>>>>
>>>> Default pagetable levels and PAGE_OFFSET aren't same for different kernel
>>>> version as below. For pagetable levels, it sets sv57 by default and falls
>>>> back to setting sv48 at boot time if sv57 is not supported by the hardware.
>>>>
>>>> For ram base, the default value is 0x80200000 for qemu riscv64 env and,
>>>> for example, is 0x200000 on the XuanTie 910 CPU.
>>>>
>>>>    * Linux Kernel 5.18 ~
>>>>    *      PGTABLE_LEVELS = 5
>>>>    *      PAGE_OFFSET = 0xff60000000000000
>>>>    * Linux Kernel 5.17 ~
>>>>    *      PGTABLE_LEVELS = 4
>>>>    *      PAGE_OFFSET = 0xffffaf8000000000
>>>>    * Linux Kernel 4.19 ~
>>>>    *      PGTABLE_LEVELS = 3
>>>>    *      PAGE_OFFSET = 0xffffffe000000000
>>>>
>>>> Since these configurations change from time to time and version to version,
>>>> it is preferable to export them via vmcoreinfo than to change the crash's
>>>> code frequently, it can simplify the development of crash tool.
>>>>
>>>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
>>>> ---
>>>>    arch/riscv/kernel/Makefile     |  1 +
>>>>    arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>>>>    2 files changed, 24 insertions(+)
>>>>    create mode 100644 arch/riscv/kernel/crash_core.c
>>>>
>>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
>>>> index db6e4b1294ba..4cf303a779ab 100644
>>>> --- a/arch/riscv/kernel/Makefile
>>>> +++ b/arch/riscv/kernel/Makefile
>>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)		+= kgdb.o
>>>>    obj-$(CONFIG_KEXEC_CORE)	+= kexec_relocate.o crash_save_regs.o machine_kexec.o
>>>>    obj-$(CONFIG_KEXEC_FILE)	+= elf_kexec.o machine_kexec_file.o
>>>>    obj-$(CONFIG_CRASH_DUMP)	+= crash_dump.o
>>>> +obj-$(CONFIG_CRASH_CORE)	+= crash_core.o
>>>>    obj-$(CONFIG_JUMP_LABEL)	+= jump_label.o
>>>> diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c
>>>> new file mode 100644
>>>> index 000000000000..3e889d0ed7bd
>>>> --- /dev/null
>>>> +++ b/arch/riscv/kernel/crash_core.c
>>>> @@ -0,0 +1,23 @@
>>>> +// SPDX-License-Identifier: GPL-2.0-only
>>>> +
>>>> +#include <linux/crash_core.h>
>>>> +#include <linux/pagemap.h>
>>>> +
>>>> +void arch_crash_save_vmcoreinfo(void)
>>>> +{
>>>> +	VMCOREINFO_NUMBER(VA_BITS);
>>>> +	VMCOREINFO_NUMBER(phys_ram_base);
>>>> +
>>>> +	vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
>>>> +	vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
>>>> +	vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
>>>> +	vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
>>>> +	vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
>>>> +#ifdef CONFIG_64BIT
>>>> +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
>>>> +	vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
>>>> +#endif
>>>> +
>>>> +	if (IS_ENABLED(CONFIG_64BIT))
>>>> +		vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
>>> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
>>> ifdeffery scope, with that you can save one line of "IS_ENABLED(CONFIG_64BIT)".
>> I followed the rule in print_vm_layout() of arch/riscv/mm/init.c, which used
>> IS_ENABLED when print the value of KERNEL_LINK_ADDR.
>>
> I see. There's PAGE_OFFSET in the middle. Thanks.
>
>          print_ml("lowmem", (unsigned long)PAGE_OFFSET,
>                  (unsigned long)high_memory)
>
> So now, do you think if it's necessary to have another
> IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?

For which MACRO?  I think current code for PAGE_OFFSET is OK.


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Xianting Tian]

在 2022/10/20 上午11:05, Baoquan He 写道:
> On 10/20/22 at 10:17am, Xianting Tian wrote:
>> 在 2022/10/20 上午10:08, Baoquan He 写道:
>>> On 10/19/22 at 06:36pm, Xianting Tian wrote:
>>>> Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC,
>>>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore.
>>>>
>>>> Default pagetable levels and PAGE_OFFSET aren't same for different kernel
>>>> version as below. For pagetable levels, it sets sv57 by default and falls
>>>> back to setting sv48 at boot time if sv57 is not supported by the hardware.
>>>>
>>>> For ram base, the default value is 0x80200000 for qemu riscv64 env and,
>>>> for example, is 0x200000 on the XuanTie 910 CPU.
>>>>
>>>>    * Linux Kernel 5.18 ~
>>>>    *      PGTABLE_LEVELS = 5
>>>>    *      PAGE_OFFSET = 0xff60000000000000
>>>>    * Linux Kernel 5.17 ~
>>>>    *      PGTABLE_LEVELS = 4
>>>>    *      PAGE_OFFSET = 0xffffaf8000000000
>>>>    * Linux Kernel 4.19 ~
>>>>    *      PGTABLE_LEVELS = 3
>>>>    *      PAGE_OFFSET = 0xffffffe000000000
>>>>
>>>> Since these configurations change from time to time and version to version,
>>>> it is preferable to export them via vmcoreinfo than to change the crash's
>>>> code frequently, it can simplify the development of crash tool.
>>>>
>>>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
>>>> ---
>>>>    arch/riscv/kernel/Makefile     |  1 +
>>>>    arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>>>>    2 files changed, 24 insertions(+)
>>>>    create mode 100644 arch/riscv/kernel/crash_core.c
>>>>
>>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
>>>> index db6e4b1294ba..4cf303a779ab 100644
>>>> --- a/arch/riscv/kernel/Makefile
>>>> +++ b/arch/riscv/kernel/Makefile
>>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)		+= kgdb.o
>>>>    obj-$(CONFIG_KEXEC_CORE)	+= kexec_relocate.o crash_save_regs.o machine_kexec.o
>>>>    obj-$(CONFIG_KEXEC_FILE)	+= elf_kexec.o machine_kexec_file.o
>>>>    obj-$(CONFIG_CRASH_DUMP)	+= crash_dump.o
>>>> +obj-$(CONFIG_CRASH_CORE)	+= crash_core.o
>>>>    obj-$(CONFIG_JUMP_LABEL)	+= jump_label.o
>>>> diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c
>>>> new file mode 100644
>>>> index 000000000000..3e889d0ed7bd
>>>> --- /dev/null
>>>> +++ b/arch/riscv/kernel/crash_core.c
>>>> @@ -0,0 +1,23 @@
>>>> +// SPDX-License-Identifier: GPL-2.0-only
>>>> +
>>>> +#include <linux/crash_core.h>
>>>> +#include <linux/pagemap.h>
>>>> +
>>>> +void arch_crash_save_vmcoreinfo(void)
>>>> +{
>>>> +	VMCOREINFO_NUMBER(VA_BITS);
>>>> +	VMCOREINFO_NUMBER(phys_ram_base);
>>>> +
>>>> +	vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
>>>> +	vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
>>>> +	vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
>>>> +	vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
>>>> +	vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
>>>> +#ifdef CONFIG_64BIT
>>>> +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
>>>> +	vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
>>>> +#endif
>>>> +
>>>> +	if (IS_ENABLED(CONFIG_64BIT))
>>>> +		vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
>>> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
>>> ifdeffery scope, with that you can save one line of "IS_ENABLED(CONFIG_64BIT)".
>> I followed the rule in print_vm_layout() of arch/riscv/mm/init.c, which used
>> IS_ENABLED when print the value of KERNEL_LINK_ADDR.
>>
> I see. There's PAGE_OFFSET in the middle. Thanks.
>
>          print_ml("lowmem", (unsigned long)PAGE_OFFSET,
>                  (unsigned long)high_memory)
>
> So now, do you think if it's necessary to have another
> IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?

For which MACRO?  I think current code for PAGE_OFFSET is OK.


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

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

[Guo Ren]

Tested-by: Guo Ren <guoren@kernel.org>

Don't forget the another two kdump fixups [1]
[1] https://lore.kernel.org/all/20221020141603.2856206-3-guoren@kernel.org/

    Only the patch without [1]:
    crash> help -r
    CPU 0: [OFFLINE]

    CPU 1:
    epc : ffffffff80009ff0 ra : ffffffff800b789a sp : ff2000001098bb40
     gp : ffffffff815fca60 tp : ff60000004680000 t0 : 6666666666663c5b
     t1 : 0000000000000000 t2 : 666666666666663c s0 : ff2000001098bc90
     s1 : ffffffff81600798 a0 : ff2000001098bb48 a1 : 0000000000000000
     a2 : 0000000000000000 a3 : 0000000000000001 a4 : 0000000000000000
     a5 : ff60000004690800 a6 : 0000000000000000 a7 : 0000000000000000
     s2 : ff2000001098bb48 s3 : ffffffff81093ec8 s4 : ffffffff816004ac
     s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80e7f720
     s8 : 00fffffffffff3f0 s9 : 0000000000000007 s10: 00aaaaaaaab98700
     s11: 0000000000000001 t3 : ffffffff819a8097 t4 : ffffffff819a8097
     t5 : ffffffff819a8098 t6 : ff2000001098b9a8

    CPU 2: [OFFLINE]

    CPU 3: [OFFLINE]

    The patch with [1]:
    crash> help -r
    CPU 0:
    epc : ffffffff80003f34 ra : ffffffff808caa7c sp : ffffffff81403eb0
     gp : ffffffff815fcb48 tp : ffffffff81413400 t0 : 0000000000000000
     t1 : 0000000000000000 t2 : 0000000000000000 s0 : ffffffff81403ec0
     s1 : 0000000000000000 a0 : 0000000000000000 a1 : 0000000000000000
     a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000
     a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000
     s2 : ffffffff816001c8 s3 : ffffffff81600370 s4 : ffffffff80c32e18
     s5 : ffffffff819d3018 s6 : ffffffff810e2110 s7 : 0000000000000000
     s8 : 0000000000000000 s9 : 0000000080039eac s10: 0000000000000000
     s11: 0000000000000000 t3 : 0000000000000000 t4 : 0000000000000000
     t5 : 0000000000000000 t6 : 0000000000000000

    CPU 1:
    epc : ffffffff80003f34 ra : ffffffff808caa7c sp : ff2000000068bf30
     gp : ffffffff815fcb48 tp : ff6000000240d400 t0 : 0000000000000000
     t1 : 0000000000000000 t2 : 0000000000000000 s0 : ff2000000068bf40
     s1 : 0000000000000001 a0 : 0000000000000000 a1 : 0000000000000000
     a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000
     a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000
     s2 : ffffffff816001c8 s3 : ffffffff81600370 s4 : ffffffff80c32e18
     s5 : ffffffff819d3018 s6 : ffffffff810e2110 s7 : 0000000000000000
     s8 : 0000000000000000 s9 : 0000000080039ea8 s10: 0000000000000000
     s11: 0000000000000000 t3 : 0000000000000000 t4 : 0000000000000000
     t5 : 0000000000000000 t6 : 0000000000000000

    CPU 2:
    epc : ffffffff80003f34 ra : ffffffff808caa7c sp : ff20000000693f30
     gp : ffffffff815fcb48 tp : ff6000000240e900 t0 : 0000000000000000
     t1 : 0000000000000000 t2 : 0000000000000000 s0 : ff20000000693f40
     s1 : 0000000000000002 a0 : 0000000000000000 a1 : 0000000000000000
     a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000
     a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000
     s2 : ffffffff816001c8 s3 : ffffffff81600370 s4 : ffffffff80c32e18
     s5 : ffffffff819d3018 s6 : ffffffff810e2110 s7 : 0000000000000000
     s8 : 0000000000000000 s9 : 0000000080039eb0 s10: 0000000000000000
     s11: 0000000000000000 t3 : 0000000000000000 t4 : 0000000000000000
     t5 : 0000000000000000 t6 : 0000000000000000

    CPU 3:
    epc : ffffffff8000a1e4 ra : ffffffff800b7bba sp : ff200000109bbb40
     gp : ffffffff815fcb48 tp : ff6000000373aa00 t0 : 6666666666663c5b
     t1 : 0000000000000000 t2 : 666666666666663c s0 : ff200000109bbc90
     s1 : ffffffff816007a0 a0 : ff200000109bbb48 a1 : 0000000000000000
     a2 : 0000000000000000 a3 : 0000000000000001 a4 : 0000000000000000
     a5 : ff60000002c61c00 a6 : 0000000000000000 a7 : 0000000000000000
     s2 : ff200000109bbb48 s3 : ffffffff810941a8 s4 : ffffffff816004b4
     s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80e7f7a0
     s8 : 00fffffffffff3f0 s9 : 0000000000000007 s10: 00aaaaaaaab98700
     s11: 0000000000000001 t3 : ffffffff819a8097 t4 : ffffffff819a8097
     t5 : ffffffff819a8098 t6 : ff200000109bb9a8

On Wed, Oct 19, 2022 at 6:36 PM Xianting Tian
<xianting.tian@linux.alibaba.com> wrote:
>
> Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC,
> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore.
>
> Default pagetable levels and PAGE_OFFSET aren't same for different kernel
> version as below. For pagetable levels, it sets sv57 by default and falls
> back to setting sv48 at boot time if sv57 is not supported by the hardware.
>
> For ram base, the default value is 0x80200000 for qemu riscv64 env and,
> for example, is 0x200000 on the XuanTie 910 CPU.
>
>  * Linux Kernel 5.18 ~
>  *      PGTABLE_LEVELS = 5
>  *      PAGE_OFFSET = 0xff60000000000000
>  * Linux Kernel 5.17 ~
>  *      PGTABLE_LEVELS = 4
>  *      PAGE_OFFSET = 0xffffaf8000000000
>  * Linux Kernel 4.19 ~
>  *      PGTABLE_LEVELS = 3
>  *      PAGE_OFFSET = 0xffffffe000000000
>
> Since these configurations change from time to time and version to version,
> it is preferable to export them via vmcoreinfo than to change the crash's
> code frequently, it can simplify the development of crash tool.
>
> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> ---
>  arch/riscv/kernel/Makefile     |  1 +
>  arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>  2 files changed, 24 insertions(+)
>  create mode 100644 arch/riscv/kernel/crash_core.c
>
> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> index db6e4b1294ba..4cf303a779ab 100644
> --- a/arch/riscv/kernel/Makefile
> +++ b/arch/riscv/kernel/Makefile
> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)            += kgdb.o
>  obj-$(CONFIG_KEXEC_CORE)       += kexec_relocate.o crash_save_regs.o machine_kexec.o
>  obj-$(CONFIG_KEXEC_FILE)       += elf_kexec.o machine_kexec_file.o
>  obj-$(CONFIG_CRASH_DUMP)       += crash_dump.o
> +obj-$(CONFIG_CRASH_CORE)       += crash_core.o
>
>  obj-$(CONFIG_JUMP_LABEL)       += jump_label.o
>
> diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c
> new file mode 100644
> index 000000000000..3e889d0ed7bd
> --- /dev/null
> +++ b/arch/riscv/kernel/crash_core.c
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include <linux/crash_core.h>
> +#include <linux/pagemap.h>
> +
> +void arch_crash_save_vmcoreinfo(void)
> +{
> +       VMCOREINFO_NUMBER(VA_BITS);
> +       VMCOREINFO_NUMBER(phys_ram_base);
> +
> +       vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
> +       vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
> +       vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
> +#ifdef CONFIG_64BIT
> +       vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
> +       vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
> +#endif
> +
> +       if (IS_ENABLED(CONFIG_64BIT))
> +               vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
> +}
> --
> 2.17.1
>


-- 
Best Regards
 Guo Ren

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

[Guo Ren]

Tested-by: Guo Ren <guoren@kernel.org>

Don't forget the another two kdump fixups [1]
[1] https://lore.kernel.org/all/20221020141603.2856206-3-guoren@kernel.org/

    Only the patch without [1]:
    crash> help -r
    CPU 0: [OFFLINE]

    CPU 1:
    epc : ffffffff80009ff0 ra : ffffffff800b789a sp : ff2000001098bb40
     gp : ffffffff815fca60 tp : ff60000004680000 t0 : 6666666666663c5b
     t1 : 0000000000000000 t2 : 666666666666663c s0 : ff2000001098bc90
     s1 : ffffffff81600798 a0 : ff2000001098bb48 a1 : 0000000000000000
     a2 : 0000000000000000 a3 : 0000000000000001 a4 : 0000000000000000
     a5 : ff60000004690800 a6 : 0000000000000000 a7 : 0000000000000000
     s2 : ff2000001098bb48 s3 : ffffffff81093ec8 s4 : ffffffff816004ac
     s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80e7f720
     s8 : 00fffffffffff3f0 s9 : 0000000000000007 s10: 00aaaaaaaab98700
     s11: 0000000000000001 t3 : ffffffff819a8097 t4 : ffffffff819a8097
     t5 : ffffffff819a8098 t6 : ff2000001098b9a8

    CPU 2: [OFFLINE]

    CPU 3: [OFFLINE]

    The patch with [1]:
    crash> help -r
    CPU 0:
    epc : ffffffff80003f34 ra : ffffffff808caa7c sp : ffffffff81403eb0
     gp : ffffffff815fcb48 tp : ffffffff81413400 t0 : 0000000000000000
     t1 : 0000000000000000 t2 : 0000000000000000 s0 : ffffffff81403ec0
     s1 : 0000000000000000 a0 : 0000000000000000 a1 : 0000000000000000
     a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000
     a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000
     s2 : ffffffff816001c8 s3 : ffffffff81600370 s4 : ffffffff80c32e18
     s5 : ffffffff819d3018 s6 : ffffffff810e2110 s7 : 0000000000000000
     s8 : 0000000000000000 s9 : 0000000080039eac s10: 0000000000000000
     s11: 0000000000000000 t3 : 0000000000000000 t4 : 0000000000000000
     t5 : 0000000000000000 t6 : 0000000000000000

    CPU 1:
    epc : ffffffff80003f34 ra : ffffffff808caa7c sp : ff2000000068bf30
     gp : ffffffff815fcb48 tp : ff6000000240d400 t0 : 0000000000000000
     t1 : 0000000000000000 t2 : 0000000000000000 s0 : ff2000000068bf40
     s1 : 0000000000000001 a0 : 0000000000000000 a1 : 0000000000000000
     a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000
     a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000
     s2 : ffffffff816001c8 s3 : ffffffff81600370 s4 : ffffffff80c32e18
     s5 : ffffffff819d3018 s6 : ffffffff810e2110 s7 : 0000000000000000
     s8 : 0000000000000000 s9 : 0000000080039ea8 s10: 0000000000000000
     s11: 0000000000000000 t3 : 0000000000000000 t4 : 0000000000000000
     t5 : 0000000000000000 t6 : 0000000000000000

    CPU 2:
    epc : ffffffff80003f34 ra : ffffffff808caa7c sp : ff20000000693f30
     gp : ffffffff815fcb48 tp : ff6000000240e900 t0 : 0000000000000000
     t1 : 0000000000000000 t2 : 0000000000000000 s0 : ff20000000693f40
     s1 : 0000000000000002 a0 : 0000000000000000 a1 : 0000000000000000
     a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000
     a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000
     s2 : ffffffff816001c8 s3 : ffffffff81600370 s4 : ffffffff80c32e18
     s5 : ffffffff819d3018 s6 : ffffffff810e2110 s7 : 0000000000000000
     s8 : 0000000000000000 s9 : 0000000080039eb0 s10: 0000000000000000
     s11: 0000000000000000 t3 : 0000000000000000 t4 : 0000000000000000
     t5 : 0000000000000000 t6 : 0000000000000000

    CPU 3:
    epc : ffffffff8000a1e4 ra : ffffffff800b7bba sp : ff200000109bbb40
     gp : ffffffff815fcb48 tp : ff6000000373aa00 t0 : 6666666666663c5b
     t1 : 0000000000000000 t2 : 666666666666663c s0 : ff200000109bbc90
     s1 : ffffffff816007a0 a0 : ff200000109bbb48 a1 : 0000000000000000
     a2 : 0000000000000000 a3 : 0000000000000001 a4 : 0000000000000000
     a5 : ff60000002c61c00 a6 : 0000000000000000 a7 : 0000000000000000
     s2 : ff200000109bbb48 s3 : ffffffff810941a8 s4 : ffffffff816004b4
     s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80e7f7a0
     s8 : 00fffffffffff3f0 s9 : 0000000000000007 s10: 00aaaaaaaab98700
     s11: 0000000000000001 t3 : ffffffff819a8097 t4 : ffffffff819a8097
     t5 : ffffffff819a8098 t6 : ff200000109bb9a8

On Wed, Oct 19, 2022 at 6:36 PM Xianting Tian
<xianting.tian@linux.alibaba.com> wrote:
>
> Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC,
> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore.
>
> Default pagetable levels and PAGE_OFFSET aren't same for different kernel
> version as below. For pagetable levels, it sets sv57 by default and falls
> back to setting sv48 at boot time if sv57 is not supported by the hardware.
>
> For ram base, the default value is 0x80200000 for qemu riscv64 env and,
> for example, is 0x200000 on the XuanTie 910 CPU.
>
>  * Linux Kernel 5.18 ~
>  *      PGTABLE_LEVELS = 5
>  *      PAGE_OFFSET = 0xff60000000000000
>  * Linux Kernel 5.17 ~
>  *      PGTABLE_LEVELS = 4
>  *      PAGE_OFFSET = 0xffffaf8000000000
>  * Linux Kernel 4.19 ~
>  *      PGTABLE_LEVELS = 3
>  *      PAGE_OFFSET = 0xffffffe000000000
>
> Since these configurations change from time to time and version to version,
> it is preferable to export them via vmcoreinfo than to change the crash's
> code frequently, it can simplify the development of crash tool.
>
> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> ---
>  arch/riscv/kernel/Makefile     |  1 +
>  arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>  2 files changed, 24 insertions(+)
>  create mode 100644 arch/riscv/kernel/crash_core.c
>
> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> index db6e4b1294ba..4cf303a779ab 100644
> --- a/arch/riscv/kernel/Makefile
> +++ b/arch/riscv/kernel/Makefile
> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)            += kgdb.o
>  obj-$(CONFIG_KEXEC_CORE)       += kexec_relocate.o crash_save_regs.o machine_kexec.o
>  obj-$(CONFIG_KEXEC_FILE)       += elf_kexec.o machine_kexec_file.o
>  obj-$(CONFIG_CRASH_DUMP)       += crash_dump.o
> +obj-$(CONFIG_CRASH_CORE)       += crash_core.o
>
>  obj-$(CONFIG_JUMP_LABEL)       += jump_label.o
>
> diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c
> new file mode 100644
> index 000000000000..3e889d0ed7bd
> --- /dev/null
> +++ b/arch/riscv/kernel/crash_core.c
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include <linux/crash_core.h>
> +#include <linux/pagemap.h>
> +
> +void arch_crash_save_vmcoreinfo(void)
> +{
> +       VMCOREINFO_NUMBER(VA_BITS);
> +       VMCOREINFO_NUMBER(phys_ram_base);
> +
> +       vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
> +       vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
> +       vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
> +#ifdef CONFIG_64BIT
> +       vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
> +       vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
> +#endif
> +
> +       if (IS_ENABLED(CONFIG_64BIT))
> +               vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
> +}
> --
> 2.17.1
>


-- 
Best Regards
 Guo Ren

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Guo Ren]

Tested-by: Guo Ren <guoren@kernel.org>

Don't forget the another two kdump fixups [1]
[1] https://lore.kernel.org/all/20221020141603.2856206-3-guoren@kernel.org/

    Only the patch without [1]:
    crash> help -r
    CPU 0: [OFFLINE]

    CPU 1:
    epc : ffffffff80009ff0 ra : ffffffff800b789a sp : ff2000001098bb40
     gp : ffffffff815fca60 tp : ff60000004680000 t0 : 6666666666663c5b
     t1 : 0000000000000000 t2 : 666666666666663c s0 : ff2000001098bc90
     s1 : ffffffff81600798 a0 : ff2000001098bb48 a1 : 0000000000000000
     a2 : 0000000000000000 a3 : 0000000000000001 a4 : 0000000000000000
     a5 : ff60000004690800 a6 : 0000000000000000 a7 : 0000000000000000
     s2 : ff2000001098bb48 s3 : ffffffff81093ec8 s4 : ffffffff816004ac
     s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80e7f720
     s8 : 00fffffffffff3f0 s9 : 0000000000000007 s10: 00aaaaaaaab98700
     s11: 0000000000000001 t3 : ffffffff819a8097 t4 : ffffffff819a8097
     t5 : ffffffff819a8098 t6 : ff2000001098b9a8

    CPU 2: [OFFLINE]

    CPU 3: [OFFLINE]

    The patch with [1]:
    crash> help -r
    CPU 0:
    epc : ffffffff80003f34 ra : ffffffff808caa7c sp : ffffffff81403eb0
     gp : ffffffff815fcb48 tp : ffffffff81413400 t0 : 0000000000000000
     t1 : 0000000000000000 t2 : 0000000000000000 s0 : ffffffff81403ec0
     s1 : 0000000000000000 a0 : 0000000000000000 a1 : 0000000000000000
     a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000
     a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000
     s2 : ffffffff816001c8 s3 : ffffffff81600370 s4 : ffffffff80c32e18
     s5 : ffffffff819d3018 s6 : ffffffff810e2110 s7 : 0000000000000000
     s8 : 0000000000000000 s9 : 0000000080039eac s10: 0000000000000000
     s11: 0000000000000000 t3 : 0000000000000000 t4 : 0000000000000000
     t5 : 0000000000000000 t6 : 0000000000000000

    CPU 1:
    epc : ffffffff80003f34 ra : ffffffff808caa7c sp : ff2000000068bf30
     gp : ffffffff815fcb48 tp : ff6000000240d400 t0 : 0000000000000000
     t1 : 0000000000000000 t2 : 0000000000000000 s0 : ff2000000068bf40
     s1 : 0000000000000001 a0 : 0000000000000000 a1 : 0000000000000000
     a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000
     a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000
     s2 : ffffffff816001c8 s3 : ffffffff81600370 s4 : ffffffff80c32e18
     s5 : ffffffff819d3018 s6 : ffffffff810e2110 s7 : 0000000000000000
     s8 : 0000000000000000 s9 : 0000000080039ea8 s10: 0000000000000000
     s11: 0000000000000000 t3 : 0000000000000000 t4 : 0000000000000000
     t5 : 0000000000000000 t6 : 0000000000000000

    CPU 2:
    epc : ffffffff80003f34 ra : ffffffff808caa7c sp : ff20000000693f30
     gp : ffffffff815fcb48 tp : ff6000000240e900 t0 : 0000000000000000
     t1 : 0000000000000000 t2 : 0000000000000000 s0 : ff20000000693f40
     s1 : 0000000000000002 a0 : 0000000000000000 a1 : 0000000000000000
     a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000
     a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000
     s2 : ffffffff816001c8 s3 : ffffffff81600370 s4 : ffffffff80c32e18
     s5 : ffffffff819d3018 s6 : ffffffff810e2110 s7 : 0000000000000000
     s8 : 0000000000000000 s9 : 0000000080039eb0 s10: 0000000000000000
     s11: 0000000000000000 t3 : 0000000000000000 t4 : 0000000000000000
     t5 : 0000000000000000 t6 : 0000000000000000

    CPU 3:
    epc : ffffffff8000a1e4 ra : ffffffff800b7bba sp : ff200000109bbb40
     gp : ffffffff815fcb48 tp : ff6000000373aa00 t0 : 6666666666663c5b
     t1 : 0000000000000000 t2 : 666666666666663c s0 : ff200000109bbc90
     s1 : ffffffff816007a0 a0 : ff200000109bbb48 a1 : 0000000000000000
     a2 : 0000000000000000 a3 : 0000000000000001 a4 : 0000000000000000
     a5 : ff60000002c61c00 a6 : 0000000000000000 a7 : 0000000000000000
     s2 : ff200000109bbb48 s3 : ffffffff810941a8 s4 : ffffffff816004b4
     s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80e7f7a0
     s8 : 00fffffffffff3f0 s9 : 0000000000000007 s10: 00aaaaaaaab98700
     s11: 0000000000000001 t3 : ffffffff819a8097 t4 : ffffffff819a8097
     t5 : ffffffff819a8098 t6 : ff200000109bb9a8

On Wed, Oct 19, 2022 at 6:36 PM Xianting Tian
<xianting.tian@linux.alibaba.com> wrote:
>
> Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC,
> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore.
>
> Default pagetable levels and PAGE_OFFSET aren't same for different kernel
> version as below. For pagetable levels, it sets sv57 by default and falls
> back to setting sv48 at boot time if sv57 is not supported by the hardware.
>
> For ram base, the default value is 0x80200000 for qemu riscv64 env and,
> for example, is 0x200000 on the XuanTie 910 CPU.
>
>  * Linux Kernel 5.18 ~
>  *      PGTABLE_LEVELS = 5
>  *      PAGE_OFFSET = 0xff60000000000000
>  * Linux Kernel 5.17 ~
>  *      PGTABLE_LEVELS = 4
>  *      PAGE_OFFSET = 0xffffaf8000000000
>  * Linux Kernel 4.19 ~
>  *      PGTABLE_LEVELS = 3
>  *      PAGE_OFFSET = 0xffffffe000000000
>
> Since these configurations change from time to time and version to version,
> it is preferable to export them via vmcoreinfo than to change the crash's
> code frequently, it can simplify the development of crash tool.
>
> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> ---
>  arch/riscv/kernel/Makefile     |  1 +
>  arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>  2 files changed, 24 insertions(+)
>  create mode 100644 arch/riscv/kernel/crash_core.c
>
> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> index db6e4b1294ba..4cf303a779ab 100644
> --- a/arch/riscv/kernel/Makefile
> +++ b/arch/riscv/kernel/Makefile
> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)            += kgdb.o
>  obj-$(CONFIG_KEXEC_CORE)       += kexec_relocate.o crash_save_regs.o machine_kexec.o
>  obj-$(CONFIG_KEXEC_FILE)       += elf_kexec.o machine_kexec_file.o
>  obj-$(CONFIG_CRASH_DUMP)       += crash_dump.o
> +obj-$(CONFIG_CRASH_CORE)       += crash_core.o
>
>  obj-$(CONFIG_JUMP_LABEL)       += jump_label.o
>
> diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c
> new file mode 100644
> index 000000000000..3e889d0ed7bd
> --- /dev/null
> +++ b/arch/riscv/kernel/crash_core.c
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include <linux/crash_core.h>
> +#include <linux/pagemap.h>
> +
> +void arch_crash_save_vmcoreinfo(void)
> +{
> +       VMCOREINFO_NUMBER(VA_BITS);
> +       VMCOREINFO_NUMBER(phys_ram_base);
> +
> +       vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
> +       vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
> +       vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
> +#ifdef CONFIG_64BIT
> +       vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
> +       vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
> +#endif
> +
> +       if (IS_ENABLED(CONFIG_64BIT))
> +               vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
> +}
> --
> 2.17.1
>


-- 
Best Regards
 Guo Ren

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

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

[Xianting Tian]

Hi Palmer, Conor

Is this version OK for you? Do you plan to apply this patch set? thanks

在 2022/10/20 下午12:40, Xianting Tian 写道:
>
> 在 2022/10/20 上午11:05, Baoquan He 写道:
>> On 10/20/22 at 10:17am, Xianting Tian wrote:
>>> 在 2022/10/20 上午10:08, Baoquan He 写道:
>>>> On 10/19/22 at 06:36pm, Xianting Tian wrote:
>>>>> Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, 
>>>>> VMALLOC,
>>>>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for 
>>>>> vmcore.
>>>>>
>>>>> Default pagetable levels and PAGE_OFFSET aren't same for different 
>>>>> kernel
>>>>> version as below. For pagetable levels, it sets sv57 by default 
>>>>> and falls
>>>>> back to setting sv48 at boot time if sv57 is not supported by the 
>>>>> hardware.
>>>>>
>>>>> For ram base, the default value is 0x80200000 for qemu riscv64 env 
>>>>> and,
>>>>> for example, is 0x200000 on the XuanTie 910 CPU.
>>>>>
>>>>>    * Linux Kernel 5.18 ~
>>>>>    *      PGTABLE_LEVELS = 5
>>>>>    *      PAGE_OFFSET = 0xff60000000000000
>>>>>    * Linux Kernel 5.17 ~
>>>>>    *      PGTABLE_LEVELS = 4
>>>>>    *      PAGE_OFFSET = 0xffffaf8000000000
>>>>>    * Linux Kernel 4.19 ~
>>>>>    *      PGTABLE_LEVELS = 3
>>>>>    *      PAGE_OFFSET = 0xffffffe000000000
>>>>>
>>>>> Since these configurations change from time to time and version to 
>>>>> version,
>>>>> it is preferable to export them via vmcoreinfo than to change the 
>>>>> crash's
>>>>> code frequently, it can simplify the development of crash tool.
>>>>>
>>>>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
>>>>> ---
>>>>>    arch/riscv/kernel/Makefile     |  1 +
>>>>>    arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>>>>>    2 files changed, 24 insertions(+)
>>>>>    create mode 100644 arch/riscv/kernel/crash_core.c
>>>>>
>>>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
>>>>> index db6e4b1294ba..4cf303a779ab 100644
>>>>> --- a/arch/riscv/kernel/Makefile
>>>>> +++ b/arch/riscv/kernel/Makefile
>>>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
>>>>>    obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o 
>>>>> crash_save_regs.o machine_kexec.o
>>>>>    obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
>>>>>    obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
>>>>> +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
>>>>>    obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
>>>>> diff --git a/arch/riscv/kernel/crash_core.c 
>>>>> b/arch/riscv/kernel/crash_core.c
>>>>> new file mode 100644
>>>>> index 000000000000..3e889d0ed7bd
>>>>> --- /dev/null
>>>>> +++ b/arch/riscv/kernel/crash_core.c
>>>>> @@ -0,0 +1,23 @@
>>>>> +// SPDX-License-Identifier: GPL-2.0-only
>>>>> +
>>>>> +#include <linux/crash_core.h>
>>>>> +#include <linux/pagemap.h>
>>>>> +
>>>>> +void arch_crash_save_vmcoreinfo(void)
>>>>> +{
>>>>> +    VMCOREINFO_NUMBER(VA_BITS);
>>>>> +    VMCOREINFO_NUMBER(phys_ram_base);
>>>>> +
>>>>> +    vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", 
>>>>> PAGE_OFFSET);
>>>>> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", 
>>>>> VMALLOC_START);
>>>>> +    vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", 
>>>>> VMALLOC_END);
>>>>> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", 
>>>>> VMEMMAP_START);
>>>>> +    vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", 
>>>>> VMEMMAP_END);
>>>>> +#ifdef CONFIG_64BIT
>>>>> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", 
>>>>> MODULES_VADDR);
>>>>> +    vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", 
>>>>> MODULES_END);
>>>>> +#endif
>>>>> +
>>>>> +    if (IS_ENABLED(CONFIG_64BIT))
>>>>> + vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", 
>>>>> KERNEL_LINK_ADDR);
>>>> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
>>>> ifdeffery scope, with that you can save one line of 
>>>> "IS_ENABLED(CONFIG_64BIT)".
>>> I followed the rule in print_vm_layout() of arch/riscv/mm/init.c, 
>>> which used
>>> IS_ENABLED when print the value of KERNEL_LINK_ADDR.
>>>
>> I see. There's PAGE_OFFSET in the middle. Thanks.
>>
>>          print_ml("lowmem", (unsigned long)PAGE_OFFSET,
>>                  (unsigned long)high_memory)
>>
>> So now, do you think if it's necessary to have another
>> IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
>
> For which MACRO?  I think current code for PAGE_OFFSET is OK.
>

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

[Xianting Tian]

Hi Palmer, Conor

Is this version OK for you? Do you plan to apply this patch set? thanks

在 2022/10/20 下午12:40, Xianting Tian 写道:
>
> 在 2022/10/20 上午11:05, Baoquan He 写道:
>> On 10/20/22 at 10:17am, Xianting Tian wrote:
>>> 在 2022/10/20 上午10:08, Baoquan He 写道:
>>>> On 10/19/22 at 06:36pm, Xianting Tian wrote:
>>>>> Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, 
>>>>> VMALLOC,
>>>>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for 
>>>>> vmcore.
>>>>>
>>>>> Default pagetable levels and PAGE_OFFSET aren't same for different 
>>>>> kernel
>>>>> version as below. For pagetable levels, it sets sv57 by default 
>>>>> and falls
>>>>> back to setting sv48 at boot time if sv57 is not supported by the 
>>>>> hardware.
>>>>>
>>>>> For ram base, the default value is 0x80200000 for qemu riscv64 env 
>>>>> and,
>>>>> for example, is 0x200000 on the XuanTie 910 CPU.
>>>>>
>>>>>    * Linux Kernel 5.18 ~
>>>>>    *      PGTABLE_LEVELS = 5
>>>>>    *      PAGE_OFFSET = 0xff60000000000000
>>>>>    * Linux Kernel 5.17 ~
>>>>>    *      PGTABLE_LEVELS = 4
>>>>>    *      PAGE_OFFSET = 0xffffaf8000000000
>>>>>    * Linux Kernel 4.19 ~
>>>>>    *      PGTABLE_LEVELS = 3
>>>>>    *      PAGE_OFFSET = 0xffffffe000000000
>>>>>
>>>>> Since these configurations change from time to time and version to 
>>>>> version,
>>>>> it is preferable to export them via vmcoreinfo than to change the 
>>>>> crash's
>>>>> code frequently, it can simplify the development of crash tool.
>>>>>
>>>>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
>>>>> ---
>>>>>    arch/riscv/kernel/Makefile     |  1 +
>>>>>    arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>>>>>    2 files changed, 24 insertions(+)
>>>>>    create mode 100644 arch/riscv/kernel/crash_core.c
>>>>>
>>>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
>>>>> index db6e4b1294ba..4cf303a779ab 100644
>>>>> --- a/arch/riscv/kernel/Makefile
>>>>> +++ b/arch/riscv/kernel/Makefile
>>>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
>>>>>    obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o 
>>>>> crash_save_regs.o machine_kexec.o
>>>>>    obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
>>>>>    obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
>>>>> +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
>>>>>    obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
>>>>> diff --git a/arch/riscv/kernel/crash_core.c 
>>>>> b/arch/riscv/kernel/crash_core.c
>>>>> new file mode 100644
>>>>> index 000000000000..3e889d0ed7bd
>>>>> --- /dev/null
>>>>> +++ b/arch/riscv/kernel/crash_core.c
>>>>> @@ -0,0 +1,23 @@
>>>>> +// SPDX-License-Identifier: GPL-2.0-only
>>>>> +
>>>>> +#include <linux/crash_core.h>
>>>>> +#include <linux/pagemap.h>
>>>>> +
>>>>> +void arch_crash_save_vmcoreinfo(void)
>>>>> +{
>>>>> +    VMCOREINFO_NUMBER(VA_BITS);
>>>>> +    VMCOREINFO_NUMBER(phys_ram_base);
>>>>> +
>>>>> +    vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", 
>>>>> PAGE_OFFSET);
>>>>> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", 
>>>>> VMALLOC_START);
>>>>> +    vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", 
>>>>> VMALLOC_END);
>>>>> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", 
>>>>> VMEMMAP_START);
>>>>> +    vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", 
>>>>> VMEMMAP_END);
>>>>> +#ifdef CONFIG_64BIT
>>>>> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", 
>>>>> MODULES_VADDR);
>>>>> +    vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", 
>>>>> MODULES_END);
>>>>> +#endif
>>>>> +
>>>>> +    if (IS_ENABLED(CONFIG_64BIT))
>>>>> + vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", 
>>>>> KERNEL_LINK_ADDR);
>>>> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
>>>> ifdeffery scope, with that you can save one line of 
>>>> "IS_ENABLED(CONFIG_64BIT)".
>>> I followed the rule in print_vm_layout() of arch/riscv/mm/init.c, 
>>> which used
>>> IS_ENABLED when print the value of KERNEL_LINK_ADDR.
>>>
>> I see. There's PAGE_OFFSET in the middle. Thanks.
>>
>>          print_ml("lowmem", (unsigned long)PAGE_OFFSET,
>>                  (unsigned long)high_memory)
>>
>> So now, do you think if it's necessary to have another
>> IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
>
> For which MACRO?  I think current code for PAGE_OFFSET is OK.
>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Xianting Tian]

Hi Palmer, Conor

Is this version OK for you? Do you plan to apply this patch set? thanks

在 2022/10/20 下午12:40, Xianting Tian 写道:
>
> 在 2022/10/20 上午11:05, Baoquan He 写道:
>> On 10/20/22 at 10:17am, Xianting Tian wrote:
>>> 在 2022/10/20 上午10:08, Baoquan He 写道:
>>>> On 10/19/22 at 06:36pm, Xianting Tian wrote:
>>>>> Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, 
>>>>> VMALLOC,
>>>>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for 
>>>>> vmcore.
>>>>>
>>>>> Default pagetable levels and PAGE_OFFSET aren't same for different 
>>>>> kernel
>>>>> version as below. For pagetable levels, it sets sv57 by default 
>>>>> and falls
>>>>> back to setting sv48 at boot time if sv57 is not supported by the 
>>>>> hardware.
>>>>>
>>>>> For ram base, the default value is 0x80200000 for qemu riscv64 env 
>>>>> and,
>>>>> for example, is 0x200000 on the XuanTie 910 CPU.
>>>>>
>>>>>    * Linux Kernel 5.18 ~
>>>>>    *      PGTABLE_LEVELS = 5
>>>>>    *      PAGE_OFFSET = 0xff60000000000000
>>>>>    * Linux Kernel 5.17 ~
>>>>>    *      PGTABLE_LEVELS = 4
>>>>>    *      PAGE_OFFSET = 0xffffaf8000000000
>>>>>    * Linux Kernel 4.19 ~
>>>>>    *      PGTABLE_LEVELS = 3
>>>>>    *      PAGE_OFFSET = 0xffffffe000000000
>>>>>
>>>>> Since these configurations change from time to time and version to 
>>>>> version,
>>>>> it is preferable to export them via vmcoreinfo than to change the 
>>>>> crash's
>>>>> code frequently, it can simplify the development of crash tool.
>>>>>
>>>>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
>>>>> ---
>>>>>    arch/riscv/kernel/Makefile     |  1 +
>>>>>    arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>>>>>    2 files changed, 24 insertions(+)
>>>>>    create mode 100644 arch/riscv/kernel/crash_core.c
>>>>>
>>>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
>>>>> index db6e4b1294ba..4cf303a779ab 100644
>>>>> --- a/arch/riscv/kernel/Makefile
>>>>> +++ b/arch/riscv/kernel/Makefile
>>>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
>>>>>    obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o 
>>>>> crash_save_regs.o machine_kexec.o
>>>>>    obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
>>>>>    obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
>>>>> +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
>>>>>    obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
>>>>> diff --git a/arch/riscv/kernel/crash_core.c 
>>>>> b/arch/riscv/kernel/crash_core.c
>>>>> new file mode 100644
>>>>> index 000000000000..3e889d0ed7bd
>>>>> --- /dev/null
>>>>> +++ b/arch/riscv/kernel/crash_core.c
>>>>> @@ -0,0 +1,23 @@
>>>>> +// SPDX-License-Identifier: GPL-2.0-only
>>>>> +
>>>>> +#include <linux/crash_core.h>
>>>>> +#include <linux/pagemap.h>
>>>>> +
>>>>> +void arch_crash_save_vmcoreinfo(void)
>>>>> +{
>>>>> +    VMCOREINFO_NUMBER(VA_BITS);
>>>>> +    VMCOREINFO_NUMBER(phys_ram_base);
>>>>> +
>>>>> +    vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", 
>>>>> PAGE_OFFSET);
>>>>> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", 
>>>>> VMALLOC_START);
>>>>> +    vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", 
>>>>> VMALLOC_END);
>>>>> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", 
>>>>> VMEMMAP_START);
>>>>> +    vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", 
>>>>> VMEMMAP_END);
>>>>> +#ifdef CONFIG_64BIT
>>>>> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", 
>>>>> MODULES_VADDR);
>>>>> +    vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", 
>>>>> MODULES_END);
>>>>> +#endif
>>>>> +
>>>>> +    if (IS_ENABLED(CONFIG_64BIT))
>>>>> + vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", 
>>>>> KERNEL_LINK_ADDR);
>>>> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
>>>> ifdeffery scope, with that you can save one line of 
>>>> "IS_ENABLED(CONFIG_64BIT)".
>>> I followed the rule in print_vm_layout() of arch/riscv/mm/init.c, 
>>> which used
>>> IS_ENABLED when print the value of KERNEL_LINK_ADDR.
>>>
>> I see. There's PAGE_OFFSET in the middle. Thanks.
>>
>>          print_ml("lowmem", (unsigned long)PAGE_OFFSET,
>>                  (unsigned long)high_memory)
>>
>> So now, do you think if it's necessary to have another
>> IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
>
> For which MACRO?  I think current code for PAGE_OFFSET is OK.
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

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

[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.

Thanks,
Conor.

> 
> 在 2022/10/20 下午12:40, Xianting Tian 写道:
> > 
> > 在 2022/10/20 上午11:05, Baoquan He 写道:
> > > On 10/20/22 at 10:17am, Xianting Tian wrote:
> > > > 在 2022/10/20 上午10:08, Baoquan He 写道:
> > > > > On 10/19/22 at 06:36pm, Xianting Tian wrote:
> > > > > > Add arch_crash_save_vmcoreinfo(), which exports VM
> > > > > > layout(MODULES, VMALLOC,
> > > > > > VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram
> > > > > > base for vmcore.
> > > > > > 
> > > > > > Default pagetable levels and PAGE_OFFSET aren't same for
> > > > > > different kernel
> > > > > > version as below. For pagetable levels, it sets sv57 by
> > > > > > default and falls
> > > > > > back to setting sv48 at boot time if sv57 is not
> > > > > > supported by the hardware.
> > > > > > 
> > > > > > For ram base, the default value is 0x80200000 for qemu
> > > > > > riscv64 env and,
> > > > > > for example, is 0x200000 on the XuanTie 910 CPU.
> > > > > > 
> > > > > >    * Linux Kernel 5.18 ~
> > > > > >    *      PGTABLE_LEVELS = 5
> > > > > >    *      PAGE_OFFSET = 0xff60000000000000
> > > > > >    * Linux Kernel 5.17 ~
> > > > > >    *      PGTABLE_LEVELS = 4
> > > > > >    *      PAGE_OFFSET = 0xffffaf8000000000
> > > > > >    * Linux Kernel 4.19 ~
> > > > > >    *      PGTABLE_LEVELS = 3
> > > > > >    *      PAGE_OFFSET = 0xffffffe000000000
> > > > > > 
> > > > > > Since these configurations change from time to time and
> > > > > > version to version,
> > > > > > it is preferable to export them via vmcoreinfo than to
> > > > > > change the crash's
> > > > > > code frequently, it can simplify the development of crash tool.
> > > > > > 
> > > > > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> > > > > > ---
> > > > > >    arch/riscv/kernel/Makefile     |  1 +
> > > > > >    arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
> > > > > >    2 files changed, 24 insertions(+)
> > > > > >    create mode 100644 arch/riscv/kernel/crash_core.c
> > > > > > 
> > > > > > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> > > > > > index db6e4b1294ba..4cf303a779ab 100644
> > > > > > --- a/arch/riscv/kernel/Makefile
> > > > > > +++ b/arch/riscv/kernel/Makefile
> > > > > > @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
> > > > > >    obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o
> > > > > > crash_save_regs.o machine_kexec.o
> > > > > >    obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
> > > > > >    obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
> > > > > > +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
> > > > > >    obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
> > > > > > diff --git a/arch/riscv/kernel/crash_core.c
> > > > > > b/arch/riscv/kernel/crash_core.c
> > > > > > new file mode 100644
> > > > > > index 000000000000..3e889d0ed7bd
> > > > > > --- /dev/null
> > > > > > +++ b/arch/riscv/kernel/crash_core.c
> > > > > > @@ -0,0 +1,23 @@
> > > > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > > > +
> > > > > > +#include <linux/crash_core.h>
> > > > > > +#include <linux/pagemap.h>
> > > > > > +
> > > > > > +void arch_crash_save_vmcoreinfo(void)
> > > > > > +{
> > > > > > +    VMCOREINFO_NUMBER(VA_BITS);
> > > > > > +    VMCOREINFO_NUMBER(phys_ram_base);
> > > > > > +
> > > > > > +   
> > > > > > vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n",
> > > > > > PAGE_OFFSET);
> > > > > > + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
> > > > > > VMALLOC_START);
> > > > > > +   
> > > > > > vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n",
> > > > > > VMALLOC_END);
> > > > > > + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n",
> > > > > > VMEMMAP_START);
> > > > > > +   
> > > > > > vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n",
> > > > > > VMEMMAP_END);
> > > > > > +#ifdef CONFIG_64BIT
> > > > > > + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n",
> > > > > > MODULES_VADDR);
> > > > > > +   
> > > > > > vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n",
> > > > > > MODULES_END);
> > > > > > +#endif
> > > > > > +
> > > > > > +    if (IS_ENABLED(CONFIG_64BIT))
> > > > > > +
> > > > > > vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
> > > > > > KERNEL_LINK_ADDR);
> > > > > Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
> > > > > ifdeffery scope, with that you can save one line of
> > > > > "IS_ENABLED(CONFIG_64BIT)".
> > > > I followed the rule in print_vm_layout() of
> > > > arch/riscv/mm/init.c, which used
> > > > IS_ENABLED when print the value of KERNEL_LINK_ADDR.
> > > > 
> > > I see. There's PAGE_OFFSET in the middle. Thanks.
> > > 
> > >          print_ml("lowmem", (unsigned long)PAGE_OFFSET,
> > >                  (unsigned long)high_memory)
> > > 
> > > So now, do you think if it's necessary to have another
> > > IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
> > 
> > For which MACRO?  I think current code for PAGE_OFFSET is OK.
> > 

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

[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.

Thanks,
Conor.

> 
> 在 2022/10/20 下午12:40, Xianting Tian 写道:
> > 
> > 在 2022/10/20 上午11:05, Baoquan He 写道:
> > > On 10/20/22 at 10:17am, Xianting Tian wrote:
> > > > 在 2022/10/20 上午10:08, Baoquan He 写道:
> > > > > On 10/19/22 at 06:36pm, Xianting Tian wrote:
> > > > > > Add arch_crash_save_vmcoreinfo(), which exports VM
> > > > > > layout(MODULES, VMALLOC,
> > > > > > VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram
> > > > > > base for vmcore.
> > > > > > 
> > > > > > Default pagetable levels and PAGE_OFFSET aren't same for
> > > > > > different kernel
> > > > > > version as below. For pagetable levels, it sets sv57 by
> > > > > > default and falls
> > > > > > back to setting sv48 at boot time if sv57 is not
> > > > > > supported by the hardware.
> > > > > > 
> > > > > > For ram base, the default value is 0x80200000 for qemu
> > > > > > riscv64 env and,
> > > > > > for example, is 0x200000 on the XuanTie 910 CPU.
> > > > > > 
> > > > > >    * Linux Kernel 5.18 ~
> > > > > >    *      PGTABLE_LEVELS = 5
> > > > > >    *      PAGE_OFFSET = 0xff60000000000000
> > > > > >    * Linux Kernel 5.17 ~
> > > > > >    *      PGTABLE_LEVELS = 4
> > > > > >    *      PAGE_OFFSET = 0xffffaf8000000000
> > > > > >    * Linux Kernel 4.19 ~
> > > > > >    *      PGTABLE_LEVELS = 3
> > > > > >    *      PAGE_OFFSET = 0xffffffe000000000
> > > > > > 
> > > > > > Since these configurations change from time to time and
> > > > > > version to version,
> > > > > > it is preferable to export them via vmcoreinfo than to
> > > > > > change the crash's
> > > > > > code frequently, it can simplify the development of crash tool.
> > > > > > 
> > > > > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> > > > > > ---
> > > > > >    arch/riscv/kernel/Makefile     |  1 +
> > > > > >    arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
> > > > > >    2 files changed, 24 insertions(+)
> > > > > >    create mode 100644 arch/riscv/kernel/crash_core.c
> > > > > > 
> > > > > > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> > > > > > index db6e4b1294ba..4cf303a779ab 100644
> > > > > > --- a/arch/riscv/kernel/Makefile
> > > > > > +++ b/arch/riscv/kernel/Makefile
> > > > > > @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
> > > > > >    obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o
> > > > > > crash_save_regs.o machine_kexec.o
> > > > > >    obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
> > > > > >    obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
> > > > > > +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
> > > > > >    obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
> > > > > > diff --git a/arch/riscv/kernel/crash_core.c
> > > > > > b/arch/riscv/kernel/crash_core.c
> > > > > > new file mode 100644
> > > > > > index 000000000000..3e889d0ed7bd
> > > > > > --- /dev/null
> > > > > > +++ b/arch/riscv/kernel/crash_core.c
> > > > > > @@ -0,0 +1,23 @@
> > > > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > > > +
> > > > > > +#include <linux/crash_core.h>
> > > > > > +#include <linux/pagemap.h>
> > > > > > +
> > > > > > +void arch_crash_save_vmcoreinfo(void)
> > > > > > +{
> > > > > > +    VMCOREINFO_NUMBER(VA_BITS);
> > > > > > +    VMCOREINFO_NUMBER(phys_ram_base);
> > > > > > +
> > > > > > +   
> > > > > > vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n",
> > > > > > PAGE_OFFSET);
> > > > > > + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
> > > > > > VMALLOC_START);
> > > > > > +   
> > > > > > vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n",
> > > > > > VMALLOC_END);
> > > > > > + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n",
> > > > > > VMEMMAP_START);
> > > > > > +   
> > > > > > vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n",
> > > > > > VMEMMAP_END);
> > > > > > +#ifdef CONFIG_64BIT
> > > > > > + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n",
> > > > > > MODULES_VADDR);
> > > > > > +   
> > > > > > vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n",
> > > > > > MODULES_END);
> > > > > > +#endif
> > > > > > +
> > > > > > +    if (IS_ENABLED(CONFIG_64BIT))
> > > > > > +
> > > > > > vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
> > > > > > KERNEL_LINK_ADDR);
> > > > > Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
> > > > > ifdeffery scope, with that you can save one line of
> > > > > "IS_ENABLED(CONFIG_64BIT)".
> > > > I followed the rule in print_vm_layout() of
> > > > arch/riscv/mm/init.c, which used
> > > > IS_ENABLED when print the value of KERNEL_LINK_ADDR.
> > > > 
> > > I see. There's PAGE_OFFSET in the middle. Thanks.
> > > 
> > >          print_ml("lowmem", (unsigned long)PAGE_OFFSET,
> > >                  (unsigned long)high_memory)
> > > 
> > > So now, do you think if it's necessary to have another
> > > IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
> > 
> > For which MACRO?  I think current code for PAGE_OFFSET is OK.
> > 

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[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.

Thanks,
Conor.

> 
> 在 2022/10/20 下午12:40, Xianting Tian 写道:
> > 
> > 在 2022/10/20 上午11:05, Baoquan He 写道:
> > > On 10/20/22 at 10:17am, Xianting Tian wrote:
> > > > 在 2022/10/20 上午10:08, Baoquan He 写道:
> > > > > On 10/19/22 at 06:36pm, Xianting Tian wrote:
> > > > > > Add arch_crash_save_vmcoreinfo(), which exports VM
> > > > > > layout(MODULES, VMALLOC,
> > > > > > VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram
> > > > > > base for vmcore.
> > > > > > 
> > > > > > Default pagetable levels and PAGE_OFFSET aren't same for
> > > > > > different kernel
> > > > > > version as below. For pagetable levels, it sets sv57 by
> > > > > > default and falls
> > > > > > back to setting sv48 at boot time if sv57 is not
> > > > > > supported by the hardware.
> > > > > > 
> > > > > > For ram base, the default value is 0x80200000 for qemu
> > > > > > riscv64 env and,
> > > > > > for example, is 0x200000 on the XuanTie 910 CPU.
> > > > > > 
> > > > > >    * Linux Kernel 5.18 ~
> > > > > >    *      PGTABLE_LEVELS = 5
> > > > > >    *      PAGE_OFFSET = 0xff60000000000000
> > > > > >    * Linux Kernel 5.17 ~
> > > > > >    *      PGTABLE_LEVELS = 4
> > > > > >    *      PAGE_OFFSET = 0xffffaf8000000000
> > > > > >    * Linux Kernel 4.19 ~
> > > > > >    *      PGTABLE_LEVELS = 3
> > > > > >    *      PAGE_OFFSET = 0xffffffe000000000
> > > > > > 
> > > > > > Since these configurations change from time to time and
> > > > > > version to version,
> > > > > > it is preferable to export them via vmcoreinfo than to
> > > > > > change the crash's
> > > > > > code frequently, it can simplify the development of crash tool.
> > > > > > 
> > > > > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> > > > > > ---
> > > > > >    arch/riscv/kernel/Makefile     |  1 +
> > > > > >    arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
> > > > > >    2 files changed, 24 insertions(+)
> > > > > >    create mode 100644 arch/riscv/kernel/crash_core.c
> > > > > > 
> > > > > > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> > > > > > index db6e4b1294ba..4cf303a779ab 100644
> > > > > > --- a/arch/riscv/kernel/Makefile
> > > > > > +++ b/arch/riscv/kernel/Makefile
> > > > > > @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
> > > > > >    obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o
> > > > > > crash_save_regs.o machine_kexec.o
> > > > > >    obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
> > > > > >    obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
> > > > > > +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
> > > > > >    obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
> > > > > > diff --git a/arch/riscv/kernel/crash_core.c
> > > > > > b/arch/riscv/kernel/crash_core.c
> > > > > > new file mode 100644
> > > > > > index 000000000000..3e889d0ed7bd
> > > > > > --- /dev/null
> > > > > > +++ b/arch/riscv/kernel/crash_core.c
> > > > > > @@ -0,0 +1,23 @@
> > > > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > > > +
> > > > > > +#include <linux/crash_core.h>
> > > > > > +#include <linux/pagemap.h>
> > > > > > +
> > > > > > +void arch_crash_save_vmcoreinfo(void)
> > > > > > +{
> > > > > > +    VMCOREINFO_NUMBER(VA_BITS);
> > > > > > +    VMCOREINFO_NUMBER(phys_ram_base);
> > > > > > +
> > > > > > +   
> > > > > > vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n",
> > > > > > PAGE_OFFSET);
> > > > > > + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
> > > > > > VMALLOC_START);
> > > > > > +   
> > > > > > vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n",
> > > > > > VMALLOC_END);
> > > > > > + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n",
> > > > > > VMEMMAP_START);
> > > > > > +   
> > > > > > vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n",
> > > > > > VMEMMAP_END);
> > > > > > +#ifdef CONFIG_64BIT
> > > > > > + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n",
> > > > > > MODULES_VADDR);
> > > > > > +   
> > > > > > vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n",
> > > > > > MODULES_END);
> > > > > > +#endif
> > > > > > +
> > > > > > +    if (IS_ENABLED(CONFIG_64BIT))
> > > > > > +
> > > > > > vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
> > > > > > KERNEL_LINK_ADDR);
> > > > > Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
> > > > > ifdeffery scope, with that you can save one line of
> > > > > "IS_ENABLED(CONFIG_64BIT)".
> > > > I followed the rule in print_vm_layout() of
> > > > arch/riscv/mm/init.c, which used
> > > > IS_ENABLED when print the value of KERNEL_LINK_ADDR.
> > > > 
> > > I see. There's PAGE_OFFSET in the middle. Thanks.
> > > 
> > >          print_ml("lowmem", (unsigned long)PAGE_OFFSET,
> > >                  (unsigned long)high_memory)
> > > 
> > > So now, do you think if it's necessary to have another
> > > IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
> > 
> > For which MACRO?  I think current code for PAGE_OFFSET is OK.
> > 

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

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

[Xianting Tian]

在 2022/10/26 下午5:25, Conor Dooley 写道:
> On Wed, Oct 26, 2022 at 05:08:11PM +0800, Xianting Tian wrote:
>> Hi Palmer, Conor
>>
>> Is this version OK for you?
> The weird ifdef/IS_ENABLED thing was the only comment I had. It's a bit
> odd & I notice Baoquan brought it up too. I didn't (and won't) give you
> a reviewed by on these patches because I don't understand the area well
> enough. The general nitpickery seems to be sorted though.

I checked the KERNEL_LINK_ADDR definition of riscv,  it is valid for 
CONFIG_64BIT and !CONFIG_64BIT.

Maybe we can remove IS_ENABLED(CONFIG_64BIT)

arch/riscv/include/asm/pgtable.h
#define ADDRESS_SPACE_END       (UL(-1))
#ifdef CONFIG_64BIT
/* Leave 2GB for kernel and BPF at the end of the address space */
#define KERNEL_LINK_ADDR        (ADDRESS_SPACE_END - SZ_2G + 1)
#else
#define KERNEL_LINK_ADDR        PAGE_OFFSET
#endif

arch/riscv/include/asm/page.h
#ifdef CONFIG_64BIT
#ifdef CONFIG_MMU
#define PAGE_OFFSET             kernel_map.page_offset
#else
#define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
#endif
/*
  * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address 
space so
  * define the PAGE_OFFSET value for SV39.
  */
#define PAGE_OFFSET_L4          _AC(0xffffaf8000000000, UL)
#define PAGE_OFFSET_L3          _AC(0xffffffd800000000, UL)
#else
#define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
#endif /* CONFIG_64BIT */

>
> Thanks,
> Conor.
>
>> 在 2022/10/20 下午12:40, Xianting Tian 写道:
>>> 在 2022/10/20 上午11:05, Baoquan He 写道:
>>>> On 10/20/22 at 10:17am, Xianting Tian wrote:
>>>>> 在 2022/10/20 上午10:08, Baoquan He 写道:
>>>>>> On 10/19/22 at 06:36pm, Xianting Tian wrote:
>>>>>>> Add arch_crash_save_vmcoreinfo(), which exports VM
>>>>>>> layout(MODULES, VMALLOC,
>>>>>>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram
>>>>>>> base for vmcore.
>>>>>>>
>>>>>>> Default pagetable levels and PAGE_OFFSET aren't same for
>>>>>>> different kernel
>>>>>>> version as below. For pagetable levels, it sets sv57 by
>>>>>>> default and falls
>>>>>>> back to setting sv48 at boot time if sv57 is not
>>>>>>> supported by the hardware.
>>>>>>>
>>>>>>> For ram base, the default value is 0x80200000 for qemu
>>>>>>> riscv64 env and,
>>>>>>> for example, is 0x200000 on the XuanTie 910 CPU.
>>>>>>>
>>>>>>>     * Linux Kernel 5.18 ~
>>>>>>>     *      PGTABLE_LEVELS = 5
>>>>>>>     *      PAGE_OFFSET = 0xff60000000000000
>>>>>>>     * Linux Kernel 5.17 ~
>>>>>>>     *      PGTABLE_LEVELS = 4
>>>>>>>     *      PAGE_OFFSET = 0xffffaf8000000000
>>>>>>>     * Linux Kernel 4.19 ~
>>>>>>>     *      PGTABLE_LEVELS = 3
>>>>>>>     *      PAGE_OFFSET = 0xffffffe000000000
>>>>>>>
>>>>>>> Since these configurations change from time to time and
>>>>>>> version to version,
>>>>>>> it is preferable to export them via vmcoreinfo than to
>>>>>>> change the crash's
>>>>>>> code frequently, it can simplify the development of crash tool.
>>>>>>>
>>>>>>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
>>>>>>> ---
>>>>>>>     arch/riscv/kernel/Makefile     |  1 +
>>>>>>>     arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>>>>>>>     2 files changed, 24 insertions(+)
>>>>>>>     create mode 100644 arch/riscv/kernel/crash_core.c
>>>>>>>
>>>>>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
>>>>>>> index db6e4b1294ba..4cf303a779ab 100644
>>>>>>> --- a/arch/riscv/kernel/Makefile
>>>>>>> +++ b/arch/riscv/kernel/Makefile
>>>>>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
>>>>>>>     obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o
>>>>>>> crash_save_regs.o machine_kexec.o
>>>>>>>     obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
>>>>>>>     obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
>>>>>>> +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
>>>>>>>     obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
>>>>>>> diff --git a/arch/riscv/kernel/crash_core.c
>>>>>>> b/arch/riscv/kernel/crash_core.c
>>>>>>> new file mode 100644
>>>>>>> index 000000000000..3e889d0ed7bd
>>>>>>> --- /dev/null
>>>>>>> +++ b/arch/riscv/kernel/crash_core.c
>>>>>>> @@ -0,0 +1,23 @@
>>>>>>> +// SPDX-License-Identifier: GPL-2.0-only
>>>>>>> +
>>>>>>> +#include <linux/crash_core.h>
>>>>>>> +#include <linux/pagemap.h>
>>>>>>> +
>>>>>>> +void arch_crash_save_vmcoreinfo(void)
>>>>>>> +{
>>>>>>> +    VMCOREINFO_NUMBER(VA_BITS);
>>>>>>> +    VMCOREINFO_NUMBER(phys_ram_base);
>>>>>>> +
>>>>>>> +
>>>>>>> vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n",
>>>>>>> PAGE_OFFSET);
>>>>>>> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
>>>>>>> VMALLOC_START);
>>>>>>> +
>>>>>>> vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n",
>>>>>>> VMALLOC_END);
>>>>>>> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n",
>>>>>>> VMEMMAP_START);
>>>>>>> +
>>>>>>> vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n",
>>>>>>> VMEMMAP_END);
>>>>>>> +#ifdef CONFIG_64BIT
>>>>>>> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n",
>>>>>>> MODULES_VADDR);
>>>>>>> +
>>>>>>> vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n",
>>>>>>> MODULES_END);
>>>>>>> +#endif
>>>>>>> +
>>>>>>> +    if (IS_ENABLED(CONFIG_64BIT))
>>>>>>> +
>>>>>>> vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
>>>>>>> KERNEL_LINK_ADDR);
>>>>>> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
>>>>>> ifdeffery scope, with that you can save one line of
>>>>>> "IS_ENABLED(CONFIG_64BIT)".
>>>>> I followed the rule in print_vm_layout() of
>>>>> arch/riscv/mm/init.c, which used
>>>>> IS_ENABLED when print the value of KERNEL_LINK_ADDR.
>>>>>
>>>> I see. There's PAGE_OFFSET in the middle. Thanks.
>>>>
>>>>           print_ml("lowmem", (unsigned long)PAGE_OFFSET,
>>>>                   (unsigned long)high_memory)
>>>>
>>>> So now, do you think if it's necessary to have another
>>>> IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
>>> For which MACRO?  I think current code for PAGE_OFFSET is OK.
>>>

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

[Xianting Tian]

在 2022/10/26 下午5:25, Conor Dooley 写道:
> On Wed, Oct 26, 2022 at 05:08:11PM +0800, Xianting Tian wrote:
>> Hi Palmer, Conor
>>
>> Is this version OK for you?
> The weird ifdef/IS_ENABLED thing was the only comment I had. It's a bit
> odd & I notice Baoquan brought it up too. I didn't (and won't) give you
> a reviewed by on these patches because I don't understand the area well
> enough. The general nitpickery seems to be sorted though.

I checked the KERNEL_LINK_ADDR definition of riscv,  it is valid for 
CONFIG_64BIT and !CONFIG_64BIT.

Maybe we can remove IS_ENABLED(CONFIG_64BIT)

arch/riscv/include/asm/pgtable.h
#define ADDRESS_SPACE_END       (UL(-1))
#ifdef CONFIG_64BIT
/* Leave 2GB for kernel and BPF at the end of the address space */
#define KERNEL_LINK_ADDR        (ADDRESS_SPACE_END - SZ_2G + 1)
#else
#define KERNEL_LINK_ADDR        PAGE_OFFSET
#endif

arch/riscv/include/asm/page.h
#ifdef CONFIG_64BIT
#ifdef CONFIG_MMU
#define PAGE_OFFSET             kernel_map.page_offset
#else
#define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
#endif
/*
  * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address 
space so
  * define the PAGE_OFFSET value for SV39.
  */
#define PAGE_OFFSET_L4          _AC(0xffffaf8000000000, UL)
#define PAGE_OFFSET_L3          _AC(0xffffffd800000000, UL)
#else
#define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
#endif /* CONFIG_64BIT */

>
> Thanks,
> Conor.
>
>> 在 2022/10/20 下午12:40, Xianting Tian 写道:
>>> 在 2022/10/20 上午11:05, Baoquan He 写道:
>>>> On 10/20/22 at 10:17am, Xianting Tian wrote:
>>>>> 在 2022/10/20 上午10:08, Baoquan He 写道:
>>>>>> On 10/19/22 at 06:36pm, Xianting Tian wrote:
>>>>>>> Add arch_crash_save_vmcoreinfo(), which exports VM
>>>>>>> layout(MODULES, VMALLOC,
>>>>>>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram
>>>>>>> base for vmcore.
>>>>>>>
>>>>>>> Default pagetable levels and PAGE_OFFSET aren't same for
>>>>>>> different kernel
>>>>>>> version as below. For pagetable levels, it sets sv57 by
>>>>>>> default and falls
>>>>>>> back to setting sv48 at boot time if sv57 is not
>>>>>>> supported by the hardware.
>>>>>>>
>>>>>>> For ram base, the default value is 0x80200000 for qemu
>>>>>>> riscv64 env and,
>>>>>>> for example, is 0x200000 on the XuanTie 910 CPU.
>>>>>>>
>>>>>>>     * Linux Kernel 5.18 ~
>>>>>>>     *      PGTABLE_LEVELS = 5
>>>>>>>     *      PAGE_OFFSET = 0xff60000000000000
>>>>>>>     * Linux Kernel 5.17 ~
>>>>>>>     *      PGTABLE_LEVELS = 4
>>>>>>>     *      PAGE_OFFSET = 0xffffaf8000000000
>>>>>>>     * Linux Kernel 4.19 ~
>>>>>>>     *      PGTABLE_LEVELS = 3
>>>>>>>     *      PAGE_OFFSET = 0xffffffe000000000
>>>>>>>
>>>>>>> Since these configurations change from time to time and
>>>>>>> version to version,
>>>>>>> it is preferable to export them via vmcoreinfo than to
>>>>>>> change the crash's
>>>>>>> code frequently, it can simplify the development of crash tool.
>>>>>>>
>>>>>>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
>>>>>>> ---
>>>>>>>     arch/riscv/kernel/Makefile     |  1 +
>>>>>>>     arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>>>>>>>     2 files changed, 24 insertions(+)
>>>>>>>     create mode 100644 arch/riscv/kernel/crash_core.c
>>>>>>>
>>>>>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
>>>>>>> index db6e4b1294ba..4cf303a779ab 100644
>>>>>>> --- a/arch/riscv/kernel/Makefile
>>>>>>> +++ b/arch/riscv/kernel/Makefile
>>>>>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
>>>>>>>     obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o
>>>>>>> crash_save_regs.o machine_kexec.o
>>>>>>>     obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
>>>>>>>     obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
>>>>>>> +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
>>>>>>>     obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
>>>>>>> diff --git a/arch/riscv/kernel/crash_core.c
>>>>>>> b/arch/riscv/kernel/crash_core.c
>>>>>>> new file mode 100644
>>>>>>> index 000000000000..3e889d0ed7bd
>>>>>>> --- /dev/null
>>>>>>> +++ b/arch/riscv/kernel/crash_core.c
>>>>>>> @@ -0,0 +1,23 @@
>>>>>>> +// SPDX-License-Identifier: GPL-2.0-only
>>>>>>> +
>>>>>>> +#include <linux/crash_core.h>
>>>>>>> +#include <linux/pagemap.h>
>>>>>>> +
>>>>>>> +void arch_crash_save_vmcoreinfo(void)
>>>>>>> +{
>>>>>>> +    VMCOREINFO_NUMBER(VA_BITS);
>>>>>>> +    VMCOREINFO_NUMBER(phys_ram_base);
>>>>>>> +
>>>>>>> +
>>>>>>> vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n",
>>>>>>> PAGE_OFFSET);
>>>>>>> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
>>>>>>> VMALLOC_START);
>>>>>>> +
>>>>>>> vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n",
>>>>>>> VMALLOC_END);
>>>>>>> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n",
>>>>>>> VMEMMAP_START);
>>>>>>> +
>>>>>>> vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n",
>>>>>>> VMEMMAP_END);
>>>>>>> +#ifdef CONFIG_64BIT
>>>>>>> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n",
>>>>>>> MODULES_VADDR);
>>>>>>> +
>>>>>>> vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n",
>>>>>>> MODULES_END);
>>>>>>> +#endif
>>>>>>> +
>>>>>>> +    if (IS_ENABLED(CONFIG_64BIT))
>>>>>>> +
>>>>>>> vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
>>>>>>> KERNEL_LINK_ADDR);
>>>>>> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
>>>>>> ifdeffery scope, with that you can save one line of
>>>>>> "IS_ENABLED(CONFIG_64BIT)".
>>>>> I followed the rule in print_vm_layout() of
>>>>> arch/riscv/mm/init.c, which used
>>>>> IS_ENABLED when print the value of KERNEL_LINK_ADDR.
>>>>>
>>>> I see. There's PAGE_OFFSET in the middle. Thanks.
>>>>
>>>>           print_ml("lowmem", (unsigned long)PAGE_OFFSET,
>>>>                   (unsigned long)high_memory)
>>>>
>>>> So now, do you think if it's necessary to have another
>>>> IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
>>> For which MACRO?  I think current code for PAGE_OFFSET is OK.
>>>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Xianting Tian]

在 2022/10/26 下午5:25, Conor Dooley 写道:
> On Wed, Oct 26, 2022 at 05:08:11PM +0800, Xianting Tian wrote:
>> Hi Palmer, Conor
>>
>> Is this version OK for you?
> The weird ifdef/IS_ENABLED thing was the only comment I had. It's a bit
> odd & I notice Baoquan brought it up too. I didn't (and won't) give you
> a reviewed by on these patches because I don't understand the area well
> enough. The general nitpickery seems to be sorted though.

I checked the KERNEL_LINK_ADDR definition of riscv,  it is valid for 
CONFIG_64BIT and !CONFIG_64BIT.

Maybe we can remove IS_ENABLED(CONFIG_64BIT)

arch/riscv/include/asm/pgtable.h
#define ADDRESS_SPACE_END       (UL(-1))
#ifdef CONFIG_64BIT
/* Leave 2GB for kernel and BPF at the end of the address space */
#define KERNEL_LINK_ADDR        (ADDRESS_SPACE_END - SZ_2G + 1)
#else
#define KERNEL_LINK_ADDR        PAGE_OFFSET
#endif

arch/riscv/include/asm/page.h
#ifdef CONFIG_64BIT
#ifdef CONFIG_MMU
#define PAGE_OFFSET             kernel_map.page_offset
#else
#define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
#endif
/*
  * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address 
space so
  * define the PAGE_OFFSET value for SV39.
  */
#define PAGE_OFFSET_L4          _AC(0xffffaf8000000000, UL)
#define PAGE_OFFSET_L3          _AC(0xffffffd800000000, UL)
#else
#define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
#endif /* CONFIG_64BIT */

>
> Thanks,
> Conor.
>
>> 在 2022/10/20 下午12:40, Xianting Tian 写道:
>>> 在 2022/10/20 上午11:05, Baoquan He 写道:
>>>> On 10/20/22 at 10:17am, Xianting Tian wrote:
>>>>> 在 2022/10/20 上午10:08, Baoquan He 写道:
>>>>>> On 10/19/22 at 06:36pm, Xianting Tian wrote:
>>>>>>> Add arch_crash_save_vmcoreinfo(), which exports VM
>>>>>>> layout(MODULES, VMALLOC,
>>>>>>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram
>>>>>>> base for vmcore.
>>>>>>>
>>>>>>> Default pagetable levels and PAGE_OFFSET aren't same for
>>>>>>> different kernel
>>>>>>> version as below. For pagetable levels, it sets sv57 by
>>>>>>> default and falls
>>>>>>> back to setting sv48 at boot time if sv57 is not
>>>>>>> supported by the hardware.
>>>>>>>
>>>>>>> For ram base, the default value is 0x80200000 for qemu
>>>>>>> riscv64 env and,
>>>>>>> for example, is 0x200000 on the XuanTie 910 CPU.
>>>>>>>
>>>>>>>     * Linux Kernel 5.18 ~
>>>>>>>     *      PGTABLE_LEVELS = 5
>>>>>>>     *      PAGE_OFFSET = 0xff60000000000000
>>>>>>>     * Linux Kernel 5.17 ~
>>>>>>>     *      PGTABLE_LEVELS = 4
>>>>>>>     *      PAGE_OFFSET = 0xffffaf8000000000
>>>>>>>     * Linux Kernel 4.19 ~
>>>>>>>     *      PGTABLE_LEVELS = 3
>>>>>>>     *      PAGE_OFFSET = 0xffffffe000000000
>>>>>>>
>>>>>>> Since these configurations change from time to time and
>>>>>>> version to version,
>>>>>>> it is preferable to export them via vmcoreinfo than to
>>>>>>> change the crash's
>>>>>>> code frequently, it can simplify the development of crash tool.
>>>>>>>
>>>>>>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
>>>>>>> ---
>>>>>>>     arch/riscv/kernel/Makefile     |  1 +
>>>>>>>     arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>>>>>>>     2 files changed, 24 insertions(+)
>>>>>>>     create mode 100644 arch/riscv/kernel/crash_core.c
>>>>>>>
>>>>>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
>>>>>>> index db6e4b1294ba..4cf303a779ab 100644
>>>>>>> --- a/arch/riscv/kernel/Makefile
>>>>>>> +++ b/arch/riscv/kernel/Makefile
>>>>>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
>>>>>>>     obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o
>>>>>>> crash_save_regs.o machine_kexec.o
>>>>>>>     obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
>>>>>>>     obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
>>>>>>> +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
>>>>>>>     obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
>>>>>>> diff --git a/arch/riscv/kernel/crash_core.c
>>>>>>> b/arch/riscv/kernel/crash_core.c
>>>>>>> new file mode 100644
>>>>>>> index 000000000000..3e889d0ed7bd
>>>>>>> --- /dev/null
>>>>>>> +++ b/arch/riscv/kernel/crash_core.c
>>>>>>> @@ -0,0 +1,23 @@
>>>>>>> +// SPDX-License-Identifier: GPL-2.0-only
>>>>>>> +
>>>>>>> +#include <linux/crash_core.h>
>>>>>>> +#include <linux/pagemap.h>
>>>>>>> +
>>>>>>> +void arch_crash_save_vmcoreinfo(void)
>>>>>>> +{
>>>>>>> +    VMCOREINFO_NUMBER(VA_BITS);
>>>>>>> +    VMCOREINFO_NUMBER(phys_ram_base);
>>>>>>> +
>>>>>>> +
>>>>>>> vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n",
>>>>>>> PAGE_OFFSET);
>>>>>>> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
>>>>>>> VMALLOC_START);
>>>>>>> +
>>>>>>> vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n",
>>>>>>> VMALLOC_END);
>>>>>>> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n",
>>>>>>> VMEMMAP_START);
>>>>>>> +
>>>>>>> vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n",
>>>>>>> VMEMMAP_END);
>>>>>>> +#ifdef CONFIG_64BIT
>>>>>>> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n",
>>>>>>> MODULES_VADDR);
>>>>>>> +
>>>>>>> vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n",
>>>>>>> MODULES_END);
>>>>>>> +#endif
>>>>>>> +
>>>>>>> +    if (IS_ENABLED(CONFIG_64BIT))
>>>>>>> +
>>>>>>> vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
>>>>>>> KERNEL_LINK_ADDR);
>>>>>> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
>>>>>> ifdeffery scope, with that you can save one line of
>>>>>> "IS_ENABLED(CONFIG_64BIT)".
>>>>> I followed the rule in print_vm_layout() of
>>>>> arch/riscv/mm/init.c, which used
>>>>> IS_ENABLED when print the value of KERNEL_LINK_ADDR.
>>>>>
>>>> I see. There's PAGE_OFFSET in the middle. Thanks.
>>>>
>>>>           print_ml("lowmem", (unsigned long)PAGE_OFFSET,
>>>>                   (unsigned long)high_memory)
>>>>
>>>> So now, do you think if it's necessary to have another
>>>> IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
>>> For which MACRO?  I think current code for PAGE_OFFSET is OK.
>>>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

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

[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.

+void arch_crash_save_vmcoreinfo(void)
+{
+       VMCOREINFO_NUMBER(VA_BITS);
+       VMCOREINFO_NUMBER(phys_ram_base);
+
+       vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
+       vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
+       vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
+       vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
+       vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
+#ifdef CONFIG_64BIT
+	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
+       vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
+       vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
+#endif
+}

> 
> Maybe we can remove IS_ENABLED(CONFIG_64BIT)
> 
> arch/riscv/include/asm/pgtable.h
> #define ADDRESS_SPACE_END       (UL(-1))
> #ifdef CONFIG_64BIT
> /* Leave 2GB for kernel and BPF at the end of the address space */
> #define KERNEL_LINK_ADDR        (ADDRESS_SPACE_END - SZ_2G + 1)
> #else
> #define KERNEL_LINK_ADDR        PAGE_OFFSET
> #endif
> 
> arch/riscv/include/asm/page.h
> #ifdef CONFIG_64BIT
> #ifdef CONFIG_MMU
> #define PAGE_OFFSET             kernel_map.page_offset
> #else
> #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
> #endif
> /*
>  * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address space so
>  * define the PAGE_OFFSET value for SV39.
>  */
> #define PAGE_OFFSET_L4          _AC(0xffffaf8000000000, UL)
> #define PAGE_OFFSET_L3          _AC(0xffffffd800000000, UL)
> #else
> #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
> #endif /* CONFIG_64BIT */
> 
> > 
> > Thanks,
> > Conor.
> > 
> > > 在 2022/10/20 下午12:40, Xianting Tian 写道:
> > > > 在 2022/10/20 上午11:05, Baoquan He 写道:
> > > > > On 10/20/22 at 10:17am, Xianting Tian wrote:
> > > > > > 在 2022/10/20 上午10:08, Baoquan He 写道:
> > > > > > > On 10/19/22 at 06:36pm, Xianting Tian wrote:
> > > > > > > > Add arch_crash_save_vmcoreinfo(), which exports VM
> > > > > > > > layout(MODULES, VMALLOC,
> > > > > > > > VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram
> > > > > > > > base for vmcore.
> > > > > > > > 
> > > > > > > > Default pagetable levels and PAGE_OFFSET aren't same for
> > > > > > > > different kernel
> > > > > > > > version as below. For pagetable levels, it sets sv57 by
> > > > > > > > default and falls
> > > > > > > > back to setting sv48 at boot time if sv57 is not
> > > > > > > > supported by the hardware.
> > > > > > > > 
> > > > > > > > For ram base, the default value is 0x80200000 for qemu
> > > > > > > > riscv64 env and,
> > > > > > > > for example, is 0x200000 on the XuanTie 910 CPU.
> > > > > > > > 
> > > > > > > >     * Linux Kernel 5.18 ~
> > > > > > > >     *      PGTABLE_LEVELS = 5
> > > > > > > >     *      PAGE_OFFSET = 0xff60000000000000
> > > > > > > >     * Linux Kernel 5.17 ~
> > > > > > > >     *      PGTABLE_LEVELS = 4
> > > > > > > >     *      PAGE_OFFSET = 0xffffaf8000000000
> > > > > > > >     * Linux Kernel 4.19 ~
> > > > > > > >     *      PGTABLE_LEVELS = 3
> > > > > > > >     *      PAGE_OFFSET = 0xffffffe000000000
> > > > > > > > 
> > > > > > > > Since these configurations change from time to time and
> > > > > > > > version to version,
> > > > > > > > it is preferable to export them via vmcoreinfo than to
> > > > > > > > change the crash's
> > > > > > > > code frequently, it can simplify the development of crash tool.
> > > > > > > > 
> > > > > > > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> > > > > > > > ---
> > > > > > > >     arch/riscv/kernel/Makefile     |  1 +
> > > > > > > >     arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
> > > > > > > >     2 files changed, 24 insertions(+)
> > > > > > > >     create mode 100644 arch/riscv/kernel/crash_core.c
> > > > > > > > 
> > > > > > > > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> > > > > > > > index db6e4b1294ba..4cf303a779ab 100644
> > > > > > > > --- a/arch/riscv/kernel/Makefile
> > > > > > > > +++ b/arch/riscv/kernel/Makefile
> > > > > > > > @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
> > > > > > > >     obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o
> > > > > > > > crash_save_regs.o machine_kexec.o
> > > > > > > >     obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
> > > > > > > >     obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
> > > > > > > > +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
> > > > > > > >     obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
> > > > > > > > diff --git a/arch/riscv/kernel/crash_core.c
> > > > > > > > b/arch/riscv/kernel/crash_core.c
> > > > > > > > new file mode 100644
> > > > > > > > index 000000000000..3e889d0ed7bd
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/arch/riscv/kernel/crash_core.c
> > > > > > > > @@ -0,0 +1,23 @@
> > > > > > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > > > > > +
> > > > > > > > +#include <linux/crash_core.h>
> > > > > > > > +#include <linux/pagemap.h>
> > > > > > > > +
> > > > > > > > +void arch_crash_save_vmcoreinfo(void)
> > > > > > > > +{
> > > > > > > > +    VMCOREINFO_NUMBER(VA_BITS);
> > > > > > > > +    VMCOREINFO_NUMBER(phys_ram_base);
> > > > > > > > +
> > > > > > > > +
> > > > > > > > vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n",
> > > > > > > > PAGE_OFFSET);
> > > > > > > > + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
> > > > > > > > VMALLOC_START);
> > > > > > > > +
> > > > > > > > vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n",
> > > > > > > > VMALLOC_END);
> > > > > > > > + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n",
> > > > > > > > VMEMMAP_START);
> > > > > > > > +
> > > > > > > > vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n",
> > > > > > > > VMEMMAP_END);
> > > > > > > > +#ifdef CONFIG_64BIT
> > > > > > > > + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n",
> > > > > > > > MODULES_VADDR);
> > > > > > > > +
> > > > > > > > vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n",
> > > > > > > > MODULES_END);
> > > > > > > > +#endif
> > > > > > > > +
> > > > > > > > +    if (IS_ENABLED(CONFIG_64BIT))
> > > > > > > > +
> > > > > > > > vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
> > > > > > > > KERNEL_LINK_ADDR);
> > > > > > > Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
> > > > > > > ifdeffery scope, with that you can save one line of
> > > > > > > "IS_ENABLED(CONFIG_64BIT)".
> > > > > > I followed the rule in print_vm_layout() of
> > > > > > arch/riscv/mm/init.c, which used
> > > > > > IS_ENABLED when print the value of KERNEL_LINK_ADDR.
> > > > > > 
> > > > > I see. There's PAGE_OFFSET in the middle. Thanks.
> > > > > 
> > > > >           print_ml("lowmem", (unsigned long)PAGE_OFFSET,
> > > > >                   (unsigned long)high_memory)
> > > > > 
> > > > > So now, do you think if it's necessary to have another
> > > > > IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
> > > > For which MACRO?  I think current code for PAGE_OFFSET is OK.
> > > > 
> 

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

[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.

+void arch_crash_save_vmcoreinfo(void)
+{
+       VMCOREINFO_NUMBER(VA_BITS);
+       VMCOREINFO_NUMBER(phys_ram_base);
+
+       vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
+       vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
+       vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
+       vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
+       vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
+#ifdef CONFIG_64BIT
+	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
+       vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
+       vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
+#endif
+}

> 
> Maybe we can remove IS_ENABLED(CONFIG_64BIT)
> 
> arch/riscv/include/asm/pgtable.h
> #define ADDRESS_SPACE_END       (UL(-1))
> #ifdef CONFIG_64BIT
> /* Leave 2GB for kernel and BPF at the end of the address space */
> #define KERNEL_LINK_ADDR        (ADDRESS_SPACE_END - SZ_2G + 1)
> #else
> #define KERNEL_LINK_ADDR        PAGE_OFFSET
> #endif
> 
> arch/riscv/include/asm/page.h
> #ifdef CONFIG_64BIT
> #ifdef CONFIG_MMU
> #define PAGE_OFFSET             kernel_map.page_offset
> #else
> #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
> #endif
> /*
>  * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address space so
>  * define the PAGE_OFFSET value for SV39.
>  */
> #define PAGE_OFFSET_L4          _AC(0xffffaf8000000000, UL)
> #define PAGE_OFFSET_L3          _AC(0xffffffd800000000, UL)
> #else
> #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
> #endif /* CONFIG_64BIT */
> 
> > 
> > Thanks,
> > Conor.
> > 
> > > 在 2022/10/20 下午12:40, Xianting Tian 写道:
> > > > 在 2022/10/20 上午11:05, Baoquan He 写道:
> > > > > On 10/20/22 at 10:17am, Xianting Tian wrote:
> > > > > > 在 2022/10/20 上午10:08, Baoquan He 写道:
> > > > > > > On 10/19/22 at 06:36pm, Xianting Tian wrote:
> > > > > > > > Add arch_crash_save_vmcoreinfo(), which exports VM
> > > > > > > > layout(MODULES, VMALLOC,
> > > > > > > > VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram
> > > > > > > > base for vmcore.
> > > > > > > > 
> > > > > > > > Default pagetable levels and PAGE_OFFSET aren't same for
> > > > > > > > different kernel
> > > > > > > > version as below. For pagetable levels, it sets sv57 by
> > > > > > > > default and falls
> > > > > > > > back to setting sv48 at boot time if sv57 is not
> > > > > > > > supported by the hardware.
> > > > > > > > 
> > > > > > > > For ram base, the default value is 0x80200000 for qemu
> > > > > > > > riscv64 env and,
> > > > > > > > for example, is 0x200000 on the XuanTie 910 CPU.
> > > > > > > > 
> > > > > > > >     * Linux Kernel 5.18 ~
> > > > > > > >     *      PGTABLE_LEVELS = 5
> > > > > > > >     *      PAGE_OFFSET = 0xff60000000000000
> > > > > > > >     * Linux Kernel 5.17 ~
> > > > > > > >     *      PGTABLE_LEVELS = 4
> > > > > > > >     *      PAGE_OFFSET = 0xffffaf8000000000
> > > > > > > >     * Linux Kernel 4.19 ~
> > > > > > > >     *      PGTABLE_LEVELS = 3
> > > > > > > >     *      PAGE_OFFSET = 0xffffffe000000000
> > > > > > > > 
> > > > > > > > Since these configurations change from time to time and
> > > > > > > > version to version,
> > > > > > > > it is preferable to export them via vmcoreinfo than to
> > > > > > > > change the crash's
> > > > > > > > code frequently, it can simplify the development of crash tool.
> > > > > > > > 
> > > > > > > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> > > > > > > > ---
> > > > > > > >     arch/riscv/kernel/Makefile     |  1 +
> > > > > > > >     arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
> > > > > > > >     2 files changed, 24 insertions(+)
> > > > > > > >     create mode 100644 arch/riscv/kernel/crash_core.c
> > > > > > > > 
> > > > > > > > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> > > > > > > > index db6e4b1294ba..4cf303a779ab 100644
> > > > > > > > --- a/arch/riscv/kernel/Makefile
> > > > > > > > +++ b/arch/riscv/kernel/Makefile
> > > > > > > > @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
> > > > > > > >     obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o
> > > > > > > > crash_save_regs.o machine_kexec.o
> > > > > > > >     obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
> > > > > > > >     obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
> > > > > > > > +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
> > > > > > > >     obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
> > > > > > > > diff --git a/arch/riscv/kernel/crash_core.c
> > > > > > > > b/arch/riscv/kernel/crash_core.c
> > > > > > > > new file mode 100644
> > > > > > > > index 000000000000..3e889d0ed7bd
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/arch/riscv/kernel/crash_core.c
> > > > > > > > @@ -0,0 +1,23 @@
> > > > > > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > > > > > +
> > > > > > > > +#include <linux/crash_core.h>
> > > > > > > > +#include <linux/pagemap.h>
> > > > > > > > +
> > > > > > > > +void arch_crash_save_vmcoreinfo(void)
> > > > > > > > +{
> > > > > > > > +    VMCOREINFO_NUMBER(VA_BITS);
> > > > > > > > +    VMCOREINFO_NUMBER(phys_ram_base);
> > > > > > > > +
> > > > > > > > +
> > > > > > > > vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n",
> > > > > > > > PAGE_OFFSET);
> > > > > > > > + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
> > > > > > > > VMALLOC_START);
> > > > > > > > +
> > > > > > > > vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n",
> > > > > > > > VMALLOC_END);
> > > > > > > > + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n",
> > > > > > > > VMEMMAP_START);
> > > > > > > > +
> > > > > > > > vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n",
> > > > > > > > VMEMMAP_END);
> > > > > > > > +#ifdef CONFIG_64BIT
> > > > > > > > + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n",
> > > > > > > > MODULES_VADDR);
> > > > > > > > +
> > > > > > > > vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n",
> > > > > > > > MODULES_END);
> > > > > > > > +#endif
> > > > > > > > +
> > > > > > > > +    if (IS_ENABLED(CONFIG_64BIT))
> > > > > > > > +
> > > > > > > > vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
> > > > > > > > KERNEL_LINK_ADDR);
> > > > > > > Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
> > > > > > > ifdeffery scope, with that you can save one line of
> > > > > > > "IS_ENABLED(CONFIG_64BIT)".
> > > > > > I followed the rule in print_vm_layout() of
> > > > > > arch/riscv/mm/init.c, which used
> > > > > > IS_ENABLED when print the value of KERNEL_LINK_ADDR.
> > > > > > 
> > > > > I see. There's PAGE_OFFSET in the middle. Thanks.
> > > > > 
> > > > >           print_ml("lowmem", (unsigned long)PAGE_OFFSET,
> > > > >                   (unsigned long)high_memory)
> > > > > 
> > > > > So now, do you think if it's necessary to have another
> > > > > IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
> > > > For which MACRO?  I think current code for PAGE_OFFSET is OK.
> > > > 
> 


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[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.

+void arch_crash_save_vmcoreinfo(void)
+{
+       VMCOREINFO_NUMBER(VA_BITS);
+       VMCOREINFO_NUMBER(phys_ram_base);
+
+       vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
+       vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
+       vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
+       vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
+       vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
+#ifdef CONFIG_64BIT
+	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
+       vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
+       vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
+#endif
+}

> 
> Maybe we can remove IS_ENABLED(CONFIG_64BIT)
> 
> arch/riscv/include/asm/pgtable.h
> #define ADDRESS_SPACE_END       (UL(-1))
> #ifdef CONFIG_64BIT
> /* Leave 2GB for kernel and BPF at the end of the address space */
> #define KERNEL_LINK_ADDR        (ADDRESS_SPACE_END - SZ_2G + 1)
> #else
> #define KERNEL_LINK_ADDR        PAGE_OFFSET
> #endif
> 
> arch/riscv/include/asm/page.h
> #ifdef CONFIG_64BIT
> #ifdef CONFIG_MMU
> #define PAGE_OFFSET             kernel_map.page_offset
> #else
> #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
> #endif
> /*
>  * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address space so
>  * define the PAGE_OFFSET value for SV39.
>  */
> #define PAGE_OFFSET_L4          _AC(0xffffaf8000000000, UL)
> #define PAGE_OFFSET_L3          _AC(0xffffffd800000000, UL)
> #else
> #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
> #endif /* CONFIG_64BIT */
> 
> > 
> > Thanks,
> > Conor.
> > 
> > > 在 2022/10/20 下午12:40, Xianting Tian 写道:
> > > > 在 2022/10/20 上午11:05, Baoquan He 写道:
> > > > > On 10/20/22 at 10:17am, Xianting Tian wrote:
> > > > > > 在 2022/10/20 上午10:08, Baoquan He 写道:
> > > > > > > On 10/19/22 at 06:36pm, Xianting Tian wrote:
> > > > > > > > Add arch_crash_save_vmcoreinfo(), which exports VM
> > > > > > > > layout(MODULES, VMALLOC,
> > > > > > > > VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram
> > > > > > > > base for vmcore.
> > > > > > > > 
> > > > > > > > Default pagetable levels and PAGE_OFFSET aren't same for
> > > > > > > > different kernel
> > > > > > > > version as below. For pagetable levels, it sets sv57 by
> > > > > > > > default and falls
> > > > > > > > back to setting sv48 at boot time if sv57 is not
> > > > > > > > supported by the hardware.
> > > > > > > > 
> > > > > > > > For ram base, the default value is 0x80200000 for qemu
> > > > > > > > riscv64 env and,
> > > > > > > > for example, is 0x200000 on the XuanTie 910 CPU.
> > > > > > > > 
> > > > > > > >     * Linux Kernel 5.18 ~
> > > > > > > >     *      PGTABLE_LEVELS = 5
> > > > > > > >     *      PAGE_OFFSET = 0xff60000000000000
> > > > > > > >     * Linux Kernel 5.17 ~
> > > > > > > >     *      PGTABLE_LEVELS = 4
> > > > > > > >     *      PAGE_OFFSET = 0xffffaf8000000000
> > > > > > > >     * Linux Kernel 4.19 ~
> > > > > > > >     *      PGTABLE_LEVELS = 3
> > > > > > > >     *      PAGE_OFFSET = 0xffffffe000000000
> > > > > > > > 
> > > > > > > > Since these configurations change from time to time and
> > > > > > > > version to version,
> > > > > > > > it is preferable to export them via vmcoreinfo than to
> > > > > > > > change the crash's
> > > > > > > > code frequently, it can simplify the development of crash tool.
> > > > > > > > 
> > > > > > > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> > > > > > > > ---
> > > > > > > >     arch/riscv/kernel/Makefile     |  1 +
> > > > > > > >     arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
> > > > > > > >     2 files changed, 24 insertions(+)
> > > > > > > >     create mode 100644 arch/riscv/kernel/crash_core.c
> > > > > > > > 
> > > > > > > > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> > > > > > > > index db6e4b1294ba..4cf303a779ab 100644
> > > > > > > > --- a/arch/riscv/kernel/Makefile
> > > > > > > > +++ b/arch/riscv/kernel/Makefile
> > > > > > > > @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
> > > > > > > >     obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o
> > > > > > > > crash_save_regs.o machine_kexec.o
> > > > > > > >     obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
> > > > > > > >     obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
> > > > > > > > +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
> > > > > > > >     obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
> > > > > > > > diff --git a/arch/riscv/kernel/crash_core.c
> > > > > > > > b/arch/riscv/kernel/crash_core.c
> > > > > > > > new file mode 100644
> > > > > > > > index 000000000000..3e889d0ed7bd
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/arch/riscv/kernel/crash_core.c
> > > > > > > > @@ -0,0 +1,23 @@
> > > > > > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > > > > > +
> > > > > > > > +#include <linux/crash_core.h>
> > > > > > > > +#include <linux/pagemap.h>
> > > > > > > > +
> > > > > > > > +void arch_crash_save_vmcoreinfo(void)
> > > > > > > > +{
> > > > > > > > +    VMCOREINFO_NUMBER(VA_BITS);
> > > > > > > > +    VMCOREINFO_NUMBER(phys_ram_base);
> > > > > > > > +
> > > > > > > > +
> > > > > > > > vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n",
> > > > > > > > PAGE_OFFSET);
> > > > > > > > + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
> > > > > > > > VMALLOC_START);
> > > > > > > > +
> > > > > > > > vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n",
> > > > > > > > VMALLOC_END);
> > > > > > > > + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n",
> > > > > > > > VMEMMAP_START);
> > > > > > > > +
> > > > > > > > vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n",
> > > > > > > > VMEMMAP_END);
> > > > > > > > +#ifdef CONFIG_64BIT
> > > > > > > > + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n",
> > > > > > > > MODULES_VADDR);
> > > > > > > > +
> > > > > > > > vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n",
> > > > > > > > MODULES_END);
> > > > > > > > +#endif
> > > > > > > > +
> > > > > > > > +    if (IS_ENABLED(CONFIG_64BIT))
> > > > > > > > +
> > > > > > > > vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
> > > > > > > > KERNEL_LINK_ADDR);
> > > > > > > Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
> > > > > > > ifdeffery scope, with that you can save one line of
> > > > > > > "IS_ENABLED(CONFIG_64BIT)".
> > > > > > I followed the rule in print_vm_layout() of
> > > > > > arch/riscv/mm/init.c, which used
> > > > > > IS_ENABLED when print the value of KERNEL_LINK_ADDR.
> > > > > > 
> > > > > I see. There's PAGE_OFFSET in the middle. Thanks.
> > > > > 
> > > > >           print_ml("lowmem", (unsigned long)PAGE_OFFSET,
> > > > >                   (unsigned long)high_memory)
> > > > > 
> > > > > So now, do you think if it's necessary to have another
> > > > > IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
> > > > For which MACRO?  I think current code for PAGE_OFFSET is OK.
> > > > 
> 


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

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

[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.

> 
> +void arch_crash_save_vmcoreinfo(void)
> +{
> +       VMCOREINFO_NUMBER(VA_BITS);
> +       VMCOREINFO_NUMBER(phys_ram_base);
> +
> +       vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
> +       vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
> +       vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
> +#ifdef CONFIG_64BIT
> +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
> +       vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
> +       vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
> +#endif
> +}
> 
> > 
> > Maybe we can remove IS_ENABLED(CONFIG_64BIT)
> > 
> > arch/riscv/include/asm/pgtable.h
> > #define ADDRESS_SPACE_END       (UL(-1))
> > #ifdef CONFIG_64BIT
> > /* Leave 2GB for kernel and BPF at the end of the address space */
> > #define KERNEL_LINK_ADDR        (ADDRESS_SPACE_END - SZ_2G + 1)
> > #else
> > #define KERNEL_LINK_ADDR        PAGE_OFFSET
> > #endif
> > 
> > arch/riscv/include/asm/page.h
> > #ifdef CONFIG_64BIT
> > #ifdef CONFIG_MMU
> > #define PAGE_OFFSET             kernel_map.page_offset
> > #else
> > #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
> > #endif
> > /*
> >  * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address space so
> >  * define the PAGE_OFFSET value for SV39.
> >  */
> > #define PAGE_OFFSET_L4          _AC(0xffffaf8000000000, UL)
> > #define PAGE_OFFSET_L3          _AC(0xffffffd800000000, UL)
> > #else
> > #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
> > #endif /* CONFIG_64BIT */
> > 
> > > 
> > > Thanks,
> > > Conor.
> > > 
> > > > 在 2022/10/20 下午12:40, Xianting Tian 写道:
> > > > > 在 2022/10/20 上午11:05, Baoquan He 写道:
> > > > > > On 10/20/22 at 10:17am, Xianting Tian wrote:
> > > > > > > 在 2022/10/20 上午10:08, Baoquan He 写道:
> > > > > > > > On 10/19/22 at 06:36pm, Xianting Tian wrote:
> > > > > > > > > Add arch_crash_save_vmcoreinfo(), which exports VM
> > > > > > > > > layout(MODULES, VMALLOC,
> > > > > > > > > VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram
> > > > > > > > > base for vmcore.
> > > > > > > > > 
> > > > > > > > > Default pagetable levels and PAGE_OFFSET aren't same for
> > > > > > > > > different kernel
> > > > > > > > > version as below. For pagetable levels, it sets sv57 by
> > > > > > > > > default and falls
> > > > > > > > > back to setting sv48 at boot time if sv57 is not
> > > > > > > > > supported by the hardware.
> > > > > > > > > 
> > > > > > > > > For ram base, the default value is 0x80200000 for qemu
> > > > > > > > > riscv64 env and,
> > > > > > > > > for example, is 0x200000 on the XuanTie 910 CPU.
> > > > > > > > > 
> > > > > > > > >     * Linux Kernel 5.18 ~
> > > > > > > > >     *      PGTABLE_LEVELS = 5
> > > > > > > > >     *      PAGE_OFFSET = 0xff60000000000000
> > > > > > > > >     * Linux Kernel 5.17 ~
> > > > > > > > >     *      PGTABLE_LEVELS = 4
> > > > > > > > >     *      PAGE_OFFSET = 0xffffaf8000000000
> > > > > > > > >     * Linux Kernel 4.19 ~
> > > > > > > > >     *      PGTABLE_LEVELS = 3
> > > > > > > > >     *      PAGE_OFFSET = 0xffffffe000000000
> > > > > > > > > 
> > > > > > > > > Since these configurations change from time to time and
> > > > > > > > > version to version,
> > > > > > > > > it is preferable to export them via vmcoreinfo than to
> > > > > > > > > change the crash's
> > > > > > > > > code frequently, it can simplify the development of crash tool.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> > > > > > > > > ---
> > > > > > > > >     arch/riscv/kernel/Makefile     |  1 +
> > > > > > > > >     arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
> > > > > > > > >     2 files changed, 24 insertions(+)
> > > > > > > > >     create mode 100644 arch/riscv/kernel/crash_core.c
> > > > > > > > > 
> > > > > > > > > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> > > > > > > > > index db6e4b1294ba..4cf303a779ab 100644
> > > > > > > > > --- a/arch/riscv/kernel/Makefile
> > > > > > > > > +++ b/arch/riscv/kernel/Makefile
> > > > > > > > > @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
> > > > > > > > >     obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o
> > > > > > > > > crash_save_regs.o machine_kexec.o
> > > > > > > > >     obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
> > > > > > > > >     obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
> > > > > > > > > +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
> > > > > > > > >     obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
> > > > > > > > > diff --git a/arch/riscv/kernel/crash_core.c
> > > > > > > > > b/arch/riscv/kernel/crash_core.c
> > > > > > > > > new file mode 100644
> > > > > > > > > index 000000000000..3e889d0ed7bd
> > > > > > > > > --- /dev/null
> > > > > > > > > +++ b/arch/riscv/kernel/crash_core.c
> > > > > > > > > @@ -0,0 +1,23 @@
> > > > > > > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > > > > > > +
> > > > > > > > > +#include <linux/crash_core.h>
> > > > > > > > > +#include <linux/pagemap.h>
> > > > > > > > > +
> > > > > > > > > +void arch_crash_save_vmcoreinfo(void)
> > > > > > > > > +{
> > > > > > > > > +    VMCOREINFO_NUMBER(VA_BITS);
> > > > > > > > > +    VMCOREINFO_NUMBER(phys_ram_base);
> > > > > > > > > +
> > > > > > > > > +
> > > > > > > > > vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n",
> > > > > > > > > PAGE_OFFSET);
> > > > > > > > > + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
> > > > > > > > > VMALLOC_START);
> > > > > > > > > +
> > > > > > > > > vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n",
> > > > > > > > > VMALLOC_END);
> > > > > > > > > + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n",
> > > > > > > > > VMEMMAP_START);
> > > > > > > > > +
> > > > > > > > > vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n",
> > > > > > > > > VMEMMAP_END);
> > > > > > > > > +#ifdef CONFIG_64BIT
> > > > > > > > > + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n",
> > > > > > > > > MODULES_VADDR);
> > > > > > > > > +
> > > > > > > > > vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n",
> > > > > > > > > MODULES_END);
> > > > > > > > > +#endif
> > > > > > > > > +
> > > > > > > > > +    if (IS_ENABLED(CONFIG_64BIT))
> > > > > > > > > +
> > > > > > > > > vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
> > > > > > > > > KERNEL_LINK_ADDR);
> > > > > > > > Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
> > > > > > > > ifdeffery scope, with that you can save one line of
> > > > > > > > "IS_ENABLED(CONFIG_64BIT)".
> > > > > > > I followed the rule in print_vm_layout() of
> > > > > > > arch/riscv/mm/init.c, which used
> > > > > > > IS_ENABLED when print the value of KERNEL_LINK_ADDR.
> > > > > > > 
> > > > > > I see. There's PAGE_OFFSET in the middle. Thanks.
> > > > > > 
> > > > > >           print_ml("lowmem", (unsigned long)PAGE_OFFSET,
> > > > > >                   (unsigned long)high_memory)
> > > > > > 
> > > > > > So now, do you think if it's necessary to have another
> > > > > > IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
> > > > > For which MACRO?  I think current code for PAGE_OFFSET is OK.
> > > > > 
> > 
> 

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

[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.

> 
> +void arch_crash_save_vmcoreinfo(void)
> +{
> +       VMCOREINFO_NUMBER(VA_BITS);
> +       VMCOREINFO_NUMBER(phys_ram_base);
> +
> +       vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
> +       vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
> +       vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
> +#ifdef CONFIG_64BIT
> +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
> +       vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
> +       vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
> +#endif
> +}
> 
> > 
> > Maybe we can remove IS_ENABLED(CONFIG_64BIT)
> > 
> > arch/riscv/include/asm/pgtable.h
> > #define ADDRESS_SPACE_END       (UL(-1))
> > #ifdef CONFIG_64BIT
> > /* Leave 2GB for kernel and BPF at the end of the address space */
> > #define KERNEL_LINK_ADDR        (ADDRESS_SPACE_END - SZ_2G + 1)
> > #else
> > #define KERNEL_LINK_ADDR        PAGE_OFFSET
> > #endif
> > 
> > arch/riscv/include/asm/page.h
> > #ifdef CONFIG_64BIT
> > #ifdef CONFIG_MMU
> > #define PAGE_OFFSET             kernel_map.page_offset
> > #else
> > #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
> > #endif
> > /*
> >  * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address space so
> >  * define the PAGE_OFFSET value for SV39.
> >  */
> > #define PAGE_OFFSET_L4          _AC(0xffffaf8000000000, UL)
> > #define PAGE_OFFSET_L3          _AC(0xffffffd800000000, UL)
> > #else
> > #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
> > #endif /* CONFIG_64BIT */
> > 
> > > 
> > > Thanks,
> > > Conor.
> > > 
> > > > 在 2022/10/20 下午12:40, Xianting Tian 写道:
> > > > > 在 2022/10/20 上午11:05, Baoquan He 写道:
> > > > > > On 10/20/22 at 10:17am, Xianting Tian wrote:
> > > > > > > 在 2022/10/20 上午10:08, Baoquan He 写道:
> > > > > > > > On 10/19/22 at 06:36pm, Xianting Tian wrote:
> > > > > > > > > Add arch_crash_save_vmcoreinfo(), which exports VM
> > > > > > > > > layout(MODULES, VMALLOC,
> > > > > > > > > VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram
> > > > > > > > > base for vmcore.
> > > > > > > > > 
> > > > > > > > > Default pagetable levels and PAGE_OFFSET aren't same for
> > > > > > > > > different kernel
> > > > > > > > > version as below. For pagetable levels, it sets sv57 by
> > > > > > > > > default and falls
> > > > > > > > > back to setting sv48 at boot time if sv57 is not
> > > > > > > > > supported by the hardware.
> > > > > > > > > 
> > > > > > > > > For ram base, the default value is 0x80200000 for qemu
> > > > > > > > > riscv64 env and,
> > > > > > > > > for example, is 0x200000 on the XuanTie 910 CPU.
> > > > > > > > > 
> > > > > > > > >     * Linux Kernel 5.18 ~
> > > > > > > > >     *      PGTABLE_LEVELS = 5
> > > > > > > > >     *      PAGE_OFFSET = 0xff60000000000000
> > > > > > > > >     * Linux Kernel 5.17 ~
> > > > > > > > >     *      PGTABLE_LEVELS = 4
> > > > > > > > >     *      PAGE_OFFSET = 0xffffaf8000000000
> > > > > > > > >     * Linux Kernel 4.19 ~
> > > > > > > > >     *      PGTABLE_LEVELS = 3
> > > > > > > > >     *      PAGE_OFFSET = 0xffffffe000000000
> > > > > > > > > 
> > > > > > > > > Since these configurations change from time to time and
> > > > > > > > > version to version,
> > > > > > > > > it is preferable to export them via vmcoreinfo than to
> > > > > > > > > change the crash's
> > > > > > > > > code frequently, it can simplify the development of crash tool.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> > > > > > > > > ---
> > > > > > > > >     arch/riscv/kernel/Makefile     |  1 +
> > > > > > > > >     arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
> > > > > > > > >     2 files changed, 24 insertions(+)
> > > > > > > > >     create mode 100644 arch/riscv/kernel/crash_core.c
> > > > > > > > > 
> > > > > > > > > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> > > > > > > > > index db6e4b1294ba..4cf303a779ab 100644
> > > > > > > > > --- a/arch/riscv/kernel/Makefile
> > > > > > > > > +++ b/arch/riscv/kernel/Makefile
> > > > > > > > > @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
> > > > > > > > >     obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o
> > > > > > > > > crash_save_regs.o machine_kexec.o
> > > > > > > > >     obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
> > > > > > > > >     obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
> > > > > > > > > +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
> > > > > > > > >     obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
> > > > > > > > > diff --git a/arch/riscv/kernel/crash_core.c
> > > > > > > > > b/arch/riscv/kernel/crash_core.c
> > > > > > > > > new file mode 100644
> > > > > > > > > index 000000000000..3e889d0ed7bd
> > > > > > > > > --- /dev/null
> > > > > > > > > +++ b/arch/riscv/kernel/crash_core.c
> > > > > > > > > @@ -0,0 +1,23 @@
> > > > > > > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > > > > > > +
> > > > > > > > > +#include <linux/crash_core.h>
> > > > > > > > > +#include <linux/pagemap.h>
> > > > > > > > > +
> > > > > > > > > +void arch_crash_save_vmcoreinfo(void)
> > > > > > > > > +{
> > > > > > > > > +    VMCOREINFO_NUMBER(VA_BITS);
> > > > > > > > > +    VMCOREINFO_NUMBER(phys_ram_base);
> > > > > > > > > +
> > > > > > > > > +
> > > > > > > > > vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n",
> > > > > > > > > PAGE_OFFSET);
> > > > > > > > > + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
> > > > > > > > > VMALLOC_START);
> > > > > > > > > +
> > > > > > > > > vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n",
> > > > > > > > > VMALLOC_END);
> > > > > > > > > + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n",
> > > > > > > > > VMEMMAP_START);
> > > > > > > > > +
> > > > > > > > > vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n",
> > > > > > > > > VMEMMAP_END);
> > > > > > > > > +#ifdef CONFIG_64BIT
> > > > > > > > > + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n",
> > > > > > > > > MODULES_VADDR);
> > > > > > > > > +
> > > > > > > > > vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n",
> > > > > > > > > MODULES_END);
> > > > > > > > > +#endif
> > > > > > > > > +
> > > > > > > > > +    if (IS_ENABLED(CONFIG_64BIT))
> > > > > > > > > +
> > > > > > > > > vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
> > > > > > > > > KERNEL_LINK_ADDR);
> > > > > > > > Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
> > > > > > > > ifdeffery scope, with that you can save one line of
> > > > > > > > "IS_ENABLED(CONFIG_64BIT)".
> > > > > > > I followed the rule in print_vm_layout() of
> > > > > > > arch/riscv/mm/init.c, which used
> > > > > > > IS_ENABLED when print the value of KERNEL_LINK_ADDR.
> > > > > > > 
> > > > > > I see. There's PAGE_OFFSET in the middle. Thanks.
> > > > > > 
> > > > > >           print_ml("lowmem", (unsigned long)PAGE_OFFSET,
> > > > > >                   (unsigned long)high_memory)
> > > > > > 
> > > > > > So now, do you think if it's necessary to have another
> > > > > > IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
> > > > > For which MACRO?  I think current code for PAGE_OFFSET is OK.
> > > > > 
> > 
> 

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

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

[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.

> 
> +void arch_crash_save_vmcoreinfo(void)
> +{
> +       VMCOREINFO_NUMBER(VA_BITS);
> +       VMCOREINFO_NUMBER(phys_ram_base);
> +
> +       vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
> +       vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
> +       vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
> +#ifdef CONFIG_64BIT
> +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
> +       vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
> +       vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
> +#endif
> +}
> 
> > 
> > Maybe we can remove IS_ENABLED(CONFIG_64BIT)
> > 
> > arch/riscv/include/asm/pgtable.h
> > #define ADDRESS_SPACE_END       (UL(-1))
> > #ifdef CONFIG_64BIT
> > /* Leave 2GB for kernel and BPF at the end of the address space */
> > #define KERNEL_LINK_ADDR        (ADDRESS_SPACE_END - SZ_2G + 1)
> > #else
> > #define KERNEL_LINK_ADDR        PAGE_OFFSET
> > #endif
> > 
> > arch/riscv/include/asm/page.h
> > #ifdef CONFIG_64BIT
> > #ifdef CONFIG_MMU
> > #define PAGE_OFFSET             kernel_map.page_offset
> > #else
> > #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
> > #endif
> > /*
> >  * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address space so
> >  * define the PAGE_OFFSET value for SV39.
> >  */
> > #define PAGE_OFFSET_L4          _AC(0xffffaf8000000000, UL)
> > #define PAGE_OFFSET_L3          _AC(0xffffffd800000000, UL)
> > #else
> > #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
> > #endif /* CONFIG_64BIT */
> > 
> > > 
> > > Thanks,
> > > Conor.
> > > 
> > > > 在 2022/10/20 下午12:40, Xianting Tian 写道:
> > > > > 在 2022/10/20 上午11:05, Baoquan He 写道:
> > > > > > On 10/20/22 at 10:17am, Xianting Tian wrote:
> > > > > > > 在 2022/10/20 上午10:08, Baoquan He 写道:
> > > > > > > > On 10/19/22 at 06:36pm, Xianting Tian wrote:
> > > > > > > > > Add arch_crash_save_vmcoreinfo(), which exports VM
> > > > > > > > > layout(MODULES, VMALLOC,
> > > > > > > > > VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram
> > > > > > > > > base for vmcore.
> > > > > > > > > 
> > > > > > > > > Default pagetable levels and PAGE_OFFSET aren't same for
> > > > > > > > > different kernel
> > > > > > > > > version as below. For pagetable levels, it sets sv57 by
> > > > > > > > > default and falls
> > > > > > > > > back to setting sv48 at boot time if sv57 is not
> > > > > > > > > supported by the hardware.
> > > > > > > > > 
> > > > > > > > > For ram base, the default value is 0x80200000 for qemu
> > > > > > > > > riscv64 env and,
> > > > > > > > > for example, is 0x200000 on the XuanTie 910 CPU.
> > > > > > > > > 
> > > > > > > > >     * Linux Kernel 5.18 ~
> > > > > > > > >     *      PGTABLE_LEVELS = 5
> > > > > > > > >     *      PAGE_OFFSET = 0xff60000000000000
> > > > > > > > >     * Linux Kernel 5.17 ~
> > > > > > > > >     *      PGTABLE_LEVELS = 4
> > > > > > > > >     *      PAGE_OFFSET = 0xffffaf8000000000
> > > > > > > > >     * Linux Kernel 4.19 ~
> > > > > > > > >     *      PGTABLE_LEVELS = 3
> > > > > > > > >     *      PAGE_OFFSET = 0xffffffe000000000
> > > > > > > > > 
> > > > > > > > > Since these configurations change from time to time and
> > > > > > > > > version to version,
> > > > > > > > > it is preferable to export them via vmcoreinfo than to
> > > > > > > > > change the crash's
> > > > > > > > > code frequently, it can simplify the development of crash tool.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> > > > > > > > > ---
> > > > > > > > >     arch/riscv/kernel/Makefile     |  1 +
> > > > > > > > >     arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
> > > > > > > > >     2 files changed, 24 insertions(+)
> > > > > > > > >     create mode 100644 arch/riscv/kernel/crash_core.c
> > > > > > > > > 
> > > > > > > > > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> > > > > > > > > index db6e4b1294ba..4cf303a779ab 100644
> > > > > > > > > --- a/arch/riscv/kernel/Makefile
> > > > > > > > > +++ b/arch/riscv/kernel/Makefile
> > > > > > > > > @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
> > > > > > > > >     obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o
> > > > > > > > > crash_save_regs.o machine_kexec.o
> > > > > > > > >     obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
> > > > > > > > >     obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
> > > > > > > > > +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
> > > > > > > > >     obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
> > > > > > > > > diff --git a/arch/riscv/kernel/crash_core.c
> > > > > > > > > b/arch/riscv/kernel/crash_core.c
> > > > > > > > > new file mode 100644
> > > > > > > > > index 000000000000..3e889d0ed7bd
> > > > > > > > > --- /dev/null
> > > > > > > > > +++ b/arch/riscv/kernel/crash_core.c
> > > > > > > > > @@ -0,0 +1,23 @@
> > > > > > > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > > > > > > +
> > > > > > > > > +#include <linux/crash_core.h>
> > > > > > > > > +#include <linux/pagemap.h>
> > > > > > > > > +
> > > > > > > > > +void arch_crash_save_vmcoreinfo(void)
> > > > > > > > > +{
> > > > > > > > > +    VMCOREINFO_NUMBER(VA_BITS);
> > > > > > > > > +    VMCOREINFO_NUMBER(phys_ram_base);
> > > > > > > > > +
> > > > > > > > > +
> > > > > > > > > vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n",
> > > > > > > > > PAGE_OFFSET);
> > > > > > > > > + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
> > > > > > > > > VMALLOC_START);
> > > > > > > > > +
> > > > > > > > > vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n",
> > > > > > > > > VMALLOC_END);
> > > > > > > > > + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n",
> > > > > > > > > VMEMMAP_START);
> > > > > > > > > +
> > > > > > > > > vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n",
> > > > > > > > > VMEMMAP_END);
> > > > > > > > > +#ifdef CONFIG_64BIT
> > > > > > > > > + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n",
> > > > > > > > > MODULES_VADDR);
> > > > > > > > > +
> > > > > > > > > vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n",
> > > > > > > > > MODULES_END);
> > > > > > > > > +#endif
> > > > > > > > > +
> > > > > > > > > +    if (IS_ENABLED(CONFIG_64BIT))
> > > > > > > > > +
> > > > > > > > > vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
> > > > > > > > > KERNEL_LINK_ADDR);
> > > > > > > > Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
> > > > > > > > ifdeffery scope, with that you can save one line of
> > > > > > > > "IS_ENABLED(CONFIG_64BIT)".
> > > > > > > I followed the rule in print_vm_layout() of
> > > > > > > arch/riscv/mm/init.c, which used
> > > > > > > IS_ENABLED when print the value of KERNEL_LINK_ADDR.
> > > > > > > 
> > > > > > I see. There's PAGE_OFFSET in the middle. Thanks.
> > > > > > 
> > > > > >           print_ml("lowmem", (unsigned long)PAGE_OFFSET,
> > > > > >                   (unsigned long)high_memory)
> > > > > > 
> > > > > > So now, do you think if it's necessary to have another
> > > > > > IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
> > > > > For which MACRO?  I think current code for PAGE_OFFSET is OK.
> > > > > 
> > 
> 

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Xianting Tian]

在 2022/10/26 下午8:05, Baoquan He 写道:
> Hi Xianting,
>
> On 10/26/22 at 05:44pm, Xianting Tian wrote:
>> 在 2022/10/26 下午5:25, Conor Dooley 写道:
>>> On Wed, Oct 26, 2022 at 05:08:11PM +0800, Xianting Tian wrote:
>>>> Hi Palmer, Conor
>>>>
>>>> Is this version OK for you?
>>> The weird ifdef/IS_ENABLED thing was the only comment I had. It's a bit
>>> odd & I notice Baoquan brought it up too. I didn't (and won't) give you
>>> a reviewed by on these patches because I don't understand the area well
>>> enough. The general nitpickery seems to be sorted though.
>> I checked the KERNEL_LINK_ADDR definition of riscv,  it is valid for
>> CONFIG_64BIT and !CONFIG_64BIT.
> This series looks good to me. My only minor concern is if we can make
> the arch_crash_save_vmcoreinfo() as below. I don't understand why we
> have to have the CONFIG_64BIT ifdeffery and the IS_ENABLED(CONFIG_64BIT)
> between two adjacent code blocks. Not sure if we are saying the same
> thing.

KERNEL_LINK_ADDR is valid for both CONFIG_64BIT and !CONFIG_64BIT, but  
MODULES_VADDR is only defined when CONFIG_64BIT.

I tend to agree only remove IS_ENABLED, thanks

For riscv:

#ifdef CONFIG_64BIT

/* Leave 2GB for kernel and BPF at the end of the address space */
#define KERNEL_LINK_ADDR        (ADDRESS_SPACE_END - SZ_2G + 1)
#else
#define KERNEL_LINK_ADDR        PAGE_OFFSET
#endif
>
> +void arch_crash_save_vmcoreinfo(void)
> +{
> +       VMCOREINFO_NUMBER(VA_BITS);
> +       VMCOREINFO_NUMBER(phys_ram_base);
> +
> +       vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
> +       vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
> +       vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
> +#ifdef CONFIG_64BIT
> +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
> +       vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
> +       vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
> +#endif
> +}
>
>> Maybe we can remove IS_ENABLED(CONFIG_64BIT)
>>
>> arch/riscv/include/asm/pgtable.h
>> #define ADDRESS_SPACE_END       (UL(-1))
>> #ifdef CONFIG_64BIT
>> /* Leave 2GB for kernel and BPF at the end of the address space */
>> #define KERNEL_LINK_ADDR        (ADDRESS_SPACE_END - SZ_2G + 1)
>> #else
>> #define KERNEL_LINK_ADDR        PAGE_OFFSET
>> #endif
>>
>> arch/riscv/include/asm/page.h
>> #ifdef CONFIG_64BIT
>> #ifdef CONFIG_MMU
>> #define PAGE_OFFSET             kernel_map.page_offset
>> #else
>> #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
>> #endif
>> /*
>>   * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address space so
>>   * define the PAGE_OFFSET value for SV39.
>>   */
>> #define PAGE_OFFSET_L4          _AC(0xffffaf8000000000, UL)
>> #define PAGE_OFFSET_L3          _AC(0xffffffd800000000, UL)
>> #else
>> #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
>> #endif /* CONFIG_64BIT */
>>
>>> Thanks,
>>> Conor.
>>>
>>>> 在 2022/10/20 下午12:40, Xianting Tian 写道:
>>>>> 在 2022/10/20 上午11:05, Baoquan He 写道:
>>>>>> On 10/20/22 at 10:17am, Xianting Tian wrote:
>>>>>>> 在 2022/10/20 上午10:08, Baoquan He 写道:
>>>>>>>> On 10/19/22 at 06:36pm, Xianting Tian wrote:
>>>>>>>>> Add arch_crash_save_vmcoreinfo(), which exports VM
>>>>>>>>> layout(MODULES, VMALLOC,
>>>>>>>>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram
>>>>>>>>> base for vmcore.
>>>>>>>>>
>>>>>>>>> Default pagetable levels and PAGE_OFFSET aren't same for
>>>>>>>>> different kernel
>>>>>>>>> version as below. For pagetable levels, it sets sv57 by
>>>>>>>>> default and falls
>>>>>>>>> back to setting sv48 at boot time if sv57 is not
>>>>>>>>> supported by the hardware.
>>>>>>>>>
>>>>>>>>> For ram base, the default value is 0x80200000 for qemu
>>>>>>>>> riscv64 env and,
>>>>>>>>> for example, is 0x200000 on the XuanTie 910 CPU.
>>>>>>>>>
>>>>>>>>>      * Linux Kernel 5.18 ~
>>>>>>>>>      *      PGTABLE_LEVELS = 5
>>>>>>>>>      *      PAGE_OFFSET = 0xff60000000000000
>>>>>>>>>      * Linux Kernel 5.17 ~
>>>>>>>>>      *      PGTABLE_LEVELS = 4
>>>>>>>>>      *      PAGE_OFFSET = 0xffffaf8000000000
>>>>>>>>>      * Linux Kernel 4.19 ~
>>>>>>>>>      *      PGTABLE_LEVELS = 3
>>>>>>>>>      *      PAGE_OFFSET = 0xffffffe000000000
>>>>>>>>>
>>>>>>>>> Since these configurations change from time to time and
>>>>>>>>> version to version,
>>>>>>>>> it is preferable to export them via vmcoreinfo than to
>>>>>>>>> change the crash's
>>>>>>>>> code frequently, it can simplify the development of crash tool.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
>>>>>>>>> ---
>>>>>>>>>      arch/riscv/kernel/Makefile     |  1 +
>>>>>>>>>      arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>>>>>>>>>      2 files changed, 24 insertions(+)
>>>>>>>>>      create mode 100644 arch/riscv/kernel/crash_core.c
>>>>>>>>>
>>>>>>>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
>>>>>>>>> index db6e4b1294ba..4cf303a779ab 100644
>>>>>>>>> --- a/arch/riscv/kernel/Makefile
>>>>>>>>> +++ b/arch/riscv/kernel/Makefile
>>>>>>>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
>>>>>>>>>      obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o
>>>>>>>>> crash_save_regs.o machine_kexec.o
>>>>>>>>>      obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
>>>>>>>>>      obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
>>>>>>>>> +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
>>>>>>>>>      obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
>>>>>>>>> diff --git a/arch/riscv/kernel/crash_core.c
>>>>>>>>> b/arch/riscv/kernel/crash_core.c
>>>>>>>>> new file mode 100644
>>>>>>>>> index 000000000000..3e889d0ed7bd
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/arch/riscv/kernel/crash_core.c
>>>>>>>>> @@ -0,0 +1,23 @@
>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0-only
>>>>>>>>> +
>>>>>>>>> +#include <linux/crash_core.h>
>>>>>>>>> +#include <linux/pagemap.h>
>>>>>>>>> +
>>>>>>>>> +void arch_crash_save_vmcoreinfo(void)
>>>>>>>>> +{
>>>>>>>>> +    VMCOREINFO_NUMBER(VA_BITS);
>>>>>>>>> +    VMCOREINFO_NUMBER(phys_ram_base);
>>>>>>>>> +
>>>>>>>>> +
>>>>>>>>> vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n",
>>>>>>>>> PAGE_OFFSET);
>>>>>>>>> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
>>>>>>>>> VMALLOC_START);
>>>>>>>>> +
>>>>>>>>> vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n",
>>>>>>>>> VMALLOC_END);
>>>>>>>>> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n",
>>>>>>>>> VMEMMAP_START);
>>>>>>>>> +
>>>>>>>>> vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n",
>>>>>>>>> VMEMMAP_END);
>>>>>>>>> +#ifdef CONFIG_64BIT
>>>>>>>>> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n",
>>>>>>>>> MODULES_VADDR);
>>>>>>>>> +
>>>>>>>>> vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n",
>>>>>>>>> MODULES_END);
>>>>>>>>> +#endif
>>>>>>>>> +
>>>>>>>>> +    if (IS_ENABLED(CONFIG_64BIT))
>>>>>>>>> +
>>>>>>>>> vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
>>>>>>>>> KERNEL_LINK_ADDR);
>>>>>>>> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
>>>>>>>> ifdeffery scope, with that you can save one line of
>>>>>>>> "IS_ENABLED(CONFIG_64BIT)".
>>>>>>> I followed the rule in print_vm_layout() of
>>>>>>> arch/riscv/mm/init.c, which used
>>>>>>> IS_ENABLED when print the value of KERNEL_LINK_ADDR.
>>>>>>>
>>>>>> I see. There's PAGE_OFFSET in the middle. Thanks.
>>>>>>
>>>>>>            print_ml("lowmem", (unsigned long)PAGE_OFFSET,
>>>>>>                    (unsigned long)high_memory)
>>>>>>
>>>>>> So now, do you think if it's necessary to have another
>>>>>> IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
>>>>> For which MACRO?  I think current code for PAGE_OFFSET is OK.
>>>>>

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

[Xianting Tian]

在 2022/10/26 下午8:05, Baoquan He 写道:
> Hi Xianting,
>
> On 10/26/22 at 05:44pm, Xianting Tian wrote:
>> 在 2022/10/26 下午5:25, Conor Dooley 写道:
>>> On Wed, Oct 26, 2022 at 05:08:11PM +0800, Xianting Tian wrote:
>>>> Hi Palmer, Conor
>>>>
>>>> Is this version OK for you?
>>> The weird ifdef/IS_ENABLED thing was the only comment I had. It's a bit
>>> odd & I notice Baoquan brought it up too. I didn't (and won't) give you
>>> a reviewed by on these patches because I don't understand the area well
>>> enough. The general nitpickery seems to be sorted though.
>> I checked the KERNEL_LINK_ADDR definition of riscv,  it is valid for
>> CONFIG_64BIT and !CONFIG_64BIT.
> This series looks good to me. My only minor concern is if we can make
> the arch_crash_save_vmcoreinfo() as below. I don't understand why we
> have to have the CONFIG_64BIT ifdeffery and the IS_ENABLED(CONFIG_64BIT)
> between two adjacent code blocks. Not sure if we are saying the same
> thing.

KERNEL_LINK_ADDR is valid for both CONFIG_64BIT and !CONFIG_64BIT, but  
MODULES_VADDR is only defined when CONFIG_64BIT.

I tend to agree only remove IS_ENABLED, thanks

For riscv:

#ifdef CONFIG_64BIT

/* Leave 2GB for kernel and BPF at the end of the address space */
#define KERNEL_LINK_ADDR        (ADDRESS_SPACE_END - SZ_2G + 1)
#else
#define KERNEL_LINK_ADDR        PAGE_OFFSET
#endif
>
> +void arch_crash_save_vmcoreinfo(void)
> +{
> +       VMCOREINFO_NUMBER(VA_BITS);
> +       VMCOREINFO_NUMBER(phys_ram_base);
> +
> +       vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
> +       vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
> +       vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
> +#ifdef CONFIG_64BIT
> +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
> +       vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
> +       vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
> +#endif
> +}
>
>> Maybe we can remove IS_ENABLED(CONFIG_64BIT)
>>
>> arch/riscv/include/asm/pgtable.h
>> #define ADDRESS_SPACE_END       (UL(-1))
>> #ifdef CONFIG_64BIT
>> /* Leave 2GB for kernel and BPF at the end of the address space */
>> #define KERNEL_LINK_ADDR        (ADDRESS_SPACE_END - SZ_2G + 1)
>> #else
>> #define KERNEL_LINK_ADDR        PAGE_OFFSET
>> #endif
>>
>> arch/riscv/include/asm/page.h
>> #ifdef CONFIG_64BIT
>> #ifdef CONFIG_MMU
>> #define PAGE_OFFSET             kernel_map.page_offset
>> #else
>> #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
>> #endif
>> /*
>>   * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address space so
>>   * define the PAGE_OFFSET value for SV39.
>>   */
>> #define PAGE_OFFSET_L4          _AC(0xffffaf8000000000, UL)
>> #define PAGE_OFFSET_L3          _AC(0xffffffd800000000, UL)
>> #else
>> #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
>> #endif /* CONFIG_64BIT */
>>
>>> Thanks,
>>> Conor.
>>>
>>>> 在 2022/10/20 下午12:40, Xianting Tian 写道:
>>>>> 在 2022/10/20 上午11:05, Baoquan He 写道:
>>>>>> On 10/20/22 at 10:17am, Xianting Tian wrote:
>>>>>>> 在 2022/10/20 上午10:08, Baoquan He 写道:
>>>>>>>> On 10/19/22 at 06:36pm, Xianting Tian wrote:
>>>>>>>>> Add arch_crash_save_vmcoreinfo(), which exports VM
>>>>>>>>> layout(MODULES, VMALLOC,
>>>>>>>>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram
>>>>>>>>> base for vmcore.
>>>>>>>>>
>>>>>>>>> Default pagetable levels and PAGE_OFFSET aren't same for
>>>>>>>>> different kernel
>>>>>>>>> version as below. For pagetable levels, it sets sv57 by
>>>>>>>>> default and falls
>>>>>>>>> back to setting sv48 at boot time if sv57 is not
>>>>>>>>> supported by the hardware.
>>>>>>>>>
>>>>>>>>> For ram base, the default value is 0x80200000 for qemu
>>>>>>>>> riscv64 env and,
>>>>>>>>> for example, is 0x200000 on the XuanTie 910 CPU.
>>>>>>>>>
>>>>>>>>>      * Linux Kernel 5.18 ~
>>>>>>>>>      *      PGTABLE_LEVELS = 5
>>>>>>>>>      *      PAGE_OFFSET = 0xff60000000000000
>>>>>>>>>      * Linux Kernel 5.17 ~
>>>>>>>>>      *      PGTABLE_LEVELS = 4
>>>>>>>>>      *      PAGE_OFFSET = 0xffffaf8000000000
>>>>>>>>>      * Linux Kernel 4.19 ~
>>>>>>>>>      *      PGTABLE_LEVELS = 3
>>>>>>>>>      *      PAGE_OFFSET = 0xffffffe000000000
>>>>>>>>>
>>>>>>>>> Since these configurations change from time to time and
>>>>>>>>> version to version,
>>>>>>>>> it is preferable to export them via vmcoreinfo than to
>>>>>>>>> change the crash's
>>>>>>>>> code frequently, it can simplify the development of crash tool.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
>>>>>>>>> ---
>>>>>>>>>      arch/riscv/kernel/Makefile     |  1 +
>>>>>>>>>      arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>>>>>>>>>      2 files changed, 24 insertions(+)
>>>>>>>>>      create mode 100644 arch/riscv/kernel/crash_core.c
>>>>>>>>>
>>>>>>>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
>>>>>>>>> index db6e4b1294ba..4cf303a779ab 100644
>>>>>>>>> --- a/arch/riscv/kernel/Makefile
>>>>>>>>> +++ b/arch/riscv/kernel/Makefile
>>>>>>>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
>>>>>>>>>      obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o
>>>>>>>>> crash_save_regs.o machine_kexec.o
>>>>>>>>>      obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
>>>>>>>>>      obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
>>>>>>>>> +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
>>>>>>>>>      obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
>>>>>>>>> diff --git a/arch/riscv/kernel/crash_core.c
>>>>>>>>> b/arch/riscv/kernel/crash_core.c
>>>>>>>>> new file mode 100644
>>>>>>>>> index 000000000000..3e889d0ed7bd
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/arch/riscv/kernel/crash_core.c
>>>>>>>>> @@ -0,0 +1,23 @@
>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0-only
>>>>>>>>> +
>>>>>>>>> +#include <linux/crash_core.h>
>>>>>>>>> +#include <linux/pagemap.h>
>>>>>>>>> +
>>>>>>>>> +void arch_crash_save_vmcoreinfo(void)
>>>>>>>>> +{
>>>>>>>>> +    VMCOREINFO_NUMBER(VA_BITS);
>>>>>>>>> +    VMCOREINFO_NUMBER(phys_ram_base);
>>>>>>>>> +
>>>>>>>>> +
>>>>>>>>> vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n",
>>>>>>>>> PAGE_OFFSET);
>>>>>>>>> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
>>>>>>>>> VMALLOC_START);
>>>>>>>>> +
>>>>>>>>> vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n",
>>>>>>>>> VMALLOC_END);
>>>>>>>>> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n",
>>>>>>>>> VMEMMAP_START);
>>>>>>>>> +
>>>>>>>>> vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n",
>>>>>>>>> VMEMMAP_END);
>>>>>>>>> +#ifdef CONFIG_64BIT
>>>>>>>>> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n",
>>>>>>>>> MODULES_VADDR);
>>>>>>>>> +
>>>>>>>>> vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n",
>>>>>>>>> MODULES_END);
>>>>>>>>> +#endif
>>>>>>>>> +
>>>>>>>>> +    if (IS_ENABLED(CONFIG_64BIT))
>>>>>>>>> +
>>>>>>>>> vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
>>>>>>>>> KERNEL_LINK_ADDR);
>>>>>>>> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
>>>>>>>> ifdeffery scope, with that you can save one line of
>>>>>>>> "IS_ENABLED(CONFIG_64BIT)".
>>>>>>> I followed the rule in print_vm_layout() of
>>>>>>> arch/riscv/mm/init.c, which used
>>>>>>> IS_ENABLED when print the value of KERNEL_LINK_ADDR.
>>>>>>>
>>>>>> I see. There's PAGE_OFFSET in the middle. Thanks.
>>>>>>
>>>>>>            print_ml("lowmem", (unsigned long)PAGE_OFFSET,
>>>>>>                    (unsigned long)high_memory)
>>>>>>
>>>>>> So now, do you think if it's necessary to have another
>>>>>> IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
>>>>> For which MACRO?  I think current code for PAGE_OFFSET is OK.
>>>>>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Xianting Tian]

在 2022/10/26 下午8:05, Baoquan He 写道:
> Hi Xianting,
>
> On 10/26/22 at 05:44pm, Xianting Tian wrote:
>> 在 2022/10/26 下午5:25, Conor Dooley 写道:
>>> On Wed, Oct 26, 2022 at 05:08:11PM +0800, Xianting Tian wrote:
>>>> Hi Palmer, Conor
>>>>
>>>> Is this version OK for you?
>>> The weird ifdef/IS_ENABLED thing was the only comment I had. It's a bit
>>> odd & I notice Baoquan brought it up too. I didn't (and won't) give you
>>> a reviewed by on these patches because I don't understand the area well
>>> enough. The general nitpickery seems to be sorted though.
>> I checked the KERNEL_LINK_ADDR definition of riscv,  it is valid for
>> CONFIG_64BIT and !CONFIG_64BIT.
> This series looks good to me. My only minor concern is if we can make
> the arch_crash_save_vmcoreinfo() as below. I don't understand why we
> have to have the CONFIG_64BIT ifdeffery and the IS_ENABLED(CONFIG_64BIT)
> between two adjacent code blocks. Not sure if we are saying the same
> thing.

KERNEL_LINK_ADDR is valid for both CONFIG_64BIT and !CONFIG_64BIT, but  
MODULES_VADDR is only defined when CONFIG_64BIT.

I tend to agree only remove IS_ENABLED, thanks

For riscv:

#ifdef CONFIG_64BIT

/* Leave 2GB for kernel and BPF at the end of the address space */
#define KERNEL_LINK_ADDR        (ADDRESS_SPACE_END - SZ_2G + 1)
#else
#define KERNEL_LINK_ADDR        PAGE_OFFSET
#endif
>
> +void arch_crash_save_vmcoreinfo(void)
> +{
> +       VMCOREINFO_NUMBER(VA_BITS);
> +       VMCOREINFO_NUMBER(phys_ram_base);
> +
> +       vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
> +       vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
> +       vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
> +#ifdef CONFIG_64BIT
> +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
> +       vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
> +       vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
> +#endif
> +}
>
>> Maybe we can remove IS_ENABLED(CONFIG_64BIT)
>>
>> arch/riscv/include/asm/pgtable.h
>> #define ADDRESS_SPACE_END       (UL(-1))
>> #ifdef CONFIG_64BIT
>> /* Leave 2GB for kernel and BPF at the end of the address space */
>> #define KERNEL_LINK_ADDR        (ADDRESS_SPACE_END - SZ_2G + 1)
>> #else
>> #define KERNEL_LINK_ADDR        PAGE_OFFSET
>> #endif
>>
>> arch/riscv/include/asm/page.h
>> #ifdef CONFIG_64BIT
>> #ifdef CONFIG_MMU
>> #define PAGE_OFFSET             kernel_map.page_offset
>> #else
>> #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
>> #endif
>> /*
>>   * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address space so
>>   * define the PAGE_OFFSET value for SV39.
>>   */
>> #define PAGE_OFFSET_L4          _AC(0xffffaf8000000000, UL)
>> #define PAGE_OFFSET_L3          _AC(0xffffffd800000000, UL)
>> #else
>> #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
>> #endif /* CONFIG_64BIT */
>>
>>> Thanks,
>>> Conor.
>>>
>>>> 在 2022/10/20 下午12:40, Xianting Tian 写道:
>>>>> 在 2022/10/20 上午11:05, Baoquan He 写道:
>>>>>> On 10/20/22 at 10:17am, Xianting Tian wrote:
>>>>>>> 在 2022/10/20 上午10:08, Baoquan He 写道:
>>>>>>>> On 10/19/22 at 06:36pm, Xianting Tian wrote:
>>>>>>>>> Add arch_crash_save_vmcoreinfo(), which exports VM
>>>>>>>>> layout(MODULES, VMALLOC,
>>>>>>>>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram
>>>>>>>>> base for vmcore.
>>>>>>>>>
>>>>>>>>> Default pagetable levels and PAGE_OFFSET aren't same for
>>>>>>>>> different kernel
>>>>>>>>> version as below. For pagetable levels, it sets sv57 by
>>>>>>>>> default and falls
>>>>>>>>> back to setting sv48 at boot time if sv57 is not
>>>>>>>>> supported by the hardware.
>>>>>>>>>
>>>>>>>>> For ram base, the default value is 0x80200000 for qemu
>>>>>>>>> riscv64 env and,
>>>>>>>>> for example, is 0x200000 on the XuanTie 910 CPU.
>>>>>>>>>
>>>>>>>>>      * Linux Kernel 5.18 ~
>>>>>>>>>      *      PGTABLE_LEVELS = 5
>>>>>>>>>      *      PAGE_OFFSET = 0xff60000000000000
>>>>>>>>>      * Linux Kernel 5.17 ~
>>>>>>>>>      *      PGTABLE_LEVELS = 4
>>>>>>>>>      *      PAGE_OFFSET = 0xffffaf8000000000
>>>>>>>>>      * Linux Kernel 4.19 ~
>>>>>>>>>      *      PGTABLE_LEVELS = 3
>>>>>>>>>      *      PAGE_OFFSET = 0xffffffe000000000
>>>>>>>>>
>>>>>>>>> Since these configurations change from time to time and
>>>>>>>>> version to version,
>>>>>>>>> it is preferable to export them via vmcoreinfo than to
>>>>>>>>> change the crash's
>>>>>>>>> code frequently, it can simplify the development of crash tool.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
>>>>>>>>> ---
>>>>>>>>>      arch/riscv/kernel/Makefile     |  1 +
>>>>>>>>>      arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>>>>>>>>>      2 files changed, 24 insertions(+)
>>>>>>>>>      create mode 100644 arch/riscv/kernel/crash_core.c
>>>>>>>>>
>>>>>>>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
>>>>>>>>> index db6e4b1294ba..4cf303a779ab 100644
>>>>>>>>> --- a/arch/riscv/kernel/Makefile
>>>>>>>>> +++ b/arch/riscv/kernel/Makefile
>>>>>>>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
>>>>>>>>>      obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o
>>>>>>>>> crash_save_regs.o machine_kexec.o
>>>>>>>>>      obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
>>>>>>>>>      obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
>>>>>>>>> +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
>>>>>>>>>      obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
>>>>>>>>> diff --git a/arch/riscv/kernel/crash_core.c
>>>>>>>>> b/arch/riscv/kernel/crash_core.c
>>>>>>>>> new file mode 100644
>>>>>>>>> index 000000000000..3e889d0ed7bd
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/arch/riscv/kernel/crash_core.c
>>>>>>>>> @@ -0,0 +1,23 @@
>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0-only
>>>>>>>>> +
>>>>>>>>> +#include <linux/crash_core.h>
>>>>>>>>> +#include <linux/pagemap.h>
>>>>>>>>> +
>>>>>>>>> +void arch_crash_save_vmcoreinfo(void)
>>>>>>>>> +{
>>>>>>>>> +    VMCOREINFO_NUMBER(VA_BITS);
>>>>>>>>> +    VMCOREINFO_NUMBER(phys_ram_base);
>>>>>>>>> +
>>>>>>>>> +
>>>>>>>>> vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n",
>>>>>>>>> PAGE_OFFSET);
>>>>>>>>> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
>>>>>>>>> VMALLOC_START);
>>>>>>>>> +
>>>>>>>>> vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n",
>>>>>>>>> VMALLOC_END);
>>>>>>>>> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n",
>>>>>>>>> VMEMMAP_START);
>>>>>>>>> +
>>>>>>>>> vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n",
>>>>>>>>> VMEMMAP_END);
>>>>>>>>> +#ifdef CONFIG_64BIT
>>>>>>>>> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n",
>>>>>>>>> MODULES_VADDR);
>>>>>>>>> +
>>>>>>>>> vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n",
>>>>>>>>> MODULES_END);
>>>>>>>>> +#endif
>>>>>>>>> +
>>>>>>>>> +    if (IS_ENABLED(CONFIG_64BIT))
>>>>>>>>> +
>>>>>>>>> vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
>>>>>>>>> KERNEL_LINK_ADDR);
>>>>>>>> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
>>>>>>>> ifdeffery scope, with that you can save one line of
>>>>>>>> "IS_ENABLED(CONFIG_64BIT)".
>>>>>>> I followed the rule in print_vm_layout() of
>>>>>>> arch/riscv/mm/init.c, which used
>>>>>>> IS_ENABLED when print the value of KERNEL_LINK_ADDR.
>>>>>>>
>>>>>> I see. There's PAGE_OFFSET in the middle. Thanks.
>>>>>>
>>>>>>            print_ml("lowmem", (unsigned long)PAGE_OFFSET,
>>>>>>                    (unsigned long)high_memory)
>>>>>>
>>>>>> So now, do you think if it's necessary to have another
>>>>>> IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
>>>>> For which MACRO?  I think current code for PAGE_OFFSET is OK.
>>>>>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

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

[Xianting Tian]

在 2022/10/26 下午9:47, Conor Dooley 写道:
> On Wed, Oct 26, 2022 at 08:05:41PM +0800, Baoquan He wrote:
>> Hi Xianting,
>>
>> On 10/26/22 at 05:44pm, Xianting Tian wrote:
>>> 在 2022/10/26 下午5:25, Conor Dooley 写道:
>>>> On Wed, Oct 26, 2022 at 05:08:11PM +0800, Xianting Tian wrote:
>>>>> Hi Palmer, Conor
>>>>>
>>>>> Is this version OK for you?
>>>> The weird ifdef/IS_ENABLED thing was the only comment I had. It's a bit
>>>> odd & I notice Baoquan brought it up too. I didn't (and won't) give you
>>>> a reviewed by on these patches because I don't understand the area well
>>>> enough. The general nitpickery seems to be sorted though.
>>> I checked the KERNEL_LINK_ADDR definition of riscv,  it is valid for
>>> CONFIG_64BIT and !CONFIG_64BIT.
>> This series looks good to me. My only minor concern is if we can make
>> the arch_crash_save_vmcoreinfo() as below. I don't understand why we
>> have to have the CONFIG_64BIT ifdeffery and the IS_ENABLED(CONFIG_64BIT)
>> between two adjacent code blocks. Not sure if we are saying the same
>> thing.
> I think we can just go and drop the IS_ENABLED(). From looking at it
> last time, one bit is compileable (but not usable) for !64BIT and the
> other isn't hence the IS_ENABLED(). I think it would make sense to drop
> the IS_ENABLED() - I don't think we're too likely to hit some compile
> testing edge cases that IS_ENABLED() would help with & only having one
> makes the code look a lot less odd and a lot more intentional.
thanks, I will send V5 patch for review.
>
>> +void arch_crash_save_vmcoreinfo(void)
>> +{
>> +       VMCOREINFO_NUMBER(VA_BITS);
>> +       VMCOREINFO_NUMBER(phys_ram_base);
>> +
>> +       vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
>> +       vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
>> +       vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
>> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
>> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
>> +#ifdef CONFIG_64BIT
>> +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
>> +       vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
>> +       vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
>> +#endif
>> +}
>>
>>> Maybe we can remove IS_ENABLED(CONFIG_64BIT)
>>>
>>> arch/riscv/include/asm/pgtable.h
>>> #define ADDRESS_SPACE_END       (UL(-1))
>>> #ifdef CONFIG_64BIT
>>> /* Leave 2GB for kernel and BPF at the end of the address space */
>>> #define KERNEL_LINK_ADDR        (ADDRESS_SPACE_END - SZ_2G + 1)
>>> #else
>>> #define KERNEL_LINK_ADDR        PAGE_OFFSET
>>> #endif
>>>
>>> arch/riscv/include/asm/page.h
>>> #ifdef CONFIG_64BIT
>>> #ifdef CONFIG_MMU
>>> #define PAGE_OFFSET             kernel_map.page_offset
>>> #else
>>> #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
>>> #endif
>>> /*
>>>   * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address space so
>>>   * define the PAGE_OFFSET value for SV39.
>>>   */
>>> #define PAGE_OFFSET_L4          _AC(0xffffaf8000000000, UL)
>>> #define PAGE_OFFSET_L3          _AC(0xffffffd800000000, UL)
>>> #else
>>> #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
>>> #endif /* CONFIG_64BIT */
>>>
>>>> Thanks,
>>>> Conor.
>>>>
>>>>> 在 2022/10/20 下午12:40, Xianting Tian 写道:
>>>>>> 在 2022/10/20 上午11:05, Baoquan He 写道:
>>>>>>> On 10/20/22 at 10:17am, Xianting Tian wrote:
>>>>>>>> 在 2022/10/20 上午10:08, Baoquan He 写道:
>>>>>>>>> On 10/19/22 at 06:36pm, Xianting Tian wrote:
>>>>>>>>>> Add arch_crash_save_vmcoreinfo(), which exports VM
>>>>>>>>>> layout(MODULES, VMALLOC,
>>>>>>>>>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram
>>>>>>>>>> base for vmcore.
>>>>>>>>>>
>>>>>>>>>> Default pagetable levels and PAGE_OFFSET aren't same for
>>>>>>>>>> different kernel
>>>>>>>>>> version as below. For pagetable levels, it sets sv57 by
>>>>>>>>>> default and falls
>>>>>>>>>> back to setting sv48 at boot time if sv57 is not
>>>>>>>>>> supported by the hardware.
>>>>>>>>>>
>>>>>>>>>> For ram base, the default value is 0x80200000 for qemu
>>>>>>>>>> riscv64 env and,
>>>>>>>>>> for example, is 0x200000 on the XuanTie 910 CPU.
>>>>>>>>>>
>>>>>>>>>>      * Linux Kernel 5.18 ~
>>>>>>>>>>      *      PGTABLE_LEVELS = 5
>>>>>>>>>>      *      PAGE_OFFSET = 0xff60000000000000
>>>>>>>>>>      * Linux Kernel 5.17 ~
>>>>>>>>>>      *      PGTABLE_LEVELS = 4
>>>>>>>>>>      *      PAGE_OFFSET = 0xffffaf8000000000
>>>>>>>>>>      * Linux Kernel 4.19 ~
>>>>>>>>>>      *      PGTABLE_LEVELS = 3
>>>>>>>>>>      *      PAGE_OFFSET = 0xffffffe000000000
>>>>>>>>>>
>>>>>>>>>> Since these configurations change from time to time and
>>>>>>>>>> version to version,
>>>>>>>>>> it is preferable to export them via vmcoreinfo than to
>>>>>>>>>> change the crash's
>>>>>>>>>> code frequently, it can simplify the development of crash tool.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
>>>>>>>>>> ---
>>>>>>>>>>      arch/riscv/kernel/Makefile     |  1 +
>>>>>>>>>>      arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>>>>>>>>>>      2 files changed, 24 insertions(+)
>>>>>>>>>>      create mode 100644 arch/riscv/kernel/crash_core.c
>>>>>>>>>>
>>>>>>>>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
>>>>>>>>>> index db6e4b1294ba..4cf303a779ab 100644
>>>>>>>>>> --- a/arch/riscv/kernel/Makefile
>>>>>>>>>> +++ b/arch/riscv/kernel/Makefile
>>>>>>>>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
>>>>>>>>>>      obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o
>>>>>>>>>> crash_save_regs.o machine_kexec.o
>>>>>>>>>>      obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
>>>>>>>>>>      obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
>>>>>>>>>> +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
>>>>>>>>>>      obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
>>>>>>>>>> diff --git a/arch/riscv/kernel/crash_core.c
>>>>>>>>>> b/arch/riscv/kernel/crash_core.c
>>>>>>>>>> new file mode 100644
>>>>>>>>>> index 000000000000..3e889d0ed7bd
>>>>>>>>>> --- /dev/null
>>>>>>>>>> +++ b/arch/riscv/kernel/crash_core.c
>>>>>>>>>> @@ -0,0 +1,23 @@
>>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0-only
>>>>>>>>>> +
>>>>>>>>>> +#include <linux/crash_core.h>
>>>>>>>>>> +#include <linux/pagemap.h>
>>>>>>>>>> +
>>>>>>>>>> +void arch_crash_save_vmcoreinfo(void)
>>>>>>>>>> +{
>>>>>>>>>> +    VMCOREINFO_NUMBER(VA_BITS);
>>>>>>>>>> +    VMCOREINFO_NUMBER(phys_ram_base);
>>>>>>>>>> +
>>>>>>>>>> +
>>>>>>>>>> vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n",
>>>>>>>>>> PAGE_OFFSET);
>>>>>>>>>> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
>>>>>>>>>> VMALLOC_START);
>>>>>>>>>> +
>>>>>>>>>> vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n",
>>>>>>>>>> VMALLOC_END);
>>>>>>>>>> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n",
>>>>>>>>>> VMEMMAP_START);
>>>>>>>>>> +
>>>>>>>>>> vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n",
>>>>>>>>>> VMEMMAP_END);
>>>>>>>>>> +#ifdef CONFIG_64BIT
>>>>>>>>>> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n",
>>>>>>>>>> MODULES_VADDR);
>>>>>>>>>> +
>>>>>>>>>> vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n",
>>>>>>>>>> MODULES_END);
>>>>>>>>>> +#endif
>>>>>>>>>> +
>>>>>>>>>> +    if (IS_ENABLED(CONFIG_64BIT))
>>>>>>>>>> +
>>>>>>>>>> vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
>>>>>>>>>> KERNEL_LINK_ADDR);
>>>>>>>>> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
>>>>>>>>> ifdeffery scope, with that you can save one line of
>>>>>>>>> "IS_ENABLED(CONFIG_64BIT)".
>>>>>>>> I followed the rule in print_vm_layout() of
>>>>>>>> arch/riscv/mm/init.c, which used
>>>>>>>> IS_ENABLED when print the value of KERNEL_LINK_ADDR.
>>>>>>>>
>>>>>>> I see. There's PAGE_OFFSET in the middle. Thanks.
>>>>>>>
>>>>>>>            print_ml("lowmem", (unsigned long)PAGE_OFFSET,
>>>>>>>                    (unsigned long)high_memory)
>>>>>>>
>>>>>>> So now, do you think if it's necessary to have another
>>>>>>> IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
>>>>>> For which MACRO?  I think current code for PAGE_OFFSET is OK.
>>>>>>

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

[Xianting Tian]

在 2022/10/26 下午9:47, Conor Dooley 写道:
> On Wed, Oct 26, 2022 at 08:05:41PM +0800, Baoquan He wrote:
>> Hi Xianting,
>>
>> On 10/26/22 at 05:44pm, Xianting Tian wrote:
>>> 在 2022/10/26 下午5:25, Conor Dooley 写道:
>>>> On Wed, Oct 26, 2022 at 05:08:11PM +0800, Xianting Tian wrote:
>>>>> Hi Palmer, Conor
>>>>>
>>>>> Is this version OK for you?
>>>> The weird ifdef/IS_ENABLED thing was the only comment I had. It's a bit
>>>> odd & I notice Baoquan brought it up too. I didn't (and won't) give you
>>>> a reviewed by on these patches because I don't understand the area well
>>>> enough. The general nitpickery seems to be sorted though.
>>> I checked the KERNEL_LINK_ADDR definition of riscv,  it is valid for
>>> CONFIG_64BIT and !CONFIG_64BIT.
>> This series looks good to me. My only minor concern is if we can make
>> the arch_crash_save_vmcoreinfo() as below. I don't understand why we
>> have to have the CONFIG_64BIT ifdeffery and the IS_ENABLED(CONFIG_64BIT)
>> between two adjacent code blocks. Not sure if we are saying the same
>> thing.
> I think we can just go and drop the IS_ENABLED(). From looking at it
> last time, one bit is compileable (but not usable) for !64BIT and the
> other isn't hence the IS_ENABLED(). I think it would make sense to drop
> the IS_ENABLED() - I don't think we're too likely to hit some compile
> testing edge cases that IS_ENABLED() would help with & only having one
> makes the code look a lot less odd and a lot more intentional.
thanks, I will send V5 patch for review.
>
>> +void arch_crash_save_vmcoreinfo(void)
>> +{
>> +       VMCOREINFO_NUMBER(VA_BITS);
>> +       VMCOREINFO_NUMBER(phys_ram_base);
>> +
>> +       vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
>> +       vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
>> +       vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
>> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
>> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
>> +#ifdef CONFIG_64BIT
>> +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
>> +       vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
>> +       vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
>> +#endif
>> +}
>>
>>> Maybe we can remove IS_ENABLED(CONFIG_64BIT)
>>>
>>> arch/riscv/include/asm/pgtable.h
>>> #define ADDRESS_SPACE_END       (UL(-1))
>>> #ifdef CONFIG_64BIT
>>> /* Leave 2GB for kernel and BPF at the end of the address space */
>>> #define KERNEL_LINK_ADDR        (ADDRESS_SPACE_END - SZ_2G + 1)
>>> #else
>>> #define KERNEL_LINK_ADDR        PAGE_OFFSET
>>> #endif
>>>
>>> arch/riscv/include/asm/page.h
>>> #ifdef CONFIG_64BIT
>>> #ifdef CONFIG_MMU
>>> #define PAGE_OFFSET             kernel_map.page_offset
>>> #else
>>> #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
>>> #endif
>>> /*
>>>   * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address space so
>>>   * define the PAGE_OFFSET value for SV39.
>>>   */
>>> #define PAGE_OFFSET_L4          _AC(0xffffaf8000000000, UL)
>>> #define PAGE_OFFSET_L3          _AC(0xffffffd800000000, UL)
>>> #else
>>> #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
>>> #endif /* CONFIG_64BIT */
>>>
>>>> Thanks,
>>>> Conor.
>>>>
>>>>> 在 2022/10/20 下午12:40, Xianting Tian 写道:
>>>>>> 在 2022/10/20 上午11:05, Baoquan He 写道:
>>>>>>> On 10/20/22 at 10:17am, Xianting Tian wrote:
>>>>>>>> 在 2022/10/20 上午10:08, Baoquan He 写道:
>>>>>>>>> On 10/19/22 at 06:36pm, Xianting Tian wrote:
>>>>>>>>>> Add arch_crash_save_vmcoreinfo(), which exports VM
>>>>>>>>>> layout(MODULES, VMALLOC,
>>>>>>>>>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram
>>>>>>>>>> base for vmcore.
>>>>>>>>>>
>>>>>>>>>> Default pagetable levels and PAGE_OFFSET aren't same for
>>>>>>>>>> different kernel
>>>>>>>>>> version as below. For pagetable levels, it sets sv57 by
>>>>>>>>>> default and falls
>>>>>>>>>> back to setting sv48 at boot time if sv57 is not
>>>>>>>>>> supported by the hardware.
>>>>>>>>>>
>>>>>>>>>> For ram base, the default value is 0x80200000 for qemu
>>>>>>>>>> riscv64 env and,
>>>>>>>>>> for example, is 0x200000 on the XuanTie 910 CPU.
>>>>>>>>>>
>>>>>>>>>>      * Linux Kernel 5.18 ~
>>>>>>>>>>      *      PGTABLE_LEVELS = 5
>>>>>>>>>>      *      PAGE_OFFSET = 0xff60000000000000
>>>>>>>>>>      * Linux Kernel 5.17 ~
>>>>>>>>>>      *      PGTABLE_LEVELS = 4
>>>>>>>>>>      *      PAGE_OFFSET = 0xffffaf8000000000
>>>>>>>>>>      * Linux Kernel 4.19 ~
>>>>>>>>>>      *      PGTABLE_LEVELS = 3
>>>>>>>>>>      *      PAGE_OFFSET = 0xffffffe000000000
>>>>>>>>>>
>>>>>>>>>> Since these configurations change from time to time and
>>>>>>>>>> version to version,
>>>>>>>>>> it is preferable to export them via vmcoreinfo than to
>>>>>>>>>> change the crash's
>>>>>>>>>> code frequently, it can simplify the development of crash tool.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
>>>>>>>>>> ---
>>>>>>>>>>      arch/riscv/kernel/Makefile     |  1 +
>>>>>>>>>>      arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>>>>>>>>>>      2 files changed, 24 insertions(+)
>>>>>>>>>>      create mode 100644 arch/riscv/kernel/crash_core.c
>>>>>>>>>>
>>>>>>>>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
>>>>>>>>>> index db6e4b1294ba..4cf303a779ab 100644
>>>>>>>>>> --- a/arch/riscv/kernel/Makefile
>>>>>>>>>> +++ b/arch/riscv/kernel/Makefile
>>>>>>>>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
>>>>>>>>>>      obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o
>>>>>>>>>> crash_save_regs.o machine_kexec.o
>>>>>>>>>>      obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
>>>>>>>>>>      obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
>>>>>>>>>> +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
>>>>>>>>>>      obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
>>>>>>>>>> diff --git a/arch/riscv/kernel/crash_core.c
>>>>>>>>>> b/arch/riscv/kernel/crash_core.c
>>>>>>>>>> new file mode 100644
>>>>>>>>>> index 000000000000..3e889d0ed7bd
>>>>>>>>>> --- /dev/null
>>>>>>>>>> +++ b/arch/riscv/kernel/crash_core.c
>>>>>>>>>> @@ -0,0 +1,23 @@
>>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0-only
>>>>>>>>>> +
>>>>>>>>>> +#include <linux/crash_core.h>
>>>>>>>>>> +#include <linux/pagemap.h>
>>>>>>>>>> +
>>>>>>>>>> +void arch_crash_save_vmcoreinfo(void)
>>>>>>>>>> +{
>>>>>>>>>> +    VMCOREINFO_NUMBER(VA_BITS);
>>>>>>>>>> +    VMCOREINFO_NUMBER(phys_ram_base);
>>>>>>>>>> +
>>>>>>>>>> +
>>>>>>>>>> vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n",
>>>>>>>>>> PAGE_OFFSET);
>>>>>>>>>> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
>>>>>>>>>> VMALLOC_START);
>>>>>>>>>> +
>>>>>>>>>> vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n",
>>>>>>>>>> VMALLOC_END);
>>>>>>>>>> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n",
>>>>>>>>>> VMEMMAP_START);
>>>>>>>>>> +
>>>>>>>>>> vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n",
>>>>>>>>>> VMEMMAP_END);
>>>>>>>>>> +#ifdef CONFIG_64BIT
>>>>>>>>>> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n",
>>>>>>>>>> MODULES_VADDR);
>>>>>>>>>> +
>>>>>>>>>> vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n",
>>>>>>>>>> MODULES_END);
>>>>>>>>>> +#endif
>>>>>>>>>> +
>>>>>>>>>> +    if (IS_ENABLED(CONFIG_64BIT))
>>>>>>>>>> +
>>>>>>>>>> vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
>>>>>>>>>> KERNEL_LINK_ADDR);
>>>>>>>>> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
>>>>>>>>> ifdeffery scope, with that you can save one line of
>>>>>>>>> "IS_ENABLED(CONFIG_64BIT)".
>>>>>>>> I followed the rule in print_vm_layout() of
>>>>>>>> arch/riscv/mm/init.c, which used
>>>>>>>> IS_ENABLED when print the value of KERNEL_LINK_ADDR.
>>>>>>>>
>>>>>>> I see. There's PAGE_OFFSET in the middle. Thanks.
>>>>>>>
>>>>>>>            print_ml("lowmem", (unsigned long)PAGE_OFFSET,
>>>>>>>                    (unsigned long)high_memory)
>>>>>>>
>>>>>>> So now, do you think if it's necessary to have another
>>>>>>> IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
>>>>>> For which MACRO?  I think current code for PAGE_OFFSET is OK.
>>>>>>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Xianting Tian]

在 2022/10/26 下午9:47, Conor Dooley 写道:
> On Wed, Oct 26, 2022 at 08:05:41PM +0800, Baoquan He wrote:
>> Hi Xianting,
>>
>> On 10/26/22 at 05:44pm, Xianting Tian wrote:
>>> 在 2022/10/26 下午5:25, Conor Dooley 写道:
>>>> On Wed, Oct 26, 2022 at 05:08:11PM +0800, Xianting Tian wrote:
>>>>> Hi Palmer, Conor
>>>>>
>>>>> Is this version OK for you?
>>>> The weird ifdef/IS_ENABLED thing was the only comment I had. It's a bit
>>>> odd & I notice Baoquan brought it up too. I didn't (and won't) give you
>>>> a reviewed by on these patches because I don't understand the area well
>>>> enough. The general nitpickery seems to be sorted though.
>>> I checked the KERNEL_LINK_ADDR definition of riscv,  it is valid for
>>> CONFIG_64BIT and !CONFIG_64BIT.
>> This series looks good to me. My only minor concern is if we can make
>> the arch_crash_save_vmcoreinfo() as below. I don't understand why we
>> have to have the CONFIG_64BIT ifdeffery and the IS_ENABLED(CONFIG_64BIT)
>> between two adjacent code blocks. Not sure if we are saying the same
>> thing.
> I think we can just go and drop the IS_ENABLED(). From looking at it
> last time, one bit is compileable (but not usable) for !64BIT and the
> other isn't hence the IS_ENABLED(). I think it would make sense to drop
> the IS_ENABLED() - I don't think we're too likely to hit some compile
> testing edge cases that IS_ENABLED() would help with & only having one
> makes the code look a lot less odd and a lot more intentional.
thanks, I will send V5 patch for review.
>
>> +void arch_crash_save_vmcoreinfo(void)
>> +{
>> +       VMCOREINFO_NUMBER(VA_BITS);
>> +       VMCOREINFO_NUMBER(phys_ram_base);
>> +
>> +       vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
>> +       vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
>> +       vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
>> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
>> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
>> +#ifdef CONFIG_64BIT
>> +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
>> +       vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
>> +       vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
>> +#endif
>> +}
>>
>>> Maybe we can remove IS_ENABLED(CONFIG_64BIT)
>>>
>>> arch/riscv/include/asm/pgtable.h
>>> #define ADDRESS_SPACE_END       (UL(-1))
>>> #ifdef CONFIG_64BIT
>>> /* Leave 2GB for kernel and BPF at the end of the address space */
>>> #define KERNEL_LINK_ADDR        (ADDRESS_SPACE_END - SZ_2G + 1)
>>> #else
>>> #define KERNEL_LINK_ADDR        PAGE_OFFSET
>>> #endif
>>>
>>> arch/riscv/include/asm/page.h
>>> #ifdef CONFIG_64BIT
>>> #ifdef CONFIG_MMU
>>> #define PAGE_OFFSET             kernel_map.page_offset
>>> #else
>>> #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
>>> #endif
>>> /*
>>>   * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address space so
>>>   * define the PAGE_OFFSET value for SV39.
>>>   */
>>> #define PAGE_OFFSET_L4          _AC(0xffffaf8000000000, UL)
>>> #define PAGE_OFFSET_L3          _AC(0xffffffd800000000, UL)
>>> #else
>>> #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
>>> #endif /* CONFIG_64BIT */
>>>
>>>> Thanks,
>>>> Conor.
>>>>
>>>>> 在 2022/10/20 下午12:40, Xianting Tian 写道:
>>>>>> 在 2022/10/20 上午11:05, Baoquan He 写道:
>>>>>>> On 10/20/22 at 10:17am, Xianting Tian wrote:
>>>>>>>> 在 2022/10/20 上午10:08, Baoquan He 写道:
>>>>>>>>> On 10/19/22 at 06:36pm, Xianting Tian wrote:
>>>>>>>>>> Add arch_crash_save_vmcoreinfo(), which exports VM
>>>>>>>>>> layout(MODULES, VMALLOC,
>>>>>>>>>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram
>>>>>>>>>> base for vmcore.
>>>>>>>>>>
>>>>>>>>>> Default pagetable levels and PAGE_OFFSET aren't same for
>>>>>>>>>> different kernel
>>>>>>>>>> version as below. For pagetable levels, it sets sv57 by
>>>>>>>>>> default and falls
>>>>>>>>>> back to setting sv48 at boot time if sv57 is not
>>>>>>>>>> supported by the hardware.
>>>>>>>>>>
>>>>>>>>>> For ram base, the default value is 0x80200000 for qemu
>>>>>>>>>> riscv64 env and,
>>>>>>>>>> for example, is 0x200000 on the XuanTie 910 CPU.
>>>>>>>>>>
>>>>>>>>>>      * Linux Kernel 5.18 ~
>>>>>>>>>>      *      PGTABLE_LEVELS = 5
>>>>>>>>>>      *      PAGE_OFFSET = 0xff60000000000000
>>>>>>>>>>      * Linux Kernel 5.17 ~
>>>>>>>>>>      *      PGTABLE_LEVELS = 4
>>>>>>>>>>      *      PAGE_OFFSET = 0xffffaf8000000000
>>>>>>>>>>      * Linux Kernel 4.19 ~
>>>>>>>>>>      *      PGTABLE_LEVELS = 3
>>>>>>>>>>      *      PAGE_OFFSET = 0xffffffe000000000
>>>>>>>>>>
>>>>>>>>>> Since these configurations change from time to time and
>>>>>>>>>> version to version,
>>>>>>>>>> it is preferable to export them via vmcoreinfo than to
>>>>>>>>>> change the crash's
>>>>>>>>>> code frequently, it can simplify the development of crash tool.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
>>>>>>>>>> ---
>>>>>>>>>>      arch/riscv/kernel/Makefile     |  1 +
>>>>>>>>>>      arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>>>>>>>>>>      2 files changed, 24 insertions(+)
>>>>>>>>>>      create mode 100644 arch/riscv/kernel/crash_core.c
>>>>>>>>>>
>>>>>>>>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
>>>>>>>>>> index db6e4b1294ba..4cf303a779ab 100644
>>>>>>>>>> --- a/arch/riscv/kernel/Makefile
>>>>>>>>>> +++ b/arch/riscv/kernel/Makefile
>>>>>>>>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
>>>>>>>>>>      obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o
>>>>>>>>>> crash_save_regs.o machine_kexec.o
>>>>>>>>>>      obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
>>>>>>>>>>      obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
>>>>>>>>>> +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
>>>>>>>>>>      obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
>>>>>>>>>> diff --git a/arch/riscv/kernel/crash_core.c
>>>>>>>>>> b/arch/riscv/kernel/crash_core.c
>>>>>>>>>> new file mode 100644
>>>>>>>>>> index 000000000000..3e889d0ed7bd
>>>>>>>>>> --- /dev/null
>>>>>>>>>> +++ b/arch/riscv/kernel/crash_core.c
>>>>>>>>>> @@ -0,0 +1,23 @@
>>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0-only
>>>>>>>>>> +
>>>>>>>>>> +#include <linux/crash_core.h>
>>>>>>>>>> +#include <linux/pagemap.h>
>>>>>>>>>> +
>>>>>>>>>> +void arch_crash_save_vmcoreinfo(void)
>>>>>>>>>> +{
>>>>>>>>>> +    VMCOREINFO_NUMBER(VA_BITS);
>>>>>>>>>> +    VMCOREINFO_NUMBER(phys_ram_base);
>>>>>>>>>> +
>>>>>>>>>> +
>>>>>>>>>> vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n",
>>>>>>>>>> PAGE_OFFSET);
>>>>>>>>>> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
>>>>>>>>>> VMALLOC_START);
>>>>>>>>>> +
>>>>>>>>>> vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n",
>>>>>>>>>> VMALLOC_END);
>>>>>>>>>> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n",
>>>>>>>>>> VMEMMAP_START);
>>>>>>>>>> +
>>>>>>>>>> vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n",
>>>>>>>>>> VMEMMAP_END);
>>>>>>>>>> +#ifdef CONFIG_64BIT
>>>>>>>>>> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n",
>>>>>>>>>> MODULES_VADDR);
>>>>>>>>>> +
>>>>>>>>>> vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n",
>>>>>>>>>> MODULES_END);
>>>>>>>>>> +#endif
>>>>>>>>>> +
>>>>>>>>>> +    if (IS_ENABLED(CONFIG_64BIT))
>>>>>>>>>> +
>>>>>>>>>> vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
>>>>>>>>>> KERNEL_LINK_ADDR);
>>>>>>>>> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
>>>>>>>>> ifdeffery scope, with that you can save one line of
>>>>>>>>> "IS_ENABLED(CONFIG_64BIT)".
>>>>>>>> I followed the rule in print_vm_layout() of
>>>>>>>> arch/riscv/mm/init.c, which used
>>>>>>>> IS_ENABLED when print the value of KERNEL_LINK_ADDR.
>>>>>>>>
>>>>>>> I see. There's PAGE_OFFSET in the middle. Thanks.
>>>>>>>
>>>>>>>            print_ml("lowmem", (unsigned long)PAGE_OFFSET,
>>>>>>>                    (unsigned long)high_memory)
>>>>>>>
>>>>>>> So now, do you think if it's necessary to have another
>>>>>>> IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
>>>>>> For which MACRO?  I think current code for PAGE_OFFSET is OK.
>>>>>>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

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

[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.

As for the difference between "#ifdef CONFIG_64BIT" and
"if (IS_ENABLED(CONFIG_64BIT))", I haven't got what's the Xianting's
point. Below is the IS_ENABLED definition in include/linux/kconfig.h,
it's truly different than #ifdef, while the change we are discussing
here is not related.

/*
 * IS_ENABLED(CONFIG_FOO) evaluates to 1 if CONFIG_FOO is set to 'y' or 'm',
 * 0 otherwise.  Note that CONFIG_FOO=y results in "#define CONFIG_FOO 1" in
 * autoconf.h, while CONFIG_FOO=m results in "#define CONFIG_FOO_MODULE 1".
 */
#define IS_ENABLED(option) __or(IS_BUILTIN(option), IS_MODULE(option))

> 
> > 
> > +void arch_crash_save_vmcoreinfo(void)
> > +{
> > +       VMCOREINFO_NUMBER(VA_BITS);
> > +       VMCOREINFO_NUMBER(phys_ram_base);
> > +
> > +       vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
> > +       vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
> > +       vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
> > +       vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
> > +       vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
> > +#ifdef CONFIG_64BIT
> > +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
> > +       vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
> > +       vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
> > +#endif
> > +}
> > 
> > > 
> > > Maybe we can remove IS_ENABLED(CONFIG_64BIT)
> > > 
> > > arch/riscv/include/asm/pgtable.h
> > > #define ADDRESS_SPACE_END       (UL(-1))
> > > #ifdef CONFIG_64BIT
> > > /* Leave 2GB for kernel and BPF at the end of the address space */
> > > #define KERNEL_LINK_ADDR        (ADDRESS_SPACE_END - SZ_2G + 1)
> > > #else
> > > #define KERNEL_LINK_ADDR        PAGE_OFFSET
> > > #endif
> > > 
> > > arch/riscv/include/asm/page.h
> > > #ifdef CONFIG_64BIT
> > > #ifdef CONFIG_MMU
> > > #define PAGE_OFFSET             kernel_map.page_offset
> > > #else
> > > #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
> > > #endif
> > > /*
> > >  * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address space so
> > >  * define the PAGE_OFFSET value for SV39.
> > >  */
> > > #define PAGE_OFFSET_L4          _AC(0xffffaf8000000000, UL)
> > > #define PAGE_OFFSET_L3          _AC(0xffffffd800000000, UL)
> > > #else
> > > #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
> > > #endif /* CONFIG_64BIT */
> > > 
> > > > 
> > > > Thanks,
> > > > Conor.
> > > > 
> > > > > 在 2022/10/20 下午12:40, Xianting Tian 写道:
> > > > > > 在 2022/10/20 上午11:05, Baoquan He 写道:
> > > > > > > On 10/20/22 at 10:17am, Xianting Tian wrote:
> > > > > > > > 在 2022/10/20 上午10:08, Baoquan He 写道:
> > > > > > > > > On 10/19/22 at 06:36pm, Xianting Tian wrote:
> > > > > > > > > > Add arch_crash_save_vmcoreinfo(), which exports VM
> > > > > > > > > > layout(MODULES, VMALLOC,
> > > > > > > > > > VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram
> > > > > > > > > > base for vmcore.
> > > > > > > > > > 
> > > > > > > > > > Default pagetable levels and PAGE_OFFSET aren't same for
> > > > > > > > > > different kernel
> > > > > > > > > > version as below. For pagetable levels, it sets sv57 by
> > > > > > > > > > default and falls
> > > > > > > > > > back to setting sv48 at boot time if sv57 is not
> > > > > > > > > > supported by the hardware.
> > > > > > > > > > 
> > > > > > > > > > For ram base, the default value is 0x80200000 for qemu
> > > > > > > > > > riscv64 env and,
> > > > > > > > > > for example, is 0x200000 on the XuanTie 910 CPU.
> > > > > > > > > > 
> > > > > > > > > >     * Linux Kernel 5.18 ~
> > > > > > > > > >     *      PGTABLE_LEVELS = 5
> > > > > > > > > >     *      PAGE_OFFSET = 0xff60000000000000
> > > > > > > > > >     * Linux Kernel 5.17 ~
> > > > > > > > > >     *      PGTABLE_LEVELS = 4
> > > > > > > > > >     *      PAGE_OFFSET = 0xffffaf8000000000
> > > > > > > > > >     * Linux Kernel 4.19 ~
> > > > > > > > > >     *      PGTABLE_LEVELS = 3
> > > > > > > > > >     *      PAGE_OFFSET = 0xffffffe000000000
> > > > > > > > > > 
> > > > > > > > > > Since these configurations change from time to time and
> > > > > > > > > > version to version,
> > > > > > > > > > it is preferable to export them via vmcoreinfo than to
> > > > > > > > > > change the crash's
> > > > > > > > > > code frequently, it can simplify the development of crash tool.
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> > > > > > > > > > ---
> > > > > > > > > >     arch/riscv/kernel/Makefile     |  1 +
> > > > > > > > > >     arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
> > > > > > > > > >     2 files changed, 24 insertions(+)
> > > > > > > > > >     create mode 100644 arch/riscv/kernel/crash_core.c
> > > > > > > > > > 
> > > > > > > > > > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> > > > > > > > > > index db6e4b1294ba..4cf303a779ab 100644
> > > > > > > > > > --- a/arch/riscv/kernel/Makefile
> > > > > > > > > > +++ b/arch/riscv/kernel/Makefile
> > > > > > > > > > @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
> > > > > > > > > >     obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o
> > > > > > > > > > crash_save_regs.o machine_kexec.o
> > > > > > > > > >     obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
> > > > > > > > > >     obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
> > > > > > > > > > +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
> > > > > > > > > >     obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
> > > > > > > > > > diff --git a/arch/riscv/kernel/crash_core.c
> > > > > > > > > > b/arch/riscv/kernel/crash_core.c
> > > > > > > > > > new file mode 100644
> > > > > > > > > > index 000000000000..3e889d0ed7bd
> > > > > > > > > > --- /dev/null
> > > > > > > > > > +++ b/arch/riscv/kernel/crash_core.c
> > > > > > > > > > @@ -0,0 +1,23 @@
> > > > > > > > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > > > > > > > +
> > > > > > > > > > +#include <linux/crash_core.h>
> > > > > > > > > > +#include <linux/pagemap.h>
> > > > > > > > > > +
> > > > > > > > > > +void arch_crash_save_vmcoreinfo(void)
> > > > > > > > > > +{
> > > > > > > > > > +    VMCOREINFO_NUMBER(VA_BITS);
> > > > > > > > > > +    VMCOREINFO_NUMBER(phys_ram_base);
> > > > > > > > > > +
> > > > > > > > > > +
> > > > > > > > > > vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n",
> > > > > > > > > > PAGE_OFFSET);
> > > > > > > > > > + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
> > > > > > > > > > VMALLOC_START);
> > > > > > > > > > +
> > > > > > > > > > vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n",
> > > > > > > > > > VMALLOC_END);
> > > > > > > > > > + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n",
> > > > > > > > > > VMEMMAP_START);
> > > > > > > > > > +
> > > > > > > > > > vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n",
> > > > > > > > > > VMEMMAP_END);
> > > > > > > > > > +#ifdef CONFIG_64BIT
> > > > > > > > > > + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n",
> > > > > > > > > > MODULES_VADDR);
> > > > > > > > > > +
> > > > > > > > > > vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n",
> > > > > > > > > > MODULES_END);
> > > > > > > > > > +#endif
> > > > > > > > > > +
> > > > > > > > > > +    if (IS_ENABLED(CONFIG_64BIT))
> > > > > > > > > > +
> > > > > > > > > > vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
> > > > > > > > > > KERNEL_LINK_ADDR);
> > > > > > > > > Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
> > > > > > > > > ifdeffery scope, with that you can save one line of
> > > > > > > > > "IS_ENABLED(CONFIG_64BIT)".
> > > > > > > > I followed the rule in print_vm_layout() of
> > > > > > > > arch/riscv/mm/init.c, which used
> > > > > > > > IS_ENABLED when print the value of KERNEL_LINK_ADDR.
> > > > > > > > 
> > > > > > > I see. There's PAGE_OFFSET in the middle. Thanks.
> > > > > > > 
> > > > > > >           print_ml("lowmem", (unsigned long)PAGE_OFFSET,
> > > > > > >                   (unsigned long)high_memory)
> > > > > > > 
> > > > > > > So now, do you think if it's necessary to have another
> > > > > > > IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
> > > > > > For which MACRO?  I think current code for PAGE_OFFSET is OK.
> > > > > > 
> > > 
> > 
> 


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[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.

As for the difference between "#ifdef CONFIG_64BIT" and
"if (IS_ENABLED(CONFIG_64BIT))", I haven't got what's the Xianting's
point. Below is the IS_ENABLED definition in include/linux/kconfig.h,
it's truly different than #ifdef, while the change we are discussing
here is not related.

/*
 * IS_ENABLED(CONFIG_FOO) evaluates to 1 if CONFIG_FOO is set to 'y' or 'm',
 * 0 otherwise.  Note that CONFIG_FOO=y results in "#define CONFIG_FOO 1" in
 * autoconf.h, while CONFIG_FOO=m results in "#define CONFIG_FOO_MODULE 1".
 */
#define IS_ENABLED(option) __or(IS_BUILTIN(option), IS_MODULE(option))

> 
> > 
> > +void arch_crash_save_vmcoreinfo(void)
> > +{
> > +       VMCOREINFO_NUMBER(VA_BITS);
> > +       VMCOREINFO_NUMBER(phys_ram_base);
> > +
> > +       vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
> > +       vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
> > +       vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
> > +       vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
> > +       vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
> > +#ifdef CONFIG_64BIT
> > +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
> > +       vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
> > +       vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
> > +#endif
> > +}
> > 
> > > 
> > > Maybe we can remove IS_ENABLED(CONFIG_64BIT)
> > > 
> > > arch/riscv/include/asm/pgtable.h
> > > #define ADDRESS_SPACE_END       (UL(-1))
> > > #ifdef CONFIG_64BIT
> > > /* Leave 2GB for kernel and BPF at the end of the address space */
> > > #define KERNEL_LINK_ADDR        (ADDRESS_SPACE_END - SZ_2G + 1)
> > > #else
> > > #define KERNEL_LINK_ADDR        PAGE_OFFSET
> > > #endif
> > > 
> > > arch/riscv/include/asm/page.h
> > > #ifdef CONFIG_64BIT
> > > #ifdef CONFIG_MMU
> > > #define PAGE_OFFSET             kernel_map.page_offset
> > > #else
> > > #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
> > > #endif
> > > /*
> > >  * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address space so
> > >  * define the PAGE_OFFSET value for SV39.
> > >  */
> > > #define PAGE_OFFSET_L4          _AC(0xffffaf8000000000, UL)
> > > #define PAGE_OFFSET_L3          _AC(0xffffffd800000000, UL)
> > > #else
> > > #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
> > > #endif /* CONFIG_64BIT */
> > > 
> > > > 
> > > > Thanks,
> > > > Conor.
> > > > 
> > > > > 在 2022/10/20 下午12:40, Xianting Tian 写道:
> > > > > > 在 2022/10/20 上午11:05, Baoquan He 写道:
> > > > > > > On 10/20/22 at 10:17am, Xianting Tian wrote:
> > > > > > > > 在 2022/10/20 上午10:08, Baoquan He 写道:
> > > > > > > > > On 10/19/22 at 06:36pm, Xianting Tian wrote:
> > > > > > > > > > Add arch_crash_save_vmcoreinfo(), which exports VM
> > > > > > > > > > layout(MODULES, VMALLOC,
> > > > > > > > > > VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram
> > > > > > > > > > base for vmcore.
> > > > > > > > > > 
> > > > > > > > > > Default pagetable levels and PAGE_OFFSET aren't same for
> > > > > > > > > > different kernel
> > > > > > > > > > version as below. For pagetable levels, it sets sv57 by
> > > > > > > > > > default and falls
> > > > > > > > > > back to setting sv48 at boot time if sv57 is not
> > > > > > > > > > supported by the hardware.
> > > > > > > > > > 
> > > > > > > > > > For ram base, the default value is 0x80200000 for qemu
> > > > > > > > > > riscv64 env and,
> > > > > > > > > > for example, is 0x200000 on the XuanTie 910 CPU.
> > > > > > > > > > 
> > > > > > > > > >     * Linux Kernel 5.18 ~
> > > > > > > > > >     *      PGTABLE_LEVELS = 5
> > > > > > > > > >     *      PAGE_OFFSET = 0xff60000000000000
> > > > > > > > > >     * Linux Kernel 5.17 ~
> > > > > > > > > >     *      PGTABLE_LEVELS = 4
> > > > > > > > > >     *      PAGE_OFFSET = 0xffffaf8000000000
> > > > > > > > > >     * Linux Kernel 4.19 ~
> > > > > > > > > >     *      PGTABLE_LEVELS = 3
> > > > > > > > > >     *      PAGE_OFFSET = 0xffffffe000000000
> > > > > > > > > > 
> > > > > > > > > > Since these configurations change from time to time and
> > > > > > > > > > version to version,
> > > > > > > > > > it is preferable to export them via vmcoreinfo than to
> > > > > > > > > > change the crash's
> > > > > > > > > > code frequently, it can simplify the development of crash tool.
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> > > > > > > > > > ---
> > > > > > > > > >     arch/riscv/kernel/Makefile     |  1 +
> > > > > > > > > >     arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
> > > > > > > > > >     2 files changed, 24 insertions(+)
> > > > > > > > > >     create mode 100644 arch/riscv/kernel/crash_core.c
> > > > > > > > > > 
> > > > > > > > > > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> > > > > > > > > > index db6e4b1294ba..4cf303a779ab 100644
> > > > > > > > > > --- a/arch/riscv/kernel/Makefile
> > > > > > > > > > +++ b/arch/riscv/kernel/Makefile
> > > > > > > > > > @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
> > > > > > > > > >     obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o
> > > > > > > > > > crash_save_regs.o machine_kexec.o
> > > > > > > > > >     obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
> > > > > > > > > >     obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
> > > > > > > > > > +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
> > > > > > > > > >     obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
> > > > > > > > > > diff --git a/arch/riscv/kernel/crash_core.c
> > > > > > > > > > b/arch/riscv/kernel/crash_core.c
> > > > > > > > > > new file mode 100644
> > > > > > > > > > index 000000000000..3e889d0ed7bd
> > > > > > > > > > --- /dev/null
> > > > > > > > > > +++ b/arch/riscv/kernel/crash_core.c
> > > > > > > > > > @@ -0,0 +1,23 @@
> > > > > > > > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > > > > > > > +
> > > > > > > > > > +#include <linux/crash_core.h>
> > > > > > > > > > +#include <linux/pagemap.h>
> > > > > > > > > > +
> > > > > > > > > > +void arch_crash_save_vmcoreinfo(void)
> > > > > > > > > > +{
> > > > > > > > > > +    VMCOREINFO_NUMBER(VA_BITS);
> > > > > > > > > > +    VMCOREINFO_NUMBER(phys_ram_base);
> > > > > > > > > > +
> > > > > > > > > > +
> > > > > > > > > > vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n",
> > > > > > > > > > PAGE_OFFSET);
> > > > > > > > > > + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
> > > > > > > > > > VMALLOC_START);
> > > > > > > > > > +
> > > > > > > > > > vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n",
> > > > > > > > > > VMALLOC_END);
> > > > > > > > > > + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n",
> > > > > > > > > > VMEMMAP_START);
> > > > > > > > > > +
> > > > > > > > > > vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n",
> > > > > > > > > > VMEMMAP_END);
> > > > > > > > > > +#ifdef CONFIG_64BIT
> > > > > > > > > > + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n",
> > > > > > > > > > MODULES_VADDR);
> > > > > > > > > > +
> > > > > > > > > > vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n",
> > > > > > > > > > MODULES_END);
> > > > > > > > > > +#endif
> > > > > > > > > > +
> > > > > > > > > > +    if (IS_ENABLED(CONFIG_64BIT))
> > > > > > > > > > +
> > > > > > > > > > vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
> > > > > > > > > > KERNEL_LINK_ADDR);
> > > > > > > > > Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
> > > > > > > > > ifdeffery scope, with that you can save one line of
> > > > > > > > > "IS_ENABLED(CONFIG_64BIT)".
> > > > > > > > I followed the rule in print_vm_layout() of
> > > > > > > > arch/riscv/mm/init.c, which used
> > > > > > > > IS_ENABLED when print the value of KERNEL_LINK_ADDR.
> > > > > > > > 
> > > > > > > I see. There's PAGE_OFFSET in the middle. Thanks.
> > > > > > > 
> > > > > > >           print_ml("lowmem", (unsigned long)PAGE_OFFSET,
> > > > > > >                   (unsigned long)high_memory)
> > > > > > > 
> > > > > > > So now, do you think if it's necessary to have another
> > > > > > > IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
> > > > > > For which MACRO?  I think current code for PAGE_OFFSET is OK.
> > > > > > 
> > > 
> > 
> 


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

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

[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.

As for the difference between "#ifdef CONFIG_64BIT" and
"if (IS_ENABLED(CONFIG_64BIT))", I haven't got what's the Xianting's
point. Below is the IS_ENABLED definition in include/linux/kconfig.h,
it's truly different than #ifdef, while the change we are discussing
here is not related.

/*
 * IS_ENABLED(CONFIG_FOO) evaluates to 1 if CONFIG_FOO is set to 'y' or 'm',
 * 0 otherwise.  Note that CONFIG_FOO=y results in "#define CONFIG_FOO 1" in
 * autoconf.h, while CONFIG_FOO=m results in "#define CONFIG_FOO_MODULE 1".
 */
#define IS_ENABLED(option) __or(IS_BUILTIN(option), IS_MODULE(option))

> 
> > 
> > +void arch_crash_save_vmcoreinfo(void)
> > +{
> > +       VMCOREINFO_NUMBER(VA_BITS);
> > +       VMCOREINFO_NUMBER(phys_ram_base);
> > +
> > +       vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
> > +       vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
> > +       vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
> > +       vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
> > +       vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
> > +#ifdef CONFIG_64BIT
> > +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
> > +       vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
> > +       vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
> > +#endif
> > +}
> > 
> > > 
> > > Maybe we can remove IS_ENABLED(CONFIG_64BIT)
> > > 
> > > arch/riscv/include/asm/pgtable.h
> > > #define ADDRESS_SPACE_END       (UL(-1))
> > > #ifdef CONFIG_64BIT
> > > /* Leave 2GB for kernel and BPF at the end of the address space */
> > > #define KERNEL_LINK_ADDR        (ADDRESS_SPACE_END - SZ_2G + 1)
> > > #else
> > > #define KERNEL_LINK_ADDR        PAGE_OFFSET
> > > #endif
> > > 
> > > arch/riscv/include/asm/page.h
> > > #ifdef CONFIG_64BIT
> > > #ifdef CONFIG_MMU
> > > #define PAGE_OFFSET             kernel_map.page_offset
> > > #else
> > > #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
> > > #endif
> > > /*
> > >  * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address space so
> > >  * define the PAGE_OFFSET value for SV39.
> > >  */
> > > #define PAGE_OFFSET_L4          _AC(0xffffaf8000000000, UL)
> > > #define PAGE_OFFSET_L3          _AC(0xffffffd800000000, UL)
> > > #else
> > > #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
> > > #endif /* CONFIG_64BIT */
> > > 
> > > > 
> > > > Thanks,
> > > > Conor.
> > > > 
> > > > > 在 2022/10/20 下午12:40, Xianting Tian 写道:
> > > > > > 在 2022/10/20 上午11:05, Baoquan He 写道:
> > > > > > > On 10/20/22 at 10:17am, Xianting Tian wrote:
> > > > > > > > 在 2022/10/20 上午10:08, Baoquan He 写道:
> > > > > > > > > On 10/19/22 at 06:36pm, Xianting Tian wrote:
> > > > > > > > > > Add arch_crash_save_vmcoreinfo(), which exports VM
> > > > > > > > > > layout(MODULES, VMALLOC,
> > > > > > > > > > VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram
> > > > > > > > > > base for vmcore.
> > > > > > > > > > 
> > > > > > > > > > Default pagetable levels and PAGE_OFFSET aren't same for
> > > > > > > > > > different kernel
> > > > > > > > > > version as below. For pagetable levels, it sets sv57 by
> > > > > > > > > > default and falls
> > > > > > > > > > back to setting sv48 at boot time if sv57 is not
> > > > > > > > > > supported by the hardware.
> > > > > > > > > > 
> > > > > > > > > > For ram base, the default value is 0x80200000 for qemu
> > > > > > > > > > riscv64 env and,
> > > > > > > > > > for example, is 0x200000 on the XuanTie 910 CPU.
> > > > > > > > > > 
> > > > > > > > > >     * Linux Kernel 5.18 ~
> > > > > > > > > >     *      PGTABLE_LEVELS = 5
> > > > > > > > > >     *      PAGE_OFFSET = 0xff60000000000000
> > > > > > > > > >     * Linux Kernel 5.17 ~
> > > > > > > > > >     *      PGTABLE_LEVELS = 4
> > > > > > > > > >     *      PAGE_OFFSET = 0xffffaf8000000000
> > > > > > > > > >     * Linux Kernel 4.19 ~
> > > > > > > > > >     *      PGTABLE_LEVELS = 3
> > > > > > > > > >     *      PAGE_OFFSET = 0xffffffe000000000
> > > > > > > > > > 
> > > > > > > > > > Since these configurations change from time to time and
> > > > > > > > > > version to version,
> > > > > > > > > > it is preferable to export them via vmcoreinfo than to
> > > > > > > > > > change the crash's
> > > > > > > > > > code frequently, it can simplify the development of crash tool.
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> > > > > > > > > > ---
> > > > > > > > > >     arch/riscv/kernel/Makefile     |  1 +
> > > > > > > > > >     arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
> > > > > > > > > >     2 files changed, 24 insertions(+)
> > > > > > > > > >     create mode 100644 arch/riscv/kernel/crash_core.c
> > > > > > > > > > 
> > > > > > > > > > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> > > > > > > > > > index db6e4b1294ba..4cf303a779ab 100644
> > > > > > > > > > --- a/arch/riscv/kernel/Makefile
> > > > > > > > > > +++ b/arch/riscv/kernel/Makefile
> > > > > > > > > > @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
> > > > > > > > > >     obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o
> > > > > > > > > > crash_save_regs.o machine_kexec.o
> > > > > > > > > >     obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
> > > > > > > > > >     obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
> > > > > > > > > > +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
> > > > > > > > > >     obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
> > > > > > > > > > diff --git a/arch/riscv/kernel/crash_core.c
> > > > > > > > > > b/arch/riscv/kernel/crash_core.c
> > > > > > > > > > new file mode 100644
> > > > > > > > > > index 000000000000..3e889d0ed7bd
> > > > > > > > > > --- /dev/null
> > > > > > > > > > +++ b/arch/riscv/kernel/crash_core.c
> > > > > > > > > > @@ -0,0 +1,23 @@
> > > > > > > > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > > > > > > > +
> > > > > > > > > > +#include <linux/crash_core.h>
> > > > > > > > > > +#include <linux/pagemap.h>
> > > > > > > > > > +
> > > > > > > > > > +void arch_crash_save_vmcoreinfo(void)
> > > > > > > > > > +{
> > > > > > > > > > +    VMCOREINFO_NUMBER(VA_BITS);
> > > > > > > > > > +    VMCOREINFO_NUMBER(phys_ram_base);
> > > > > > > > > > +
> > > > > > > > > > +
> > > > > > > > > > vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n",
> > > > > > > > > > PAGE_OFFSET);
> > > > > > > > > > + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
> > > > > > > > > > VMALLOC_START);
> > > > > > > > > > +
> > > > > > > > > > vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n",
> > > > > > > > > > VMALLOC_END);
> > > > > > > > > > + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n",
> > > > > > > > > > VMEMMAP_START);
> > > > > > > > > > +
> > > > > > > > > > vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n",
> > > > > > > > > > VMEMMAP_END);
> > > > > > > > > > +#ifdef CONFIG_64BIT
> > > > > > > > > > + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n",
> > > > > > > > > > MODULES_VADDR);
> > > > > > > > > > +
> > > > > > > > > > vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n",
> > > > > > > > > > MODULES_END);
> > > > > > > > > > +#endif
> > > > > > > > > > +
> > > > > > > > > > +    if (IS_ENABLED(CONFIG_64BIT))
> > > > > > > > > > +
> > > > > > > > > > vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
> > > > > > > > > > KERNEL_LINK_ADDR);
> > > > > > > > > Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
> > > > > > > > > ifdeffery scope, with that you can save one line of
> > > > > > > > > "IS_ENABLED(CONFIG_64BIT)".
> > > > > > > > I followed the rule in print_vm_layout() of
> > > > > > > > arch/riscv/mm/init.c, which used
> > > > > > > > IS_ENABLED when print the value of KERNEL_LINK_ADDR.
> > > > > > > > 
> > > > > > > I see. There's PAGE_OFFSET in the middle. Thanks.
> > > > > > > 
> > > > > > >           print_ml("lowmem", (unsigned long)PAGE_OFFSET,
> > > > > > >                   (unsigned long)high_memory)
> > > > > > > 
> > > > > > > So now, do you think if it's necessary to have another
> > > > > > > IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
> > > > > > For which MACRO?  I think current code for PAGE_OFFSET is OK.
> > > > > > 
> > > 
> > 
> 

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

[Xianting Tian]

在 2022/10/31 下午4:57, Baoquan He 写道:
> On 10/26/22 at 02:47pm, Conor Dooley wrote:
>> On Wed, Oct 26, 2022 at 08:05:41PM +0800, Baoquan He wrote:
>>> Hi Xianting,
>>>
>>> On 10/26/22 at 05:44pm, Xianting Tian wrote:
>>>> 在 2022/10/26 下午5:25, Conor Dooley 写道:
>>>>> On Wed, Oct 26, 2022 at 05:08:11PM +0800, Xianting Tian wrote:
>>>>>> Hi Palmer, Conor
>>>>>>
>>>>>> Is this version OK for you?
>>>>> The weird ifdef/IS_ENABLED thing was the only comment I had. It's a bit
>>>>> odd & I notice Baoquan brought it up too. I didn't (and won't) give you
>>>>> a reviewed by on these patches because I don't understand the area well
>>>>> enough. The general nitpickery seems to be sorted though.
>>>> I checked the KERNEL_LINK_ADDR definition of riscv,  it is valid for
>>>> CONFIG_64BIT and !CONFIG_64BIT.
>>> This series looks good to me. My only minor concern is if we can make
>>> the arch_crash_save_vmcoreinfo() as below. I don't understand why we
>>> have to have the CONFIG_64BIT ifdeffery and the IS_ENABLED(CONFIG_64BIT)
>>> between two adjacent code blocks. Not sure if we are saying the same
>>> thing.
>> I think we can just go and drop the IS_ENABLED(). From looking at it
>> last time, one bit is compileable (but not usable) for !64BIT and the
>> other isn't hence the IS_ENABLED(). I think it would make sense to drop
>> the IS_ENABLED() - I don't think we're too likely to hit some compile
>> testing edge cases that IS_ENABLED() would help with & only having one
>> makes the code look a lot less odd and a lot more intentional.
> I check risc-v code again, and agree we can drop the IS_ENABLED checking
> to export KERNEL_LINK_ADDR anyway. We can surely deduce
> KERNEL_LINK_ADDR in userspace e.g makedumpfile/Crash, while it seems no
> harm to get it from the vmcoreinfo directly.

thanks Baoquan for the confirm,

please help give the Revied-by and promote the patch set to be applied 
to Linux 6.1 :)

>
> As for the difference between "#ifdef CONFIG_64BIT" and
> "if (IS_ENABLED(CONFIG_64BIT))", I haven't got what's the Xianting's
> point. Below is the IS_ENABLED definition in include/linux/kconfig.h,
> it's truly different than #ifdef, while the change we are discussing
> here is not related.
>
> /*
>   * IS_ENABLED(CONFIG_FOO) evaluates to 1 if CONFIG_FOO is set to 'y' or 'm',
>   * 0 otherwise.  Note that CONFIG_FOO=y results in "#define CONFIG_FOO 1" in
>   * autoconf.h, while CONFIG_FOO=m results in "#define CONFIG_FOO_MODULE 1".
>   */
> #define IS_ENABLED(option) __or(IS_BUILTIN(option), IS_MODULE(option))
>
>>> +void arch_crash_save_vmcoreinfo(void)
>>> +{
>>> +       VMCOREINFO_NUMBER(VA_BITS);
>>> +       VMCOREINFO_NUMBER(phys_ram_base);
>>> +
>>> +       vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
>>> +       vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
>>> +       vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
>>> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
>>> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
>>> +#ifdef CONFIG_64BIT
>>> +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
>>> +       vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
>>> +       vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
>>> +#endif
>>> +}
>>>
>>>> Maybe we can remove IS_ENABLED(CONFIG_64BIT)
>>>>
>>>> arch/riscv/include/asm/pgtable.h
>>>> #define ADDRESS_SPACE_END       (UL(-1))
>>>> #ifdef CONFIG_64BIT
>>>> /* Leave 2GB for kernel and BPF at the end of the address space */
>>>> #define KERNEL_LINK_ADDR        (ADDRESS_SPACE_END - SZ_2G + 1)
>>>> #else
>>>> #define KERNEL_LINK_ADDR        PAGE_OFFSET
>>>> #endif
>>>>
>>>> arch/riscv/include/asm/page.h
>>>> #ifdef CONFIG_64BIT
>>>> #ifdef CONFIG_MMU
>>>> #define PAGE_OFFSET             kernel_map.page_offset
>>>> #else
>>>> #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
>>>> #endif
>>>> /*
>>>>   * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address space so
>>>>   * define the PAGE_OFFSET value for SV39.
>>>>   */
>>>> #define PAGE_OFFSET_L4          _AC(0xffffaf8000000000, UL)
>>>> #define PAGE_OFFSET_L3          _AC(0xffffffd800000000, UL)
>>>> #else
>>>> #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
>>>> #endif /* CONFIG_64BIT */
>>>>
>>>>> Thanks,
>>>>> Conor.
>>>>>
>>>>>> 在 2022/10/20 下午12:40, Xianting Tian 写道:
>>>>>>> 在 2022/10/20 上午11:05, Baoquan He 写道:
>>>>>>>> On 10/20/22 at 10:17am, Xianting Tian wrote:
>>>>>>>>> 在 2022/10/20 上午10:08, Baoquan He 写道:
>>>>>>>>>> On 10/19/22 at 06:36pm, Xianting Tian wrote:
>>>>>>>>>>> Add arch_crash_save_vmcoreinfo(), which exports VM
>>>>>>>>>>> layout(MODULES, VMALLOC,
>>>>>>>>>>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram
>>>>>>>>>>> base for vmcore.
>>>>>>>>>>>
>>>>>>>>>>> Default pagetable levels and PAGE_OFFSET aren't same for
>>>>>>>>>>> different kernel
>>>>>>>>>>> version as below. For pagetable levels, it sets sv57 by
>>>>>>>>>>> default and falls
>>>>>>>>>>> back to setting sv48 at boot time if sv57 is not
>>>>>>>>>>> supported by the hardware.
>>>>>>>>>>>
>>>>>>>>>>> For ram base, the default value is 0x80200000 for qemu
>>>>>>>>>>> riscv64 env and,
>>>>>>>>>>> for example, is 0x200000 on the XuanTie 910 CPU.
>>>>>>>>>>>
>>>>>>>>>>>      * Linux Kernel 5.18 ~
>>>>>>>>>>>      *      PGTABLE_LEVELS = 5
>>>>>>>>>>>      *      PAGE_OFFSET = 0xff60000000000000
>>>>>>>>>>>      * Linux Kernel 5.17 ~
>>>>>>>>>>>      *      PGTABLE_LEVELS = 4
>>>>>>>>>>>      *      PAGE_OFFSET = 0xffffaf8000000000
>>>>>>>>>>>      * Linux Kernel 4.19 ~
>>>>>>>>>>>      *      PGTABLE_LEVELS = 3
>>>>>>>>>>>      *      PAGE_OFFSET = 0xffffffe000000000
>>>>>>>>>>>
>>>>>>>>>>> Since these configurations change from time to time and
>>>>>>>>>>> version to version,
>>>>>>>>>>> it is preferable to export them via vmcoreinfo than to
>>>>>>>>>>> change the crash's
>>>>>>>>>>> code frequently, it can simplify the development of crash tool.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
>>>>>>>>>>> ---
>>>>>>>>>>>      arch/riscv/kernel/Makefile     |  1 +
>>>>>>>>>>>      arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>>>>>>>>>>>      2 files changed, 24 insertions(+)
>>>>>>>>>>>      create mode 100644 arch/riscv/kernel/crash_core.c
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
>>>>>>>>>>> index db6e4b1294ba..4cf303a779ab 100644
>>>>>>>>>>> --- a/arch/riscv/kernel/Makefile
>>>>>>>>>>> +++ b/arch/riscv/kernel/Makefile
>>>>>>>>>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
>>>>>>>>>>>      obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o
>>>>>>>>>>> crash_save_regs.o machine_kexec.o
>>>>>>>>>>>      obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
>>>>>>>>>>>      obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
>>>>>>>>>>> +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
>>>>>>>>>>>      obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
>>>>>>>>>>> diff --git a/arch/riscv/kernel/crash_core.c
>>>>>>>>>>> b/arch/riscv/kernel/crash_core.c
>>>>>>>>>>> new file mode 100644
>>>>>>>>>>> index 000000000000..3e889d0ed7bd
>>>>>>>>>>> --- /dev/null
>>>>>>>>>>> +++ b/arch/riscv/kernel/crash_core.c
>>>>>>>>>>> @@ -0,0 +1,23 @@
>>>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0-only
>>>>>>>>>>> +
>>>>>>>>>>> +#include <linux/crash_core.h>
>>>>>>>>>>> +#include <linux/pagemap.h>
>>>>>>>>>>> +
>>>>>>>>>>> +void arch_crash_save_vmcoreinfo(void)
>>>>>>>>>>> +{
>>>>>>>>>>> +    VMCOREINFO_NUMBER(VA_BITS);
>>>>>>>>>>> +    VMCOREINFO_NUMBER(phys_ram_base);
>>>>>>>>>>> +
>>>>>>>>>>> +
>>>>>>>>>>> vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n",
>>>>>>>>>>> PAGE_OFFSET);
>>>>>>>>>>> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
>>>>>>>>>>> VMALLOC_START);
>>>>>>>>>>> +
>>>>>>>>>>> vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n",
>>>>>>>>>>> VMALLOC_END);
>>>>>>>>>>> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n",
>>>>>>>>>>> VMEMMAP_START);
>>>>>>>>>>> +
>>>>>>>>>>> vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n",
>>>>>>>>>>> VMEMMAP_END);
>>>>>>>>>>> +#ifdef CONFIG_64BIT
>>>>>>>>>>> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n",
>>>>>>>>>>> MODULES_VADDR);
>>>>>>>>>>> +
>>>>>>>>>>> vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n",
>>>>>>>>>>> MODULES_END);
>>>>>>>>>>> +#endif
>>>>>>>>>>> +
>>>>>>>>>>> +    if (IS_ENABLED(CONFIG_64BIT))
>>>>>>>>>>> +
>>>>>>>>>>> vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
>>>>>>>>>>> KERNEL_LINK_ADDR);
>>>>>>>>>> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
>>>>>>>>>> ifdeffery scope, with that you can save one line of
>>>>>>>>>> "IS_ENABLED(CONFIG_64BIT)".
>>>>>>>>> I followed the rule in print_vm_layout() of
>>>>>>>>> arch/riscv/mm/init.c, which used
>>>>>>>>> IS_ENABLED when print the value of KERNEL_LINK_ADDR.
>>>>>>>>>
>>>>>>>> I see. There's PAGE_OFFSET in the middle. Thanks.
>>>>>>>>
>>>>>>>>            print_ml("lowmem", (unsigned long)PAGE_OFFSET,
>>>>>>>>                    (unsigned long)high_memory)
>>>>>>>>
>>>>>>>> So now, do you think if it's necessary to have another
>>>>>>>> IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
>>>>>>> For which MACRO?  I think current code for PAGE_OFFSET is OK.
>>>>>>>

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

[Xianting Tian]

在 2022/10/31 下午4:57, Baoquan He 写道:
> On 10/26/22 at 02:47pm, Conor Dooley wrote:
>> On Wed, Oct 26, 2022 at 08:05:41PM +0800, Baoquan He wrote:
>>> Hi Xianting,
>>>
>>> On 10/26/22 at 05:44pm, Xianting Tian wrote:
>>>> 在 2022/10/26 下午5:25, Conor Dooley 写道:
>>>>> On Wed, Oct 26, 2022 at 05:08:11PM +0800, Xianting Tian wrote:
>>>>>> Hi Palmer, Conor
>>>>>>
>>>>>> Is this version OK for you?
>>>>> The weird ifdef/IS_ENABLED thing was the only comment I had. It's a bit
>>>>> odd & I notice Baoquan brought it up too. I didn't (and won't) give you
>>>>> a reviewed by on these patches because I don't understand the area well
>>>>> enough. The general nitpickery seems to be sorted though.
>>>> I checked the KERNEL_LINK_ADDR definition of riscv,  it is valid for
>>>> CONFIG_64BIT and !CONFIG_64BIT.
>>> This series looks good to me. My only minor concern is if we can make
>>> the arch_crash_save_vmcoreinfo() as below. I don't understand why we
>>> have to have the CONFIG_64BIT ifdeffery and the IS_ENABLED(CONFIG_64BIT)
>>> between two adjacent code blocks. Not sure if we are saying the same
>>> thing.
>> I think we can just go and drop the IS_ENABLED(). From looking at it
>> last time, one bit is compileable (but not usable) for !64BIT and the
>> other isn't hence the IS_ENABLED(). I think it would make sense to drop
>> the IS_ENABLED() - I don't think we're too likely to hit some compile
>> testing edge cases that IS_ENABLED() would help with & only having one
>> makes the code look a lot less odd and a lot more intentional.
> I check risc-v code again, and agree we can drop the IS_ENABLED checking
> to export KERNEL_LINK_ADDR anyway. We can surely deduce
> KERNEL_LINK_ADDR in userspace e.g makedumpfile/Crash, while it seems no
> harm to get it from the vmcoreinfo directly.

thanks Baoquan for the confirm,

please help give the Revied-by and promote the patch set to be applied 
to Linux 6.1 :)

>
> As for the difference between "#ifdef CONFIG_64BIT" and
> "if (IS_ENABLED(CONFIG_64BIT))", I haven't got what's the Xianting's
> point. Below is the IS_ENABLED definition in include/linux/kconfig.h,
> it's truly different than #ifdef, while the change we are discussing
> here is not related.
>
> /*
>   * IS_ENABLED(CONFIG_FOO) evaluates to 1 if CONFIG_FOO is set to 'y' or 'm',
>   * 0 otherwise.  Note that CONFIG_FOO=y results in "#define CONFIG_FOO 1" in
>   * autoconf.h, while CONFIG_FOO=m results in "#define CONFIG_FOO_MODULE 1".
>   */
> #define IS_ENABLED(option) __or(IS_BUILTIN(option), IS_MODULE(option))
>
>>> +void arch_crash_save_vmcoreinfo(void)
>>> +{
>>> +       VMCOREINFO_NUMBER(VA_BITS);
>>> +       VMCOREINFO_NUMBER(phys_ram_base);
>>> +
>>> +       vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
>>> +       vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
>>> +       vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
>>> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
>>> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
>>> +#ifdef CONFIG_64BIT
>>> +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
>>> +       vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
>>> +       vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
>>> +#endif
>>> +}
>>>
>>>> Maybe we can remove IS_ENABLED(CONFIG_64BIT)
>>>>
>>>> arch/riscv/include/asm/pgtable.h
>>>> #define ADDRESS_SPACE_END       (UL(-1))
>>>> #ifdef CONFIG_64BIT
>>>> /* Leave 2GB for kernel and BPF at the end of the address space */
>>>> #define KERNEL_LINK_ADDR        (ADDRESS_SPACE_END - SZ_2G + 1)
>>>> #else
>>>> #define KERNEL_LINK_ADDR        PAGE_OFFSET
>>>> #endif
>>>>
>>>> arch/riscv/include/asm/page.h
>>>> #ifdef CONFIG_64BIT
>>>> #ifdef CONFIG_MMU
>>>> #define PAGE_OFFSET             kernel_map.page_offset
>>>> #else
>>>> #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
>>>> #endif
>>>> /*
>>>>   * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address space so
>>>>   * define the PAGE_OFFSET value for SV39.
>>>>   */
>>>> #define PAGE_OFFSET_L4          _AC(0xffffaf8000000000, UL)
>>>> #define PAGE_OFFSET_L3          _AC(0xffffffd800000000, UL)
>>>> #else
>>>> #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
>>>> #endif /* CONFIG_64BIT */
>>>>
>>>>> Thanks,
>>>>> Conor.
>>>>>
>>>>>> 在 2022/10/20 下午12:40, Xianting Tian 写道:
>>>>>>> 在 2022/10/20 上午11:05, Baoquan He 写道:
>>>>>>>> On 10/20/22 at 10:17am, Xianting Tian wrote:
>>>>>>>>> 在 2022/10/20 上午10:08, Baoquan He 写道:
>>>>>>>>>> On 10/19/22 at 06:36pm, Xianting Tian wrote:
>>>>>>>>>>> Add arch_crash_save_vmcoreinfo(), which exports VM
>>>>>>>>>>> layout(MODULES, VMALLOC,
>>>>>>>>>>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram
>>>>>>>>>>> base for vmcore.
>>>>>>>>>>>
>>>>>>>>>>> Default pagetable levels and PAGE_OFFSET aren't same for
>>>>>>>>>>> different kernel
>>>>>>>>>>> version as below. For pagetable levels, it sets sv57 by
>>>>>>>>>>> default and falls
>>>>>>>>>>> back to setting sv48 at boot time if sv57 is not
>>>>>>>>>>> supported by the hardware.
>>>>>>>>>>>
>>>>>>>>>>> For ram base, the default value is 0x80200000 for qemu
>>>>>>>>>>> riscv64 env and,
>>>>>>>>>>> for example, is 0x200000 on the XuanTie 910 CPU.
>>>>>>>>>>>
>>>>>>>>>>>      * Linux Kernel 5.18 ~
>>>>>>>>>>>      *      PGTABLE_LEVELS = 5
>>>>>>>>>>>      *      PAGE_OFFSET = 0xff60000000000000
>>>>>>>>>>>      * Linux Kernel 5.17 ~
>>>>>>>>>>>      *      PGTABLE_LEVELS = 4
>>>>>>>>>>>      *      PAGE_OFFSET = 0xffffaf8000000000
>>>>>>>>>>>      * Linux Kernel 4.19 ~
>>>>>>>>>>>      *      PGTABLE_LEVELS = 3
>>>>>>>>>>>      *      PAGE_OFFSET = 0xffffffe000000000
>>>>>>>>>>>
>>>>>>>>>>> Since these configurations change from time to time and
>>>>>>>>>>> version to version,
>>>>>>>>>>> it is preferable to export them via vmcoreinfo than to
>>>>>>>>>>> change the crash's
>>>>>>>>>>> code frequently, it can simplify the development of crash tool.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
>>>>>>>>>>> ---
>>>>>>>>>>>      arch/riscv/kernel/Makefile     |  1 +
>>>>>>>>>>>      arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>>>>>>>>>>>      2 files changed, 24 insertions(+)
>>>>>>>>>>>      create mode 100644 arch/riscv/kernel/crash_core.c
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
>>>>>>>>>>> index db6e4b1294ba..4cf303a779ab 100644
>>>>>>>>>>> --- a/arch/riscv/kernel/Makefile
>>>>>>>>>>> +++ b/arch/riscv/kernel/Makefile
>>>>>>>>>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
>>>>>>>>>>>      obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o
>>>>>>>>>>> crash_save_regs.o machine_kexec.o
>>>>>>>>>>>      obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
>>>>>>>>>>>      obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
>>>>>>>>>>> +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
>>>>>>>>>>>      obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
>>>>>>>>>>> diff --git a/arch/riscv/kernel/crash_core.c
>>>>>>>>>>> b/arch/riscv/kernel/crash_core.c
>>>>>>>>>>> new file mode 100644
>>>>>>>>>>> index 000000000000..3e889d0ed7bd
>>>>>>>>>>> --- /dev/null
>>>>>>>>>>> +++ b/arch/riscv/kernel/crash_core.c
>>>>>>>>>>> @@ -0,0 +1,23 @@
>>>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0-only
>>>>>>>>>>> +
>>>>>>>>>>> +#include <linux/crash_core.h>
>>>>>>>>>>> +#include <linux/pagemap.h>
>>>>>>>>>>> +
>>>>>>>>>>> +void arch_crash_save_vmcoreinfo(void)
>>>>>>>>>>> +{
>>>>>>>>>>> +    VMCOREINFO_NUMBER(VA_BITS);
>>>>>>>>>>> +    VMCOREINFO_NUMBER(phys_ram_base);
>>>>>>>>>>> +
>>>>>>>>>>> +
>>>>>>>>>>> vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n",
>>>>>>>>>>> PAGE_OFFSET);
>>>>>>>>>>> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
>>>>>>>>>>> VMALLOC_START);
>>>>>>>>>>> +
>>>>>>>>>>> vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n",
>>>>>>>>>>> VMALLOC_END);
>>>>>>>>>>> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n",
>>>>>>>>>>> VMEMMAP_START);
>>>>>>>>>>> +
>>>>>>>>>>> vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n",
>>>>>>>>>>> VMEMMAP_END);
>>>>>>>>>>> +#ifdef CONFIG_64BIT
>>>>>>>>>>> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n",
>>>>>>>>>>> MODULES_VADDR);
>>>>>>>>>>> +
>>>>>>>>>>> vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n",
>>>>>>>>>>> MODULES_END);
>>>>>>>>>>> +#endif
>>>>>>>>>>> +
>>>>>>>>>>> +    if (IS_ENABLED(CONFIG_64BIT))
>>>>>>>>>>> +
>>>>>>>>>>> vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
>>>>>>>>>>> KERNEL_LINK_ADDR);
>>>>>>>>>> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
>>>>>>>>>> ifdeffery scope, with that you can save one line of
>>>>>>>>>> "IS_ENABLED(CONFIG_64BIT)".
>>>>>>>>> I followed the rule in print_vm_layout() of
>>>>>>>>> arch/riscv/mm/init.c, which used
>>>>>>>>> IS_ENABLED when print the value of KERNEL_LINK_ADDR.
>>>>>>>>>
>>>>>>>> I see. There's PAGE_OFFSET in the middle. Thanks.
>>>>>>>>
>>>>>>>>            print_ml("lowmem", (unsigned long)PAGE_OFFSET,
>>>>>>>>                    (unsigned long)high_memory)
>>>>>>>>
>>>>>>>> So now, do you think if it's necessary to have another
>>>>>>>> IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
>>>>>>> For which MACRO?  I think current code for PAGE_OFFSET is OK.
>>>>>>>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Xianting Tian]

在 2022/10/31 下午4:57, Baoquan He 写道:
> On 10/26/22 at 02:47pm, Conor Dooley wrote:
>> On Wed, Oct 26, 2022 at 08:05:41PM +0800, Baoquan He wrote:
>>> Hi Xianting,
>>>
>>> On 10/26/22 at 05:44pm, Xianting Tian wrote:
>>>> 在 2022/10/26 下午5:25, Conor Dooley 写道:
>>>>> On Wed, Oct 26, 2022 at 05:08:11PM +0800, Xianting Tian wrote:
>>>>>> Hi Palmer, Conor
>>>>>>
>>>>>> Is this version OK for you?
>>>>> The weird ifdef/IS_ENABLED thing was the only comment I had. It's a bit
>>>>> odd & I notice Baoquan brought it up too. I didn't (and won't) give you
>>>>> a reviewed by on these patches because I don't understand the area well
>>>>> enough. The general nitpickery seems to be sorted though.
>>>> I checked the KERNEL_LINK_ADDR definition of riscv,  it is valid for
>>>> CONFIG_64BIT and !CONFIG_64BIT.
>>> This series looks good to me. My only minor concern is if we can make
>>> the arch_crash_save_vmcoreinfo() as below. I don't understand why we
>>> have to have the CONFIG_64BIT ifdeffery and the IS_ENABLED(CONFIG_64BIT)
>>> between two adjacent code blocks. Not sure if we are saying the same
>>> thing.
>> I think we can just go and drop the IS_ENABLED(). From looking at it
>> last time, one bit is compileable (but not usable) for !64BIT and the
>> other isn't hence the IS_ENABLED(). I think it would make sense to drop
>> the IS_ENABLED() - I don't think we're too likely to hit some compile
>> testing edge cases that IS_ENABLED() would help with & only having one
>> makes the code look a lot less odd and a lot more intentional.
> I check risc-v code again, and agree we can drop the IS_ENABLED checking
> to export KERNEL_LINK_ADDR anyway. We can surely deduce
> KERNEL_LINK_ADDR in userspace e.g makedumpfile/Crash, while it seems no
> harm to get it from the vmcoreinfo directly.

thanks Baoquan for the confirm,

please help give the Revied-by and promote the patch set to be applied 
to Linux 6.1 :)

>
> As for the difference between "#ifdef CONFIG_64BIT" and
> "if (IS_ENABLED(CONFIG_64BIT))", I haven't got what's the Xianting's
> point. Below is the IS_ENABLED definition in include/linux/kconfig.h,
> it's truly different than #ifdef, while the change we are discussing
> here is not related.
>
> /*
>   * IS_ENABLED(CONFIG_FOO) evaluates to 1 if CONFIG_FOO is set to 'y' or 'm',
>   * 0 otherwise.  Note that CONFIG_FOO=y results in "#define CONFIG_FOO 1" in
>   * autoconf.h, while CONFIG_FOO=m results in "#define CONFIG_FOO_MODULE 1".
>   */
> #define IS_ENABLED(option) __or(IS_BUILTIN(option), IS_MODULE(option))
>
>>> +void arch_crash_save_vmcoreinfo(void)
>>> +{
>>> +       VMCOREINFO_NUMBER(VA_BITS);
>>> +       VMCOREINFO_NUMBER(phys_ram_base);
>>> +
>>> +       vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
>>> +       vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
>>> +       vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
>>> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
>>> +       vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
>>> +#ifdef CONFIG_64BIT
>>> +	vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
>>> +       vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
>>> +       vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
>>> +#endif
>>> +}
>>>
>>>> Maybe we can remove IS_ENABLED(CONFIG_64BIT)
>>>>
>>>> arch/riscv/include/asm/pgtable.h
>>>> #define ADDRESS_SPACE_END       (UL(-1))
>>>> #ifdef CONFIG_64BIT
>>>> /* Leave 2GB for kernel and BPF at the end of the address space */
>>>> #define KERNEL_LINK_ADDR        (ADDRESS_SPACE_END - SZ_2G + 1)
>>>> #else
>>>> #define KERNEL_LINK_ADDR        PAGE_OFFSET
>>>> #endif
>>>>
>>>> arch/riscv/include/asm/page.h
>>>> #ifdef CONFIG_64BIT
>>>> #ifdef CONFIG_MMU
>>>> #define PAGE_OFFSET             kernel_map.page_offset
>>>> #else
>>>> #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
>>>> #endif
>>>> /*
>>>>   * By default, CONFIG_PAGE_OFFSET value corresponds to SV48 address space so
>>>>   * define the PAGE_OFFSET value for SV39.
>>>>   */
>>>> #define PAGE_OFFSET_L4          _AC(0xffffaf8000000000, UL)
>>>> #define PAGE_OFFSET_L3          _AC(0xffffffd800000000, UL)
>>>> #else
>>>> #define PAGE_OFFSET             _AC(CONFIG_PAGE_OFFSET, UL)
>>>> #endif /* CONFIG_64BIT */
>>>>
>>>>> Thanks,
>>>>> Conor.
>>>>>
>>>>>> 在 2022/10/20 下午12:40, Xianting Tian 写道:
>>>>>>> 在 2022/10/20 上午11:05, Baoquan He 写道:
>>>>>>>> On 10/20/22 at 10:17am, Xianting Tian wrote:
>>>>>>>>> 在 2022/10/20 上午10:08, Baoquan He 写道:
>>>>>>>>>> On 10/19/22 at 06:36pm, Xianting Tian wrote:
>>>>>>>>>>> Add arch_crash_save_vmcoreinfo(), which exports VM
>>>>>>>>>>> layout(MODULES, VMALLOC,
>>>>>>>>>>> VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram
>>>>>>>>>>> base for vmcore.
>>>>>>>>>>>
>>>>>>>>>>> Default pagetable levels and PAGE_OFFSET aren't same for
>>>>>>>>>>> different kernel
>>>>>>>>>>> version as below. For pagetable levels, it sets sv57 by
>>>>>>>>>>> default and falls
>>>>>>>>>>> back to setting sv48 at boot time if sv57 is not
>>>>>>>>>>> supported by the hardware.
>>>>>>>>>>>
>>>>>>>>>>> For ram base, the default value is 0x80200000 for qemu
>>>>>>>>>>> riscv64 env and,
>>>>>>>>>>> for example, is 0x200000 on the XuanTie 910 CPU.
>>>>>>>>>>>
>>>>>>>>>>>      * Linux Kernel 5.18 ~
>>>>>>>>>>>      *      PGTABLE_LEVELS = 5
>>>>>>>>>>>      *      PAGE_OFFSET = 0xff60000000000000
>>>>>>>>>>>      * Linux Kernel 5.17 ~
>>>>>>>>>>>      *      PGTABLE_LEVELS = 4
>>>>>>>>>>>      *      PAGE_OFFSET = 0xffffaf8000000000
>>>>>>>>>>>      * Linux Kernel 4.19 ~
>>>>>>>>>>>      *      PGTABLE_LEVELS = 3
>>>>>>>>>>>      *      PAGE_OFFSET = 0xffffffe000000000
>>>>>>>>>>>
>>>>>>>>>>> Since these configurations change from time to time and
>>>>>>>>>>> version to version,
>>>>>>>>>>> it is preferable to export them via vmcoreinfo than to
>>>>>>>>>>> change the crash's
>>>>>>>>>>> code frequently, it can simplify the development of crash tool.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
>>>>>>>>>>> ---
>>>>>>>>>>>      arch/riscv/kernel/Makefile     |  1 +
>>>>>>>>>>>      arch/riscv/kernel/crash_core.c | 23 +++++++++++++++++++++++
>>>>>>>>>>>      2 files changed, 24 insertions(+)
>>>>>>>>>>>      create mode 100644 arch/riscv/kernel/crash_core.c
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
>>>>>>>>>>> index db6e4b1294ba..4cf303a779ab 100644
>>>>>>>>>>> --- a/arch/riscv/kernel/Makefile
>>>>>>>>>>> +++ b/arch/riscv/kernel/Makefile
>>>>>>>>>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)        += kgdb.o
>>>>>>>>>>>      obj-$(CONFIG_KEXEC_CORE)    += kexec_relocate.o
>>>>>>>>>>> crash_save_regs.o machine_kexec.o
>>>>>>>>>>>      obj-$(CONFIG_KEXEC_FILE)    += elf_kexec.o machine_kexec_file.o
>>>>>>>>>>>      obj-$(CONFIG_CRASH_DUMP)    += crash_dump.o
>>>>>>>>>>> +obj-$(CONFIG_CRASH_CORE)    += crash_core.o
>>>>>>>>>>>      obj-$(CONFIG_JUMP_LABEL)    += jump_label.o
>>>>>>>>>>> diff --git a/arch/riscv/kernel/crash_core.c
>>>>>>>>>>> b/arch/riscv/kernel/crash_core.c
>>>>>>>>>>> new file mode 100644
>>>>>>>>>>> index 000000000000..3e889d0ed7bd
>>>>>>>>>>> --- /dev/null
>>>>>>>>>>> +++ b/arch/riscv/kernel/crash_core.c
>>>>>>>>>>> @@ -0,0 +1,23 @@
>>>>>>>>>>> +// SPDX-License-Identifier: GPL-2.0-only
>>>>>>>>>>> +
>>>>>>>>>>> +#include <linux/crash_core.h>
>>>>>>>>>>> +#include <linux/pagemap.h>
>>>>>>>>>>> +
>>>>>>>>>>> +void arch_crash_save_vmcoreinfo(void)
>>>>>>>>>>> +{
>>>>>>>>>>> +    VMCOREINFO_NUMBER(VA_BITS);
>>>>>>>>>>> +    VMCOREINFO_NUMBER(phys_ram_base);
>>>>>>>>>>> +
>>>>>>>>>>> +
>>>>>>>>>>> vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n",
>>>>>>>>>>> PAGE_OFFSET);
>>>>>>>>>>> + vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n",
>>>>>>>>>>> VMALLOC_START);
>>>>>>>>>>> +
>>>>>>>>>>> vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n",
>>>>>>>>>>> VMALLOC_END);
>>>>>>>>>>> + vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n",
>>>>>>>>>>> VMEMMAP_START);
>>>>>>>>>>> +
>>>>>>>>>>> vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n",
>>>>>>>>>>> VMEMMAP_END);
>>>>>>>>>>> +#ifdef CONFIG_64BIT
>>>>>>>>>>> + vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n",
>>>>>>>>>>> MODULES_VADDR);
>>>>>>>>>>> +
>>>>>>>>>>> vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n",
>>>>>>>>>>> MODULES_END);
>>>>>>>>>>> +#endif
>>>>>>>>>>> +
>>>>>>>>>>> +    if (IS_ENABLED(CONFIG_64BIT))
>>>>>>>>>>> +
>>>>>>>>>>> vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n",
>>>>>>>>>>> KERNEL_LINK_ADDR);
>>>>>>>>>> Wondering why you don't put KERNEL_LINK_ADDR exporting into the above
>>>>>>>>>> ifdeffery scope, with that you can save one line of
>>>>>>>>>> "IS_ENABLED(CONFIG_64BIT)".
>>>>>>>>> I followed the rule in print_vm_layout() of
>>>>>>>>> arch/riscv/mm/init.c, which used
>>>>>>>>> IS_ENABLED when print the value of KERNEL_LINK_ADDR.
>>>>>>>>>
>>>>>>>> I see. There's PAGE_OFFSET in the middle. Thanks.
>>>>>>>>
>>>>>>>>            print_ml("lowmem", (unsigned long)PAGE_OFFSET,
>>>>>>>>                    (unsigned long)high_memory)
>>>>>>>>
>>>>>>>> So now, do you think if it's necessary to have another
>>>>>>>> IS_ENABLED(CONFIG_64BIT) in the current arch_crash_save_vmcoreinfo()?
>>>>>>> For which MACRO?  I think current code for PAGE_OFFSET is OK.
>>>>>>>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec