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

[PATCH 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 moves the "RMPOPT optimizations enabled" message out of the
feature-only-gated initcall and into the SNP-gated enable path, so it is
not printed when SNP is disabled in the BIOS.

Both restore the behaviour of the posted series; the issues were
introduced when the series was applied (see the per-patch notes). Each
carries a Fixes: tag.

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 | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)


base-commit: 250ee734115bca1c1f7a38d838909aa83cce87ae
-- 
2.43.0

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

[Ashish Kalra]

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

snp_probe_rmptable_info() only clears X86_FEATURE_RMPOPT when the platform
does not advertise X86_FEATURE_SEGMENTED_RMP, or when the segmented RMP
table probe fails.  It misses the case where the platform advertises
segmented RMP but the firmware has it disabled (MSR_AMD64_RMP_CFG's
SEG_RMP_ENABLED bit is clear), so the system runs with a contiguous RMP:
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".  The clear runs at BSP init before alternatives, so
the subsequent cpu_feature_enabled(X86_FEATURE_RMPOPT) checks observe it.

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

Note: this restores the snp_probe_rmptable_info() structure from the
posted series (v16 3/5), where a single setup_clear_cpu_cap() on the
common contiguous fall-through covered the "SEGMENTED_RMP advertised but
disabled by firmware" case (called out in the v16 cover letter).  When
applied, 15d974be0a3b narrowed that clear into an else branch and dropped
that case.
 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 2/2] x86/sev: Only announce RMPOPT optimizations when SNP is enabled

[Ashish Kalra]

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

rmpopt_init() 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 disabled in the BIOS the
message is still printed at boot even though RMPOPT is never actually used
(snp_enable_rmpopt() bails out on !CC_ATTR_HOST_SEV_SNP), which is
misleading.

rmpopt_init() is only the software setup (workqueue and the delayed work);
the capability that matters for the message - an active SNP host - is
checked in snp_enable_rmpopt().  Move the announcement there, as a
pr_info_once(), so it is emitted only when RMPOPT is actually enabled on an
SNP host.

Fixes: c6c6f156d192 ("x86/sev: Perform RMP optimizations asynchronously")
Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
---

Note: in the posted series the pr_info_once() lived in
snp_enable_rmpopt() (SNP-gated); when applied, c6c6f156d192 moved it to
rmpopt_init() (feature-only-gated) as a plain pr_info().  This restores the
original placement.
 arch/x86/virt/svm/sev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
index 43e4945e6cdf..6f5f4ee821d0 100644
--- a/arch/x86/virt/svm/sev.c
+++ b/arch/x86/virt/svm/sev.c
@@ -656,8 +656,6 @@ static int __init rmpopt_init(void)
 	if ((rmpopt_pa_end - rmpopt_pa_start) > SZ_2T)
 		rmpopt_pa_end = rmpopt_pa_start + SZ_2T;
 
-	pr_info("RMPOPT optimizations enabled\n");
-
 	rmpopt_soft_init = true;
 
 	return 0;
@@ -690,6 +688,8 @@ void snp_enable_rmpopt(void)
 
 	mod_delayed_work(rmpopt_wq, &rmpopt_delayed_work,
 			 msecs_to_jiffies(RMPOPT_WORK_TIMEOUT));
+
+	pr_info_once("RMPOPT optimizations enabled\n");
 }
 EXPORT_SYMBOL_FOR_MODULES(snp_enable_rmpopt, "ccp,kvm-amd");
 
-- 
2.43.0

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

[Borislav Petkov]

On Tue, Oct 13, 2026 at 03:44:18PM +0000, Ashish Kalra wrote:
> snp_probe_rmptable_info() only clears X86_FEATURE_RMPOPT when the platform
> does not advertise X86_FEATURE_SEGMENTED_RMP, or when the segmented RMP
> table probe fails.  It misses the case where the platform advertises
> segmented RMP but the firmware has it disabled (MSR_AMD64_RMP_CFG's
> SEG_RMP_ENABLED bit is clear)

What does that mean: "the platform advertises segmented RMP"?

The CPUID bit is still set?

Or anything else?

How do you create this configuration?

Thx.

-- 
Regards/Gruss,
    Boris.

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

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

[Kalra, Ashish]

On 10/13/2026 5:26 PM, Borislav Petkov wrote:
> On Tue, Oct 13, 2026 at 03:44:18PM +0000, Ashish Kalra wrote:
>> snp_probe_rmptable_info() only clears X86_FEATURE_RMPOPT when the platform
>> does not advertise X86_FEATURE_SEGMENTED_RMP, or when the segmented RMP
>> table probe fails.  It misses the case where the platform advertises
>> segmented RMP but the firmware has it disabled (MSR_AMD64_RMP_CFG's
>> SEG_RMP_ENABLED bit is clear)
> 
> What does that mean: "the platform advertises segmented RMP"?
> 
> The CPUID bit is still set?

