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

On Wed, Jun 24, 2026, Jethro Beekman wrote:
> On 2026-06-24 00:55, Sean Christopherson wrote:
> > 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.
> 
> If the goal is to get rid of the arbitrary 0xFFFFFFFFF000 GPA/put the VMSA in
> guest memory, then we just need a vcpu ioctl that lets you set the GPA.

That's more or less what I suggested[*], hopefully by piggybacking the AP_CREATE
logic inasmuch as possible.  Or were you thinking something even simpler?

[*] https://lore.kernel.org/all/[email protected]