From nobody Fri Dec 27 18:15:01 2024 Delivered-To: importer@patchew.org Received-SPF: none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) client-ip=198.145.21.10; envelope-from=edk2-devel-bounces@lists.01.org; helo=ml01.01.org; Authentication-Results: mx.zoho.com; spf=none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) smtp.mailfrom=edk2-devel-bounces@lists.01.org; Return-Path: Received: from ml01.01.org (ml01.01.org [198.145.21.10]) by mx.zohomail.com with SMTPS id 1498687618791465.3044947856498; Wed, 28 Jun 2017 15:06:58 -0700 (PDT) Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 1BBB821CB74CB; Wed, 28 Jun 2017 15:05:23 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 EDF0F21CB74C7 for ; Wed, 28 Jun 2017 15:05:19 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7A2A43B74E; Wed, 28 Jun 2017 22:06:51 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-57.phx2.redhat.com [10.3.116.57]) by smtp.corp.redhat.com (Postfix) with ESMTP id 547405DC1D; Wed, 28 Jun 2017 22:06:50 +0000 (UTC) X-Original-To: edk2-devel@lists.01.org DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7A2A43B74E Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 7A2A43B74E From: Laszlo Ersek To: edk2-devel-01 Date: Thu, 29 Jun 2017 00:06:44 +0200 Message-Id: <20170628220645.26413-2-lersek@redhat.com> In-Reply-To: <20170628220645.26413-1-lersek@redhat.com> References: <20170628220645.26413-1-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 28 Jun 2017 22:06:51 +0000 (UTC) Subject: [edk2] [PATCH 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: , Cc: Jordan Justen , Liming Gao , Ard Biesheuvel MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" X-ZohoMail: RSF_4 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" 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 the FDF file that refer to the firmware volume. The idea behind build-time relocation is that XIP (execute in place) modules will not be relocated at boot-time: - Pre-DXE phase modules generally execute in place. (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 PlatformPei installs the permanent PEI RAM, and the RAM migration occurs.) - Modules dispatched by the DXE Core are generally relocated at boot-time. However, this is not necessarily so, the LMFA (Load Modules at Fixed Address) feature apparently allows in-place execution for such modules as well, deriving the load address from the containing firmware volume's base address at build time. (LMFA is controlled by the gEfiMdeModulePkgTokenSpaceGuid.PcdLoadModuleAtFixAddressEnable fixed PCD, which we leave disabled in OVMF.) Therefore GenFv relocates even DXE and UEFI driver modules if the containing firmware volume has a nonzero base address. In OVMF, this is the case for both PEIV and DXEFV: > [FD.MEMFD] > BaseAddress =3D $(MEMFD_BASE_ADDRESS) > Size =3D 0xB00000 > ErasePolarity =3D 1 > BlockSize =3D 0x10000 > NumBlocks =3D 0xB0 > ... > 0x020000|0x0E0000 > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid= .PcdOvmfPeiMemFvSize > FV =3D PEIFV > > 0x100000|0xA00000 > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid= .PcdOvmfDxeMemFvSize > FV =3D DXEFV While the build-time relocation certainly makes sense for PEIFV (see above), the reasons for which we specify DXEFV under [FD.MEMFD] are weaker: - we set the PcdOvmfDxeMemFvBase and PcdOvmfDxeMemFvSize PCDs here, - and we ascertain that DXEFV, when decompressed by SEC from FVMAIN_COMPACT, will fit into the area allotted here, at build time. In other words, the build-time relocation of the modules in DXEFV is a waste of resources. But, it gets worse: Build-time relocation of an executable is only possible if the on-disk and 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. For boot-time modules that we build as part of edk2, both alignment values 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. 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. 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. As stated above, this relocation has always been useless and wasteful in OVMF, because we never enable LMFA. (Put differently, E3522X2.EFI could never be loaded from an FV with LMFA enabled for the platform because E3522X2.EFI has unmatched FileAlignment and SectionAlignment headers.) In DXEFV we also have SMM drivers. Those are relocated at boot-time (into SMRAM) unconditionally, regardless of LMFA; SMRAM is always discovered at boot-time. Kudos to Ard and Liming for the PE/COFF sections & relocations explanation, and for the FvForceRebase=3DFALSE tip. I regression-tested this change in the following configurations (all with normal boot and S3 suspend/resume): IA32, q35, SMM, Linux IA32X64, q35, SMM, Linux IA32X64, q35, SMM, Windows-8.1 X64, i440fx, no-SMM, Linux 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 --- OvmfPkg/OvmfPkgIa32.fdf | 1 + OvmfPkg/OvmfPkgIa32X64.fdf | 1 + OvmfPkg/OvmfPkgX64.fdf | 1 + 3 files changed, 3 insertions(+) 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 --=20 2.13.1.3.g8be5a757fa67 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel From nobody Fri Dec 27 18:15:01 2024 Delivered-To: importer@patchew.org Received-SPF: none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) client-ip=198.145.21.10; envelope-from=edk2-devel-bounces@lists.01.org; helo=ml01.01.org; Authentication-Results: mx.zoho.com; spf=none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) smtp.mailfrom=edk2-devel-bounces@lists.01.org; Return-Path: Received: from ml01.01.org (ml01.01.org [198.145.21.10]) by mx.zohomail.com with SMTPS id 1498687620062888.1516354066065; Wed, 28 Jun 2017 15:07:00 -0700 (PDT) Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 534C121BBC410; Wed, 28 Jun 2017 15:05:23 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 4300121CB74B5 for ; Wed, 28 Jun 2017 15:05:21 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C5F77C0587D1; Wed, 28 Jun 2017 22:06:52 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-57.phx2.redhat.com [10.3.116.57]) by smtp.corp.redhat.com (Postfix) with ESMTP id CCAC65DC1D; Wed, 28 Jun 2017 22:06:51 +0000 (UTC) X-Original-To: edk2-devel@lists.01.org DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C5F77C0587D1 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com C5F77C0587D1 From: Laszlo Ersek To: edk2-devel-01 Date: Thu, 29 Jun 2017 00:06:45 +0200 Message-Id: <20170628220645.26413-3-lersek@redhat.com> In-Reply-To: <20170628220645.26413-1-lersek@redhat.com> References: <20170628220645.26413-1-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 28 Jun 2017 22:06:52 +0000 (UTC) Subject: [edk2] [PATCH 2/2] OvmfPkg: update -D E1000_ENABLE from Intel PROEFI v.07 to BootUtil v.22 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: , Cc: Jordan Justen , Jiaxin Wu MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" X-ZohoMail: RSF_4 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" Jiaxin reports that the OvmfPkg/README instructions for downloading the Intel PROEFI drivers, and the filenames in OvmfPkg/OvmfPkg*.fdf for incorporating the same in the OVMF binaries, are no longer up to date; the download link has stopped working. Additionally, the IA32 driver binary is no more distributed by Intel. Update OvmfPkg/README with new download instructions, and adapt the OVMF FDF files. With this driver in use for QEMU's e1000 NIC, the DH shell command prints, as Controller Name, "Intel(R) PRO/1000 MT Network Connection". I successfully tested DHCP and ping from the UEFI shell. Cc: Jiaxin Wu Cc: Jordan Justen Reported-by: Jiaxin Wu Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D613 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek Reviewed-by: Wu Jiaxin Tested-by: Wu Jiaxin --- OvmfPkg/OvmfPkgIa32.fdf | 5 ---- OvmfPkg/OvmfPkgIa32X64.fdf | 2 +- OvmfPkg/OvmfPkgX64.fdf | 2 +- OvmfPkg/README | 31 +++++++++++++------- 4 files changed, 23 insertions(+), 17 deletions(-) diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf index 859457e9aae5..cd91bc03a683 100644 --- a/OvmfPkg/OvmfPkgIa32.fdf +++ b/OvmfPkg/OvmfPkgIa32.fdf @@ -294,11 +294,6 @@ [FV.DXEFV] # # Network modules # -!if $(E1000_ENABLE) - FILE DRIVER =3D 5D695E11-9B3F-4b83-B25F-4A8D5D69BE07 { - SECTION PE32 =3D Intel3.5/EFI32/E3507E2.EFI - } -!endif INF MdeModulePkg/Universal/Network/SnpDxe/SnpDxe.inf INF MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf INF MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf index 2a0ed8313786..fae82709aee1 100644 --- a/OvmfPkg/OvmfPkgIa32X64.fdf +++ b/OvmfPkg/OvmfPkgIa32X64.fdf @@ -296,7 +296,7 @@ [FV.DXEFV] # !if $(E1000_ENABLE) FILE DRIVER =3D 5D695E11-9B3F-4b83-B25F-4A8D5D69BE07 { - SECTION PE32 =3D Intel3.5/EFIX64/E3507X2.EFI + SECTION PE32 =3D Intel3.5/EFIX64/E3522X2.EFI } !endif INF MdeModulePkg/Universal/Network/SnpDxe/SnpDxe.inf diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf index ca61fa125795..4da0b19b94cf 100644 --- a/OvmfPkg/OvmfPkgX64.fdf +++ b/OvmfPkg/OvmfPkgX64.fdf @@ -296,7 +296,7 @@ [FV.DXEFV] # !if $(E1000_ENABLE) FILE DRIVER =3D 5D695E11-9B3F-4b83-B25F-4A8D5D69BE07 { - SECTION PE32 =3D Intel3.5/EFIX64/E3507X2.EFI + SECTION PE32 =3D Intel3.5/EFIX64/E3522X2.EFI } !endif INF MdeModulePkg/Universal/Network/SnpDxe/SnpDxe.inf diff --git a/OvmfPkg/README b/OvmfPkg/README index 33ff9432bb3e..00fb71848200 100644 --- a/OvmfPkg/README +++ b/OvmfPkg/README @@ -224,24 +224,35 @@ longer.) basic virtio-net driver, located in OvmfPkg/VirtioNetDxe. =20 * Also independently of the iPXE NIC drivers, Intel's proprietary E1000 NIC - driver (PROEFI) can be embedded in the OVMF image at build time: + driver (from the BootUtil distribution) can be embedded in the OVMF imag= e at + build time: =20 - - Download UEFI drivers for the e1000 NIC - - http://downloadcenter.intel.com/Detail_Desc.aspx?agr=3DY&DwnldID=3D1= 7515&lang=3Deng - - Install the drivers into a directory called Intel3.5 in your WORKSPA= CE. + - Download BootUtil: + - Navigate to + https://downloadcenter.intel.com/download/19186/Ethernet-Intel-Ether= net-Connections-Boot-Utility-Preboot-Images-and-EFI-Drivers + - Click the download link for "PREBOOT.EXE". + - Accept the Intel Software License Agreement that appears. + - Unzip "PREBOOT.EXE" into a separate directory (this works with the + "unzip" utility on platforms different from Windows as well). + - Copy the "APPS/EFI/EFIx64/E3522X2.EFI" driver binary to + "Intel3.5/EFIX64/E3522X2.EFI" in your WORKSPACE. + - Intel have stopped distributing an IA32 driver binary (which used to + match the filename pattern "E35??E2.EFI"), thus this method will only + work for the IA32X64 and X64 builds of OVMF. =20 - Include the driver in OVMF during the build: - - Add "-D E1000_ENABLE" to your build command, + - Add "-D E1000_ENABLE" to your build command (only when building + "OvmfPkg/OvmfPkgIa32X64.dsc" or "OvmfPkg/OvmfPkgX64.dsc"). - For example: "build -D E1000_ENABLE". =20 * When a matching iPXE driver is configured for a NIC as described above, = it takes priority over other drivers that could possibly drive the card too: =20 - | e1000 ne2k_pci pcnet rtl8139 virtio-net-pci - -------------+------------------------------------------------ - iPXE | x x x x x - VirtioNetDxe | x - Intel PROEFI | x + | e1000 ne2k_pci pcnet rtl8139 virtio-net-pci + ---------------------+------------------------------------------------ + iPXE | x x x x x + VirtioNetDxe | x + Intel BootUtil (X64) | x =20 =3D=3D=3D OVMF Flash Layout =3D=3D=3D =20 --=20 2.13.1.3.g8be5a757fa67 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel