mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tom Lendacky <thomas.lendacky@amd.com>
To: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	Sean Christopherson <sean.j.christopherson@intel.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Brijesh Singh <brijesh.singh@amd.com>
Subject: [PATCH v4 20/34] KVM: SVM: Add support for EFER write traps for an SEV-ES guest
Date: Tue, 17 Nov 2020 11:07:23 -0600	[thread overview]
Message-ID: <d8a0d7b0d6f032bc0c0ae80d979f500b66efb332.1605632857.git.thomas.lendacky@amd.com> (raw)
In-Reply-To: <cover.1605632857.git.thomas.lendacky@amd.com>

From: Tom Lendacky <thomas.lendacky@amd.com>

For SEV-ES guests, the interception of EFER write access is not
recommended. EFER interception occurs prior to EFER being modified and
the hypervisor is unable to modify EFER itself because the register is
located in the encrypted register state.

SEV-ES support introduces a new EFER write trap. This trap provides
intercept support of an EFER write after it has been modified. The new
EFER value is provided in the VMCB EXITINFO1 field, allowing the
hypervisor to track the setting of the guest EFER.

Add support to track the value of the guest EFER value using the EFER
write trap so that the hypervisor understands the guest operating mode.

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
 arch/x86/include/uapi/asm/svm.h |  2 ++
 arch/x86/kvm/svm/svm.c          | 20 ++++++++++++++++++++
 2 files changed, 22 insertions(+)

diff --git a/arch/x86/include/uapi/asm/svm.h b/arch/x86/include/uapi/asm/svm.h
index 09f723945425..6e3f92e17655 100644
--- a/arch/x86/include/uapi/asm/svm.h
+++ b/arch/x86/include/uapi/asm/svm.h
@@ -77,6 +77,7 @@
 #define SVM_EXIT_MWAIT_COND    0x08c
 #define SVM_EXIT_XSETBV        0x08d
 #define SVM_EXIT_RDPRU         0x08e
+#define SVM_EXIT_EFER_WRITE_TRAP		0x08f
 #define SVM_EXIT_INVPCID       0x0a2
 #define SVM_EXIT_NPF           0x400
 #define SVM_EXIT_AVIC_INCOMPLETE_IPI		0x401
@@ -184,6 +185,7 @@
 	{ SVM_EXIT_MONITOR,     "monitor" }, \
 	{ SVM_EXIT_MWAIT,       "mwait" }, \
 	{ SVM_EXIT_XSETBV,      "xsetbv" }, \
+	{ SVM_EXIT_EFER_WRITE_TRAP,	"write_efer_trap" }, \
 	{ SVM_EXIT_INVPCID,     "invpcid" }, \
 	{ SVM_EXIT_NPF,         "npf" }, \
 	{ SVM_EXIT_AVIC_INCOMPLETE_IPI,		"avic_incomplete_ipi" }, \
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 02a8035dd6b2..f840e3a3ee45 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -2519,6 +2519,25 @@ static int cr8_write_interception(struct vcpu_svm *svm)
 	return 0;
 }
 
