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

[Sean Christopherson]

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ö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.
> 
> 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 questions
regarding the use case.  Answer their questions, and I'm confident you'll get
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.
 : 
 : 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"?
 : 
 : 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 difference,
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 support.
The only "assumed knowledge" is why it's desirable for the measurement to be 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 this series
is *too* narrowly focused on their use case.

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