[PATCH v3 0/2] x86/sev: Fix RMPOPT enablement on non-RMPOPT configs

[Ashish Kalra]

From: Ashish Kalra <ashish.kalra@xxxxxxx>

Two fixes for the RMPOPT series, both for configurations where the
RMPOPT CPUID bit is advertised but RMPOPT is not actually usable:

Patch 1 clears X86_FEATURE_RMPOPT when the platform advertises segmented
RMP but the firmware has it disabled (contiguous RMP) - otherwise the
RMPOPT initcall programs RMPOPT_BASE and issues RMPOPT, which #GP.

Patch 2 gates rmpopt_init() on an active SNP host, so the RMPOPT workqueue
setup and the "optimizations enabled" message only happen on an SNP host -
e.g. not when SNP is disabled in the BIOS.

v3:
 - Patch 2: gate rmpopt_init() on cc_platform_has(CC_ATTR_HOST_SEV_SNP)
   instead of the X86_FEATURE_SEV_SNP CPUID bit.  SNP can be disabled after
   feature detection (e.g. when AMD IOMMU init fails to enable it), which
   clears CC_ATTR_HOST_SEV_SNP but leaves the CPUID bit set;
   CC_ATTR_HOST_SEV_SNP reflects the final host state and matches the gate
   in snp_enable_rmpopt().

v2:
 - Patch 1: expand the commit message to spell out the CPUID-advertise vs
   firmware-enable distinction and how the configuration arises; drop the
   trailing sentence; add Tom's Reviewed-by.
 - Patch 2: rather than moving the announcement to snp_enable_rmpopt(),
   gate rmpopt_init() on an SNP host and keep the message there (Tom).

Ashish Kalra (2):
  x86/sev: Clear RMPOPT when segmented RMP is disabled by firmware
  x86/sev: Only announce RMPOPT optimizations when SNP is enabled

 arch/x86/virt/svm/sev.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)


base-commit: 250ee734115bca1c1f7a38d838909aa83cce87ae
-- 
2.43.0