Yes, "Advertises" is the X86_FEATURE_SEGMENTED_RMP CPUID bit set. That's separate from segmented RMP being enabled,
which is MSR_AMD64_RMP_CFG[SEG_RMP_ENABLED] (0xc0010136, bit 0), programmed by firmware

> 
> Or anything else?
> 
> How do you create this configuration?

There is a BIOS option to enable/disable Segmented RMP. Disabling it on a part that supports/advertises segmented RMP
feature brings the RMP up contiguous (SEG_RMP_ENABLED clear) while the SEGMENTED_RMP CPUID bit stays set.

Thanks,
Ashish

> 
> Thx.
> 

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

[Tom Lendacky]

On 10/13/26 10:44, Ashish Kalra wrote:
> From: Ashish Kalra <ashish.kalra@amd.com>
> 
> snp_probe_rmptable_info() only clears X86_FEATURE_RMPOPT when the platform
> does not advertise X86_FEATURE_SEGMENTED_RMP, or when the segmented RMP
> table probe fails.  It misses the case where the platform advertises
> segmented RMP but the firmware has it disabled (MSR_AMD64_RMP_CFG's
> SEG_RMP_ENABLED bit is clear), so the system runs with a contiguous RMP:
> 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".  The clear runs at BSP init before alternatives, so

The clearing of the RMPOPT feature runs at BSP initialization, before
alternatives patching, so the ...

(Not sure this last line is even really needed, though)

> the subsequent cpu_feature_enabled(X86_FEATURE_RMPOPT) checks observe it.
> 
> 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: this restores the snp_probe_rmptable_info() structure from the
> posted series (v16 3/5), where a single setup_clear_cpu_cap() on the
> common contiguous fall-through covered the "SEGMENTED_RMP advertised but
> disabled by firmware" case (called out in the v16 cover letter).  When
> applied, 15d974be0a3b narrowed that clear into an else branch and dropped
> that case.
>  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();
>  }
>  

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

[Tom Lendacky]

On 10/13/26 10:44, Ashish Kalra wrote:
> From: Ashish Kalra <ashish.kalra@amd.com>
> 
> rmpopt_init() 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 disabled in the BIOS the
> message is still printed at boot even though RMPOPT is never actually used
> (snp_enable_rmpopt() bails out on !CC_ATTR_HOST_SEV_SNP), which is
> misleading.
> 
> rmpopt_init() is only the software setup (workqueue and the delayed work);
> the capability that matters for the message - an active SNP host - is
> checked in snp_enable_rmpopt().  Move the announcement there, as a
> pr_info_once(), so it is emitted only when RMPOPT is actually enabled on an
> SNP host.
> 
> Fixes: c6c6f156d192 ("x86/sev: Perform RMP optimizations asynchronously")
> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
> ---
> 
> Note: in the posted series the pr_info_once() lived in
> snp_enable_rmpopt() (SNP-gated); when applied, c6c6f156d192 moved it to
> rmpopt_init() (feature-only-gated) as a plain pr_info().  This restores the
> original placement.
>  arch/x86/virt/svm/sev.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
> index 43e4945e6cdf..6f5f4ee821d0 100644
> --- a/arch/x86/virt/svm/sev.c
> +++ b/arch/x86/virt/svm/sev.c
> @@ -656,8 +656,6 @@ static int __init rmpopt_init(void)

Should the check at the start of rmpopt_init() just be

if (!cpu_feature_enabled(X86_FEATURE_SEV_SNP) ||
    !cpu_feature_enabled(X86_FEATURE_RMPOPT))

so that you don't even bother setting up the workqueue, etc.?

Thanks,
Tom

>  	if ((rmpopt_pa_end - rmpopt_pa_start) > SZ_2T)
>  		rmpopt_pa_end = rmpopt_pa_start + SZ_2T;
>  
> -	pr_info("RMPOPT optimizations enabled\n");
> -
>  	rmpopt_soft_init = true;
>  
>  	return 0;
> @@ -690,6 +688,8 @@ void snp_enable_rmpopt(void)
>  
>  	mod_delayed_work(rmpopt_wq, &rmpopt_delayed_work,
>  			 msecs_to_jiffies(RMPOPT_WORK_TIMEOUT));
> +
> +	pr_info_once("RMPOPT optimizations enabled\n");
>  }
>  EXPORT_SYMBOL_FOR_MODULES(snp_enable_rmpopt, "ccp,kvm-amd");
>