The UEFI Forum released the latest and greatest version of the beloved Platform Initialization (PI) Specification, v1.8.  It is notable that this is the first version of the PI spec to be produced using's new document build system.  The new build system uses a combination of the reStructuredText and Sphinx technologies, and replaces older proprietary tools like Adobe FrameMaker.  The UEFI Spec v2.10 was recently updated with this same new document build system, and you can expect all future specifications to carry on with the new technology.  So, if you notice a new "look and feel" to PI v1.8, that's why.

Furthermore, a simple, but much welcomed change, is that the five different volumes that comprise the PI spec are now explicitly called out before each section number.  Previously, putting all five volumes in one .PDF meant that each volume's sections were numbered consecutively, like 1,2,3,4,5... 1,2,3,4,5... 1,2,3,4,5..., such that it was tricky to know where one volume stopped and the next began.  Now, Roman numerals are used to represent the volume numbers, and are prepended before each section:

PI v1.8 contains eight changes, summarized below.  I hope you find the summary useful!

2103 Adding EFI_DELAYED_DISPATCH_FUNCTION definition and explanation

PEI Delayed Dispatch was a new feature introduced in PI v1.7.  This change adds some missing definition and explanation to this feature.

2119 HOB Update for Memory Ranges Capable of Being Protected by CPU Cryptographic Capabilities

UEFI Spec v2.7 introduced a new memory attribute EFI_MEMORY_CPU_CRYPTO to the system memory map to designate memory ranges capable of being encrypted by the CPU.  Heretofore, there was no way for PEI to notify DXE that a particular memory range was capable of encryption.  This change fixes that by adding a new attribute, EFI_RESOURCE_ATTRIBUTE_ENCRYPTED, which can be passed to DXE via a HOB.

2147 EFI_RESOURCE_ATTRIBUTE_SP not defined in Resource Descriptor HOB

Similar in spirit to #2119 (above).  UEFI v2.7 introduced a memory attribute EFI_MEMORY_SP to the system memory map.  The "SP" here means "Special Purpose", and is meant to signify a memory range earmarked for specific purposes such as for specific device drivers or applications.  Until now, there was no way for PEI to pass on to DXE this attribute.  Now, PI has the corresponding memory attribute EFI_RESOURCE_ATTRIBUTE_SPECIAL_PURPOSE for this need.

2160 MP Services 2 PPI

PEI_MP_SERVICES_PPI has existed since PI v1.4.  This change adds a new function to the protocol named StartupAllCPUs(), and increments the protocol version number to 2, i.e., PEI_MP_SERVICES2_PPI.  The StartupAllCPUs() function executes a caller-provided function on all enabled CPUs.

2161 Introduce unaccepted memory type

This change, and its associated change to UEFI, introduce the concept of "unaccepted memory".  Server-class CPUs from AMD (AMD SEV-SNP) and Intel (Intel TDX) use this concept as a way for a guest virtual machine to accept or reject being allocated to certain memory ranges on the host.

2340 Introduction of EFI_SW_EC_FRAGMENTED_MEMORY_MAP Status Code

This change introduced a new error code to PiStatusCode.h in order to catch instances of instances of inconsistent memory maps between S4/resume cycles.  The new code to represent such cases is EFI_SW_EC_FRAGMENTED_MEMORY_MAP.

2341 Introduction of EFI_PERIPHERAL_TPM Peripheral Subclass Definition

This change adds a new status code subclass for TPMs.  The new subclass allows grouping errors related to TPMs for easier troubleshooting and to avoid TPM status codes conflicting with codes from other peripheral subsystems.

2351 update PI spec revision

This is simply a note that the version number of the spec text is updated.  You can safely ignore this.

Post a Comment

Be sure to select an account profile (e.g. Google, OpenID, etc.) before typing your comment!