aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/export-to-sqlite.py
diff options
context:
space:
mode:
authorEric Farman <[email protected]>2021-12-13 22:05:50 +0100
committerChristian Borntraeger <[email protected]>2021-12-17 14:52:47 +0100
commit812de04661c4daa7ac385c0dfd62594540538034 (patch)
tree07fa0f43cd2559ffffe0773bc67de4713da9abdf /tools/perf/scripts/python/export-to-sqlite.py
parent3c724f1a1caaee40c99422e22e22133e1496ffc3 (diff)
KVM: s390: Clarify SIGP orders versus STOP/RESTART
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: [email protected] Suggested-by: David Hildenbrand <[email protected]> Signed-off-by: Eric Farman <[email protected]> Reviewed-by: Christian Borntraeger <[email protected]> Acked-by: David Hildenbrand <[email protected]> Link: https://lore.kernel.org/r/[email protected] [[email protected]: add stable tag] Signed-off-by: Christian Borntraeger <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/export-to-sqlite.py')
0 files changed, 0 insertions, 0 deletions