From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id EF86321A00AC9 for ; Tue, 4 Jul 2017 04:52:44 -0700 (PDT) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jul 2017 04:54:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,307,1496127600"; d="scan'208";a="874628585" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by FMSMGA003.fm.intel.com with ESMTP; 04 Jul 2017 04:54:22 -0700 Received: from fmsmsx156.amr.corp.intel.com (10.18.116.74) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 4 Jul 2017 04:54:22 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by fmsmsx156.amr.corp.intel.com (10.18.116.74) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 4 Jul 2017 04:54:22 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.146]) by SHSMSX104.ccr.corp.intel.com ([10.239.4.70]) with mapi id 14.03.0319.002; Tue, 4 Jul 2017 19:54:20 +0800 From: "Gao, Liming" To: Laszlo Ersek , edk2-devel-01 CC: Ard Biesheuvel , "Justen, Jordan L" Thread-Topic: [PATCH v2 1/2] OvmfPkg: disable build-time relocation for DXEFV modules Thread-Index: AQHS9Kxm4AVsIypA5kW/OpCCBm+Uz6JDjyag Date: Tue, 4 Jul 2017 11:54:19 +0000 Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14D7512A0@shsmsx102.ccr.corp.intel.com> References: <20170704100022.18828-1-lersek@redhat.com> <20170704100022.18828-2-lersek@redhat.com> In-Reply-To: <20170704100022.18828-2-lersek@redhat.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: [PATCH v2 1/2] OvmfPkg: disable build-time relocation for DXEFV modules X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 11:52:45 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reviewed-by: Liming Gao > -----Original Message----- > From: Laszlo Ersek [mailto:lersek@redhat.com] > Sent: Tuesday, July 4, 2017 6:00 PM > To: edk2-devel-01 > Cc: Ard Biesheuvel ; Justen, Jordan L ; Gao, Liming > Subject: [PATCH v2 1/2] OvmfPkg: disable build-time relocation for DXEFV = modules >=20 > When the GenFv utility from BaseTools composes a firmware volume, it > checks whether modules in the firmware volume are subject to build-time > relocation. The primary indication for relocation is whether the firmware > volume has a nonzero base address, according to the [FD] section(s) in th= e > FDF file that refer to the firmware volume. >=20 > The idea behind build-time relocation is that XIP (execute in place) > modules will not be relocated at boot-time: >=20 > - Pre-DXE phase modules generally execute in place. >=20 > (OVMF is no exception, despite the fact that we have writeable memory > even in SEC: PEI_CORE and PEIMs run in-place from PEIFV, after SEC > decompresses PEIFV and DXEFV from FVMAIN_COMPACT (flash) to RAM. > PEI_CORE and the PEIMs are relocated at boot-time only after PlatformPe= i > installs the permanent PEI RAM, and the RAM migration occurs.) >=20 > - Modules dispatched by the DXE Core are generally relocated at boot-time= . > However, this is not necessarily so. Quoting Liming from > : >=20 > > PI spec has no limitation that XIP is for PEIM only. DXE driver may be > > built as XIP for other purpose. For example, if DXE driver image addres= s > > is not zero, DxeCore will try allocating the preferred address and load > > it. In another case, once DXE driver is relocated at build time, DxeCor= e > > will dispatch it and start it directly without loading, it may save boo= t > > performance. >=20 > Therefore GenFv relocates even DXE and UEFI driver modules if the > containing firmware volume has a nonzero base address. >=20 > In OVMF, this is the case for both PEIV and DXEFV: >=20 > > [FD.MEMFD] > > BaseAddress =3D $(MEMFD_BASE_ADDRESS) > > Size =3D 0xB00000 > > ErasePolarity =3D 1 > > BlockSize =3D 0x10000 > > NumBlocks =3D 0xB0 > > ... > > 0x020000|0x0E0000 > > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGu= id.PcdOvmfPeiMemFvSize > > FV =3D PEIFV > > > > 0x100000|0xA00000 > > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGu= id.PcdOvmfDxeMemFvSize > > FV =3D DXEFV >=20 > While the build-time relocation certainly makes sense for PEIFV (see > above), the reasons for which we specify DXEFV under [FD.MEMFD] are > weaker: >=20 > - we set the PcdOvmfDxeMemFvBase and PcdOvmfDxeMemFvSize PCDs here, >=20 > - and we ascertain that DXEFV, when decompressed by SEC from > FVMAIN_COMPACT, will fit into the area allotted here, at build time. >=20 > In other words, the build-time relocation of the modules in DXEFV is a > waste of resources. But, it gets worse: >=20 > Build-time relocation of an executable is only possible if the on-disk an= d > in-memory layouts are identical, i.e., if the sections of the PE/COFF > image adhere to the same alignment on disk and in memory. Put differently= , > the FileAlignment and SectionAlignment headers must be equal. >=20 > For boot-time modules that we build as part of edk2, both alignment value= s > are 0x20 bytes. For runtime modules that we build as part of edk2, both > alignment values are 0x1000 bytes. This is why the DXEFV relocation, > albeit wasteful, is also successful every time. >=20 > Unfortunately, if we try to include a PE/COFF binary in DXEFV that > originates from outside of edk2, the DXEFV relocation can fail due to the > binary having unmatched FileAlignment and SectionAlignment headers. This > is precisely the case with the E3522X2.EFI network driver for the e1000 > NIC, from Intel's BootUtil / PREBOOT.EXE distribution. >=20 > The solution is to use the FvForceRebase=3DFALSE override under [FV.DXEFV= ]. > This tells GenFv not to perform build-time relocation on the firmware > volume, despite the FV having a nonzero base address. >=20 > In DXEFV we also have SMM drivers. Those are relocated at boot-time (into > SMRAM) unconditionally; SMRAM is always discovered at boot-time. >=20 > Kudos to Ard and Liming for the PE/COFF sections & relocations > explanation, and for the FvForceRebase=3DFALSE tip. >=20 > I regression-tested this change in the following configurations (all with > normal boot and S3 suspend/resume): >=20 > IA32, q35, SMM, Linux > IA32X64, q35, SMM, Linux > IA32X64, q35, SMM, Windows-8.1 > X64, i440fx, no-SMM, Linux >=20 > Cc: Ard Biesheuvel > Cc: Jordan Justen > Cc: Liming Gao > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D613 > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D615 > Suggested-by: Ard Biesheuvel > Suggested-by: Liming Gao > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Laszlo Ersek > --- >=20 > Notes: > v2: > - in the commit message, replace LMFA references with Liming's > explanation from the mailing list > - no code changes >=20 > OvmfPkg/OvmfPkgIa32.fdf | 1 + > OvmfPkg/OvmfPkgIa32X64.fdf | 1 + > OvmfPkg/OvmfPkgX64.fdf | 1 + > 3 files changed, 3 insertions(+) >=20 > diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf > index 09c165882c3f..859457e9aae5 100644 > --- a/OvmfPkg/OvmfPkgIa32.fdf > +++ b/OvmfPkg/OvmfPkgIa32.fdf > @@ -168,6 +168,7 @@ [FV.PEIFV] > ########################################################################= ######## >=20 > [FV.DXEFV] > +FvForceRebase =3D FALSE > FvNameGuid =3D 7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1 > BlockSize =3D 0x10000 > FvAlignment =3D 16 > diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf > index 5233314139bc..2a0ed8313786 100644 > --- a/OvmfPkg/OvmfPkgIa32X64.fdf > +++ b/OvmfPkg/OvmfPkgIa32X64.fdf > @@ -168,6 +168,7 @@ [FV.PEIFV] > ########################################################################= ######## >=20 > [FV.DXEFV] > +FvForceRebase =3D FALSE > FvNameGuid =3D 7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1 > BlockSize =3D 0x10000 > FvAlignment =3D 16 > diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf > index 36150101e784..ca61fa125795 100644 > --- a/OvmfPkg/OvmfPkgX64.fdf > +++ b/OvmfPkg/OvmfPkgX64.fdf > @@ -168,6 +168,7 @@ [FV.PEIFV] > ########################################################################= ######## >=20 > [FV.DXEFV] > +FvForceRebase =3D FALSE > FvNameGuid =3D 7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1 > BlockSize =3D 0x10000 > FvAlignment =3D 16 > -- > 2.13.1.3.g8be5a757fa67 >=20