[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 06/13] doc: update AMD SEV to include Live mi
Dr. David Alan Gilbert
Re: [Qemu-devel] [PATCH v2 06/13] doc: update AMD SEV to include Live migration flow
Fri, 12 Jul 2019 15:29:42 +0100
* Singh, Brijesh (address@hidden) wrote:
> Signed-off-by: Brijesh Singh <address@hidden>
> docs/amd-memory-encryption.txt | 42 +++++++++++++++++++++++++++++++++-
> 1 file changed, 41 insertions(+), 1 deletion(-)
> diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
> index abb9a976f5..374f4b0a94 100644
> --- a/docs/amd-memory-encryption.txt
> +++ b/docs/amd-memory-encryption.txt
> @@ -89,7 +89,47 @@ TODO
> Live Migration
> +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-sev-info object can be used to pass the target machine's PDH and
> +certificate chain.
> +(QMP) migrate-sev-set-info pdh=<target_pdh> plat-cert=<target_cert_chain> \
> + amd-cert=<amd_cert>
> +(QMP) migrate tcp:0:4444
> +During the migration flow, the SEND_START is called on the source hypervisor
> +to create outgoing encryption context. The SEV guest policy dectates whether
^an outgoing ^ d*i*ctates
> +the certificate passed through the migrate-sev-set-info command will be
> +validate. SEND_UPDATE_DATA is called to encrypt the guest private pages.
^ validate*d* ? How does the cert get validated anyway? As a
guest owner what rules can I set about which other host it gets migrated
Actually, thinking about it, I didn't notice anything in the patchset
that checked/gave diagnostics about the guest policy - shouldn't there
be something that nicely says something like:
'Guest policy has NOSEND set, guest can not be migrated'
> +After migration is completed, SEND_FINISH is called to destroy the encryption
> +context and make the VM non-runnable to protect it against the cloning.
^ 'the' not needed
> +On the target machine, RECEIVE_START is called first to create an
> +incoming encryption context. The RECEIVE_UPDATE_DATA is called to copy
> +the receieved 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).
Dr. David Alan Gilbert / address@hidden / Manchester, UK
[Qemu-devel] [PATCH v2 05/13] doc: update AMD SEV API spec web link, Singh, Brijesh, 2019/07/10
[Qemu-devel] [PATCH v2 06/13] doc: update AMD SEV to include Live migration flow, Singh, Brijesh, 2019/07/10
[Qemu-devel] [PATCH v2 04/13] kvm: add support to sync the page encryption state bitmap, Singh, Brijesh, 2019/07/10
[Qemu-devel] [PATCH v2 07/13] target/i386: sev: do not create launch context for an incoming guest, Singh, Brijesh, 2019/07/10
[Qemu-devel] [PATCH v2 08/13] misc.json: add migrate-set-sev-info command, Singh, Brijesh, 2019/07/10
- Re: [Qemu-devel] [PATCH v2 02/13] kvm: introduce high-level API to support encrypted page migration, (continued)