From: Michael Roth <redacted>

Generally access to MSR_AMD64_SEV is only safe if the 0x8000001F CPUID
leaf indicates SEV support. With SEV-SNP, CPUID responses from the
hypervisor are not considered trustworthy, particularly for 0x8000001F.
SEV-SNP provides a firmware-validated CPUID table to use as an
alternative, but prior to checking MSR_AMD64_SEV there are no
guarantees that this is even an SEV-SNP guest.

Rather than relying on these CPUID values early on, allow SEV-ES and
SEV-SNP guests to instead use a cpuid instruction to trigger a #VC and
have it cache MSR_AMD64_SEV in sev_status, since it is known to be safe
to access MSR_AMD64_SEV if a #VC has triggered.

Signed-off-by: Michael Roth <redacted>
Signed-off-by: Brijesh Singh <redacted>
---
 arch/x86/kernel/sev-shared.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/x86/kernel/sev-shared.c b/arch/x86/kernel/sev-shared.c
index 8ee27d07c1cd..2796c524d174 100644
--- a/arch/x86/kernel/sev-shared.c
+++ b/arch/x86/kernel/sev-shared.c

@@ -191,6 +191,20 @@ void __init do_vc_no_ghcb(struct pt_regs *regs, unsigned long exit_code)
 	if (exit_code != SVM_EXIT_CPUID)
 		goto fail;
 
+	/*
+	 * A #VC implies that either SEV-ES or SEV-SNP are enabled, so the SEV
+	 * MSR is also available. Go ahead and initialize sev_status here to
+	 * allow SEV features to be checked without relying solely on the SEV
+	 * cpuid bit to indicate whether it is safe to do so.
+	 */
+	if (!sev_status) {
+		unsigned long lo, hi;
+
+		asm volatile("rdmsr" : "=a" (lo), "=d" (hi)
+				     : "c" (MSR_AMD64_SEV));
+		sev_status = (hi << 32) | lo;
+	}
+
 	sev_es_wr_ghcb_msr(GHCB_CPUID_REQ(fn, GHCB_CPUID_REQ_EAX));
 	VMGEXIT();
 	val = sev_es_rd_ghcb_msr();

-- 
2.25.1