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

["Jörg Rödel" <joro@8bytes.org>]

On Tue, Jun 23, 2026 at 06:40:13AM -0700, Sean Christopherson wrote:
> On Wed, Jun 17, 2026, Jörg Rödel wrote:
> > 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,

The situation today is that the launch measurement can be predicted with a lot
of internal KVM knowledge (Knowing that KVM creates a VMSA at a fixed GPA at
launch time, how KVM sets it up, ...) and detailed knowledge of the VM instance
(number of VCPUs).

What KVM can NOT do today is to launch an SNP VM with a launch measurement as
predicted by the IGVM format.

And this is what concerns me because the industry is moving towards IGVM for
predicting launch measurments of CoCo VMs.  It is supported in QEMU, in Cloud
Hypervisor, FUKI will use it, SVSM relies on it, and there are certainly more
users I am not aware of.

> then the launch measurement *must* be stable across kernels because it's part
> of KVM's ABI.

The current behavior stays in place and is kept as the default, no ABI
breakage.

> 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.

I agree that KVM does not cause inherently unpredictable measurements, but a
lot of internal KVM and VM knowledge is needed to predict it. This is a problem
IGVM is meant to solve in a platform- and hypervisor-independent way.

Do you agree that supporting the IGVM use-case is valuable? If so, what would
be your suggestion to make it work on KVM?


-Joerg