On Mon, Feb 26, 2024 at 02:03:29PM -0500, Paolo Bonzini wrote: > The idea that no parameter would ever be necessary when enabling SEV or > SEV-ES for a VM was decidedly optimistic. 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. > > 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. > > The series is structured as follows: > > - patches 1 to 5 are unrelated fixes and improvements for the SEV code > and documentation. In particular they change sev.c so that it is > compiled only if SEV is enabled in kconfig > > - patches 6 to 8 introduce the new device attribute to retrieve supported > VMSA features > > - patch 9 disables DEBUG_SWAP by default > > - patches 10 and 11 introduce new infrastructure for VM types, replacing > the similar code in the TDX patches > > - patches 12 to 14 introduce the new VM types for SEV and > SEV-ES, and KVM_SEV_INIT2 as a new sub-operation for KVM_MEM_ENCRYPT_OP. > > - patch 15 tests the new ioctl. > > The idea is that SEV SNP will only ever support KVM_SEV_INIT2. I have > patches in progress for QEMU to support this new API. > > Thanks, > > Paolo > > > v2->v3: > - use u64_to_user_addr() > - Compile sev.c if and only if CONFIG_KVM_AMD_SEV=y > - remove double signoffs > - rebase on top of kvm-x86/next I can't apply this series on top of current kvm-x86/next. On what exact commit the series is based on? Confused... -- An old man doll... just what I always wanted! - Clara
Attachment:
signature.asc
Description: PGP signature
