From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8D35D574080; Mon, 31 Aug 2026 13:48:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788184138; cv=none; b=XT2OZNx0rsRqq1JlUUyo8RxqJfFDHB0qIYHkzBVH6u27EXybPAulQzAri/fQdnMchONoonzhDKAA0Q6KhBC0PqGK2mhBBhtp4TyQZNxmnv/Y43/3uMcBvpQ7v+Z0a80pdEyp3mbcAnlP37nwmiWXDpj3mVgbWHFWPYiOUenBzq8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788184138; c=relaxed/simple; bh=yI1cOqwXV3vY6Yg+U8NNS8KbWXEe73KQKMJYZ9qik3A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=p7XDzO23lIzGIU1MfCTsts1qfhKp9jeHJWP+VYnNaE0NsJejO6DTGuRSVGhwVcoC4x3ahheStA6pp2n/WSRYyRBcdEFT+UBipjUGzTf7KG2EChkn6Pn/8Rebph5cdwcVaGDJaGp1kdtgiARcarJOO5EojGSmpohZ/trUq1aAsTE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=SJXm5of3; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="SJXm5of3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BB28A1F000E9; Mon, 31 Aug 2026 13:48:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1788184136; bh=MXCZr7+4fRL9hwvMXPlfPdWHW/akhdPd4hQC8Rg+cvk=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=SJXm5of328vhiIg754O5TSWVLCNZPZCinpyJYaVSa74AXOGEYK1TUmvf5KdurYLoA j2geCA/o+kl0iLZuA6QeLR8bhX6V4kCTgvG9mMzmJmVfnIKnR4m4FmIdZlHitVHm0N IAbgkZU78gg7Tq+vXZRmR+eJjMVzOagL4rxCo1TU= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Michael Roth , Sean Christopherson Subject: [PATCH 6.18 41/83] KVM: SEV: Track the GPA of the guest-controlled VMSA used for SNP guests Date: Mon, 31 Aug 2026 15:34:17 +0200 Message-ID: <20260831133401.609372499@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260831133359.207714926@linuxfoundation.org> References: <20260831133359.207714926@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Sean Christopherson commit 42a39ad5d592aec87a70527a4e694f6210694482 upstream. Track the GPA of the guest-provided VMSA used after AP_CREATION events when running SNP guests, instead of simply tracking whether or not the vCPU is using a guest-provided VMSA. KVM needs to know the GPA of the VMSA that's actively being used so that it can react to MMU invalidation events, i.e. so that KVM can drop the VMSA if its backing guest_memfd page is punched out of existence. Opportunistically rename snp_vmsa_gpa to clarify that it tracks the pending VMSA GPA, whereas snp_guest_vmsa_gpa now tracks the in-use VMSA GPA. Note! Take care to track the GPA, not the GFN, as VALID_PAGE() won't behave correctly if an invalid GFN is converted to a GPA for checking. Note #2! Keep snp_has_guest_vmsa so that switching to a guest-provided VMSA is sticky, even if the guest-provided VMSA becomes invalid. No functional change intended. Cc: stable@vger.kernel.org # 6.12.x Reviewed-by: Michael Roth Link: https://patch.msgid.link/20260709204948.1988414-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman --- arch/x86/kvm/svm/sev.c | 14 +++++++++----- arch/x86/kvm/svm/svm.h | 3 ++- 2 files changed, 11 insertions(+), 6 deletions(-) --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -4037,6 +4037,7 @@ static void sev_snp_init_protected_guest /* Clear use of the VMSA */ svm->vmcb->control.vmsa_pa = INVALID_PAGE; + svm->sev_es.snp_guest_vmsa_gpa = INVALID_PAGE; /* * When replacing the VMSA during SEV-SNP AP creation, @@ -4044,11 +4045,11 @@ static void sev_snp_init_protected_guest */ vmcb_mark_all_dirty(svm->vmcb); - if (!VALID_PAGE(svm->sev_es.snp_vmsa_gpa)) + if (!VALID_PAGE(svm->sev_es.snp_pending_vmsa_gpa)) return; - gfn = gpa_to_gfn(svm->sev_es.snp_vmsa_gpa); - svm->sev_es.snp_vmsa_gpa = INVALID_PAGE; + gfn = gpa_to_gfn(svm->sev_es.snp_pending_vmsa_gpa); + svm->sev_es.snp_pending_vmsa_gpa = INVALID_PAGE; slot = gfn_to_memslot(vcpu->kvm, gfn); if (!slot) @@ -4073,6 +4074,7 @@ static void sev_snp_init_protected_guest svm->sev_es.snp_has_guest_vmsa = true; /* Use the new VMSA */ + svm->sev_es.snp_guest_vmsa_gpa = gfn_to_gpa(gfn); svm->vmcb->control.vmsa_pa = pfn_to_hpa(pfn); /* Mark the vCPU as runnable */ @@ -4139,10 +4141,10 @@ static int sev_snp_ap_creation(struct vc return -EINVAL; } - target_svm->sev_es.snp_vmsa_gpa = svm->vmcb->control.exit_info_2; + target_svm->sev_es.snp_pending_vmsa_gpa = svm->vmcb->control.exit_info_2; break; case SVM_VMGEXIT_AP_DESTROY: - target_svm->sev_es.snp_vmsa_gpa = INVALID_PAGE; + target_svm->sev_es.snp_pending_vmsa_gpa = INVALID_PAGE; break; default: vcpu_unimpl(vcpu, "vmgexit: invalid AP creation request [%#x] from guest\n", @@ -4731,6 +4733,8 @@ int sev_vcpu_create(struct kvm_vcpu *vcp return -ENOMEM; svm->sev_es.vmsa = page_address(vmsa_page); + svm->sev_es.snp_pending_vmsa_gpa = INVALID_PAGE; + svm->sev_es.snp_guest_vmsa_gpa = INVALID_PAGE; vcpu->arch.guest_tsc_protected = snp_is_secure_tsc_enabled(vcpu->kvm); --- a/arch/x86/kvm/svm/svm.h +++ b/arch/x86/kvm/svm/svm.h @@ -248,7 +248,8 @@ struct vcpu_sev_es_state { u64 ghcb_registered_gpa; struct mutex snp_vmsa_mutex; /* Used to handle concurrent updates of VMSA. */ - gpa_t snp_vmsa_gpa; + gpa_t snp_pending_vmsa_gpa; + gpa_t snp_guest_vmsa_gpa; bool snp_ap_waiting_for_reset; bool snp_has_guest_vmsa; };