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

[PATCH v2 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 X86_FEATURE_SEV_SNP as well, 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.

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 X86_FEATURE_SEV_SNP 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 v2 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 v2 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 disabled in the BIOS 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).

X86_FEATURE_SEV_SNP is resolved in bsp_determine_snp(), well before this
initcall, and is cleared when the SNP host cannot be brought up (including
SNP disabled in the BIOS).  Gate rmpopt_init() on it as well, so the setup
and the announcement only happen on an SNP host.

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..81b9efd55c51 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 (!cpu_feature_enabled(X86_FEATURE_SEV_SNP) ||
+	    !cpu_feature_enabled(X86_FEATURE_RMPOPT))
 		return -ENODEV;
 
 	rmpopt_wq = alloc_workqueue("rmpopt_wq", WQ_PERCPU, 1);
-- 
2.43.0

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] x86/sev: rmpopt_init checks CPU feature instead of CC_ATTR_HOST_SEV_SNP
--

commit 4dd9ce9c71a0a62c99cac5b242adafc6f676a4ec
Author: Ashish Kalra <ashish.kalra@amd.com>

x86/sev: Only announce RMPOPT optimizations when SNP is enabled

This commit updates rmpopt_init() to check for X86_FEATURE_SEV_SNP in
addition to X86_FEATURE_RMPOPT. The intent is to avoid allocating the RMPOPT
workqueue and printing the enablement message when the host is not an SNP host.

> diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
> index 43e4945e6cdf1..81b9efd55c511 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 (!cpu_feature_enabled(X86_FEATURE_SEV_SNP) ||
> +	    !cpu_feature_enabled(X86_FEATURE_RMPOPT))

[Severity: Medium]
Will this reliably detect if SNP is disabled during IOMMU initialization?

If AMD IOMMU initialization fails to enable SNP (e.g., RMP initialization
fails or IOMMU is missing), it dynamically clears CC_ATTR_HOST_SEV_SNP but
leaves X86_FEATURE_SEV_SNP enabled:

drivers/iommu/amd/init.c:iommu_go_to_state() {
    ...
		cc_platform_clear(CC_ATTR_HOST_SEV_SNP);
    ...
}

Since rmpopt_init() runs as a device_initcall, it executes after IOMMU
initialization (which runs as a rootfs_initcall). By checking the CPU
feature instead of the software CC_ATTR flag, it seems it will erroneously
allocate the rmpopt_wq workqueue and print a misleading
'RMPOPT optimizations enabled' message on a non-SNP host, leaking an unused
workqueue on a cold path.

Should this check use cc_platform_has(CC_ATTR_HOST_SEV_SNP) instead?

>  		return -ENODEV;
>  
>  	rmpopt_wq = alloc_workqueue("rmpopt_wq", WQ_PERCPU, 1);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1792011434.git.ashish.kalra@amd.com?part=2

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

[Kalra, Ashish]

On 10/14/2026 4:26 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] x86/sev: rmpopt_init checks CPU feature instead of CC_ATTR_HOST_SEV_SNP
> --
> 
> commit 4dd9ce9c71a0a62c99cac5b242adafc6f676a4ec
> Author: Ashish Kalra <ashish.kalra@amd.com>
> 
> x86/sev: Only announce RMPOPT optimizations when SNP is enabled
> 
> This commit updates rmpopt_init() to check for X86_FEATURE_SEV_SNP in
> addition to X86_FEATURE_RMPOPT. The intent is to avoid allocating the RMPOPT
> workqueue and printing the enablement message when the host is not an SNP host.
> 
>> diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
>> index 43e4945e6cdf1..81b9efd55c511 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 (!cpu_feature_enabled(X86_FEATURE_SEV_SNP) ||
>> +	    !cpu_feature_enabled(X86_FEATURE_RMPOPT))
> 
> [Severity: Medium]
> Will this reliably detect if SNP is disabled during IOMMU initialization?
> 
> If AMD IOMMU initialization fails to enable SNP (e.g., RMP initialization
> fails or IOMMU is missing), it dynamically clears CC_ATTR_HOST_SEV_SNP but
> leaves X86_FEATURE_SEV_SNP enabled:
> 
> drivers/iommu/amd/init.c:iommu_go_to_state() {
>     ...
> 		cc_platform_clear(CC_ATTR_HOST_SEV_SNP);
>     ...
> }
> 
> Since rmpopt_init() runs as a device_initcall, it executes after IOMMU
> initialization (which runs as a rootfs_initcall). By checking the CPU
> feature instead of the software CC_ATTR flag, it seems it will erroneously
> allocate the rmpopt_wq workqueue and print a misleading
> 'RMPOPT optimizations enabled' message on a non-SNP host, leaking an unused
> workqueue on a cold path.
> 
> Should this check use cc_platform_has(CC_ATTR_HOST_SEV_SNP) instead?
> 

Good catch — correct. The AMD IOMMU disable_snp path clears CC_ATTR_HOST_SEV_SNP on failure but leaves X86_FEATURE_SEV_SNP set, and it runs (rootfs_initcall) before rmpopt_init() (device_initcall), so the CPUID-bit check would miss that case. I will post a v3, which gates rmpopt_init() on cc_platform_has(CC_ATTR_HOST_SEV_SNP) instead — it reflects the final host SNP state (set at BSP init, cleared whenever SNP can't be brought up) and matches the gate already used in snp_enable_rmpopt().

Thanks,
Ashish

>>  		return -ENODEV;
>>  
>>  	rmpopt_wq = alloc_workqueue("rmpopt_wq", WQ_PERCPU, 1);
>