On 05/03/25 12:53, Harsh Prateek Bora wrote:
On 2/17/25 12:47, Aditya Gupta wrote:
<...snip...>
+ case FADUMP_CPU_STATE_DATA: {
+ struct rtas_fadump_reg_save_area_header reg_save_hdr;
+ struct rtas_fadump_reg_entry **reg_entries;
+ struct rtas_fadump_r
On 2/17/25 12:47, Aditya Gupta wrote:
Kernel expects CPU states/register states in the format mentioned in
"Register Save Area" in PAPR.
The platform (in our case, QEMU) saves each CPU register in the form of
an array of "register entries", the start and end of this array is
signified by "CPU
On 27/02/25 08:57, Nicholas Piggin wrote:
On Mon Feb 17, 2025 at 5:17 PM AEST, Aditya Gupta wrote:
<...snip...>
diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
index 9b29cadab2c9..0aca4270aee8 100644
<...snip...>
--- a/hw/ppc/spapr_rtas.c
+++ b/hw/ppc/spapr_rtas.c
@@ -413,9 +416,174 @@ s
On Mon Feb 17, 2025 at 5:17 PM AEST, Aditya Gupta wrote:
> Kernel expects CPU states/register states in the format mentioned in
> "Register Save Area" in PAPR.
>
> The platform (in our case, QEMU) saves each CPU register in the form of
> an array of "register entries", the start and end of this arr
Kernel expects CPU states/register states in the format mentioned in
"Register Save Area" in PAPR.
The platform (in our case, QEMU) saves each CPU register in the form of
an array of "register entries", the start and end of this array is
signified by "CPUSTRT" and "CPUEND" register entries respect
