summaryrefslogtreecommitdiffstats
path: root/UefiCpuPkg
Commit message (Collapse)AuthorAgeFilesLines
* UefiCpuPkg/PiSmmCpuDxeSmm: fix 2M->4K page splitting regression for PDEsLaszlo Ersek2020-01-171-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit 4eee0cc7cc0d ("UefiCpuPkg/PiSmmCpu: Enable 5 level paging when CPU supports", 2019-07-12), the Page Directory Entry setting was regressed (corrupted) when splitting a 2MB page to 512 4KB pages, in the InitPaging() function. Consider the following hunk, displayed with $ git show --function-context --ignore-space-change 4eee0cc7cc0db > // > // If it is 2M page, check IsAddressSplit() > // > if (((*Pd & IA32_PG_PS) != 0) && IsAddressSplit (Address)) { > // > // Based on current page table, create 4KB page table for split area. > // > ASSERT (Address == (*Pd & PHYSICAL_ADDRESS_MASK)); > > Pt = AllocatePageTableMemory (1); > ASSERT (Pt != NULL); > > + *Pd = (UINTN) Pt | IA32_PG_RW | IA32_PG_P; > + > // Split it > - for (PtIndex = 0; PtIndex < SIZE_4KB / sizeof(*Pt); PtIndex++) { > - Pt[PtIndex] = Address + ((PtIndex << 12) | mAddressEncMask | PAGE_ATTRIBUTE_BITS); > + for (PtIndex = 0; PtIndex < SIZE_4KB / sizeof(*Pt); PtIndex++, Pt++) { > + *Pt = Address + ((PtIndex << 12) | mAddressEncMask | PAGE_ATTRIBUTE_BITS); > } // end for PT > *Pd = (UINT64)(UINTN)Pt | mAddressEncMask | PAGE_ATTRIBUTE_BITS; > } // end if IsAddressSplit > } // end for PD First, the new assignment to the Page Directory Entry (*Pd) is superfluous. That's because (a) we set (*Pd) after the Page Table Entry loop anyway, and (b) here we do not attempt to access the memory starting at "Address" (which is mapped by the original value of the Page Directory Entry). Second, appending "Pt++" to the incrementing expression of the PTE loop is a bug. It causes "Pt" to point *right past* the just-allocated Page Table, once we finish the loop. But the PDE assignment that immediately follows the loop assumes that "Pt" still points to the *start* of the new Page Table. The result is that the originally mapped 2MB page disappears from the processor's view. The PDE now points to a "Page Table" that is filled with garbage. The random entries in that "Page Table" will cause some virtual addresses in the original 2MB area to fault. Other virtual addresses in the same range will no longer have a 1:1 physical mapping, but be scattered over random physical page frames. The second phase of the InitPaging() function ("Go through page table and set several page table entries to absent or execute-disable") already manipulates entries in wrong Page Tables, for such PDEs that got split in the first phase. This issue has been caught as follows: - OVMF is started with 2001 MB of guest RAM. - This places the main SMRAM window at 0x7C10_1000. - The SMRAM management in the SMM Core links this SMRAM window into "mSmmMemoryMap", with a FREE_PAGE_LIST record placed at the start of the area. - At "SMM Ready To Lock" time, PiSmmCpuDxeSmm calls InitPaging(). The first phase (quoted above) decides to split the 2MB page at 0x7C00_0000 into 512 4KB pages, and corrupts the PDE. The new Page Table is allocated at 0x7CE0_D000, but the PDE is set to 0x7CE0_E000 (plus attributes 0x67). - Due to the corrupted PDE, the second phase of InitPaging() already looks up the PTE for Address=0x7C10_1000 in the wrong place. The second phase goes on to mark bogus PTEs as "NX". - PiSmmCpuDxeSmm calls SetMemMapAttributes(). Address 0x7C10_1000 is at the base of the SMRAM window, therefore it happens to be listed in the SMRAM map as an EfiConventionalMemory region. SetMemMapAttributes() calls SmmSetMemoryAttributes() to mark the region as XP. However, GetPageTableEntry() in ConvertMemoryPageAttributes() fails -- address 0x7C10_1000 is no longer mapped by anything! -- and so the attribute setting fails with RETURN_UNSUPPORTED. This error goes unnoticed, as SetMemMapAttributes() ignores the return value of SmmSetMemoryAttributes(). - When SetMemMapAttributes() reaches another entry in the SMRAM map, ConvertMemoryPageAttributes() decides it needs to split a 2MB page, and calls SplitPage(). - SplitPage() calls AllocatePageTableMemory() for the new Page Table, which takes us to InternalAllocMaxAddress() in the SMM Core. - The SMM core attempts to read the FREE_PAGE_LIST record at 0x7C10_1000. Because this virtual address is no longer mapped, the firmware crashes in InternalAllocMaxAddress(), when accessing (Pages->NumberOfPages). Remove the useless assignment to (*Pd) from before the loop. Revert the loop incrementing and the PTE assignment to the known good version. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1789335 Fixes: 4eee0cc7cc0db74489b99c19eba056b53eda6358 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg: Shadow microcode patch according to FIT microcode entry.Siyuan Fu2020-01-107-67/+222
| | | | | | | | | | | | | | | | | | | | | | | | The existing MpInitLib will shadow the microcode update patches from flash to memory and this is done by searching microcode region specified by PCD PcdCpuMicrocodePatchAddress and PcdCpuMicrocodePatchRegionSize. This brings a limition to platform FW that all the microcode patches must be placed in one continuous flash space. This patch shadows microcode update according to FIT microcode entries if it's present, otherwise it will fallback to original logic (by PCD). A new featured PCD gUefiCpuPkgTokenSpaceGuid.PcdCpuShadowMicrocodeByFit is added for enabling/disabling this support. TEST: Tested on FIT enabled platform. BZ: https://tianocore.acgmultimedia.com/show_bug.cgi?id=2449 Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Siyuan Fu <siyuan.fu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/CpuCommonFeaturesLib: SMXE bit of CR4 should setJason Voelz2020-01-101-0/+9
| | | | | | | | Add code to set SMXE in CR4 in the SmxInitialize flow when SMX is enabled. Signed-off-by: Jason Voelz <jason.voelz@intel.com> Cc: Ray Ni <ray.ni@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Add missed comments for parameter.Eric Dong2020-01-101-0/+2
| | | | | | | | | | | This issue caused by below change: SHA-1: b948a496150f4ae4f656c0f0ab672608723c80e6 * UefiCpuPkg/PiSmmCpuDxeSmm: Pre-allocate PROCEDURE_TOKEN buffer REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2388 Reviewed-by: Ray Ni <ray.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg: Always load microcode patch on AP processor.Siyuan, Fu2020-01-081-6/+0
| | | | | | | | | | | | | | | | | | | | This patch updates the microcode loader to always perform a microcode detect and load on both BSP and AP processor. This is to fix a potential microcode revision mismatch issue in below situation: 1. Assume there are two microcode co-exists in flash: one production version and one debug version microcode. 2. FIT loads production microcode to BSP and all AP. 3. UefiCpuPkg loader loads debug microcode to BSP, and skip the loading on AP. As a result, different microcode patches are loaded to BSP and AP, and trigger microcode mismatch error during OS boot. BZ link: https://bugzilla.tianocore.org/show_bug.cgi?id=2431 Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Siyuan Fu <siyuan.fu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg: Remove alignment check when calculate microcode size.Siyuan Fu2020-01-082-21/+6
| | | | | | | | | | | | | | | | | | | | This patch removes the unnecessary alignment check on microcode patch TotalSize introduced by commit d786a172. The TotalSize has already been checked with 1K alignment and MAX_ADDRESS in previous code as below: if ( (UINTN)MicrocodeEntryPoint > (MAX_ADDRESS - TotalSize) || ((UINTN)MicrocodeEntryPoint + TotalSize) > MicrocodeEnd || (DataSize & 0x3) != 0 || (TotalSize & (SIZE_1KB - 1)) != 0 || TotalSize < DataSize ) { Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Siyuan Fu <siyuan.fu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: improve the coding styleEric Dong2020-01-081-9/+9
| | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2434 Current code use below loops to enumerate the CPUs: for (Index = mMaxNumberOfCpus; Index-- > 0;) { it has no issue but not easy for the developers to read the code. Update above code to below style, for (Index = 0; Index < mMaxNumberOfCpus; Index++) { It make the developers easy to read and consistent with other similar cases in this driver. Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Eric Dong <eric.dong@intel.com>
* Revert "UefiCpuPkg/PiSmmCpuDxeSmm: Fix buffer overflow issue."Eric Dong2020-01-081-8/+8
| | | | | | | | | | This reverts commit 123b720eeb371e0a31eb727bcf59255b584e355f. The commit message for commit 123b720eeb37 is not correct. Cc: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Pre-allocate PROCEDURE_TOKEN bufferEric Dong2020-01-022-87/+109
| | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2388 Token is new introduced by MM MP Protocol. Current logic allocate Token every time when need to use it. The logic caused SMI latency raised to very high. Update logic to allocate Token buffer at driver's entry point. Later use the token from the allocated token buffer. Only when all the buffer have been used, then need to allocate new buffer. Former change (9caaa79dd7e078ebb4012dde3b3d3a5d451df609) missed PROCEDURE_TOKEN part, this change covers it. Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/MpInitLib: Remove redundant microcode fields in CPU_MP_DATAHao A Wu2020-01-022-42/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previous commits have introduced below fields in structure CPU_AP_DATA: UINT32 ProcessorSignature; UINT8 PlatformId; UINT64 MicrocodeEntryAddr; which store the information of: A. CPUID B. Platform ID C. Detected microcode patch entry address (including the microcode patch header) for each processor within system. Therefore, the below fields in structure CPU_MP_DATA: UINT32 ProcessorSignature; UINT32 ProcessorFlags; UINT64 MicrocodeDataAddress; UINT32 MicrocodeRevision; which store the BSP's information of: A. CPUID B. Platform ID C. The address and revision of detected microcode patch are redundant and can be removed. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/MpInitLib: Relocate microcode patch fields in CPU_MP_DATAHao A Wu2020-01-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | The below 2 microcode patch related fields in structure CPU_MP_DATA: UINT64 MicrocodePatchAddress; UINT64 MicrocodePatchRegionSize; They will be passed from PEI phase and be reused DXE phase. Previously, these 2 fields were placed after some fields with type 'UINTN', this will lead to different field offset in different architecture for them. This commit will move them before the fields with different size in different architecture to ensure they can be properly used in DXE phase. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/MpInitLib: Produce EDKII microcode patch HOBHao A Wu2020-01-025-8/+100
| | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2430 This commit will update the MpInitLib to: A. Collect the base address and size information after microcode patches being loaded into memory; B. Collect the detected microcode patch for each processor within system; C. Based on the collected information, produce the EDKII microcode patch HOB. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg: Add definitions for EDKII microcode patch HOBHao A Wu2020-01-022-0/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2430 This commit will add the definitions for EDKII microcode patch HOB. The intention of adding this HOB is to provide a scheme to store the below information: A. The base address and size of the microcode patches that are being loaded (from flash) into memory; B. The information of detected microcode patch for each processor within the system. The producer of the HOB will be the UefiCpuPkg/MpInitLib (where the load, detect and apply of the microcode happen). The consumer of the HOB can be modules that want to detect/apply the microcode patch by themselves again later during the boot flow. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/MpInitLib: Reduce the size when loading microcode patchesHao A Wu2020-01-023-62/+340
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2429 This commit will attempt to reduce the copy size when loading the microcode patches data from flash into memory. Such optimization is done by a pre-process of the microcode patch headers (on flash). A microcode patch will be loaded into memory only when the below 3 criteria are met: A. With a microcode patch header (which means the data is not padding data between microcode patches); B. The 'ProcessorSignature' & 'ProcessorFlags' fields in the header match at least one processor within system; C. If the Extended Signature Table exists in a microcode patch, the 'ProcessorSignature' & 'ProcessorFlag' fields in the table entries match at least one processor within system. Criterion B and C will require all the processors to be woken up once to collect their CPUID and Platform ID information. Hence, this commit will move the copy, detect and apply of microcode patch on BSP and APs after all the processors have been woken up. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/MpInitLib: Collect processors' CPUID & Platform ID infoHao A Wu2020-01-022-1/+15
| | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2429 This commit will collect the CPUID and Platform ID information for each processor within system. They will be stored in the CPU_AP_DATA structure. These information will be used in the next commit to decide whether a microcode patch will be loaded into memory. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Fix buffer overflow issue.Eric Dong2019-12-241-8/+8
| | | | | | | | | | | | The size for the array of mSmmMpSyncData->CpuData[] is 0 ~ mMaxNumberOfCpus -1. But current code may use mSmmMpSyncData->CpuData[mMaxNumberOfCpus]. This patch fixed this issue. Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Remove dependence between APsEric Dong2019-12-242-85/+45
| | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2268 In current implementation, when check whether APs called by StartUpAllAPs or StartUpThisAp, it checks the Tokens value used by other APs. Also the AP will update the Token value for itself if its task finished. In this case, the potential race condition issues happens for the tokens. Because of this, system may trig ASSERT during cycling test. This change enhance the code logic, add new attributes for the token to remove the reference for the tokens belongs to other APs. Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Avoid allocate Token every timeEric Dong2019-12-065-4/+88
| | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2388 Token is new introduced by MM MP Protocol. Current logic allocate Token every time when need to use it. The logic caused SMI latency raised to very high. Update logic to allocate Token buffer at driver's entry point. Later use the token from the allocated token buffer. Only when all the buffer have been used, then need to allocate new buffer. Reviewed-by: Ray Ni <ray.ni@intel.com> Signed-off-by: Eric Dong <eric.dong@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg: Update the coding stylesShenglei Zhang2019-12-044-4/+4
| | | | | | | | | | | | In MpLib.c, remove the white space on a new line. In PageTbl.c and PiSmmCpuDxeSmm.h, update the comment style. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/UefiCpuPkg.uni: Add missing strings for PCDShenglei Zhang2019-12-041-0/+16
| | | | | | | | Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/RegisterCpuFeature: Remove CPU_FEATURE_XD macroRay Ni2019-11-131-1/+1
| | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2329 Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/CpuCommonFeaturesLib: Remove XD enable/disable logicRay Ni2019-11-133-108/+1
| | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2329 XD (ExecutionDisable) feature, when turned on, allows page table entry BIT63 set to 1 indicating the memory pointed by the page table is disallowed to execute. DxeIpl::CreateIdentityMappingPageTables() enables the XD when CPU supports it. Later DxeCore modifies the page table to set the BIT63 to protect the stack/heap to disallow code execution in stack/heap. UefiCpuPkg/CpuCommonFeaturesLib enables/disables the XD feature according to PcdCpuFeaturesSetting. When XD is disabled, GP fault is generated immediately because some page entries have BIT63 set. To fix this issue, this patch removes the XD feature logic from UefiCpuPkg/CpuCommonFeaturesLib so the XD feature is only taken care of by DxeIpl. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg: Add YAML file for CI buildsMichael D Kinney2019-11-111-0/+51
| | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2315 Add YAML file to the package directory with the configuration of the checks to perform during a CI build. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* UefiCpuPkg/MpInitLib: Remove global variable X2ApicEnableRay Ni2019-11-052-9/+6
| | | | | | | | | | | | | | | | | | | | MpInitLib sets X2ApicEnable in two places. 1. CollectProcessorCount() This function is called when MpInitLibInitialize() hasn't been called before. It sets X2ApicEnable and later in the same function it configures all CPUs to operate in X2 APIC mode. 2. MpInitLibInitialize() The X2ApicEnable setting happens when this function is called in second time. But after that setting, no code consumes that flag. With the above analysis and with the purpose of simplifying the code, the X2ApicEnable in #1 is changed to local variable and the #2 can be changed to remove the setting of X2ApicEnable. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/MpInitLib: Set X2ApicEnable flag from BSPRay Ni2019-11-051-9/+16
| | | | | | | | | | | | | | | | | | | | | Today's logic sets X2ApicEnable flag in each AP's initialization path when InitFlag == ApInitConfig. Since all CPUs update the same global data, a spin-lock is used to avoid modifications from multiple CPUs happen at the same time. The spin-lock causes two problems: 1. Potential performance downgrade. 2. Undefined behavior when improper timer lib is used. For example we saw certain platforms used AcpiTimerLib from PcAtChipsetPkg and that library depends on retrieving PeiServices from idtr. But in fact AP's (idtr - 4) doesn't point to PeiServices. The patch simplifies the code to let BSP set the X2ApicEnable flag so the spin-lock acquisition from AP is not needed any more. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg: Add missing components to UefiCpuPkg.dscSean Brogan2019-10-231-0/+2
| | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2255 Update UefiCpuPkg.dsc to guarantee all libraries and modules are always built. Add the following components. * UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.inf * UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeaturesLib.inf ResetVector.inf is a binary INF, so no source builds are triggered from adding this line. However, a build with this component does verify the contents of the INF file. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/MpInitLib: honor the platform's boot CPU count in AP detectionLaszlo Ersek2019-10-115-40/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - If a platform boots such that the boot CPU count is smaller than PcdCpuMaxLogicalProcessorNumber, then the platform cannot use the "fast AP detection" logic added in commit 6e1987f19af7. (Which has been documented as a subset of use case (2) in the previous patch.) Said logic depends on the boot CPU count being equal to PcdCpuMaxLogicalProcessorNumber. If the equality does not hold, the platform either has to wait too long, or risk missing APs due to an early timeout. - The platform may not be able to use the variant added in commit 0594ec417c89 either. (Which has been documented as use case (1) in the previous patch.) See commit 861218740d6d. When OVMF runs on QEMU/KVM, APs may check in with the BSP in arbitrary order, plus the individual AP may take arbitrarily long to check-in. If "NumApsExecuting" falls to zero mid-enumeration, APs will be missed. Allow platforms to specify the exact boot CPU count, independently of PcdCpuMaxLogicalProcessorNumber. In this mode, the BSP waits for all APs to check-in regardless of timeout. If at least one AP fails to check-in, then the AP enumeration hangs forever. That is the desired behavior when the exact boot CPU count is known in advance. (A hung boot is better than an AP checking-in after timeout, and executing code from released storage.) Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/MpInitLib: expand comment on initial AP enumerationLaszlo Ersek2019-10-111-7/+29
| | | | | | | | | | | Before adding another AP enumeration mode, clarify the documentation on the current logic. No functional changes. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg: strip trailing whitespaceLeif Lindholm2019-10-041-1/+1
| | | | | | | | | Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* UefiCpuPkg/CpuDxe: clean up PAGE_TABLE_LIB_PAGING_CONTEXT usage.Dong, Eric2019-09-255-16/+112
| | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1039 Current implementation not checks system mode before using PAGE_TABLE_LIB_PAGING_CONTEXT.ContextData.X64 or PAGE_TABLE_LIB_PAGING_CONTEXT.ContextData.Ia32. This patch check the mode before using the correct one. Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/CpuExceptionHandlerLib: Fix split lockJohn E Lofgren2019-09-201-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2150 v4: The v3 posting didn't do what it promised to do, so do it now for real. V3 changes: change to mov instruction (non locking instuction) instead of xchg to simplify design. V2 changes: Add xchg 16 bit instructions to handle sgdt and sidt base 63:48 bits and 47:32 bits. Add comment to explain why xchg 64bit isnt being used Split lock happens when a locking instruction is used on mis-aligned data that crosses two cachelines. If close source platform enables Alignment Check Exception(#AC), They can hit a double fault due to split lock being in CpuExceptionHandlerLib. sigt and sgdt saves 10 bytes to memory, 8 bytes is base and 2 bytes is limit. The data is mis-aligned, can cross two cacheline, and a xchg instruction(locking instuction) is being utilize. Signed-off-by: John E Lofgren <john.e.lofgren@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg: Fix potential spinLock issue in SmmStartupThisApDamian Nikodem2019-09-201-7/+2
| | | | | | | | | | | | | | | | | | | | | | Due to needs a tackling the deficiency of the AP API, it's necessary to ensure that in non-blocking mode previous AP executed command is finished before starting new one. To remedy above: 1) execute AcquireSpinLock instead AcquireSpinLockOrFail - this will ensure time "window" to eliminate potential race condition between BSP and AP spinLock release in non-blocking mode. This also will eliminate possibility to start executing new AP function before last is finished. 2) remove returns EFI_STATUS - EFI_NOT_READY - in new scenario returned status is not necessary to caller. Signed-off-by: Damian Nikodem <damian.nikodem@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Benjamin You <benjamin.you@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Krzysztof Rusocki <krzysztof.rusocki@intel.com>
* UefiCpuPkg: Remove PcdCpuSmmStaticPageTableRay Ni2019-09-191-11/+0
| | | | | | | | | | PcdCpuSmmRestrictedMemoryAccess is introduced to replace PcdCpuSmmStaticPageTable. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/PiSmmCpu: Enable 5L paging only when phy addr line > 48Ray Ni2019-09-132-22/+39
| | | | | | | | | | | | | | | | | | | Today's behavior is to enable 5l paging when CPU supports it (CPUID[7,0].ECX.BIT[16] is set). The patch changes the behavior to enable 5l paging when two conditions are both met: 1. CPU supports it; 2. The max physical address bits is bigger than 48. Because 4-level paging can support to address physical address up to 2^48 - 1, there is no need to enable 5-level paging with max physical address bits <= 48. Signed-off-by: Ray Ni <ray.ni@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg: support single EFI_PEI_CORE_FV_LOCATION_PPI in PpiListChasel Chiu2019-09-051-5/+4
| | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2153 Current logic will skip searching EFI_PEI_CORE_FV_LOCATION_PPI when the PPI in PpiList having EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST flag, but platform may pass single PPI in PpiList that should be supported. Changed the logic to verify PpiList first before checking EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST flag. Test: Verified both single EFI_PEI_CORE_FV_LOCATION_PPI and multiple PPIs in PpiList cases and both can boot with the PeiCore specified by EFI_PEI_CORE_FV_LOCATION_PPI. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* UefiCpuPkg: Explain relationship between several SMM PCDsRay Ni2019-09-041-1/+7
| | | | | | | | | | | | | | | There are three PCDs that may impact the behavior of each other in SMM environment: PcdCpuSmmProfileEnable PcdHeapGuardPropertyMask in MdeModulePkg PcdCpuSmmRestrictedMemoryAccess The patch updates the comments in DEC file to document it. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/PiSmmCpu: Restrict access per PcdCpuSmmRestrictedMemoryAccessRay Ni2019-09-044-8/+49
| | | | | | | | | | | | | | | | | | Today's behavior is to always restrict access to non-SMRAM regardless the value of PcdCpuSmmRestrictedMemoryAccess. Because RAS components require to access all non-SMRAM memory, the patch changes the code logic to honor PcdCpuSmmRestrictedMemoryAccess so that only when the PCD is true, the restriction takes affect and page table memory is also protected. Because IA32 build doesn't reference this PCD, such restriction always takes affect in IA32 build. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/PiSmmCpu: Use new PCD PcdCpuSmmRestrictedMemoryAccessRay Ni2019-09-042-22/+34
| | | | | | | | | | | | | | | The patch changes PiSmmCpu driver to consume PCD PcdCpuSmmRestrictedMemoryAccess. Because the behavior controlled by PcdCpuSmmStaticPageTable in original code is not changed after switching to PcdCpuSmmRestrictedMemoryAccess. The functionality is not impacted by this patch. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg: Add PcdCpuSmmRestrictedMemoryAccessRay Ni2019-09-041-0/+12
| | | | | | | | | | | | | | | | | | The patch adds a new X64 only PCD PcdCpuSmmRestrictedMemoryAccess. The PCD indicates access to non-SMRAM memory is restricted to reserved, runtime and ACPI NVS type after SmmReadyToLock. MMIO access is always allowed regardless of the value of this PCD. Loose of such restriction is only required by RAS components in X64 platforms. The PCD value is considered as constantly TRUE in IA32 platforms. When the PCD value is TRUE, page table is initialized to cover all memory spaces and the memory occupied by page table is protected by page table itself as read-only. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/SecCore: get AllSecPpiList after SecPlatformMain.Eric Dong2019-08-301-1/+2
| | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2136 SecPlatformMain is a platform hook function which let platform does some update. Some platform may adjust SecCoreData->PeiTemporaryRamBase which caused former saved AllSecPpiList variable invalid. This patch update the logic to get AllSecPpiList after SecPlatformMain. If SecPlatformMain() returns no platform-specific PPI list, then there is nothing to merge, so we don't need "AllSecPpiList" at all. Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg: Adding a new TSC library by using CPUID(0x15) TSC leafDonald Kuo2019-08-2113-0/+643
| | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1909 Cc: Ray Ni <ray.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Amy Chan <amy.chan@intel.com> Cc: Rangasai V Chaganty <rangasai.v.chaganty@intel.com> Signed-off-by: Donald Kuo <donald.kuo@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/CpuCommonFeaturesLib: Use new macros.Dong, Eric2019-08-214-132/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2040 Below code is current implementation: if (MsrRegister[ProcessorNumber].Bits.Lock == 0) { CPU_REGISTER_TABLE_WRITE_FIELD ( ProcessorNumber, Msr, MSR_IA32_FEATURE_CONTROL, MSR_IA32_FEATURE_CONTROL_REGISTER, Bits.Lock, 1 ); } 1. In first normal boot, the Bits.Lock is 0, 1 will be added into the register table and then will set to the MSR. 2. Trig warm reboot, MSR value preserves. After normal boot phase, the Bits.Lock is 1, so it will not be added into the register table during the warm reboot phase. 3. Trig S3 then resume, the Bits.Lock change to 0 and Bits.Lock is not added in register table, so it's still 0 after resume. This is not an expect behavior. The expect value is the value should always 1 after booting or resuming from S3. The root cause for this issue is 1. driver bases on current value to insert the "set value action" to the register table. 2. Some MSRs may reserve their value during warm reboot. The solution for this issue is using new added macros for the MSRs which preserve value during warm reboot. Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/RegisterCpuFeaturesLib: Supports test then write new value logic.Dong, Eric2019-08-211-1/+30
| | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2040 Supports new logic which test current value before write new value. Only write new value when current value not same as new value. Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/RegisterCpuFeaturesLib: Combine CR read/write action.Dong, Eric2019-08-211-47/+63
| | | | | | Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Supports test then write new value logic.Dong, Eric2019-08-211-0/+29
| | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2040 Supports new logic which test current value before write new value. Only write new value when current value not same as new value. Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Combine CR read/write action.Dong, Eric2019-08-211-42/+62
| | | | | | Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg/RegisterCpuFeaturesLib: Add "Test Then Write" Macros.Dong, Eric2019-08-213-4/+134
| | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2040 Add below new micros which test the current value before write the new value. Only write new value when current value not same as new value. CPU_REGISTER_TABLE_TEST_THEN_WRITE32 CPU_REGISTER_TABLE_TEST_THEN_WRITE64 CPU_REGISTER_TABLE_TEST_THEN_WRITE_FIELD Also add below API: CpuRegisterTableTestThenWrite Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Cc: Star Zeng <star.zeng@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: don't free page table pages that are required to ↵Damian Nikodem2019-08-211-40/+59
| | | | | | | | | | | | | | | | | | | | | handle current page fault Reclaim may free page table pages that are required to handle current page fault. This causes a page leak, and, after sufficent number of specific page fault+reclaim pairs, we run out of reclaimable pages and hit: ASSERT (MinAcc != (UINT64)-1); To remedy, prevent pages essential to handling current page fault: (1) from being considered as reclaim candidates (first reclaim phase) (2) from being freed as part of "branch cleanup" (second reclaim phase) Signed-off-by: Damian Nikodem <damian.nikodem@intel.com> Cc: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Krzysztof Rusocki <krzysztof.rusocki@intel.com>
* UefiCpuPkg/Cpuid: Add description for parameter LeafFunctionShenglei Zhang2019-08-161-0/+2
| | | | | | | | | | | LeafFunction needs to be described in comments. https://bugzilla.tianocore.org/show_bug.cgi?id=2052 Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* UefiCpuPkg/PiSmmCpuDxeSmm: Fix coding styleShenglei Zhang2019-08-132-6/+6
| | | | | | | | | | | | | 1. Update CPUStatus to CpuStatus in comments to align comments with code. 2. Add "OUT" attribute for "ProcedureArguments" parameter in function header. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-30 15:56:13 +0000