From: Sean Christopherson Date: Tue, 10 Mar 2026 23:48:22 +0000 (-0700) Subject: KVM: SEV: Document that checking for SEV+ guests when reclaiming memory is "safe" X-Git-Tag: v7.1-rc1~118^2~2^2~7 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=2f34d421e8f041cf831b26a7596dc38336062d24;p=thirdparty%2Fkernel%2Flinux.git KVM: SEV: Document that checking for SEV+ guests when reclaiming memory is "safe" Document that the check for an SEV+ guest when reclaiming guest memory is safe even though kvm->lock isn't held. This will allow asserting that kvm->lock is held in the SEV accessors, without triggering false positives on the "safe" cases. No functional change intended. Link: https://patch.msgid.link/20260310234829.2608037-15-seanjc@google.com Signed-off-by: Sean Christopherson --- diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 015d102b32d90..ed8bb60341ae3 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -3293,8 +3293,14 @@ void sev_guest_memory_reclaimed(struct kvm *kvm) * With SNP+gmem, private/encrypted memory is unreachable via the * hva-based mmu notifiers, i.e. these events are explicitly scoped to * shared pages, where there's no need to flush caches. + * + * Checking for SEV+ outside of kvm->lock is safe as __sev_guest_init() + * can only be done before vCPUs are created, caches can be incoherent + * if and only if a vCPU was run, and either this task will see the VM + * as being SEV+ or the vCPU won't be to access the memory (because of + * the in-progress invalidation). */ - if (!sev_guest(kvm) || sev_snp_guest(kvm)) + if (!____sev_guest(kvm) || ____sev_snp_guest(kvm)) return; sev_writeback_caches(kvm);