2016-07-20 15:56:58 +02:00
|
|
|
/** @file
|
|
|
|
|
Common header file for MP Initialize Library.
|
|
|
|
|
|
2023-03-01 07:09:47 +01:00
|
|
|
Copyright (c) 2016 - 2023, Intel Corporation. All rights reserved.<BR>
|
2020-02-29 16:05:45 +01:00
|
|
|
Copyright (c) 2020, AMD Inc. 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
|
|
|
|
|
|
|
|
**/
|
|
|
|
|
|
|
|
|
|
#ifndef _MP_LIB_H_
|
|
|
|
|
#define _MP_LIB_H_
|
|
|
|
|
|
|
|
|
|
#include <PiPei.h>
|
|
|
|
|
|
2019-08-01 11:58:31 +02:00
|
|
|
#include <Register/Intel/Cpuid.h>
|
2020-02-29 16:05:45 +01:00
|
|
|
#include <Register/Amd/Cpuid.h>
|
2021-12-09 04:28:00 +01:00
|
|
|
#include <Register/Amd/Ghcb.h>
|
2019-08-01 11:58:31 +02:00
|
|
|
#include <Register/Intel/Msr.h>
|
|
|
|
|
#include <Register/Intel/LocalApic.h>
|
|
|
|
|
#include <Register/Intel/Microcode.h>
|
2016-07-20 15:56:58 +02:00
|
|
|
|
|
|
|
|
#include <Library/MpInitLib.h>
|
|
|
|
|
#include <Library/BaseLib.h>
|
|
|
|
|
#include <Library/BaseMemoryLib.h>
|
|
|
|
|
#include <Library/MemoryAllocationLib.h>
|
|
|
|
|
#include <Library/DebugLib.h>
|
|
|
|
|
#include <Library/LocalApicLib.h>
|
|
|
|
|
#include <Library/CpuLib.h>
|
|
|
|
|
#include <Library/TimerLib.h>
|
|
|
|
|
#include <Library/SynchronizationLib.h>
|
|
|
|
|
#include <Library/MtrrLib.h>
|
|
|
|
|
#include <Library/HobLib.h>
|
2020-04-22 08:50:24 +02:00
|
|
|
#include <Library/PcdLib.h>
|
2021-04-01 18:32:44 +02:00
|
|
|
#include <Library/MicrocodeLib.h>
|
2021-12-09 04:27:50 +01:00
|
|
|
#include <ConfidentialComputingGuestAttr.h>
|
2016-07-20 15:56:58 +02:00
|
|
|
|
2021-12-09 04:27:30 +01:00
|
|
|
#include <Register/Amd/Fam17Msr.h>
|
|
|
|
|
#include <Register/Amd/Ghcb.h>
|
|
|
|
|
|
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
|
|
|
#include <Guid/MicrocodePatchHob.h>
|
2023-06-28 10:47:22 +02:00
|
|
|
#include "MpHandOff.h"
|
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
|
|
|
|
2016-07-20 18:20:26 +02:00
|
|
|
#define WAKEUP_AP_SIGNAL SIGNATURE_32 ('S', 'T', 'A', 'P')
|
2023-06-28 10:47:22 +02:00
|
|
|
//
|
|
|
|
|
// To trigger the start-up signal, BSP writes the specified
|
|
|
|
|
// StartupSignalValue to the StartupSignalAddress of each processor.
|
|
|
|
|
// This address is monitored by the APs, and as soon as they receive
|
|
|
|
|
// the value that matches the MP_HAND_OFF_SIGNAL, they will wake up
|
|
|
|
|
// and switch the context from PEI to DXE phase.
|
|
|
|
|
//
|
|
|
|
|
#define MP_HAND_OFF_SIGNAL SIGNATURE_32 ('M', 'P', 'H', 'O')
|
2016-07-20 18:20:26 +02:00
|
|
|
|
2016-07-21 10:08:12 +02:00
|
|
|
#define CPU_INIT_MP_LIB_HOB_GUID \
|
|
|
|
|
{ \
|
|
|
|
|
0x58eb6a19, 0x3699, 0x4c68, { 0xa8, 0x36, 0xda, 0xcd, 0x8e, 0xdc, 0xad, 0x4a } \
|
|
|
|
|
}
|
|
|
|
|
|
2016-07-21 15:20:18 +02:00
|
|
|
//
|
|
|
|
|
// The MP data for switch BSP
|
|
|
|
|
//
|
|
|
|
|
#define CPU_SWITCH_STATE_IDLE 0
|
|
|
|
|
#define CPU_SWITCH_STATE_STORED 1
|
|
|
|
|
#define CPU_SWITCH_STATE_LOADED 2
|
|
|
|
|
|
2019-12-19 07:33:44 +01:00
|
|
|
//
|
|
|
|
|
// Default maximum number of entries to store the microcode patches information
|
|
|
|
|
//
|
|
|
|
|
#define DEFAULT_MAX_MICROCODE_PATCH_NUM 8
|
|
|
|
|
|
|
|
|
|
//
|
|
|
|
|
// Data structure for microcode patch information
|
|
|
|
|
//
|
|
|
|
|
typedef struct {
|
|
|
|
|
UINTN Address;
|
|
|
|
|
UINTN Size;
|
|
|
|
|
} MICROCODE_PATCH_INFO;
|
|
|
|
|
|
2022-08-26 09:04:46 +02:00
|
|
|
//
|
|
|
|
|
// CPU volatile registers around INIT-SIPI-SIPI
|
|
|
|
|
//
|
|
|
|
|
typedef struct {
|
|
|
|
|
UINTN Cr0;
|
|
|
|
|
UINTN Cr3;
|
|
|
|
|
UINTN Cr4;
|
|
|
|
|
UINTN Dr0;
|
|
|
|
|
UINTN Dr1;
|
|
|
|
|
UINTN Dr2;
|
|
|
|
|
UINTN Dr3;
|
|
|
|
|
UINTN Dr6;
|
|
|
|
|
UINTN Dr7;
|
|
|
|
|
IA32_DESCRIPTOR Gdtr;
|
|
|
|
|
IA32_DESCRIPTOR Idtr;
|
|
|
|
|
UINT16 Tr;
|
|
|
|
|
} CPU_VOLATILE_REGISTERS;
|
|
|
|
|
|
2016-07-21 15:20:18 +02:00
|
|
|
//
|
|
|
|
|
// CPU exchange information for switch BSP
|
|
|
|
|
//
|
|
|
|
|
typedef struct {
|
2022-08-26 09:04:46 +02:00
|
|
|
UINT8 State; // offset 0
|
|
|
|
|
UINTN StackPointer; // offset 4 / 8
|
|
|
|
|
CPU_VOLATILE_REGISTERS VolatileRegisters; // offset 8 / 16
|
2016-07-21 15:20:18 +02:00
|
|
|
} CPU_EXCHANGE_ROLE_INFO;
|
|
|
|
|
|
2016-07-20 17:32:17 +02:00
|
|
|
//
|
|
|
|
|
// AP loop state when APs are in idle state
|
|
|
|
|
// It's value is the same with PcdCpuApLoopMode
|
|
|
|
|
//
|
|
|
|
|
typedef enum {
|
|
|
|
|
ApInHltLoop = 1,
|
|
|
|
|
ApInMwaitLoop = 2,
|
|
|
|
|
ApInRunLoop = 3
|
|
|
|
|
} AP_LOOP_MODE;
|
|
|
|
|
|
2016-07-20 17:33:25 +02:00
|
|
|
//
|
|
|
|
|
// AP initialization state during APs wakeup
|
|
|
|
|
//
|
|
|
|
|
typedef enum {
|
|
|
|
|
ApInitConfig = 1,
|
|
|
|
|
ApInitReconfig = 2,
|
|
|
|
|
ApInitDone = 3
|
|
|
|
|
} AP_INIT_STATE;
|
|
|
|
|
|
2016-07-20 17:43:29 +02:00
|
|
|
//
|
|
|
|
|
// AP state
|
|
|
|
|
//
|
2018-07-24 16:25:41 +02:00
|
|
|
// The state transitions for an AP when it process a procedure are:
|
|
|
|
|
// Idle ----> Ready ----> Busy ----> Idle
|
|
|
|
|
// [BSP] [AP] [AP]
|
|
|
|
|
//
|
2016-07-20 17:43:29 +02:00
|
|
|
typedef enum {
|
|
|
|
|
CpuStateIdle,
|
|
|
|
|
CpuStateReady,
|
|
|
|
|
CpuStateBusy,
|
2018-11-02 09:27:48 +01:00
|
|
|
CpuStateFinished,
|
2016-07-20 17:43:29 +02:00
|
|
|
CpuStateDisabled
|
|
|
|
|
} CPU_STATE;
|
|
|
|
|
|
2016-07-20 17:33:25 +02:00
|
|
|
//
|
|
|
|
|
// AP related data
|
|
|
|
|
//
|
|
|
|
|
typedef struct {
|
|
|
|
|
SPIN_LOCK ApLock;
|
|
|
|
|
volatile UINT32 *StartupApSignal;
|
|
|
|
|
volatile UINTN ApFunction;
|
|
|
|
|
volatile UINTN ApFunctionArgument;
|
|
|
|
|
BOOLEAN CpuHealthy;
|
2016-07-20 17:43:29 +02:00
|
|
|
volatile CPU_STATE State;
|
2016-07-20 17:47:59 +02:00
|
|
|
CPU_VOLATILE_REGISTERS VolatileRegisters;
|
2016-07-20 17:33:25 +02:00
|
|
|
BOOLEAN Waiting;
|
|
|
|
|
BOOLEAN *Finished;
|
|
|
|
|
UINT64 ExpectedTime;
|
|
|
|
|
UINT64 CurrentTime;
|
|
|
|
|
UINT64 TotalTime;
|
|
|
|
|
EFI_EVENT WaitEvent;
|
2019-12-19 06:36:24 +01:00
|
|
|
UINT32 ProcessorSignature;
|
|
|
|
|
UINT8 PlatformId;
|
2019-12-23 07:32:49 +01:00
|
|
|
UINT64 MicrocodeEntryAddr;
|
2021-03-12 12:39:38 +01:00
|
|
|
UINT32 MicrocodeRevision;
|
2021-12-09 04:28:00 +01:00
|
|
|
SEV_ES_SAVE_AREA *SevEsSaveArea;
|
2016-07-20 17:33:25 +02:00
|
|
|
} CPU_AP_DATA;
|
|
|
|
|
|
|
|
|
|
//
|
|
|
|
|
// Basic CPU information saved in Guided HOB.
|
|
|
|
|
// Because the contents will be shard between PEI and DXE,
|
|
|
|
|
// we need to make sure the each fields offset same in different
|
|
|
|
|
// architecture.
|
|
|
|
|
//
|
UefiCpuPkg/MpInitLib: support 64-bit AP stack addresses
The cached "CPU_INFO_IN_HOB.ApTopOfStack" field currently has type UINT32.
This is not ideal because the AP stacks are located within
"CpuMpData->Buffer", which is allocated with a plain AllocatePages() call
in MpInitLibInitialize():
platform CpuMpPei included PEI RAM > 4GB result
-------- ----------------- ------------- ------
Ia32 * n/a good
Ia32X64 no n/a BAD
Ia32X64 yes n/a good
X64 no * BAD
X64 yes no good
X64 yes yes BAD
- If we are on an Ia32X64 or X64 platform that does not include CpuMpPei,
then CpuDxe cannot reuse the CPU_INFO_IN_HOB structures preallocated by
CpuMpPei (through the CpuInitMpLib GUID HOB), and then AllocatePages()
-- invoked first in 64-bit DXE -- could return an address outside of
32-bit address space.
- If we are on an X64 platform where the permanent PEI RAM extends above
the 32-bit address space, then the same issue can surface even if
CpuMpPei is included: even the original allocation of the
CPU_INFO_IN_HOB structures, by CpuMpPei, could be satisfied from above
4GB.
The original "AP init" branch in "X64/MpFuncs.nasm" correctly considers a
64-bit stack start: the "MP_CPU_EXCHANGE_INFO.StackStart" field has type
UINTN, and the code uses QWORD addition and movement to set RSP from it.
Adapt the "GetApicId" branch of "X64/MpFuncs.nasm":
- change the type of "CPU_INFO_IN_HOB.ApTopOfStack" to UINT64,
- remove the explicit truncation to UINT32 in InitializeApData(),
- update the "GetNextProcNumber" iteration size to the new size of
"CPU_INFO_IN_HOB",
- set RSP with a QWORD movement from "CPU_INFO_IN_HOB.ApTopOfStack".
Because the same CPU_INFO_IN_HOB structure is used by "Ia32/MpFuncs.nasm",
we have to update the "GetNextProcNumber" iteration size there as well.
The ESP setting can be preserved as a DWORD movement from the original
offset (decimal 12), since our integers are little endian.
Cc: Jeff Fan <jeff.fan@intel.com>
Fixes: 845c5be1fd9bf7edfac4a103dfab70829686978f
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
2016-11-16 23:31:11 +01:00
|
|
|
#pragma pack (1)
|
2016-07-20 17:33:25 +02:00
|
|
|
typedef struct {
|
|
|
|
|
UINT32 InitialApicId;
|
|
|
|
|
UINT32 ApicId;
|
|
|
|
|
UINT32 Health;
|
UefiCpuPkg/MpInitLib: support 64-bit AP stack addresses
The cached "CPU_INFO_IN_HOB.ApTopOfStack" field currently has type UINT32.
This is not ideal because the AP stacks are located within
"CpuMpData->Buffer", which is allocated with a plain AllocatePages() call
in MpInitLibInitialize():
platform CpuMpPei included PEI RAM > 4GB result
-------- ----------------- ------------- ------
Ia32 * n/a good
Ia32X64 no n/a BAD
Ia32X64 yes n/a good
X64 no * BAD
X64 yes no good
X64 yes yes BAD
- If we are on an Ia32X64 or X64 platform that does not include CpuMpPei,
then CpuDxe cannot reuse the CPU_INFO_IN_HOB structures preallocated by
CpuMpPei (through the CpuInitMpLib GUID HOB), and then AllocatePages()
-- invoked first in 64-bit DXE -- could return an address outside of
32-bit address space.
- If we are on an X64 platform where the permanent PEI RAM extends above
the 32-bit address space, then the same issue can surface even if
CpuMpPei is included: even the original allocation of the
CPU_INFO_IN_HOB structures, by CpuMpPei, could be satisfied from above
4GB.
The original "AP init" branch in "X64/MpFuncs.nasm" correctly considers a
64-bit stack start: the "MP_CPU_EXCHANGE_INFO.StackStart" field has type
UINTN, and the code uses QWORD addition and movement to set RSP from it.
Adapt the "GetApicId" branch of "X64/MpFuncs.nasm":
- change the type of "CPU_INFO_IN_HOB.ApTopOfStack" to UINT64,
- remove the explicit truncation to UINT32 in InitializeApData(),
- update the "GetNextProcNumber" iteration size to the new size of
"CPU_INFO_IN_HOB",
- set RSP with a QWORD movement from "CPU_INFO_IN_HOB.ApTopOfStack".
Because the same CPU_INFO_IN_HOB structure is used by "Ia32/MpFuncs.nasm",
we have to update the "GetNextProcNumber" iteration size there as well.
The ESP setting can be preserved as a DWORD movement from the original
offset (decimal 12), since our integers are little endian.
Cc: Jeff Fan <jeff.fan@intel.com>
Fixes: 845c5be1fd9bf7edfac4a103dfab70829686978f
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
2016-11-16 23:31:11 +01:00
|
|
|
UINT64 ApTopOfStack;
|
2016-07-20 17:33:25 +02:00
|
|
|
} CPU_INFO_IN_HOB;
|
UefiCpuPkg/MpInitLib: support 64-bit AP stack addresses
The cached "CPU_INFO_IN_HOB.ApTopOfStack" field currently has type UINT32.
This is not ideal because the AP stacks are located within
"CpuMpData->Buffer", which is allocated with a plain AllocatePages() call
in MpInitLibInitialize():
platform CpuMpPei included PEI RAM > 4GB result
-------- ----------------- ------------- ------
Ia32 * n/a good
Ia32X64 no n/a BAD
Ia32X64 yes n/a good
X64 no * BAD
X64 yes no good
X64 yes yes BAD
- If we are on an Ia32X64 or X64 platform that does not include CpuMpPei,
then CpuDxe cannot reuse the CPU_INFO_IN_HOB structures preallocated by
CpuMpPei (through the CpuInitMpLib GUID HOB), and then AllocatePages()
-- invoked first in 64-bit DXE -- could return an address outside of
32-bit address space.
- If we are on an X64 platform where the permanent PEI RAM extends above
the 32-bit address space, then the same issue can surface even if
CpuMpPei is included: even the original allocation of the
CPU_INFO_IN_HOB structures, by CpuMpPei, could be satisfied from above
4GB.
The original "AP init" branch in "X64/MpFuncs.nasm" correctly considers a
64-bit stack start: the "MP_CPU_EXCHANGE_INFO.StackStart" field has type
UINTN, and the code uses QWORD addition and movement to set RSP from it.
Adapt the "GetApicId" branch of "X64/MpFuncs.nasm":
- change the type of "CPU_INFO_IN_HOB.ApTopOfStack" to UINT64,
- remove the explicit truncation to UINT32 in InitializeApData(),
- update the "GetNextProcNumber" iteration size to the new size of
"CPU_INFO_IN_HOB",
- set RSP with a QWORD movement from "CPU_INFO_IN_HOB.ApTopOfStack".
Because the same CPU_INFO_IN_HOB structure is used by "Ia32/MpFuncs.nasm",
we have to update the "GetNextProcNumber" iteration size there as well.
The ESP setting can be preserved as a DWORD movement from the original
offset (decimal 12), since our integers are little endian.
Cc: Jeff Fan <jeff.fan@intel.com>
Fixes: 845c5be1fd9bf7edfac4a103dfab70829686978f
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
2016-11-16 23:31:11 +01:00
|
|
|
#pragma pack ()
|
2016-07-20 17:33:25 +02:00
|
|
|
|
2016-07-20 16:56:09 +02:00
|
|
|
//
|
|
|
|
|
// AP reset code information including code address and size,
|
|
|
|
|
// this structure will be shared be C code and assembly code.
|
|
|
|
|
// It is natural aligned by design.
|
|
|
|
|
//
|
|
|
|
|
typedef struct {
|
|
|
|
|
UINT8 *RendezvousFunnelAddress;
|
|
|
|
|
UINTN ModeEntryOffset;
|
|
|
|
|
UINTN RendezvousFunnelSize;
|
2023-03-01 07:09:52 +01:00
|
|
|
UINT8 *RelocateApLoopFuncAddressGeneric;
|
|
|
|
|
UINTN RelocateApLoopFuncSizeGeneric;
|
2023-03-01 07:09:53 +01:00
|
|
|
UINT8 *RelocateApLoopFuncAddressAmdSev;
|
|
|
|
|
UINTN RelocateApLoopFuncSizeAmdSev;
|
2017-12-29 02:12:54 +01:00
|
|
|
UINTN ModeTransitionOffset;
|
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
|
|
|
UINTN SwitchToRealNoNxOffset;
|
|
|
|
|
UINTN SwitchToRealPM16ModeOffset;
|
|
|
|
|
UINTN SwitchToRealPM16ModeSize;
|
2016-07-20 16:56:09 +02:00
|
|
|
} MP_ASSEMBLY_ADDRESS_MAP;
|
2016-07-20 15:56:58 +02:00
|
|
|
|
2016-07-20 17:33:25 +02:00
|
|
|
typedef struct _CPU_MP_DATA CPU_MP_DATA;
|
|
|
|
|
|
2016-07-20 16:44:39 +02:00
|
|
|
#pragma pack(1)
|
|
|
|
|
|
|
|
|
|
//
|
|
|
|
|
// MP CPU exchange information for AP reset code
|
|
|
|
|
// This structure is required to be packed because fixed field offsets
|
|
|
|
|
// into this structure are used in assembly code in this module
|
|
|
|
|
//
|
|
|
|
|
typedef struct {
|
|
|
|
|
UINTN StackStart;
|
|
|
|
|
UINTN StackSize;
|
|
|
|
|
UINTN CFunction;
|
|
|
|
|
IA32_DESCRIPTOR GdtrProfile;
|
|
|
|
|
IA32_DESCRIPTOR IdtrProfile;
|
|
|
|
|
UINTN BufferStart;
|
|
|
|
|
UINTN ModeOffset;
|
2017-10-23 08:45:44 +02:00
|
|
|
UINTN ApIndex;
|
2016-07-20 16:44:39 +02:00
|
|
|
UINTN CodeSegment;
|
|
|
|
|
UINTN DataSegment;
|
2016-07-29 15:13:34 +02:00
|
|
|
UINTN EnableExecuteDisable;
|
2016-07-20 16:44:39 +02:00
|
|
|
UINTN Cr3;
|
2016-11-14 04:09:00 +01:00
|
|
|
UINTN InitFlag;
|
|
|
|
|
CPU_INFO_IN_HOB *CpuInfo;
|
2017-10-23 09:02:36 +02:00
|
|
|
UINTN NumApsExecuting;
|
2016-07-20 17:33:25 +02:00
|
|
|
CPU_MP_DATA *CpuMpData;
|
2017-05-17 21:19:16 +02:00
|
|
|
UINTN InitializeFloatingPointUnitsAddress;
|
2017-12-29 02:12:54 +01:00
|
|
|
UINT32 ModeTransitionMemory;
|
|
|
|
|
UINT16 ModeTransitionSegment;
|
|
|
|
|
UINT32 ModeHighMemory;
|
|
|
|
|
UINT16 ModeHighSegment;
|
2019-08-01 11:58:24 +02:00
|
|
|
//
|
|
|
|
|
// Enable5LevelPaging indicates whether 5-level paging is enabled in long mode.
|
|
|
|
|
//
|
|
|
|
|
BOOLEAN Enable5LevelPaging;
|
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
|
|
|
BOOLEAN SevEsIsEnabled;
|
2021-12-09 04:27:54 +01:00
|
|
|
BOOLEAN SevSnpIsEnabled;
|
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
|
|
|
UINTN GhcbBase;
|
UefiCpuPkg/MpInitLib: use BSP to do extended topology check
During AP bringup, just after switching to long mode, APs will do some
cpuid calls to verify that the extended topology leaf (0xB) is available
so they can fetch their x2 APIC IDs from it. In the case of SEV-ES,
these cpuid instructions must be handled by direct use of the GHCB MSR
protocol to fetch the values from the hypervisor, since a #VC handler
is not yet available due to the AP's stack not being set up yet.
For SEV-SNP, rather than relying on the GHCB MSR protocol, it is
expected that these values would be obtained from the SEV-SNP CPUID
table instead. The actual x2 APIC ID (and 8-bit APIC IDs) would still
be fetched from hypervisor using the GHCB MSR protocol however, so
introducing support for the SEV-SNP CPUID table in that part of the AP
bring-up code would only be to handle the checks/validation of the
extended topology leaf.
Rather than introducing all the added complexity needed to handle these
checks via the CPUID table, instead let the BSP do the check in advance,
since it can make use of the #VC handler to avoid the need to scan the
SNP CPUID table directly, and add a flag in ExchangeInfo to communicate
the result of this check to APs.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ray Ni <ray.ni@intel.com>
Suggested-by: Brijesh Singh <brijesh.singh@amd.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
2021-12-09 04:27:55 +01:00
|
|
|
BOOLEAN ExtTopoAvail;
|
2016-07-20 16:44:39 +02:00
|
|
|
} MP_CPU_EXCHANGE_INFO;
|
|
|
|
|
|
|
|
|
|
#pragma pack()
|
2016-07-20 17:33:25 +02:00
|
|
|
|
|
|
|
|
//
|
|
|
|
|
// CPU MP Data save in memory
|
|
|
|
|
//
|
|
|
|
|
struct _CPU_MP_DATA {
|
|
|
|
|
UINT64 CpuInfoInHob;
|
|
|
|
|
UINT32 CpuCount;
|
|
|
|
|
UINT32 BspNumber;
|
|
|
|
|
//
|
|
|
|
|
// The above fields data will be passed from PEI to DXE
|
|
|
|
|
// Please make sure the fields offset same in the different
|
|
|
|
|
// architecture.
|
|
|
|
|
//
|
|
|
|
|
SPIN_LOCK MpLock;
|
|
|
|
|
UINTN Buffer;
|
|
|
|
|
UINTN CpuApStackSize;
|
|
|
|
|
MP_ASSEMBLY_ADDRESS_MAP AddressMap;
|
|
|
|
|
UINTN WakeupBuffer;
|
2018-01-24 02:36:01 +01:00
|
|
|
UINTN WakeupBufferHigh;
|
2016-07-20 17:33:25 +02:00
|
|
|
UINTN BackupBuffer;
|
|
|
|
|
UINTN BackupBufferSize;
|
2021-12-05 23:54:17 +01:00
|
|
|
|
2016-07-20 17:33:25 +02:00
|
|
|
volatile UINT32 FinishedCount;
|
UefiCpuPkg/MpInitLib: Remove StartCount and volatile definition.
The patch includes below changes:
(1) It removes "volatile" from RunningCount, because only the BSP modifies it.
(2) When we detect a timeout in CheckAllAPs(), and collect the list of failed CPUs, the size of the list is derived from the following difference, before the patch:
StartCount - FinishedCount
where "StartCount" is set by the BSP at startup, and FinishedCount is incremented by the APs themselves.
Here the patch replaces this difference with
StartCount - RunningCount
that is, the difference is no more calculated from the BSP's startup counter and the AP's shared finish counter, but from the RunningCount measurement that the BSP does itself, in CheckAllAPs().
(3) Finally, the patch changes the meaning of RunningCount. Before the patch, we have:
- StartCount: the number of APs the BSP stars up,
- RunningCount: the number of finished APs that the BSP collected
After the patch, StartCount is removed, and RunningCount is *redefined* as the following difference:
OLD_StartCount - OLD_RunningCount
Giving the number of APs that the BSP started up but hasn't collected yet.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
2018-07-24 16:29:53 +02:00
|
|
|
UINT32 RunningCount;
|
2016-07-20 17:33:25 +02:00
|
|
|
BOOLEAN SingleThread;
|
|
|
|
|
EFI_AP_PROCEDURE Procedure;
|
|
|
|
|
VOID *ProcArguments;
|
|
|
|
|
BOOLEAN *Finished;
|
|
|
|
|
UINT64 ExpectedTime;
|
|
|
|
|
UINT64 CurrentTime;
|
|
|
|
|
UINT64 TotalTime;
|
|
|
|
|
EFI_EVENT WaitEvent;
|
|
|
|
|
UINTN **FailedCpuList;
|
2021-12-05 23:54:17 +01:00
|
|
|
|
2016-07-20 17:33:25 +02:00
|
|
|
AP_INIT_STATE InitFlag;
|
2016-07-21 15:20:18 +02:00
|
|
|
BOOLEAN SwitchBspFlag;
|
2016-11-14 04:43:26 +01:00
|
|
|
UINTN NewBspNumber;
|
2016-07-21 15:20:18 +02:00
|
|
|
CPU_EXCHANGE_ROLE_INFO BSPInfo;
|
|
|
|
|
CPU_EXCHANGE_ROLE_INFO APInfo;
|
2016-07-20 17:33:25 +02:00
|
|
|
MTRR_SETTINGS MtrrTable;
|
|
|
|
|
UINT8 ApLoopMode;
|
|
|
|
|
UINT8 ApTargetCState;
|
|
|
|
|
UINT16 PmCodeSegment;
|
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
|
|
|
UINT16 Pm16CodeSegment;
|
2016-07-20 17:33:25 +02:00
|
|
|
CPU_AP_DATA *CpuData;
|
|
|
|
|
volatile MP_CPU_EXCHANGE_INFO *MpCpuExchangeInfo;
|
2021-12-05 23:54:17 +01:00
|
|
|
|
2016-12-26 09:44:24 +01:00
|
|
|
UINT32 CurrentTimerCount;
|
|
|
|
|
UINTN DivideValue;
|
|
|
|
|
UINT8 Vector;
|
|
|
|
|
BOOLEAN PeriodicMode;
|
|
|
|
|
BOOLEAN TimerInterruptState;
|
2020-01-16 02:30:12 +01:00
|
|
|
UINT64 MicrocodePatchAddress;
|
|
|
|
|
UINT64 MicrocodePatchRegionSize;
|
2018-07-11 13:07:28 +02:00
|
|
|
|
2018-06-27 10:42:51 +02:00
|
|
|
//
|
|
|
|
|
// Whether need to use Init-Sipi-Sipi to wake up the APs.
|
|
|
|
|
// Two cases need to set this value to TRUE. One is in HLT
|
|
|
|
|
// loop mode, the other is resume from S3 which loop mode
|
2018-09-05 08:22:18 +02:00
|
|
|
// will be hardcode change to HLT mode by PiSmmCpuDxeSmm
|
2018-06-27 10:42:51 +02:00
|
|
|
// driver.
|
|
|
|
|
//
|
|
|
|
|
BOOLEAN WakeUpByInitSipiSipi;
|
2020-08-12 22:21:42 +02:00
|
|
|
|
|
|
|
|
BOOLEAN SevEsIsEnabled;
|
2021-12-09 04:27:54 +01:00
|
|
|
BOOLEAN SevSnpIsEnabled;
|
2021-12-09 04:28:00 +01:00
|
|
|
BOOLEAN UseSevEsAPMethod;
|
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
|
|
|
UINTN SevEsAPBuffer;
|
|
|
|
|
UINTN SevEsAPResetStackStart;
|
|
|
|
|
CPU_MP_DATA *NewCpuMpData;
|
|
|
|
|
|
|
|
|
|
UINT64 GhcbBase;
|
2016-07-20 17:33:25 +02:00
|
|
|
};
|
2016-07-21 10:08:12 +02:00
|
|
|
|
2022-08-19 08:17:28 +02:00
|
|
|
//
|
|
|
|
|
// AP_STACK_DATA is stored at the top of each AP stack.
|
|
|
|
|
//
|
|
|
|
|
typedef struct {
|
|
|
|
|
UINTN Bist;
|
|
|
|
|
CPU_MP_DATA *MpData;
|
|
|
|
|
} AP_STACK_DATA;
|
|
|
|
|
|
2020-08-12 22:21:43 +02:00
|
|
|
#define AP_SAFE_STACK_SIZE 128
|
|
|
|
|
#define AP_RESET_STACK_SIZE AP_SAFE_STACK_SIZE
|
2023-03-01 07:09:47 +01:00
|
|
|
STATIC_ASSERT ((AP_SAFE_STACK_SIZE & (CPU_STACK_ALIGNMENT - 1)) == 0, "AP_SAFE_STACK_SIZE is not aligned with CPU_STACK_ALIGNMENT");
|
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
|
|
|
|
|
|
|
|
#pragma pack(1)
|
|
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
|
UINT8 InsnBuffer[8];
|
|
|
|
|
UINT16 Rip;
|
|
|
|
|
UINT16 Segment;
|
|
|
|
|
} SEV_ES_AP_JMP_FAR;
|
|
|
|
|
|
|
|
|
|
#pragma pack()
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
Assembly code to move an AP from long mode to real mode.
|
|
|
|
|
|
|
|
|
|
Move an AP from long mode to real mode in preparation to invoking
|
|
|
|
|
the reset vector. This is used for SEV-ES guests where a hypervisor
|
|
|
|
|
is not allowed to set the CS and RIP to point to the reset vector.
|
|
|
|
|
|
|
|
|
|
@param[in] BufferStart The reset vector target.
|
|
|
|
|
@param[in] Code16 16-bit protected mode code segment value.
|
|
|
|
|
@param[in] Code32 32-bit protected mode code segment value.
|
|
|
|
|
@param[in] StackStart The start of a stack to be used for transitioning
|
|
|
|
|
from long mode to real mode.
|
|
|
|
|
**/
|
|
|
|
|
typedef
|
2021-12-09 04:27:30 +01:00
|
|
|
VOID
|
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
|
|
|
(EFIAPI AP_RESET)(
|
|
|
|
|
IN UINTN BufferStart,
|
|
|
|
|
IN UINT16 Code16,
|
|
|
|
|
IN UINT16 Code32,
|
|
|
|
|
IN UINTN StackStart
|
|
|
|
|
);
|
|
|
|
|
|
2016-07-21 10:08:12 +02:00
|
|
|
extern EFI_GUID mCpuInitMpLibHobGuid;
|
|
|
|
|
|
2016-07-20 16:47:47 +02:00
|
|
|
/**
|
|
|
|
|
Assembly code to place AP into safe loop mode.
|
|
|
|
|
|
|
|
|
|
Place AP into targeted C-State if MONITOR is supported, otherwise
|
|
|
|
|
place AP into hlt state.
|
|
|
|
|
Place AP in protected mode if the current is long mode. Due to AP maybe
|
|
|
|
|
wakeup by some hardware event. It could avoid accessing page table that
|
|
|
|
|
may not available during booting to OS.
|
|
|
|
|
|
|
|
|
|
@param[in] MwaitSupport TRUE indicates MONITOR is supported.
|
|
|
|
|
FALSE indicates MONITOR is not supported.
|
|
|
|
|
@param[in] ApTargetCState Target C-State value.
|
|
|
|
|
@param[in] PmCodeSegment Protected mode code segment value.
|
|
|
|
|
**/
|
2023-03-01 07:09:52 +01:00
|
|
|
typedef
|
|
|
|
|
VOID
|
|
|
|
|
(EFIAPI *ASM_RELOCATE_AP_LOOP_GENERIC)(
|
|
|
|
|
IN BOOLEAN MwaitSupport,
|
|
|
|
|
IN UINTN ApTargetCState,
|
|
|
|
|
IN UINTN TopOfApStack,
|
|
|
|
|
IN UINTN NumberToFinish,
|
|
|
|
|
IN UINTN Cr3
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
Assembly code to place AP into safe loop mode for Amd processors
|
|
|
|
|
with Sev enabled.
|
|
|
|
|
Place AP into targeted C-State if MONITOR is supported, otherwise
|
|
|
|
|
place AP into hlt state.
|
|
|
|
|
Place AP in protected mode if the current is long mode. Due to AP maybe
|
|
|
|
|
wakeup by some hardware event. It could avoid accessing page table that
|
|
|
|
|
may not available during booting to OS.
|
|
|
|
|
@param[in] MwaitSupport TRUE indicates MONITOR is supported.
|
|
|
|
|
FALSE indicates MONITOR is not supported.
|
|
|
|
|
@param[in] ApTargetCState Target C-State value.
|
|
|
|
|
@param[in] PmCodeSegment Protected mode code segment value.
|
|
|
|
|
**/
|
2016-07-20 16:47:47 +02:00
|
|
|
typedef
|
2021-12-09 04:27:30 +01:00
|
|
|
VOID
|
2023-03-01 07:09:53 +01:00
|
|
|
(EFIAPI *ASM_RELOCATE_AP_LOOP_AMDSEV)(
|
2016-07-20 16:47:47 +02:00
|
|
|
IN BOOLEAN MwaitSupport,
|
|
|
|
|
IN UINTN ApTargetCState,
|
2023-01-09 04:37:21 +01:00
|
|
|
IN UINTN PmCodeSegment,
|
2016-11-25 06:18:57 +01:00
|
|
|
IN UINTN TopOfApStack,
|
2020-08-12 22:21:43 +02:00
|
|
|
IN UINTN NumberToFinish,
|
2023-01-09 04:37:21 +01:00
|
|
|
IN UINTN Pm16CodeSegment,
|
|
|
|
|
IN UINTN SevEsAPJumpTable,
|
|
|
|
|
IN UINTN WakeupBuffer
|
2016-07-20 16:47:47 +02:00
|
|
|
);
|
2016-07-20 16:56:09 +02:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
Assembly code to get starting address and size of the rendezvous entry for APs.
|
|
|
|
|
Information for fixing a jump instruction in the code is also returned.
|
|
|
|
|
|
|
|
|
|
@param[out] AddressMap Output buffer for address map information.
|
|
|
|
|
**/
|
|
|
|
|
VOID
|
|
|
|
|
EFIAPI
|
|
|
|
|
AsmGetAddressMap (
|
|
|
|
|
OUT MP_ASSEMBLY_ADDRESS_MAP *AddressMap
|
|
|
|
|
);
|
|
|
|
|
|
2016-07-21 15:20:18 +02:00
|
|
|
/**
|
|
|
|
|
This function is called by both the BSP and the AP which is to become the BSP to
|
|
|
|
|
Exchange execution context including stack between them. After return from this
|
|
|
|
|
function, the BSP becomes AP and the AP becomes the BSP.
|
|
|
|
|
|
|
|
|
|
@param[in] MyInfo Pointer to buffer holding the exchanging information for the executing processor.
|
|
|
|
|
@param[in] OthersInfo Pointer to buffer holding the exchanging information for the peer.
|
|
|
|
|
|
|
|
|
|
**/
|
|
|
|
|
VOID
|
|
|
|
|
EFIAPI
|
|
|
|
|
AsmExchangeRole (
|
|
|
|
|
IN CPU_EXCHANGE_ROLE_INFO *MyInfo,
|
|
|
|
|
IN CPU_EXCHANGE_ROLE_INFO *OthersInfo
|
|
|
|
|
);
|
|
|
|
|
|
2023-03-01 07:09:48 +01:00
|
|
|
typedef union {
|
2023-03-01 07:09:52 +01:00
|
|
|
VOID *Data;
|
2023-03-01 07:09:53 +01:00
|
|
|
ASM_RELOCATE_AP_LOOP_AMDSEV AmdSevEntry; // 64-bit AMD Sev processors
|
2023-03-01 07:09:52 +01:00
|
|
|
ASM_RELOCATE_AP_LOOP_GENERIC GenericEntry; // Intel processors (32-bit or 64-bit), 32-bit AMD processors, or AMD non-Sev processors
|
2023-03-01 07:09:48 +01:00
|
|
|
} RELOCATE_AP_LOOP_ENTRY;
|
|
|
|
|
|
2016-07-21 10:08:12 +02:00
|
|
|
/**
|
|
|
|
|
Get the pointer to CPU MP Data structure.
|
|
|
|
|
|
|
|
|
|
@return The pointer to CPU MP Data structure.
|
|
|
|
|
**/
|
|
|
|
|
CPU_MP_DATA *
|
|
|
|
|
GetCpuMpData (
|
|
|
|
|
VOID
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
Save the pointer to CPU MP Data structure.
|
|
|
|
|
|
|
|
|
|
@param[in] CpuMpData The pointer to CPU MP Data structure will be saved.
|
|
|
|
|
**/
|
|
|
|
|
VOID
|
|
|
|
|
SaveCpuMpData (
|
|
|
|
|
IN CPU_MP_DATA *CpuMpData
|
|
|
|
|
);
|
|
|
|
|
|
2016-07-24 16:19:09 +02:00
|
|
|
/**
|
2017-08-04 04:05:20 +02:00
|
|
|
Get available system memory below 1MB by specified size.
|
2016-07-24 16:19:09 +02:00
|
|
|
|
2017-08-04 04:05:20 +02:00
|
|
|
@param[in] WakeupBufferSize Wakeup buffer size required
|
|
|
|
|
|
|
|
|
|
@retval other Return wakeup buffer address below 1MB.
|
|
|
|
|
@retval -1 Cannot find free memory below 1MB.
|
2016-07-24 16:19:09 +02:00
|
|
|
**/
|
2017-08-04 04:05:20 +02:00
|
|
|
UINTN
|
|
|
|
|
GetWakeupBuffer (
|
|
|
|
|
IN UINTN WakeupBufferSize
|
2016-07-24 16:19:09 +02:00
|
|
|
);
|
|
|
|
|
|
2023-06-28 10:47:24 +02:00
|
|
|
/**
|
|
|
|
|
Switch Context for each AP.
|
|
|
|
|
|
|
|
|
|
**/
|
|
|
|
|
VOID
|
|
|
|
|
SwitchApContext (
|
|
|
|
|
IN MP_HAND_OFF *MpHandOff
|
|
|
|
|
);
|
|
|
|
|
|
2017-12-29 02:12:54 +01:00
|
|
|
/**
|
|
|
|
|
Get available EfiBootServicesCode memory below 4GB by specified size.
|
|
|
|
|
|
|
|
|
|
This buffer is required to safely transfer AP from real address mode to
|
|
|
|
|
protected mode or long mode, due to the fact that the buffer returned by
|
|
|
|
|
GetWakeupBuffer() may be marked as non-executable.
|
|
|
|
|
|
|
|
|
|
@param[in] BufferSize Wakeup transition buffer size.
|
|
|
|
|
|
|
|
|
|
@retval other Return wakeup transition buffer address below 4GB.
|
|
|
|
|
@retval 0 Cannot find free memory below 4GB.
|
|
|
|
|
**/
|
|
|
|
|
UINTN
|
2022-05-07 11:10:49 +02:00
|
|
|
AllocateCodeBuffer (
|
2017-12-29 02:12:54 +01:00
|
|
|
IN UINTN BufferSize
|
|
|
|
|
);
|
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
|
Return the address of the SEV-ES AP jump table.
|
|
|
|
|
|
|
|
|
|
This buffer is required in order for an SEV-ES guest to transition from
|
|
|
|
|
UEFI into an OS.
|
|
|
|
|
|
|
|
|
|
@return Return SEV-ES AP jump table buffer
|
|
|
|
|
**/
|
|
|
|
|
UINTN
|
|
|
|
|
GetSevEsAPMemory (
|
|
|
|
|
VOID
|
|
|
|
|
);
|
|
|
|
|
|
2023-03-01 07:09:52 +01:00
|
|
|
/**
|
|
|
|
|
Create 1:1 mapping page table in reserved memory to map the specified address range.
|
|
|
|
|
@param[in] LinearAddress The start of the linear address range.
|
|
|
|
|
@param[in] Length The length of the linear address range.
|
|
|
|
|
@return The page table to be created.
|
|
|
|
|
**/
|
|
|
|
|
UINTN
|
|
|
|
|
CreatePageTable (
|
|
|
|
|
IN UINTN Address,
|
|
|
|
|
IN UINTN Length
|
|
|
|
|
);
|
|
|
|
|
|
2016-07-20 18:23:52 +02:00
|
|
|
/**
|
|
|
|
|
This function will be called by BSP to wakeup AP.
|
|
|
|
|
|
|
|
|
|
@param[in] CpuMpData Pointer to CPU MP Data
|
|
|
|
|
@param[in] Broadcast TRUE: Send broadcast IPI to all APs
|
|
|
|
|
FALSE: Send IPI to AP by ApicId
|
|
|
|
|
@param[in] ProcessorNumber The handle number of specified processor
|
|
|
|
|
@param[in] Procedure The function to be invoked by AP
|
|
|
|
|
@param[in] ProcedureArgument The argument to be passed into AP function
|
2018-07-26 10:44:22 +02:00
|
|
|
@param[in] WakeUpDisabledAps Whether need to wake up disabled APs in broadcast mode.
|
2016-07-20 18:23:52 +02:00
|
|
|
**/
|
|
|
|
|
VOID
|
|
|
|
|
WakeUpAP (
|
|
|
|
|
IN CPU_MP_DATA *CpuMpData,
|
|
|
|
|
IN BOOLEAN Broadcast,
|
|
|
|
|
IN UINTN ProcessorNumber,
|
2021-12-03 03:01:00 +01:00
|
|
|
IN EFI_AP_PROCEDURE Procedure OPTIONAL,
|
|
|
|
|
IN VOID *ProcedureArgument OPTIONAL,
|
2022-03-10 09:06:25 +01:00
|
|
|
IN BOOLEAN WakeUpDisabledAps
|
2016-07-20 18:23:52 +02:00
|
|
|
);
|
|
|
|
|
|
2016-07-21 10:08:12 +02:00
|
|
|
/**
|
|
|
|
|
Initialize global data for MP support.
|
|
|
|
|
|
|
|
|
|
@param[in] CpuMpData The pointer to CPU MP Data structure.
|
|
|
|
|
**/
|
|
|
|
|
VOID
|
|
|
|
|
InitMpGlobalData (
|
|
|
|
|
IN CPU_MP_DATA *CpuMpData
|
|
|
|
|
);
|
|
|
|
|
|
2016-07-21 15:33:11 +02:00
|
|
|
/**
|
|
|
|
|
Worker function to execute a caller provided function on all enabled APs.
|
|
|
|
|
|
|
|
|
|
@param[in] Procedure A pointer to the function to be run on
|
|
|
|
|
enabled APs of the system.
|
|
|
|
|
@param[in] SingleThread If TRUE, then all the enabled APs execute
|
|
|
|
|
the function specified by Procedure one by
|
|
|
|
|
one, in ascending order of processor handle
|
|
|
|
|
number. If FALSE, then all the enabled APs
|
|
|
|
|
execute the function specified by Procedure
|
|
|
|
|
simultaneously.
|
2019-04-10 05:00:43 +02:00
|
|
|
@param[in] ExcludeBsp Whether let BSP also trig this task.
|
2016-07-21 15:33:11 +02:00
|
|
|
@param[in] WaitEvent The event created by the caller with CreateEvent()
|
|
|
|
|
service.
|
2016-12-13 03:46:28 +01:00
|
|
|
@param[in] TimeoutInMicroseconds Indicates the time limit in microseconds for
|
2016-07-21 15:33:11 +02:00
|
|
|
APs to return from Procedure, either for
|
|
|
|
|
blocking or non-blocking mode.
|
|
|
|
|
@param[in] ProcedureArgument The parameter passed into Procedure for
|
|
|
|
|
all APs.
|
|
|
|
|
@param[out] FailedCpuList If all APs finish successfully, then its
|
|
|
|
|
content is set to NULL. If not all APs
|
|
|
|
|
finish before timeout expires, then its
|
|
|
|
|
content is set to address of the buffer
|
|
|
|
|
holding handle numbers of the failed APs.
|
|
|
|
|
|
|
|
|
|
@retval EFI_SUCCESS In blocking mode, all APs have finished before
|
|
|
|
|
the timeout expired.
|
|
|
|
|
@retval EFI_SUCCESS In non-blocking mode, function has been dispatched
|
|
|
|
|
to all enabled APs.
|
|
|
|
|
@retval others Failed to Startup all APs.
|
|
|
|
|
|
|
|
|
|
**/
|
|
|
|
|
EFI_STATUS
|
2019-04-10 05:00:43 +02:00
|
|
|
StartupAllCPUsWorker (
|
2016-07-21 15:33:11 +02:00
|
|
|
IN EFI_AP_PROCEDURE Procedure,
|
|
|
|
|
IN BOOLEAN SingleThread,
|
2019-04-10 05:00:43 +02:00
|
|
|
IN BOOLEAN ExcludeBsp,
|
2016-07-21 15:33:11 +02:00
|
|
|
IN EFI_EVENT WaitEvent OPTIONAL,
|
|
|
|
|
IN UINTN TimeoutInMicroseconds,
|
|
|
|
|
IN VOID *ProcedureArgument OPTIONAL,
|
|
|
|
|
OUT UINTN **FailedCpuList OPTIONAL
|
|
|
|
|
);
|
|
|
|
|
|
2016-07-21 15:31:47 +02:00
|
|
|
/**
|
|
|
|
|
Worker function to let the caller get one enabled AP to execute a caller-provided
|
|
|
|
|
function.
|
|
|
|
|
|
|
|
|
|
@param[in] Procedure A pointer to the function to be run on
|
|
|
|
|
enabled APs of the system.
|
|
|
|
|
@param[in] ProcessorNumber The handle number of the AP.
|
|
|
|
|
@param[in] WaitEvent The event created by the caller with CreateEvent()
|
|
|
|
|
service.
|
2016-12-13 03:46:28 +01:00
|
|
|
@param[in] TimeoutInMicroseconds Indicates the time limit in microseconds for
|
2016-07-21 15:31:47 +02:00
|
|
|
APs to return from Procedure, either for
|
|
|
|
|
blocking or non-blocking mode.
|
|
|
|
|
@param[in] ProcedureArgument The parameter passed into Procedure for
|
|
|
|
|
all APs.
|
|
|
|
|
@param[out] Finished If AP returns from Procedure before the
|
|
|
|
|
timeout expires, its content is set to TRUE.
|
|
|
|
|
Otherwise, the value is set to FALSE.
|
|
|
|
|
|
|
|
|
|
@retval EFI_SUCCESS In blocking mode, specified AP finished before
|
|
|
|
|
the timeout expires.
|
|
|
|
|
@retval others Failed to Startup AP.
|
|
|
|
|
|
|
|
|
|
**/
|
|
|
|
|
EFI_STATUS
|
|
|
|
|
StartupThisAPWorker (
|
|
|
|
|
IN EFI_AP_PROCEDURE Procedure,
|
|
|
|
|
IN UINTN ProcessorNumber,
|
|
|
|
|
IN EFI_EVENT WaitEvent OPTIONAL,
|
|
|
|
|
IN UINTN TimeoutInMicroseconds,
|
|
|
|
|
IN VOID *ProcedureArgument OPTIONAL,
|
|
|
|
|
OUT BOOLEAN *Finished OPTIONAL
|
|
|
|
|
);
|
|
|
|
|
|
2016-07-21 15:20:18 +02:00
|
|
|
/**
|
|
|
|
|
Worker function to switch the requested AP to be the BSP from that point onward.
|
|
|
|
|
|
|
|
|
|
@param[in] ProcessorNumber The handle number of AP that is to become the new BSP.
|
|
|
|
|
@param[in] EnableOldBSP If TRUE, then the old BSP will be listed as an
|
|
|
|
|
enabled AP. Otherwise, it will be disabled.
|
|
|
|
|
|
|
|
|
|
@retval EFI_SUCCESS BSP successfully switched.
|
2018-06-27 15:14:20 +02:00
|
|
|
@retval others Failed to switch BSP.
|
2016-07-21 15:20:18 +02:00
|
|
|
|
|
|
|
|
**/
|
|
|
|
|
EFI_STATUS
|
|
|
|
|
SwitchBSPWorker (
|
|
|
|
|
IN UINTN ProcessorNumber,
|
|
|
|
|
IN BOOLEAN EnableOldBSP
|
|
|
|
|
);
|
|
|
|
|
|
2016-07-21 15:23:05 +02:00
|
|
|
/**
|
|
|
|
|
Worker function to let the caller enable or disable an AP from this point onward.
|
|
|
|
|
This service may only be called from the BSP.
|
|
|
|
|
|
|
|
|
|
@param[in] ProcessorNumber The handle number of AP.
|
|
|
|
|
@param[in] EnableAP Specifies the new state for the processor for
|
|
|
|
|
enabled, FALSE for disabled.
|
|
|
|
|
@param[in] HealthFlag If not NULL, a pointer to a value that specifies
|
|
|
|
|
the new health status of the AP.
|
|
|
|
|
|
|
|
|
|
@retval EFI_SUCCESS The specified AP was enabled or disabled successfully.
|
|
|
|
|
@retval others Failed to Enable/Disable AP.
|
|
|
|
|
|
|
|
|
|
**/
|
|
|
|
|
EFI_STATUS
|
|
|
|
|
EnableDisableApWorker (
|
|
|
|
|
IN UINTN ProcessorNumber,
|
|
|
|
|
IN BOOLEAN EnableAP,
|
|
|
|
|
IN UINT32 *HealthFlag OPTIONAL
|
|
|
|
|
);
|
|
|
|
|
|
2016-07-21 10:08:12 +02:00
|
|
|
/**
|
|
|
|
|
Get pointer to CPU MP Data structure from GUIDed HOB.
|
|
|
|
|
|
|
|
|
|
@return The pointer to CPU MP Data structure.
|
|
|
|
|
**/
|
|
|
|
|
CPU_MP_DATA *
|
|
|
|
|
GetCpuMpDataFromGuidedHob (
|
|
|
|
|
VOID
|
|
|
|
|
);
|
2016-07-21 15:28:16 +02:00
|
|
|
|
|
|
|
|
/** Checks status of specified AP.
|
|
|
|
|
|
|
|
|
|
This function checks whether the specified AP has finished the task assigned
|
|
|
|
|
by StartupThisAP(), and whether timeout expires.
|
|
|
|
|
|
|
|
|
|
@param[in] ProcessorNumber The handle number of processor.
|
|
|
|
|
|
|
|
|
|
@retval EFI_SUCCESS Specified AP has finished task assigned by StartupThisAPs().
|
|
|
|
|
@retval EFI_TIMEOUT The timeout expires.
|
|
|
|
|
@retval EFI_NOT_READY Specified AP has not finished task and timeout has not expired.
|
|
|
|
|
**/
|
|
|
|
|
EFI_STATUS
|
|
|
|
|
CheckThisAP (
|
|
|
|
|
IN UINTN ProcessorNumber
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
Checks status of all APs.
|
|
|
|
|
|
|
|
|
|
This function checks whether all APs have finished task assigned by StartupAllAPs(),
|
|
|
|
|
and whether timeout expires.
|
|
|
|
|
|
|
|
|
|
@retval EFI_SUCCESS All APs have finished task assigned by StartupAllAPs().
|
|
|
|
|
@retval EFI_TIMEOUT The timeout expires.
|
|
|
|
|
@retval EFI_NOT_READY APs have not finished task and timeout has not expired.
|
|
|
|
|
**/
|
|
|
|
|
EFI_STATUS
|
|
|
|
|
CheckAllAPs (
|
|
|
|
|
VOID
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
Checks APs status and updates APs status if needed.
|
|
|
|
|
|
|
|
|
|
**/
|
|
|
|
|
VOID
|
|
|
|
|
CheckAndUpdateApsStatus (
|
|
|
|
|
VOID
|
|
|
|
|
);
|
|
|
|
|
|
2016-07-20 17:49:35 +02:00
|
|
|
/**
|
|
|
|
|
Detect whether specified processor can find matching microcode patch and load it.
|
|
|
|
|
|
2019-12-23 07:32:49 +01:00
|
|
|
@param[in] CpuMpData The pointer to CPU MP Data structure.
|
|
|
|
|
@param[in] ProcessorNumber The handle number of the processor. The range is
|
|
|
|
|
from 0 to the total number of logical processors
|
|
|
|
|
minus 1.
|
2016-07-20 17:49:35 +02:00
|
|
|
**/
|
|
|
|
|
VOID
|
|
|
|
|
MicrocodeDetect (
|
2018-07-11 13:07:28 +02:00
|
|
|
IN CPU_MP_DATA *CpuMpData,
|
2019-12-23 07:32:49 +01:00
|
|
|
IN UINTN ProcessorNumber
|
2016-07-20 17:49:35 +02:00
|
|
|
);
|
|
|
|
|
|
2019-12-19 07:33:44 +01:00
|
|
|
/**
|
2020-01-08 04:22:30 +01:00
|
|
|
Shadow the required microcode patches data into memory.
|
2019-12-19 07:33:44 +01:00
|
|
|
|
|
|
|
|
@param[in, out] CpuMpData The pointer to CPU MP Data structure.
|
|
|
|
|
**/
|
|
|
|
|
VOID
|
2020-01-08 04:22:30 +01:00
|
|
|
ShadowMicrocodeUpdatePatch (
|
2019-12-19 07:33:44 +01:00
|
|
|
IN OUT CPU_MP_DATA *CpuMpData
|
|
|
|
|
);
|
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
|
Get the cached microcode patch base address and size from the microcode patch
|
|
|
|
|
information cache HOB.
|
|
|
|
|
|
|
|
|
|
@param[out] Address Base address of the microcode patches data.
|
|
|
|
|
It will be updated if the microcode patch
|
|
|
|
|
information cache HOB is found.
|
|
|
|
|
@param[out] RegionSize Size of the microcode patches data.
|
|
|
|
|
It will be updated if the microcode patch
|
|
|
|
|
information cache HOB is found.
|
|
|
|
|
|
|
|
|
|
@retval TRUE The microcode patch information cache HOB is found.
|
|
|
|
|
@retval FALSE The microcode patch information cache HOB is not found.
|
|
|
|
|
|
|
|
|
|
**/
|
|
|
|
|
BOOLEAN
|
|
|
|
|
GetMicrocodePatchInfoFromHob (
|
|
|
|
|
UINT64 *Address,
|
|
|
|
|
UINT64 *RegionSize
|
|
|
|
|
);
|
|
|
|
|
|
2016-07-24 17:03:12 +02:00
|
|
|
/**
|
|
|
|
|
Detect whether Mwait-monitor feature is supported.
|
|
|
|
|
|
|
|
|
|
@retval TRUE Mwait-monitor feature is supported.
|
|
|
|
|
@retval FALSE Mwait-monitor feature is not supported.
|
|
|
|
|
**/
|
|
|
|
|
BOOLEAN
|
|
|
|
|
IsMwaitSupport (
|
|
|
|
|
VOID
|
|
|
|
|
);
|
|
|
|
|
|
2016-12-26 09:28:58 +01:00
|
|
|
/**
|
|
|
|
|
Enable Debug Agent to support source debugging on AP function.
|
|
|
|
|
|
|
|
|
|
**/
|
|
|
|
|
VOID
|
|
|
|
|
EnableDebugAgent (
|
|
|
|
|
VOID
|
|
|
|
|
);
|
|
|
|
|
|
2019-12-23 07:32:49 +01:00
|
|
|
/**
|
|
|
|
|
Find the current Processor number by APIC ID.
|
|
|
|
|
|
|
|
|
|
@param[in] CpuMpData Pointer to PEI CPU MP Data
|
|
|
|
|
@param[out] ProcessorNumber Return the pocessor number found
|
|
|
|
|
|
|
|
|
|
@retval EFI_SUCCESS ProcessorNumber is found and returned.
|
|
|
|
|
@retval EFI_NOT_FOUND ProcessorNumber is not found.
|
|
|
|
|
**/
|
|
|
|
|
EFI_STATUS
|
|
|
|
|
GetProcessorNumber (
|
|
|
|
|
IN CPU_MP_DATA *CpuMpData,
|
|
|
|
|
OUT UINTN *ProcessorNumber
|
|
|
|
|
);
|
|
|
|
|
|
2020-02-11 14:30:48 +01:00
|
|
|
/**
|
|
|
|
|
This funtion will try to invoke platform specific microcode shadow logic to
|
|
|
|
|
relocate microcode update patches into memory.
|
|
|
|
|
|
2020-03-04 12:39:28 +01:00
|
|
|
@param[in, out] CpuMpData The pointer to CPU MP Data structure.
|
2020-02-11 14:30:48 +01:00
|
|
|
|
|
|
|
|
@retval EFI_SUCCESS Shadow microcode success.
|
|
|
|
|
@retval EFI_OUT_OF_RESOURCES No enough resource to complete the operation.
|
|
|
|
|
@retval EFI_UNSUPPORTED Can't find platform specific microcode shadow
|
|
|
|
|
PPI/Protocol.
|
|
|
|
|
**/
|
|
|
|
|
EFI_STATUS
|
|
|
|
|
PlatformShadowMicrocode (
|
|
|
|
|
IN OUT CPU_MP_DATA *CpuMpData
|
|
|
|
|
);
|
|
|
|
|
|
2021-12-09 04:27:30 +01:00
|
|
|
/**
|
|
|
|
|
Allocate the SEV-ES AP jump table buffer.
|
|
|
|
|
|
|
|
|
|
@param[in, out] CpuMpData The pointer to CPU MP Data structure.
|
|
|
|
|
**/
|
|
|
|
|
VOID
|
|
|
|
|
AllocateSevEsAPMemory (
|
|
|
|
|
IN OUT CPU_MP_DATA *CpuMpData
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
Program the SEV-ES AP jump table buffer.
|
|
|
|
|
|
|
|
|
|
@param[in] SipiVector The SIPI vector used for the AP Reset
|
|
|
|
|
**/
|
|
|
|
|
VOID
|
|
|
|
|
SetSevEsJumpTable (
|
|
|
|
|
IN UINTN SipiVector
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
The function puts the AP in halt loop.
|
|
|
|
|
|
|
|
|
|
@param[in] CpuMpData The pointer to CPU MP Data structure.
|
|
|
|
|
**/
|
|
|
|
|
VOID
|
|
|
|
|
SevEsPlaceApHlt (
|
|
|
|
|
CPU_MP_DATA *CpuMpData
|
|
|
|
|
);
|
|
|
|
|
|
2021-12-09 04:27:50 +01:00
|
|
|
/**
|
|
|
|
|
Check if the specified confidential computing attribute is active.
|
|
|
|
|
|
|
|
|
|
@retval TRUE The specified Attr is active.
|
|
|
|
|
@retval FALSE The specified Attr is not active.
|
|
|
|
|
**/
|
|
|
|
|
BOOLEAN
|
|
|
|
|
EFIAPI
|
|
|
|
|
ConfidentialComputingGuestHas (
|
|
|
|
|
CONFIDENTIAL_COMPUTING_GUEST_ATTR Attr
|
|
|
|
|
);
|
|
|
|
|
|
UefiCpuPkg/MpInitLib: use BSP to do extended topology check
During AP bringup, just after switching to long mode, APs will do some
cpuid calls to verify that the extended topology leaf (0xB) is available
so they can fetch their x2 APIC IDs from it. In the case of SEV-ES,
these cpuid instructions must be handled by direct use of the GHCB MSR
protocol to fetch the values from the hypervisor, since a #VC handler
is not yet available due to the AP's stack not being set up yet.
For SEV-SNP, rather than relying on the GHCB MSR protocol, it is
expected that these values would be obtained from the SEV-SNP CPUID
table instead. The actual x2 APIC ID (and 8-bit APIC IDs) would still
be fetched from hypervisor using the GHCB MSR protocol however, so
introducing support for the SEV-SNP CPUID table in that part of the AP
bring-up code would only be to handle the checks/validation of the
extended topology leaf.
Rather than introducing all the added complexity needed to handle these
checks via the CPUID table, instead let the BSP do the check in advance,
since it can make use of the #VC handler to avoid the need to scan the
SNP CPUID table directly, and add a flag in ExchangeInfo to communicate
the result of this check to APs.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ray Ni <ray.ni@intel.com>
Suggested-by: Brijesh Singh <brijesh.singh@amd.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
2021-12-09 04:27:55 +01:00
|
|
|
/**
|
|
|
|
|
The function fills the exchange data for the AP.
|
|
|
|
|
|
|
|
|
|
@param[in] ExchangeInfo The pointer to CPU Exchange Data structure
|
|
|
|
|
**/
|
|
|
|
|
VOID
|
|
|
|
|
FillExchangeInfoDataSevEs (
|
|
|
|
|
IN volatile MP_CPU_EXCHANGE_INFO *ExchangeInfo
|
|
|
|
|
);
|
|
|
|
|
|
2021-12-09 04:28:00 +01:00
|
|
|
/**
|
|
|
|
|
Issue RMPADJUST to adjust the VMSA attribute of an SEV-SNP page.
|
|
|
|
|
|
|
|
|
|
@param[in] PageAddress
|
|
|
|
|
@param[in] VmsaPage
|
|
|
|
|
|
|
|
|
|
@return RMPADJUST return value
|
|
|
|
|
**/
|
|
|
|
|
UINT32
|
|
|
|
|
SevSnpRmpAdjust (
|
|
|
|
|
IN EFI_PHYSICAL_ADDRESS PageAddress,
|
|
|
|
|
IN BOOLEAN VmsaPage
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
Create an SEV-SNP AP save area (VMSA) for use in running the vCPU.
|
|
|
|
|
|
|
|
|
|
@param[in] CpuMpData Pointer to CPU MP Data
|
|
|
|
|
@param[in] CpuData Pointer to CPU AP Data
|
|
|
|
|
@param[in] ApicId APIC ID of the vCPU
|
|
|
|
|
**/
|
|
|
|
|
VOID
|
|
|
|
|
SevSnpCreateSaveArea (
|
|
|
|
|
IN CPU_MP_DATA *CpuMpData,
|
|
|
|
|
IN CPU_AP_DATA *CpuData,
|
|
|
|
|
UINT32 ApicId
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
Create SEV-SNP APs.
|
|
|
|
|
|
|
|
|
|
@param[in] CpuMpData Pointer to CPU MP Data
|
|
|
|
|
@param[in] ProcessorNumber The handle number of specified processor
|
|
|
|
|
(-1 for all APs)
|
|
|
|
|
**/
|
|
|
|
|
VOID
|
|
|
|
|
SevSnpCreateAP (
|
|
|
|
|
IN CPU_MP_DATA *CpuMpData,
|
|
|
|
|
IN INTN ProcessorNumber
|
|
|
|
|
);
|
|
|
|
|
|
2023-06-28 10:47:22 +02:00
|
|
|
/**
|
|
|
|
|
Get pointer to CPU MP Data structure from GUIDed HOB.
|
|
|
|
|
|
|
|
|
|
@param[in] CpuMpData The pointer to CPU MP Data structure.
|
|
|
|
|
**/
|
|
|
|
|
VOID
|
|
|
|
|
AmdSevUpdateCpuMpData (
|
|
|
|
|
IN CPU_MP_DATA *CpuMpData
|
|
|
|
|
);
|
|
|
|
|
|
2016-07-20 15:56:58 +02:00
|
|
|
#endif
|
