From: Harsh Prateek Bora <harshpb@linux.ibm.com>
To: qemu-devel@nongnu.org
Cc: Aditya Gupta <adityag@linux.ibm.com>,
Sourabh Jain <sourabhjain@linux.ibm.com>,
Shivang Upadhyay <shivangu@linux.ibm.com>
Subject: [PULL 26/32] hw/ppc: Trigger Fadump boot if fadump is registered
Date: Thu, 23 Oct 2025 17:46:45 +0530 [thread overview]
Message-ID: <20251023121653.3686015-27-harshpb@linux.ibm.com> (raw)
In-Reply-To: <20251023121653.3686015-1-harshpb@linux.ibm.com>
From: Aditya Gupta <adityag@linux.ibm.com>
According to PAPR:
R1–7.3.30–3. When the platform receives an ibm,os-term RTAS call, or
on a system reset without an ibm,nmi-interlock RTAS call, if the
platform has a dump structure registered through the
ibm,configure-kernel-dump call, the platform must process each
registered kernel dump section as required and, when available,
present the dump structure information to the operating system
through the “ibm,kernel-dump” property, updated with status for each
dump section, until the dump has been invalidated through the
ibm,configure-kernel-dump RTAS call.
If Fadump has been registered, trigger an Fadump boot (memory preserving
boot), if QEMU recieves a 'ibm,os-term' rtas call.
Implementing the fadump boot as:
* pause all vcpus (will need to save registers later)
* preserve memory regions specified by fadump (will be implemented
in future)
* do a memory preserving reboot (GUEST_RESET in QEMU doesn't clear
the memory)
Memory regions registered by fadump will be handled in a later patch.
Note: Preserving memory regions is not implemented yet so on an
"ibm,os-term" call will just trigger a reboot in QEMU if fadump is
registered, and the second kernel will boot as a normal boot (not
fadump boot)
Signed-off-by: Aditya Gupta <adityag@linux.ibm.com>
Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Tested-by: Shivang Upadhyay <shivangu@linux.ibm.com>
Link: https://lore.kernel.org/qemu-devel/20251021134823.1861675-3-adityag@linux.ibm.com
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
---
include/hw/ppc/spapr_fadump.h | 6 +++
hw/ppc/spapr_fadump.c | 77 +++++++++++++++++++++++++++++++++++
hw/ppc/spapr_rtas.c | 5 +++
3 files changed, 88 insertions(+)
diff --git a/include/hw/ppc/spapr_fadump.h b/include/hw/ppc/spapr_fadump.h
index f64f339204..1cb90c9d63 100644
--- a/include/hw/ppc/spapr_fadump.h
+++ b/include/hw/ppc/spapr_fadump.h
@@ -16,6 +16,11 @@
#define FADUMP_VERSION 1
+/* Dump status flags */
+#define FADUMP_STATUS_DUMP_PERFORMED 0x8000
+#define FADUMP_STATUS_DUMP_TRIGGERED 0x4000
+#define FADUMP_STATUS_DUMP_ERROR 0x2000
+
/*
* The Firmware Assisted Dump Memory structure supports a maximum of 10 sections
* in the dump memory structure. Presently, three sections are used for
@@ -66,4 +71,5 @@ struct FadumpMemStruct {
};
uint32_t do_fadump_register(struct SpaprMachineState *, target_ulong);
+void trigger_fadump_boot(struct SpaprMachineState *, target_ulong);
#endif /* PPC_SPAPR_FADUMP_H */
diff --git a/hw/ppc/spapr_fadump.c b/hw/ppc/spapr_fadump.c
index 2c9f024c2d..53e5c12c76 100644
--- a/hw/ppc/spapr_fadump.c
+++ b/hw/ppc/spapr_fadump.c
@@ -7,6 +7,7 @@
#include "qemu/osdep.h"
#include "qemu/log.h"
#include "hw/ppc/spapr.h"
+#include "system/cpus.h"
/*
* Handle the "FADUMP_CMD_REGISTER" command in 'ibm,configure-kernel-dump'
@@ -121,3 +122,79 @@ uint32_t do_fadump_register(SpaprMachineState *spapr, target_ulong args)
return RTAS_OUT_SUCCESS;
}
+
+/* Preserve the memory locations registered for fadump */
+static bool fadump_preserve_mem(void)
+{
+ /*
+ * TODO: Implement preserving memory regions requested during fadump
+ * registration
+ */
+ return false;
+}
+
+/*
+ * Trigger a fadump boot, ie. next boot will be a crashkernel/fadump boot
+ * with fadump dump active.
+ *
+ * This is triggered by ibm,os-term RTAS call, if fadump was registered.
+ *
+ * It preserves the memory and sets 'FADUMP_STATUS_DUMP_TRIGGERED' as
+ * fadump status, which can be used later to add the "ibm,kernel-dump"
+ * device tree node as presence of 'FADUMP_STATUS_DUMP_TRIGGERED' signifies
+ * next boot as fadump boot in our case
+ */
+void trigger_fadump_boot(SpaprMachineState *spapr, target_ulong spapr_retcode)
+{
+ FadumpSectionHeader *header = &spapr->registered_fdm.header;
+
+ pause_all_vcpus();
+
+ /* Preserve the memory locations registered for fadump */
+ if (!fadump_preserve_mem()) {
+ /* Failed to preserve the registered memory regions */
+ rtas_st(spapr_retcode, 0, RTAS_OUT_HW_ERROR);
+
+ /* Cause a reboot */
+ qemu_system_guest_panicked(NULL);
+ return;
+ }
+
+ /*
+ * Mark next boot as fadump boot
+ *
+ * Note: These is some bit of assumption involved here, as PAPR doesn't
+ * specify any use of the dump status flags, nor does the kernel use it
+ *
+ * But from description in Table 136 in PAPR v2.13, it looks like:
+ * FADUMP_STATUS_DUMP_TRIGGERED
+ * = Dump was triggered by the previous system boot (PAPR says)
+ * = Next boot will be a fadump boot (Assumed)
+ *
+ * FADUMP_STATUS_DUMP_PERFORMED
+ * = Dump performed (Set to 0 by caller of the
+ * ibm,configure-kernel-dump call) (PAPR says)
+ * = Firmware has performed the copying/dump of requested regions
+ * (Assumed)
+ * = Dump is active for the next boot (Assumed)
+ */
+ header->dump_status_flag = cpu_to_be16(
+ FADUMP_STATUS_DUMP_TRIGGERED | /* Next boot will be fadump boot */
+ FADUMP_STATUS_DUMP_PERFORMED /* Dump is active */
+ );
+
+ /* Reset fadump_registered for next boot */
+ spapr->fadump_registered = false;
+ spapr->fadump_dump_active = true;
+
+ /*
+ * Then do a guest reset
+ *
+ * Requirement:
+ * GUEST_RESET is expected to NOT clear the memory, as is the case when
+ * this is merged
+ */
+ qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET);
+
+ rtas_st(spapr_retcode, 0, RTAS_OUT_SUCCESS);
+}
diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
index 6042fc72e5..1f78fe406e 100644
--- a/hw/ppc/spapr_rtas.c
+++ b/hw/ppc/spapr_rtas.c
@@ -420,6 +420,11 @@ static void rtas_ibm_os_term(PowerPCCPU *cpu,
target_ulong msgaddr = rtas_ld(args, 0);
char msg[512];
+ if (spapr->fadump_registered) {
+ /* If fadump boot works, control won't come back here */
+ return trigger_fadump_boot(spapr, rets);
+ }
+
cpu_physical_memory_read(msgaddr, msg, sizeof(msg) - 1);
msg[sizeof(msg) - 1] = 0;
--
2.43.5
next prev parent reply other threads:[~2025-10-23 12:33 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-23 12:16 [PULL RESEND 00/32] ppc-for-10.2 queue Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 01/32] ppc/spapr: remove deprecated machine pseries-3.0 Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 02/32] hw/ppc/spapr: Remove SpaprMachineClass::nr_xirqs field Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 03/32] ppc/spapr: remove deprecated machine pseries-3.1 Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 04/32] hw/ppc/spapr: Inline spapr_dtb_needed() Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 05/32] hw/ppc/spapr: Inline few SPAPR_IRQ_* uses Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 06/32] target/ppc/kvm: Remove kvmppc_get_host_serial() as unused Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 07/32] target/ppc/kvm: Remove kvmppc_get_host_model() " Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 08/32] ppc/spapr: remove deprecated machine pseries-4.0 Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 09/32] hw/ppc/spapr: Remove SpaprMachineClass::phb_placement callback Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 10/32] ppc/spapr: remove deprecated machine pseries-4.1 Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 11/32] ppc/spapr: remove deprecated machine pseries-4.2 Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 12/32] ppc/amigaone: Free allocated struct Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 13/32] ppc/vof: Make nextprop behave more like Open Firmware Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 14/32] hw/ppc/pegasos2: Remove explicit name properties from device tree Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 15/32] hw/ppc/pegasos2: Change device tree generation Harsh Prateek Bora
2025-10-27 13:14 ` Peter Maydell
2025-10-30 9:06 ` Harsh Prateek Bora
2025-10-30 10:18 ` BALATON Zoltan
2025-10-23 12:16 ` [PULL 16/32] hw/ppc/pegasos2: Remove fdt pointer from machine state Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 17/32] hw/ppc/pegasos2: Rename mv field in " Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 18/32] hw/ppc/pegasos2: Add south bridge pointer in the " Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 19/32] hw/ppc/pegasos2: Move PCI IRQ routing setup to a function Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 20/32] hw/ppc/pegasos2: Move hardware specific parts out of machine reset Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 21/32] hw/ppc/pegasos2: Introduce abstract superclass Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 22/32] hw/ppc/pegasos2: Add bus frequency to machine state Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 23/32] hw/ppc/pegasos2: Add Pegasos I emulation Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 24/32] hw/ppc/pegasos2: Add VOF support for pegasos1 Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 25/32] hw/ppc: Implement fadump register command Harsh Prateek Bora
2025-10-23 12:16 ` Harsh Prateek Bora [this message]
2025-10-23 12:16 ` [PULL 27/32] hw/ppc: Preserve memory regions registered for fadump Harsh Prateek Bora
2025-10-27 13:06 ` Peter Maydell
2025-10-23 12:16 ` [PULL 28/32] hw/ppc: Implement saving CPU state in Fadump Harsh Prateek Bora
2025-10-27 13:03 ` Peter Maydell
2025-10-23 12:16 ` [PULL 29/32] hw/ppc: Pass dump-sizes property for fadump in device tree Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 30/32] hw/ppc: Enable fadump for PSeries Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 31/32] tests/functional: Add test for fadump in PSeries Harsh Prateek Bora
2025-10-23 12:16 ` [PULL 32/32] MAINTAINERS: Add entry for FADump (pSeries) Harsh Prateek Bora
2025-10-23 19:33 ` [PULL RESEND 00/32] ppc-for-10.2 queue Richard Henderson
-- strict thread matches above, loose matches on Subject: below --
2025-10-23 11:43 [PULL " Harsh Prateek Bora
2025-10-23 11:44 ` [PULL 26/32] hw/ppc: Trigger Fadump boot if fadump is registered Harsh Prateek Bora
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=20251023121653.3686015-27-harshpb@linux.ibm.com \
--to=harshpb@linux.ibm.com \
--cc=adityag@linux.ibm.com \
--cc=qemu-devel@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).