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

[Sean Christopherson]

On Wed, Jun 24, 2026, Jethro Beekman wrote:
> On 2026-06-24 00:02, Sean Christopherson wrote:
> >> A UAPI that allows creation of all architecturally-valid enclaves for
> >> purposes of measurement portability was stated as an explicit non-goal. As
> >> 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 
> 
> As Jon points out, the VMSA GPA is not architecturally relevant, so any
> enclave can be changed to support a BSP VMSA at 0xFFFFFFFFF000. The only
> reason to "support VMSA GPAs other than KVM's hardcoded, arbitrary
> 0xFFFFFFFFF000" is measurement portability.

Well, that and hardcoding 0xFFFFFFFFF000 is bizarre and confusing, IMO.

> > (b) to play nice with multi-VMPL scenarios in the future.
> 
> It's not clear to me what multi-VMPL scenario Jon is describing that requires
> custom VMSA content/address at launch time other than measurement
> portability. It's currently completely possible for VMPL0 code to set the
> VMPL of a VMSA or create a new VMSA with VMPL>0 at any GPA of their choosing.

Sorry, I phrased that poorly.  It's not about directly playing nice with multi-VMPL
scenarios, it's that if/when multi-VMPL support comes along, the BSP's VMSA for
VMPL0 will likely be the only VMSA that is NOT in guest memory.  And so supporting
an in-guest VMSA for BSP VMPL0 would provide consistency on top of cross-hypervisor
compatilibity, and I place a lot of value on consistency.

FWIW, I loathe the AP_CREATE scheme.  I wish we could go back in time and burn it
with fire.  Unfortunately, we're stuck with it, i.e. we need to deal with the
complexity of in-guest VMSAs regardless of whether or not KVM supports one for
the BSP, at which point we don't gain much by refusing to support "bring your
own VMSA" (so long as the uAPI and implementation are clean and don't add undue
burden).