diff options
author | Sean Christopherson <seanjc@google.com> | 2020-12-31 01:26:54 +0100 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2021-02-04 11:27:31 +0100 |
commit | aec511ad153556640fb1de38bfe00c69464f997f (patch) | |
tree | f73e71a4eec80d878271ae95924d6866a067fb8e /arch/x86/kernel/reboot.c | |
parent | KVM: x86: use static calls to reduce kvm_x86_ops overhead (diff) | |
download | linux-aec511ad153556640fb1de38bfe00c69464f997f.tar.xz linux-aec511ad153556640fb1de38bfe00c69464f997f.zip |
x86/virt: Eat faults on VMXOFF in reboot flows
Silently ignore all faults on VMXOFF in the reboot flows as such faults
are all but guaranteed to be due to the CPU not being in VMX root.
Because (a) VMXOFF may be executed in NMI context, e.g. after VMXOFF but
before CR4.VMXE is cleared, (b) there's no way to query the CPU's VMX
state without faulting, and (c) the whole point is to get out of VMX
root, eating faults is the simplest way to achieve the desired behaior.
Technically, VMXOFF can fault (or fail) for other reasons, but all other
fault and failure scenarios are mode related, i.e. the kernel would have
to magically end up in RM, V86, compat mode, at CPL>0, or running with
the SMI Transfer Monitor active. The kernel is beyond hosed if any of
those scenarios are encountered; trying to do something fancy in the
error path to handle them cleanly is pointless.
Fixes: 1e9931146c74 ("x86: asm/virtext.h: add cpu_vmxoff() inline function")
Reported-by: David P. Reed <dpreed@deepplum.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20201231002702.2223707-2-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'arch/x86/kernel/reboot.c')
0 files changed, 0 insertions, 0 deletions