From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) by mx.groups.io with SMTP id smtpd.web12.996.1611365372003417173 for ; Fri, 22 Jan 2021 17:29:32 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=Z1G4Ubi1; spf=pass (domain: apple.com, ip: 17.151.62.68, mailfrom: afish@apple.com) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 10N1LOu3043751; Fri, 22 Jan 2021 17:29:29 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=dXJK6IOkqaUbIHER1ux12RPnlPyB/n7AGI7kDCxEs7o=; b=Z1G4Ubi1de3GNFlKwbySzJmuN+pFYmBOTLTiEzX0ahfw85Ud0I8Z1ZcysVZagUjEKsIU uJVRn9q/MMMUfE+LZGhGUiQYNMWmNTGc2mqqhGss6pHa0+k1e2A9+IpaLzFRQixNKlX7 cTWmvnmTvixY7KyVNwJLra2PTl8F9QaQVVfDTmVxct9Eywq2Q74q4cs3nXIDfwMghuSb PJc4e+DD04qPDY/TpS41KCjzcT8MNg29VRN1zg+Epj4MuF1VtBGrDW0mYfpBPrR1iciV epolNSgmYpyFHrg8VlsxUw4m/AO46A451vcB7VA6cZkEYT2yEF9ngS8/ssb7lirGmpqA SQ== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by nwk-aaemail-lapp03.apple.com with ESMTP id 367k3188yg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 22 Jan 2021 17:29:29 -0800 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPS id <0QND00D9N5H4DCD0@rn-mailsvcp-mta-lapp04.rno.apple.com>; Fri, 22 Jan 2021 17:29:28 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) id <0QND00I005EP8G00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Fri, 22 Jan 2021 17:29:28 -0800 (PST) X-Va-A: X-Va-T-CD: fe60454d8cca2d204232efa0cd93203e X-Va-E-CD: fe87dfdd8d606e2ecac11e84730ff99c X-Va-R-CD: 59e06b9307deba3f2b1ab3f54cc79876 X-Va-CD: 0 X-Va-ID: 2ede1794-ba67-495e-a19d-65f4a35810d2 X-V-A: X-V-T-CD: fe60454d8cca2d204232efa0cd93203e X-V-E-CD: fe87dfdd8d606e2ecac11e84730ff99c X-V-R-CD: 59e06b9307deba3f2b1ab3f54cc79876 X-V-CD: 0 X-V-ID: 8e4c5bbb-9968-49d1-b519-4bd6c1da6583 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343,18.0.737 definitions=2021-01-22_16:2021-01-22,2021-01-22 signatures=0 Received: from [17.235.9.47] (unknown [17.235.9.47]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPSA id <0QND00D4A5H3S100@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Fri, 22 Jan 2021 17:29:28 -0800 (PST) From: "Andrew Fish" Message-id: <732BE659-4DEA-48C2-9AAB-1C4A776A0021@apple.com> MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) Subject: Re: [edk2-devel] [PATCH] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Use physical address with SEV-ES Date: Fri, 22 Jan 2021 17:29:22 -0800 In-reply-to: Cc: Tom Lendacky , Brijesh Singh , Jordan Justen , Ard Biesheuvel To: edk2-devel-groups-io , Laszlo Ersek References: <8bba19920e58813f32889dec522bbcd8de113219.1611338106.git.thomas.lendacky@amd.com> <8d660790-fafd-c0d5-f1eb-1e02830a7fa9@redhat.com> X-Mailer: Apple Mail (2.3654.20.0.2.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343,18.0.737 definitions=2021-01-22_16:2021-01-22,2021-01-22 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_37C1A090-4177-459B-B52B-93090849C41F" --Apple-Mail=_37C1A090-4177-459B-B52B-93090849C41F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 22, 2021, at 4:25 PM, Laszlo Ersek wrote: >=20 > On 01/22/21 23:40, Tom Lendacky wrote: >=20 >> Can SetVirtualAddressMap() be called more than once? >=20 > According to the UEFI spec: no, it can't. >=20 > The call to SetVirtualAddressMap() must be done with the physical > mappings. On successful return from this function, the system must > then make any future calls with the newly assigned virtual mappings. >=20 > [...] >=20 > The SetVirtualAddressMap() and ConvertPointer() services are only > callable in physical mode, so they do not need to be converted from > physical pointers to virtual pointers. >=20 > [...] >=20 > A virtual address map may only be applied one time. Once the runtime > system is in virtual mode, calls to this function return > EFI_UNSUPPORTED. >=20 > (I seem to detect a bit of contradiction between quotes #1+#2 and #3 -- > the first two quotes seem to explain that a second call is expected to > be impossible, whereas the third quote explains how a second or later > call should behave. But, anyway, the intent is clear.) >=20 Laszlo, So the answer is no you can=E2=80=99t call it more than once. While the te= xt is confusing it describes the only possible behavior.=20 If you look at the EFI_UNSUPPORTED Status Codes Returned: "EFI firmware is= not at runtime, or the EFI firmware is already in virtual address mapped m= ode.=E2=80=9D This is what the edk2 implementation does [1]. And combine th= at with this text "Once all events have been notified, the EFI firmware rea= pplies image =E2=80=9Cfix-up=E2=80=9D information to virtually relocate all= runtime images to their new addresses. =E2=80=9C. So basically that implie= s that after the1st call all the Runtime drivers have been fixed up to run = at their virtual address. So if you called them again at their physical mod= e address they would likely crash. That crash could be implementation depen= dent I guess based on when the EFI virtual mappings are produced. It is per= fectly legal to only produce them in kernel after ExitBootServices. Remembe= r all the notification functions are registered via their physical address.= = =20 [1] https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Runtim= eDxe/Runtime.c#L245 it enforces the call only once.=20 // // Can only switch to virtual addresses once the memory map is locked do= wn, // and can only set it once // if (!mRuntime.AtRuntime || mRuntime.VirtualMode) { return EFI_UNSUPPORTED; } // // Only understand the original descriptor format // if (DescriptorVersion !=3D EFI_MEMORY_DESCRIPTOR_VERSION || DescriptorSi= ze < sizeof (EFI_MEMORY_DESCRIPTOR)) { return EFI_INVALID_PARAMETER; } // // We are now committed to go to virtual mode, so lets get to it! // mRuntime.VirtualMode =3D TRUE; Thanks, Andrew Fish > Thanks, > Laszlo >=20 >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_37C1A090-4177-459B-B52B-93090849C41F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 22, 2021, at 4:25 PM= , Laszlo Ersek <lersek@r= edhat.com> wrote:

On 01/22/21 23:40, Tom Lendacky wrote:

Can SetVirtualAd= dressMap() be called more than once?

According to the UEFI spec: no, it can't.

   The call to SetVirtualAddressMap() must be done with = the physical
   mappings. On successful retur= n from this function, the system must
   then= make any future calls with the newly assigned virtual mappings.

   [...]

   The SetVirtualAddressMap() and ConvertPointer() service= s are only
   callable in physical mode, so t= hey do not need to be converted from
   physi= cal pointers to virtual pointers.

  = ; [...]

   A virtual addr= ess map may only be applied one time. Once the runtime
 = ;  system is in virtual mode, calls to this function return
   EFI_UNSUPPORTED.

(= I seem to detect a bit of contradiction between quotes #1+#2 and #3 --
the first two quotes seem to explain that a second call is expect= ed to
be impossible, whereas the third quote explains how a s= econd or later
call should behave. But, anyway, the intent is= clear.)


Laszlo,

So the answer is no you can=E2=80=99t call it more than once. While = the text is confusing it describes the only possible behavior. 

If you l= ook at the EFI_UNSUPPORTED Status Codes Returned: "EFI firmware is not at r= untime, or the EFI firmware is already in virtual address mapped mode.=E2= =80=9D This is what the edk2 implementation does [1]. And combine that wit= h this text "Once all events have been notified, the EFI firmware reapplies= image =E2=80=9Cfix-up=E2=80=9D information to virtually relocate all runti= me images to their new addresses. =E2=80=9C. So basically that implies that= after the1st call all the Runtime drivers have been fixed up to run at the= ir virtual address. So if you called them again at their physical mode addr= ess they would likely crash. That crash could be implementation dependent I= guess based on when the EFI virtual mappings are produced. It is perfectly= legal to only produce them in kernel after ExitBootServices. Remember all = the notification functions are registered via their physical address. =


[1] https://github.com/tianocore/edk2/blob/= master/MdeModulePkg/Core/RuntimeDxe/Runtime.c#L245 it enforces the call= only once. 
=
//
// C= an only switch to virtual addresses once the memory map is locked down,
// and can only set it once
//
if (!mRunt= ime.AtRuntime || mRun= time.VirtualMode) {
return EFI_UNSUPPORTED;
}
<= tr style=3D"box-sizing: border-box;" class=3D"">

//
// On= ly understand the original descriptor format
//
if (DescriptorVersion != =3D EFI_MEMORY_DESCRIPTOR_VERSION || DescriptorSize < sizeof (EFI_MEMORY_DESCRIPTOR)) {
return EFI_INVALID_PAR= AMETER;
}
//
// We are now committed to go to virtual mode, so lets get to it!
//
mRuntime.VirtualMode =3D T= RUE;

<= /div>

Thanks,

Andrew Fish
Thanks,
Laszlo







--Apple-Mail=_37C1A090-4177-459B-B52B-93090849C41F--