aboutsummaryrefslogtreecommitdiffstats
path: root/tools/testing/selftests/net/lib/py/utils.py
diff options
context:
space:
mode:
authorSean Christopherson <[email protected]>2025-02-24 17:41:56 +0000
committerSean Christopherson <[email protected]>2025-02-28 23:43:18 +0000
commit2a289aed3fcd7fdd6d5c8def0f992d31a0754094 (patch)
tree43ab18fbf26ef73df7141b2b2bb9d04069485ff2 /tools/testing/selftests/net/lib/py/utils.py
parentKVM: x86: Use a dedicated flow for queueing re-injected exceptions (diff)
downloadkernel-2a289aed3fcd7fdd6d5c8def0f992d31a0754094.tar.gz
kernel-2a289aed3fcd7fdd6d5c8def0f992d31a0754094.zip
KVM: x86: Always set mp_state to RUNNABLE on wakeup from HLT
When emulating HLT and a wake event is already pending, explicitly mark the vCPU RUNNABLE (via kvm_set_mp_state()) instead of assuming the vCPU is already in the appropriate state. Barring a KVM bug, it should be impossible for the vCPU to be in a non-RUNNABLE state, but there is no advantage to relying on that to hold true, and ensuring the vCPU is made RUNNABLE avoids non-deterministic behavior with respect to pv_unhalted. E.g. if the vCPU is not already RUNNABLE, then depending on when pv_unhalted is set, KVM could either leave the vCPU in the non-RUNNABLE state (set before __kvm_emulate_halt()), or transition the vCPU to HALTED and then RUNNABLE (pv_unhalted set after the kvm_vcpu_has_events() check). Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]>
Diffstat (limited to 'tools/testing/selftests/net/lib/py/utils.py')
0 files changed, 0 insertions, 0 deletions