Avi Kivity wrote:
So why not do it for this instruction as well? Instead of updating the
psw, return a success/error code and let the kernel update psw.
It's not a single instruction, but a set of reasons we need the psw in
userspace:
- for logging the instruction address on exits
- to check if a wait-type psw is active, and if so to switch between:
- enabled wait psws, where interrupts could wake the cpu (aka
/halt, which needs to be handled in-kernel)
- disabled wait psws, where CPUs are suspended due to cpu
hotremove, system dump on panic
- to handle cpus in stopped state, typically on regular
reboots/shutdowns
- for setting the condition code during implementation of:
- all s/390 I/O instructions
- IPI for restarting remote CPUs (that are not in KVM_RUN)
- IPI for storing remote CPU status into the remote cpu's lowcore page
- IPI for resetting remote CPUs
- for all IPIs where the remote CPU is not known to the kernel, such
as the detection loop for all 65535 cpu slots on startup of the
guest kernel
- for interpretion of service calls (usually to the machine's service
processor)
- virtio I/O
The sweet thing about having the psw in userspace is that for almost all
above reasons, there's nothing more than the psw that we need to have in
order to perform that operation. Giving the 128-bit psw to userspace
does simply save us having special cases for above list, with an
exit_reason and a struct for each of them.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
