From: Harsh Prateek Bora <harshpb@linux.ibm.com>
To: Aditya Gupta <adityag@linux.ibm.com>,
qemu-devel@nongnu.org, shivangu@linux.ibm.com
Cc: qemu-ppc@nongnu.org, Nicholas Piggin <npiggin@gmail.com>,
Daniel Henrique Barboza <danielhb413@gmail.com>,
Sourabh Jain <sourabhjain@linux.ibm.com>,
Mahesh J Salgaonkar <mahesh@linux.ibm.com>,
Hari Bathini <hbathini@linux.ibm.com>
Subject: Re: [PATCH v4 0/8] Implement Firmware Assisted Dump for PSeries
Date: Tue, 21 Oct 2025 10:30:24 +0530 [thread overview]
Message-ID: <22f3b73d-c068-4df6-9eaa-4012068ab289@linux.ibm.com> (raw)
In-Reply-To: <20250323174007.221116-1-adityag@linux.ibm.com>
+ Shivang - FYI
Hi Aditya,
Could you please keep Shivang in Cc when you post v5 ? TIA.
regards,
Harsh
On 3/23/25 23:09, Aditya Gupta wrote:
> 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.
>
> Refer the Patch #7/8: "hw/ppc: Enable fadump for PSeries" for logs of a
> succesfful fadump crash
>
> Note: HPTE region has not been implemented. It's not planned as of now.
>
> 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 (can fail with big initrd) and crashkernel=1G
>
> Git Tree for Testing
> ====================
>
> https://github.com/adi-g15-ibm/qemu/tree/fadump-pseries-v4
>
> Note: You will need a way to get the /proc/vmcore out of the VM for testing
> with crash-utility
>
> I use the following command line which sets up networking:
> "-net user,hostfwd=tcp::10022-:22 -net nic"
>
> And a rootfs with ssh support, then copy the /proc/vmcore with networking
> (can do compression using gzip before ssh, but compression might take lot
> of time if done inside the VM)
>
> Test vmcore for Testing with crash-utility
> ==========================================
>
> Can use vmlinux and vmcore available at https://github.com/adi-g15-ibm/qemu/releases/tag/test-images-fadump-pseries-v2
> Above vmcore was generated with upstream qemu with these fadump patches
> applied, and in a KVM VM
> A limitation with above vmcore is it was a single CPU VM
>
> Changelog
> =========
> v4
> + [patch #8/8]: fixed kvm testcase, add license
>
> v3:
> + [patch #3,7]: fix compile errors (#define declared in a later patch
> but used in this patch, unused var)
> + [patch #4/8]: use 'g_autofree' for cpu buffer, and replace g_malloc with
> g_try_malloc
> + [patch #5/8]: use 'g_new' instead of 'malloc', add null check for cpu
> region
> - nothing in other patches has been changed compared to v2
>
> v2:
> + rearrange code so that no unused functions get introduced in any patch
> + add functional test for pseries as suggested by nick
> + fix multiple issues pointed by harsh and nick
> + fix bug in cpu register saving where it was being stored in
> little-endian
> - removed 'is_next_boot_fadump' and used fadump header's status flag to
> store it
> + fixed multiple style issues (naming, unneeded diffs etc)
>
> Aditya Gupta (8):
> hw/ppc: Implement skeleton code for fadump in PSeries
> hw/ppc: Implement fadump register command
> 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 dump-sizes property for fadump in device tree
> hw/ppc: Enable fadump for PSeries
> tests/functional: Add test for fadump in PSeries
>
> hw/ppc/meson.build | 1 +
> hw/ppc/spapr.c | 72 +++
> hw/ppc/spapr_fadump.c | 685 ++++++++++++++++++++++
> hw/ppc/spapr_rtas.c | 71 +++
> include/hw/ppc/spapr.h | 11 +-
> include/hw/ppc/spapr_fadump.h | 121 ++++
> tests/functional/meson.build | 2 +
> tests/functional/qemu_test/linuxkernel.py | 59 ++
> tests/functional/test_ppc64_fadump.py | 182 ++++++
> 9 files changed, 1203 insertions(+), 1 deletion(-)
> create mode 100644 hw/ppc/spapr_fadump.c
> create mode 100644 include/hw/ppc/spapr_fadump.h
> create mode 100755 tests/functional/test_ppc64_fadump.py
>
prev parent reply other threads:[~2025-10-21 5:01 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-23 17:39 [PATCH v4 0/8] Implement Firmware Assisted Dump for PSeries Aditya Gupta
2025-03-23 17:40 ` [PATCH v4 1/8] hw/ppc: Implement skeleton code for fadump in PSeries Aditya Gupta
2025-04-21 10:51 ` Harsh Prateek Bora
2025-04-22 4:48 ` Aditya Gupta
2025-10-17 8:40 ` Sourabh Jain
2025-10-17 11:38 ` Aditya Gupta
2025-10-17 11:44 ` Aditya Gupta
2025-10-20 5:23 ` Sourabh Jain
2025-10-17 11:46 ` Sourabh Jain
2025-10-17 11:56 ` Aditya Gupta
2025-10-18 11:50 ` Sourabh Jain
2025-10-19 11:30 ` Aditya Gupta
2025-03-23 17:40 ` [PATCH v4 2/8] hw/ppc: Implement fadump register command Aditya Gupta
2025-10-17 9:54 ` Sourabh Jain
2025-10-17 11:55 ` Aditya Gupta
2025-10-20 5:26 ` Sourabh Jain
2025-03-23 17:40 ` [PATCH v4 3/8] hw/ppc: Trigger Fadump boot if fadump is registered Aditya Gupta
2025-10-17 11:26 ` Sourabh Jain
2025-10-17 11:59 ` Aditya Gupta
2025-03-23 17:40 ` [PATCH v4 4/8] hw/ppc: Preserve memory regions registered for fadump Aditya Gupta
2025-10-17 13:06 ` Sourabh Jain
2025-10-17 18:13 ` Aditya Gupta
2025-03-23 17:40 ` [PATCH v4 5/8] hw/ppc: Implement saving CPU state in Fadump Aditya Gupta
2025-10-18 10:54 ` Sourabh Jain
2025-10-19 19:22 ` Aditya Gupta
2025-10-20 5:40 ` Sourabh Jain
2025-03-23 17:40 ` [PATCH v4 6/8] hw/ppc: Pass dump-sizes property for fadump in device tree Aditya Gupta
2025-10-18 11:20 ` Sourabh Jain
2025-10-19 19:30 ` Aditya Gupta
2025-10-20 5:44 ` Sourabh Jain
2025-03-23 17:40 ` [PATCH v4 7/8] hw/ppc: Enable fadump for PSeries Aditya Gupta
2025-10-18 12:04 ` Sourabh Jain
2025-10-20 19:44 ` Aditya Gupta
2025-03-23 17:40 ` [PATCH v4 8/8] tests/functional: Add test for fadump in PSeries Aditya Gupta
2025-04-21 6:27 ` [PATCH v4 0/8] Implement Firmware Assisted Dump for PSeries Aditya Gupta
2025-10-21 5:00 ` Harsh Prateek Bora [this message]
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=22f3b73d-c068-4df6-9eaa-4012068ab289@linux.ibm.com \
--to=harshpb@linux.ibm.com \
--cc=adityag@linux.ibm.com \
--cc=danielhb413@gmail.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=shivangu@linux.ibm.com \
--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).