Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "HAGIO KAZUHITO(萩尾 一仁)" <k-hagio-ab@nec.com>
To: Song Shuai <songshuaishuai@tinylab.org>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>
Subject: Re: [PATCH makedumpfile 0/2] Add riscv64 support for makedumpfile
Date: Tue, 3 Oct 2023 04:22:28 +0000	[thread overview]
Message-ID: <b7d09d33-c606-0c76-8865-e4e43a5d43ce@nec.com> (raw)
In-Reply-To: <20230927111822.180630-1-songshuaishuai@tinylab.org>

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
> 
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  parent reply	other threads:[~2023-10-03  4:23 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-27 11:18 [PATCH makedumpfile 0/2] Add riscv64 support for makedumpfile Song Shuai
2023-09-27 11:18 ` [PATCH makedumpfile 1/2] Add riscv64 support Song Shuai
2023-09-27 11:18 ` [PATCH makedumpfile 2/2] riscv64: Correct the pfn_start for flatmem Song Shuai
2023-10-03  4:22 ` HAGIO KAZUHITO(萩尾 一仁) [this message]
2023-10-07  2:27   ` [PATCH makedumpfile 0/2] Add riscv64 support for makedumpfile Song Shuai
2023-10-10  7:53     ` HAGIO KAZUHITO(萩尾 一仁)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b7d09d33-c606-0c76-8865-e4e43a5d43ce@nec.com \
    --to=k-hagio-ab@nec.com \
    --cc=kexec@lists.infradead.org \
    --cc=songshuaishuai@tinylab.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox