From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [edk2-devel] [RFC PATCH 00/14] Firmware Support for Fast Live Migration for AMD SEV To: Tobin Feldman-Fitzthum ,devel@edk2.groups.io From: "Paolo Bonzini" X-Originating-Location: Desio, Lombardy, IT (93.56.170.5) X-Originating-Platform: Linux Firefox 85 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Thu, 04 Mar 2021 01:21:10 -0800 References: <20210302204839.82042-1-tobin@linux.ibm.com> In-Reply-To: <20210302204839.82042-1-tobin@linux.ibm.com> Message-ID: <9205.1614849670474335263@groups.io> Content-Type: multipart/alternative; boundary="J4Ggfr10ggQmBHpk0Nmg" --J4Ggfr10ggQmBHpk0Nmg Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 i= t's much nicer to have a separate VM that goes through a specialized run lo= op; however, even in the firmware level there are some complications (as yo= u pointed out) in letting MpService workers run after ExitBootServices. My idea would be that the firmware would start the VM as usual using the s= ame launch data; then, the firmware would detect it was running as a migrat= ion helper VM during the SEC or PEI phases (for example via the GHCB or som= e other unencrypted communication area), and divert execution to the migrat= ion helper instead of proceeding to the next boot phase. This would be some= what similar in spirit to how edk2 performs S3 resume, if my memory serves = correctly. What do you think? Thanks, Paolo --J4Ggfr10ggQmBHpk0Nmg Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Tobin,

as mentioned in the reply to the QEMU patches posted b= y Tobin, I think the firmware helper approach is very good, but there are s= ome 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 E= xitBootServices.

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 div= ert execution to the migration helper instead of proceeding to the next boo= t phase. This would be somewhat similar in spirit to how edk2 performs S3 r= esume, if my memory serves correctly.

What do you think?
Thanks,

Paolo --J4Ggfr10ggQmBHpk0Nmg--