* [PATCH v14 1/5] x86/cpufeatures: Add X86_FEATURE_RMPOPT feature flag
2026-09-10 21:58 [PATCH v14 0/5] Add RMPOPT support Ashish Kalra
@ 2026-09-10 21:59 ` Ashish Kalra
2026-09-10 21:59 ` [PATCH v14 2/5] x86/sev: Disable CPU hotplug while SNP is active Ashish Kalra
` (3 subsequent siblings)
4 siblings, 0 replies; 11+ messages in thread
From: Ashish Kalra @ 2026-09-10 21:59 UTC (permalink / raw)
To: tglx, mingo, bp, dave.hansen, x86, hpa, seanjc, peterz,
thomas.lendacky, herbert, davem, ardb
Cc: pbonzini, aik, Michael.Roth, KPrateek.Nayak, Tycho.Andersen,
Nathan.Fontenot, ackerleytng, jackyli, pgonda, rientjes,
jacobhxu, xin, pawan.kumar.gupta, babu.moger, dyoung, nikunj,
darwi, linux-kernel, linux-crypto, kvm, linux-coco
From: Ashish Kalra <ashish.kalra@amd.com>
Add a flag indicating whether RMPOPT instruction is supported.
RMPOPT is a new instruction that reduces the performance overhead of RMP
checks for the hypervisor and non-SNP guests by allowing those checks to be
skipped when 1-GB memory regions are known to contain no SEV-SNP guest memory.
For more information on the RMPOPT instruction, see the AMD64 RMPOPT
technical documentation.
[ bp: Zap respective tools/ change. ]
Suggested-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Link: https://patch.msgid.link/39e9ee269a572c516a3f4e937bfe12d00697d5e6.1782841284.git.ashish.kalra@amd.com
---
arch/x86/include/asm/cpufeatures.h | 2 +-
arch/x86/kernel/cpu/scattered.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index f70ee74b5f92..3b5b32d3391b 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -76,7 +76,7 @@
#define X86_FEATURE_K8 ( 3*32+ 4) /* Opteron, Athlon64 */
#define X86_FEATURE_ZEN5 ( 3*32+ 5) /* CPU based on Zen5 microarchitecture */
#define X86_FEATURE_ZEN6 ( 3*32+ 6) /* CPU based on Zen6 microarchitecture */
-/* Free ( 3*32+ 7) */
+#define X86_FEATURE_RMPOPT ( 3*32+ 7) /* Support for AMD RMPOPT instruction */
#define X86_FEATURE_CONSTANT_TSC ( 3*32+ 8) /* "constant_tsc" TSC ticks at a constant rate */
/* free: was #define X86_FEATURE_UP ( 3*32+ 9) * "up" SMP kernel running on UP */
#define X86_FEATURE_ART ( 3*32+10) /* "art" Always running timer (ART) */
diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
index 8665a6474806..d1795ce219da 100644
--- a/arch/x86/kernel/cpu/scattered.c
+++ b/arch/x86/kernel/cpu/scattered.c
@@ -67,6 +67,7 @@ static const struct cpuid_bit cpuid_bits[] = {
{ X86_FEATURE_PERFMON_V2, CPUID_EAX, 0, 0x80000022, 0 },
{ X86_FEATURE_AMD_LBR_V2, CPUID_EAX, 1, 0x80000022, 0 },
{ X86_FEATURE_AMD_LBR_PMC_FREEZE, CPUID_EAX, 2, 0x80000022, 0 },
+ { X86_FEATURE_RMPOPT, CPUID_EDX, 0, 0x80000025, 0 },
{ X86_FEATURE_AMD_HTR_CORES, CPUID_EAX, 30, 0x80000026, 0 },
{ 0, 0, 0, 0, 0 }
};
--
2.43.0
^ permalink raw reply [flat|nested] 11+ messages in thread* [PATCH v14 2/5] x86/sev: Disable CPU hotplug while SNP is active
2026-09-10 21:58 [PATCH v14 0/5] Add RMPOPT support Ashish Kalra
2026-09-10 21:59 ` [PATCH v14 1/5] x86/cpufeatures: Add X86_FEATURE_RMPOPT feature flag Ashish Kalra
@ 2026-09-10 21:59 ` Ashish Kalra
2026-09-10 21:59 ` [PATCH v14 3/5] x86/sev: Initialize RMPOPT configuration MSRs Ashish Kalra
` (2 subsequent siblings)
4 siblings, 0 replies; 11+ messages in thread
From: Ashish Kalra @ 2026-09-10 21:59 UTC (permalink / raw)
To: tglx, mingo, bp, dave.hansen, x86, hpa, seanjc, peterz,
thomas.lendacky, herbert, davem, ardb
Cc: pbonzini, aik, Michael.Roth, KPrateek.Nayak, Tycho.Andersen,
Nathan.Fontenot, ackerleytng, jackyli, pgonda, rientjes,
jacobhxu, xin, pawan.kumar.gupta, babu.moger, dyoung, nikunj,
darwi, linux-kernel, linux-crypto, kvm, linux-coco
From: Ashish Kalra <ashish.kalra@amd.com>
While SNP is active, every memory write is checked against the RMP to
protect 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.
Suggested-by: Thomas Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
---
arch/x86/virt/svm/sev.c | 36 ++++++++++++++++++++++++++----------
1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
index cff285d8ad8e..558f7924a3f8 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,18 @@ int snp_prepare(void)
clear_rmp();
- cpus_read_lock();
+ /*
+ * No CPU may come online without SnpEn while SNP is active; disable
+ * hotplug here and re-enable it in snp_shutdown().
+ */
+ 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 +551,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");
@@ -567,6 +565,13 @@ void snp_shutdown(void)
clear_rmp();
on_each_cpu(mfd_reconfigure, NULL, 1);
+
+ /*
+ * 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();
}
EXPORT_SYMBOL_FOR_MODULES(snp_shutdown, "ccp");
@@ -577,6 +582,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 +593,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();
+
/*
* Setting crash_kexec_post_notifiers to 'true' to ensure that SNP panic
* notifier is invoked to do SNP IOMMU shutdown before kdump.
--
2.43.0
^ permalink raw reply [flat|nested] 11+ messages in thread* [PATCH v14 3/5] x86/sev: Initialize RMPOPT configuration MSRs
2026-09-10 21:58 [PATCH v14 0/5] Add RMPOPT support Ashish Kalra
2026-09-10 21:59 ` [PATCH v14 1/5] x86/cpufeatures: Add X86_FEATURE_RMPOPT feature flag Ashish Kalra
2026-09-10 21:59 ` [PATCH v14 2/5] x86/sev: Disable CPU hotplug while SNP is active Ashish Kalra
@ 2026-09-10 21:59 ` Ashish Kalra
2026-09-10 22:00 ` [PATCH v14 4/5] x86/sev: Perform RMP optimizations asynchronously Ashish Kalra
2026-09-10 22:00 ` [PATCH v14 5/5] x86/sev: Re-enable RMP optimizations on SNP guest shutdown Ashish Kalra
4 siblings, 0 replies; 11+ messages in thread
From: Ashish Kalra @ 2026-09-10 21:59 UTC (permalink / raw)
To: tglx, mingo, bp, dave.hansen, x86, hpa, seanjc, peterz,
thomas.lendacky, herbert, davem, ardb
Cc: pbonzini, aik, Michael.Roth, KPrateek.Nayak, Tycho.Andersen,
Nathan.Fontenot, ackerleytng, jackyli, pgonda, rientjes,
jacobhxu, xin, pawan.kumar.gupta, babu.moger, dyoung, nikunj,
darwi, linux-kernel, linux-crypto, kvm, linux-coco
From: Ashish Kalra <ashish.kalra@amd.com>
The new RMPOPT instruction helps manage per-CPU RMP optimization
structures inside the CPU. It takes a 1GB-aligned physical address
and either returns the status of the optimizations or tries to enable
the optimizations.
Per-CPU RMPOPT tables support at most 2 TB of addressable memory for
RMP optimizations.
Initialize the per-CPU RMPOPT table base to the starting physical
address. This enables RMP optimization for up to 2 TB of system RAM on
all CPUs.
Additionally, add support to setup and enable RMPOPT once SNP is
enabled and initialized.
Suggested-by: Thomas Lendacky <thomas.lendacky@amd.com>
Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
---
v14: rmpopt_disable() and the RMPOPT_BASE teardown were removed from this
patch (the disable path is reworked in the next patch, and the MSRs are
now left in place on shutdown). Dropped Reviewed-by: Dave Hansen and
Tom Lendacky due to this rework.
arch/x86/include/asm/msr-index.h | 3 +++
arch/x86/include/asm/sev.h | 2 ++
arch/x86/virt/svm/sev.c | 46 ++++++++++++++++++++++++++++----
drivers/crypto/ccp/sev-dev.c | 2 ++
4 files changed, 48 insertions(+), 5 deletions(-)
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 3a8e51a0c9e8..1635e2e1c576 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -761,6 +761,9 @@
#define MSR_AMD64_SEG_RMP_ENABLED_BIT 0
#define MSR_AMD64_SEG_RMP_ENABLED BIT_ULL(MSR_AMD64_SEG_RMP_ENABLED_BIT)
#define MSR_AMD64_RMP_SEGMENT_SHIFT(x) (((x) & GENMASK_ULL(13, 8)) >> 8)
+#define MSR_AMD64_RMPOPT_BASE 0xc0010139
+#define MSR_AMD64_RMPOPT_ENABLE_BIT 0
+#define MSR_AMD64_RMPOPT_ENABLE BIT_ULL(MSR_AMD64_RMPOPT_ENABLE_BIT)
#define MSR_SVSM_CAA 0xc001f000
diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
index 9e7a077c445d..5638d09b5132 100644
--- a/arch/x86/include/asm/sev.h
+++ b/arch/x86/include/asm/sev.h
@@ -662,6 +662,7 @@ static inline void snp_leak_pages(u64 pfn, unsigned int pages)
__snp_leak_pages(pfn, pages, true);
}
int snp_prepare(void);
+void snp_setup_rmpopt(void);
void snp_shutdown(void);
#else
static inline bool snp_probe_rmptable_info(void) { return false; }
@@ -680,6 +681,7 @@ static inline void snp_leak_pages(u64 pfn, unsigned int npages) {}
static inline void kdump_sev_callback(void) { }
static inline void snp_fixup_e820_tables(void) {}
static inline int snp_prepare(void) { return -ENODEV; }
+static inline void snp_setup_rmpopt(void) {}
static inline void snp_shutdown(void) {}
#endif
diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
index 558f7924a3f8..a059327dc107 100644
--- a/arch/x86/virt/svm/sev.c
+++ b/arch/x86/virt/svm/sev.c
@@ -124,6 +124,8 @@ static void *rmp_bookkeeping __ro_after_init;
static u64 probed_rmp_base, probed_rmp_size;
+static phys_addr_t rmpopt_pa_start;
+
static LIST_HEAD(snp_leaked_pages_list);
static DEFINE_SPINLOCK(snp_leaked_pages_list_lock);
@@ -575,6 +577,32 @@ void snp_shutdown(void)
}
EXPORT_SYMBOL_FOR_MODULES(snp_shutdown, "ccp");
+static bool rmpopt_capable(void)
+{
+ return cpu_feature_enabled(X86_FEATURE_RMPOPT) &&
+ cc_platform_has(CC_ATTR_HOST_SEV_SNP);
+}
+
+void snp_setup_rmpopt(void)
+{
+ u64 rmpopt_base;
+ int cpu;
+
+ if (!rmpopt_capable())
+ return;
+
+ rmpopt_pa_start = ALIGN_DOWN(PFN_PHYS(min_low_pfn), SZ_1G);
+ rmpopt_base = rmpopt_pa_start | MSR_AMD64_RMPOPT_ENABLE;
+
+ /*
+ * Per-CPU RMPOPT tables cover at most 2 TB. Program each core's
+ * RMPOPT_BASE with the start of RAM to optimize up to 2 TB.
+ */
+ for_each_cpu(cpu, cpu_primary_thread_mask)
+ wrmsrq_on_cpu(cpu, MSR_AMD64_RMPOPT_BASE, rmpopt_base);
+}
+EXPORT_SYMBOL_FOR_MODULES(snp_setup_rmpopt, "ccp");
+
/*
* Do the necessary preparations which are verified by the firmware as
* described in the SNP_INIT_EX firmware command description in the SNP
@@ -699,13 +727,21 @@ static bool probe_segmented_rmptable_info(void)
bool snp_probe_rmptable_info(void)
{
- if (cpu_feature_enabled(X86_FEATURE_SEGMENTED_RMP))
+ if (cpu_feature_enabled(X86_FEATURE_SEGMENTED_RMP)) {
rdmsrq(MSR_AMD64_RMP_CFG, rmp_cfg);
- if (rmp_cfg & MSR_AMD64_SEG_RMP_ENABLED)
- return probe_segmented_rmptable_info();
- else
- return probe_contiguous_rmptable_info();
+ if (rmp_cfg & MSR_AMD64_SEG_RMP_ENABLED)
+ return probe_segmented_rmptable_info();
+ }
+
+ /*
+ * Segmented RMP is either not supported on the platform or is
+ * disabled by the firmware. RMPOPT is not supported without
+ * segmented RMP.
+ */
+ setup_clear_cpu_cap(X86_FEATURE_RMPOPT);
+
+ return probe_contiguous_rmptable_info();
}
/*
diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
index f833cb7e4da3..287a8345854b 100644
--- a/drivers/crypto/ccp/sev-dev.c
+++ b/drivers/crypto/ccp/sev-dev.c
@@ -1663,6 +1663,8 @@ static int __sev_snp_init_locked(int *error, unsigned int max_snp_asid)
sev_es_tmr_size = SNP_TMR_SIZE;
+ snp_setup_rmpopt();
+
return 0;
}
--
2.43.0
^ permalink raw reply [flat|nested] 11+ messages in thread* [PATCH v14 4/5] x86/sev: Perform RMP optimizations asynchronously
2026-09-10 21:58 [PATCH v14 0/5] Add RMPOPT support Ashish Kalra
` (2 preceding siblings ...)
2026-09-10 21:59 ` [PATCH v14 3/5] x86/sev: Initialize RMPOPT configuration MSRs Ashish Kalra
@ 2026-09-10 22:00 ` Ashish Kalra
2026-09-12 1:53 ` Borislav Petkov
2026-09-10 22:00 ` [PATCH v14 5/5] x86/sev: Re-enable RMP optimizations on SNP guest shutdown Ashish Kalra
4 siblings, 1 reply; 11+ messages in thread
From: Ashish Kalra @ 2026-09-10 22:00 UTC (permalink / raw)
To: tglx, mingo, bp, dave.hansen, x86, hpa, seanjc, peterz,
thomas.lendacky, herbert, davem, ardb
Cc: pbonzini, aik, Michael.Roth, KPrateek.Nayak, Tycho.Andersen,
Nathan.Fontenot, ackerleytng, jackyli, pgonda, rientjes,
jacobhxu, xin, pawan.kumar.gupta, babu.moger, dyoung, nikunj,
darwi, linux-kernel, linux-crypto, kvm, linux-coco
From: Ashish Kalra <ashish.kalra@amd.com>
When SNP is enabled, all writes to memory are checked to ensure memory
integrity. This imposes performance overhead on the whole system.
RMPOPT is a new instruction that minimizes the performance overhead of
RMP checks on the hypervisor and on non-SNP guests by allowing RMP
checks to be skipped for 1GB regions of memory that are known not to
contain any SNP guest memory.
Add support for performing RMP optimizations asynchronously using a
dedicated workqueue.
At RMP initialization time, run an optimization pass over all physical
memory (up to 2TB of system RAM, starting from the lowest physical
memory address aligned down to a 1GB boundary), skipping RMP checks for
1GB regions that do not contain SNP guest memory (excluding preassigned
pages such as the RMP table and firmware pages).
As SNP guests are launched, RMPUPDATE assigns their private pages to
guest-owned state; when such a page falls within an optimized 1GB
region, the hardware clears that region's RMPOPT optimization and RMP
checks resume there to protect the guest memory.
Since launching SNP guests clears these optimizations, perform them
again asynchronously using the dedicated workqueue.
Suggested-by: Thomas Lendacky <thomas.lendacky@amd.com>
Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
---
v14: Reworked the setup/teardown - initialize once and do not tear it down;
rmpopt_disable() now only cancels the pending pass. Use a dedicated
per-CPU workqueue (WQ_PERCPU) and drop the migrate_disable()/
migrate_enable() around the local scan. Added a binutils-version
comment above the RMPOPT .byte and trimmed redundant comments and the
2 TB pr_info(). Subject reworded from "Add support to perform RMP
optimizations asynchronously". Dropped Reviewed-by: Ackerley Tng and
Tom Lendacky due to the rework (kept Suggested-by).
arch/x86/virt/svm/sev.c | 92 ++++++++++++++++++++++++++++++++++++++++-
1 file changed, 91 insertions(+), 1 deletion(-)
diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
index a059327dc107..35678b1f535d 100644
--- a/arch/x86/virt/svm/sev.c
+++ b/arch/x86/virt/svm/sev.c
@@ -19,6 +19,7 @@
#include <linux/iommu.h>
#include <linux/amd-iommu.h>
#include <linux/nospec.h>
+#include <linux/workqueue.h>
#include <asm/sev.h>
#include <asm/processor.h>
@@ -124,7 +125,16 @@ static void *rmp_bookkeeping __ro_after_init;
static u64 probed_rmp_base, probed_rmp_size;
-static phys_addr_t rmpopt_pa_start;
+static u64 rmpopt_pa_start, rmpopt_pa_end;
+
+enum rmpopt_op_type {
+ RMPOPT_OP_VERIFY_AND_REPORT_STATUS,
+ RMPOPT_OP_REPORT_STATUS
+};
+
+static struct workqueue_struct *rmpopt_wq;
+static struct delayed_work rmpopt_delayed_work;
+static DEFINE_MUTEX(rmpopt_wq_mutex);
static LIST_HEAD(snp_leaked_pages_list);
static DEFINE_SPINLOCK(snp_leaked_pages_list_lock);
@@ -557,6 +567,14 @@ int snp_prepare(void)
}
EXPORT_SYMBOL_FOR_MODULES(snp_prepare, "ccp");
+static void rmpopt_disable(void)
+{
+ guard(mutex)(&rmpopt_wq_mutex);
+
+ if (rmpopt_wq)
+ cancel_delayed_work_sync(&rmpopt_delayed_work);
+}
+
void snp_shutdown(void)
{
u64 syscfg;
@@ -565,6 +583,8 @@ void snp_shutdown(void)
if (syscfg & MSR_AMD64_SYSCFG_SNP_EN)
return;
+ rmpopt_disable();
+
clear_rmp();
on_each_cpu(mfd_reconfigure, NULL, 1);
@@ -583,6 +603,43 @@ static bool rmpopt_capable(void)
cc_platform_has(CC_ATTR_HOST_SEV_SNP);
}
+/*
+ * RMPOPT optimizations skip RMP checks at 1GB granularity if this range of
+ * memory does not contain any SNP guest memory.
+ *
+ * @pa is a system physical address; RMPOPT operates on the containing 1GB.
+ */
+static void rmpopt(u64 pa)
+{
+ enum rmpopt_op_type op = RMPOPT_OP_VERIFY_AND_REPORT_STATUS;
+ u64 pa_start = ALIGN_DOWN(pa, SZ_1G);
+
+ /* Supported by binutils 2.48+ */
+ asm volatile(".byte 0xf2, 0x0f, 0x01, 0xfc"
+ :: "a" (pa_start), "c" (op)
+ : "memory", "cc");
+}
+
+/* on_each_cpu() callback: optimize the whole RMPOPT range on this CPU. */
+static void rmpopt_scan_range(void *arg)
+{
+ u64 pa;
+
+ for (pa = rmpopt_pa_start; pa < rmpopt_pa_end; pa += SZ_1G)
+ rmpopt(pa);
+}
+
+static void do_rmpopt_work(struct work_struct *work)
+{
+ /*
+ * Warm up the RMPOPT cache on this pinned per-CPU worker with interrupts
+ * on, so the IRQ-disabled fan-out below only issues cache-hit RMPOPTs.
+ */
+ rmpopt_scan_range(NULL);
+
+ on_each_cpu_mask(cpu_primary_thread_mask, rmpopt_scan_range, NULL, true);
+}
+
void snp_setup_rmpopt(void)
{
u64 rmpopt_base;
@@ -591,6 +648,30 @@ void snp_setup_rmpopt(void)
if (!rmpopt_capable())
return;
+ guard(mutex)(&rmpopt_wq_mutex);
+
+ /*
+ * Set up once: the workqueue and RMPOPT_BASE MSRs are left in place on
+ * shutdown, so a later re-initialization just re-queues the optimization
+ * pass rather than redoing the setup.
+ */
+ if (rmpopt_wq) {
+ queue_delayed_work(rmpopt_wq, &rmpopt_delayed_work, 0);
+ return;
+ }
+
+ /*
+ * Use a dedicated per-CPU workqueue so the potentially lengthy warm-up
+ * scan does not tie up a shared workqueue worker.
+ */
+ rmpopt_wq = alloc_workqueue("rmpopt_wq", WQ_PERCPU, 1);
+ if (!rmpopt_wq) {
+ pr_err("Failed to allocate RMPOPT workqueue\n");
+ return;
+ }
+
+ INIT_DELAYED_WORK(&rmpopt_delayed_work, do_rmpopt_work);
+
rmpopt_pa_start = ALIGN_DOWN(PFN_PHYS(min_low_pfn), SZ_1G);
rmpopt_base = rmpopt_pa_start | MSR_AMD64_RMPOPT_ENABLE;
@@ -600,6 +681,15 @@ void snp_setup_rmpopt(void)
*/
for_each_cpu(cpu, cpu_primary_thread_mask)
wrmsrq_on_cpu(cpu, MSR_AMD64_RMPOPT_BASE, rmpopt_base);
+
+ rmpopt_pa_end = ALIGN(PFN_PHYS(max_pfn), SZ_1G);
+
+ if ((rmpopt_pa_end - rmpopt_pa_start) > SZ_2T)
+ rmpopt_pa_end = rmpopt_pa_start + SZ_2T;
+
+ queue_delayed_work(rmpopt_wq, &rmpopt_delayed_work, 0);
+
+ pr_info("RMPOPT optimizations enabled\n");
}
EXPORT_SYMBOL_FOR_MODULES(snp_setup_rmpopt, "ccp");
--
2.43.0
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH v14 4/5] x86/sev: Perform RMP optimizations asynchronously
2026-09-10 22:00 ` [PATCH v14 4/5] x86/sev: Perform RMP optimizations asynchronously Ashish Kalra
@ 2026-09-12 1:53 ` Borislav Petkov
2026-09-14 20:00 ` Kalra, Ashish
0 siblings, 1 reply; 11+ messages in thread
From: Borislav Petkov @ 2026-09-12 1:53 UTC (permalink / raw)
To: Ashish Kalra
Cc: tglx, mingo, dave.hansen, x86, hpa, seanjc, peterz,
thomas.lendacky, herbert, davem, ardb, pbonzini, aik,
Michael.Roth, KPrateek.Nayak, Tycho.Andersen, Nathan.Fontenot,
ackerleytng, jackyli, pgonda, rientjes, jacobhxu, xin,
pawan.kumar.gupta, babu.moger, dyoung, nikunj, darwi,
linux-kernel, linux-crypto, kvm, linux-coco
On Thu, Sep 10, 2026 at 10:00:08PM +0000, Ashish Kalra wrote:
> void snp_setup_rmpopt(void)
> {
> u64 rmpopt_base;
> @@ -591,6 +648,30 @@ void snp_setup_rmpopt(void)
> if (!rmpopt_capable())
> return;
>
> + guard(mutex)(&rmpopt_wq_mutex);
> +
> + /*
> + * Set up once: the workqueue and RMPOPT_BASE MSRs are left in place on
> + * shutdown, so a later re-initialization just re-queues the optimization
> + * pass rather than redoing the setup.
> + */
> + if (rmpopt_wq) {
> + queue_delayed_work(rmpopt_wq, &rmpopt_delayed_work, 0);
> + return;
> + }
No, this is not how this is done. This is a *setup* function but you also use
it to start the workqueue if it has been allocated already. So it should
either setup or start but not both.
So what you do is, you try to allocate the workqueue. If it fails, you clear
X86_FEATURE_RMPOPT so that rmpopt_capable() is false and that can be your
start_workqueue function.
This way you get rid of all that
if (rmpopt_wq)
sprinkles everywhere.
> +
> + /*
> + * Use a dedicated per-CPU workqueue so the potentially lengthy warm-up
> + * scan does not tie up a shared workqueue worker.
> + */
> + rmpopt_wq = alloc_workqueue("rmpopt_wq", WQ_PERCPU, 1);
> + if (!rmpopt_wq) {
> + pr_err("Failed to allocate RMPOPT workqueue\n");
> + return;
> + }
> +
> + INIT_DELAYED_WORK(&rmpopt_delayed_work, do_rmpopt_work);
> +
> rmpopt_pa_start = ALIGN_DOWN(PFN_PHYS(min_low_pfn), SZ_1G);
> rmpopt_base = rmpopt_pa_start | MSR_AMD64_RMPOPT_ENABLE;
>
> @@ -600,6 +681,15 @@ void snp_setup_rmpopt(void)
> */
> for_each_cpu(cpu, cpu_primary_thread_mask)
> wrmsrq_on_cpu(cpu, MSR_AMD64_RMPOPT_BASE, rmpopt_base);
> +
> + rmpopt_pa_end = ALIGN(PFN_PHYS(max_pfn), SZ_1G);
> +
> + if ((rmpopt_pa_end - rmpopt_pa_start) > SZ_2T)
> + rmpopt_pa_end = rmpopt_pa_start + SZ_2T;
> +
> + queue_delayed_work(rmpopt_wq, &rmpopt_delayed_work, 0);
> +
> + pr_info("RMPOPT optimizations enabled\n");
> }
> EXPORT_SYMBOL_FOR_MODULES(snp_setup_rmpopt, "ccp");
There is no ccp driver patch calling this so this export needs to happen when
you're actually adding the ccp code.
Same thing for the snp_rmpopt_all_physmem() export to kvm-amd.
Looking at this more, I would like to get rid of the snp_setup_rmpopt() export
and have this function do the necessary setup stuff from an initcall in this
file. This way you set up the stuff at kernel init time and have everything
ready to go.
Then the ccp will *only* call a function which is called snp_enable_rmpopt()
after it has enabled SNP. That function simply enables the workqueue.
And then kvm-amd can call that function too so we end up with one export.
Oh, and you can zap those comments while at it:
diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
index ca99617142be..c8ba71431a5e 100644
--- a/arch/x86/virt/svm/sev.c
+++ b/arch/x86/virt/svm/sev.c
@@ -619,7 +619,6 @@ static void rmpopt(u64 pa)
: "memory", "cc");
}
-/* on_each_cpu() callback: optimize the whole RMPOPT range on this CPU. */
static void rmpopt_scan_range(void *arg)
{
u64 pa;
@@ -632,7 +631,7 @@ static void do_rmpopt_work(struct work_struct *work)
{
/*
* Warm up the RMPOPT cache on this pinned per-CPU worker with interrupts
- * on, so the IRQ-disabled fan-out below only issues cache-hit RMPOPTs.
+ * enabled, so the IRQ-disabled fan-out below only issues cache-hit RMPOPTs.
*/
rmpopt_scan_range(NULL);
@@ -649,11 +648,6 @@ void snp_setup_rmpopt(void)
guard(mutex)(&rmpopt_wq_mutex);
- /*
- * Set up once: the workqueue and RMPOPT_BASE MSRs are left in place on
- * shutdown, so a later re-initialization just re-queues the optimization
- * pass rather than redoing the setup.
- */
if (rmpopt_wq) {
queue_delayed_work(rmpopt_wq, &rmpopt_delayed_work, 0);
return;
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH v14 4/5] x86/sev: Perform RMP optimizations asynchronously
2026-09-12 1:53 ` Borislav Petkov
@ 2026-09-14 20:00 ` Kalra, Ashish
2026-09-14 23:15 ` Borislav Petkov
0 siblings, 1 reply; 11+ messages in thread
From: Kalra, Ashish @ 2026-09-14 20:00 UTC (permalink / raw)
To: Borislav Petkov
Cc: tglx, mingo, dave.hansen, x86, hpa, seanjc, peterz,
thomas.lendacky, herbert, davem, ardb, pbonzini, aik,
Michael.Roth, KPrateek.Nayak, Tycho.Andersen, Nathan.Fontenot,
ackerleytng, jackyli, pgonda, rientjes, jacobhxu, xin,
pawan.kumar.gupta, babu.moger, dyoung, nikunj, darwi,
linux-kernel, linux-crypto, kvm, linux-coco
Hello Boris,
On 9/11/2026 8:53 PM, Borislav Petkov wrote:
> On Thu, Sep 10, 2026 at 10:00:08PM +0000, Ashish Kalra wrote:
>> void snp_setup_rmpopt(void)
>> {
>> u64 rmpopt_base;
>> @@ -591,6 +648,30 @@ void snp_setup_rmpopt(void)
>> if (!rmpopt_capable())
>> return;
>>
>> + guard(mutex)(&rmpopt_wq_mutex);
>> +
>> + /*
>> + * Set up once: the workqueue and RMPOPT_BASE MSRs are left in place on
>> + * shutdown, so a later re-initialization just re-queues the optimization
>> + * pass rather than redoing the setup.
>> + */
>> + if (rmpopt_wq) {
>> + queue_delayed_work(rmpopt_wq, &rmpopt_delayed_work, 0);
>> + return;
>> + }
>
> No, this is not how this is done. This is a *setup* function but you also use
> it to start the workqueue if it has been allocated already. So it should
> either setup or start but not both.
>
> So what you do is, you try to allocate the workqueue. If it fails, you clear
> X86_FEATURE_RMPOPT so that rmpopt_capable() is false and that can be your
> start_workqueue function.
>
> This way you get rid of all that
>
> if (rmpopt_wq)
>
> sprinkles everywhere.
>
>> +
>> + /*
>> + * Use a dedicated per-CPU workqueue so the potentially lengthy warm-up
>> + * scan does not tie up a shared workqueue worker.
>> + */
>> + rmpopt_wq = alloc_workqueue("rmpopt_wq", WQ_PERCPU, 1);
>> + if (!rmpopt_wq) {
>> + pr_err("Failed to allocate RMPOPT workqueue\n");
>> + return;
>> + }
>> +
>> + INIT_DELAYED_WORK(&rmpopt_delayed_work, do_rmpopt_work);
>> +
>> rmpopt_pa_start = ALIGN_DOWN(PFN_PHYS(min_low_pfn), SZ_1G);
>> rmpopt_base = rmpopt_pa_start | MSR_AMD64_RMPOPT_ENABLE;
>>
>> @@ -600,6 +681,15 @@ void snp_setup_rmpopt(void)
>> */
>> for_each_cpu(cpu, cpu_primary_thread_mask)
>> wrmsrq_on_cpu(cpu, MSR_AMD64_RMPOPT_BASE, rmpopt_base);
>> +
>> + rmpopt_pa_end = ALIGN(PFN_PHYS(max_pfn), SZ_1G);
>> +
>> + if ((rmpopt_pa_end - rmpopt_pa_start) > SZ_2T)
>> + rmpopt_pa_end = rmpopt_pa_start + SZ_2T;
>> +
>> + queue_delayed_work(rmpopt_wq, &rmpopt_delayed_work, 0);
>> +
>> + pr_info("RMPOPT optimizations enabled\n");
>> }
>> EXPORT_SYMBOL_FOR_MODULES(snp_setup_rmpopt, "ccp");
>
> There is no ccp driver patch calling this so this export needs to happen when
> you're actually adding the ccp code.
>
> Same thing for the snp_rmpopt_all_physmem() export to kvm-amd.
>
> Looking at this more, I would like to get rid of the snp_setup_rmpopt() export
> and have this function do the necessary setup stuff from an initcall in this
> file. This way you set up the stuff at kernel init time and have everything
> ready to go.
>
> Then the ccp will *only* call a function which is called snp_enable_rmpopt()
> after it has enabled SNP. That function simply enables the workqueue.
>
> And then kvm-amd can call that function too so we end up with one export.
>
Thanks, Boris. Splitting setup from start and collapsing to a single export makes sense — a couple of constraints from the RMPOPT
spec shape how it has to be done.
RMPOPT_BASE can only be written (RMPOPT_EN set) when SYSCFG[SnpEn] and RMP_CFG[SegmentedRmpEn] are both 1; otherwise the access
#GP(0)s. So the MSR programming can't run from an init‑time initcall — SnpEn is 0 then and it would #GP. The software setup can,
though, so the split becomes:
- an initcall in this file does the software setup — allocate the workqueue and INIT_DELAYED_WORK(), no export;
- snp_enable_rmpopt() (the single export) programs RMPOPT_BASE on the primary threads and queues the pass. ccp calls it after it
has enabled SNP, and kvm‑amd calls it on teardown.
The same spec text makes that single entry point safe to call repeatedly: RMPOPT_BASE_ADDR is read‑only once RMPOPT_EN is 1 (and
RMPOPT_EN can't be cleared while SnpEn is 1), so a later call's write is a probably a no‑op rather than a reprogram. If we want
to avoid even the redundant IPIs, snp_enable_rmpopt() can read RMPOPT_BASE and skip programming when RMPOPT_EN is already set — a
hardware‑state check instead of an if (rmpopt_wq).
On clearing X86_FEATURE_RMPOPT when the allocation fails: that hits the problem we ran into in earlier revisions — the workqueue
allocation is at initcall time, after alternatives are patched, where setup_clear_cpu_cap() isn't reliable (static_cpu_has() is
already baked in), so clearing the cap won't flip rmpopt_capable(). The setup/enable split removes most of the if (rmpopt_wq)
checks anyway; the only one left is a single guard in snp_enable_rmpopt() for the (rare) allocation‑failure case, which I will
probably like to keep rather than rely on clearing the feature.
I'll respin as v15 with the setup/enable split once we settle the feature‑clear question and the RMPOPT_BASE MSR programming
question (i.e., skipping it if RMPOPT_EN is already set).
> Oh, and you can zap those comments while at it:
Yes, i will fix the comments as below.
Thanks,
Ashish
>
> diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
> index ca99617142be..c8ba71431a5e 100644
> --- a/arch/x86/virt/svm/sev.c
> +++ b/arch/x86/virt/svm/sev.c
> @@ -619,7 +619,6 @@ static void rmpopt(u64 pa)
> : "memory", "cc");
> }
>
> -/* on_each_cpu() callback: optimize the whole RMPOPT range on this CPU. */
> static void rmpopt_scan_range(void *arg)
> {
> u64 pa;
> @@ -632,7 +631,7 @@ static void do_rmpopt_work(struct work_struct *work)
> {
> /*
> * Warm up the RMPOPT cache on this pinned per-CPU worker with interrupts
> - * on, so the IRQ-disabled fan-out below only issues cache-hit RMPOPTs.
> + * enabled, so the IRQ-disabled fan-out below only issues cache-hit RMPOPTs.
> */
> rmpopt_scan_range(NULL);
>
> @@ -649,11 +648,6 @@ void snp_setup_rmpopt(void)
>
> guard(mutex)(&rmpopt_wq_mutex);
>
> - /*
> - * Set up once: the workqueue and RMPOPT_BASE MSRs are left in place on
> - * shutdown, so a later re-initialization just re-queues the optimization
> - * pass rather than redoing the setup.
> - */
> if (rmpopt_wq) {
> queue_delayed_work(rmpopt_wq, &rmpopt_delayed_work, 0);
> return;
>
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH v14 4/5] x86/sev: Perform RMP optimizations asynchronously
2026-09-14 20:00 ` Kalra, Ashish
@ 2026-09-14 23:15 ` Borislav Petkov
2026-09-15 21:04 ` Kalra, Ashish
0 siblings, 1 reply; 11+ messages in thread
From: Borislav Petkov @ 2026-09-14 23:15 UTC (permalink / raw)
To: Kalra, Ashish
Cc: tglx, mingo, dave.hansen, x86, hpa, seanjc, peterz,
thomas.lendacky, herbert, davem, ardb, pbonzini, aik,
Michael.Roth, KPrateek.Nayak, Tycho.Andersen, Nathan.Fontenot,
ackerleytng, jackyli, pgonda, rientjes, jacobhxu, xin,
pawan.kumar.gupta, babu.moger, dyoung, nikunj, darwi,
linux-kernel, linux-crypto, kvm, linux-coco
On Mon, Sep 14, 2026 at 03:00:04PM -0500, Kalra, Ashish wrote:
> Thanks, Boris. Splitting setup from start and collapsing to a single export makes sense — a couple of constraints from the RMPOPT
> spec shape how it has to be done.
>
> RMPOPT_BASE can only be written (RMPOPT_EN set) when SYSCFG[SnpEn] and RMP_CFG[SegmentedRmpEn] are both 1; otherwise the access
> #GP(0)s. So the MSR programming can't run from an init‑time initcall — SnpEn is 0 then and it would #GP. The software setup can,
> though, so the split becomes:
>
> - an initcall in this file does the software setup — allocate the workqueue and INIT_DELAYED_WORK(), no export;
> - snp_enable_rmpopt() (the single export) programs RMPOPT_BASE on the primary threads and queues the pass. ccp calls it after it
> has enabled SNP, and kvm‑amd calls it on teardown.
This programming sure sounds like something we don't need to repeat each time
we enable RMPOPT...
rmpopt_pa_start is practically static so I'd love it if those MSRs are written
once and that's it. The question is, do they keep their value when we disable
SNP?
And I can basically imagine the answer from hw folks: "yeah, yeah, maybe, but
to be on the safe side, you should always write them after having enabled
SNP."
Because if not, I'd be perfectly fine with us setting them on the *first* SNP
init and not touching them again.
IOW, this pseudo:
if (!rdmsr(RMPOPT_BASE))
wrmsr(RMPOPT_BASE, ...):
This should probably be in the snp_enable_rmpopt() function anyway as it
should do what we want.
> The same spec text makes that single entry point safe to call repeatedly: RMPOPT_BASE_ADDR is read‑only once RMPOPT_EN is 1 (and
> RMPOPT_EN can't be cleared while SnpEn is 1), so a later call's write is a probably a no‑op rather than a reprogram. If we want
> to avoid even the redundant IPIs, snp_enable_rmpopt() can read RMPOPT_BASE and skip programming when RMPOPT_EN is already set — a
> hardware‑state check instead of an if (rmpopt_wq).
Yap, or that. Sounds ok to me if it works.
> On clearing X86_FEATURE_RMPOPT when the allocation fails: that hits the problem we ran into in earlier revisions — the workqueue
> allocation is at initcall time, after alternatives are patched, where setup_clear_cpu_cap() isn't reliable (static_cpu_has() is
> already baked in), so clearing the cap won't flip rmpopt_capable(). The setup/enable split removes most of the if (rmpopt_wq)
> checks anyway; the only one left is a single guard in snp_enable_rmpopt() for the (rare) allocation‑failure case, which I will
> probably like to keep rather than rely on clearing the feature.
Or, you can introduce that bool rmpopt_enabled and clear it and test it in
rmpopt_capable(). As long as it stays a static var, only visible in this
compilation unit and not exported, that's good enough.
> I'll respin as v15 with the setup/enable split once we settle the feature‑clear question and the RMPOPT_BASE MSR programming
> question (i.e., skipping it if RMPOPT_EN is already set).
Thx.
Btw, you can respin the last two patches only and send them as a reply to that
thread - I have applied the first 3 already so no need to resend them again.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH v14 4/5] x86/sev: Perform RMP optimizations asynchronously
2026-09-14 23:15 ` Borislav Petkov
@ 2026-09-15 21:04 ` Kalra, Ashish
2026-09-15 23:37 ` Borislav Petkov
0 siblings, 1 reply; 11+ messages in thread
From: Kalra, Ashish @ 2026-09-15 21:04 UTC (permalink / raw)
To: Borislav Petkov
Cc: tglx, mingo, dave.hansen, x86, hpa, seanjc, peterz,
thomas.lendacky, herbert, davem, ardb, pbonzini, aik,
Michael.Roth, KPrateek.Nayak, Tycho.Andersen, Nathan.Fontenot,
ackerleytng, jackyli, pgonda, rientjes, jacobhxu, xin,
pawan.kumar.gupta, babu.moger, dyoung, nikunj, darwi,
linux-kernel, linux-crypto, kvm, linux-coco
Hello Boris,
On 9/14/2026 6:15 PM, Borislav Petkov wrote:
> On Mon, Sep 14, 2026 at 03:00:04PM -0500, Kalra, Ashish wrote:
>> Thanks, Boris. Splitting setup from start and collapsing to a single export makes sense — a couple of constraints from the RMPOPT
>> spec shape how it has to be done.
>>
>> RMPOPT_BASE can only be written (RMPOPT_EN set) when SYSCFG[SnpEn] and RMP_CFG[SegmentedRmpEn] are both 1; otherwise the access
>> #GP(0)s. So the MSR programming can't run from an init‑time initcall — SnpEn is 0 then and it would #GP. The software setup can,
>> though, so the split becomes:
>>
>> - an initcall in this file does the software setup — allocate the workqueue and INIT_DELAYED_WORK(), no export;
>> - snp_enable_rmpopt() (the single export) programs RMPOPT_BASE on the primary threads and queues the pass. ccp calls it after it
>> has enabled SNP, and kvm‑amd calls it on teardown.
>
> This programming sure sounds like something we don't need to repeat each time
> we enable RMPOPT...
>
> rmpopt_pa_start is practically static so I'd love it if those MSRs are written
> once and that's it. The question is, do they keep their value when we disable
> SNP?
>
> And I can basically imagine the answer from hw folks: "yeah, yeah, maybe, but
> to be on the safe side, you should always write them after having enabled
> SNP."
>
> Because if not, I'd be perfectly fine with us setting them on the *first* SNP
> init and not touching them again.
>
> IOW, this pseudo:
>
> if (!rdmsr(RMPOPT_BASE))
> wrmsr(RMPOPT_BASE, ...):
>
> This should probably be in the snp_enable_rmpopt() function anyway as it
> should do what we want.
>
>> The same spec text makes that single entry point safe to call repeatedly: RMPOPT_BASE_ADDR is read‑only once RMPOPT_EN is 1 (and
>> RMPOPT_EN can't be cleared while SnpEn is 1), so a later call's write is a probably a no‑op rather than a reprogram. If we want
>> to avoid even the redundant IPIs, snp_enable_rmpopt() can read RMPOPT_BASE and skip programming when RMPOPT_EN is already set — a
>> hardware‑state check instead of an if (rmpopt_wq).
>
> Yap, or that. Sounds ok to me if it works.
>
>> On clearing X86_FEATURE_RMPOPT when the allocation fails: that hits the problem we ran into in earlier revisions — the workqueue
>> allocation is at initcall time, after alternatives are patched, where setup_clear_cpu_cap() isn't reliable (static_cpu_has() is
>> already baked in), so clearing the cap won't flip rmpopt_capable(). The setup/enable split removes most of the if (rmpopt_wq)
>> checks anyway; the only one left is a single guard in snp_enable_rmpopt() for the (rare) allocation‑failure case, which I will
>> probably like to keep rather than rely on clearing the feature.
>
> Or, you can introduce that bool rmpopt_enabled and clear it and test it in
> rmpopt_capable(). As long as it stays a static var, only visible in this
> compilation unit and not exported, that's good enough.
>
>> I'll respin as v15 with the setup/enable split once we settle the feature‑clear question and the RMPOPT_BASE MSR programming
>> question (i.e., skipping it if RMPOPT_EN is already set).
>
> Thx.
>
> Btw, you can respin the last two patches only and send them as a reply to that
> thread - I have applied the first 3 already so no need to resend them again.
>
One thing to sort out first, since you've already applied p1‑p3: the setup/enable rework reshapes a few things that landed
in p3 — snp_setup_rmpopt() becomes the single snp_enable_rmpopt() export, rmpopt_capable() now uses the rmpopt_enabled
guard, and the ccp caller in sev-dev.c changes with the rename. I can carry all of that as deltas in the respun p4 (i.e.
p3 adds snp_setup_rmpopt() and p4 renames/reworks it right after), but if you'd rather it land cleanly I can refresh p3
too so it introduces the final shape. Which would you prefer — p4 deltas over what's applied, or a refreshed p3 as well?
Thanks,
Ashish
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v14 4/5] x86/sev: Perform RMP optimizations asynchronously
2026-09-15 21:04 ` Kalra, Ashish
@ 2026-09-15 23:37 ` Borislav Petkov
0 siblings, 0 replies; 11+ messages in thread
From: Borislav Petkov @ 2026-09-15 23:37 UTC (permalink / raw)
To: Kalra, Ashish
Cc: tglx, mingo, dave.hansen, x86, hpa, seanjc, peterz,
thomas.lendacky, herbert, davem, ardb, pbonzini, aik,
Michael.Roth, KPrateek.Nayak, Tycho.Andersen, Nathan.Fontenot,
ackerleytng, jackyli, pgonda, rientjes, jacobhxu, xin,
pawan.kumar.gupta, babu.moger, dyoung, nikunj, darwi,
linux-kernel, linux-crypto, kvm, linux-coco
On Tue, Sep 15, 2026 at 04:04:31PM -0500, Kalra, Ashish wrote:
> One thing to sort out first, since you've already applied p1‑p3: the setup/enable rework reshapes a few things that landed
> in p3 — snp_setup_rmpopt() becomes the single snp_enable_rmpopt() export, rmpopt_capable() now uses the rmpopt_enabled
> guard, and the ccp caller in sev-dev.c changes with the rename. I can carry all of that as deltas in the respun p4 (i.e.
> p3 adds snp_setup_rmpopt() and p4 renames/reworks it right after), but if you'd rather it land cleanly I can refresh p3
> too so it introduces the final shape. Which would you prefer — p4 deltas over what's applied, or a refreshed p3 as well?
Nah, feel free to send a new set, if you have to touch 1-3.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v14 5/5] x86/sev: Re-enable RMP optimizations on SNP guest shutdown
2026-09-10 21:58 [PATCH v14 0/5] Add RMPOPT support Ashish Kalra
` (3 preceding siblings ...)
2026-09-10 22:00 ` [PATCH v14 4/5] x86/sev: Perform RMP optimizations asynchronously Ashish Kalra
@ 2026-09-10 22:00 ` Ashish Kalra
4 siblings, 0 replies; 11+ messages in thread
From: Ashish Kalra @ 2026-09-10 22:00 UTC (permalink / raw)
To: tglx, mingo, bp, dave.hansen, x86, hpa, seanjc, peterz,
thomas.lendacky, herbert, davem, ardb
Cc: pbonzini, aik, Michael.Roth, KPrateek.Nayak, Tycho.Andersen,
Nathan.Fontenot, ackerleytng, jackyli, pgonda, rientjes,
jacobhxu, xin, pawan.kumar.gupta, babu.moger, dyoung, nikunj,
darwi, linux-kernel, linux-crypto, kvm, linux-coco
From: Ashish Kalra <ashish.kalra@amd.com>
The RMPOPT table is a per-CPU table which indicates whether 1GB regions
of physical memory are entirely hypervisor-owned.
When performing host memory accesses in hypervisor mode as well as
non-SNP guest mode, the processor may consult the RMPOPT table to
potentially skip an RMP access and improve performance.
Normal guest events disable RMP optimizations: pages are converted from
shared to private as SNP guests are launched, and large pages are split
and collapsed during guest operation -- both disable the RMPOPT
optimizations for the affected 1GB regions.
When guests are torn down, their pages are converted back to shared, so
those regions may become eligible for RMPOPT optimization again. Without
some intervention, all RMP optimizations would eventually be lost, so
re-optimize all of physical memory on SNP guest teardown.
Perform the re-optimization after a delay, using mod_delayed_work() so
that the delay timer is reset on each call. This batches multiple guest
terminations into a single pass: the re-optimization runs 10 seconds
after the *last* termination rather than after the first.
mod_delayed_work() also re-queues work that is already in-flight, so a
re-scan request during an active scan is not silently dropped.
Guest teardown is currently the only event that returns guest memory to
hypervisor ownership: SNP guests do not support ballooning or memory
hotplug, so pages freed during a guest's lifetime remain guest-owned.
It is therefore the only point at which memory becomes eligible for RMP
re-optimization, which is why re-optimization is driven by guest
teardown rather than by a periodic scan.
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
---
arch/x86/include/asm/sev.h | 2 ++
arch/x86/kvm/svm/sev.c | 2 ++
arch/x86/virt/svm/sev.c | 31 +++++++++++++++++++++++++++++++
3 files changed, 35 insertions(+)
diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
index 5638d09b5132..3235e171647d 100644
--- a/arch/x86/include/asm/sev.h
+++ b/arch/x86/include/asm/sev.h
@@ -662,6 +662,7 @@ static inline void snp_leak_pages(u64 pfn, unsigned int pages)
__snp_leak_pages(pfn, pages, true);
}
int snp_prepare(void);
+void snp_rmpopt_all_physmem(void);
void snp_setup_rmpopt(void);
void snp_shutdown(void);
#else
@@ -681,6 +682,7 @@ static inline void snp_leak_pages(u64 pfn, unsigned int npages) {}
static inline void kdump_sev_callback(void) { }
static inline void snp_fixup_e820_tables(void) {}
static inline int snp_prepare(void) { return -ENODEV; }
+static inline void snp_rmpopt_all_physmem(void) {}
static inline void snp_setup_rmpopt(void) {}
static inline void snp_shutdown(void) {}
#endif
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 5705723f1f41..d8e6b8a08b79 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -3032,6 +3032,8 @@ void sev_vm_destroy(struct kvm *kvm)
*/
if (snp_decommission_context(kvm))
return;
+
+ snp_rmpopt_all_physmem();
} else {
sev_unbind_asid(kvm, sev->handle);
}
diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
index 35678b1f535d..c16f82642390 100644
--- a/arch/x86/virt/svm/sev.c
+++ b/arch/x86/virt/svm/sev.c
@@ -640,6 +640,37 @@ static void do_rmpopt_work(struct work_struct *work)
on_each_cpu_mask(cpu_primary_thread_mask, rmpopt_scan_range, NULL, true);
}
+/*
+ * Delay, in milliseconds, before the RMP re-optimization pass runs after an SNP
+ * guest is torn down, passed as the delay to mod_delayed_work(). This coalesces
+ * a burst of teardowns into a single scan and gives each guest's pages time to
+ * be converted back to the shared, hypervisor-owned state. The 10 second value
+ * is a heuristic trading re-optimization latency against scanning too eagerly.
+ */
+#define RMPOPT_WORK_TIMEOUT (10 * MSEC_PER_SEC)
+
+/*
+ * Perform RMP optimizations on memory freed by terminating guests. The scan
+ * is deferred, so it normally runs after sev_gmem_invalidate() has converted
+ * this guest's pages back to shared, and picks them up then. A very large
+ * guest whose conversion has not finished by then is picked up by a later
+ * teardown's scan.
+ */
+void snp_rmpopt_all_physmem(void)
+{
+ if (!rmpopt_capable())
+ return;
+
+ guard(mutex)(&rmpopt_wq_mutex);
+
+ if (!rmpopt_wq)
+ return;
+
+ mod_delayed_work(rmpopt_wq, &rmpopt_delayed_work,
+ msecs_to_jiffies(RMPOPT_WORK_TIMEOUT));
+}
+EXPORT_SYMBOL_FOR_MODULES(snp_rmpopt_all_physmem, "kvm-amd");
+
void snp_setup_rmpopt(void)
{
u64 rmpopt_base;
--
2.43.0
^ permalink raw reply [flat|nested] 11+ messages in thread