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 01:43, Sean Christopherson wrote:
> 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/ajr1r-PAiXMnZ7x1@xxxxxxxxxx

This seems pretty much in line with what I just suggested. In that message, I didn't realize you were already suggesting to replace the entire patch set with that ioctl.

--
Jethro Beekman | CTO | Fortanix

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