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

[PATCH v4 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
RMPOPT_BASE is programmed and RMPOPT issued, which #GP on a contiguous RMP.

Patch 2 sets up RMPOPT only on an active SNP host by moving the soft-init
(workqueue setup and the "optimizations enabled" message) into
snp_rmptable_init(), so it no longer runs on systems where SNP is not
enabled (e.g. disabled in the BIOS).

v4:
 - Patch 1: drop the inline comment on the common fall-through clear (the
   rationale is in the commit message), and reword the commit message so
   RMPOPT_BASE programming is no longer attributed to the "RMPOPT initcall".
   No functional change; Tom's Reviewed-by retained.
 - Patch 2: instead of gating rmpopt_init() on CC_ATTR_HOST_SEV_SNP, move
   the RMPOPT soft-init into snp_rmptable_init(), which runs only once the
   host RMP table is established (CC_ATTR_HOST_SEV_SNP guaranteed).
   rmpopt_init() keeps its X86_FEATURE_RMPOPT-only gate and drops the
   device_initcall.

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: Set up RMPOPT only on an active SNP host

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


base-commit: 250ee734115bca1c1f7a38d838909aa83cce87ae
-- 
2.43.0

[PATCH v4 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, RMPOPT_BASE is programmed and the RMPOPT
instruction issued, 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>
---
 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 bd70c4d0b774..cd0412b9d251 100644
--- a/arch/x86/virt/svm/sev.c
+++ b/arch/x86/virt/svm/sev.c
@@ -827,10 +827,10 @@ bool snp_probe_rmptable_info(void)
 			setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
 			return false;
 		}
-	} else {
-		setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
 	}
 
+	setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
+
 	return probe_contiguous_rmptable_info();
 }
 
-- 
2.43.0

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

[Pankaj Gupta]

> 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, RMPOPT_BASE is programmed and the RMPOPT
> instruction issued, 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>

Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com>
Tested-by: Pankaj Gupta <pankaj.gupta@amd.com>

> ---
>  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 bd70c4d0b774..cd0412b9d251 100644
> --- a/arch/x86/virt/svm/sev.c
> +++ b/arch/x86/virt/svm/sev.c
> @@ -827,10 +827,10 @@ bool snp_probe_rmptable_info(void)
>                         setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
>                         return false;
>                 }
> -       } else {
> -               setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
>         }
>
> +       setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
> +
>         return probe_contiguous_rmptable_info();
>  }
>
> --
> 2.43.0
>
>

[PATCH v4 2/2] x86/sev: Set up RMPOPT only on an active SNP host

[Ashish Kalra]

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

rmpopt_init() allocates the RMPOPT workqueue and prints "RMPOPT
optimizations enabled", gated only on X86_FEATURE_RMPOPT - a CPUID bit
advertised independently of whether SNP is active.  As a device_initcall
it runs on every system with that bit, so on a host where SNP is not
enabled (disabled in the BIOS, or AMD IOMMU initialization fails to bring
it up) 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.

Rather than add an explicit SNP-host gate to the initcall, set RMPOPT up
where the host SNP state is established.  Call rmpopt_init() from the tail
of snp_rmptable_init(), which runs only once the host RMP table has been
set up and CC_ATTR_HOST_SEV_SNP is guaranteed (it WARN_ON_ONCE()s
otherwise), and drop the device_initcall.  rmpopt_init() keeps its
original X86_FEATURE_RMPOPT-only gate and no longer needs a separate
SNP-host check.

This is soft initialization only - the workqueue and the announcement; the
actual RMPOPT_BASE programming is still done later by snp_enable_rmpopt(),
which re-checks X86_FEATURE_RMPOPT, CC_ATTR_HOST_SEV_SNP and
rmpopt_soft_init.  An rmpopt_init() failure is non-fatal to SNP and is
intentionally ignored by snp_rmptable_init().

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 cd0412b9d251..39d3943cdc49 100644
--- a/arch/x86/virt/svm/sev.c
+++ b/arch/x86/virt/svm/sev.c
@@ -662,7 +662,6 @@ static int __init rmpopt_init(void)
 
 	return 0;
 }
-device_initcall(rmpopt_init);
 
 void snp_enable_rmpopt(void)
 {
@@ -726,6 +725,8 @@ int __init snp_rmptable_init(void)
 	 */
 	crash_kexec_post_notifiers = true;
 
+	rmpopt_init();
+
 	return 0;
 }
 
-- 
2.43.0

