|
From: | Tobin Feldman-Fitzthum |
Subject: | RFC: Fast Migration for SEV and SEV-ES - blueprint and proof of concept |
Date: | Fri, 30 Oct 2020 13:53:35 -0400 |
User-agent: | Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 |
Hello,Dov Murik, James Bottomley, Hubertus Franke, and I have been working on a plan for fast live migration with SEV and SEV-ES. We just posted an RFC about it to the edk2 list. It includes a proof-of-concept for what we feel to be the most difficult part of fast live migration with SEV-ES.
https://edk2.groups.io/g/devel/topic/77875297This was posted to the edk2 list because OVMF is one of the main components of our approach to live migration. With SEV/SEV-ES the hypervisor generally does not have access to guest memory/CPU state. We propose a Migration Handler in OVMF that runs inside the guest and assists the hypervisor with migration. One major challenge to this approach is that for SEV-ES this Migration Handler must be able to set the CPU state of the target to the CPU state of the source while the target is running. Our demo shows that this is feasible.
While OVMF is a major component of our approach, QEMU obviously has a huge part to play as well. We want to start thinking about the best way to support fast live migration for SEV and for encrypted VMs in general. A handful of issues are starting to come into focus. For instance, the target VM needs to be started before we begin receiving pages from the source VM. We will also need to start an extra vCPU for the Migration Handler to run on. We are currently working on a demo of end-to-end live migration for SEV (non-ES) VMs that should help crystallize these issues. It should be on the list around the end of the year. For now, check out our other post, which has a lot more information and let me know if you have any thoughts.
-Tobin
[Prev in Thread] | Current Thread | [Next in Thread] |