| Message ID | 20190710201244.25195-1-brijesh.singh@amd.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add AMD SEV guest live migration support | expand |
On Wed, Jul 10, 2019 at 08:12:59PM +0000, Singh, Brijesh wrote: > The series add support for AMD SEV guest live migration commands. To protect the > confidentiality of an SEV protected guest memory while in transit we need to > use the SEV commands defined in SEV API spec [1]. > > SEV guest VMs have the concept of private and shared memory. Private memory > is encrypted with the guest-specific key, while shared memory may be encrypted > with hypervisor key. The commands provided by the SEV FW are meant to be used > for the private memory only. The patch series introduces a new hypercall. > The guest OS can use this hypercall to notify the page encryption status. > If the page is encrypted with guest specific-key then we use SEV command during > the migration. If page is not encrypted then fallback to default. > I am bit lost. Why can't the hypervisor keep track of hypervisor key pages and treat all other pages as owned by the guest and hence using the guest-specific key?
On 7/12/19 10:52 AM, Konrad Rzeszutek Wilk wrote: > On Wed, Jul 10, 2019 at 08:12:59PM +0000, Singh, Brijesh wrote: >> The series add support for AMD SEV guest live migration commands. To protect the >> confidentiality of an SEV protected guest memory while in transit we need to >> use the SEV commands defined in SEV API spec [1]. >> >> SEV guest VMs have the concept of private and shared memory. Private memory >> is encrypted with the guest-specific key, while shared memory may be encrypted >> with hypervisor key. The commands provided by the SEV FW are meant to be used >> for the private memory only. The patch series introduces a new hypercall. >> The guest OS can use this hypercall to notify the page encryption status. >> If the page is encrypted with guest specific-key then we use SEV command during >> the migration. If page is not encrypted then fallback to default. >> > > I am bit lost. Why can't the hypervisor keep track of hypervisor key pages > and treat all other pages as owned by the guest and hence using the guest-specific > key? > The guest OS marks the pages 'private' or 'shared'. It is done by setting page encryption flag (aka C-bit) in guest page table. The shared pages may not necessary be just hypervisor key pages. In case of SEV, DMA needs to be done on the shared pages, so guest OS marks the DMA buffers as shared. -Brijesh
The series add support for AMD SEV guest live migration commands. To protect the confidentiality of an SEV protected guest memory while in transit we need to use the SEV commands defined in SEV API spec [1]. SEV guest VMs have the concept of private and shared memory. Private memory is encrypted with the guest-specific key, while shared memory may be encrypted with hypervisor key. The commands provided by the SEV FW are meant to be used for the private memory only. The patch series introduces a new hypercall. The guest OS can use this hypercall to notify the page encryption status. If the page is encrypted with guest specific-key then we use SEV command during the migration. If page is not encrypted then fallback to default. The patch adds new ioctls KVM_{SET,GET}_PAGE_ENC_BITMAP. The ioctl can be used by the qemu to get the page encrypted bitmap. Qemu can consult this bitmap during the migration to know whether the page is encrypted. [1] https://developer.amd.com/wp-content/resources/55766.PDF While implementing the migration I stumbled on the follow question: - Since there is a guest OS changes required to support the migration, so how do we know whether guest OS is updated? Should we extend KVM capabilities/feature bits to check this? The complete tree with patch is available at: https://github.com/codomania/kvm/tree/sev-migration-v3 Changes since v2: - reset the page encryption bitmap on vcpu reboot Changes since v1: - Add support to share the page encryption between the source and target machine. - Fix review feedbacks from Tom Lendacky. - Add check to limit the session blob length. - Update KVM_GET_PAGE_ENC_BITMAP icotl to use the base_gfn instead of the memory slot when querying the bitmap. Brijesh Singh (11): KVM: SVM: Add KVM_SEV SEND_START command KVM: SVM: Add KVM_SEND_UPDATE_DATA command KVM: SVM: Add KVM_SEV_SEND_FINISH command KVM: SVM: Add support for KVM_SEV_RECEIVE_START command KVM: SVM: Add KVM_SEV_RECEIVE_UPDATE_DATA command KVM: SVM: Add KVM_SEV_RECEIVE_FINISH command KVM: x86: Add AMD SEV specific Hypercall3 KVM: X86: Introduce KVM_HC_PAGE_ENC_STATUS hypercall KVM: x86: Introduce KVM_GET_PAGE_ENC_BITMAP ioctl mm: x86: Invoke hypercall when page encryption status is changed KVM: x86: Introduce KVM_SET_PAGE_ENC_BITMAP ioctl .../virtual/kvm/amd-memory-encryption.rst | 120 ++++ Documentation/virtual/kvm/api.txt | 48 ++ Documentation/virtual/kvm/hypercalls.txt | 14 + arch/x86/include/asm/kvm_host.h | 4 + arch/x86/include/asm/kvm_para.h | 12 + arch/x86/include/asm/mem_encrypt.h | 3 + arch/x86/kvm/svm.c | 580 +++++++++++++++++- arch/x86/kvm/vmx/vmx.c | 1 + arch/x86/kvm/x86.c | 29 + arch/x86/mm/mem_encrypt.c | 45 +- arch/x86/mm/pageattr.c | 15 + include/uapi/linux/kvm.h | 52 ++ include/uapi/linux/kvm_para.h | 1 + 13 files changed, 919 insertions(+), 5 deletions(-)