From: Sean Christopherson <seanjc@google.com>
To: "Jörg Rödel" <joro@8bytes.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
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>,
Jethro Beekman <jethro@fortanix.com>
Subject: Re: [PATCH 4/4] kvm: svm: Support KVM_SEV_SNP_PAGE_TYPE_VMSA at SNP_LAUNCH_UPDATE
Date: Tue, 16 Jun 2026 10:55:28 -0700 [thread overview]
Message-ID: <ajGOELiYwKByXbVP@google.com> (raw)
In-Reply-To: <aiqwjn2DVOumfr3T@8bytes.org>
+Jethro
On Thu, Jun 11, 2026, Jörg Rödel wrote:
> Hi Sean,
>
> On Thu, Jun 11, 2026 at 05:43:05AM -0700, Sean Christopherson wrote:
> > On Thu, Jun 11, 2026, Jörg Rödel wrote:
> > > From: Joerg Roedel <joerg.roedel@amd.com>
> > >
> > > Support setting a VMSA in guest physical memory during the SEV-SNP
> > > launch process. Only one VMSA can be provided which will then be used
> > > for the BSP. All of the APs will not have a VMSA allocated or assigned
> > > when this feature is used.
> > >
> > > This ensures stable launch measurements on SEV-SNP which are
> > > independent of the number of VCPUs the VM is launched with.
> >
> > This needs a *much* longer explanation and more justification for exactly why
> > this needs to be handled in KVM. I understand most of the words and acronyms,
> > but that's about where my understanding stops.
>
> Sure, how about:
>
> For SEV-SNP VMs KVM currently allocates and measures one VMSA per VCPU into the
> initial memory image. Historically this behavior comes from the SEV-ES
> implementation, which has no concept of a guest-provided or guest-owned VMSA.
> So on SEV-ES there is no other choice than allocating the VMSAs in KVM.
>
> In contrast, on SEV-SNP each VMSA has a GPA assigned and is (in theory)
> guest-owned, so that the old SEV-ES behavior of letting KVM manage the
> VMSAs causes several problems (especially together with IGVM-loading)
> and inefficiencies:
>
> 1. With the current KVM behavior the initial launch measurement depends
> on the number of VCPUs the VM has assigned.
>
> 2. Current SEV-SNP guest code will not use the KVM-allocated VMSAs for
> APs. Both EDK2 and the Linux kernel will allocate and provide their
> own VMSA pages for every AP. So the current allocation dance KVM is
> doing is useless for the APs.
>
> 3. The current behavior makes it impossible to implement the
> IGVM-promise of a predictable launch measurement derived from only
> the IGVM file and the target platform.
>
> To solve these problems this patch adds support to measure an IGVM-provided
> VMSA page into the initial SEV-SNP memory image. Only one VMSA page is
> supported for now, which aligns with the IGVM requirement that each file can
> only provide one VP-context. The VMSA will be checked by KVM for supported SEV
> features and VMPL0 before being accepted.
>
> When a VMSA page is measured in this way it will be used as the launch VMSA of
> the BSP for the VM. For all other VCPUs KVM will not allocate or measure VMSA
> pages, keeping the launch measurement in sync with the IGVM image. The guest
> has to provide VMSAs for all APs it intends to use, which common guest
> components already do anyway.
Isn't this essentially the same thing as hot-plugging vCPUs after launch? I
have yet to review it in depth (sorry Jethro), but it looks a *lot* simpler.
https://lore.kernel.org/all/20d3a189-5649-4864-81cd-5a421267f21b@fortanix.com
next prev parent reply other threads:[~2026-06-16 17:55 UTC|newest]
Thread overview: 20+ 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-11 12:56 ` sashiko-bot
2026-06-11 14:13 ` Jörg Rödel
2026-06-16 20:52 ` Tom Lendacky
2026-06-11 12:35 ` [PATCH 2/4] kvm: svm: Defer VMSA allocation to LAUNCH_FINISH stage Jörg Rödel
2026-06-11 12:58 ` sashiko-bot
2026-06-11 14:29 ` Jörg Rödel
2026-06-16 21:33 ` Tom Lendacky
2026-06-11 12:35 ` [PATCH 3/4] kvm: svm: Support guest-provided VMSA for launching Jörg Rödel
2026-06-11 13:05 ` sashiko-bot
2026-06-11 14:43 ` Jörg Rödel
2026-06-16 21:48 ` Tom Lendacky
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 [this message]
2026-06-11 12:58 ` sashiko-bot
2026-06-11 15:23 ` Jörg Rödel
2026-06-16 22:11 ` Tom Lendacky
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=ajGOELiYwKByXbVP@google.com \
--to=seanjc@google.com \
--cc=coconut-svsm@lists.linux.dev \
--cc=jethro@fortanix.com \
--cc=joerg.roedel@amd.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.