From: "Nicholas Piggin" <npiggin@gmail.com>
To: "Aditya Gupta" <adityag@linux.ibm.com>, <qemu-devel@nongnu.org>
Cc: <qemu-ppc@nongnu.org>,
"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: Re: [PATCH 5/6] hw/ppc: Pass device tree properties for Fadump
Date: Thu, 27 Feb 2025 13:28:53 +1000 [thread overview]
Message-ID: <D82WR22WF5C9.20VWJUD0Y5IPN@gmail.com> (raw)
In-Reply-To: <20250217071711.83735-6-adityag@linux.ibm.com>
On Mon Feb 17, 2025 at 5:17 PM AEST, Aditya Gupta wrote:
> Platform (ie. QEMU) is expected to pass few device tree properties for
> details for fadump:
>
> * "ibm,configure-kernel-dump": RTAS call for fadump
> * "ibm,configure-kernel-dump-sizes": Space required to store dump data
> for firmware provided dump sections (ie. CPU & HPTE regions)
> * "ibm,configure-kernel-dump-version": Versions of fadump supported
> * "ibm,kernel-dump": Contains the Fadump Memory Structure on a fadump
> boot
>
> Implement passing configure-kernel-dump-sizes, and
> configure-kernel-dump-version device tree properties, irrespective of
> whether it's a fadump boot or not, so that kernel can reserve memory to
> store the firmware provided dump sections in case of a crash
>
> Also, in case of a fadump boot, pass the fadump memory structure to the
> kernel in "ibm,kernel-dump" device tree property.
>
> Signed-off-by: Aditya Gupta <adityag@linux.ibm.com>
> ---
> hw/ppc/spapr.c | 62 ++++++++++++++++++++++++++++++++++++++++++
> include/hw/ppc/spapr.h | 2 ++
> 2 files changed, 64 insertions(+)
>
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index f3a4b4235d43..3602e5b5d18d 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -897,9 +897,27 @@ static int spapr_dt_rng(void *fdt)
> static void spapr_dt_rtas(SpaprMachineState *spapr, void *fdt)
> {
You might be able to add a spapr_dt_rtas_fadump() function
and do it there to help keep functions small?
Thanks,
Nick
> MachineState *ms = MACHINE(spapr);
> + MachineClass *mc = MACHINE_GET_CLASS(ms);
> int rtas;
> GString *hypertas = g_string_sized_new(256);
> GString *qemu_hypertas = g_string_sized_new(256);
> + uint32_t max_possible_cpus = mc->possible_cpu_arch_ids(ms)->len;
> + uint64_t fadump_cpu_state_size = 0;
> + uint16_t fadump_versions[2] = {
> + FADUMP_VERSION /* min supported version */,
> + FADUMP_VERSION /* max supported version */
> + };
> + uint32_t fadump_rgn_sizes[2][3] = {
> + {
> + cpu_to_be32(FADUMP_CPU_STATE_DATA),
> + 0, 0 /* Calculated later */
> + },
> + {
> + cpu_to_be32(FADUMP_HPTE_REGION),
> + 0, 0 /* HPTE region not implemented */
> + }
> + };
> +
> uint32_t lrdr_capacity[] = {
> 0,
> 0,
> @@ -1006,6 +1024,50 @@ static void spapr_dt_rtas(SpaprMachineState *spapr, void *fdt)
> _FDT(fdt_setprop(fdt, rtas, "ibm,lrdr-capacity",
> lrdr_capacity, sizeof(lrdr_capacity)));
>
> + /*
> + * CPU State Data contains multiple fields such as header, num_cpus and
> + * register entries
> + *
> + * Calculate the maximum CPU State Data size, according to maximum
> + * possible CPUs the QEMU VM can have
> + */
> + /* Reg save header */
> + fadump_cpu_state_size += sizeof(struct rtas_fadump_reg_save_area_header);
> +
> + /* Num_cpus */
> + fadump_cpu_state_size += sizeof(__be32);
> +
> + /* Register Entries */
> + fadump_cpu_state_size += max_possible_cpus *
> + FADUMP_NUM_PER_CPU_REGS *
> + sizeof(struct rtas_fadump_reg_entry);
> +
> + /* Set maximum size for CPU state data region */
> + assert(fadump_rgn_sizes[0][0] == cpu_to_be32(FADUMP_CPU_STATE_DATA));
> +
> + /* Upper 32 bits of size, usually 0 */
> + fadump_rgn_sizes[0][1] = cpu_to_be32(fadump_cpu_state_size >> 32);
> +
> + /* Lower 32 bits of size */
> + fadump_rgn_sizes[0][2] = cpu_to_be32(fadump_cpu_state_size & 0xffffffff);
> +
> + /* Add device tree properties required from platform for fadump */
> + _FDT((fdt_setprop(fdt, rtas, "ibm,configure-kernel-dump-version",
> + fadump_versions, sizeof(fadump_versions))));
> + _FDT((fdt_setprop(fdt, rtas, "ibm,configure-kernel-dump-sizes",
> + fadump_rgn_sizes, sizeof(fadump_rgn_sizes))));
> +
> + if (is_next_boot_fadump) {
> + struct rtas_fadump_mem_struct *fdm =
> + &fadump_metadata.registered_fdm;
> +
> + uint64_t fdm_size =
> + sizeof(struct rtas_fadump_section_header) +
> + (be16_to_cpu(fdm->header.dump_num_sections) *
> + sizeof(struct rtas_fadump_section));
> +
> + _FDT((fdt_setprop(fdt, rtas, "ibm,kernel-dump", fdm, fdm_size)));
> + }
> spapr_dt_rtas_tokens(fdt, rtas);
> }
>
> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> index 0e8002bad9e0..fa63008e57ec 100644
> --- a/include/hw/ppc/spapr.h
> +++ b/include/hw/ppc/spapr.h
> @@ -928,6 +928,8 @@ static inline uint64_t fadump_gpr_id_to_u64(uint32_t gpr_id)
> return val;
> }
>
> +extern bool is_next_boot_fadump;
> +
> struct fadump_metadata {
> bool fadump_registered;
> bool fadump_dump_active;
next prev parent reply other threads:[~2025-02-27 3:29 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-17 7:17 [PATCH 0/6] Implement Firmware Assisted Dump for PSeries Aditya Gupta
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 [this message]
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=D82WR22WF5C9.20VWJUD0Y5IPN@gmail.com \
--to=npiggin@gmail.com \
--cc=adityag@linux.ibm.com \
--cc=danielhb413@gmail.com \
--cc=harshpb@linux.ibm.com \
--cc=hbathini@linux.ibm.com \
--cc=mahesh@linux.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.