Re: [PATCH v4 2/2] x86/sev: Set up RMPOPT only on an active SNP host

[Gupta, Pankaj]

> From: Ashish Kalra <ashish.kalra@amd.com>
>
> rmpopt_init() allocates the RMPOPT workqueue and prints "RMPOPT
> optimizations enabled", gated only on X86_FEATURE_RMPOPT - a CPUID bit
> advertised independently of whether SNP is active.  As a device_initcall
> it runs on every system with that bit, so on a host where SNP is not
> enabled (disabled in the BIOS, or AMD IOMMU initialization fails to bring
> it up) 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.
>
> Rather than add an explicit SNP-host gate to the initcall, set RMPOPT up
> where the host SNP state is established.  Call rmpopt_init() from the tail
> of snp_rmptable_init(), which runs only once the host RMP table has been
> set up and CC_ATTR_HOST_SEV_SNP is guaranteed (it WARN_ON_ONCE()s
> otherwise), and drop the device_initcall.  rmpopt_init() keeps its
> original X86_FEATURE_RMPOPT-only gate and no longer needs a separate
> SNP-host check.
>
> This is soft initialization only - the workqueue and the announcement; the
> actual RMPOPT_BASE programming is still done later by snp_enable_rmpopt(),
> which re-checks X86_FEATURE_RMPOPT, CC_ATTR_HOST_SEV_SNP and
> rmpopt_soft_init.  An rmpopt_init() failure is non-fatal to SNP and is
> intentionally ignored by snp_rmptable_init().
>
> 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>
Reviewed-by: Pankaj Gupta <pankaj.gupta@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 cd0412b9d251..39d3943cdc49 100644
> --- a/arch/x86/virt/svm/sev.c
> +++ b/arch/x86/virt/svm/sev.c
> @@ -662,7 +662,6 @@ static int __init rmpopt_init(void)
>   
>   	return 0;
>   }
> -device_initcall(rmpopt_init);
>   
>   void snp_enable_rmpopt(void)
>   {
> @@ -726,6 +725,8 @@ int __init snp_rmptable_init(void)
>   	 */
>   	crash_kexec_post_notifiers = true;
>   
> +	rmpopt_init();
> +
>   	return 0;
>   }
>   

Re: [PATCH v4 2/2] x86/sev: Set up RMPOPT only on an active SNP host

[Tom Lendacky]

On 10/28/26 14:49, Ashish Kalra wrote:
> From: Ashish Kalra <ashish.kalra@amd.com>
> 
> rmpopt_init() allocates the RMPOPT workqueue and prints "RMPOPT
> optimizations enabled", gated only on X86_FEATURE_RMPOPT - a CPUID bit
> advertised independently of whether SNP is active.  As a device_initcall
> it runs on every system with that bit, so on a host where SNP is not
> enabled (disabled in the BIOS, or AMD IOMMU initialization fails to bring
> it up) 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.
> 
> Rather than add an explicit SNP-host gate to the initcall, set RMPOPT up
> where the host SNP state is established.  Call rmpopt_init() from the tail
> of snp_rmptable_init(), which runs only once the host RMP table has been
> set up and CC_ATTR_HOST_SEV_SNP is guaranteed (it WARN_ON_ONCE()s
> otherwise), and drop the device_initcall.  rmpopt_init() keeps its
> original X86_FEATURE_RMPOPT-only gate and no longer needs a separate
> SNP-host check.
> 
> This is soft initialization only - the workqueue and the announcement; the
> actual RMPOPT_BASE programming is still done later by snp_enable_rmpopt(),
> which re-checks X86_FEATURE_RMPOPT, CC_ATTR_HOST_SEV_SNP and
> rmpopt_soft_init.  An rmpopt_init() failure is non-fatal to SNP and is
> intentionally ignored by snp_rmptable_init().
> 
> 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>

Reviewed-by: Tom Lendacky <thomas.lendacky@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 cd0412b9d251..39d3943cdc49 100644
> --- a/arch/x86/virt/svm/sev.c
> +++ b/arch/x86/virt/svm/sev.c
> @@ -662,7 +662,6 @@ static int __init rmpopt_init(void)
>  
>  	return 0;
>  }
> -device_initcall(rmpopt_init);
>  
>  void snp_enable_rmpopt(void)
>  {
> @@ -726,6 +725,8 @@ int __init snp_rmptable_init(void)
>  	 */
>  	crash_kexec_post_notifiers = true;
>  
> +	rmpopt_init();
> +
>  	return 0;
>  }
>