[PATCH 0/2] OvmfPkg: refresh -D E1000_ENABLE (Intel proprietary driver for e1000)

[PATCH 0/2] OvmfPkg: refresh -D E1000_ENABLE (Intel proprietary driver for e1000)

[Laszlo Ersek]

The current instructions in the README, and the filenames in the FDF
files, are out of date. They are updated in the second patch.

Including the new driver in DXEFV requires a separate one-liner build
tweak for DXEFV, which however takes a wall of text to explain. This is
done in the first patch.

Repo:   https://github.com/lersek/edk2.git
Branch: e1000_refresh

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Liming Gao <liming.gao@intel.com>

Thanks,
Laszlo

Laszlo Ersek (2):
  OvmfPkg: disable build-time relocation for DXEFV modules
  OvmfPkg: update -D E1000_ENABLE from Intel PROEFI v.07 to BootUtil
    v.22

 OvmfPkg/OvmfPkgIa32.fdf    |  6 +---
 OvmfPkg/OvmfPkgIa32X64.fdf |  3 +-
 OvmfPkg/OvmfPkgX64.fdf     |  3 +-
 OvmfPkg/README             | 31 +++++++++++++-------
 4 files changed, 26 insertions(+), 17 deletions(-)

-- 
2.13.1.3.g8be5a757fa67

[PATCH 1/2] OvmfPkg: disable build-time relocation for DXEFV modules

[Laszlo Ersek]

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   = $(MEMFD_BASE_ADDRESS)
> Size          = 0xB00000
> ErasePolarity = 1
> BlockSize     = 0x10000
> NumBlocks     = 0xB0
> ...
> 0x020000|0x0E0000
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
> FV = PEIFV
>
> 0x100000|0xA00000
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
> FV = 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=FALSE 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=FALSE 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 <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=613
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=615
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Suggested-by: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 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]
 ################################################################################
 
 [FV.DXEFV]
+FvForceRebase      = FALSE
 FvNameGuid         = 7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1
 BlockSize          = 0x10000
 FvAlignment        = 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]
 ################################################################################
 
 [FV.DXEFV]
+FvForceRebase      = FALSE
 FvNameGuid         = 7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1
 BlockSize          = 0x10000
 FvAlignment        = 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]
 ################################################################################
 
 [FV.DXEFV]
+FvForceRebase      = FALSE
 FvNameGuid         = 7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1
 BlockSize          = 0x10000
 FvAlignment        = 16
-- 
2.13.1.3.g8be5a757fa67

[PATCH 2/2] OvmfPkg: update -D E1000_ENABLE from Intel PROEFI v.07 to BootUtil v.22

