All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
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>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Peter Gonda <pgonda@google.com>,
	Brijesh Singh <brijesh.singh@amd.com>,
	Tom Lendacky <thomas.lendacky@amd.com>
Subject: [PATCH 1/2] Revert "KVM: x86: Truncate reported guest MAXPHYADDR to C-bit if SEV is supported"
Date: Thu, 24 Jun 2021 19:03:53 -0700	[thread overview]
Message-ID: <20210625020354.431829-2-seanjc@google.com> (raw)
In-Reply-To: <20210625020354.431829-1-seanjc@google.com>

It turns out that non-SEV guest can indeed use bit 47, and the unexpected
reserved #PF observed when setting bit 47 is due to a magic 12gb
HyperTransport region being off limits, even for GPAs.  Per Tom:

  I think you may be hitting a special HT region that is at the top 12GB
  of the 48-bit memory range and is reserved, even for GPAs.  Can you
  somehow get the test to use an address below 0xfffd_0000_0000? That
  would show that bit 47 is valid for the legacy guest while staying out
  of the HT region.

And indeed, accessing 0xfffd00000000 generates a reserved #PF, while
dropping down a single page to 0xfffcfffff000 does not.

This reverts commit 3675f005c87c4026713c9f863924de511fdd36c4.

Cc: Peter Gonda <pgonda@google.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kvm/cpuid.c   | 11 -----------
 arch/x86/kvm/svm/svm.c | 37 ++++++++-----------------------------
 arch/x86/kvm/x86.c     |  3 ---
 arch/x86/kvm/x86.h     |  1 -
 4 files changed, 8 insertions(+), 44 deletions(-)

diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 0edda1fc4fe7..ca7866d63e98 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -955,17 +955,6 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array *array, u32 function)
 		else if (!g_phys_as)
 			g_phys_as = phys_as;
 
-		/*
-		 * The exception to the exception is if hardware supports SEV,
-		 * in which case the C-bit is reserved for non-SEV guests and
-		 * isn't a GPA bit for SEV guests.
-		 *
-		 * Note, KVM always reports '0' for the number of reduced PA
-		 * bits (see 0x8000001F).
-		 */
-		if (tdp_enabled && sev_c_bit)
-			g_phys_as = min(g_phys_as, (unsigned int)sev_c_bit);
-
 		entry->eax = g_phys_as | (virt_as << 8);
 		entry->edx = 0;
 		cpuid_entry_override(entry, CPUID_8000_0008_EBX);
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 616b9679ddcc..8834822c00cd 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -860,26 +860,6 @@ static void shrink_ple_window(struct kvm_vcpu *vcpu)
 	}
 }
 
-static __init u8 svm_get_c_bit(bool sev_only)
-{
-	unsigned int eax, ebx, ecx, edx;
-	u64 msr;
-
-	if (cpuid_eax(0x80000000) < 0x8000001f)
-		return 0;
-
-	if (rdmsrl_safe(MSR_AMD64_SYSCFG, &msr) ||
-	    !(msr & MSR_AMD64_SYSCFG_MEM_ENCRYPT))
-		return 0;
-
-	cpuid(0x8000001f, &eax, &ebx, &ecx, &edx);
-
-	if (sev_only && !(eax & feature_bit(SEV)))
-		return 0;
-
-	return ebx & 0x3f;
-}
-
 /*
  * The default MMIO mask is a single bit (excluding the present bit),
  * which could conflict with the memory encryption bit. Check for
@@ -889,13 +869,18 @@ static __init u8 svm_get_c_bit(bool sev_only)
 static __init void svm_adjust_mmio_mask(void)
 {
 	unsigned int enc_bit, mask_bit;
-	u64 mask;
+	u64 msr, mask;
+
+	/* If there is no memory encryption support, use existing mask */
+	if (cpuid_eax(0x80000000) < 0x8000001f)
+		return;
 
 	/* If memory encryption is not enabled, use existing mask */
-	enc_bit = svm_get_c_bit(false);
-	if (!enc_bit)
+	rdmsrl(MSR_AMD64_SYSCFG, msr);
+	if (!(msr & MSR_AMD64_SYSCFG_MEM_ENCRYPT))
 		return;
 
+	enc_bit = cpuid_ebx(0x8000001f) & 0x3f;
 	mask_bit = boot_cpu_data.x86_phys_bits;
 
 	/* Increment the mask bit if it is the same as the encryption bit */
@@ -1028,12 +1013,6 @@ static __init int svm_hardware_setup(void)
 	kvm_configure_mmu(npt_enabled, get_max_npt_level(), PG_LEVEL_1G);
 	pr_info("kvm: Nested Paging %sabled\n", npt_enabled ? "en" : "dis");
 
-	/*
-	 * The SEV C-bit location is needed to correctly enumeration guest
-	 * MAXPHYADDR even if SEV is not fully supported.
-	 */
-	sev_c_bit = svm_get_c_bit(true);
-
 	/* Note, SEV setup consumes npt_enabled. */
 	sev_hardware_setup();
 
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 4a597aafe637..13905ef5bb48 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -209,9 +209,6 @@ static struct kvm_user_return_msrs __percpu *user_return_msrs;
 				| XFEATURE_MASK_BNDCSR | XFEATURE_MASK_AVX512 \
 				| XFEATURE_MASK_PKRU)
 
-u8 __read_mostly sev_c_bit;
-EXPORT_SYMBOL_GPL(sev_c_bit);
-
 u64 __read_mostly host_efer;
 EXPORT_SYMBOL_GPL(host_efer);
 
diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
index bc3f5c9e3708..44ae10312740 100644
--- a/arch/x86/kvm/x86.h
+++ b/arch/x86/kvm/x86.h
@@ -328,7 +328,6 @@ extern u64 host_xcr0;
 extern u64 supported_xcr0;
 extern u64 host_xss;
 extern u64 supported_xss;
-extern u8  sev_c_bit;
 
 static inline bool kvm_mpx_supported(void)
 {
-- 
2.32.0.93.g670b81a890-goog


  reply	other threads:[~2021-06-25  2:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-25  2:03 [PATCH 0/2] KVM: SVM: Final C-bit fixes? Sean Christopherson
2021-06-25  2:03 ` Sean Christopherson [this message]
2021-06-25 13:28   ` [PATCH 1/2] Revert "KVM: x86: Truncate reported guest MAXPHYADDR to C-bit if SEV is supported" Tom Lendacky
2021-06-25  2:03 ` [PATCH 2/2] KVM: SVM: Revert clearing of C-bit on GPA in #NPF handler Sean Christopherson
2021-06-25 13:26   ` Tom Lendacky
2021-07-08 16:30 ` [PATCH 0/2] KVM: SVM: Final C-bit fixes? 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=20210625020354.431829-2-seanjc@google.com \
    --to=seanjc@google.com \
    --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=pbonzini@redhat.com \
    --cc=pgonda@google.com \
    --cc=thomas.lendacky@amd.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.