On Mon, Aug 16, 2021 at 6:37 AM Ashish Kalra <Ashish.Kalra@xxxxxxx> wrote: > > From: Ashish Kalra <ashish.kalra@xxxxxxx> > > This is an RFC series for Mirror VM support that are > essentially secondary VMs sharing the encryption context > (ASID) with a primary VM. The patch-set creates a new > VM and shares the primary VM's encryption context > with it using the KVM_CAP_VM_COPY_ENC_CONTEXT_FROM capability. > The mirror VM uses a separate pair of VM + vCPU file > descriptors and also uses a simplified KVM run loop, > for example, it does not support any interrupt vmexit's. etc. > Currently the mirror VM shares the address space of the > primary VM. Sharing an address space is incompatible with post-copy migration via UFFD on the target side. I'll be honest and say I'm not deeply familiar with QEMU's implementation of post-copy, but I imagine there must be a mapping of guest memory that doesn't fault: on the target side (or on both sides), the migration helper will need to have it's view of guest memory go through that mapping, or a similar mapping. Separately, I'm a little weary of leaving the migration helper mapped into the shared address space as writable. Since the migration threads will be executing guest-owned code, the guest could use these threads to do whatever it pleases (including getting free cycles). The migration helper's code needs to be trusted by both the host and the guest. Making it non-writable, sourced by the host, and attested by the hardware would mitigate these concerns. The host could also try to monitor for malicious use of migration threads, but that would be pretty finicky. The host could competitively schedule the migration helper vCPUs with the guest vCPUs, but I'd imagine that wouldn't be the best for guest performance. --Steve
