UefiCpuPkg/PiSmmCpuDxeSmm: Add sync barrier before BSP invokes SmmCoreEntry

This patch introduces a synchronization point between the BSP and APs to
ensure all APs have entered their SMM wait-loop (while (TRUE) in APHandler
()) before the BSP calls into the SMI handler logic via gSmmCpuPrivate
->SmmCoreEntry().

Previously, the BSP would invoke ReleaseAllAPs() and immediately proceed
to SmmCoreEntry() without confirming whether APs had reached the stable
waiting state. If SmmStartupThisAp() was called inside the SMI handler
shortly after ReleaseAllAPs(), it might lead to a race condition:
APs are issued two consecutive wait signals (SmmCpuSyncWaitForBsp()).
BSP sends two consecutive releases (ReleaseAllAPs() + SmmStartupThisAp())
If an AP has not yet responded to the first release, the second release may
overwrite the semaphore state, and the AP might miss the notification,
causing it to hang or behave unpredictably.

To address this:
A SmmCpuSyncWaitForAPs() is added in BSP after
mmCpuPlatformHookBeforeMmiHandler() and before entering SmmCoreEntry().
A matching SmmCpuSyncReleaseBsp() is added in AP immediately after its own
SmmCpuPlatformHookBeforeMmiHandler()

This ensures that BSP does not enter SMI handler logic or dispatch any
AP-related requests before all APs are confirmed to be idle and ready.
Debug sync point markers (e.g., /// #6, #7) are updated accordingly.
This change eliminates a subtle but critical race condition in
multi-processor/multi-socket systems during SMM entry and improves overall
synchronization safety.

Signed-off-by: Wei6 Xu <wei6.xu@intel.com>

0 files changed, 0 insertions, 0 deletions