From: "Jörg Rödel" <joro@8bytes.org>
To: Sean Christopherson <seanjc@google.com>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: x86@kernel.org, Tom Lendacky <thomas.lendacky@amd.com>,
Michael Roth <michael.roth@amd.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
coconut-svsm@lists.linux.dev, Joerg Roedel <joerg.roedel@amd.com>
Subject: [PATCH 2/4] kvm: svm: Defer VMSA allocation to LAUNCH_FINISH stage
Date: Thu, 11 Jun 2026 14:35:26 +0200 [thread overview]
Message-ID: <20260611123528.572255-3-joro@8bytes.org> (raw)
In-Reply-To: <20260611123528.572255-1-joro@8bytes.org>
From: Joerg Roedel <joerg.roedel@amd.com>
Do not allocate a KVM-managed VMSA for all VCPUs on VCPU creation,
defer it to the LAUNCH_FINISH stage of SEV-ES and SEV-SNP. At this
stage the VMSAs get used for the first time.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
---
arch/x86/kvm/svm/sev.c | 40 +++++++++++++++++++++++-----------------
1 file changed, 23 insertions(+), 17 deletions(-)
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 9b1280222e20..350bb97c32c0 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -1095,11 +1095,11 @@ static int sev_es_sync_vmsa(struct vcpu_svm *svm)
{
struct kvm_vcpu *vcpu = &svm->vcpu;
struct kvm_sev_info *sev = to_kvm_sev_info(vcpu->kvm);
- struct sev_es_save_area *save = sev_es_vmsa_ref(vcpu);
+ struct sev_es_save_area *save;
struct xregs_state *xsave;
const u8 *s;
+ int ret, i;
u8 *d;
- int i;
lockdep_assert_held(&vcpu->mutex);
@@ -1110,6 +1110,12 @@ static int sev_es_sync_vmsa(struct vcpu_svm *svm)
if (svm->vcpu.guest_debug || (svm->vmcb->save.dr7 & ~DR7_FIXED_1))
return -EINVAL;
+ ret = sev_es_vcpu_alloc_vmsa(vcpu);
+ if (ret)
+ return ret;
+
+ save = sev_es_vmsa_ref(vcpu);
+
/*
* SEV-ES will use a VMSA that is pointed to by the VMCB, not
* the traditional VMSA that is part of the VMCB. Copy the
@@ -1196,7 +1202,7 @@ static int __sev_launch_update_vmsa(struct kvm *kvm, struct kvm_vcpu *vcpu,
{
struct sev_data_launch_update_vmsa vmsa;
struct vcpu_svm *svm = to_svm(vcpu);
- void *vmsa_ref = sev_es_vmsa_ref(vcpu);
+ void *vmsa_ref;
int ret;
if (vcpu->guest_debug) {
@@ -1209,6 +1215,8 @@ static int __sev_launch_update_vmsa(struct kvm *kvm, struct kvm_vcpu *vcpu,
if (ret)
return ret;
+ vmsa_ref = sev_es_vmsa_ref(vcpu);
+
/*
* The LAUNCH_UPDATE_VMSA command will perform in-place encryption of
* the VMSA memory content (i.e it will write the same memory region
@@ -1237,6 +1245,9 @@ static int __sev_launch_update_vmsa(struct kvm *kvm, struct kvm_vcpu *vcpu,
fpstate_set_confidential(&vcpu->arch.guest_fpu);
vcpu->arch.guest_state_protected = true;
+ /* VMSA encrypted - put it into the VMCB */
+ svm->vmcb->control.vmsa_pa = sev_es_vmsa_pa(vcpu);
+
/*
* SEV-ES guest mandates LBR Virtualization to be _always_ ON. Enable it
* only after setting guest_state_protected because KVM_SET_MSRS allows
@@ -2689,12 +2700,14 @@ static int snp_launch_update_vmsa(struct kvm *kvm, struct kvm_sev_cmd *argp)
kvm_for_each_vcpu(i, vcpu, kvm) {
struct vcpu_svm *svm = to_svm(vcpu);
- void *vmsa = sev_es_vmsa_ref(vcpu);
+ void *vmsa;
ret = sev_es_sync_vmsa(svm);
if (ret)
goto out;
+ vmsa = sev_es_vmsa_ref(vcpu);
+
ret = sev_es_vcpu_vmsa_make_private(vcpu);
if (ret)
goto out;
@@ -2710,6 +2723,10 @@ static int snp_launch_update_vmsa(struct kvm *kvm, struct kvm_sev_cmd *argp)
}
svm->vcpu.arch.guest_state_protected = true;
+
+ /* VMSA encrypted - put it into the VMCB */
+ svm->vmcb->control.vmsa_pa = sev_es_vmsa_pa(vcpu);
+
/*
* SEV-ES (and thus SNP) guest mandates LBR Virtualization to
* be _always_ ON. Enable it only after setting
@@ -4914,22 +4931,11 @@ void sev_init_vmcb(struct vcpu_svm *svm, bool init_event)
int sev_vcpu_create(struct kvm_vcpu *vcpu)
{
struct vcpu_svm *svm = to_svm(vcpu);
- int ret;
mutex_init(&svm->sev_es.snp_vmsa_mutex);
- if (!is_sev_es_guest(vcpu))
- return 0;
-
- /*
- * SEV-ES guests require a separate (from the VMCB) VMSA page used to
- * contain the encrypted register state of the guest.
- */
- ret = sev_es_vcpu_alloc_vmsa(vcpu);
- if (ret)
- return ret;
-
- vcpu->arch.guest_tsc_protected = snp_is_secure_tsc_enabled(vcpu->kvm);
+ if (is_sev_es_guest(vcpu))
+ vcpu->arch.guest_tsc_protected = snp_is_secure_tsc_enabled(vcpu->kvm);
return 0;
}
--
2.53.0
next prev parent reply other threads:[~2026-06-11 12:36 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-11 12:35 [PATCH 0/4] KVM: SEV: Support direct setting of VMSA for SEV-SNP guests Jörg Rödel
2026-06-11 12:35 ` [PATCH 1/4] kvm: svm: Streamline VMSA setting for VCPUs Jörg Rödel
2026-06-16 20:52 ` Tom Lendacky
2026-06-23 10:55 ` Jörg Rödel
2026-06-23 20:18 ` Sean Christopherson
2026-06-11 12:35 ` Jörg Rödel [this message]
2026-06-16 21:33 ` [PATCH 2/4] kvm: svm: Defer VMSA allocation to LAUNCH_FINISH stage Tom Lendacky
2026-06-23 11:26 ` Jörg Rödel
2026-06-11 12:35 ` [PATCH 3/4] kvm: svm: Support guest-provided VMSA for launching Jörg Rödel
2026-06-16 21:48 ` Tom Lendacky
2026-06-23 11:36 ` Jörg Rödel
2026-06-23 21:07 ` Sean Christopherson
2026-06-11 12:35 ` [PATCH 4/4] kvm: svm: Support KVM_SEV_SNP_PAGE_TYPE_VMSA at SNP_LAUNCH_UPDATE Jörg Rödel
2026-06-11 12:43 ` Sean Christopherson
2026-06-11 13:23 ` Jörg Rödel
2026-06-16 17:55 ` Sean Christopherson
2026-06-17 6:45 ` Jörg Rödel
2026-06-17 13:00 ` Sean Christopherson
2026-06-17 13:25 ` Jörg Rödel
2026-06-17 13:37 ` Sean Christopherson
2026-06-17 14:44 ` Jörg Rödel
2026-06-23 13:40 ` Sean Christopherson
2026-06-23 14:44 ` Jörg Rödel
2026-06-23 14:51 ` [EXTERNAL] " Jon Lange
2026-06-23 20:23 ` Sean Christopherson
2026-06-23 20:43 ` Jethro Beekman
2026-06-23 21:43 ` Sean Christopherson
2026-06-23 21:47 ` Jethro Beekman
2026-06-23 22:02 ` Sean Christopherson
2026-06-23 22:35 ` Jethro Beekman
2026-06-23 22:55 ` Sean Christopherson
2026-06-23 23:08 ` Jethro Beekman
2026-06-23 23:43 ` Sean Christopherson
2026-06-24 6:42 ` Jethro Beekman
2026-06-17 13:18 ` James Bottomley
2026-06-17 13:28 ` Jörg Rödel
2026-06-17 13:45 ` James Bottomley
2026-06-17 14:53 ` Jörg Rödel
2026-06-16 22:11 ` Tom Lendacky
2026-06-23 11:48 ` Jörg Rödel
2026-06-23 21:29 ` Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260611123528.572255-3-joro@8bytes.org \
--to=joro@8bytes.org \
--cc=coconut-svsm@lists.linux.dev \
--cc=joerg.roedel@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome