From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
x86@kernel.org
Cc: Sean Christopherson <seanjc@google.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
"H. Peter Anvin" <hpa@zytor.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
"David P . Reed" <dpreed@deepplum.com>,
Randy Dunlap <rdunlap@infradead.org>,
Uros Bizjak <ubizjak@gmail.com>
Subject: [PATCH 1/9] x86/virt: Eat faults on VMXOFF in reboot flows
Date: Wed, 30 Dec 2020 16:26:54 -0800 [thread overview]
Message-ID: <20201231002702.2223707-2-seanjc@google.com> (raw)
In-Reply-To: <20201231002702.2223707-1-seanjc@google.com>
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>
---
arch/x86/include/asm/virtext.h | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/arch/x86/include/asm/virtext.h b/arch/x86/include/asm/virtext.h
index 9aad0e0876fb..fda3e7747c22 100644
--- a/arch/x86/include/asm/virtext.h
+++ b/arch/x86/include/asm/virtext.h
@@ -30,15 +30,22 @@ static inline int cpu_has_vmx(void)
}
-/** Disable VMX on the current CPU
+/**
+ * cpu_vmxoff() - Disable VMX on the current CPU
*
- * vmxoff causes a undefined-opcode exception if vmxon was not run
- * on the CPU previously. Only call this function if you know VMX
- * is enabled.
+ * Disable VMX and clear CR4.VMXE (even if VMXOFF faults)
+ *
+ * Note, VMXOFF causes a #UD if the CPU is !post-VMXON, but it's impossible to
+ * atomically track post-VMXON state, e.g. this may be called in NMI context.
+ * Eat all faults as all other faults on VMXOFF faults are mode related, i.e.
+ * faults are guaranteed to be due to the !post-VMXON check unless the CPU is
+ * magically in RM, VM86, compat mode, or at CPL>0.
*/
static inline void cpu_vmxoff(void)
{
- asm volatile ("vmxoff");
+ asm_volatile_goto("1: vmxoff\n\t"
+ _ASM_EXTABLE(1b, %l[fault]) :::: fault);
+fault:
cr4_clear_bits(X86_CR4_VMXE);
}
--
2.29.2.729.g45daf8777d-goog
next prev parent reply other threads:[~2020-12-31 0:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-31 0:26 [PATCH 0/9] x86/virt: KVM: x86: Exception handling fixes/cleanups Sean Christopherson
2020-12-31 0:26 ` Sean Christopherson [this message]
2020-12-31 0:26 ` [PATCH 2/9] x86/reboot: Force all cpus to exit VMX root if VMX is supported Sean Christopherson
2020-12-31 0:26 ` [PATCH 3/9] x86/virt: Mark flags and memory as clobbered by VMXOFF Sean Christopherson
2020-12-31 0:26 ` [PATCH 4/9] KVM/nVMX: Use __vmx_vcpu_run in nested_vmx_check_vmentry_hw Sean Christopherson
2020-12-31 0:26 ` [PATCH 5/9] KVM: VMX: Move Intel PT shenanigans out of VMXON/VMXOFF flows Sean Christopherson
2020-12-31 0:26 ` [PATCH 6/9] KVM: VMX: Use the kernel's version of VMXOFF Sean Christopherson
2020-12-31 0:27 ` [PATCH 7/9] KVM: SVM: Use asm goto to handle unexpected #UD on SVM instructions Sean Christopherson
2020-12-31 0:27 ` [PATCH 8/9] KVM: x86: Kill off __ex() and __kvm_handle_fault_on_reboot() Sean Christopherson
2020-12-31 0:27 ` [PATCH 9/9] KVM: x86: Move declaration of kvm_spurious_fault() to x86.h Sean Christopherson
2021-01-27 17:26 ` [PATCH 0/9] x86/virt: KVM: x86: Exception handling fixes/cleanups Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201231002702.2223707-2-seanjc@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=dpreed@deepplum.com \
--cc=hpa@zytor.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rdunlap@infradead.org \
--cc=tglx@linutronix.de \
--cc=ubizjak@gmail.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®