On Thu, Feb 13, 2020 at 2:28 PM Ashish Kalra <ashish.kalra@xxxxxxx> 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@xxxxxxx> wrote: > >> > > >> > From: Brijesh Singh <brijesh.singh@xxxxxxx> > > > > > > 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?
