On 09.02.21 15:15, Janosch Frank wrote:
KVM and QEMU handle a SIGP stop and store status in two steps:
1) Stop the CPU by injecting a stop request
2) Store when the CPU has left SIE because of the stop request
The problem is that the SIGP order is already considered completed by
KVM/QEMU when step 1 has been performed and not once both have
completed. In addition we currently don't implement the busy CC so a
QEMU remembers that stop-and-store-status is active in
"cpu->env.sigp_order" and rejects other orders until completed with
SIGP_CC_BUSY. See handle_sigp_single_dst().
The "issue" is that the kernel does not know about that. The kernel will
continue handling
- SIGP_SENSE
- SIGP_EXTERNAL_CALL
- SIGP_EMERGENCY_SIGNAL
- SIGP_COND_EMERGENCY_SIGNAL
- SIGP_SENSE_RUNNING
itself and not go to user space where that information is present. And
for some of these orders we really don't want to go to user space.
I remember that at least SIGP_SENSE_RUNNING doesn't give any guarantees,
so that one might be correct.
I remember that it was a little unclear if all of these orders actually
have to wait for other orders to finish (IOW: return SIGP_CC_BUSY).
Especially with SIGPIF even the hardware has no idea if we are emulating
a SIGP STOP .* right now, how should it know? We would have to disable
the facility, and that's most probably not what the HW/facility was
designed for.
Yeah, it's complicated. We would have to let QEMU "set" and "clear" a
SIGP busy status in the kernel. Then we could at least let SIGP SENSE be
correct and fast (I think that's the only critical one to get right).
--
Thanks,
David / dhildenb
