[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

[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 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
>
>

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;
>  }
>  

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

[Borislav Petkov]

Ok,

pls check if this works too:

From: Ashish Kalra <ashish.kalra@amd.com>
Date: Wed, 28 Oct 2026 19:49:22 +0000
Subject: [PATCH] x86/sev: Clear RMPOPT when segmented RMP is disabled by firmware

Segmented RMP support is advertised via X86_FEATURE_SEGMENTED_RMP, and the
firmware enables it via MSR_AMD64_RMP_CFG[SEG_RMP_ENABLED]. The latter can be
cleared in platform BIOS by the user, in which case the system runs in
contiguous RMP setting.

snp_probe_rmptable_info() does not clear X86_FEATURE_RMPOPT in the
advertised-but-firmware-disabled case.

As a result, this does not prevent snp_enable_rmpopt() from trying to program
MSR_AMD64_RMPOPT_BASE, which raises a #GP on the MSR access.

Make sure X86_FEATURE_RMPOPT is cleared in all cases where segmented RMP is
not enabled.

  [ bp:
   - Put the commit message on Ozempic
   - Flip the logic in the function so that the segmented RMP disabled
     case goes first and the flow gets simpler this way. ]

Fixes: 15d974be0a3b ("x86/sev: Initialize RMPOPT configuration MSRs")
Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/56da047d63b22f03a7e709fc172a5543da894d67.1793216372.git.ashish.kalra@amd.com
---
 arch/x86/virt/svm/sev.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
index bd70c4d0b774..ff6d17795054 100644
--- a/arch/x86/virt/svm/sev.c
+++ b/arch/x86/virt/svm/sev.c
@@ -817,21 +817,20 @@ static bool probe_segmented_rmptable_info(void)
 
 bool snp_probe_rmptable_info(void)
 {
-	if (cpu_feature_enabled(X86_FEATURE_SEGMENTED_RMP)) {
-		rdmsrq(MSR_AMD64_RMP_CFG, rmp_cfg);
+	if (!cpu_feature_enabled(X86_FEATURE_SEGMENTED_RMP)) {
+		setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
 
-		if (rmp_cfg & MSR_AMD64_SEG_RMP_ENABLED) {
-			if (probe_segmented_rmptable_info())
-				return true;
+		return probe_contiguous_rmptable_info();
+	}
 
-			setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
-			return false;
-		}
-	} else {
-		setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
+	rdmsrq(MSR_AMD64_RMP_CFG, rmp_cfg);
+	if (rmp_cfg & MSR_AMD64_SEG_RMP_ENABLED) {
+		if (probe_segmented_rmptable_info())
+			return true;
 	}
 
-	return probe_contiguous_rmptable_info();
+	setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
+	return false;
 }
 
 /*
-- 
2.53.0

-- 
Regards/Gruss,
    Boris.

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

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

[K Prateek Nayak]

Hello Boris,

On 11/2/2026 10:58 AM, Borislav Petkov wrote:
> Segmented RMP support is advertised via X86_FEATURE_SEGMENTED_RMP, and the
> firmware enables it via MSR_AMD64_RMP_CFG[SEG_RMP_ENABLED]. The latter can be
> cleared in platform BIOS by the user, in which case the system runs in
> contiguous RMP setting.

nit. In the latter case, SNP is disabled entirely in bsp_determine_snp and
the system won't continue with contiguous RMP.

> snp_probe_rmptable_info() does not clear X86_FEATURE_RMPOPT in the
> advertised-but-firmware-disabled case.
> 
> As a result, this does not prevent snp_enable_rmpopt() from trying to program
> MSR_AMD64_RMPOPT_BASE, which raises a #GP on the MSR access.
> 
> Make sure X86_FEATURE_RMPOPT is cleared in all cases where segmented RMP is
> not enabled.
> 
>   [ bp:
>    - Put the commit message on Ozempic
>    - Flip the logic in the function so that the segmented RMP disabled
>      case goes first and the flow gets simpler this way. ]
> 
> Fixes: 15d974be0a3b ("x86/sev: Initialize RMPOPT configuration MSRs")
> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
> Link: https://patch.msgid.link/56da047d63b22f03a7e709fc172a5543da894d67.1793216372.git.ashish.kalra@amd.com

Feel free to include:

Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>

> ---
>  arch/x86/virt/svm/sev.c | 21 ++++++++++-----------
>  1 file changed, 10 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
> index bd70c4d0b774..ff6d17795054 100644
> --- a/arch/x86/virt/svm/sev.c
> +++ b/arch/x86/virt/svm/sev.c
> @@ -817,21 +817,20 @@ static bool probe_segmented_rmptable_info(void)
>  
>  bool snp_probe_rmptable_info(void)
>  {
> -	if (cpu_feature_enabled(X86_FEATURE_SEGMENTED_RMP)) {
> -		rdmsrq(MSR_AMD64_RMP_CFG, rmp_cfg);
> +	if (!cpu_feature_enabled(X86_FEATURE_SEGMENTED_RMP)) {
> +		setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
>  
> -		if (rmp_cfg & MSR_AMD64_SEG_RMP_ENABLED) {
> -			if (probe_segmented_rmptable_info())
> -				return true;
> +		return probe_contiguous_rmptable_info();
> +	}
>  
> -			setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
> -			return false;
> -		}
> -	} else {
> -		setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
> +	rdmsrq(MSR_AMD64_RMP_CFG, rmp_cfg);
> +	if (rmp_cfg & MSR_AMD64_SEG_RMP_ENABLED) {
> +		if (probe_segmented_rmptable_info())
> +			return true;
>  	}
>  
> -	return probe_contiguous_rmptable_info();
> +	setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
> +	return false;
>  }
>  
>  /*

-- 
Thanks and Regards,
Prateek

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

[Borislav Petkov]

On Mon, Nov 02, 2026 at 11:42:05AM +0530, K Prateek Nayak wrote:
> On 11/2/2026 10:58 AM, Borislav Petkov wrote:
> > Segmented RMP support is advertised via X86_FEATURE_SEGMENTED_RMP, and the
> > firmware enables it via MSR_AMD64_RMP_CFG[SEG_RMP_ENABLED]. The latter can be
> > cleared in platform BIOS by the user, in which case the system runs in
> > contiguous RMP setting.
> 
> nit. In the latter case, SNP is disabled entirely in bsp_determine_snp and
> the system won't continue with contiguous RMP.

Ah, true, good catch.

Thx.

-- 
Regards/Gruss,
    Boris.

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

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

[Tom Lendacky]

On 11/2/26 00:12, K Prateek Nayak wrote:
> Hello Boris,
> 
> On 11/2/2026 10:58 AM, Borislav Petkov wrote:
>> Segmented RMP support is advertised via X86_FEATURE_SEGMENTED_RMP, and the
>> firmware enables it via MSR_AMD64_RMP_CFG[SEG_RMP_ENABLED]. The latter can be
>> cleared in platform BIOS by the user, in which case the system runs in
>> contiguous RMP setting.
> 
> nit. In the latter case, SNP is disabled entirely in bsp_determine_snp and
> the system won't continue with contiguous RMP.

Heh, I don't think that is a nit, it is broken.

I think the code as it was read fine, but that's just my opinion.

Thanks,
Tom
> 
>> snp_probe_rmptable_info() does not clear X86_FEATURE_RMPOPT in the
>> advertised-but-firmware-disabled case.
>>
>> As a result, this does not prevent snp_enable_rmpopt() from trying to program
>> MSR_AMD64_RMPOPT_BASE, which raises a #GP on the MSR access.
>>
>> Make sure X86_FEATURE_RMPOPT is cleared in all cases where segmented RMP is
>> not enabled.
>>
>>   [ bp:
>>    - Put the commit message on Ozempic
>>    - Flip the logic in the function so that the segmented RMP disabled
>>      case goes first and the flow gets simpler this way. ]
>>
>> Fixes: 15d974be0a3b ("x86/sev: Initialize RMPOPT configuration MSRs")
>> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
>> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
>> Link: https://patch.msgid.link/56da047d63b22f03a7e709fc172a5543da894d67.1793216372.git.ashish.kalra@amd.com
> 
> Feel free to include:
> 
> Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
> 
>> ---
>>  arch/x86/virt/svm/sev.c | 21 ++++++++++-----------
>>  1 file changed, 10 insertions(+), 11 deletions(-)
>>
>> diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
>> index bd70c4d0b774..ff6d17795054 100644
>> --- a/arch/x86/virt/svm/sev.c
>> +++ b/arch/x86/virt/svm/sev.c
>> @@ -817,21 +817,20 @@ static bool probe_segmented_rmptable_info(void)
>>  
>>  bool snp_probe_rmptable_info(void)
>>  {
>> -	if (cpu_feature_enabled(X86_FEATURE_SEGMENTED_RMP)) {
>> -		rdmsrq(MSR_AMD64_RMP_CFG, rmp_cfg);
>> +	if (!cpu_feature_enabled(X86_FEATURE_SEGMENTED_RMP)) {
>> +		setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
>>  
>> -		if (rmp_cfg & MSR_AMD64_SEG_RMP_ENABLED) {
>> -			if (probe_segmented_rmptable_info())
>> -				return true;
>> +		return probe_contiguous_rmptable_info();
>> +	}
>>  
>> -			setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
>> -			return false;
>> -		}
>> -	} else {
>> -		setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
>> +	rdmsrq(MSR_AMD64_RMP_CFG, rmp_cfg);
>> +	if (rmp_cfg & MSR_AMD64_SEG_RMP_ENABLED) {
>> +		if (probe_segmented_rmptable_info())
>> +			return true;
>>  	}
>>  
>> -	return probe_contiguous_rmptable_info();
>> +	setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
>> +	return false;
>>  }
>>  
>>  /*
> 

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

[Borislav Petkov]

On Mon, Nov 02, 2026 at 08:12:16AM -0600, Tom Lendacky wrote:
> Heh, I don't think that is a nit, it is broken.
>
> I think the code as it was read fine, but that's just my opinion.

Lemme see if you like this more (pasting it in applied form because the diff
is unreadable):

bool snp_probe_rmptable_info(void)
{
        if (!cpu_feature_enabled(X86_FEATURE_SEGMENTED_RMP))
                goto out;
        
        rdmsrq(MSR_AMD64_RMP_CFG, rmp_cfg);
        if (rmp_cfg & MSR_AMD64_SEG_RMP_ENABLED) {
                if (probe_segmented_rmptable_info())
                        return true;
        }       

out:
        setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
        return probe_contiguous_rmptable_info();
}

No repeated code, no if-else conditionals, just what needs to happen.

Thx.

-- 
Regards/Gruss,
    Boris.

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

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

[Kalra, Ashish]

Hello Boris,

On 11/2/2026 8:48 AM, Borislav Petkov wrote:
> On Mon, Nov 02, 2026 at 08:12:16AM -0600, Tom Lendacky wrote:
>> Heh, I don't think that is a nit, it is broken.
>>
>> I think the code as it was read fine, but that's just my opinion.
> 
> Lemme see if you like this more (pasting it in applied form because the diff
> is unreadable):
> 
> bool snp_probe_rmptable_info(void)
> {
>         if (!cpu_feature_enabled(X86_FEATURE_SEGMENTED_RMP))
>                 goto out;
>         
>         rdmsrq(MSR_AMD64_RMP_CFG, rmp_cfg);
>         if (rmp_cfg & MSR_AMD64_SEG_RMP_ENABLED) {
>                 if (probe_segmented_rmptable_info())
>                         return true;
>         }       
> 
> out:
>         setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
>         return probe_contiguous_rmptable_info();
> }
> 
> No repeated code, no if-else conditionals, just what needs to happen.

The original patch returns false if segmented RMP is enabled but
probe_segmented_rmptable_info() fails, your version falls through to
probe_contiguous_rmptable_info() instead. 

I believe it makes sense to keep the return false there: on a
segmented RMP enabled platform the RMP is segmented, not contiguous, so the
contiguous probe shouldn't run.

That's why i think the original patch looks fine to me.

Thanks,
Ashish

> 
> Thx.
>