arch/x86/include/asm/sev.h | 38 +++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-)
The sev_evict_cache() is guest-related code and should be guarded by
CONFIG_AMD_MEM_ENCRYPT, not CONFIG_KVM_AMD_SEV. Move the function
declarations under the appropriate #ifdef.
Fixes: 7b306dfa326f ("x86/sev: Evict cache lines during SNP memory validation")
Cc: <stable@kernel.org>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
arch/x86/include/asm/sev.h | 38 +++++++++++++++++++-------------------
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
index 00475b814ac4..e5a7e0ebdc73 100644
--- a/arch/x86/include/asm/sev.h
+++ b/arch/x86/include/asm/sev.h
@@ -579,6 +579,24 @@ struct psc_desc {
u64 caa_pa;
};
+static inline void sev_evict_cache(void *va, int npages)
+{
+ volatile u8 val __always_unused;
+ u8 *bytes = va;
+ int page_idx;
+
+ /*
+ * For SEV guests, a read from the first/last cache-lines of a 4K page
+ * using the guest key is sufficient to cause a flush of all cache-lines
+ * associated with that 4K page without incurring all the overhead of a
+ * full CLFLUSH sequence.
+ */
+ for (page_idx = 0; page_idx < npages; page_idx++) {
+ val = bytes[page_idx * PAGE_SIZE];
+ val = bytes[page_idx * PAGE_SIZE + PAGE_SIZE - 1];
+ }
+}
+
#else /* !CONFIG_AMD_MEM_ENCRYPT */
#define snp_vmpl 0
@@ -624,6 +642,7 @@ static inline enum es_result savic_register_gpa(u64 gpa) { return ES_UNSUPPORTED
static inline enum es_result savic_unregister_gpa(u64 *gpa) { return ES_UNSUPPORTED; }
static inline void savic_ghcb_msr_write(u32 reg, u64 value) { }
static inline u64 savic_ghcb_msr_read(u32 reg) { return 0; }
+static inline void sev_evict_cache(void *va, int npages) {}
#endif /* CONFIG_AMD_MEM_ENCRYPT */
@@ -638,24 +657,6 @@ int rmp_make_shared(u64 pfn, enum pg_level level);
void snp_leak_pages(u64 pfn, unsigned int npages);
void kdump_sev_callback(void);
void snp_fixup_e820_tables(void);
-
-static inline void sev_evict_cache(void *va, int npages)
-{
- volatile u8 val __always_unused;
- u8 *bytes = va;
- int page_idx;
-
- /*
- * For SEV guests, a read from the first/last cache-lines of a 4K page
- * using the guest key is sufficient to cause a flush of all cache-lines
- * associated with that 4K page without incurring all the overhead of a
- * full CLFLUSH sequence.
- */
- for (page_idx = 0; page_idx < npages; page_idx++) {
- val = bytes[page_idx * PAGE_SIZE];
- val = bytes[page_idx * PAGE_SIZE + PAGE_SIZE - 1];
- }
-}
#else
static inline bool snp_probe_rmptable_info(void) { return false; }
static inline int snp_rmptable_init(void) { return -ENOSYS; }
@@ -671,7 +672,6 @@ static inline int rmp_make_shared(u64 pfn, enum pg_level level) { return -ENODEV
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 void sev_evict_cache(void *va, int npages) {}
#endif
#endif
base-commit: fc1ded58808520a1ced0c4e2e5fb0dbd33b33612
--
2.46.2On Fri, Sep 12, 2025 at 03:29:19PM -0500, Tom Lendacky wrote:
> The sev_evict_cache() is guest-related code and should be guarded by
> CONFIG_AMD_MEM_ENCRYPT, not CONFIG_KVM_AMD_SEV. Move the function
> declarations under the appropriate #ifdef.
>
> Fixes: 7b306dfa326f ("x86/sev: Evict cache lines during SNP memory validation")
> Cc: <stable@kernel.org>
Do we really want this in stable?
I haven't seen any breakages from it...
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Fri, Sep 12, 2025 at 10:42:03PM +0200, Borislav Petkov wrote:
> On Fri, Sep 12, 2025 at 03:29:19PM -0500, Tom Lendacky wrote:
> > The sev_evict_cache() is guest-related code and should be guarded by
> > CONFIG_AMD_MEM_ENCRYPT, not CONFIG_KVM_AMD_SEV. Move the function
> > declarations under the appropriate #ifdef.
> >
> > Fixes: 7b306dfa326f ("x86/sev: Evict cache lines during SNP memory validation")
> > Cc: <stable@kernel.org>
>
> Do we really want this in stable?
>
> I haven't seen any breakages from it...
I think that's actually the concerning thing. If someone built a guest
kernel with CONFIG_KVM_AMD_SEV=y they might be under the impression that
this is performing evictions when it's actually just a stub function.
-Mike
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
On Fri, Sep 12, 2025 at 03:49:29PM -0500, Michael Roth wrote:
> I think that's actually the concerning thing. If someone built a guest
> kernel with CONFIG_KVM_AMD_SEV=y they might be under the impression that
> this is performing evictions when it's actually just a stub function.
That sooo needs to be in the commit message...
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 9/12/25 16:02, Borislav Petkov wrote: > On Fri, Sep 12, 2025 at 03:49:29PM -0500, Michael Roth wrote: >> I think that's actually the concerning thing. If someone built a guest >> kernel with CONFIG_KVM_AMD_SEV=y they might be under the impression that >> this is performing evictions when it's actually just a stub function. > > That sooo needs to be in the commit message... I can send a v2 or if you want to modify the commit message with the following: The sev_evict_cache() is guest-related code and should be guarded by CONFIG_AMD_MEM_ENCRYPT, not CONFIG_KVM_AMD_SEV. CONFIG_AMD_MEM_ENCRYPT=y is required for a guest to run properly as an SEV-SNP guest, but a guest kernel built with CONFIG_KVM_AMD_SEV=n would get the stub function of sev_evict_cache() instead of the version that performs the actual eviction. Move the function declarations under the appropriate #ifdef. Let me know. Thanks, Tom >
On Sat, Sep 13, 2025 at 09:29:47AM -0500, Tom Lendacky wrote:
> On 9/12/25 16:02, Borislav Petkov wrote:
> > On Fri, Sep 12, 2025 at 03:49:29PM -0500, Michael Roth wrote:
> >> I think that's actually the concerning thing. If someone built a guest
> >> kernel with CONFIG_KVM_AMD_SEV=y they might be under the impression that
> >> this is performing evictions when it's actually just a stub function.
> >
> > That sooo needs to be in the commit message...
>
> I can send a v2 or if you want to modify the commit message with the
> following:
>
> The sev_evict_cache() is guest-related code and should be guarded by
> CONFIG_AMD_MEM_ENCRYPT, not CONFIG_KVM_AMD_SEV.
>
> CONFIG_AMD_MEM_ENCRYPT=y is required for a guest to run properly as an
> SEV-SNP guest, but a guest kernel built with CONFIG_KVM_AMD_SEV=n would
> get the stub function of sev_evict_cache() instead of the version that
> performs the actual eviction. Move the function declarations under the
> appropriate #ifdef.
>
> Let me know.
Right, I had fixed it up locally already like this:
The sev_evict_cache() is guest-related code and should be guarded by
CONFIG_AMD_MEM_ENCRYPT, not CONFIG_KVM_AMD_SEV. Move the function
declarations under the appropriate #ifdef otherwise a guest kernel built
with CONFIG_KVM_AMD_SEV=n won't be doing proper evicting.
but you can send me your version on Monday.
When you do, can you pls rebase it ontop of -rc6 which Linus would have
released by then because this one needs to go up now and doesn't need to be
based ontop of tip/master and be against the x86/sev changes there.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Fri, Sep 12, 2025 at 03:29:19PM -0500, Tom Lendacky wrote:
> The sev_evict_cache() is guest-related code and should be guarded by
> CONFIG_AMD_MEM_ENCRYPT, not CONFIG_KVM_AMD_SEV. Move the function
> declarations under the appropriate #ifdef.
>
> Fixes: 7b306dfa326f ("x86/sev: Evict cache lines during SNP memory validation")
> Cc: <stable@kernel.org>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Michael Roth <michael.roth@amd.com>
© 2016 - 2025 Red Hat, Inc.