Messages in this thread | | | From | Andy Lutomirski <> | Date | Fri, 14 Feb 2020 10:56:53 -0800 | Subject | Re: [PATCH 10/12] mm: x86: Invoke hypercall when page encryption status is changed |
| |
On Thu, Feb 13, 2020 at 2:28 PM Ashish Kalra <ashish.kalra@amd.com> wrote: > > On Wed, Feb 12, 2020 at 09:42:02PM -0800, Andy Lutomirski wrote: > >> On Wed, Feb 12, 2020 at 5:18 PM Ashish Kalra <Ashish.Kalra@amd.com> wrote: > >> > > >> > From: Brijesh Singh <brijesh.singh@amd.com> > > > > > > Invoke a hypercall when a memory region is changed from encrypted -> > > > decrypted and vice versa. Hypervisor need to know the page encryption > > > status during the guest migration. > >> > >> What happens if the guest memory status doesn't match what the > >> hypervisor thinks it is? What happens if the guest gets migrated > >> between the hypercall and the associated flushes? > > This is basically same as the dirty page tracking and logging being done > during Live Migration. As with dirty page tracking and logging we > maintain a page encryption bitmap in the kernel which keeps tracks of > guest's page encrypted/decrypted state changes and this bitmap is > sync'ed regularly from kernel to qemu and also during the live migration > process, therefore any dirty pages whose encryption status will change > during migration, should also have their page status updated when the > page encryption bitmap is sync'ed. > > Also i think that when the amount of dirty pages reach a low threshold, > QEMU stops the source VM and then transfers all the remaining dirty > pages, so at that point, there will also be a final sync of the page > encryption bitmap, there won't be any hypercalls after this as the > source VM has been stopped and the remaining VM state gets transferred.
And have you ensured that, in the inevitable race when a guest gets migrated part way through an encryption state change, that no data corruption occurs?
| |