Re: [PATCH v2] pseries/kexec: skip resetting CPUs added by firmware but not started by the kernel

On 07/04/26 15:49, Shivang Upadhyay wrote:

Hi,
Thanks for your review.

On Mon, 2026-04-06 at 14:22 +0530, Vishal Chourasia wrote:

quoted

Hi Shivang,

Thanks for working on this issue.
A few questions and concerns about the approach:

1. Was this issue only observed with QEMU-based virtualization, or
does
it also reproduce on PowerVM/phyp? The commit message and sample logs
don't clarify this. If this is QEMU-specific, I think we should fix
this
in QEMU rather than working around it in the kernel.

Currently this is only happening in Qemu (both tcg and kvm mode). But I
think this should be reproducible on phyp also. Ill confirm wheather it
is really the case or not.

quoted

2. The approach taken here moves away from the PAPR interface. The
kernel currently uses H_SIGNAL_SYS_RESET_ALL_OTHERS, which is the
architecturally defined hcall for this purpose. Replacing it with a
per-CPU loop that checks internal kernel state (paca cpu_start)
breaks
the clean abstraction between guest and
QEMU's sPAPR implementation should behave the same way. The
hypervisor

Yeah it is a valid concern about ownership for this resets. Ill try to
see if this fix is possible in qemu itself.

quoted

(QEMU) should maintain a list of CPUs that have been
activated/online/started and given to the guest. When
H_SIGNAL_SYS_RESET_ALL_OTHERS is called, QEMU should only reset those
CPUs that the guest has actually started. Unless the guest makes the
RTAS start-cpu call for a CPU, QEMU should not include that CPU in
the
set of CPUs to be reset.

I think discussing this would help determine the right fix location.

Can you refer to the following commit in QEMU to see if help in this
case.

commit fb802acdc8b162084e9e60d42aeba79097d14d2b
Author: Nicholas Piggin [off-list ref]
Date:   Tue Mar 18 15:03:48 2025 +1000

      ppc/spapr: Fix RTAS stopped state

Thanks for this reference. cpu->quiesced state was introduced in this
patch, for modelling "RTAS stopped" state.

as per the commit message:
A KVM spapr guest boots with all secondary CPUs defined to be in the
RTAS stopped" state. In this state, the CPU is only responsive to the
start-cpu RTAS call.

So, we should be able to use this to check wheather cpu is started or
not. Only other concern here would be about phyp's implementation for
this.

Yes, something like this.

diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c

index 032805a8d0..8c51372cf8 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c

@@ -1105,6 +1105,9 @@ static target_ulong h_signal_sys_reset(PowerPCCPU *cpu,

                     continue;
                 }
             }
+
+            if (c->env.quiesced) continue;
+
             run_on_cpu(cs, spapr_do_system_reset_on_cpu, RUN_ON_CPU_NULL);
         }
         return H_SUCCESS;

Thanks.
~Shivang.