summaryrefslogtreecommitdiff
path: root/UefiCpuPkg
AgeCommit message (Collapse)AuthorFilesLines
2024-01-09UefiCpuPkg: Check lower 24 bits of ProcessorNumberduntan1-1/+4
Check lower 24 bits of ProcessorNumber instead of the value of ProcessorNumber in the API MpInitLibGetProcessorInfo() of MpInitLibUp instance. Lower 24 bits of ProcessorNumber contains the actual processor number. The BIT24 of input ProcessorNumber might be set to indicate if the EXTENDED_PROCESSOR_INFORMATION will be retrived. Signed-off-by: Dun Tan <dun.tan@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Min Xu <min.m.xu@intel.com> Message-Id: <20240108050804.1718-3-dun.tan@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
2024-01-09UefiCpuPkg: set EXTENDED_PROCESSOR_INFORMATION to 0duntan4-7/+13
Set EXTENDED_PROCESSOR_INFORMATION to 0 in API MpInitLibGetProcessorInfo() of MpInitLibUp. This commit use ZeroMem() to set all fileds in output EFI_PROCESSOR_INFORMATION to 0 before StatusFlag field is reassigned. Previously EXTENDED_PROCESSOR_INFORMATION in the API MpInitLibGetProcessorInfo() of MpInitLibUp is ignored. In PEI/DXE MpInitLib, EXTENDED_PROCESSOR_INFORMATION will be retrived when BIT24 of input ProcessorNumber is set. This commit can avoid garbage in the output structure in MpInitLibGetProcessorInfo() of MpInitLibUp. Signed-off-by: Dun Tan <dun.tan@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Min Xu <min.m.xu@intel.com> Message-Id: <20240108050804.1718-2-dun.tan@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
2024-01-05UefiCpuPkg/CpuMpPei: Parallel get stack base for better performance.Zhiguang Liu1-27/+29
Parallel run the function GetStackBase for all APs for better performance. Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Daoxiang Li <daoxiang.li@intel.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
2023-12-26UefiCpuPkg/PiSmmCpuDxeSmm: Reduce one round BSP & AP syncJiaxin Wu1-16/+20
After BSP returned from SmmCoreEntry, there are several rounds BSP and AP sync in BSP handler: 1 .ReleaseAllAPs(); /// Notify all APs to exit. if (SmmCpuFeaturesNeedConfigureMtrrs()) { 2. SmmCpuSyncWaitForAPs(); /// Wait for all APs to program MTRRs. 3. ReleaseAllAPs(); /// Signal APs to restore MTRRs. } 4. SmmCpuSyncWaitForAPs(); /// Wait for all APs to complete pending tasks including MTRR. 5. ReleaseAllAPs(); /// Signal APs to Reset states. 6. SmmCpuSyncWaitForAPs(); /// Gather APs to exit SMM synchronously. Before step 6 and after step 5, BSP performs below items: A. InitializeDebugAgent() /// Stop source level debug. B. SmmCpuUpdate() /// Perform pending operations for hot-plug. C. Present = FALSE; /// Clear the Present flag of BSP. For InitializeDebugAgent(), BSP needs to wait all APs complete pending tasks and then notify all APs to stop source level debug. So, above step 4 & step 5 are required for InitializeDebugAgent(). For SmmCpuUpdate(), it's to perform pending operations for hot-plug CPUs take effect in next SMI. Existing APs in SMI do not reply on the CPU switch & hot-add & hot-remove operations. So, no need step 4 and step 5 for additional one round BSP & AP sync. Step 6 can make sure all APs are ready to exit SMM, then hot-plug operation can take effect in next SMI. For BSP "Present" flag, AP does not reply on it. No need step 4 and step 5 for additional one round BSP & AP sync. Based on above analysis, step 4 and step 5 are only required if need configure MTRR and support SMM source level debug. So, we can reduce one round BSP and AP sync if both are unsupported. With this change, SMI performance can be improved. Cc: Laszlo Ersek <lersek@redhat.com> 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> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@Intel.com>
2023-12-26UefiCpuPkg/PiSmmCpuDxeSmm: Invert ReleaseAllAPs & InitializeDebugAgentJiaxin Wu1-5/+5
Existing BSP handler stops source level debug, then call ReleaseAllAPs to tell all APs can reset the Present flag to FALSE: InitializeDebugAgent (); /// Stop source level debug ReleaseAllAPs (); /// Tell APs can reset "Present" flag. This patch is to invert ReleaseAllAPs & InitializeDebugAgent: ReleaseAllAPs (); /// Tell APs can reset "Present" flag. InitializeDebugAgent (); /// Stop source level debug After this change, there is no negative impact since SMM source level debug feature doesn't depend on AP's "Present" flag, no impact to the SMM source level debug capability. Instead, the change will benefit the AP source level debug capability to trace its "Present" flag change for SMI exit since the source level debug feature will be stopped after each AP has the chance to reset the state. Cc: Laszlo Ersek <lersek@redhat.com> 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> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@Intel.com>
2023-12-26UefiCpuPkg/PiSmmCpuDxeSmm: Align BSP and AP sync logic for SMI exitJiaxin Wu1-10/+10
Below piece of code is the BSP and AP sync logic for SMI exit. 1. AP after finish the scheduled procedure: if (SmmCpuFeaturesNeedConfigureMtrrs ()) { SmmCpuSyncReleaseBsp (); SmmCpuSyncWaitForBsp (); ... } SmmCpuSyncReleaseBsp (); SmmCpuSyncWaitForBsp (); SmmCpuSyncReleaseBsp (); 2. BSP after return from SmmCoreEntry: SmmCpuSyncWaitForAPs (); if (SmmCpuFeaturesNeedConfigureMtrrs ()) { ReleaseAllAPs (); ... SmmCpuSyncWaitForAPs (); } ReleaseAllAPs (); SmmCpuSyncWaitForAPs(); This patch is to make BSP same as AP sync logic: if (SmmCpuFeaturesNeedConfigureMtrrs ()) { SmmCpuSyncWaitForAPs (); ReleaseAllAPs (); ... } SmmCpuSyncWaitForAPs (); ReleaseAllAPs (); SmmCpuSyncWaitForAPs(); With the change, it will be easy to understand the sync flow as below: BSP: SmmCpuSyncWaitForAPs <-- AP: SmmCpuSyncReleaseBsp BSP: ReleaseAllAPs --> AP: SmmCpuSyncWaitForBsp This patch doesn't have function impact. Cc: Laszlo Ersek <lersek@redhat.com> 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> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@Intel.com>
2023-12-26UefiCpuPkg/PiSmmCpuDxeSmm: Check SMM Debug Agent support or notJiaxin Wu4-11/+23
This patch is to check SMM Debug Agent support or not before InitializeDebugAgent. Cc: Laszlo Ersek <lersek@redhat.com> 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> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@Intel.com>
2023-12-20UefiCpuPkg/PiSmmCpuDxeSmm: Consume SmmCpuSyncLibJiaxin Wu3-213/+68
There is the SmmCpuSyncLib Library class define the SMM CPU sync flow, which is aligned with existing SMM CPU driver sync behavior. This patch is to consume SmmCpuSyncLib instance directly. With this change, SMM CPU Sync flow/logic can be customized with different implementation no matter for any purpose, e.g. performance tuning, handle specific register, etc. Cc: Laszlo Ersek <lersek@redhat.com> 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> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
2023-12-20UefiCpuPkg/PiSmmCpuDxeSmm: Simplify RunningApCount decrementJiaxin Wu1-1/+1
To decrease the count of RunningApCount, InterlockedDecrement is enough to achieve that. This patch is to simplify RunningApCount decrement. Cc: Laszlo Ersek <lersek@redhat.com> 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> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
2023-12-20UefiCpuPkg: Implements SmmCpuSyncLib library instanceJiaxin Wu3-0/+688
Implements SmmCpuSyncLib Library instance. The instance refers the existing SMM CPU driver (PiSmmCpuDxeSmm) sync implementation and behavior: 1.Abstract Counter and Run semaphores into SmmCpuSyncCtx. 2.Abstract CPU arrival count operation to SmmCpuSyncGetArrivedCpuCount(), SmmCpuSyncCheckInCpu(), SmmCpuSyncCheckOutCpu(), SmmCpuSyncLockDoor(). Implementation is aligned with existing SMM CPU driver. 3. Abstract SMM CPU Sync flow to: BSP: SmmCpuSyncReleaseOneAp --> AP: SmmCpuSyncWaitForBsp BSP: SmmCpuSyncWaitForAPs <-- AP: SmmCpuSyncReleaseBsp Semaphores release & wait during sync flow is same as existing SMM CPU driver. 4.Same operation to Counter and Run semaphores by leverage the atomic compare exchange. Cc: Laszlo Ersek <lersek@redhat.com> 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> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
2023-12-20UefiCpuPkg: Adds SmmCpuSyncLib library classJiaxin Wu2-0/+293
Intel is planning to provide different SMM CPU Sync implementation along with some specific registers to improve the SMI performance, hence need SmmCpuSyncLib Library for Intel. This patch is to: 1.Adds SmmCpuSyncLib Library class in UefiCpuPkg.dec. 2.Adds SmmCpuSyncLib.h function declaration header file. For the new SmmCpuSyncLib, it provides 3 sets of APIs: 1. ContextInit/ContextDeinit/ContextReset: ContextInit() is called in driver's entrypoint to allocate and initialize the SMM CPU Sync context. ContextDeinit() is called in driver's unload function to deinitialize SMM CPU Sync context. ContextReset() is called before CPU exist SMI, which allows CPU to check into the next SMI from this point. 2. GetArrivedCpuCount/CheckInCpu/CheckOutCpu/LockDoor: When SMI happens, all processors including BSP enter to SMM mode by calling CheckInCpu(). The elected BSP calls LockDoor() so that CheckInCpu() will return the error code after that. CheckOutCpu() can be called in error handling flow for the CPU who calls CheckInCpu() earlier. GetArrivedCpuCount() returns the number of checked-in CPUs. 3. WaitForAPs/ReleaseOneAp/WaitForBsp/ReleaseBsp WaitForAPs() & ReleaseOneAp() are called from BSP to wait the number of APs and release one specific AP. WaitForBsp() & ReleaseBsp() are called from APs to wait and release BSP. The 4 APIs are used to synchronize the running flow among BSP and APs. BSP and AP Sync flow can be easy understand as below: BSP: ReleaseOneAp --> AP: WaitForBsp BSP: WaitForAPs <-- AP: ReleaseBsp Cc: Laszlo Ersek <lersek@redhat.com> 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> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
2023-12-20UefiCpuPkg/PiSmmCpuDxeSmm: Optimize Semaphore Sync between BSP and APJiaxin Wu1-14/+58
This patch is to define 3 new functions (WaitForBsp & ReleaseBsp & ReleaseOneAp) used for the semaphore sync between BSP & AP. With the change, BSP and AP Sync flow will be easy understand as below: BSP: ReleaseAllAPs or ReleaseOneAp --> AP: WaitForBsp BSP: WaitForAllAPs <-- AP: ReleaseBsp Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zeng Star <star.zeng@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@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>
2023-12-12UefiCpuPkg: Avoid assuming only one smmbasehobDun Tan1-32/+149
Modify the gSmmBaseHobGuid consumption code to remove the asuumption that there is only one gSmmBaseHobGuid. If the CPU number is big enough, there will be more than one SmmBaseHob in the HOB list. 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>
2023-12-12UefiCpuPkg: Cache core type in MpInfo2 HOBDun Tan2-2/+59
Cache core type in MpInfo2 HOB by CpuMpPei module. 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>
2023-12-12UefiCpuPkg: Add a new field in MpInfo2 HOBDun Tan1-0/+2
Add new field CoreType in gMpInformationHobGuid2 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>
2023-12-12UefiCpuPkg: Consume MpInfo2Hob in PiSmmCpuDxeDun Tan3-51/+168
Consume MpInfo2Hob in PiSmmCpuDxe driver to get NumberOfProcessors, MaxNumberOfCpus and EFI_PROCESSOR_INFORMATION for all CPU from the MpInformation2 HOB. This can avoid calling MP service. 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>
2023-12-12UefiCpuPkg: Build MpInfo2HOB in CpuMpPeiDun Tan3-2/+96
Build MpInfo2HOB in CpuMpPei module so that later PiSmmCpuDxe or other StandaloneMm module can consume the HOB. Since there might be more one gMpInformationHobGuid2 in HOB list, CpuMpPei create a gMpInformationHobGuid2 with 0 value NumberOfProcessors field in the end of the process to indicate it's the last MP_INFORMATION2_HOB. 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>
2023-12-12UefiCpuPkg: Create gMpInformationHobGuid2 in UefiCpuPkgDun Tan2-0/+59
Create gMpInformationHobGuid2 in UefiCpuPkg. Currently, there is a gMpInformationHobGuid defined, created and consumed only in StandaloneMmPkg. The HOB contains the EFI_PROCESSOR_INFORMATION structure for each CPU and the number of processors. This is the same as the information that PiSmmCpuDxeSmm uses MpService Protocol to get. This new gMpInformationHobGuid2 also contains the NumberOfProcessors and the EFI_PROCESSOR_INFORMATION for each CPU. Also the HOB is extended to support the case that the maximum HOB length is not enough for all CPU. So there might be more than one HOB instance in the HOB list. Each HOB describes the corresponding CPU index range. The plan is to create gMpInformationHob2Guid in CpuMpPei module(implemented in next commit). Then PiSmmCpuDxeSmm and other MM_STANDALONE modules can consume the hob. This can avoid calling MpService Protocol in PiSmmCpuDxeSmm. Also the issue that one gMpInformationHobGuid might be not enough when CPU number is 1~2000 or bigger can be solved. 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>
2023-12-08UefiCpuPkg/PiSmmCpuDxeSmm: Get processor extended informationWu, Jiaxin1-0/+10
This patch is to extend SmmAddProcessor function to get processor extended information. It's to complete commit 1fadd18d. 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: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20231115111553.6592-3-jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
2023-12-08UefiCpuPkg/BaseXApicLib: Fix CPUID_V2_EXTENDED_TOPOLOGY detectionWu, Jiaxin1-5/+16
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>
2023-12-07UefiCpuPkg: Backup and Restore MSR IA32_U_CET in SMI handler.Sheng Wei2-0/+30
OS may enable CET-IBT feature by set MSR IA32_U_CET.bit2. If IA32_U_CET.bit2 is set, CPU is in WAIT_FOR_ENDBRANCH state and the next assemble code is not ENDBR, it will trigger #CP exception when set CR4.CET bit. SMI handler needs to backup MSR IA32_U_CET and clear MSR IA32_U_CET before set CR4.CET bit, And SMI handler needs to restore MSR IA32_U_CET when exit SMI handler. Signed-off-by: Sheng Wei <w.sheng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com> Cc: Tan Dun <dun.tan@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
2023-12-07UefiCpuPkg: Only change CR4.CET bit for enable and disable CET.Sheng Wei2-6/+14
Signed-off-by: Sheng Wei <w.sheng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com> Cc: Tan Dun <dun.tan@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
2023-12-07UefiCpuPkg: Use CET macro definitions in Cet.inc for SmiEntry.nasm files.Sheng Wei2-29/+4
Signed-off-by: Sheng Wei <w.sheng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com> Cc: Tan Dun <dun.tan@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
2023-12-07UefiCpuPkg: Use macro CR4_CET_BIT to replace hard code value in Cet.nasm.Sheng Wei2-6/+8
Signed-off-by: Sheng Wei <w.sheng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com> Cc: Tan Dun <dun.tan@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
2023-12-07UefiCpuPkg: Add macro definitions for CET feature for NASM files.Sheng Wei1-0/+26
Signed-off-by: Sheng Wei <w.sheng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com> Cc: Tan Dun <dun.tan@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
2023-12-06UefiCpuPkg/CpuMpPei: Use CpuPageTableLib to set memory attribute.Zhiguang Liu1-248/+69
Currently, there are code to set memory attribute in CpuMpPei module. However, the code doesn't handle the case of 5 level paging. Use the CpuPageTableLib to set memory attribute for two purpose: 1. Add 5 level paging support 2. Clean up code 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>
2023-12-06UefiCpuPkg/CpuPageTableLib/TestCase: Refine test case for PAE paging.Zhiguang Liu2-4/+34
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>
2023-12-06UefiCpuPkg/CpuPageTableLib: Init local variable before using it.Zhiguang Liu1-3/+1
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>
2023-11-29UefiCpuPkg/PiSmmCpuDxeSmm: Use NonSmm BSP as default SMM BSP.Zhiguang Liu1-0/+10
Currently, if BSP election is not enabled, will use Core0 as SMM BSP. However, Core0 does not always have the highest performance. So, we can used NonSmm BSP as default BSP. This will take effect in normal SMM init flow and S3 boot flow. In normal SMM flow, the code is executed before first SMI. In S3 flow, the code is executed in Non-SMM BSP's first SMI, where the gSmmCpuPrivate keeps the data from last boot. 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>
2023-11-28UefiCpuPkg/MpInitLib: Copy SEV-ES save area pointer during APIC ID sortingTom Lendacky1-1/+7
With SEV-SNP, the SEV-ES save area for a vCPU should be unique to that vCPU. After commit 3323359a811a, 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: 3323359a811a ("UefiCpuPkg/MpInitLib: Reuse VMSA allocation to ...") Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
2023-11-28UefiCpuPkg/MpInitLib: Use AsmCpuidEx() for CPUID_EXTENDED_TOPOLOGY leafTom Lendacky1-1/+8
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: d4d7c9ad5fe5 ("UefiCpuPkg/MpInitLib: use BSP to do extended ...") Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
2023-11-27UefiCpuPkg: Use Attribute From SMM MemoryAttributesTable if NonzeroTaylor Beebe1-8/+11
PiSmmCore fetches the EFI memory map and calls SplitTable() to split each loaded image section into its own descriptor with EFI_MEMORY_XP marking data sections and EFI_MEMORY_RO marking code sections. The SMM MAT logic is almost identical to the DXE MAT logic but goes a step further and also updates the memory map descriptors which describe image code and data sections to be of type EfiRuntimeServicesCode and EfiRuntimeServicesData respectively. The consolidated MAT logic (present in the new ImagePropertiesRecordLib) more closely follows the DXE MAT logic which identifies image code sections by the presence of the attribute EFI_MEMORY_RO in the descriptor and image data sections by the presence of the attribute EFI_MEMORY_XP. Because of the flow choice of the consolidated MAT logic, the SMM MAT logic should just use the attributes from the table returned by SplitTable(). Additionally, the function EnforceMemoryMapAttribute() in the SMM MAT logic will ensure that the CODE and DATA memory types have the desired attributes so bisecting this patch series at this commit will still function as before. 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: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2023-11-27UefiCpuPkg/MpInitLib: Update the comments of _CPU_MP_DATA.xieyuanh2-6/+9
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>
2023-11-27UefiCpuPkg/MpInitLib: Enable execute disable bit.Yuanhao Xie2-3/+12
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>
2023-11-10UefiCpuPkg/PiSmmCpuDxeSmm: Fix CP Exception when CET enableJiaxin Wu3-58/+81
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>
2023-10-31UefiCpuPkg: Correct file description for MpHandOff header fileYuanhao Xie1-1/+4
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> Message-Id: <20231007063203.936-1-yuanhao.xie@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Rahul R Kumar <rahul.r.kumar@intel.com>
2023-10-26UefiCpuPkg/MpInitLib: Wait for all APs to finish initializationYuanhao Xie1-2/+7
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: 964a4f032dcd 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>
2023-10-25UefiCpuPkg/BaseXApicX2ApicLib: fix CPUID_V2_EXTENDED_TOPOLOGY detectionGerd Hoffmann1-5/+16
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>
2023-10-17UefiCpuPkg: RISC-V: MMU: Introduce a PCD for SATP modeTuan Phan3-1/+16
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>
2023-10-12UefiCpuPkg/CpuDxe: Eliminate the unused variable.YuanhaoXie1-9/+7
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>
2023-10-09UefiCpuPkg/CpuDxe: Update RefreshMemoryAttributesFromMtrrRay Ni1-273/+36
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>
2023-10-09UefiCpuPkg/MtrrUnitTest: Add Unit test of setting/getting memoryYuanhaoXie1-6/+36
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>
2023-10-09UefiCpuPkg/MtrrLib: Improve MtrrDebugPrintAllMtrrsWorker.YuanhaoXie1-35/+10
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>
2023-10-09UefiCpuPkg/MtrrLib: Add API MtrrGetMemoryAttributesInMtrrSettings.YuanhaoXie2-10/+130
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>
2023-10-09UefiCpuPkg/MtrrLib: Update APIs related to set memory attributes.Ray Ni1-39/+56
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>
2023-10-09UefiCpuPkg/MtrrUnitTest: Update UnitTestMtrrSetAllMtrrs().YuanhaoXie1-15/+20
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>
2023-10-09UefiCpuPkg/MtrrLib: Fix MtrrSetAllMtrrs to handle absent fixed MTRRs.Ray Ni2-9/+26
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>
2023-10-09UefiCpuPkg/MtrrUnitTest: Update UnitTestMtrrGetFixedMtrr().YuanhaoXie1-0/+13
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>
2023-10-09UefiCpuPkg/MtrrLib: Update MtrrGetFixedMtrr().YuanhaoXie1-1/+5
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>
2023-10-09UefiCpuPkg/MtrrUnitTest: Update UnitTestMtrrGetAllMtrrs().YuanhaoXie1-15/+84
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>
generated by cgit v1.1 at 2024-08-15 07:36:31 +0000