This patch is to complete 170d4ce8, sync the change to BaseXApicLib.
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.
Cc: Laszlo Ersek <lersek@redhat.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: Star Zeng <star.zeng@intel.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Message-Id: <20231115111553.6592-2-jiaxin.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Refine test case:
1. Check PAE paging reserved bits is zero.
2. Set stack as random value.
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
The local variable OneOfPagingEntry is used before initialized, this
may cause reserved bit in page table entry is set especially in PAE
paging mode. The bug is random because it depends on the value in
stack.
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
With SEV-SNP, the SEV-ES save area for a vCPU should be unique to that
vCPU. After commit 3323359a81, the VMSA allocation was re-used, but when
sorting the CPUs by APIC ID, the save area was not updated to follow the
original CPU. Similar to the StartupApSignal address, the SevEsSaveArea
address should be updated when sorting the CPUs.
This does not cause an issue at this time because all APs are in HLT state
and then are (re)started at the same time, with the same VMSA contents.
However, this should be fixed to account for any change in future
behavior.
Fixes: 3323359a81 ("UefiCpuPkg/MpInitLib: Reuse VMSA allocation to ...")
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The CPUID_EXTENDED_TOPOLOGY CPUID leaf takes a subleaf as input when
returning CPUID information. However, the AsmCpuid() function does not
zero out ECX before the CPUID instruction, so the input leaf is used as
the sub-leaf for the CPUID request and returns erroneous/invalid CPUID
data, since the intent of the request was to get data related to sub-leaf
0. Instead, use AsmCpuidEx() for the CPUID_EXTENDED_TOPOLOGY leaf.
Fixes: d4d7c9ad5f ("UefiCpuPkg/MpInitLib: use BSP to do extended ...")
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
No functional changes in this patch.
Updates the comments of _CPU_MP_DATA to delcared that duplications in
CpuMpData are present to avoid to be direct accessed and comprehended
in assembly code. CpuMpData: Intended for use in C code while
ExchangeInfo are used in assembly code in this module.
This patch deletes the unnecessary comments in CpuMpData, since
CpuMpData is no longer responsible for passing information from PEI to
DXE.
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Cc: Laszlo Ersek lersek@redhat.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>
This patch synchronizes the No-Execute bit in the IA32_EFER
register for the APs before the RestoreVolatileRegisters operation.
The commit 964a4f0, titled "Eliminate the second INIT-SIPI-SIPI
sequence," replaces the second INIT-SIPI-SIPI sequence with the BSP
calling the SwitchApContext function to initiate a specialized start-up
signal, waking up APs in the DXE instead of using INIT-SIPI-SIPI.
Due to this change, the logic for "Enable execute disable bit" in
MpFuncs.nasm is no longer executed. However, to ensure the proper setup
of the page table, it is necessary to synchronize the IA32_EFER.NXE for
APs before executing RestoreVolatileRegisters .
Based on SDM:
If IA32_EFER.NXE is set to 1, it signifies execute-disable, meaning
instruction fetches are not allowed from the 4-KByte page controlled by
this entry. Conversely, if it is set to 0, it is reserved.
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek lersek@redhat.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>
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>
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>
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>
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>
The timer compare register is 64-bit so simplifying the delay
function.
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Signed-off-by: Tuan Phan <tphan@ventanamicro.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Update ProcTrace feature code to support enable collect performance
data by generating CYC and TSC packets. Add a new dynamic
PCD to indicate if enable performance collecting. In ProcTrace.c
code, if this new PCD is true, after check cpuid, CYC and TSC
packets will be generated by setting the corresponding MSR bits
feilds if supported.
Bugzila: https://bugzilla.tianocore.org/show_bug.cgi?id=4423
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>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Xiao X Chen <xiao.x.chen@intel.com>
Update code to support enable ProcTrace only on BSP. Add a new
dynamic PCD to indicate if enable ProcTrace only on BSP. In
ProcTrace.c code, if this new PCD is true, only allocate buffer
and set CtrlReg.Bits.TraceEn to 1 for BSP.
Bugzila: https://bugzilla.tianocore.org/show_bug.cgi?id=4423
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>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Xiao X Chen <xiao.x.chen@intel.com>
Because UefiCpuPkg/UefiCpuLib is merged to MdePkg/CpuLib and all modules
are updated to not depend on this library, remove it completely.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Yu Pu <yu.pu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
UefiCpuPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
The CPU exception handler library code was rewritten at some point to
populate the vector code templates with absolute references at runtime,
given that the XCODE linker does not permit absolute references in
executable code when creating PIE executables.
This is rather unfortunate, as this prevents us from using strict
permissions on the memory mappings, given that the .text section needs
to be writable at runtime for this arrangement to work.
So let's make this hack XCODE-only, by setting a preprocessor #define
from the command line when using the XCODE toolchain, and only including
the runtime fixup code when the macro is defined.
While at it, rename the Xcode5ExceptionHandlerAsm.nasm source file and
drop the Xcode5 prefix: this code is used by other toolchains too.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The PEI flavor of CpuExceptionHandlerLib never populates more than 32
IDT vectors, and there is no CET shadow stack support in the PEI phase.
So there is no need to use the generic ExceptionHandler NASM source,
which carries a 256-entry template and CET support, and writes to its
own .text section when built using XCODE, which is not permitted in the
PEI phase. So let's switch to the reduced SEC/PEI version of this
component, which is sufficient for PEI and doesn't suffer from the same
issue.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Wu, Jiaxin
Zhiguang Liu
Tom Lendacky
xieyuanh
Gerd Hoffmann
Tuan Phan
Ray Ni
Abdul Lateef Attar
Abdul Lateef Attar
Dun Tan
Yu Pu
Rebecca Cran
Ard Biesheuvel