mirror of https://github.com/acidanthera/audk.git
ec07fd0e35
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4337 Existing SMBASE Relocation is in the PiSmmCpuDxeSmm driver, which will relocate the SMBASE of each processor by setting the SMBASE field in the saved state map (at offset 7EF8h) to a new value. The RSM instruction reloads the internal SMBASE register with the value in SMBASE field when each time it exits SMM. All subsequent SMI requests will use the new SMBASE to find the starting address for the SMI handler (at SMBASE + 8000h). Due to the default SMBASE for all x86 processors is 0x30000, the APs' 1st SMI for rebase has to be executed one by one to avoid the processors over-writing each other's SMM Save State Area (see existing SmmRelocateBases() function), which means the next AP has to wait for the previous AP to finish its 1st SMI, then it can call into its 1st SMI for rebase via Smi Ipi command, thus leading the existing SMBASE Relocation has to be running in series. Besides, it needs very complex code to handle the AP exit semaphore (mRebased[Index]), which will hook return address of SMM Save State so that semaphore code can be executed immediately after AP exits SMM for SMBASE relocation (see existing SemaphoreHook() function). With SMM Base Hob support, PiSmmCpuDxeSmm does not need the RSM instruction to do the SMBASE Relocation. SMBASE Register for each processors have already been programmed and all SMBASE address have recorded in SMM Base Hob. So the same default SMBASE Address (0x30000) will not be used, thus the processors over-writing each other's SMM Save State Area will not happen in PiSmmCpuDxeSmm driver. This way makes the first SMI init can be executed in parallel and save boot time on multi-core system. Besides, Semaphore Hook code logic is also not required, which will greatly simplify the SMBASE Relocation flow. Mainly changes as below: * Assume the biggest possibility of tile size is 8k. * Combine 2 SMIs (gcSmmInitTemplate & gcSmiHandlerTemplate) into one (gcSmiHandlerTemplate), the new SMI handler needs to run to 2 paths: one to SmmCpuFeaturesInitializeProcessor(), the other to SMM Core Entry Point. * Issue SMI IPI (All Excluding Self SMM IPI + BSP SMM IPI) for first SMI init before normal SMI sources happen. * Call SmmCpuFeaturesInitializeProcessor() in parallel. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zeng Star <star.zeng@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> |
||
---|---|---|
.. | ||
Ia32 | ||
X64 | ||
CpuS3.c | ||
CpuService.c | ||
CpuService.h | ||
MpService.c | ||
PiSmmCpuDxeSmm.c | ||
PiSmmCpuDxeSmm.h | ||
PiSmmCpuDxeSmm.inf | ||
PiSmmCpuDxeSmm.uni | ||
PiSmmCpuDxeSmmExtra.uni | ||
SmmCpuMemoryManagement.c | ||
SmmMp.c | ||
SmmMp.h | ||
SmmProfile.c | ||
SmmProfile.h | ||
SmmProfileInternal.h | ||
SmramSaveState.c | ||
SyncTimer.c |