Re: [PATCH v4 3/8] hw/ppc: Trigger Fadump boot if fadump is registered

[Sourabh Jain <sourabhjain@linux.ibm.com>]

On 23/03/25 23:10, Aditya Gupta wrote:
> 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>
> ---
>   hw/ppc/spapr_fadump.c         | 77 +++++++++++++++++++++++++++++++++++
>   hw/ppc/spapr_rtas.c           |  5 +++
>   include/hw/ppc/spapr_fadump.h |  6 +++
>   3 files changed, 88 insertions(+)
>
> diff --git a/hw/ppc/spapr_fadump.c b/hw/ppc/spapr_fadump.c
> index 9c7fb9e12b16..fedd2cde9a4f 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 (My perception)

Can we say assumption made or assumed instead of My perception.

> +     *
> +     *   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
> +     *        (My perception)
> +     *      = Dump is active for the next boot (My perception)

Same here.

> +     */
> +    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 0454938a01e9..14b954a05109 100644
> --- a/hw/ppc/spapr_rtas.c
> +++ b/hw/ppc/spapr_rtas.c
> @@ -412,6 +412,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;
>   
> diff --git a/include/hw/ppc/spapr_fadump.h b/include/hw/ppc/spapr_fadump.h
> index 6abbcb44f353..e484604c1c70 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 */