2016-07-20 15:56:58 +02:00
|
|
|
## @file
|
|
|
|
|
# MP Initialize Library instance for DXE driver.
|
|
|
|
|
#
|
UefiCpuPkg/MpInitLib: Not pass microcode info between archs in CPU_MP_DATA
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2465
Commit 89164babec:
UefiCpuPkg/MpInitLib: don't shadow the microcode patch twice.
attempted to use 'MicrocodePatchRegionSize' and 'MicrocodePatchAddress'
fields to avoid loading the microcode patches data into memory again in
the DXE phase.
However, the CPU_MP_DATA structure has members with type 'UINTN' or
pointer before the microcode patch related fields. This may cause issues
when PEI and DXE are of different archs (e.g. PEI - IA32, DXE - x64),
since the microcode patch related fields will have different offsets in
the CPU_MP_DATA structure.
Commit 88bd066166:
UefiCpuPkg/MpInitLib: Relocate microcode patch fields in CPU_MP_DATA
tried to resolve the above-mentioned issue by relocating the fields
'MicrocodePatchRegionSize' and 'MicrocodePatchAddress' before members with
different size between different archs. But it failed to take the case of
pre-built binaries (e.g. FSP) into consideration.
Binaries can be built when the code base had a different version of the
CPU_MP_DATA structure definition. This may cause issues when accessing
these microcode patch related fields, since their offsets are different
(between PEI phase in the binaries and DXE phase in current code
implementation).
This commit will use the newly introduced EDKII microcode patch HOB
instead for the DXE phase to get the information of the loaded microcode
patches data done in the PEI phase. And the 'MicrocodePatchRegionSize' and
'MicrocodePatchAddress' fields in CPU_MP_DATA will not be used to pass
information between phases.
For pre-built binaries, they can be classified into 3 types with regard to
the time when they are being built:
A. Before commit 89164babec
(In other words, 'MicrocodePatchRegionSize' and 'MicrocodePatchAddress'
were not being used to skip microcode load in DXE)
For this case, the EDKII microcode patch HOB will not be produced. This
commit will load the microcode patches data again in DXE. Such behavior is
the same with the code base back then.
B. After commit 89164babec, before commit e1ed55738e
(In other words, 'MicrocodePatchRegionSize' and 'MicrocodePatchAddress'
being used to skip microcode load in DXE, but failed to work properly
between differnt archs.)
For this case, the EDKII microcode patch HOB will not be produced as well.
This commit will also load the microcode patches data again in DXE.
But since commit 89164babec failed to keep the detection and application
of microcode patches working properly in DXE after skipping the load, we
fall back to the origin behavior (that is to load the microcode patches
data again in DXE).
C. After commit e1ed55738e
(In other words, EDKII microcode patch HOB will be produced.)
For this case, it will have the same behavior with the BIOS built from
the current source codes.
Cc: Michael Kubacki <michael.a.kubacki@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
2020-01-22 07:02:05 +01:00
|
|
|
# Copyright (c) 2016 - 2020, Intel Corporation. All rights reserved.<BR>
|
2019-04-04 01:07:22 +02:00
|
|
|
# SPDX-License-Identifier: BSD-2-Clause-Patent
|
2016-07-20 15:56:58 +02:00
|
|
|
#
|
|
|
|
|
##
|
|
|
|
|
|
|
|
|
|
[Defines]
|
|
|
|
|
INF_VERSION = 0x00010005
|
|
|
|
|
BASE_NAME = DxeMpInitLib
|
|
|
|
|
MODULE_UNI_FILE = DxeMpInitLib.uni
|
|
|
|
|
FILE_GUID = B88F7146-9834-4c55-BFAC-481CC0C33736
|
|
|
|
|
MODULE_TYPE = DXE_DRIVER
|
|
|
|
|
VERSION_STRING = 1.1
|
|
|
|
|
LIBRARY_CLASS = MpInitLib|DXE_DRIVER
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# The following information is for reference only and not required by the build tools.
|
|
|
|
|
#
|
|
|
|
|
# VALID_ARCHITECTURES = IA32 X64
|
|
|
|
|
#
|
|
|
|
|
|
2016-07-20 16:44:39 +02:00
|
|
|
[Sources.IA32]
|
|
|
|
|
Ia32/MpEqu.inc
|
|
|
|
|
Ia32/MpFuncs.nasm
|
|
|
|
|
|
|
|
|
|
[Sources.X64]
|
|
|
|
|
X64/MpEqu.inc
|
|
|
|
|
X64/MpFuncs.nasm
|
|
|
|
|
|
2016-07-20 15:56:58 +02:00
|
|
|
[Sources.common]
|
|
|
|
|
DxeMpLib.c
|
|
|
|
|
MpLib.c
|
|
|
|
|
MpLib.h
|
2016-07-20 17:49:35 +02:00
|
|
|
Microcode.c
|
2016-07-20 15:56:58 +02:00
|
|
|
|
|
|
|
|
[Packages]
|
|
|
|
|
MdePkg/MdePkg.dec
|
2016-12-26 09:28:58 +01:00
|
|
|
MdeModulePkg/MdeModulePkg.dec
|
2016-07-20 15:56:58 +02:00
|
|
|
UefiCpuPkg/UefiCpuPkg.dec
|
|
|
|
|
|
|
|
|
|
[LibraryClasses]
|
|
|
|
|
BaseLib
|
|
|
|
|
LocalApicLib
|
|
|
|
|
MemoryAllocationLib
|
|
|
|
|
HobLib
|
|
|
|
|
MtrrLib
|
|
|
|
|
CpuLib
|
|
|
|
|
UefiCpuLib
|
|
|
|
|
UefiBootServicesTableLib
|
2016-12-26 09:28:58 +01:00
|
|
|
DebugAgentLib
|
2017-05-22 08:49:03 +02:00
|
|
|
SynchronizationLib
|
2020-04-22 08:50:24 +02:00
|
|
|
PcdLib
|
2016-07-20 15:56:58 +02:00
|
|
|
|
2016-12-26 12:13:44 +01:00
|
|
|
[Protocols]
|
|
|
|
|
gEfiTimerArchProtocolGuid ## SOMETIMES_CONSUMES
|
|
|
|
|
|
2016-07-20 15:56:58 +02:00
|
|
|
[Guids]
|
|
|
|
|
gEfiEventExitBootServicesGuid ## CONSUMES ## Event
|
2017-09-25 13:06:17 +02:00
|
|
|
gEfiEventLegacyBootGuid ## SOMETIMES_CONSUMES ## Event
|
UefiCpuPkg/MpInitLib: Not pass microcode info between archs in CPU_MP_DATA
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2465
Commit 89164babec:
UefiCpuPkg/MpInitLib: don't shadow the microcode patch twice.
attempted to use 'MicrocodePatchRegionSize' and 'MicrocodePatchAddress'
fields to avoid loading the microcode patches data into memory again in
the DXE phase.
However, the CPU_MP_DATA structure has members with type 'UINTN' or
pointer before the microcode patch related fields. This may cause issues
when PEI and DXE are of different archs (e.g. PEI - IA32, DXE - x64),
since the microcode patch related fields will have different offsets in
the CPU_MP_DATA structure.
Commit 88bd066166:
UefiCpuPkg/MpInitLib: Relocate microcode patch fields in CPU_MP_DATA
tried to resolve the above-mentioned issue by relocating the fields
'MicrocodePatchRegionSize' and 'MicrocodePatchAddress' before members with
different size between different archs. But it failed to take the case of
pre-built binaries (e.g. FSP) into consideration.
Binaries can be built when the code base had a different version of the
CPU_MP_DATA structure definition. This may cause issues when accessing
these microcode patch related fields, since their offsets are different
(between PEI phase in the binaries and DXE phase in current code
implementation).
This commit will use the newly introduced EDKII microcode patch HOB
instead for the DXE phase to get the information of the loaded microcode
patches data done in the PEI phase. And the 'MicrocodePatchRegionSize' and
'MicrocodePatchAddress' fields in CPU_MP_DATA will not be used to pass
information between phases.
For pre-built binaries, they can be classified into 3 types with regard to
the time when they are being built:
A. Before commit 89164babec
(In other words, 'MicrocodePatchRegionSize' and 'MicrocodePatchAddress'
were not being used to skip microcode load in DXE)
For this case, the EDKII microcode patch HOB will not be produced. This
commit will load the microcode patches data again in DXE. Such behavior is
the same with the code base back then.
B. After commit 89164babec, before commit e1ed55738e
(In other words, 'MicrocodePatchRegionSize' and 'MicrocodePatchAddress'
being used to skip microcode load in DXE, but failed to work properly
between differnt archs.)
For this case, the EDKII microcode patch HOB will not be produced as well.
This commit will also load the microcode patches data again in DXE.
But since commit 89164babec failed to keep the detection and application
of microcode patches working properly in DXE after skipping the load, we
fall back to the origin behavior (that is to load the microcode patches
data again in DXE).
C. After commit e1ed55738e
(In other words, EDKII microcode patch HOB will be produced.)
For this case, it will have the same behavior with the BIOS built from
the current source codes.
Cc: Michael Kubacki <michael.a.kubacki@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
2020-01-22 07:02:05 +01:00
|
|
|
gEdkiiMicrocodePatchHobGuid ## SOMETIMES_CONSUMES ## HOB
|
2016-07-20 15:56:58 +02:00
|
|
|
|
|
|
|
|
[Pcd]
|
UefiCpuPkg/MpInitLib DXE: Add PCD to control AP status check interval
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2627
The commit will introduce a static PCD to specify the periodic interval
for checking the AP status when MP services StartupAllAPs() and
StartupThisAP() are being executed in a non-blocking manner. Or in other
words, specifies the interval for callback function CheckApsStatus().
The purpose is to provide the platform owners with the ability to choose
the proper interval value to trigger CheckApsStatus() according to:
A) The number of processors in the system;
B) How MP services (StartupAllAPs & StartupThisAP) being used.
Setting the PCD to a small value means the AP status check callback will
be triggered more frequently, it can benefit the performance for the case
when the BSP uses WaitForEvent() or uses CheckEvent() in a loop to wait
for AP(s) to complete the task, especially when the task can be finished
considerably fast on AP(s).
An example is within function CpuFeaturesInitialize() under
UefiCpuPkg/Library/RegisterCpuFeaturesLib/DxeRegisterCpuFeaturesLib.c,
where BSP will perform the same task with APs and requires all the
processors to finish the task before BSP proceeds to its next task.
Setting the PCD to a big value, on the other hand, can reduce the impact
on BSP by the time being consumed in CheckApsStatus(), especially when the
number of processors is huge so that the time consumed in CheckApsStatus()
is not negligible.
The type of the PCD is UINT32, which means the maximum possible interval
value can be set to:
4,294,967,295 microseconds = 4,295 seconds = 71.58 minutes = 1.19 hours
which should be sufficient for usage.
For least impact, the default value of the new PCD will be the same with
the current interval value. It will be set to 100,000 microseconds, which
is 100 milliseconds.
Unitest done:
A) OS boot successfully;
B) Use debug message to confirm the 'TriggerTime' parameter for the
'SetTimer' service is the same before & after this patch.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Brian J. Johnson <brian.johnson@hpe.com>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-03-13 08:22:19 +01:00
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber ## CONSUMES
|
|
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuBootLogicalProcessorNumber ## CONSUMES
|
|
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuApInitTimeOutInMicroSeconds ## SOMETIMES_CONSUMES
|
|
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuApStackSize ## CONSUMES
|
|
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuMicrocodePatchAddress ## CONSUMES
|
|
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuMicrocodePatchRegionSize ## CONSUMES
|
|
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuApLoopMode ## CONSUMES
|
|
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuApTargetCstate ## SOMETIMES_CONSUMES
|
|
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuApStatusCheckIntervalInMicroSeconds ## CONSUMES
|
2020-08-12 22:21:42 +02:00
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdSevEsIsEnabled ## CONSUMES
|
UefiCpuPkg/MpInitLib DXE: Add PCD to control AP status check interval
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2627
The commit will introduce a static PCD to specify the periodic interval
for checking the AP status when MP services StartupAllAPs() and
StartupThisAP() are being executed in a non-blocking manner. Or in other
words, specifies the interval for callback function CheckApsStatus().
The purpose is to provide the platform owners with the ability to choose
the proper interval value to trigger CheckApsStatus() according to:
A) The number of processors in the system;
B) How MP services (StartupAllAPs & StartupThisAP) being used.
Setting the PCD to a small value means the AP status check callback will
be triggered more frequently, it can benefit the performance for the case
when the BSP uses WaitForEvent() or uses CheckEvent() in a loop to wait
for AP(s) to complete the task, especially when the task can be finished
considerably fast on AP(s).
An example is within function CpuFeaturesInitialize() under
UefiCpuPkg/Library/RegisterCpuFeaturesLib/DxeRegisterCpuFeaturesLib.c,
where BSP will perform the same task with APs and requires all the
processors to finish the task before BSP proceeds to its next task.
Setting the PCD to a big value, on the other hand, can reduce the impact
on BSP by the time being consumed in CheckApsStatus(), especially when the
number of processors is huge so that the time consumed in CheckApsStatus()
is not negligible.
The type of the PCD is UINT32, which means the maximum possible interval
value can be set to:
4,294,967,295 microseconds = 4,295 seconds = 71.58 minutes = 1.19 hours
which should be sufficient for usage.
For least impact, the default value of the new PCD will be the same with
the current interval value. It will be set to 100,000 microseconds, which
is 100 milliseconds.
Unitest done:
A) OS boot successfully;
B) Use debug message to confirm the 'TriggerTime' parameter for the
'SetTimer' service is the same before & after this patch.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Brian J. Johnson <brian.johnson@hpe.com>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-03-13 08:22:19 +01:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard ## CONSUMES
|
