]> git.proxmox.com Git - mirror_ubuntu-jammy-kernel.git/commit - arch/s390/kvm/interrupt.c
KVM: s390: Clarify SIGP orders versus STOP/RESTART
authorEric Farman <farman@linux.ibm.com>
Mon, 13 Dec 2021 21:05:50 +0000 (22:05 +0100)
committerPaolo Pisati <paolo.pisati@canonical.com>
Tue, 25 Jan 2022 11:05:31 +0000 (12:05 +0100)
commit22c62377c6aec9be729eb9ad912ad6564e2ba64f
tree803863d73bd580d42e2dda33043f46061d7e946d
parenta77472f148620436b6009c8ba454893b80263b59
KVM: s390: Clarify SIGP orders versus STOP/RESTART

BugLink: https://bugs.launchpad.net/bugs/1958977
commit 812de04661c4daa7ac385c0dfd62594540538034 upstream.

With KVM_CAP_S390_USER_SIGP, there are only five Signal Processor
orders (CONDITIONAL EMERGENCY SIGNAL, EMERGENCY SIGNAL, EXTERNAL CALL,
SENSE, and SENSE RUNNING STATUS) which are intended for frequent use
and thus are processed in-kernel. The remainder are sent to userspace
with the KVM_CAP_S390_USER_SIGP capability. Of those, three orders
(RESTART, STOP, and STOP AND STORE STATUS) have the potential to
inject work back into the kernel, and thus are asynchronous.

Let's look for those pending IRQs when processing one of the in-kernel
SIGP orders, and return BUSY (CC2) if one is in process. This is in
agreement with the Principles of Operation, which states that only one
order can be "active" on a CPU at a time.

Cc: stable@vger.kernel.org
Suggested-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Eric Farman <farman@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Acked-by: David Hildenbrand <david@redhat.com>
Link: https://lore.kernel.org/r/20211213210550.856213-2-farman@linux.ibm.com
[borntraeger@linux.ibm.com: add stable tag]
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
arch/s390/kvm/interrupt.c
arch/s390/kvm/kvm-s390.c
arch/s390/kvm/kvm-s390.h
arch/s390/kvm/sigp.c