]> git.proxmox.com Git - mirror_edk2.git/commit
OvmfPkg: add a Name GUID to each Firmware Volume
authorLaszlo Ersek <lersek@redhat.com>
Tue, 12 Jul 2016 14:48:47 +0000 (16:48 +0200)
committerLaszlo Ersek <lersek@redhat.com>
Tue, 12 Jul 2016 23:03:57 +0000 (01:03 +0200)
commit16f26de663967b5a64140b6abba2c145ea50194c
tree4d3222a41acd640fe889ea0490329aa76c605b7c
parenta78b518b6eddef545fa440822bec315b31e4e987
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>
OvmfPkg/OvmfPkgIa32.fdf
OvmfPkg/OvmfPkgIa32X64.fdf
OvmfPkg/OvmfPkgX64.fdf