On 04/03/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.
It's not exactly a warm reboot. It's two VMs booted at the same time,
with exactly the same contents as far as encrypted RAM goes, but
different unencrypted RAM. The difference makes one VM boot regularly
and the other end up in the migration helper. The migration helper can
be entirely contained in PEI, or it can even be its own OS, stored as a
flat binary in the firmware. Whatever is easier.
The divergence would happen much earlier than S3 though. It would have
to happen before the APs are brought up, for example, and essentially
before the first fw_cfg access if (as is likely) the migration helper VM
does not have fw_cfg at all. That's why I brought up the possibility of
diverging as soon as SEC.
- 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?)
Answering the other message:
(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...))
As far as the SEV hardware is concerned, a "VM" is defined by the ASID.
The VM would be separate at the KVM level, but it would share the ASID
(and thus the guest RAM) with the primary VM. So as far as the SEV
hardware and the processor are concerned, the separate VM would be just
one more VMCB that runs with that ASID. Only KVM knows that they are
backed by different file descriptors etc.
In fact, another advantage is that it would be much easier to scale the
migration helper to multiple vCPUs. This is probably also a case for
diverging much earlier than PEI, because a multi-processor migration
helper running in PEI or DXE would require ACPI tables and a lot of
infrastructure that is probably undesirable.
Paolo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72486): https://edk2.groups.io/g/devel/message/72486
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]
-=-=-=-=-=-=-=-=-=-=-=-
