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

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

[Ashish Kalra]

From: Ashish Kalra <ashish.kalra@amd.com>

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

[PATCH v3 1/2] x86/sev: Clear RMPOPT when segmented RMP is disabled by firmware

[Ashish Kalra]

From: Ashish Kalra <ashish.kalra@amd.com>

Segmented RMP has two independent states: the CPU *advertises* support via
the X86_FEATURE_SEGMENTED_RMP CPUID bit, and the firmware *enables* it via
MSR_AMD64_RMP_CFG[SEG_RMP_ENABLED].  A platform can advertise segmented RMP
(CPUID bit set) while the firmware leaves it disabled (SEG_RMP_ENABLED
clear) -- e.g. through a BIOS option to disable Segmented RMP -- in which
case the system runs with a contiguous RMP.

snp_probe_rmptable_info() clears X86_FEATURE_RMPOPT only when the CPU does
not advertise segmented RMP, or when the segmented RMP table probe fails.
It misses the advertised-but-firmware-disabled case: that path falls
through to the contiguous probe with X86_FEATURE_RMPOPT still set.

X86_FEATURE_RMPOPT is a CPUID bit advertised independently of whether
segmented RMP is enabled, but RMPOPT requires an enabled segmented RMP.
With the capability left set, the RMPOPT initcall programs RMPOPT_BASE and
issues the RMPOPT instruction, both of which #GP on a contiguous RMP:

  unchecked MSR access error: WRMSR to 0xc0010139 ...
  general protection fault ... snp_enable_rmpopt

Clear X86_FEATURE_RMPOPT on the common contiguous fall-through so it covers
both "segmented RMP not supported" and "segmented RMP supported but
disabled by firmware".

Fixes: 15d974be0a3b ("x86/sev: Initialize RMPOPT configuration MSRs")
Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
---

Note: 15d974be0a3b as applied narrowed the contiguous fall-through clear
into an else branch, dropping the "SEGMENTED_RMP advertised but disabled by
firmware" case the posted series (v16 3/5) covered; this restores it.
 arch/x86/virt/svm/sev.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
index bd70c4d0b774..43e4945e6cdf 100644
--- a/arch/x86/virt/svm/sev.c
+++ b/arch/x86/virt/svm/sev.c
@@ -827,10 +827,16 @@ bool snp_probe_rmptable_info(void)
 			setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
 			return false;
 		}
-	} else {
-		setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
 	}
 
+	/*
+	 * Segmented RMP is either not supported on the platform or is
+	 * disabled by the firmware.  RMPOPT is not supported without
+	 * segmented RMP, so drop the capability before it reaches the
+	 * initcall and faults programming RMPOPT_BASE / issuing RMPOPT.
+	 */
+	setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
+
 	return probe_contiguous_rmptable_info();
 }
 
-- 
2.43.0

[PATCH v3 2/2] x86/sev: Only announce RMPOPT optimizations when SNP is enabled

[Ashish Kalra]

From: Ashish Kalra <ashish.kalra@amd.com>

rmpopt_init() sets up the RMPOPT workqueue and prints "RMPOPT
optimizations enabled" gated only on X86_FEATURE_RMPOPT, which is a CPUID
bit advertised independently of whether SNP is active.  On a system where
SNP is not enabled the workqueue is allocated and the message is printed at
boot even though RMPOPT is never used (snp_enable_rmpopt() bails out on a
non-SNP host).

Gate rmpopt_init() on an active SNP host as well, using
cc_platform_has(CC_ATTR_HOST_SEV_SNP).  This reflects the final host SNP
state: it is set at BSP initialization and cleared whenever SNP cannot be
brought up, whether disabled in the BIOS or when AMD IOMMU initialization
fails to enable SNP (which clears CC_ATTR_HOST_SEV_SNP but leaves the
X86_FEATURE_SEV_SNP CPUID bit set).  It is settled before this
device_initcall runs and matches the gate used in snp_enable_rmpopt().

Suggested-by: Tom Lendacky <thomas.lendacky@amd.com>
Fixes: c6c6f156d192 ("x86/sev: Perform RMP optimizations asynchronously")
Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
---
 arch/x86/virt/svm/sev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
index 43e4945e6cdf..fe78f512e7aa 100644
--- a/arch/x86/virt/svm/sev.c
+++ b/arch/x86/virt/svm/sev.c
@@ -639,7 +639,8 @@ static void do_rmpopt_work(struct work_struct *work)
 
 static int __init rmpopt_init(void)
 {
-	if (!cpu_feature_enabled(X86_FEATURE_RMPOPT))
+	if (!cc_platform_has(CC_ATTR_HOST_SEV_SNP) ||
+	    !cpu_feature_enabled(X86_FEATURE_RMPOPT))
 		return -ENODEV;
 
 	rmpopt_wq = alloc_workqueue("rmpopt_wq", WQ_PERCPU, 1);
-- 
2.43.0

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

[Borislav Petkov]

On Wed, Oct 14, 2026 at 11:06:32PM +0000, Ashish Kalra wrote:
> From: Ashish Kalra <ashish.kalra@amd.com>
> 
> Two fixes for the RMPOPT series, both for configurations where the
> RMPOPT CPUID bit is advertised but RMPOPT is not actually usable:

Those are clearly not settled yet.

But you don't have to rush them, take your time with, test them more and
analyze better what you're fixing instead of piling more stuff ontop.

And avoid all that unnecessary commenting you're doing. The stuff you're
saying belongs in the commit message - not spread around the code.

If the code needs more explanation, then perhaps it needs to be simplified
and split properly.

I'm not at all happy about how intertwined and inter-dependent and thus
fragile our SNP init gunk is.

So think about that too, perhaps it can be simplified even more.

I'll take the final versions later, during the 7.4 stabilization phase.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette