[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240223104009.632194-1-pbonzini@redhat.com>
Date: Fri, 23 Feb 2024 05:39:58 -0500
From: Paolo Bonzini <pbonzini@...hat.com>
To: linux-kernel@...r.kernel.org,
kvm@...r.kernel.org
Cc: seanjc@...gle.com,
michael.roth@....com,
aik@....com
Subject: [PATCH v2 00/11] KVM: SEV: allow customizing VMSA features
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
- patch 6 (new in v2) disables DEBUG_SWAP by default
- patches 7 and 8 introduce new infrastructure for VM types, partly lifted
out of the TDX patches
- patches 9 and 10 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.
- patch 11 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
v1->v2:
- fix compilation with SEV disabled (patch 4)
- new patch "KVM: SEV: disable DEBUG_SWAP by default" (patch 6)
- move definition of __KVM_X86_*_TYPE outside uapi headers (patch 7)
- do not export __kvm_is_vm_type_supported (patch 8)
- fixes to documentation (patch 10)
- reject all features for SEV (patch 10)
- do not enable any features for legacy KVM_SEV_INIT/KVM_SEV_ES_INIT (patch 10)
Paolo Bonzini (11):
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: disable DEBUG_SWAP by default
KVM: x86: define standard behavior for bits 0/1 of VM type
KVM: x86: Add is_vm_type_supported callback
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
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 | 11 +-
arch/x86/include/uapi/asm/kvm.h | 35 ++++
arch/x86/kvm/svm/sev.c | 110 +++++++++++-
arch/x86/kvm/svm/svm.c | 14 +-
arch/x86/kvm/svm/svm.h | 6 +-
arch/x86/kvm/x86.c | 157 ++++++++++++++----
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 | 146 ++++++++++++++++
13 files changed, 510 insertions(+), 69 deletions(-)
create mode 100644 tools/testing/selftests/kvm/x86_64/sev_init2_tests.c
--
2.39.1
Powered by blists - more mailing lists