diff options
author | Tom Lendacky <thomas.lendacky@amd.com> | 2020-12-10 11:10:09 -0600 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2020-12-15 05:21:00 -0500 |
commit | ad73109ae7ec30d5bfb76be108e304f9f0af4829 (patch) | |
tree | 9f4f49bbc58f49c77ac0e4679b0094fa8ea04521 /arch/arm64 | |
parent | 16809ecdc1e8ab7278f1d60021ac809edd17d060 (diff) | |
download | linux-ad73109ae7ec30d5bfb76be108e304f9f0af4829.tar.gz linux-ad73109ae7ec30d5bfb76be108e304f9f0af4829.tar.bz2 linux-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/arm64')
0 files changed, 0 insertions, 0 deletions