From: Aditya Gupta <adityag@linux.ibm.com>
To: <qemu-devel@nongnu.org>
Cc: <qemu-ppc@nongnu.org>, Nicholas Piggin <npiggin@gmail.com>,
Daniel Henrique Barboza <danielhb413@gmail.com>,
Harsh Prateek Bora <harshpb@linux.ibm.com>,
Sourabh Jain <sourabhjain@linux.ibm.com>,
Mahesh J Salgaonkar <mahesh@linux.ibm.com>,
Hari Bathini <hbathini@linux.ibm.com>
Subject: [PATCH 0/6] Implement Firmware Assisted Dump for PSeries
Date: Mon, 17 Feb 2025 12:47:05 +0530 [thread overview]
Message-ID: <20250217071711.83735-1-adityag@linux.ibm.com> (raw)
Overview
=========
Implemented Firmware Assisted Dump (fadump) on PSeries machine in QEMU.
Fadump is an alternative dump mechanism to kdump, in which we the firmware
does a memory preserving boot, and the second/crashkernel is booted fresh
like a normal system reset, instead of the crashed kernel loading the
second/crashkernel in case of kdump.
This requires implementing the "ibm,configure-kernel-dump" RTAS call in
QEMU.
While booting with fadump=on, Linux will register fadump memory regions.
Some memory regions like Real Mode Memory regions, and custom memory
regions declared by OS basically require copying the requested memory
range to a destination
While other memory regions are populated by the firmware/platform (QEMU in
this case), such as CPU State Data and HPTE.
We pass the sizes for these data segment to the kernel as it needs to know
how much memory to reserve (ibm,configure-kernel-dump-sizes).
Then after a crash, once Linux does a OS terminate call, we trigger fadump
if fadump was registered.
Implementing the fadump boot as:
* pause all vcpus (will save registers later)
* preserve memory regions specified by fadump
* do a memory preserving reboot (using GUEST_RESET as it doesn't clear
the memory)
And then we pass a metadata (firmware memory structure) as
"ibm,kernel-dump" in the device tree, containing all details of the
preserved memory regions to the kernel.
Testing
=======
Has been tested with following QEMU options:
* firmware: x-vof and SLOF
* tcg & kvm
* l1 guest and l2 guest
* with/without smp
* cma/nocma
* default crashkernel values and crashkernel=1G
Logs of a linux boot with firmware assisted dump:
./build/qemu-system-ppc64 -M pseries,x-vof=on --cpu power10 --smp 4 -m 4G -kernel some-vmlinux -initrd some-initrd -append "debug fadump=on crashkernel=1G" -nographic
[ 0.000000] random: crng init done
[ 0.000000] fadump: Reserved 1024MB of memory at 0x00000040000000 (System RAM: 4096MB)
...
[ 1.084686] rtas fadump: Registration is successful!
...
# cat /sys/kernel/debug/powerpc/fadump_region
CPU :[0x00000040000000-0x000000400013d3] 0x13d4 bytes, Dumped: 0x0
HPTE:[0x000000400013d4-0x000000400013d3] 0x0 bytes, Dumped: 0x0
DUMP: Src: 0x00000000000000, Dest: 0x00000040010000, Size: 0x40000000, Dumped: 0x0 bytes
[0x000000fffff800-0x000000ffffffff]: cmdline append: ''
# echo c > /proc/sysrq-trigger
The fadump boot after crash:
[ 0.000000] rtas fadump: Firmware-assisted dump is active.
[ 0.000000] fadump: Updated cmdline: debug fadump=on crashkernel=1G
[ 0.000000] fadump: Firmware-assisted dump is active.
[ 0.000000] fadump: Reserving 3072MB of memory at 0x00000040000000 for preserving crash data
....
# file /proc/vmcore
/proc/vmcore: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, OpenPOWER ELF V2 ABI, version 1 (SYSV), SVR4-style
Analysing the vmcore with crash-utility:
KERNEL: vmlinux-6.14-rc2
DUMPFILE: vmcore-a64dcfb451e2-nocma
CPUS: 4
DATE: Thu Jan 1 05:30:00 IST 1970
UPTIME: 00:00:30
LOAD AVERAGE: 0.74, 0.21, 0.07
TASKS: 94
NODENAME: buildroot
RELEASE: 6.14.0-rc2+
VERSION: #1 SMP Wed Feb 12 06:49:59 CST 2025
MACHINE: ppc64le (1000 Mhz)
MEMORY: 4 GB
PANIC: "Kernel panic - not syncing: sysrq triggered crash"
PID: 270
COMMAND: "sh"
TASK: c000000009e7cc00 [THREAD_INFO: c000000009e7cc00]
CPU: 3
STATE: TASK_RUNNING (PANIC)
Git Tree for Testing
====================
https://github.com/adi-g15-ibm/qemu/tree/fadump-pseries-v1
Known Issues
============
* CPU register saving seems to have cases where it's showing all registers
with the same value
* The implementation doesn't pass all the registers mentioned in PAPR since
QEMU doesn't implement them/doesn't need them.
The linux kernel uses only 9 of the 45 registers we are passing in QEMU.
Aditya Gupta (6):
hw/ppc: Implement skeleton code for fadump in PSeries
hw/ppc: Trigger Fadump boot if fadump is registered
hw/ppc: Preserve memory regions registered for fadump
hw/ppc: Implement saving CPU state in Fadump
hw/ppc: Pass device tree properties for Fadump
hw/ppc: Enable Fadump for PSeries
hw/ppc/spapr.c | 62 ++++++
hw/ppc/spapr_rtas.c | 456 +++++++++++++++++++++++++++++++++++++++++
include/hw/ppc/spapr.h | 172 +++++++++++++++-
3 files changed, 689 insertions(+), 1 deletion(-)
--
2.48.1
next reply other threads:[~2025-02-17 7:18 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-17 7:17 Aditya Gupta [this message]
2025-02-17 7:17 ` [PATCH 1/6] hw/ppc: Implement skeleton code for fadump in PSeries Aditya Gupta
2025-02-27 3:07 ` Nicholas Piggin
2025-02-27 6:49 ` Aditya Gupta
2025-02-27 8:48 ` Nicholas Piggin
2025-02-27 12:15 ` Aditya Gupta
2025-03-04 9:01 ` Harsh Prateek Bora
2025-03-06 4:08 ` Aditya Gupta
2025-02-17 7:17 ` [PATCH 2/6] hw/ppc: Trigger Fadump boot if fadump is registered Aditya Gupta
2025-02-27 3:14 ` Nicholas Piggin
2025-02-27 6:56 ` Aditya Gupta
2025-03-04 9:21 ` Harsh Prateek Bora
2025-03-06 4:11 ` Aditya Gupta
2025-02-17 7:17 ` [PATCH 3/6] hw/ppc: Preserve memory regions registered for fadump Aditya Gupta
2025-03-05 6:40 ` Harsh Prateek Bora
2025-03-06 4:16 ` Aditya Gupta
2025-02-17 7:17 ` [PATCH 4/6] hw/ppc: Implement saving CPU state in Fadump Aditya Gupta
2025-02-27 3:27 ` Nicholas Piggin
2025-02-27 7:01 ` Aditya Gupta
2025-03-05 7:23 ` Harsh Prateek Bora
2025-03-06 4:22 ` Aditya Gupta
2025-02-17 7:17 ` [PATCH 5/6] hw/ppc: Pass device tree properties for Fadump Aditya Gupta
2025-02-27 3:28 ` Nicholas Piggin
2025-02-27 7:02 ` Aditya Gupta
2025-03-05 7:34 ` Harsh Prateek Bora
2025-02-17 7:17 ` [PATCH 6/6] hw/ppc: Enable Fadump for PSeries Aditya Gupta
2025-02-27 3:33 ` Nicholas Piggin
2025-02-27 7:07 ` Aditya Gupta
2025-02-27 8:52 ` Nicholas Piggin
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=20250217071711.83735-1-adityag@linux.ibm.com \
--to=adityag@linux.ibm.com \
--cc=danielhb413@gmail.com \
--cc=harshpb@linux.ibm.com \
--cc=hbathini@linux.ibm.com \
--cc=mahesh@linux.ibm.com \
--cc=npiggin@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=sourabhjain@linux.ibm.com \
/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;
as well as URLs for NNTP newsgroup(s).