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

On Tue, Jun 23, 2026, 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 s=
ee 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.  Exp=
anding that
> > > > surface has a very, very, VERY high bar to get over.
> > >=20
> > > 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 mea=
surement,
> > 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.
>=20
> Joerg is suggesting that we need a launch measurement that is stable not =
just
> across multiple launches on the same system, but across multiple hypervis=
ors.

*sigh*

So that, and also the multi-VMPL implications, absolutely need to be decrib=
ed in
about this level of detail in the cover letter, and the changelog needs abo=
ut the
same level of documentation to justify the various design decisions.

Bluntly, all of the changelogs in this series are awful.  +200 lines of cod=
e in
arguably the nastiest bit of "architecture" KVM has to deal with, and the l=
ongest
changelog barely hits 6 lines.

And whatever uAPI we end up with needs tests, and a lot of them, including =
coverage
for negative testcases.  Because I'm working on fixing the third? guest-exp=
loitable
DoS that's unique to SNP this year, and I've reached my breaking point: I'm=
 not
taking new functionality like this without sufficient test coverage.

Rant(s) aside, thanks for the information, it's super helpful!