[Laszlo Ersek]

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 <jiaxin.wu@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Reported-by: Jiaxin Wu <jiaxin.wu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=613
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 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 = 5D695E11-9B3F-4b83-B25F-4A8D5D69BE07 {
-    SECTION PE32 = 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 = 5D695E11-9B3F-4b83-B25F-4A8D5D69BE07 {
-    SECTION PE32 = Intel3.5/EFIX64/E3507X2.EFI
+    SECTION PE32 = 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 = 5D695E11-9B3F-4b83-B25F-4A8D5D69BE07 {
-    SECTION PE32 = Intel3.5/EFIX64/E3507X2.EFI
+    SECTION PE32 = 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.
 
 * 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 image at
+  build time:
 
-  - Download UEFI drivers for the e1000 NIC
-    - http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=17515&lang=eng
-    - Install the drivers into a directory called Intel3.5 in your WORKSPACE.
+  - Download BootUtil:
+    - Navigate to
+      https://downloadcenter.intel.com/download/19186/Ethernet-Intel-Ethernet-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.
 
   - 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".
 
 * 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:
 
-                 | 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
 
 === OVMF Flash Layout ===
 
-- 
2.13.1.3.g8be5a757fa67

Re: [PATCH 1/2] OvmfPkg: disable build-time relocation for DXEFV modules

[Gao, Liming]

Laszlo:
  LMFA feature doesn't do PE image rebase at build time. Only XIP module needs to be rebased at build time. LMFA feature will specify the loaded memory address for each PE image. At build time, build tool records the memory address into the one field of PE image. It doesn't rebase PE image. At boot time, PeiCore/DxeCore/SmmCore will parse PE image, and try to load it at the preferred memory address. If the preferred memory address is not available, PE image will be loaded to other memory address. LMFA feature only supports the source build EFI image, not support the binary EFI image. This is a debug feature. 

  For this case, OvmfPkg DXEFV doesn't require to run as XIP. So, it doesn't require rebase. I agree this change. 

Thanks
Liming
>-----Original Message-----
>From: Laszlo Ersek [mailto:lersek@redhat.com]
>Sent: Thursday, June 29, 2017 6:07 AM
>To: edk2-devel-01 <edk2-devel@lists.01.org>
>Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Justen, Jordan L
><jordan.l.justen@intel.com>; Gao, Liming <liming.gao@intel.com>
>Subject: [PATCH 1/2] OvmfPkg: disable build-time relocation for DXEFV
>modules
>
>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   = $(MEMFD_BASE_ADDRESS)
>> Size          = 0xB00000
>> ErasePolarity = 1
>> BlockSize     = 0x10000
>> NumBlocks     = 0xB0
>> ...
>> 0x020000|0x0E0000
>>
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgToke
>nSpaceGuid.PcdOvmfPeiMemFvSize
>> FV = PEIFV
>>
>> 0x100000|0xA00000
>>
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTok
>enSpaceGuid.PcdOvmfDxeMemFvSize
>> FV = 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=FALSE 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=FALSE 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 <ard.biesheuvel@linaro.org>
>Cc: Jordan Justen <jordan.l.justen@intel.com>
>Cc: Liming Gao <liming.gao@intel.com>
>Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=613
>Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=615
>Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>Suggested-by: Liming Gao <liming.gao@intel.com>
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>---
> 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]
>
>###########################################################
>#####################
>
> [FV.DXEFV]
>+FvForceRebase      = FALSE
> FvNameGuid         = 7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1
> BlockSize          = 0x10000
> FvAlignment        = 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]
>
>###########################################################
>#####################
>
> [FV.DXEFV]
>+FvForceRebase      = FALSE
> FvNameGuid         = 7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1
> BlockSize          = 0x10000
> FvAlignment        = 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]
>
>###########################################################
>#####################
>
> [FV.DXEFV]
>+FvForceRebase      = FALSE
> FvNameGuid         = 7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1
> BlockSize          = 0x10000
> FvAlignment        = 16
>--
>2.13.1.3.g8be5a757fa67
>

Re: [PATCH 2/2] OvmfPkg: update -D E1000_ENABLE from Intel PROEFI v.07 to BootUtil v.22

[Wu, Jiaxin]

After patch with "[PATCH 1/2] disable build-time relocation for DXEFV modules", I can pass the platform build, then HTTP boot feature has been verified.

Tested-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>

Thanks,
Jiaxin

> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Thursday, June 29, 2017 6:07 AM
> To: edk2-devel-01 <edk2-devel@lists.01.org>
> Cc: Wu, Jiaxin <jiaxin.wu@intel.com>; Justen, Jordan L
> <jordan.l.justen@intel.com>
> Subject: [PATCH 2/2] OvmfPkg: update -D E1000_ENABLE from Intel PROEFI
> v.07 to BootUtil v.22
> 
> 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 <jiaxin.wu@intel.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Reported-by: Jiaxin Wu <jiaxin.wu@intel.com>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=613
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>  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 = 5D695E11-9B3F-4b83-B25F-4A8D5D69BE07 {
> -    SECTION PE32 = 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 = 5D695E11-9B3F-4b83-B25F-4A8D5D69BE07 {
> -    SECTION PE32 = Intel3.5/EFIX64/E3507X2.EFI
> +    SECTION PE32 = 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 = 5D695E11-9B3F-4b83-B25F-4A8D5D69BE07 {
> -    SECTION PE32 = Intel3.5/EFIX64/E3507X2.EFI
> +    SECTION PE32 = 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.
> 
>  * 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
> image at
> +  build time:
> 
> -  - Download UEFI drivers for the e1000 NIC
> -    -
> http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=17515&
> lang=eng
> -    - Install the drivers into a directory called Intel3.5 in your WORKSPACE.
> +  - Download BootUtil:
> +    - Navigate to
> +      https://downloadcenter.intel.com/download/19186/Ethernet-Intel-
> Ethernet-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.
> 
>    - 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".
> 
>  * 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:
> 
> -                 | 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
> 
>  === OVMF Flash Layout ===
> 
> --
> 2.13.1.3.g8be5a757fa67

Re: [PATCH 2/2] OvmfPkg: update -D E1000_ENABLE from Intel PROEFI v.07 to BootUtil v.22

[Laszlo Ersek]

On 06/30/17 03:20, Wu, Jiaxin wrote:
> After patch with "[PATCH 1/2] disable build-time relocation for DXEFV modules", I can pass the platform build, then HTTP boot feature has been verified.
> 
> Tested-by: Wu Jiaxin <jiaxin.wu@intel.com>
> Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
> 

Thank you!
Laszlo

Re: [PATCH 1/2] OvmfPkg: disable build-time relocation for DXEFV modules

[Laszlo Ersek]

Liming,

On 06/29/17 05:32, Gao, Liming wrote:
> Laszlo:
>   LMFA feature doesn't do PE image rebase at build time. Only XIP
>   module needs to be rebased at build time.

Thank you for the clarification.

In this case, BaseTools/GenFv has a bug.

Namely, if LMFA does not need build-time relocation for DXE-phase
modules, then *what exactly* needs build-time relocation for DXE-phase
modules?

This is the code in "BaseTools/Source/C/GenFv/GenFvInternalLib.c":

  3537        case EFI_FV_FILETYPE_DRIVER:
  3538        case EFI_FV_FILETYPE_DXE_CORE:
  3539          //
  3540          // Check if section-alignment and file-alignment match or not
  3541          //
  3542          if ((ImgHdr->Pe32.OptionalHeader.SectionAlignment != ImgHdr->Pe32.OptionalHeader.FileAlignment)) {
  3543            //
  3544            // Xip module has the same section alignment and file alignment.
  3545            //
  3546            Error (NULL, 0, 3000, "Invalid", "Section-Alignment and File-Alignment do not match : %s.", FileName);
  3547            return EFI_ABORTED;
  3548          }
  3549          NewPe32BaseAddress = XipBase + (UINTN) CurrentPe32Section.Pe32Section + CurSecHdrSize - (UINTN)FfsFile;
  3550          break;

According to the Platform Init 1.6 spec,

- 2.1.4.1 Firmware File Types:

  [...] the type EFI_FV_FILETYPE_DRIVER indicates that the file is a DXE
  driver and is interesting to the DXE Dispatcher.

- 2.1.4.1.4 EFI_FV_FILETYPE_DRIVER:

  The file type EFI_FV_FILETYPE_DRIVER denotes a file that contains a
  PE32 image that can be dispatched by the DXE Dispatcher.

So, *when exactly* is it the case that a module dispatched by the DXE
core *needs* build-time relocation?

I claim that the answer is "never", and therefore the above code is a
bug in BaseTools/GenFv.

I thought that this build-time relocation was needed by the LMFA
feature, but you confirmed above that LMFA does not need it. So, it
looks like *nothing at all* needs build-time relocation for
EFI_FV_FILETYPE_DRIVER, because the modules dispatched by the DXE core
are *never* XIP modules.

Do you agree?

>   For this case, OvmfPkg DXEFV doesn't require to run as XIP. So, it
>   doesn't require rebase. I agree this change.

This change (for the OVMF FDF files) is only valid if the above
BaseTools/GenFv code is also valid. In other words, *if* there is at
least one valid reason for rebasing DXE modules at build-time.

If there is *no* such reason, then the OVMF FDF files do not need this
change, and GenFv must be fixed instead.

So: if LMFA is *not* the one reason that justifies the rebasing for
EFI_FV_FILETYPE_DRIVER, then *what* is the reason? In my commit message
for the OVMF FDF change, I have to refer to that exact reason.

Thanks
Laszlo

Re: [PATCH 1/2] OvmfPkg: disable build-time relocation for DXEFV modules

[Gao, Liming]

Laszlo:
  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 address is not zero, DxeCore will try allocating the preferred address and load it. In another case, once DXE driver is relocated at build time, DxeCore will dispatch it and start it directly without loading, it may save boot performance. 

Thanks
Liming
>-----Original Message-----
>From: Laszlo Ersek [mailto:lersek@redhat.com]
>Sent: Sunday, July 02, 2017 4:36 AM
>To: Gao, Liming <liming.gao@intel.com>; edk2-devel-01 <edk2-
>devel@lists.01.org>
>Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Justen, Jordan L
><jordan.l.justen@intel.com>
>Subject: Re: [PATCH 1/2] OvmfPkg: disable build-time relocation for DXEFV
>modules
>
>Liming,
>
>On 06/29/17 05:32, Gao, Liming wrote:	
>> Laszlo:
>>   LMFA feature doesn't do PE image rebase at build time. Only XIP
>>   module needs to be rebased at build time.
>
>Thank you for the clarification.
>
>In this case, BaseTools/GenFv has a bug.
>
>Namely, if LMFA does not need build-time relocation for DXE-phase
>modules, then *what exactly* needs build-time relocation for DXE-phase
>modules?
>
>This is the code in "BaseTools/Source/C/GenFv/GenFvInternalLib.c":
>
>  3537        case EFI_FV_FILETYPE_DRIVER:
>  3538        case EFI_FV_FILETYPE_DXE_CORE:
>  3539          //
>  3540          // Check if section-alignment and file-alignment match or not
>  3541          //
>  3542          if ((ImgHdr->Pe32.OptionalHeader.SectionAlignment != ImgHdr-
>>Pe32.OptionalHeader.FileAlignment)) {
>  3543            //
>  3544            // Xip module has the same section alignment and file alignment.
>  3545            //
>  3546            Error (NULL, 0, 3000, "Invalid", "Section-Alignment and File-
>Alignment do not match : %s.", FileName);
>  3547            return EFI_ABORTED;
>  3548          }
>  3549          NewPe32BaseAddress = XipBase + (UINTN)
>CurrentPe32Section.Pe32Section + CurSecHdrSize - (UINTN)FfsFile;
>  3550          break;
>
>According to the Platform Init 1.6 spec,
>
>- 2.1.4.1 Firmware File Types:
>
>  [...] the type EFI_FV_FILETYPE_DRIVER indicates that the file is a DXE
>  driver and is interesting to the DXE Dispatcher.
>
>- 2.1.4.1.4 EFI_FV_FILETYPE_DRIVER:
>
>  The file type EFI_FV_FILETYPE_DRIVER denotes a file that contains a
>  PE32 image that can be dispatched by the DXE Dispatcher.
>
>So, *when exactly* is it the case that a module dispatched by the DXE
>core *needs* build-time relocation?
>
>I claim that the answer is "never", and therefore the above code is a
>bug in BaseTools/GenFv.
>
>I thought that this build-time relocation was needed by the LMFA
>feature, but you confirmed above that LMFA does not need it. So, it
>looks like *nothing at all* needs build-time relocation for
>EFI_FV_FILETYPE_DRIVER, because the modules dispatched by the DXE core
>are *never* XIP modules.
>
>Do you agree?
>
>>   For this case, OvmfPkg DXEFV doesn't require to run as XIP. So, it
>>   doesn't require rebase. I agree this change.
>
>This change (for the OVMF FDF files) is only valid if the above
>BaseTools/GenFv code is also valid. In other words, *if* there is at
>least one valid reason for rebasing DXE modules at build-time.
>
>If there is *no* such reason, then the OVMF FDF files do not need this
>change, and GenFv must be fixed instead.
>
>So: if LMFA is *not* the one reason that justifies the rebasing for
>EFI_FV_FILETYPE_DRIVER, then *what* is the reason? In my commit message
>for the OVMF FDF change, I have to refer to that exact reason.
>
>Thanks
>Laszlo

Re: [PATCH 1/2] OvmfPkg: disable build-time relocation for DXEFV modules

[Laszlo Ersek]

On 07/03/17 17:08, Gao, Liming wrote:

> 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
> address is not zero, DxeCore will try allocating the preferred address
> and load it. In another case, once DXE driver is relocated at build
> time, DxeCore will dispatch it and start it directly without loading,
> it may save boot performance.

OK, I'll update the commit message on patch #1 and repost the series.

Thanks
Laszlo

Re: [PATCH 1/2] OvmfPkg: disable build-time relocation for DXEFV modules

[Jordan Justen]

On 2017-06-28 20:32:54, Gao, Liming wrote:
> Laszlo:
>   LMFA feature doesn't do PE image rebase at build time. Only XIP
>   module needs to be rebased at build time. LMFA feature will
>   specify the loaded memory address for each PE image. At build
>   time, build tool records the memory address into the one field of
>   PE image. It doesn't rebase PE image. At boot time,
>   PeiCore/DxeCore/SmmCore will parse PE image, and try to load it at
>   the preferred memory address. If the preferred memory address is
>   not available, PE image will be loaded to other memory address.
>   LMFA feature only supports the source build EFI image, not support
>   the binary EFI image. This is a debug feature.
> 
>   For this case, OvmfPkg DXEFV doesn't require to run as XIP. So, it
>   doesn't require rebase. I agree this change.
> 

Liming,

With this flag set to FALSE, do we attempt to rebase the images, but
just not fail if we can't rebase one of the modules? Or, will this
disable rebasing of all modules in the FV?

I don't think we really make use of this debug feature in OVMF today,
but I was wondering what potential impact it might have. I thought in
some cases by loading the modules at a fixed address it can help with
loading symbols for debug, right?

Laszlo,

I don't think you need to hold off on the patches for this answer, so
you can add an Acked-by from me for your v2.

-Jordan

>
> >-----Original Message-----
> >From: Laszlo Ersek [mailto:lersek@redhat.com]
> >Sent: Thursday, June 29, 2017 6:07 AM
> >To: edk2-devel-01 <edk2-devel@lists.01.org>
> >Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Justen, Jordan L
> ><jordan.l.justen@intel.com>; Gao, Liming <liming.gao@intel.com>
> >Subject: [PATCH 1/2] OvmfPkg: disable build-time relocation for DXEFV
> >modules
> >
> >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   = $(MEMFD_BASE_ADDRESS)
> >> Size          = 0xB00000
> >> ErasePolarity = 1
> >> BlockSize     = 0x10000
> >> NumBlocks     = 0xB0
> >> ...
> >> 0x020000|0x0E0000
> >>
> >gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgToke
> >nSpaceGuid.PcdOvmfPeiMemFvSize
> >> FV = PEIFV
> >>
> >> 0x100000|0xA00000
> >>
> >gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTok
> >enSpaceGuid.PcdOvmfDxeMemFvSize
> >> FV = 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=FALSE 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=FALSE 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 <ard.biesheuvel@linaro.org>
> >Cc: Jordan Justen <jordan.l.justen@intel.com>
> >Cc: Liming Gao <liming.gao@intel.com>
> >Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=613
> >Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=615
> >Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >Suggested-by: Liming Gao <liming.gao@intel.com>
> >Contributed-under: TianoCore Contribution Agreement 1.0
> >Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> >---
> > 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]
> >
> >###########################################################
> >#####################
> >
> > [FV.DXEFV]
> >+FvForceRebase      = FALSE
> > FvNameGuid         = 7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1
> > BlockSize          = 0x10000
> > FvAlignment        = 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]
> >
> >###########################################################
> >#####################
> >
> > [FV.DXEFV]
> >+FvForceRebase      = FALSE
> > FvNameGuid         = 7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1
> > BlockSize          = 0x10000
> > FvAlignment        = 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]
> >
> >###########################################################
> >#####################
> >
> > [FV.DXEFV]
> >+FvForceRebase      = FALSE
> > FvNameGuid         = 7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1
> > BlockSize          = 0x10000
> > FvAlignment        = 16
> >--
> >2.13.1.3.g8be5a757fa67
> >
> 

Re: [PATCH 1/2] OvmfPkg: disable build-time relocation for DXEFV modules

[Laszlo Ersek]

On 07/05/17 19:48, Jordan Justen wrote:
> On 2017-06-28 20:32:54, Gao, Liming wrote:
>> Laszlo:
>>   LMFA feature doesn't do PE image rebase at build time. Only XIP
>>   module needs to be rebased at build time. LMFA feature will
>>   specify the loaded memory address for each PE image. At build
>>   time, build tool records the memory address into the one field of
>>   PE image. It doesn't rebase PE image. At boot time,
>>   PeiCore/DxeCore/SmmCore will parse PE image, and try to load it at
>>   the preferred memory address. If the preferred memory address is
>>   not available, PE image will be loaded to other memory address.
>>   LMFA feature only supports the source build EFI image, not support
>>   the binary EFI image. This is a debug feature.
>>
>>   For this case, OvmfPkg DXEFV doesn't require to run as XIP. So, it
>>   doesn't require rebase. I agree this change.
>>
> 
> Liming,
> 
> With this flag set to FALSE, do we attempt to rebase the images, but
> just not fail if we can't rebase one of the modules? Or, will this
> disable rebasing of all modules in the FV?
> 
> I don't think we really make use of this debug feature in OVMF today,
> but I was wondering what potential impact it might have. I thought in
> some cases by loading the modules at a fixed address it can help with
> loading symbols for debug, right?
> 
> Laszlo,
> 
> I don't think you need to hold off on the patches for this answer, so
> you can add an Acked-by from me for your v2.

Thanks, will do.
Laszlo