From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124])
 by mx.groups.io with SMTP id smtpd.web08.2268.1614890752328007552
 for <devel@edk2.groups.io>;
 Thu, 04 Mar 2021 12:45:52 -0800
Authentication-Results: mx.groups.io;
 dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=SzeR0EuQ;
 spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1614890751;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=XmqemosQWYgov5Oczz4xNxz2b4Xtd0TXLZRNQFZIrdI=;
	b=SzeR0EuQdX2QMn8X/Cs1E8MjXBfCINzHjeVuAD9RnLvKJxaW9gGWaJBEUYndxwrOmu+MIo
	9P8YbsUZl+agPssx8r5cZaJ4nzVaHbbZwdShVnSEf0rftmtFSQNBLRdkHYbUsthHLGS564
	cM5MplNfUx3FxU/FgifxFOkE9jO9Da4=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-135-1MIaVDCAN76UKHLA6ypNXw-1; Thu, 04 Mar 2021 15:45:49 -0500
X-MC-Unique: 1MIaVDCAN76UKHLA6ypNXw-1
Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7F81180432A;
	Thu,  4 Mar 2021 20:45:48 +0000 (UTC)
Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-76.ams2.redhat.com [10.36.112.76])
	by smtp.corp.redhat.com (Postfix) with ESMTP id A9B935C1B4;
	Thu,  4 Mar 2021 20:45:47 +0000 (UTC)
Subject: Re: [edk2-devel] [RFC PATCH 00/14] Firmware Support for Fast Live Migration for AMD SEV
To: devel@edk2.groups.io, pbonzini@redhat.com,
 Tobin Feldman-Fitzthum <tobin@linux.ibm.com>
References: <20210302204839.82042-1-tobin@linux.ibm.com>
 <9205.1614849670474335263@groups.io>
From: "Laszlo Ersek" <lersek@redhat.com>
Message-ID: <7775b8d9-ed8d-eb4f-0c1a-3552996cef90@redhat.com>
Date: Thu, 4 Mar 2021 21:45:46 +0100
MIME-Version: 1.0
In-Reply-To: <9205.1614849670474335263@groups.io>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16
Authentication-Results: relay.mimecast.com;
	auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit

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?)

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