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:02, Sean Christopherson wrote:
> On Tue, Jun 23, 2026, Jethro Beekman wrote:
>> On 2026-06-23 23:43, Sean Christopherson wrote:
>>> On Tue, Jun 23, 2026, Jethro Beekman wrote:
>>>> On 2026-06-23 16:51, Jon Lange wrote:
>>>>> On Tuesday, June 23, 2026 6:40 AM, Sean Christopherson wrote:
>>>>>> On Wed, Jun 17, 2026, Jörg Rödel 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 see 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.  Expanding that
>>>>>>>> surface has a very, very, VERY high bar to get over.
>>>>>>>
>>>>>>> The strongest argument in my view (and the main reason we are doing this) is
>>>>>>> actually the predictable launch measurement. On SEV-SNP this is a requirement
>>>>>>> to use platform VM-identity features like the ID Block.
>>>>>>
>>>>>> And I'm saying that unless KVM *can't* provide a predictable launch measurement,
>>>>>> 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.
>>>>>
>>>>> Joerg is suggesting that we need a launch measurement that is stable not
>>>>> just across multiple launches on the same system, but across multiple
>>>>> hypervisors.
>>>>
>>>> If this is now suddenly an acceptable argument, please also merge https://lkml.org/lkml/2021/4/12/625
>>>
>>> No, that's not how this works.  Dave and Jarkko both have unanswered questions
>>> regarding the use case.  Answer their questions, and I'm confident you'll get
>>> traction.
>>>
>>>  : I don't believe we necessarily *WANT* or need Linux to support "all
>>>  : possible ECREATE, EADD, EEXTEND, EINIT sequences".  Yet, it's what is
>>>  : being used to justify this series without any other justification.
>>>  : 
>>>  : It's going to be a different story if you bring me a real enclave that
>>>  : *REALLY* wants to do this for good reasons.
>>>
>>> and
>>>
>>>  : What specifically are you referring as the "rest of the world"?
>>>  : 
>>>  : That would be mean that there is reviewable workload "out there".
>>>
>>> The start of that thread is *exactly* what's playing out here.  The big difference,
>>> and why this one's likely getting a different result, is that Jon provided a very
>>> thorough explanation of exactly what use case Joerg and company want to support.
>>> The only "assumed knowledge" is why it's desirable for the measurement to be stable
>>> across hypervisors, but I'm comfortable stitching that together on my own.
>>>
>>> In other words, they aren't asking KVM to support every possible way/time a VMSA
>>> could be associated with a vCPU, they're asking to extend KVM to support a concrete
>>> use case, with meaningful real world impact.  In fact, I actually think this series
>>> is *too* narrowly focused on their use case.
>>>
>>> FWIW, KVM_TDX_INIT_MEM_REGION has almost the exact same ABI that SGX has: pages
>>> contents are measured immediately after they're added.
>>
>> Sorry, the argument from Jon/Joerg is no different than the one we made years
>> ago for SGX.
>>
>> It was previously made abundantly clear that it's the kernel maintainers's
>> stance that it's sufficient to offer a UAPI that allows the creation of a
>> Linux-specific subset of enclaves with a stable measurement encompassing
>> largely the enclave functionality available in the hardware. Or said another
>> way: if you can take your enclave and modify it to work with Linux, albeit
>> with a different measurement, that is acceptable. KVM-SNP is currently at
>> that state: it is currently completely possible to load VMs that were
>> designed with the current Linux VMSA in IGVM format.
>>
>> 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.

> (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.

> If that happens to let userspace build
> every architecturally possible VM, then yay!, we got lucky and probably won't
> ever need to revisit this.  But "support every possibility" is not the goal.

-- 
Jethro Beekman | CTO | Fortanix

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