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