Local test #7
Closed
Local test #7
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Create Acpi66.h, which is copied from Acpi65.h, and make the following changes: 1. Replace all occurences of "6.5/6_5" with "6.6/6_6". 2. Add "ResetVector" in Multiprocessor Wakeup Structure. 3. Add "Test" command for Multiprocessor Wakeup Mailbox. 4. Make Acpi66.h the latest ACPI definitions that Acpi.h contains. Cc: Michael D Kinney <[email protected]> Cc: Liming Gao <[email protected]> Signed-off-by: Ceping Sun <[email protected]>
Add the GDT table to swicth paging mode when the OS jumps to the ResetVector in Mailbox. Signed-off-by: Ceping Sun <[email protected]> Reviewed-by: Min Xu <[email protected]> Tested-by: Kirill A. Shutemov <[email protected]>
Base on ACPI 6.6 MultiProcessor Wakeup Mailbox Structure, the new "Test" command is added. Also the "Sleep" command is not defined in ACPI MultiProcessor Wakeup MailBox commands, it should be removed. Cc: Gerd Hoffmann <[email protected]> Cc: Min Xu <[email protected]> Cc: Jiewen Yao <[email protected]> Cc: Kirill A. Shutemov <[email protected]> Signed-off-by: Ceping Sun <[email protected]>
Base on ACPI 6.6 Multiprocessor Wakeup Structure, it needs to provide the ResetVector address to OS, The ResetVector can make the AP to enter a state to check the mailbox. Signed-off-by: Ceping Sun <[email protected]> Reviewed-by: Min Xu <[email protected]> Tested-by: Kirill A. Shutemov <[email protected]>
Since OVMF already supports 5-level paging, the ResetVector needs to handle the case. Cc: Gerd Hoffmann <[email protected]> Cc: Min Xu <[email protected]> Cc: Jiewen Yao <[email protected]> Cc: Kirill A. Shutemov <[email protected]> Signed-off-by: Ceping Sun <[email protected]>
This reverts commit efaa102.
sunceping
pushed a commit
that referenced
this pull request
Jul 1, 2025
…eEntry 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 <[email protected]>
mergify bot
pushed a commit
that referenced
this pull request
Jul 2, 2025
…eEntry 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 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
<Include a description of the change and why this change was made.>
<For each item, place an "x" in between
[and]if true. Example:[x](you can also check items in GitHub UI)><Create the PR as a Draft PR if it is only created to run CI checks.>
<Delete lines in <> tags before creating the PR.>
How This Was Tested
<Describe the test(s) that were run to verify the changes.>
Integration Instructions
<Describe how these changes should be integrated. Use N/A if nothing is required.>