diff options
author | KarimAllah Ahmed <karahmed@amazon.de> | 2018-04-10 15:15:46 +0300 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2018-04-10 18:19:44 +0300 |
commit | 386c6ddbda180676b7d9fc375d54a7bdd353d39e (patch) | |
tree | 6544b98c691fa8ce69940a6d03bebb3badaa120b /tools/testing/selftests/kvm | |
parent | e01bca2fc698d7f0626f0214001af523e18ad60b (diff) | |
download | linux-386c6ddbda180676b7d9fc375d54a7bdd353d39e.tar.xz |
X86/VMX: Disable VMX preemption timer if MWAIT is not intercepted
The VMX-preemption timer is used by KVM as a way to set deadlines for the
guest (i.e. timer emulation). That was safe till very recently when
capability KVM_X86_DISABLE_EXITS_MWAIT to disable intercepting MWAIT was
introduced. According to Intel SDM 25.5.1:
"""
The VMX-preemption timer operates in the C-states C0, C1, and C2; it also
operates in the shutdown and wait-for-SIPI states. If the timer counts down
to zero in any state other than the wait-for SIPI state, the logical
processor transitions to the C0 C-state and causes a VM exit; the timer
does not cause a VM exit if it counts down to zero in the wait-for-SIPI
state. The timer is not decremented in C-states deeper than C2.
"""
Now once the guest issues the MWAIT with a c-state deeper than
C2 the preemption timer will never wake it up again since it stopped
ticking! Usually this is compensated by other activities in the system that
would wake the core from the deep C-state (and cause a VMExit). For
example, if the host itself is ticking or it received interrupts, etc!
So disable the VMX-preemption timer if MWAIT is exposed to the guest!
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: kvm@vger.kernel.org
Signed-off-by: KarimAllah Ahmed <karahmed@amazon.de>
Fixes: 4d5422cea3b61f158d58924cbb43feada456ba5c
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'tools/testing/selftests/kvm')
0 files changed, 0 insertions, 0 deletions