On 2/18/25 19:27, Sean Christopherson wrote: > When processing an SNP AP Creation event, invalidate the "next" VMSA GPA > even if acquiring the page/pfn for the new VMSA fails. In practice, the > next GPA will never be used regardless of whether or not its invalidated, > as the entire flow is guarded by snp_ap_waiting_for_reset, and said guard > and snp_vmsa_gpa are always written as a pair. But that's really hard to > see in the code. > > Signed-off-by: Sean Christopherson <seanjc@xxxxxxxxxx> Reviewed-by: Tom Lendacky <thomas.lendacky@xxxxxxx> > --- > arch/x86/kvm/svm/sev.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c > index 15c324b61b24..7345cac6f93a 100644 > --- a/arch/x86/kvm/svm/sev.c > +++ b/arch/x86/kvm/svm/sev.c > @@ -3877,6 +3877,7 @@ void sev_snp_init_protected_guest_state(struct kvm_vcpu *vcpu) > return; > > gfn = gpa_to_gfn(svm->sev_es.snp_vmsa_gpa); > + svm->sev_es.snp_vmsa_gpa = INVALID_PAGE; > > slot = gfn_to_memslot(vcpu->kvm, gfn); > if (!slot) > @@ -3906,8 +3907,6 @@ void sev_snp_init_protected_guest_state(struct kvm_vcpu *vcpu) > /* Mark the vCPU as runnable */ > kvm_set_mp_state(vcpu, KVM_MP_STATE_RUNNABLE); > > - svm->sev_es.snp_vmsa_gpa = INVALID_PAGE; > - > /* > * gmem pages aren't currently migratable, but if this ever changes > * then care should be taken to ensure svm->sev_es.vmsa is pinned
