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

[Jethro Beekman]

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.

--
Jethro Beekman | CTO | Fortanix

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature