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

[Vishal Chourasia]

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:
> > 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.
>
> > 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.
>
> > (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 <npiggin@xxxxxxxxx>
> > 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.