> Add a capability for userspace to mirror SEV encryption context from > one vm to another. On our side, this is intended to support a > Migration Helper vCPU, but it can also be used generically to support > other in-guest workloads scheduled by the host. The intention is for > the primary guest and the mirror to have nearly identical memslots. So this causes a cloned VM that you can boot up another CPU into but the boot path must have been already present? In essence we've already been thinking about something like this to get migration running inside OVMF: https://lore.kernel.org/qemu-devel/8b824c44-6a51-c3a7-6596-921dc47fea39@xxxxxxxxxxxxx/ It sounds like this mechanism can be used to boot a vCPU through a mirror VM after the fact, which is very compatible with the above whose mechanism is simply to steal a VCPU to hold in reset until it's activated. However, you haven't published how you activate the entity inside the VM ... do you have patches for this so we can see the internal capture mechanism and mirror VM boot path? > The primary benefits of this are that: > 1) The VMs do not share KVM contexts (think APIC/MSRs/etc), so they > can't accidentally clobber each other. > 2) The VMs can have different memory-views, which is necessary for > post-copy migration (the migration vCPUs on the target need to read > and write to pages, when the primary guest would VMEXIT). > > This does not change the threat model for AMD SEV. Any memory > involved is still owned by the primary guest and its initial state is > still attested to through the normal SEV_LAUNCH_* flows. If userspace > wanted to circumvent SEV, they could achieve the same effect by > simply attaching a vCPU to the primary VM. > This patch deliberately leaves userspace in charge of the memslots > for the mirror, as it already has the power to mess with them in the > primary guest. Well it does alter the threat model in that previously the configuration, including the CPU configuration, was fixed after launch and attestation. Now the CSP can alter the configuration via a mirror. I'm not sure I have a threat for this, but it definitely alters the model. > This patch does not support SEV-ES (much less SNP), as it does not > handle handing off attested VMSAs to the mirror. One of the reasons for doing the sequestered vcpu is that -ES and -SNP require the initial CPU state to be part of the attestation, so with them you can't add CPU state after the fact. I think you could use this model if you declare the vCPU in the mirror in the initial attested VMSA, but that's conjecture at this stage. > For additional context, we need a Migration Helper because SEV PSP > migration is far too slow for our live migration on its own. Using an > in-guest migrator lets us speed this up significantly. We have the same problem here at IBM, hence the RFC referred to above. James
