On Fri, Feb 09, 2024, Paolo Bonzini wrote: > The idea that no parameter would ever be necessary when enabling SEV or > SEV-ES for a VM was decidedly optimistic. That implies there was a conscious decision regarding the uAPI. AFAICT, all of the SEV uAPIs are direct reflections of the PSP invocations. Which is why I'm being so draconian about the SNP uAPIs; this time around, we need to actually design something. > The first source of variability that was encountered is the desired set of > VMSA features, as that affects the measurement of the VM's initial state and > cannot be changed arbitrarily by the hypervisor. > > This series adds all the APIs that are needed to customize the features, > with room for future enhancements: > > - a new /dev/kvm device attribute to retrieve the set of supported > features (right now, only debug swap) > > - a new sub-operation for KVM_MEM_ENCRYPT_OP that can take a struct, > replacing the existing KVM_SEV_INIT and KVM_SEV_ES_INIT > > It then puts the new op to work by including the VMSA features as a field > of the The existing KVM_SEV_INIT and KVM_SEV_ES_INIT use the full set of > supported VMSA features for backwards compatibility; but I am considering > also making them use zero as the feature mask, and will gladly adjust the > patches if so requested. Rather than add a new KVM_MEMORY_ENCRYPT_OP, I think we should go for broke and start building the generic set of "protected VM" APIs. E.g. TDX wants to add KVM_TDX_INIT_VM, and I'm guessing ARM needs similar functionality. And AFAIK, every technology follows an INIT => ADD (MEASURE) * N => FINALIZE type sequence. If need be, I would rather have a massive union, a la kvm_run, to hold the vendor specific bits than end up with sub-sub-ioctls and every vendor implementation reinventing the wheel. If it's sane and feasible for userspace, maybe even KVM_CREATE_VM2? > In order to avoid creating *two* new KVM_MEM_ENCRYPT_OPs, I decided that > I could as well make SEV and SEV-ES use VM types. And then, why not make > a SEV-ES VM, when created with the new VM type instead of KVM_SEV_ES_INIT, > reject KVM_GET_REGS/KVM_SET_REGS and friends on the vCPU file descriptor > once the VMSA has been encrypted... Which is how the API should have > always behaved. +1000
