UefiCpuPkg/PiSmmCpuDxeSmm: Consume SMM Base Hob for SmBase info

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>

1 files changed, 24 insertions, 1 deletions

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
index a0967eb69c..baf827cf9d 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
@@ -1,7 +1,7 @@
 /** @file

 SMM MP service implementation

 

-Copyright (c) 2009 - 2022, Intel Corporation. All rights reserved.<BR>

+Copyright (c) 2009 - 2023, Intel Corporation. All rights reserved.<BR>

 Copyright (c) 2017, AMD Incorporated. All rights reserved.<BR>

 

 SPDX-License-Identifier: BSD-2-Clause-Patent

@@ -1723,6 +1723,10 @@ SmiRendezvous (
 

   ASSERT (CpuIndex < mMaxNumberOfCpus);

 

+  if (mSmmRelocated) {

+    ASSERT (mSmmInitialized != NULL);

+  }

+

   //

   // Save Cr2 because Page Fault exception in SMM may override its value,

   // when using on-demand paging for above 4G memory.

@@ -1730,6 +1734,25 @@ SmiRendezvous (
   Cr2 = 0;

   SaveCr2 (&Cr2);

 

+  if (mSmmRelocated && !mSmmInitialized[CpuIndex]) {

+    //

+    // Perform SmmInitHandler for CpuIndex

+    //

+    SmmInitHandler ();

+

+    //

+    // Restore Cr2

+    //

+    RestoreCr2 (Cr2);

+

+    //

+    // Mark the first SMI init for CpuIndex has been done so as to avoid the reentry.

+    //

+    mSmmInitialized[CpuIndex] = TRUE;

+

+    return;

+  }

+

   //

   // Call the user register Startup function first.

   //