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 23:43, Sean Christopherson wrote:
> > 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 =
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.  Ex=
panding 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 r=
equirement
> >>>>> 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 sta=
ble across
> >>>> kernels because it's part of KVM's ABI.  So as I see it, the issue i=
sn'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 http=
s://lkml.org/lkml/2021/4/12/625
> >=20
> > No, that's not how this works.  Dave and Jarkko both have unanswered qu=
estions
> > regarding the use case.  Answer their questions, and I'm confident you'=
ll get
> > traction.
> >=20
> >  : I don't believe we necessarily *WANT* or need Linux to support "all
> >  : possible ECREATE, EADD, EEXTEND, EINIT sequences".  Yet, it's what i=
s
> >  : 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 th=
at
> >  : *REALLY* wants to do this for good reasons.
> >=20
> > and
> >=20
> >  : What specifically are you referring as the "rest of the world"?
> >  :=20
> >  : That would be mean that there is reviewable workload "out there".
> >=20
> > 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 provi=
ded 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 o=
wn.
> >=20
> > In other words, they aren't asking KVM to support every possible way/ti=
me a VMSA
> > could be associated with a vCPU, they're asking to extend KVM to suppor=
t a concrete
> > use case, with meaningful real world impact.  In fact, I actually think=
 this series
> > is *too* narrowly focused on their use case.
> >=20
> > FWIW, KVM_TDX_INIT_MEM_REGION has almost the exact same ABI that SGX ha=
s: pages
> > contents are measured immediately after they're added.
>=20
> Sorry, the argument from Jon/Joerg is no different than the one we made y=
ears
> ago for SGX.
>=20
> It was previously made abundantly clear that it's the kernel maintainers'=
s
> stance that it's sufficient to offer a UAPI that allows the creation of a
> Linux-specific subset of enclaves with a stable measurement encompassing
> largely the enclave functionality available in the hardware. Or said anot=
her
> way: if you can take your enclave and modify it to work with Linux, albei=
t
> with a different measurement, that is acceptable. KVM-SNP is currently at
> that state: it is currently completely possible to load VMs that were
> designed with the current Linux VMSA in IGVM format.
>=20
> A UAPI that allows creation of all architecturally-valid enclaves for
> purposes of measurement portability was stated as an explicit non-goal. A=
s
> this is the only stated purpose of this patch set, it should also not be
> accepted.

No, the stated goals (thanks to the follow-up from Jon) are to (a) support =
VMSA
GPAs other than KVM's hardcoded, arbitrary 0xFFFFFFFFF000, and (b) to play =
nice
with multi-VMPL scenarios in the future.  If that happens to let userspace =
build
every architecturally possible VM, then yay!, we got lucky and probably won=
't
ever need to revisit this.  But "support every possibility" is not the goal=
.

Side topic, if someone is going to propose changes for TDX measurements rel=
ated
to IGVM, now would be a good time to mention them :-)