Advanced Configuration and Power Interface Specification

Advanced Configuration and Power Interface Specification
18.4.1 Example: Firmware First Handling Using NMI Notification
If the platform chooses to use NMI to report errors, which is the recommended method for uncorrected errors, the
platform follows these steps:
1. System firmware configures the platform to trigger a firmware handler when the error occurs
2. System firmware identifies the error source for which it will handle errors via the error source
enumeration interface by setting the FIRMWARE_FIRST flag
3. System firmware describes the generic error source, and the associated error status block, as
described in Section 18.3.2.6. System firmware identifies the relation between the generic error
source and the original error source by using the original source ID in the related source ID of
Table 18-329.
4. When a hardware error reported by the error source occurs, system firmware gains control and
handles the error condition as required. Upon completion system firmware should do the
following:
a Extract the error information from the error source and fill in the error information in the
data block of the generic error source it identified as an alternate in step 3. The error
information format follows the specification in Section 18.3.2.6.1
b
c
d
Set the appropriate bit in the block status field (Table 18-330) to indicate to the OSPM that a
valid error condition is present.
Clears error state from the hardware.
Generates an NMI.
At this point, the OSPM NMI handler scans the list of generic error sources to find the error source
that reported the error and processes the error report
18.5 Error Serialization
• The error record serialization feature is used to save and retrieve hardware error information to
and from a persistent store. OSPM interacts with the platform through a platform interface. On
UEFI-based platforms, the UEFI runtime variable services can be used to carry out error record
persistence operations. On non-UEFI based platforms, the ACPI solution described below is
used.
• For error persistence across boots, the platform must implement some form of non-volatile store
to save error records. The amount of space required depends on the platform’s processor
architecture. Typically, this store will be flash memory or some other form of non-volatile
RAM.
• Serialized errors are encoded according to the Common Platform Error Record (CPER) format,
which is described in appendix N of the UEFI 2.1 specification. These entries are referred to as
error records.
• The Error Record Serialization Interface is designed to be sufficiently abstract to allow hardware
vendors flexibility in how they implement their error record serialization hardware. The
platform provides details necessary to communicate with its serialization hardware by
populating the ERST with a set of Serialization Instruction Entries. One or more serialization
instruction entries comprise a Serialization Action. OSPM carries out serialization operations by
730 April, 2015 Version 6.0