According to the Unified Extensible Firmware Interface specification, the software environment that provides initialization procedures before the operating system loads does not support multi-thread processing. The main reason is the single-stream UEFI ideology and, as a result, the non-reentrantness of the UEFI API service procedures. At the same time, a number of tasks not related to calling service functions (for example, testing RAM) not only allow parallel execution by several program threads, but also receive an increase in performance from such a hike.
Note : A few years ago, experiments on initializing a multiprocessor platform in a 16-bit MS-DOS environment were conducted in our laboratory, using direct programming of hardware resources, in particular, Local APIC interrupt controllers. A successful technical experience, however, turned out to be somewhat similar to a joke about a trainer who taught the dog to play the violin, and the audience, as it turned out, does not go to the circus to listen to the violin concerto ...
The presence in UEFI firmware of a documented set of service functions called
EFI_MP_SERVICES_PROTOCOL suggests that the fate of multi-threaded processing under UEFI will be somewhat different. Let us consider in more detail one of the functions of this protocol.
Running AP: how to do it
Consider a set of parameters and principles of using one of the main functions of
StartupThisAP , which provides for launching an AP (Application Processors) multiprocessor system and coordinating their work by the BSP (Bootstrap Processor).
')
Description of the StartupThisAP function in the UEFI Platform Initialization Specification document. Volume 2. Driver Execution Environment Core Interface. Version 1.3.The function allows you to run an arbitrary procedure on a given logical processor of the multiprocessor platform. The object of control is
logical processors , for example, in a system with two 8-core processors that support
Hyper-Threading technology , the number of logical processors will be 2 * 8 * 2 = 32. To request the number of processors, use the
GetNumberOfProcessors function, an example of which is described in the description
SMP Detect utilities .
So, the StartupThisAP function takes 7 parameters.
- EFI_MP_SERVICES_PROTOCOL - pointer to the interface unit of the called protocol, returned by the EFI_Locate_Protocol function.
- EFI_AP_PROCEDURE is a pointer to the procedure that the AP processor must perform. The procedure must be previously prepared in memory in accordance with the rules for the current mode of operation of the processor, for example, Microsoft x64 calling convention is used for UEFI x64.
- ProcessorNumber is the number of the processor to start, counting from 0.
- WaitEvent - the number (handle) of the event reserved by the calling procedure. The called procedure generates this event to report the success of the routine on the AP processor or the expiration of the timeout. A special case - the zero value of this parameter means that the BSP processor running the procedure on the AP processor must wait for the procedure to complete before returning from the function. No events are generated. This mode is called Blocking Mode.
- TimeoutInMicroseconds - timeout value in microseconds, which determines the waiting time for completion of the procedure running on the AP processor. When the timeout expires, the procedure is forced to end with error generation. The zero value of this parameter means the absence of restrictions on the execution time of the procedure (endless waiting).
- ProcedureArgument is a parameter passed to a procedure launched on the AP processor. A value of zero means no parameter passing.
- Finished - a pointer to the variable set by the UEFI firmware to TRUE if the procedure started on the AP was successfully completed before the timeout expired. Zero value means not to use such a variable.
After execution, the function returns the UEFI status in the RAX register.
Summary
It can be stated that, compared to the Legacy BIOS, the UEFI firmware greatly simplifies the task of the system programmer when initializing a multiprocessor platform. The transfer of interprocessor interrupts, known as IPI or Inter Processor Interrupts, as well as the transfer of the AP processor to a UEFI context compatible mode, can be accomplished not using direct hardware programming, but using service functions. An exception may be tasks whereby multiprocessor support platform resources are an independent object of research or diagnostics.
application
UPD. The picture was replaced: initially by mistake was the structure of the interface block EFI_MP_SERVICES_PROTOCOL