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

On Tue, Jun 23, 2026, Jethro Beekman wrote:
> On 2026-06-23 16:51, Jon Lange wrote:
> > On Tuesday, June 23, 2026 6:40 AM, Sean Christopherson wrote:
> >> On Wed, Jun 17, 2026, J=C3=B6rg R=C3=B6del 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 se=
e that as a
> >>>> strong argument for new uAPI, especially not for VMSA pages.  I am v=
ery firmly
> >>>> of the opinion that letting anything but the host kernel configure t=
he VMSA is
> >>>> beyond stupid, but unfortunately we're stuck with AP_CREATION.  Expa=
nding 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 t=
his) is
> >>> actually the predictable launch measurement. On SEV-SNP this is a req=
uirement
> >>> to use platform VM-identity features like the ID Block.
> >>
> >> And I'm saying that unless KVM *can't* provide a predictable launch me=
asurement,
> >> which AIUI isn't the case, then the launch measurement *must* be stabl=
e 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.
> >=20
> > Joerg is suggesting that we need a launch measurement that is stable no=
t
> > just across multiple launches on the same system, but across multiple
> > hypervisors.
>=20
> If this is now suddenly an acceptable argument, please also merge https:/=
/lkml.org/lkml/2021/4/12/625

No, that's not how this works.  Dave and Jarkko both have unanswered questi=
ons
regarding the use case.  Answer their questions, and I'm confident you'll g=
et
traction.

 : I don't believe we necessarily *WANT* or need Linux to support "all
 : possible ECREATE, EADD, EEXTEND, EINIT sequences".  Yet, it's what is
 : being used to justify this series without any other justification.
 :=20
 : It's going to be a different story if you bring me a real enclave that
 : *REALLY* wants to do this for good reasons.

and

 : What specifically are you referring as the "rest of the world"?
 :=20
 : That would be mean that there is reviewable workload "out there".

The start of that thread is *exactly* what's playing out here.  The big dif=
ference,
and why this one's likely getting a different result, is that Jon provided =
a very
thorough explanation of exactly what use case Joerg and company want to sup=
port.
The only "assumed knowledge" is why it's desirable for the measurement to b=
e stable
across hypervisors, but I'm comfortable stitching that together on my own.

In other words, they aren't asking KVM to support every possible way/time a=
 VMSA
could be associated with a vCPU, they're asking to extend KVM to support a =
concrete
use case, with meaningful real world impact.  In fact, I actually think thi=
s series
is *too* narrowly focused on their use case.

FWIW, KVM_TDX_INIT_MEM_REGION has almost the exact same ABI that SGX has: p=
ages
contents are measured immediately after they're added.