Add missing GDT alignment into mBuffer to prevent possible memory
corruption on ALIGN_POINTER operation on NewGdtTable
in ArchExceptionHandler
Signed-off-by: Savva Mitrofanov <savvamtr@gmail.com>
Root cause:
1. Before DisableReadonlyPageWriteProtect() is called, the return
address (#1) is pushed in shadow stack.
2. CET is disabled.
3. DisableReadonlyPageWriteProtect() returns to #1.
4. Page table is modified.
5. EnableReadonlyPageWriteProtect() is called, but the return
address (#2) is not pushed in shadow stack.
6. CET is enabled.
7. EnableReadonlyPageWriteProtect() returns to #2.
#CP exception happens because the actual return address (#2)
doesn't match the return address stored in shadow stack (#1).
Analysis:
Shadow stack will stop update after CET disable (DisableCet() in
DisableReadOnlyPageWriteProtect), but normal smi stack will be
continue updated with the function called and return
(DisableReadOnlyPageWriteProtect & EnableReadOnlyPageWriteProtect),
thus leading stack mismatch after CET re-enabled (EnableCet() in
EnableReadOnlyPageWriteProtect).
According SDM Vol 3, 6.15-Control Protection Exception:
Normal smi stack and shadow stack must be matched when CET enable,
otherwise CP Exception will happen, which is caused by a near RET
instruction.
CET is disabled in DisableCet(), while can be enabled in
EnableCet(). This way won't cause the problem because they are
implemented in a way that return address of DisableCet() is
poped out from shadow stack (Incsspq performs a pop to increases
the shadow stack) and EnableCet() doesn't use "RET" but "JMP" to
return to caller. So calling EnableCet() and DisableCet() doesn't
have the same issue as calling DisableReadonlyPageWriteProtect()
and EnableReadonlyPageWriteProtect().
With above root cause & analysis, define below 2 macros instead of
functions for WP & CET operation:
WRITE_UNPROTECT_RO_PAGES (Wp, Cet)
WRITE_PROTECT_RO_PAGES (Wp, Cet)
Because DisableCet() & EnableCet() must be in the same function
to avoid shadow stack and normal SMI stack mismatch.
Note: WRITE_UNPROTECT_RO_PAGES () must be called pair with
WRITE_PROTECT_RO_PAGES () in same function.
Change-Id: I4e126697efcd8dbfb4887da034d8691bfca969e3
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zeng Star <star.zeng@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Aim:
- To solve the assertion that checks if CpuMpData->FinishedCount
equals (CpuMpData->CpuCount - 1). The assertion arises from a timing
discrepancy between the BSP's completion of startup signal checks and
the APs' incrementation of the FinishedCount.
- This patch also ensures that "finished" reporting from the APs is as
later as possible.
More specifially:
In the SwitchApContext() function, the BSP trigers
the startup signal and check whether the APs have received it. After
completing this check, the BSP then verifies if the FinishedCount is
equal to CpuCount-1.
On the AP side, upon receiving the startup signal, they invoke
SwitchContextPerAp() and increase the FinishedCount to indicate their
activation. However, even when all APs have received the startup signal,
they might not have finished incrementing the FinishedCount. This timing
gap results in the triggering of the assertion.
Solution:
Instead of assertion, use while loop to waits until all the APs have
incremented the FinishedCount.
Fixes: 964a4f032d
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <20231025114216.2824-1-yuanhao.xie@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Checking the max cpuid leaf is not enough to figure whenever
CPUID_V2_EXTENDED_TOPOLOGY is supported. Intel SDM says:
Software must detect the presence of CPUID leaf 1FH by verifying
(a) the highest leaf index supported by CPUID is >= 1FH, and
(b) CPUID.1FH:EBX[15:0] reports a non-zero value.
The same is true for CPUID leaf 0BH.
This patch adds the EBX check to GetProcessorLocation2ByApicId(). The
patch also fixes the existing check in GetProcessorLocationByApicId() to
be in line with the spec by looking at bits 15:0. The comments are
updated with a quote from the Intel SDM.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2241388
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-Id: <20231017112807.1244254-1-kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Introduce a PCD to control the maximum SATP mode that MMU allowed
to use. This PCD helps RISC-V platform set bare or minimum SATP mode
during bring up to debug memory map issue.
Signed-off-by: Tuan Phan <tphan@ventanamicro.com>
Reviewed-by: Dhaval Sharma <dhaval@rivosinc.com>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
This change does not introduce any functional modifications.
Remove the unused mValidMtrrAddressMask and mValidMtrrBitsMask.
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ray Ni <ray.ni@intel.com>
Old implementation of RefreshMemoryAttributesFromMtrr directly
retrieves the MTRR register content and applies the MTRR cache type
to GCD database following the precedence order defined by SDM.
The code can updated to simply get all the memory cache types for all
memory through newly introduced API With the new introduced API
MtrrGetMemoryAttributesInMtrrSettings.
Benefits:
1. Remove the duplicated logic in CpuDxe driver that handles MTRR
details.
2. Let the MtrrLib to handle the case when fixed MTRR is absent.
(Old logic cannot handle the case.)
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
attributes
Add Unit test of trrGetMemoryAttributesInMtrrSettings and
MtrrSetMemoryAttributesInMtrrSettings.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Improve MtrrDebugPrintAllMtrrsWorker by making use of
MtrrGetMemoryAttributesInMtrrSettings.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
MtrrGetMemoryAttributesInMtrrSettings parses the MTRR settings
either from hardware or from the parameter and returns an
array containing the memory cache types of all memory addresses.
This API could elinimate the needs of following APIs:
1. MtrrGetMemoryAttributeInVariableMtr
2. MtrrGetFixedMtrr
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Update APIs related to set memory attributes to handle the fixed MTRR
is not always supported.
There are 3 APIs in MtrrLib that can set memory attributes:
1. MtrrSetMemoryAttributesInMtrrSettings
2. MtrrSetMemoryAttributeInMtrrSettings
3. MtrrSetMemoryAttribute
The general idea applied in MtrrSetMemoryAttributesInMtrrSettings is:
1. MtrrLibPreMtrrChange saves the old MTRR default type which
contains bit to enable fixed MTRR.
2. Main logic in MtrrSetMemoryAttributesInMtrrSettings applies
memory attribute settings for below 1MB to variable MTRRs
if fixed MTRR is not supported.
3. MtrrLibPostMtrrChange unconditionally sets E bit in MTRR default
type MSR but only set FE bit when fixed MTRRs are modified.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Update UnitTestMtrrSetAllMtrrs() for the case that fixed MtrrLib
is not always supported.
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Update MtrrSetAllMtrrs to not access fixed MTRRs if CPU doesn't
support them.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
UnitTestMtrrGetFixedMtrr updated for the case that fixed MtrrLib
is not always supported.
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
IsMtrrSupported() return true when either fixed mtrr supported or
variable mtrr suppored. In this case, rather than checking whether
MTRR is supported or not, we should specifically check for fixed MTRR
support.
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Update UnitTestMtrrGetAllMtrrs() for the case that fixed MtrrLib
is not always supported
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The patch fixes the following issues in the original implementation:
1. MtrrSetting contains random value if MTRR is not supported.
2. Unconditionally access fixed MTRR on CPU that may not support
fixed MTRR.
3. The maximum number of Variable MTRR entries are initialized, while
the portion exceeding the maximum number remains uninitialized.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Update UnitTestMtrrGetDefaultMemoryType for the case the when Fixed
MTRRs are not supported.
The original implementation returns FALSE when either fixed MTRR isn't
supported or the number of variable MTRRs is 0. The correct behavior
should return FALSE only when both fixed MTRR isn't supported and the
number of variable MTRRs is 0.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Update UnitTestGetFirmwareVariableMtrrCount for the case the when
Fixed MTRRs are not supported.
The original implementation returns FALSE when either fixed MTRR isn't
supported or the number of variable MTRRs is 0. The correct behavior
should return FALSE only when both fixed MTRR isn't supported and the
number of variable MTRRs is 0.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The previous implementation returns FALSE if either fixed MTRR is
unsupported or the number of variable MTRRs is 0. The correct behavior
is to return FALSE only when both fixed MTRR is unsupported and the
number of variable MTRRs is 0.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Add internal function MtrrLibIsMtrrSupported and
update IsMtrrSupported to call the new internal function.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4494
Current reset vector uses 0xffffffe0 as AP waking vector, and expects
GenFv generates code aligned on a 4k boundary which will jump to this
location. However, some issues are listed below
1. GenFV doesn't generate code as the comment expects, because GenFv
assumes no modifications are required to the VTF-0 'Volume Top File'.
2. Even if removing VFT0 signature and let GenFv to modify, Genfv is
hard-code using another flash address 0xffffffd0.
3. In the same patch series, AP waking vector code is removed from
GenFv, because no such usage anymore. The existing of first two issues
also approve the usage is not available for a long time.
Therefore, remove AP waking vector related code.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4494
There are two part of AP waking Vector logic in SecCore.
The first one working with GenFv to find a free 4K aligned space,
use the 4K aligned address as AP waking Vector and jump to 4G-30h,
and finally jump to ApStartup..
The second one hard code uses 4G-1000h as AP waking Vector and
jump to ApStartup.
Both usages are no longer used. Remove them.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Use MpService2Ppi to wakeup AP in s3 boot flow during initializing
CPU. If mSmmS3ResumeState->MpService2Ppi is not 0, then BSP will
use MpService2Ppi->StartupAllCPUs to do CPU initialization for both
BSP and AP instead of only sending InitSipiSipi for AP.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
This commit is code logic refinement for s3 boot flow
in CpuS3.c. It doesn't change any code functionality.
This commit implementes InitializeAp and InitializeBsp
as a single function since they are doing almost the
same thing. Then both BSP and AP will execute the same
function InitializeCpuProcedure to do CPU initialization.
This can make the code logic easier to understand.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Add assert for invalid excution mode combination of 64bit PEI +
32bit DXE.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Prepare MpService2Ppi in S3Resume when PEI and SMM env run
in the same execution mode. Then smm s3 code can use Mp
Service to wakeup AP instead of only sending InitSipiSipi.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4511
With 64 bit build we are seeing the CD in control register CR 0 set.
This causes the NEM to disabled for some specific bios profiles.
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Debkumar De <debkumar.de@intel.com>
Cc: Catharine West <catharine.west@intel.com>
Signed-off-by: Wu, Mingliang <mingliangx.wu@intel.com>
The implementation of this new behavior aligns with the guidelines
outlined in the Intel SDM.
Following a power-up or RESET of an MP system, system hardware
dynamically selects one of the processors on the system bus as the BSP.
The remaining processors are designated as APs. The APs complete a
minimal self-configuration, then wait for a startup signal (a SIPI
message) from the BSP processor.
Additionally, the MP protocol is executed only after
a power-up or RESET. If the MP protocol has completed and a
BSP is chosen, subsequent INITs (either to a specific processor or
system wide) do not cause the MP protocol to be repeated. Instead, each
logical processor examines its BSP flag (in the IA32_APIC_BASE MSR) to
determine whether it should execute the BIOS boot-strap code (if it is
the BSP) or enter a wait-for-SIPI state (if it is an AP).
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Add PcdFirstTimeWakeUpAPsBySipi to check if it is in the OVMF environment
and necessary to wake up APs by INIT-SIPI-SIPI.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Add new API SendStartupIpiAllExcludingSelf(), and modify
SendInitSipiSipiAllExcludingSelf() by let it call the new API.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The purpose is to fix an issue where an exception occurs at the start
of the DXE phase by applying the following patch series on INTEL-based
systems.
UefiCpuPkg: Refactor the logic for placing APs in HltLoop.
UefiCpuPkg: Refactor the logic for placing APs in Mwait/Runloop.
UefiCpuPkg: Create MpHandOff.
UefiCpuPkg: ApWakeupFunction directly use CpuMpData.
UefiCpuPkg: Eliminate the second INIT-SIPI-SIPI sequence.
This series of patches makes changes to the way the APs are
initialized and woken up. It removes the 2nd time INIT-SIPI-SIPI and
introduces a special startup signal to wake up APs. These patches also
create a new HOB identified by the mMpHandOffGuid, which stores only the
minimum information required from the PEI phase to the DXE phase.
As a result, the original HOB (mCpuInitMpLibHobGuid) is now used only
as a global variable in the PEI phase and is no longer necessary in the
DXE phase for INTEL-based systems. The AMD SEV-ES related code
still relies on the OldCpuMpData in the DXE phase.
This patch decouple the SEV-ES functionality of assigning CpuMpData to
OldCpuMpData->NewCpuMpData from the Intel logic.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
During CpuDxe initialization, MMU will be setup with the highest
mode that HW supports.
Signed-off-by: Tuan Phan <tphan@ventanamicro.com>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
When both the PEI and DXE phases operate in the same execution
mode(32-bit/64-bit), the BSP send a special start-up signal during
the DXE phase to awaken the Application APs.
To eliminate the need for the INIT-SIPI-SIPI sequence at the beginning
of the DXE phase, the BSP call the SwitchApContext function to trigger
the special start-up signal. By writing the specified
StartupSignalValue to the designated StartupSignalAddress, the BSP
wakes up the APs from mwait mode. Once the APs receive the
MP_HAND_OFF_SIGNAL value, they are awakened and proceed to execute the
SwitchContextPerAp procedure. They enter another while loop,
transitioning their context from the PEI phase to the DXE phase.
The original state transitions for an AP during the procedure are as
follows:
Idle ----> Ready ----> Busy ----> Idle
[BSP] [AP] [AP]
Instead of init-sipi-sipi sequence, we make use of a
start-up signal to awaken the APs and transfer their context from
PEI to DXE. Consequently, APs, rather than the BSP, to set their state
to CpuStateReady.
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
In the original design, once the APs finished executing their assembly
code and switched to executing C code, they would enter a continuous
loop within a function. In this function, they would collect CpuMpData
using the MP_CPU_EXCHANGE_INFO mechanism. However, in the updated
approach, CpuMpData can now be passed directly to the ApWakeUpFunction,
bypassing the need for MP_CPU_EXCHANGE_INFO. This modification is made
in preparation for eliminating the requirement of a second
INIT-SIPI-SIPI sequence in the DXE phase.
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Initially, the purpose of the Hob was twofold: it served as a way to
transfer information from PEI to DXE. However, during the DXE phase,
only a few fields from the CPU_MP_DATA which collected in PEI phase were
needed. A new Hob was specifically created to transfer information
to the DXE phase. This new Hob contained only the essential fields
required for reuse in DXE. For instance, instead of directly including
the BspNumber in MpHandOff, the DXE phase introduced the use of
GetBspNumber() to collect the BspNumber from ApicID and CpuCount.
The SaveCpuMpData() function was updated to construct the MP_HAND_OFF
Hob. Additionally, the function introduced the MP_HAND_OFF_SIGNAL,
which solely served the purpose of awakening the APs
and transitioning their context from PEI to DXE. The
WaitLoopExecutionMode field indicated whether the bit mode of PEI
matched that of DXE. Both of them were filled only if the ApLoopMode
was not ApInHltLoop. In the case of ApInHltLoop, it remained necessary
to wake up the APs using the init-sipi-sipi sequence. This improvement
still allow INIT-SIPI-SIPI even APs are wait in Run/Mwait loop mode.
The function GetMpHandOffHob() was added to facilitate access to the
collected MpHandOff in the DXE phase. The CpuMpData in the DXE phase
was updated by gathering information from MpHandOff. Since MpHandOff
replaced the usage of OldCpuMpData and contained essential information
from the PEI phase to the DXE phase. AmdSevUpdateCpuMpData was included
to maintain the original implementation of AmdSev, ensuring that
OldCpuMpData->NewCpuMpData pointed to CpuMpData.
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Refactor the logic for placing APs in
Mwait/Runloop into a separate function.
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Refactor the logic for placing APs in HltLoop into a separate function.
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Some features like RAS need to use processor extended information
under smm, So add code to support it
Signed-off-by: Hongbin1 Zhang <hongbin1.zhang@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Cc: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4182
Removes SmmCpuFeaturesReadSaveStateRegister and
SmmCpuFeaturesWirteSaveStateRegister function from
SmmCpuFeaturesLib library.
MmSaveStateLib library replaces the functionality of the above
functions.
Platform old/new need to use MmSaveStateLib library to read/write save
state registers.
Current implementation supports Intel and AMD.
Cc: Paul Grimes <paul.grimes@amd.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Abdul Lateef Attar <abdattar@amd.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4182
Implements MmSaveStateLib library interfaces
to read and write save state
registers for Intel processor family.
Moves Intel and AMD common functionality to common area.
Cc: Paul Grimes <paul.grimes@amd.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Abdul Lateef Attar <abdattar@amd.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4182
Implements interfaces to read and write save state
registers of AMD's processor family.
Initializes processor SMMADDR and MASK depends
on PcdSmrrEnable flag.
Program or corrects the IP once control returns from SMM.
Cc: Paul Grimes <paul.grimes@amd.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Abdul Lateef Attar <abdattar@amd.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4182
moves Intel-specific code to the arch-dependent file.
Other processor families might have different
implementation of these functions.
Hence, moving out of the common file.
Cc: Abner Chang <abner.chang@amd.com>
Cc: Paul Grimes <paul.grimes@amd.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4182
Adds MmSaveStateLib Library class in UefiCpuPkg.dec.
Adds function declaration header file.
Cc: Paul Grimes <paul.grimes@amd.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Abdul Lateef Attar <abdattar@amd.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Mikhail Krichanov
Savva Mitrofanov
Jiaxin Wu
Yuanhao Xie
Gerd Hoffmann
Tuan Phan
Ray Ni
Zhiguang Liu
Dun Tan
Wu, MingliangX
Abdul Lateef Attar
Zhang, Hongbin1
Abdul Lateef Attar