[PATCH makedumpfile 0/2] Add riscv64 support for makedumpfile

Song Shuai songshuaishuai at tinylab.org
Fri Oct 6 19:27:50 PDT 2023



在 2023/10/3 12:22, HAGIO KAZUHITO(萩尾 一仁) 写道:
> 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.)

Sorry for the later reply,

here are the log for the Sv57 and SPARSE_EXTREME kernel:

https://termbin.com/zcf9:

and the log for FLATMEM

https://termbin.com/t89k

> 
>>
>>
>> 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?
> 
Right, would fix it if you're ok with the Patch2.

> 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

-- 
Thanks
Song Shuai



More information about the kexec mailing list