+static int efer_trap(struct vcpu_svm *svm)
+{
+	struct msr_data msr_info;
+	int ret;
+
+	/*
+	 * Clear the EFER_SVME bit from EFER. The SVM code always sets this
+	 * bit in svm_set_efer(), but __kvm_valid_efer() checks it against
+	 * whether the guest has X86_FEATURE_SVM - this avoids a failure if
+	 * the guest doesn't have X86_FEATURE_SVM.
+	 */
+	msr_info.host_initiated = false;
+	msr_info.index = MSR_EFER;
+	msr_info.data = svm->vmcb->control.exit_info_1 & ~EFER_SVME;
+	ret = kvm_set_msr_common(&svm->vcpu, &msr_info);
+
+	return kvm_complete_insn_gp(&svm->vcpu, ret);
+}
+
 static int svm_get_msr_feature(struct kvm_msr_entry *msr)
 {
 	msr->data = 0;
@@ -3027,6 +3046,7 @@ static int (*const svm_exit_handlers[])(struct vcpu_svm *svm) = {
 	[SVM_EXIT_MWAIT]			= mwait_interception,
 	[SVM_EXIT_XSETBV]			= xsetbv_interception,
 	[SVM_EXIT_RDPRU]			= rdpru_interception,
+	[SVM_EXIT_EFER_WRITE_TRAP]		= efer_trap,
 	[SVM_EXIT_INVPCID]                      = invpcid_interception,
 	[SVM_EXIT_NPF]				= npf_interception,
 	[SVM_EXIT_RSM]                          = rsm_interception,
-- 
2.28.0


  parent reply	other threads:[~2020-11-17 17:10 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-17 17:07 [PATCH v4 00/34] SEV-ES hypervisor support Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 01/34] x86/cpu: Add VM page flush MSR availablility as a CPUID feature Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 02/34] KVM: SVM: Remove the call to sev_platform_status() during setup Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 03/34] KVM: SVM: Add support for SEV-ES capability in KVM Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 04/34] KVM: SVM: Add GHCB accessor functions for retrieving fields Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 05/34] KVM: SVM: Add support for the SEV-ES VMSA Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 06/34] KVM: x86: Mark GPRs dirty when written Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 07/34] KVM: SVM: Add required changes to support intercepts under SEV-ES Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 08/34] KVM: SVM: Prevent debugging " Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 09/34] KVM: SVM: Do not allow instruction emulation " Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 10/34] KVM: SVM: Cannot re-initialize the VMCB after shutdown with SEV-ES Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 11/34] KVM: SVM: Prepare for SEV-ES exit handling in the sev.c file Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 12/34] KVM: SVM: Add initial support for a VMGEXIT VMEXIT Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 13/34] KVM: SVM: Create trace events for VMGEXIT processing Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 14/34] KVM: SVM: Add support for SEV-ES GHCB MSR protocol function 0x002 Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 15/34] KVM: SVM: Add support for SEV-ES GHCB MSR protocol function 0x004 Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 16/34] KVM: SVM: Add support for SEV-ES GHCB MSR protocol function 0x100 Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 17/34] KVM: SVM: Create trace events for VMGEXIT MSR protocol processing Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 18/34] KVM: SVM: Support MMIO for an SEV-ES guest Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 19/34] KVM: SVM: Support string IO operations " Tom Lendacky
2020-11-17 17:07 ` Tom Lendacky [this message]
2020-11-17 17:07 ` [PATCH v4 21/34] KVM: SVM: Add support for CR0 write traps " Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 22/34] KVM: SVM: Add support for CR4 " Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 23/34] KVM: SVM: Add support for CR8 " Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 24/34] KVM: x86: Update __get_sregs() / __set_sregs() to support SEV-ES Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 25/34] KVM: SVM: Do not report support for SMM for an SEV-ES guest Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 26/34] KVM: SVM: Guest FPU state save/restore not needed for " Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 27/34] KVM: SVM: Add support for booting APs for an " Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 28/34] KVM: SVM: Add NMI support " Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 29/34] KVM: SVM: Set the encryption mask for the SVM host save area Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 30/34] KVM: SVM: Update ASID allocation to support SEV-ES guests Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 31/34] KVM: SVM: Provide support for SEV-ES vCPU creation/loading Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 32/34] KVM: SVM: Provide support for SEV-ES vCPU loading Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 33/34] KVM: SVM: Provide an updated VMRUN invocation for SEV-ES guests Tom Lendacky
2020-11-17 17:07 ` [PATCH v4 34/34] KVM: SVM: Provide support to launch and run an SEV-ES guest Tom Lendacky
2020-11-23 16:52 ` [PATCH v4 00/34] SEV-ES hypervisor support Tom Lendacky
2020-11-24 18:52   ` Sean Christopherson
2020-11-25 15:25     ` Tom Lendacky

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=d8a0d7b0d6f032bc0c0ae80d979f500b66efb332.1605632857.git.thomas.lendacky@amd.com \
    --to=thomas.lendacky@amd.com \
    --cc=bp@alien8.de \
    --cc=brijesh.singh@amd.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=sean.j.christopherson@intel.com \
    --cc=tglx@linutronix.de \
    --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®