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

[Jon Lange]

On Tuesday, June 23, 2026 6:40 AM, Sean Christopherson wrote:
> On Wed, Jun 17, 2026, Jörg Rödel wrote:
> > On Wed, Jun 17, 2026 at 06:37:52AM -0700, Sean Christopherson wrote:
> > > Ok, so it took us a few times to learn our lesson.  I still don't see that as a
> > > strong argument for new uAPI, especially not for VMSA pages.  I am very firmly
> > > of the opinion that letting anything but the host kernel configure the VMSA is
> > > beyond stupid, but unfortunately we're stuck with AP_CREATION.  Expanding that
> > > surface has a very, very, VERY high bar to get over.
> > 
> > The strongest argument in my view (and the main reason we are doing this) is
> > actually the predictable launch measurement. On SEV-SNP this is a requirement
> > to use platform VM-identity features like the ID Block.
>
> And I'm saying that unless KVM *can't* provide a predictable launch measurement,
> which AIUI isn't the case, then the launch measurement *must* be stable across
> kernels because it's part of KVM's ABI.  So as I see it, the issue isn't that
> KVM is inherently unpredictable, it's that we lack tests to validate a thorny,
> subtle piece of KVM's ABI.

Joerg is suggesting that we need a launch measurement that is stable not just across multiple launches on the same system, but across multiple hypervisors.  This is what it means to have a stable ID block, so that the same ID block can be used every time the guest is launched.  The synthetic GPA that KVM uses today to associate the VMSA is not architectural, so it is not used by any other hypervisor.  The only architectural concept that exists is GPA, and the only consistent notion of GPA is the guest address space, so permitting the guest image to specify the VMSA GPA is not only the obvious choice, but it is the only apparent choice.  Beyond that, the SNP architecture does not specify an architectural startup state for the boot processor, and guests expect to be able to provide whatever contents they need, which certainly suggests that the data of the VMSA is guest-controlled.

Regarding the treatment of VMSAs generally, the SNP architecture considers these to be guest-owned data because they have protected contents.  Outside of the boot processor, every AP starts by donating a GPA page to become the VMSA of the newly started processor, which is necessary because the guest itself write protected contents into the VMSA to initialize it before it can become eligible for execution.  And beyond the AP case, when multiple VMPLs are involved, each lower VMPLs VMSA also originates as a GPA page, and here it is not only for initialization purposes, but because the higher VMPL has an ongoing need to read and write the VMSAs of the lower VMPLs for management purposes.  Without the lower VMSAs living in the GPA space, it is difficult to reason about how the highest VMPL could retain a valid mapping for this access.

So when you add up the fact that AP VMSAs are intended to be guest-owned (by the GHCB protocol) and the VMSAs of the lower VMPLs are required to be guest-owned (for ongoing access), the idea that the BSP VMSA must be host-controlled makes it the oddball.  If the system has to support VMSAs living in GPA space generally, then it doesn't seem like a stretch to say that the BSP VMSAs could be treated identically.  This gives consistency not only with the rest of the VMSA design, but gives cross-hypervisor consistency as well.

-Jon