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. This version was suggested by David Hildenbrand on v3 [1], where we examine the target vcpu for a pending STOP/RESTART IRQ while processing a SIGP order in-kernel, and returning the CC2 if one is in-flight. Unlike v2-v4 of this RFC, this solution requires no changes to userspace to exploit a new interface, but a small change is made on the QEMU side to keep the sequence of events in checks. Thoughts? [1] https://lore.kernel.org/r/858e4f2b-d601-a4f1-9e80-8f7838299c9a@xxxxxxxxxx/ 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/ v4: https://lore.kernel.org/r/20211119213707.2363945-1-farman@xxxxxxxxxxxxx/ Eric Farman (1): KVM: s390: Clarify SIGP orders versus STOP/RESTART arch/s390/kvm/interrupt.c | 7 +++++++ arch/s390/kvm/kvm-s390.c | 9 +++++++-- arch/s390/kvm/kvm-s390.h | 1 + arch/s390/kvm/sigp.c | 28 ++++++++++++++++++++++++++++ 4 files changed, 43 insertions(+), 2 deletions(-) -- 2.32.0
