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

[Shivang Upadhyay <shivangu@linux.ibm.com>]

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@gmail.com>
> 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.

Thanks.
~Shivang.