summaryrefslogtreecommitdiffstats
path: root/arch/x86/kernel
diff options
context:
space:
mode:
authorTom Lendacky <thomas.lendacky@amd.com>2020-12-10 11:10:09 -0600
committerPaolo Bonzini <pbonzini@redhat.com>2020-12-15 05:21:00 -0500
commitad73109ae7ec30d5bfb76be108e304f9f0af4829 (patch)
tree9f4f49bbc58f49c77ac0e4679b0094fa8ea04521 /arch/x86/kernel
parent16809ecdc1e8ab7278f1d60021ac809edd17d060 (diff)
downloadlinux-stable-ad73109ae7ec30d5bfb76be108e304f9f0af4829.tar.gz
linux-stable-ad73109ae7ec30d5bfb76be108e304f9f0af4829.tar.bz2
linux-stable-ad73109ae7ec30d5bfb76be108e304f9f0af4829.zip
KVM: SVM: Provide support to launch and run an SEV-ES guest
An SEV-ES guest is started by invoking a new SEV initialization ioctl, KVM_SEV_ES_INIT. This identifies the guest as an SEV-ES guest, which is used to drive the appropriate ASID allocation, VMSA encryption, etc. Before being able to run an SEV-ES vCPU, the vCPU VMSA must be encrypted and measured. This is done using the LAUNCH_UPDATE_VMSA command after all calls to LAUNCH_UPDATE_DATA have been performed, but before LAUNCH_MEASURE has been performed. In order to establish the encrypted VMSA, the current (traditional) VMSA and the GPRs are synced to the page that will hold the encrypted VMSA and then LAUNCH_UPDATE_VMSA is invoked. The vCPU is then marked as having protected guest state. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <e9643245adb809caf3a87c09997926d2f3d6ff41.1607620209.git.thomas.lendacky@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'arch/x86/kernel')
0 files changed, 0 insertions, 0 deletions