From: "Kalra, Ashish" <ashish.kalra@amd.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>,
K Prateek Nayak <kprateek.nayak@amd.com>,
tglx@kernel.org, mingo@redhat.com, dave.hansen@linux.intel.com,
x86@kernel.org, hpa@zytor.com, seanjc@google.com,
peterz@infradead.org, herbert@gondor.apana.org.au,
davem@davemloft.net, ardb@kernel.org, pbonzini@redhat.com,
aik@amd.com, Michael.Roth@amd.com, Tycho.Andersen@amd.com,
Nathan.Fontenot@amd.com, ackerleytng@google.com,
jackyli@google.com, pgonda@google.com, rientjes@google.com,
jacobhxu@google.com, xin@zytor.com,
pawan.kumar.gupta@linux.intel.com, babu.moger@amd.com,
dyoung@redhat.com, nikunj@amd.com, darwi@linutronix.de,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
kvm@vger.kernel.org, linux-coco@lists.linux.dev
Subject: Re: [PATCH v4 1/2] x86/sev: Clear RMPOPT when segmented RMP is disabled by firmware
Date: Mon, 2 Nov 2026 14:21:28 -0600 [thread overview]
Message-ID: <5c80e556-cdb8-46fd-9bee-c54732377236@amd.com> (raw)
In-Reply-To: <20261102193116.GDaujlBJc3XjG3xzLj@fat_crate.local>
On 11/2/2026 1:31 PM, Borislav Petkov wrote:
> On Mon, Nov 02, 2026 at 09:50:32AM -0600, Kalra, Ashish wrote:
>> 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 simplifies the code even more:
>
> 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)
> return probe_segmented_rmptable_info();
>
> out:
> setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
> return probe_contiguous_rmptable_info();
> }
>
> Along with the below, which should have happened too:
>
> 1. RMPOPT depends on SEV_SNP, ofc. This would make sure RMPOPT is cleared
> everytime SNP is cleared, as it should be.
>
Yes, that is a good point, but do note that the cpuid-dep only fires when the SEV_SNP CPUID bit is cleared though,
and the IOMMU "can't enable SNP" path clears only CC_ATTR_HOST_SEV_SNP, not the CPUID bit.
> 2. snp_enable_rmpopt() needs to check SNP first, ofc, and then RMPOPT.
Yes.
>
> diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
> index 99801e844b30..acbcec394ef1 100644
> --- a/arch/x86/kernel/cpu/cpuid-deps.c
> +++ b/arch/x86/kernel/cpu/cpuid-deps.c
> @@ -93,6 +93,7 @@ static const struct cpuid_dep cpuid_deps[] = {
> { X86_FEATURE_SPEC_CTRL_SSBD, X86_FEATURE_SPEC_CTRL },
> { X86_FEATURE_LASS, X86_FEATURE_SMAP },
> { X86_FEATURE_INVLPGB, X86_FEATURE_PCID },
> + { X86_FEATURE_RMPOPT, X86_FEATURE_SEV_SNP },
> {}
> };
>
> diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
> index ff6d17795054..a47b812b2ea3 100644
> --- a/arch/x86/virt/svm/sev.c
> +++ b/arch/x86/virt/svm/sev.c
> @@ -669,10 +669,10 @@ void snp_enable_rmpopt(void)
> u64 base;
> int cpu;
>
> - if (!cpu_feature_enabled(X86_FEATURE_RMPOPT))
> + if (!cc_platform_has(CC_ATTR_HOST_SEV_SNP))
> return;
>
> - if (!cc_platform_has(CC_ATTR_HOST_SEV_SNP))
> + if (!cpu_feature_enabled(X86_FEATURE_RMPOPT))
> return;
>
> if (!rmpopt_soft_init)
>
> ---
>
> here's the full diff. Have a look pls and let me know what else I am missing:
>
> ---
>
> diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
> index 99801e844b30..acbcec394ef1 100644
> --- a/arch/x86/kernel/cpu/cpuid-deps.c
> +++ b/arch/x86/kernel/cpu/cpuid-deps.c
> @@ -93,6 +93,7 @@ static const struct cpuid_dep cpuid_deps[] = {
> { X86_FEATURE_SPEC_CTRL_SSBD, X86_FEATURE_SPEC_CTRL },
> { X86_FEATURE_LASS, X86_FEATURE_SMAP },
> { X86_FEATURE_INVLPGB, X86_FEATURE_PCID },
> + { X86_FEATURE_RMPOPT, X86_FEATURE_SEV_SNP },
> {}
> };
>
> diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
> index bd70c4d0b774..a47b812b2ea3 100644
> --- a/arch/x86/virt/svm/sev.c
> +++ b/arch/x86/virt/svm/sev.c
> @@ -669,10 +669,10 @@ void snp_enable_rmpopt(void)
> u64 base;
> int cpu;
>
> - if (!cpu_feature_enabled(X86_FEATURE_RMPOPT))
> + if (!cc_platform_has(CC_ATTR_HOST_SEV_SNP))
> return;
>
> - if (!cc_platform_has(CC_ATTR_HOST_SEV_SNP))
> + if (!cpu_feature_enabled(X86_FEATURE_RMPOPT))
> return;
>
> if (!rmpopt_soft_init)
> @@ -817,20 +817,15 @@ 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 (rmp_cfg & MSR_AMD64_SEG_RMP_ENABLED) {
> - if (probe_segmented_rmptable_info())
> - return true;
> + if (!cpu_feature_enabled(X86_FEATURE_SEGMENTED_RMP))
> + goto out;
>
> - 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)
> + return probe_segmented_rmptable_info();
>
> +out:
> + setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
> return probe_contiguous_rmptable_info();
> }
>
> ---
Looks good, the simplification is nice. Two things worth noting:
1). With the leaner snp_probe_rmptable_info(), a probe_segmented_rmptable_info() failure no longer clears RMPOPT inline — it now relies
on the new {RMPOPT, SEV_SNP} dep: the false return (from probe_segmented_rmptable_info()) makes bsp_determine_snp() clear SEV_SNP,
which clears RMPOPT.
2). As i mentioned above, the cpuid-dep only fires when the SEV_SNP CPUID bit is cleared though, and the IOMMU "can't enable SNP" path
clears only CC_ATTR_HOST_SEV_SNP, not the CPUID bit. So we still need the rmpopt_init() (in patch 2 of this series) move into
snp_rmptable_init() to avoid announcing RMPOPT / allocating the workqueue on a host where the IOMMU turned SNP off —
this dep doesn't cover that case.
Rest looks right.
Thanks,
Ashish
>
> Thx.
>
next prev parent reply other threads:[~2026-11-02 20:21 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-28 19:48 [PATCH v4 0/2] x86/sev: Fix RMPOPT enablement on non-RMPOPT configs Ashish Kalra
2026-10-28 19:49 ` [PATCH v4 1/2] x86/sev: Clear RMPOPT when segmented RMP is disabled by firmware Ashish Kalra
2026-10-28 21:51 ` Pankaj Gupta
2026-11-02 5:28 ` Borislav Petkov
2026-11-02 6:12 ` K Prateek Nayak
2026-11-02 7:01 ` Borislav Petkov
2026-11-02 14:12 ` Tom Lendacky
2026-11-02 14:48 ` Borislav Petkov
2026-11-02 15:50 ` Kalra, Ashish
2026-11-02 19:31 ` Borislav Petkov
2026-11-02 20:21 ` Kalra, Ashish [this message]
2026-11-03 0:22 ` Borislav Petkov
2026-11-02 21:25 ` Tom Lendacky
2026-11-02 21:43 ` Borislav Petkov
2026-11-03 0:07 ` Kalra, Ashish
2026-11-03 0:45 ` Borislav Petkov
2026-11-03 2:58 ` K Prateek Nayak
2026-10-28 19:49 ` [PATCH v4 2/2] x86/sev: Set up RMPOPT only on an active SNP host Ashish Kalra
2026-10-28 22:00 ` Gupta, Pankaj
2026-10-29 15:33 ` Tom Lendacky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5c80e556-cdb8-46fd-9bee-c54732377236@amd.com \
--to=ashish.kalra@amd.com \
--cc=Michael.Roth@amd.com \
--cc=Nathan.Fontenot@amd.com \
--cc=Tycho.Andersen@amd.com \
--cc=ackerleytng@google.com \
--cc=aik@amd.com \
--cc=ardb@kernel.org \
--cc=babu.moger@amd.com \
--cc=bp@alien8.de \
--cc=darwi@linutronix.de \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=dyoung@redhat.com \
--cc=herbert@gondor.apana.org.au \
--cc=hpa@zytor.com \
--cc=jackyli@google.com \
--cc=jacobhxu@google.com \
--cc=kprateek.nayak@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nikunj@amd.com \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=pgonda@google.com \
--cc=rientjes@google.com \
--cc=seanjc@google.com \
--cc=tglx@kernel.org \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
--cc=xin@zytor.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®