On 03/04/21 21:45, Laszlo Ersek wrote: > On 03/04/21 10:21, Paolo Bonzini wrote: >> Hi Tobin, >> >> as mentioned in the reply to the QEMU patches posted by Tobin, I >> think the firmware helper approach is very good, but there are some >> disadvantages in the idea of auxiliary vCPUs. These are especially >> true in the VMM, where it's much nicer to have a separate VM that >> goes through a specialized run loop; however, even in the firmware >> level there are some complications (as you pointed out) in letting >> MpService workers run after ExitBootServices. >> >> My idea would be that the firmware would start the VM as usual using >> the same launch data; then, the firmware would detect it was running >> as a migration helper VM during the SEC or PEI phases (for example >> via the GHCB or some other unencrypted communication area), and >> divert execution to the migration helper instead of proceeding to the >> next boot phase. This would be somewhat similar in spirit to how edk2 >> performs S3 resume, if my memory serves correctly. > > Very cool. You'd basically warm-reboot the virtual machine into a new > boot mode (cf. BOOT_WITH_FULL_CONFIGURATION vs. BOOT_ON_S3_RESUME in > OvmfPkg/PlatformPei). > > To me that's much more attractive than a "background job". > > The S3 parallel is great. What I'm missing is: > > - Is it possible to warm-reboot an SEV VM? (I vaguely recall that it's > not possible for SEV-ES at least.) Because, that's how we'd transfer > control to the early parts of the firmware again, IIUC your idea, while > preserving the memory contents. > > - Who would initiate this process? S3 suspend is guest-initiated. (Not > that we couldn't use the guest agent, if needed.) > > (In case the idea is really about a separate VM, and not about rebooting > the already running VM, then I don't understand -- how would a separate > VM access the guest RAM that needs to be migrated?)
Sorry -- I've just caught up with the QEMU thread. Your message there: https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg01220.html says: Patches were posted recently to the KVM mailing list to create secondary VMs sharing the encryption context (ASID) with a primary VM I did think of VMs sharing memory, but the goal of SEV seemed to be to prevent exactly that, so I didn't think that was possible. I stand corrected, and yes, this way I understand -- and welcome -- a completely separate VM snooping the migration subject VM's memory. My question would be then whether the migration helper VM would run on its own memory, and just read out the other VM's memory -- or the MH VM would run somewhere inside the original VM's memory (which sounds a lot riskier). But your message explains that too: The main advantage would be that the migration VM would not have to share the address space with the primary VM This sounds ideal; it should allow for a completely independent firmware platform -- we wouldn't even have to call it "OVMF", and it might not even have to contain the DXE Core and later-phase components. (Of course if it's more convenient to keep the stuff in OVMF, that works too.) (For some unsolicited personal information, now I feel less bad about this idea never occurring to me -- I never knew about the KVM patch set that would enable encryption context sharing. (TBH I thought that was prevented, by design, in the SEV hardware...)) A workflow request to Tobin and Dov -- when posting closely interfacing QEMU and edk2 series, it's best to cross-post both series to both lists, and to CC everybody on everything. Feel free to use subject prefixes like [qemu PATCH] and [edk2 PATCH] for clarity. It's been difficult for me to follow both discussions (it doesn't help that I've been CC'd on neither). Thanks! Laszlo > > NB in the X64 PEI phase of OVMF, only the first 4GB of RAM is mapped, so > the migration handler would have to build its own page table under this > approach too. > > Thanks! > Laszlo > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#72454): https://edk2.groups.io/g/devel/message/72454 Mute This Topic: https://groups.io/mt/81036365/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
