From: Tom Lendacky <thomas.lendacky@amd.com>
To: Ashish Kalra <Ashish.Kalra@amd.com>,
tglx@kernel.org, mingo@redhat.com, bp@alien8.de,
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
Cc: pbonzini@redhat.com, aik@amd.com, Michael.Roth@amd.com,
KPrateek.Nayak@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, john.allen@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 v11 2/6] x86/sev: Disable CPU hotplug while SNP is active
Date: Fri, 31 Jul 2026 14:35:55 -0500 [thread overview]
Message-ID: <bd67f2e0-312d-4eea-a5ad-009554e3ea93@amd.com> (raw)
In-Reply-To: <e1631971b3862bcd6043199feba3df51f3ba336c.1784844080.git.ashish.kalra@amd.com>
On 7/27/26 14:04, Ashish Kalra wrote:
> From: Ashish Kalra <ashish.kalra@amd.com>
>
> While SNP is active, every memory write is checked against the RMP to
> protect SEV-SNP guest memory. A core performs these RMP checks only once
> SNP has been initialized via SNP_INIT and the SNP-enable bit in SYSCFG is
> set on that core; the firmware requires the SNP-enable bit to be set on
> every present CPU before SNP initialization.
>
> A core that is not SNP-enabled and not SNP-initialized performs no RMP
> checks at all, so there is no valid configuration with SNP active and any
> CPU exempt from RMP checks.
>
> The firmware determines which CPUs are present from the processor and the
> BIOS/UEFI configuration (e.g. SMT disabled in the BIOS) and enumerates
> them at SNP init; it is not aware of the OS bringing CPUs online or
> offline afterwards.
>
> SNP_INIT fails unless SnpEn is set on all CPUs, so a CPU that is offline
> when SNP_INIT is issued, does not have SnpEn set, SNP_INIT fails, and
> there can be no SNP guest memory. OS CPU hotplug can thus diverge from
> the firmware's expectations and break SNP.
>
> Tie CPU hotplug to the SNP-enable bit: disable it in snp_prepare() before
> SNP is enabled, and re-enable it in snp_shutdown() once the firmware has
> disabled SNP.
>
> If snp_prepare() fails before enabling SNP it re-enables hotplug itself;
> once SNP is enabled hotplug stays disabled, including across a failed
> SNP_INIT and across the legacy SNP_SHUTDOWN_EX path, both of which leave
> SNP enabled.
>
> A kexec target that boots with SNP already enabled, disables hotplug once
> in snp_rmptable_init(), since snp_prepare() bails when SNP is already
> enabled.
>
> With CPU hotplug now disabled while SNP is active, the online CPU mask is
> stable, so the cpus_read_lock() previously taken in snp_prepare() to
> iterate it is redundant. Drop cpus_read_lock()/cpus_read_unlock() here.
> The RMPOPT setup and cleanup added later are introduced after this patch
> and never take the lock for the same reason.
>
> Suggested-by: Thomas Lendacky <thomas.lendacky@amd.com>
> Suggested-by: Borislav Petkov (AMD) <bp@alien8.de>
> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
> ---
> arch/x86/virt/svm/sev.c | 39 +++++++++++++++++++++++++++++----------
> 1 file changed, 29 insertions(+), 10 deletions(-)
>
> diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
> index cff285d8ad8e..e2f69fba0938 100644
> --- a/arch/x86/virt/svm/sev.c
> +++ b/arch/x86/virt/svm/sev.c
> @@ -513,7 +513,6 @@ static void clear_hsave_pa(void *arg)
>
> int snp_prepare(void)
> {
> - int ret;
> u64 val;
>
> /*
> @@ -526,14 +525,21 @@ int snp_prepare(void)
>
> clear_rmp();
>
> - cpus_read_lock();
> + /*
> + * Disable CPU hotplug before enabling SNP: no CPU may come online
> + * without SnpEn while SNP is active, and none may go offline during
> + * enable. This keeps cpu_online_mask stable for the check and the
> + * on_each_cpu() calls below, so cpus_read_lock() is not needed. It is
> + * re-enabled in snp_shutdown() once the firmware disables SNP.
> + */
> + cpu_hotplug_disable();
>
> if (!cpumask_equal(cpu_online_mask, cpu_present_mask)) {
> - ret = -EOPNOTSUPP;
> + cpu_hotplug_enable();
> pr_warn("SNP init failed: not all CPUs online. (%*pbl online <-> %*pbl present masks).\n",
> cpumask_pr_args(cpu_online_mask),
> cpumask_pr_args(cpu_present_mask));
> - goto unlock;
> + return -EOPNOTSUPP;
> }
>
> wbinvd_on_all_cpus();
> @@ -548,12 +554,7 @@ int snp_prepare(void)
> /* SNP_INIT requires MSR_VM_HSAVE_PA to be cleared on all CPUs. */
> on_each_cpu(clear_hsave_pa, NULL, 1);
>
> - ret = 0;
> -
> -unlock:
> - cpus_read_unlock();
> -
> - return ret;
> + return 0;
> }
> EXPORT_SYMBOL_FOR_MODULES(snp_prepare, "ccp");
>
> @@ -565,6 +566,13 @@ void snp_shutdown(void)
> if (syscfg & MSR_AMD64_SYSCFG_SNP_EN)
> return;
>
> + /*
> + * The firmware has disabled SNP (SnpEn is clear), so re-enable CPU
> + * hotplug. A legacy SNP shutdown returns above with SnpEn still set and
> + * leaves hotplug disabled.
> + */
> + cpu_hotplug_enable();
> +
> clear_rmp();
> on_each_cpu(mfd_reconfigure, NULL, 1);
> }
> @@ -577,6 +585,8 @@ EXPORT_SYMBOL_FOR_MODULES(snp_shutdown, "ccp");
> */
> int __init snp_rmptable_init(void)
> {
> + u64 val;
> +
> if (WARN_ON_ONCE(!cc_platform_has(CC_ATTR_HOST_SEV_SNP)))
> return -ENOSYS;
>
> @@ -586,6 +596,15 @@ int __init snp_rmptable_init(void)
> if (!setup_rmptable())
> return -ENOSYS;
>
> + /*
> + * On a kexec boot SNP may already be enabled (legacy firmware leaves
> + * SnpEn set across shutdown), in which case snp_prepare() bails without
> + * disabling CPU hotplug, so disable it here.
> + */
> + rdmsrq(MSR_AMD64_SYSCFG, val);
> + if (val & MSR_AMD64_SYSCFG_SNP_EN)
> + cpu_hotplug_disable();
> +
Why not just put the cpu_hotplug_disable() at the start of snp_prepare()
then? Wouldn't that take care of both situations and only end up with a
single disable point?
Thanks,
Tom
> /*
> * Setting crash_kexec_post_notifiers to 'true' to ensure that SNP panic
> * notifier is invoked to do SNP IOMMU shutdown before kdump.
next prev parent reply other threads:[~2026-07-31 19:36 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-27 19:00 [PATCH v11 0/6] Add RMPOPT support Ashish Kalra
2026-07-27 19:03 ` [PATCH v11 1/6] x86/cpufeatures: Add X86_FEATURE_RMPOPT feature flag Ashish Kalra
2026-07-27 19:01 ` Ashish Kalra
2026-07-27 19:04 ` [PATCH v11 2/6] x86/sev: Disable CPU hotplug while SNP is active Ashish Kalra
2026-07-29 2:15 ` Borislav Petkov
2026-07-29 17:51 ` Kalra, Ashish
2026-07-31 19:35 ` Tom Lendacky [this message]
2026-07-31 20:27 ` Kalra, Ashish
2026-07-27 19:04 ` [PATCH v11 3/6] x86/sev: Initialize RMPOPT configuration MSRs Ashish Kalra
2026-07-30 2:07 ` Borislav Petkov
2026-07-30 2:55 ` K Prateek Nayak
2026-07-30 3:39 ` Borislav Petkov
2026-07-30 19:52 ` Kalra, Ashish
2026-07-30 20:00 ` Kalra, Ashish
2026-07-31 0:12 ` Borislav Petkov
2026-07-31 19:43 ` Tom Lendacky
2026-07-27 19:05 ` [PATCH v11 4/6] x86/sev: Add support to perform RMP optimizations asynchronously Ashish Kalra
2026-07-31 5:44 ` Borislav Petkov
2026-07-31 12:37 ` Kalra, Ashish
2026-07-31 20:14 ` Tom Lendacky
2026-07-27 19:05 ` [PATCH v11 5/6] x86/sev: Add interface to re-enable RMP optimizations Ashish Kalra
2026-07-27 19:06 ` [PATCH v11 6/6] KVM: SEV: Perform RMP optimizations on SNP guest shutdown Ashish Kalra
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=bd67f2e0-312d-4eea-a5ad-009554e3ea93@amd.com \
--to=thomas.lendacky@amd.com \
--cc=Ashish.Kalra@amd.com \
--cc=KPrateek.Nayak@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=john.allen@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=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