UEFI Multi-Core Initialization in Early Boot Phases

Unified Extensible Firmware Interface (UEFI) manages multi-core and multi-threaded initialization through a strict division of labor between a single primary core and the remaining secondary cores across standardized boot phases. During the initial reset, the platform designates one core as the Bootstrap Processor (BSP) to execute firmware sequentially, while all other cores—termed Application Processors (APs)—are held in a dormant state. As boot progresses, UEFI utilizes low-level interrupt signaling and the EFI MP Services Protocol to bring up secondary cores, synchronize processor states, run tasks in parallel, and safely park them before handing control to the operating system.

Hardware Reset and the Bootstrap Processor

When a multi-core system powers on, the processor hardware automatically conducts an election to establish the Bootstrap Processor (BSP). On x86 architectures, this is handled via hardware arbitration through the Local Advanced Programmable Interrupt Controller (LAPIC).

The selected BSP begins fetching and executing firmware instructions from the reset vector. All remaining cores are designated as Application Processors (APs). By default, the hardware places APs into a wait-for-SIPI (Startup Inter-Processor Interrupt) state, halting their execution to prevent race conditions while system memory and core firmware components are unconfigured.

The SEC (Security) Phase

The SEC phase is the first phase of UEFI execution and runs exclusively on the BSP. Because physical system RAM is not yet available, the BSP sets up Cache-as-RAM (CAR) to establish a temporary stack for execution.

During this phase, APs remain entirely dormant in their hardware-halted state. Restricting execution to the BSP ensures that CAR boundaries are not violated and avoids the complexity of multi-threaded cache manipulation before memory coherency is formally established.

The PEI (Pre-EFI Initialization) Phase

The primary role of the PEI phase is to discover and initialize main memory (DRAM). Execution remains predominantly single-threaded on the BSP.

In modern platforms, early multi-processor awareness can occur toward the end of the PEI phase via an MP Pre-EFI Initialization Module (PEIM). If platform initialization requires early multi-core involvement—such as reading CPU topology, gathering Built-In Self-Test (BIST) results, or accelerating memory training—the MP PEIM uses basic interrupt signaling to wake the APs. However, persistent multi-threading remains limited until permanent DRAM is functional and the permanent memory map is installed.

The DXE (Driver Execution Environment) Phase

Comprehensive multi-core and multi-threading management is established during the DXE phase through the EFI_MP_SERVICES_PROTOCOL. The DXE Foundation loads an architecture-specific MP CPU driver to manage the APs systematically:

  1. Waking the APs (INIT-SIPI-SIPI Sequence): The BSP's MP driver allocates a memory buffer below the 1 MB boundary (the real-mode addressable space) containing an assembly trampoline. The BSP issues an INIT-SIPI-SIPI interrupt sequence through its LAPIC to the APs, pointing them to this trampoline.
  2. Mode Transition: The APs wake up in 16-bit real mode, execute the trampoline code, switch to protected mode, enable paging, and transition to 64-bit long mode.
  3. Establishing the Rendezvous Point: Each AP is assigned its own unique execution stack and enters a controlled, synchronized loop (rendezvous) managed by the firmware. Here, APs execute low-power PAUSE or HLT instructions, continuously checking for tasks assigned by the BSP.

Multi-Threading Model and Task Dispatch

UEFI does not implement a preemptive, time-sliced scheduler for multi-threading. Instead, it relies on a cooperative master-worker dispatch model exposed by the EFI_MP_SERVICES_PROTOCOL.

The BSP can direct tasks to APs using two primary services:

  • StartupAllAPs: Directs all active secondary cores to execute a specified procedure concurrently.
  • StartupThisAP: Directs a specific, individual AP to execute a target procedure.

These dispatches can be blocking (where the BSP halts execution until the APs complete the work) or non-blocking (where the BSP continues other tasks while monitoring an event signal for completion). Firmware components utilize this mechanism for high-latency parallel operations, such as:

  • Applying microcode updates across all logical cores simultaneously.
  • Programming Model-Specific Registers (MSRs) that require identical configuration across all processors.
  • Collecting thermal and power state data.
  • Initializing core-specific virtualization or platform security features.

OS Handoff and ExitBootServices

Before UEFI relinquishes control to the operating system bootloader, the system must transition out of its firmware multi-processing environment. When the operating system invokes EFI_BOOT_SERVICES.ExitBootServices(), the MP driver shuts down firmware-level dispatching.

The APs are safely returned to a quiescent state—typically placed back into a wait-for-SIPI loop or parked using an ACPI-specified parking protocol or MWAIT loop. This leaves the secondary cores completely isolated and ready for the operating system kernel to initialize them according to its own native scheduling and multi-processing model.