When implementing PV in KVM we chose to add the cpu load state to the
mp state solely to have a way to keep the UV happy. The UV requires us
to set that state before running the boot cpu since entering that
state sets the initial PSW.

Since entering that state in KVM only sets off the UV call which
causes the initial PSW load and does not set the KVM tracking to
operating, we need a second set mp state to reach operating state.

Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
---
 target/s390x/cpu-system.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/target/s390x/cpu-system.c b/target/s390x/cpu-system.c
index cc9685221a..5bd8b8d837 100644
--- a/target/s390x/cpu-system.c
+++ b/target/s390x/cpu-system.c
@@ -73,8 +73,12 @@ static void s390_cpu_load_normal(CPUState *s)
         cpu->env.psw.addr = spsw & PSW_MASK_SHORT_ADDR;
     } else {
         /*
-         * Firmware requires us to set the load state before we set
-         * the cpu to operating on protected guests.
+         * Firmware/UV requires us to set the load state before we run
+         * the cpu on (re)boots. The UV load includes operating so the
+         * second set state isn't really needed but KVM doesn't update
+         * its internal state to operating on load. So we have to set
+         * operating again. The UV doesn't mind that since it's
+         * effectively a NOP.
          */
         s390_cpu_set_state(S390_CPU_STATE_LOAD, cpu);
     }
-- 
2.53.0

On 9/23/26 4:20 AM, Janosch Frank wrote:
> When implementing PV in KVM we chose to add the cpu load state to the
> mp state solely to have a way to keep the UV happy. The UV requires us
> to set that state before running the boot cpu since entering that
> state sets the initial PSW.
> 
> Since entering that state in KVM only sets off the UV call which
> causes the initial PSW load and does not set the KVM tracking to
> operating, we need a second set mp state to reach operating state.
> 
> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>

I was puzzled that this was applying as an empty commit. Philippe 
already picked this up [*], committed as 
bb495851c6744ede99b457d50255964a61249221 yesterday

[*] 
https://lore.kernel.org/qemu-devel/20260924152353.36209-11-philmd@oss.qualcomm.com/

On 2026-09-25 14:47, Eric Farman wrote:
> 
> 
> On 9/23/26 4:20 AM, Janosch Frank wrote:
>> When implementing PV in KVM we chose to add the cpu load state to the
>> mp state solely to have a way to keep the UV happy. The UV requires us
>> to set that state before running the boot cpu since entering that
>> state sets the initial PSW.
>>
>> Since entering that state in KVM only sets off the UV call which
>> causes the initial PSW load and does not set the KVM tracking to
>> operating, we need a second set mp state to reach operating state.
>>
>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
> 
> I was puzzled that this was applying as an empty commit. Philippe 
> already picked this up [*], committed as 
> bb495851c6744ede99b457d50255964a61249221 yesterday
> 
> [*] https://lore.kernel.org/qemu-devel/20260924152353.36209-11- 
> philmd@oss.qualcomm.com/

Yep sorry I forgot to mentioned I queued this patch because it
was logically making sense in with the rest of the patches being
merged. Otherwise I rather the s390x patches go via your tree ;)

Regards,

Phil.

On 9/23/26 4:20 AM, Janosch Frank wrote:
> When implementing PV in KVM we chose to add the cpu load state to the
> mp state solely to have a way to keep the UV happy. The UV requires us
> to set that state before running the boot cpu since entering that
> state sets the initial PSW.
> 
> Since entering that state in KVM only sets off the UV call which
> causes the initial PSW load and does not set the KVM tracking to
> operating, we need a second set mp state to reach operating state.
> 
> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>

Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>

On 9/23/26 4:20 AM, Janosch Frank wrote:
> When implementing PV in KVM we chose to add the cpu load state to the
> mp state solely to have a way to keep the UV happy. The UV requires us
> to set that state before running the boot cpu since entering that
> state sets the initial PSW.
> 
> Since entering that state in KVM only sets off the UV call which
> causes the initial PSW load and does not set the KVM tracking to
> operating, we need a second set mp state to reach operating state.
> 
> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
> ---
>   target/s390x/cpu-system.c | 8 ++++++--
>   1 file changed, 6 insertions(+), 2 deletions(-)

Reviewed-by: Eric Farman <farman@linux.ibm.com>

On 23/9/26 10:20, Janosch Frank wrote:
> When implementing PV in KVM we chose to add the cpu load state to the
> mp state solely to have a way to keep the UV happy. The UV requires us
> to set that state before running the boot cpu since entering that
> state sets the initial PSW.
> 
> Since entering that state in KVM only sets off the UV call which
> causes the initial PSW load and does not set the KVM tracking to
> operating, we need a second set mp state to reach operating state.
> 
> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
> ---
>   target/s390x/cpu-system.c | 8 ++++++--
>   1 file changed, 6 insertions(+), 2 deletions(-)

Thank you!

Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>