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

[Anushree Mathur]

On 07/04/26 3:55 PM, Vishal Chourasia wrote:
> 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 at 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.
>>
>> Hi Vishal/Shivang,
>>
>> I have tested this qemu patch mentioned here, after applying this the 
>> issue is getting fixed.
>>
>> Thank you!
>> Anushree Mathur
>>