Re: RFC: Fast Migration for SEV and SEV-ES - blueprint and proof of concept

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Tobin Feldman-Fitzthum (tobin@linux.ibm.com) wrote:
> 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/77875297
> 
> This 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.

That might not be that hard to fudge; we already start the VM in
postcopy mode before we have all of RAM; now in that we have to do stuff
to protect the RAM because we expect the guest to access it; in this
case you possibly don't need to.

> 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.

I don't think I understood why you'd want to map the VMSA, or why it
would be encrypted in such a way it was useful to you.

Dave


> -Tobin
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK