Here is an update to the handling of SIGP between kernel and userspace. As before, I'm looking at problems encountered when a SIGP order that is processed in the kernel (for example, SIGP SENSE) is run concurrently with another one is processed in userspace (for example, SIGP STOP). Being able to provide an honest answer in the SIGP SENSE as to whether the targeted VCPU is/not stopped is important to provide a consistent answer while a guest OS is bringing its configuration online. Furthermore, there is a desire to be architecturally correct in this space, where the Principles of Operation states lists of orders that should return a CC2 (BUSY) when any of another list of orders is being processed on the targeted CPU. This version goes back to something similar to v2, in that there's only a single IOCTL created. But unlike v2, userspace handles both the "set" and "reset" sides of the equation, specifying the operations in the payload sent via the IOCTL. With this, I started considering that the kernel itself could mark the cpu busy/ready as it relates to SIGP, such that a !USER_SIGP userspace would be happy with matters too, but haven't quite gotten that working to my liking. I'll send the QEMU series shortly, which takes advantage of this. Thoughts? Previous RFCs: v1: https://lore.kernel.org/r/20211008203112.1979843-1-farman@xxxxxxxxxxxxx/ v2: https://lore.kernel.org/r/20211102194652.2685098-1-farman@xxxxxxxxxxxxx/ v3: https://lore.kernel.org/r/20211110203322.1374925-1-farman@xxxxxxxxxxxxx/ Eric Farman (2): Capability/IOCTL/Documentation KVM: s390: Introduce a USER_BUSY capability and IOCTL Documentation/virt/kvm/api.rst | 22 ++++++++++++++++++ arch/s390/include/asm/kvm_host.h | 2 ++ arch/s390/kvm/kvm-s390.c | 40 ++++++++++++++++++++++++++++++++ arch/s390/kvm/kvm-s390.h | 15 ++++++++++++ arch/s390/kvm/sigp.c | 3 +++ include/uapi/linux/kvm.h | 16 +++++++++++++ 6 files changed, 98 insertions(+) -- 2.25.1
