Multi-Socket ARM Servers and UEFI Runtime Services

This article examines how server-grade ARM platforms execute UEFI runtime services across multi-socket, Non-Uniform Memory Access (NUMA) topologies. Implementing unified firmware services on multi-socket ARM systems requires complex coordination between ARM's Exception Level architecture, hardware-enforced cache coherency protocols, and runtime memory mapping. The following sections break down the underlying hardware fabrics, memory management workflows, cross-socket synchronization, and the delegation of critical runtime tasks to secure firmware environments.

Cache-Coherent Interconnects and Topology Discovery

At the hardware layer, multi-socket ARM platforms—such as those built on ARM Neoverse N-series or V-series cores—rely on coherent mesh networks and chip-to-chip links (e.g., CCIX, CXL, or vendor-specific inter-socket fabrics). Before UEFI runtime services can function across sockets, the boot firmware must initialize these interconnects during the Pre-EFI Initialization (PEI) and Driver Execution Environment (DXE) phases.

The hardware fabric enforces hardware-managed cache coherency across physical socket boundaries using directory-based snooping protocols. When the primary socket's core executes a UEFI runtime service, any shared data structure residing in memory attached to a secondary socket is transparently cached and synchronized by the interconnect. System hardware presents this physical memory map as a coherent NUMA space, managed downstream by the ARM Generic Interrupt Controller (GICv3/GICv4) to route inter-processor interrupts (IPIs) across socket domains.

Memory Allocation and SetVirtualAddressMap

UEFI defines two distinct execution stages for memory: physical mode prior to OS handover, and virtual mode after the operating system boots. Because UEFI runtime services persist alongside the operating system, they must transition into the OS's virtual address space.

  1. Memory Reservation: During early boot, the DXE foundation allocates memory regions tagged specifically as EfiRuntimeServicesCode and EfiRuntimeServicesData. On multi-socket systems, firmware implementations typically allocate these regions from the boot socket's local memory to minimize early memory-controller dependencies, though the pages remain globally accessible across all sockets via the coherent fabric.
  2. Virtual Mapping Transition: When the operating system initializes, it calls the SetVirtualAddressMap() runtime service. The OS provides a descriptor array mapping UEFI's physical runtime pages into the operating system’s high-memory virtual address space.
  3. Descriptor Fixups: The UEFI runtime drivers update their internal pointers to reflect these new virtual addresses. On ARM platforms compliant with the Server Base Boot Requirements (SBBR) and Server Base System Architecture (SBSA), this virtual mapping must be homogeneous across all online cores and sockets. Every core on Socket 0 and Socket 1 shares the identical page-table translations for UEFI runtime services.

Concurrency and Cross-Socket Synchronization

Standard UEFI runtime services are strictly non-reentrant. Functions such as GetVariable, SetVariable, GetTime, and ResetSystem cannot be executed concurrently by multiple processing cores.

In a system spanning multiple sockets and hundreds of physical threads, firmware mitigates concurrency issues through explicit software locking:

  • Spinlocks and Barriers: Runtime drivers utilize architectural ARM spinlocks based on Load-Exclusive/Store-Exclusive primitives (LDREX/STREX in ARMv8-A or Load-Acquire/Store-Release instructions in ARMv8.1+). These operations trigger coherency updates across the inter-socket fabric to ensure atomic variable access.
  • Operating System Responsibility: The UEFI specification mandates that the calling operating system must serialize calls to runtime services. If a kernel thread on Socket 1 executes SetVariable, the OS kernel must prevent another thread on Socket 0 from entering a runtime service until the first invocation completes.

Firmware Partitioning and Secure Execution (EL3 / Standalone MM)

In modern server-grade ARM implementations, standard UEFI runtime drivers running in Non-Secure EL1 or EL2 do not directly manipulate critical platform components. Instead, they act as thin dispatchers that delegate requests to higher privilege levels:

Power Management via PSCI (EL3)

Services like ResetSystem() delegate system resets, core power-downs, and socket-level power transitions to the Power State Coordination Interface (PSCI). PSCI runs within Secure EL3 under ARM Trusted Firmware (TF-A). When a reset call is triggered, the core executes a Secure Monitor Call (SMC), elevating execution to EL3, where the firmware coordinates with platform power-management integrated circuits (PMICs) and intra-socket logic to reboot the entire topology coherently.

Non-Volatile Variables via Standalone MM (Secure EL0/EL1)

Modifications to UEFI variables via SetVariable must be persistently stored in SPI-NOR flash or dedicated non-volatile storage, which usually resides on a specific socket's bus. Rather than allowing raw access from the non-secure operating system, platforms utilize ARM Standalone Management Mode (Standalone MM):

  • The OS invokes the UEFI runtime service at Non-Secure EL1.
  • The runtime driver triggers an SMC, transitioning the CPU to EL3.
  • EL3 dispatches the payload to Secure Partition Manager (SPM), routing execution to a Standalone MM instance operating in Secure EL0 or Secure EL1.
  • If the SPI controller resides physically on Socket 0, but the runtime call originated on Socket 1, the hardware fabric bridges the memory and I/O accesses, or the secure firmware issues an authenticated Inter-Processor Interrupt to dispatch the operation directly on the target socket.

Through the combination of hardware-enforced cache coherency across interconnects, unified virtual memory mapping during OS handoff, and secure isolation via ARM's Exception Levels, multi-socket ARM chips provide stable and standard-compliant UEFI runtime interfaces regardless of system scale.