From: Janosch Frank <[email protected]> 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 <[email protected]> Reviewed-by: Eric Farman <[email protected]> Reviewed-by: Matthew Rosato <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Message-ID: <[email protected]> Signed-off-by: Philippe Mathieu-Daudé <[email protected]> --- 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 c938c77d0bd..f12ef1bd1cc 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
