On 9/22/26 2:48 PM, Philippe Mathieu-Daudé wrote:
On 2026-09-22 13:16, Janosch Frank wrote:
On 9/22/26 10:56 AM, Philippe Mathieu-Daudé wrote:
Hi,
(old patch committed as 59181010a2ff82c3a97e9b5768ee87c38e4815f1)
On 2020-03-19 14:19, Janosch Frank wrote:
Handling of CPU reset and setting of the IPL psw from guest storage at
offset 0 is done by a Ultravisor call. Let's only fetch it if
necessary.
Signed-off-by: Janosch Frank <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Reviewed-by: Christian Borntraeger <[email protected]>
Reviewed-by: Claudio Imbrenda <[email protected]>
Reviewed-by: Cornelia Huck <[email protected]>
---
target/s390x/cpu.c | 26 +++++++++++++++++---------
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c
index 961e3ebdc530cfab..71a0c9b3e55d0cbf 100644
--- a/target/s390x/cpu.c
+++ b/target/s390x/cpu.c
@@ -77,16 +77,24 @@ static bool s390_cpu_has_work(CPUState *cs)
static void s390_cpu_load_normal(CPUState *s)
{
S390CPU *cpu = S390_CPU(s);
- uint64_t spsw = ldq_phys(s->as, 0);
-
- cpu->env.psw.mask = spsw & PSW_MASK_SHORT_CTRL;
- /*
- * Invert short psw indication, so SIE will report a specification
- * exception if it was not set.
- */
- cpu->env.psw.mask ^= PSW_MASK_SHORTPSW;
- cpu->env.psw.addr = spsw & PSW_MASK_SHORT_ADDR;
+ uint64_t spsw;
+ if (!s390_is_pv()) {
+ spsw = ldq_phys(s->as, 0);
+ cpu->env.psw.mask = spsw & PSW_MASK_SHORT_CTRL;
+ /*
+ * Invert short psw indication, so SIE will report a
specification
+ * exception if it was not set.
+ */
+ cpu->env.psw.mask ^= PSW_MASK_SHORTPSW;
+ 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.
+ */
+ s390_cpu_set_state(S390_CPU_STATE_LOAD, cpu);
S390_CPU_STATE_LOAD is overwritten the line above, is that deliberate?
Yes.
LOAD is a superset of OPERATING and doing a second OPERATING is
therefore a NOP.
The load isn't a real state in KVM, we only use it for the UV call.
So we have to do a second change into OPERATING for KVM to track the
state if we were in stopped state.
Oh OK now I see the KVM_SET_MP_STATE calls. Since it was not obvious
to me, could the comment be updated to clarify that? (no obligation,
feel free to disregard if you find it clear enough for you).
Thanks for the quick head-up!
Sure, I'll extend the comment.
