Re: [PATCH 4/4] kvm: svm: Support KVM_SEV_SNP_PAGE_TYPE_VMSA at SNP_LAUNCH_UPDATE

Sean Christopherson <[email protected]> Tue, 16 Jun 2026 10:55:28 -0700
Newsgroups dev.linux.lists.coconut-svsm,org.kernel.vger.kvm,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
+Jethro

On Thu, Jun 11, 2026, J=C3=B6rg R=C3=B6del wrote:
> Hi Sean,
>=20
> On Thu, Jun 11, 2026 at 05:43:05AM -0700, Sean Christopherson wrote:
> > On Thu, Jun 11, 2026, J=C3=B6rg R=C3=B6del wrote:
> > > From: Joerg Roedel <[email protected]>
> > >=20
> > > 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 assigne=
d
> > > 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.
> >=20
> > This needs a *much* longer explanation and more justification for exact=
ly why
> > this needs to be handled in KVM.  I understand most of the words and ac=
ronyms,
> > but that's about where my understanding stops.
>=20
> Sure, how about:
>=20
> For SEV-SNP VMs KVM currently allocates and measures one VMSA per VCPU in=
to the
> initial memory image.  Historically this behavior comes from the SEV-ES
> implementation, which has no concept of a guest-provided or guest-owned V=
MSA.
> So on SEV-ES there is no other choice than allocating the VMSAs in KVM.
>=20
> 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:
>=20
> 	1. With the current KVM behavior the initial launch measurement depends
> 	   on the number of VCPUs the VM has assigned.
>=20
> 	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.
>=20
> 	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.
>=20
> To solve these problems this patch adds support to measure an IGVM-provid=
ed
> 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 supporte=
d SEV
> features and VMPL0 before being accepted.
>=20
> When a VMSA page is measured in this way it will be used as the launch VM=
SA 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 gu=
est
> 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/[email protected]=
om