[PATCH makedumpfile 0/2] Add riscv64 support for makedumpfile
HAGIO KAZUHITO(萩尾 一仁)
k-hagio-ab at nec.com
Mon Oct 2 21:22:28 PDT 2023
Hi,
thank you for the patch.
On 2023/09/27 20:18, Song Shuai wrote:
> These 2 patches add riscv64 support for makedumpfile:
>
> Patch1 - Add riscv64 support
> ===========================
>
> This patch adds support for riscv64 in makedumpfile.
> It implements the "vtop" for kenrel memory regions
> and supports Sv39/Sv48/Sv57 page modes for RV64.
Could I have a log of makedumpfile with --message-level 31 option for
reference? e.g.
makedumpfile -c -d 31 --message-level 31 vmcore dumpfile > mkdf.log
(IIRC the kexec mail list doesn't accept attached files, so please send
it off-list.)
>
>
> Patch2 - riscv64: Correct the pfn_start for flatmem
> ==================================================
>
> This patch temporarily fixes a issue of the tests about FLATMEM,
> as the commit-msg says:
>
> To let info->max_mapnr indicte the direct max PFN and then
This means "indicate", right?
Thanks,
Kazu
> make the kdump header's max_mapnr_64 correct, riscv64 port
> didn't define ARCH_PFN_OFFSET.
>
> As for FLATMEM type, the pfn region of mem_map_data should
> be adjusted to start from info->phys_base instead of zero.
>
> Not taking other arches into consideration and test, so I simplely
> judge the __riscv64__ instead of ARCH_PFN_OFFSET. Maybe we can improve it.
>
>
> Tests
> =====
>
> With these 2 patches, the following tests had passed in RV64 Qemu virt machine:
>
> Preparation:
> -----------
>
> 1. build kernel with FLATMEM and SPARSE memory models
> 2. boot kernel with 3 different page-modes by setting nov4l/nov5l in cmdline
> 3. panic kernel
>
> Tests:
> -----
>
> 1. create kdump-compressed file via this command
> - `/mnt/mkdf_f -d31 -f -c /proc/vmcore /mnt/dump.file1`
> - or with `--vtop` option to translate some typical addresses (like:
> kernel_link_addr, vmalloc_start, page_offset)
>
> 2. start crash with kdump file and do some VTOPs
>
>
> A test log:
> -----------
>
> # With the Sv57 and SPARSE_EXTREME kernel
> # vtop the vmalloc start address -- 0xff20000000000000
>
>
> # /mnt/mkdf_f --vtop 0xff20000000000000 -d31 -f --non-mmap -c /proc/vmcore /mnt/dump.file1
>
> Translating virtual address ff20000000000000 to physical address.
> VIRTUAL PHYSICAL
> ff20000000000000 80087000
>
> Copying data : [100.0 %] |
> eta: 0s
>
> The dumpfile is saved to /mnt/dump.file1.
>
> makedumpfile Completed.
>
> # sudo ../crash/crash /home/song/9_linux/linux/00_rv_def/vmlinux /tmp/hello/dump.file1
> ...
> KERNEL: /home/song/9_linux/linux/00_rv_def/vmlinux
> DUMPFILE: /tmp/hello/dump.file1 [PARTIAL DUMP]
> CPUS: 2
> DATE: Wed Sep 27 18:37:45 CST 2023
> UPTIME: 00:00:18
> LOAD AVERAGE: 0.00, 0.00, 0.00
> TASKS: 55
> NODENAME: (none)
> RELEASE: 6.6.0-rc1-00007-g22bfc766389c
> VERSION: #1 SMP Mon Sep 25 19:29:05 CST 2023
> MACHINE: riscv64 (unknown Mhz)
> MEMORY: 511.8 MB
> PANIC: "Kernel panic - not syncing: sysrq triggered crash"
> PID: 1
> COMMAND: "sh"
> TASK: ff600000000e0000 [THREAD_INFO: ff600000000e0000]
> CPU: 1
> STATE: TASK_RUNNING (PANIC)
>
> crash> vtop 0xff20000000000000
> VIRTUAL PHYSICAL
> ff20000000000000 80087000
>
> PGD: ffffffff814fa900 => 20010c01
> P4D: 0000000080043000 => 0000000020025401
> PUD: 0000000080095000 => 0000000020025801
> PMD: 0000000080096000 => 0000000020026001
> PTE: 80098000 => 20021ce7
> PAGE: 0000000080087000
>
> PTE PHYSICAL FLAGS
> 20021ce7 80087000 (PRESENT|READ|WRITE|GLOBAL|ACCESSED|DIRTY)
>
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> ff1c0000020021c0 80087000 0 0 1 0 // same as the makedumpfile's vtop
>
>
> Song Shuai (2):
> Add riscv64 support
> riscv64: Correct the pfn_start for flatmem
>
> Makefile | 2 +-
> arch/riscv64.c | 219 +++++++++++++++++++++++++++++++++++++++++++++++++
> makedumpfile.c | 18 ++++
> makedumpfile.h | 107 ++++++++++++++++++++++++
> 4 files changed, 345 insertions(+), 1 deletion(-)
> create mode 100644 arch/riscv64.c
>
More information about the kexec
mailing list