Documentation/Intel: Add MultiProcessorInit documentation

Add documentation for MP service PPI using EFI interface
on Intel 9th Gen Platforms.

Documented so far:
* Problem Statement
* New Design Proposal
* API interface
* Code Flow changes
* Benefits

BRANCH=none
BUG=b:74436746
TEST=none

Change-Id: I5b6096ef31d8a523c00cbad39ab9d4884e735fde
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/25921
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit is contained in:
Subrata Banik 2018-04-30 09:14:32 +05:30 committed by Martin Roth
parent c80435d340
commit 55b183f112
2 changed files with 74 additions and 0 deletions

View File

@ -0,0 +1,74 @@
# Intel Common Code Block Publishing EFI_MP_SERVICES_PPI
## Introduction
This documentation is intended to document the purpose for creating EFI service
Interface inside coreboot space to perform CPU feature programming on Application
Processors for Intel 9th Gen (Cannon Lake) and beyond CPUs.
Today coreboot is capable enough to handle multi-processor initialization on IA platforms.
The multi-processor initialization code has to take care of lots of duties:
1 Bringing all cores out of reset
2 Load latest microcode on all cores
3 Sync latest MTRR snapshot between BSP and APs
4 Perform sets of CPU feature programming
* CPU Power & Thermal Management
* Overclocking
* Intel Trusted Execution Technology
* Intel Software Guard Extensions
* Intel Processor Trace etc.
This above CPU feature programming lists are expected to grow with current and future
CPU complexity and there might be some cases where certain feature programming mightbe
closed source in nature.
Platform code might need to compromise on those closed source nature of CPU programming
if we don't plan to provide an alternate interface which can be used by coreboot to
get-rid of such close source CPU programming.
## Proposal
As coreboot is doing CPU multi-processor initialization for IA platform before FSP-S
initialization and having all possible information about cores in terms of maximum number
of cores, APIC ids, stack size etc. Its also possible for coreboot to extend its own
support model and create a sets of APIs which later can be used by FSP to run CPU feature
programming using coreboot published APIs.
Due to the fact that FSP is using EFI infrastructure and need to relying on install/locate
PPI to perform certain API call, hence coreboot has to created MP services APIs known as
EFI_MP_SERVICES_PPI as per PI specification volume 1, section 8.3.9.
More details here: http://www.uefi.org/sites/default/files/resources/PI_Spec_1_6.pdf
### coreboot to publish EFI_MP_SERVICES_PPI APIs
| API | Description |
|------------------------------|------------------------------------------------------------------|
| PeiGetNumberOfProcessors | Get the number of CPU's. |
| PeiGetProcessorInfo | Get information on a specific CPU. |
| PeiStartupAllAPs | Activate all of the application processors. |
| PeiStartupThisAP | Activate a specific application processor. |
| PeiSwitchBSP | Switch the boot strap processor. |
| PeiEnableDisableAP | Enable or disable an application processor. |
| PeiWhoAmI | Identify the currently executing processor. |
|------------------------------|------------------------------------------------------------------|
## Code Flow
Here is proposed design flow with coreboot has implemented EFI_MP_SERVICES_PPI API and FSP will make
use of the same to perform some CPU feature programming.
** coreboot-FSP MP init flow **
![alt text][coreboot_publish_mp_service_api]
[coreboot_publish_mp_service_api]: coreboot_publish_mp_service_api.png "coreboot-fsp mp init flow"
## Benefits
1. coreboot was using SkipMpInit=1 which will skip entire FSP CPU feature programming.
With proposed model, coreboot will make use of SkipMpInit=0 which will allow to run all
Silicon recommended CPU programming.
2. CPU feature programming inside FSP will be more transparent than before as its using
coreboot interfaces to execute those programming.
3. coreboot will have more control over running those feature programming as API optimization
handled by coreboot.

Binary file not shown.

After

Width:  |  Height:  |  Size: 120 KiB