OvmfPkg: add a Name GUID to each Firmware Volume

The FDF spec mentions the FvNameGuid statement for [FV.xxxx] sections, but
the detailed description can be found in Volume 3 of the Platform Init
spec (which is at 1.4a currently).

Adding an FvNameGuid statement to [FV.xxx] has the following effects
(implemented by "BaseTools/Source/C/GenFv/GenFvInternalLib.c"):

- The EFI_FIRMWARE_VOLUME_HEADER.ExtHeaderOffset field is set to a nonzero
  value, pointing after EFI_FIRMWARE_VOLUME_HEADER itself (although not
  directly, see below).

- An EFI_FIRMWARE_VOLUME_EXT_HEADER object is created at the pointed-to
  address. This object is not followed by any
  EFI_FIRMWARE_VOLUME_EXT_ENTRY (= extension) entries, so it only
  specifies the Name GUID for the firmware volume.

  The EFI_FIRMWARE_VOLUME_EXT_HEADER for each firmware volume can be found
  in the Build directory as a separate file (20 bytes in size):

  Build/Ovmf*/*_GCC*/FV/*.ext

- The new data consume 48 bytes in the following volumes: SECFV,
  FVMAIN_COMPACT, DXEFV. They comprise:

  - 16 padding bytes,

  - EFI_FFS_FILE_HEADER2 (8 bytes in total: no Name and ExtendedSize
    fields, and Type=EFI_FV_FILETYPE_FFS_PAD),

  - EFI_FIRMWARE_VOLUME_EXT_HEADER (20 bytes, see above),

  - 4 padding bytes.

  (The initial 16 padding bytes and the EFI_FFS_FILE_HEADER2 structure are
  the reason why EFI_FIRMWARE_VOLUME_HEADER.ExtHeaderOffset does not point
  immediately past EFI_FIRMWARE_VOLUME_HEADER.)

  The sizes of the firmware volumes don't change, only their internal
  usages grow by 48 bytes. I verified that the statements and calculations
  in "OvmfPkg/DecomprScratchEnd.fdf.inc" are unaffected and remain valid.

- The new data consume 0 bytes in PEIFV. This is because PEIFV has enough
  internal padding at the moment to accomodate the above structures
  without a growth in usage.

In the future, firmware volumes can be identified by Name GUID (Fv(...)
device path nodes), rather than memory location (MemoryMapped(...) device
path nodes). This is supposed to improve stability for persistent device
paths that refer to FFS files; for example, UEFI boot options.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Suggested-by: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

1 files changed, 4 insertions, 0 deletions

diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 30b0c2ba3f..6e468a8ab0 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -98,6 +98,7 @@ FV = DXEFV
 ################################################################################

 

 [FV.SECFV]

+FvNameGuid         = 763BED0D-DE9F-48F5-81F1-3E90E1B1A015

 BlockSize          = 0x1000

 FvAlignment        = 16

 ERASE_POLARITY     = 1

@@ -128,6 +129,7 @@ INF  RuleOverride=RESET_VECTOR OvmfPkg/ResetVector/ResetVector.inf
 

 ################################################################################

 [FV.PEIFV]

+FvNameGuid         = 6938079B-B503-4E3D-9D24-B28337A25806

 BlockSize          = 0x10000

 FvAlignment        = 16

 ERASE_POLARITY     = 1

@@ -166,6 +168,7 @@ INF  OvmfPkg/SmmAccess/SmmAccessPei.inf
 ################################################################################

 

 [FV.DXEFV]

+FvNameGuid         = 7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1

 BlockSize          = 0x10000

 FvAlignment        = 16

 ERASE_POLARITY     = 1

@@ -379,6 +382,7 @@ INF  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
 ################################################################################

 

 [FV.FVMAIN_COMPACT]

+FvNameGuid         = 48DB5E17-707C-472D-91CD-1613E7EF51B0

 FvAlignment        = 16

 ERASE_POLARITY     = 1

 MEMORY_MAPPED      = TRUE