On Tue, Aug 17, 2021 at 1:50 PM Tobin Feldman-Fitzthum <tobin@xxxxxxxxxxxxx> wrote: > > > On 8/17/21 12:32 PM, Paolo Bonzini wrote: > > There's three possibilities for this: > > > > 1) the easy one: the bottom 4G of guest memory are mapped in the > > mirror VM 1:1. The ram_addr_t-based addresses are shifted by either > > 4G or a huge value such as 2^42 (MAXPHYADDR - physical address > > reduction - 1). This even lets the migration helper reuse the OVMF > > runtime services memory map (but be careful about thread safety...). > > This is essentially what we do in our prototype, although we have an > even simpler approach. We have a 1:1 mapping that maps an address to > itself with the cbit set. During Migration QEMU asks the migration > handler to import/export encrypted pages and provides the GPA for said > page. Since the migration handler only exports/imports encrypted pages, > we can have the cbit set for every page in our mapping. We can still use > OVMF functions with these mappings because they are on encrypted pages. > The MH does need to use a few shared pages (to communicate with QEMU, > for instance), so we have another mapping without the cbit that is at a > large offset. > > I think this is basically equivalent to what you suggest. As you point > out above, this approach does require that any page that will be > exported/imported by the MH is mapped in the guest. Is this a bad > assumption? The VMSA for SEV-ES is one example of a region that is > encrypted but not mapped in the guest (the PSP handles it directly). We > have been planning to map the VMSA into the guest to support migration > with SEV-ES (along with other changes). Ahh, It sounds like you are looking into sidestepping the existing AMD-SP flows for migration. I assume the idea is to spin up a VM on the target side, and have the two VMs attest to each other. How do the two sides know if the other is legitimate? I take it that the source is directing the LAUNCH flows? --Steve
