2016-07-20 15:56:58 +02:00
|
|
|
## @file
|
|
|
|
|
# MP Initialize Library instance for PEI driver.
|
|
|
|
|
#
|
2021-02-09 14:58:01 +01:00
|
|
|
# Copyright (c) 2016 - 2021, 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 = PeiMpInitLib
|
|
|
|
|
MODULE_UNI_FILE = PeiMpInitLib.uni
|
|
|
|
|
FILE_GUID = B00F6090-7739-4830-B906-E0032D388987
|
|
|
|
|
MODULE_TYPE = PEIM
|
|
|
|
|
VERSION_STRING = 1.1
|
|
|
|
|
LIBRARY_CLASS = MpInitLib|PEIM
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# 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]
|
2021-12-09 04:28:00 +01:00
|
|
|
Ia32/AmdSev.c
|
2016-07-20 16:44:39 +02:00
|
|
|
Ia32/MpFuncs.nasm
|
|
|
|
|
|
|
|
|
|
[Sources.X64]
|
2021-12-09 04:28:00 +01:00
|
|
|
X64/AmdSev.c
|
2016-07-20 16:44:39 +02:00
|
|
|
X64/MpFuncs.nasm
|
|
|
|
|
|
2016-07-20 15:56:58 +02:00
|
|
|
[Sources.common]
|
2021-12-09 04:27:30 +01:00
|
|
|
AmdSev.c
|
2021-02-09 14:58:01 +01:00
|
|
|
MpEqu.inc
|
2016-07-20 15:56:58 +02:00
|
|
|
PeiMpLib.c
|
|
|
|
|
MpLib.c
|
|
|
|
|
MpLib.h
|
2016-07-20 17:49:35 +02:00
|
|
|
Microcode.c
|
2023-06-28 10:47:22 +02:00
|
|
|
MpHandOff.h
|
2016-07-20 15:56:58 +02:00
|
|
|
[Packages]
|
|
|
|
|
MdePkg/MdePkg.dec
|
|
|
|
|
UefiCpuPkg/UefiCpuPkg.dec
|
2018-06-27 10:42:51 +02:00
|
|
|
MdeModulePkg/MdeModulePkg.dec
|
2016-07-20 15:56:58 +02:00
|
|
|
|
|
|
|
|
[LibraryClasses]
|
|
|
|
|
BaseLib
|
|
|
|
|
LocalApicLib
|
|
|
|
|
MemoryAllocationLib
|
|
|
|
|
HobLib
|
|
|
|
|
MtrrLib
|
|
|
|
|
CpuLib
|
|
|
|
|
SynchronizationLib
|
2018-06-27 10:42:51 +02:00
|
|
|
PeiServicesLib
|
2020-04-22 08:50:24 +02:00
|
|
|
PcdLib
|
2022-11-07 07:30:26 +01:00
|
|
|
CcExitLib
|
2021-04-01 18:32:44 +02:00
|
|
|
MicrocodeLib
|
2016-07-20 15:56:58 +02:00
|
|
|
|
|
|
|
|
[Pcd]
|
|
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber ## CONSUMES
|
UefiCpuPkg/MpInitLib: honor the platform's boot CPU count in AP detection
- 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>
2019-10-07 14:05:28 +02:00
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuBootLogicalProcessorNumber ## CONSUMES
|
|
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuApInitTimeOutInMicroSeconds ## SOMETIMES_CONSUMES
|
2016-07-20 15:56:58 +02:00
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuApStackSize ## CONSUMES
|
|
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuMicrocodePatchAddress ## CONSUMES
|
|
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuMicrocodePatchRegionSize ## CONSUMES
|
|
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuApLoopMode ## CONSUMES
|
|
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuApTargetCstate ## SOMETIMES_CONSUMES
|
UefiCpuPkg: Allow AP booting under SEV-ES
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Typically, an AP is booted using the INIT-SIPI-SIPI sequence. This
sequence is intercepted by the hypervisor, which sets the AP's registers
to the values requested by the sequence. At that point, the hypervisor can
start the AP, which will then begin execution at the appropriate location.
Under SEV-ES, AP booting presents some challenges since the hypervisor is
not allowed to alter the AP's register state. In this situation, we have
to distinguish between the AP's first boot and AP's subsequent boots.
First boot:
Once the AP's register state has been defined (which is before the guest
is first booted) it cannot be altered. Should the hypervisor attempt to
alter the register state, the change would be detected by the hardware
and the VMRUN instruction would fail. Given this, the first boot for the
AP is required to begin execution with this initial register state, which
is typically the reset vector. This prevents the BSP from directing the
AP startup location through the INIT-SIPI-SIPI sequence.
To work around this, the firmware will provide a build time reserved area
that can be used as the initial IP value. The hypervisor can extract this
location value by checking for the SEV-ES reset block GUID that must be
located 48-bytes from the end of the firmware. The format of the SEV-ES
reset block area is:
0x00 - 0x01 - SEV-ES Reset IP
0x02 - 0x03 - SEV-ES Reset CS Segment Base[31:16]
0x04 - 0x05 - Size of the SEV-ES reset block
0x06 - 0x15 - SEV-ES Reset Block GUID
(00f771de-1a7e-4fcb-890e-68c77e2fb44e)
The total size is 22 bytes. Any expansion to this block must be done
by adding new values before existing values.
The hypervisor will use the IP and CS values obtained from the SEV-ES
reset block to set as the AP's initial values. The CS Segment Base
represents the upper 16 bits of the CS segment base and must be left
shifted by 16 bits to form the complete CS segment base value.
Before booting the AP for the first time, the BSP must initialize the
SEV-ES reset area. This consists of programming a FAR JMP instruction
to the contents of a memory location that is also located in the SEV-ES
reset area. The BSP must program the IP and CS values for the FAR JMP
based on values drived from the INIT-SIPI-SIPI sequence.
Subsequent boots:
Again, the hypervisor cannot alter the AP register state, so a method is
required to take the AP out of halt state and redirect it to the desired
IP location. If it is determined that the AP is running in an SEV-ES
guest, then instead of calling CpuSleep(), a VMGEXIT is issued with the
AP Reset Hold exit code (0x80000004). The hypervisor will put the AP in
a halt state, waiting for an INIT-SIPI-SIPI sequence. Once the sequence
is recognized, the hypervisor will resume the AP. At this point the AP
must transition from the current 64-bit long mode down to 16-bit real
mode and begin executing at the derived location from the INIT-SIPI-SIPI
sequence.
Another change is around the area of obtaining the (x2)APIC ID during AP
startup. During AP startup, the AP can't take a #VC exception before the
AP has established a stack. However, the AP stack is set by using the
(x2)APIC ID, which is obtained through CPUID instructions. A CPUID
instruction will cause a #VC, so a different method must be used. The
GHCB protocol supports a method to obtain CPUID information from the
hypervisor through the GHCB MSR. This method does not require a stack,
so it is used to obtain the necessary CPUID information to determine the
(x2)APIC ID.
The new 16-bit protected mode GDT entry is used in order to transition
from 64-bit long mode down to 16-bit real mode.
A new assembler routine is created that takes the AP from 64-bit long mode
to 16-bit real mode. This is located under 1MB in memory and transitions
from 64-bit long mode to 32-bit compatibility mode to 16-bit protected
mode and finally 16-bit real mode.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
2020-08-12 22:21:42 +02:00
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase ## SOMETIMES_CONSUMES
|
2021-12-09 04:28:00 +01:00
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdGhcbHypervisorFeatures ## CONSUMES
|
2023-07-18 12:05:18 +02:00
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdFirstTimeWakeUpAPsBySipi ## CONSUMES
|
UefiCpuPkg: Allow AP booting under SEV-ES
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Typically, an AP is booted using the INIT-SIPI-SIPI sequence. This
sequence is intercepted by the hypervisor, which sets the AP's registers
to the values requested by the sequence. At that point, the hypervisor can
start the AP, which will then begin execution at the appropriate location.
Under SEV-ES, AP booting presents some challenges since the hypervisor is
not allowed to alter the AP's register state. In this situation, we have
to distinguish between the AP's first boot and AP's subsequent boots.
First boot:
Once the AP's register state has been defined (which is before the guest
is first booted) it cannot be altered. Should the hypervisor attempt to
alter the register state, the change would be detected by the hardware
and the VMRUN instruction would fail. Given this, the first boot for the
AP is required to begin execution with this initial register state, which
is typically the reset vector. This prevents the BSP from directing the
AP startup location through the INIT-SIPI-SIPI sequence.
To work around this, the firmware will provide a build time reserved area
that can be used as the initial IP value. The hypervisor can extract this
location value by checking for the SEV-ES reset block GUID that must be
located 48-bytes from the end of the firmware. The format of the SEV-ES
reset block area is:
0x00 - 0x01 - SEV-ES Reset IP
0x02 - 0x03 - SEV-ES Reset CS Segment Base[31:16]
0x04 - 0x05 - Size of the SEV-ES reset block
0x06 - 0x15 - SEV-ES Reset Block GUID
(00f771de-1a7e-4fcb-890e-68c77e2fb44e)
The total size is 22 bytes. Any expansion to this block must be done
by adding new values before existing values.
The hypervisor will use the IP and CS values obtained from the SEV-ES
reset block to set as the AP's initial values. The CS Segment Base
represents the upper 16 bits of the CS segment base and must be left
shifted by 16 bits to form the complete CS segment base value.
Before booting the AP for the first time, the BSP must initialize the
SEV-ES reset area. This consists of programming a FAR JMP instruction
to the contents of a memory location that is also located in the SEV-ES
reset area. The BSP must program the IP and CS values for the FAR JMP
based on values drived from the INIT-SIPI-SIPI sequence.
Subsequent boots:
Again, the hypervisor cannot alter the AP register state, so a method is
required to take the AP out of halt state and redirect it to the desired
IP location. If it is determined that the AP is running in an SEV-ES
guest, then instead of calling CpuSleep(), a VMGEXIT is issued with the
AP Reset Hold exit code (0x80000004). The hypervisor will put the AP in
a halt state, waiting for an INIT-SIPI-SIPI sequence. Once the sequence
is recognized, the hypervisor will resume the AP. At this point the AP
must transition from the current 64-bit long mode down to 16-bit real
mode and begin executing at the derived location from the INIT-SIPI-SIPI
sequence.
Another change is around the area of obtaining the (x2)APIC ID during AP
startup. During AP startup, the AP can't take a #VC exception before the
AP has established a stack. However, the AP stack is set by using the
(x2)APIC ID, which is obtained through CPUID instructions. A CPUID
instruction will cause a #VC, so a different method must be used. The
GHCB protocol supports a method to obtain CPUID information from the
hypervisor through the GHCB MSR. This method does not require a stack,
so it is used to obtain the necessary CPUID information to determine the
(x2)APIC ID.
The new 16-bit protected mode GDT entry is used in order to transition
from 64-bit long mode down to 16-bit real mode.
A new assembler routine is created that takes the AP from 64-bit long mode
to 16-bit real mode. This is located under 1MB in memory and transitions
from 64-bit long mode to 32-bit compatibility mode to 16-bit protected
mode and finally 16-bit real mode.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
2020-08-12 22:21:42 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbBase ## CONSUMES
|
2021-12-09 04:27:50 +01:00
|
|
|
gEfiMdePkgTokenSpaceGuid.PcdConfidentialComputingGuestAttr ## CONSUMES
|
2020-02-11 14:30:48 +01:00
|
|
|
|
|
|
|
|
[Ppis]
|
|
|
|
|
gEdkiiPeiShadowMicrocodePpiGuid ## SOMETIMES_CONSUMES
|
2016-07-20 15:56:58 +02:00
|
|
|
|
2018-06-27 10:42:51 +02:00
|
|
|
[Guids]
|
2018-09-05 08:22:18 +02:00
|
|
|
gEdkiiS3SmmInitDoneGuid
|
2019-12-23 07:32:49 +01:00
|
|
|
gEdkiiMicrocodePatchHobGuid
|
