* Steve Rutherford (srutherford@xxxxxxxxxx) wrote: > 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. Ignoring SEV, our postcopy currently has a single mapping which is guarded by UFFD. There is no 'no-fault' mapping. We use the uffd ioctl to 'place' a page into that space when we receive it. But yes, I guess that can't work with SEV; as you say; if the helper has to do the write, it'll have to do it into a shadow that it can write to, even though the rest of th e guest must UF on access. > 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)a Agreed. > . 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. Some people worry about having the host supply the guest firmware, because they worry they'll be railroaded into using something they don't actually trust, and if there aim of using SEV etc is to avoid trusting the cloud owner, that breaks that. So for them, I think they want the migration helper to be trusted by the guest and tolerated by the host. > 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. The CPU usage has to go somewhere. Dave > > --Steve > -- Dr. David Alan Gilbert / dgilbert@xxxxxxxxxx / Manchester, UK
