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

[Vishal Chourasia <vishalc@linux.ibm.com>]

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

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.
>
>
>