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 defined as follows: - patches 1 and 2 are unrelated fixes and improvements for the SEV API - patches 3 to 5 introduce the new device attribute to retrieve supported VMSA features - patches 6 to 7 introduce new infrastructure for VM types, partly lifted out of the TDX patches - patches 8 and 9 introduce respectively the new VM types for SEV and SEV-ES, and KVM_SEV_INIT2 as a new sub-operation for KVM_MEM_ENCRYPT_OP. - patches 10 and 11 are tests. The last patch is not intended to be applied in order to keep some coverage of KVM_SEV_INIT and KVM_SEV_ES_INIT in self tests; but it is there as "proof" that migration can be made to work with the new API as well. 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 Isaku Yamahata (1): KVM: x86: Add is_vm_type_supported callback Paolo Bonzini (10): KVM: x86: define standard behavior for bits 0/1 of VM type KVM: SEV: fix compat ABI for KVM_MEMORY_ENCRYPT_OP KVM: introduce new vendor op for KVM_GET_DEVICE_ATTR Documentation: kvm/sev: separate description of firmware KVM: SEV: publish supported VMSA features KVM: SEV: store VMSA features in kvm_sev_info KVM: SEV: define VM types for SEV and SEV-ES KVM: SEV: introduce KVM_SEV_INIT2 operation selftests: kvm: add tests for KVM_SEV_INIT2 selftests: kvm: switch sev_migrate_tests to KVM_SEV_INIT2 Documentation/virt/kvm/api.rst | 2 + .../virt/kvm/x86/amd-memory-encryption.rst | 81 +++++++-- arch/x86/include/asm/kvm-x86-ops.h | 2 + arch/x86/include/asm/kvm_host.h | 4 +- arch/x86/include/uapi/asm/kvm.h | 42 ++++- arch/x86/kvm/svm/sev.c | 104 +++++++++++- arch/x86/kvm/svm/svm.c | 14 +- arch/x86/kvm/svm/svm.h | 6 +- arch/x86/kvm/x86.c | 158 ++++++++++++++---- arch/x86/kvm/x86.h | 2 + tools/testing/selftests/kvm/Makefile | 1 + .../selftests/kvm/include/kvm_util_base.h | 6 +- .../selftests/kvm/set_memory_region_test.c | 8 +- .../selftests/kvm/x86_64/sev_init2_tests.c | 147 ++++++++++++++++ .../selftests/kvm/x86_64/sev_migrate_tests.c | 45 ++--- 15 files changed, 530 insertions(+), 92 deletions(-) create mode 100644 tools/testing/selftests/kvm/x86_64/sev_init2_tests.c -- 2.39.0
