| Message ID | 20190806165429.19327-3-brijesh.singh@amd.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add SEV guest live migration support | expand |
* Singh, Brijesh (brijesh.singh@amd.com) wrote: > Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> > --- > docs/amd-memory-encryption.txt | 40 +++++++++++++++++++++++++++++++++- > 1 file changed, 39 insertions(+), 1 deletion(-) > > diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt > index 8822cadda1..01d95089a8 100644 > --- a/docs/amd-memory-encryption.txt > +++ b/docs/amd-memory-encryption.txt > @@ -89,7 +89,45 @@ TODO > > Live Migration > ---------------- > -TODO > +AMD SEV encrypts the memory of VMs and because a different key is used > +in each VM, the hypervisor will be unable to simply copy the > +ciphertext from one VM to another to migrate the VM. Instead the AMD SEV Key > +Management API provides sets of function which the hypervisor can use > +to package a guest page for migration, while maintaining the confidentiality > +provided by AMD SEV. > + > +SEV guest VMs have the concept of private and shared memory. The private > +memory is encrypted with the guest-specific key, while shared memory may > +be encrypted with the hypervisor key. The migration APIs provided by the > +SEV API spec should be used for migrating the private pages. The > +KVM_GET_PAGE_ENC_BITMAP ioctl can be used to get the guest page encryption > +bitmap. The bitmap can be used to check if the given guest page is > +private or shared. > + > +Before initiating the migration, we need to know the targets machine's public > +Diffie-Hellman key (PDH) and certificate chain. It can be retrieved > +with the 'query-sev-capabilities' QMP command or using the sev-tool. The > +migrate-set-parameter can be used to pass the target machine's PDH and > +certificate chain. > + > +During the migration flow, the SEND_START is called on the source hypervisor > +to create an outgoing encryption context. The SEV guest policy dictates whether > +the certificate passed through the migrate-sev-set-info command will be > +validated. SEND_UPDATE_DATA is called to encrypt the guest private pages. > +After migration is completed, SEND_FINISH is called to destroy the encryption > +context and make the VM non-runnable to protect it against cloning. > + > +On the target machine, RECEIVE_START is called first to create an > +incoming encryption context. The RECEIVE_UPDATE_DATA is called to copy > +the received encrypted page into guest memory. After migration has > +completed, RECEIVE_FINISH is called to make the VM runnable. > + > +For more information about the migration see SEV API Appendix A > +Usage flow (Live migration section). > + > +NOTE: > +To protect against the memory clone SEV APIs are designed to make the VM > +unrunnable in case of the migration failure. > > References > ----------------- > -- > 2.17.1 > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt index 8822cadda1..01d95089a8 100644 --- a/docs/amd-memory-encryption.txt +++ b/docs/amd-memory-encryption.txt @@ -89,7 +89,45 @@ TODO Live Migration ---------------- -TODO +AMD SEV encrypts the memory of VMs and because a different key is used +in each VM, the hypervisor will be unable to simply copy the +ciphertext from one VM to another to migrate the VM. Instead the AMD SEV Key +Management API provides sets of function which the hypervisor can use +to package a guest page for migration, while maintaining the confidentiality +provided by AMD SEV. + +SEV guest VMs have the concept of private and shared memory. The private +memory is encrypted with the guest-specific key, while shared memory may +be encrypted with the hypervisor key. The migration APIs provided by the +SEV API spec should be used for migrating the private pages. The +KVM_GET_PAGE_ENC_BITMAP ioctl can be used to get the guest page encryption +bitmap. The bitmap can be used to check if the given guest page is +private or shared. + +Before initiating the migration, we need to know the targets machine's public +Diffie-Hellman key (PDH) and certificate chain. It can be retrieved +with the 'query-sev-capabilities' QMP command or using the sev-tool. The +migrate-set-parameter can be used to pass the target machine's PDH and +certificate chain. + +During the migration flow, the SEND_START is called on the source hypervisor +to create an outgoing encryption context. The SEV guest policy dictates whether +the certificate passed through the migrate-sev-set-info command will be +validated. SEND_UPDATE_DATA is called to encrypt the guest private pages. +After migration is completed, SEND_FINISH is called to destroy the encryption +context and make the VM non-runnable to protect it against cloning. + +On the target machine, RECEIVE_START is called first to create an +incoming encryption context. The RECEIVE_UPDATE_DATA is called to copy +the received encrypted page into guest memory. After migration has +completed, RECEIVE_FINISH is called to make the VM runnable. + +For more information about the migration see SEV API Appendix A +Usage flow (Live migration section). + +NOTE: +To protect against the memory clone SEV APIs are designed to make the VM +unrunnable in case of the migration failure. References -----------------
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> --- docs/amd-memory-encryption.txt | 40 +++++++++++++++++++++++++++++++++- 1 file changed, 39 insertions(+), 1 deletion(-)