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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Changes since V1:
https://lore.kernel.org/kexec/20230927111822.180630-1-songshuaishuai@xxxxxxxxxxx/

- fix a typo in Patch2's commit-msg
- adjust some indentions of Patch1


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.


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 indicate the direct max PFN and then
    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.


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

-- 
2.20.1


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



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux