Re: [edk2-devel] [PATCH v3 00/13] Add SmmRelocationLib
Thanks,
Ray
From: Gerd Hoffmann
Sent: Thursday, April 25, 2024 14:58
To: Ni, Ray
Cc: Wu, Jiaxin ; devel@edk2.groups.io
; Zeng, Star ; Kumar, Rahul R
; Dong, Guo ; Rhodes, Sean
; Lu, James ; Guo, Gua
; Ard Biesheuvel ; Yao, Jiewen
; Abdul Lateef Attar ; Abner
Chang ; Tom Lendacky
Subject: Re: [edk2-devel] [PATCH v3 00/13] Add SmmRelocationLib
Hi,
> That means the SMMRevId is 0_xx64h for AMD64 processor. But I am not
> sure what the value is for AMD32 processor. Maybe 0 according to the
> OVMF logic.
The smm emulation in the linux kernel uses 0 and 0x64.
[Ray] OK. that supports the OVMF instance's logic. But I'd like Tom or any
other AMD guys to provide spec that says 0 for AMD32.
> But, I am very suspicious about the logic in AMD's version as below:
> --- AMD's version
> SmmSaveStateRegisterLma = (UINT8)EFI_MM_SAVE_STATE_REGISTER_LMA_32BIT;
>
> LMAValue = (UINT32)AsmReadMsr64 (EFER_ADDRESS) & LMA;
> if (LMAValue) {
> SmmSaveStateRegisterLma = (UINT8)EFI_MM_SAVE_STATE_REGISTER_LMA_64BIT;
> }
> ---
> The above logic detects the current CPU mode and 64bit save state area layout
> is used if it's running in 64bit.
> But if a AMD64 CPU runs in 32bit mode, the above logic causes the
> 32bit save state area layout is used. It's not right! The save state
> area layout does not depend on the CPU running mode, but whether it's
> a legacy CPU or a 64-capable CPU.
Well, that is not entirely clear to me. Could it be 64-bit processors
support both 32-bit and 64-bit format, for backward compatibility
reasons?
[Ray] The CPU uses a fixed save state area layout no matter it runs in 32bit or
64bit.
The 64bit cpu only uses the 64bit format, no matter it runs in 32bit or 64bit.
So OvmfPkgIa32 builds could use the 32-bit format, OvmfPkgX64 builds use
the 64-bit format, everything works fine?
[Ray] For OVMF, it depends on how the virtual cpu is defined by QEMU
implementation.
If the underline CPU is a AMD64 cpu, the CPU supports running in 32bit or 64bit
modes. But no matter
it runs in 32bit or 64bit, the save state area layout always follows the 64bit
format.
The tricky corner case is OvmfPkgIa32X64, where (after applying this
series) 32-bit PEI should setup things for 64-bit SMM/DXE, and checking
the current processor mode will not give use the result we need.
> Jiaxin, I agree that the confusion should be cleaned up by AMD
> experts. Let's not change any existing behavior.
Agree. Tom?
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118310): https://edk2.groups.io/g/devel/message/118310
Mute This Topic: https://groups.io/mt/105593568/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 1/1] UefiCpuPkg/SmmCpuSyncLib: Add MM_STANDALONE tag.
-# Copyright (c) 2023, Intel Corporation. All rights reserved. +# Copyright (c) 2024, Intel Corporation. All rights reserved. Yuanhao, why did you change the copyright year from 2023 to 2024? You can either leave it unchanged, or change it to "2023 - 2024". # SPDX-License-Identifier: BSD-2-Clause-Patent # ## @@ -13,7 +13,7 @@ BASE_NAME = SmmCpuSyncLib FILE_GUID = 1ca1bc1a-16a4-46ef-956a-ca500fd3381f MODULE_TYPE= DXE_SMM_DRIVER - LIBRARY_CLASS = SmmCpuSyncLib|DXE_SMM_DRIVER + LIBRARY_CLASS = SmmCpuSyncLib|DXE_SMM_DRIVER MM_STANDALONE [Sources] SmmCpuSyncLib.c -- 2.39.1.windows.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#118269): https://edk2.groups.io/g/devel/message/118269 Mute This Topic: https://groups.io/mt/105685282/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 2/2] StandaloneMmPkg: Initialize 'WillReturn' variable
Reviewed-by: Ray Ni
Thanks,
Ray
From: Liu, Zhiguang
Sent: Thursday, April 25, 2024 12:40
To: devel@edk2.groups.io
Cc: Liu, Zhiguang ; Liming Gao
; Wu, Jiaxin ; Ni, Ray
; Laszlo Ersek ; Ard Biesheuvel
; Sami Mujawar
Subject: [PATCH 2/2] StandaloneMmPkg: Initialize 'WillReturn' variable
The local variable 'WillReturn' was being used without prior
initialization in some code paths.
This patch ensures that 'WillReturn' is properly initialized
to prevent undefined behavior.
Cc: Liming Gao
Cc: Jiaxin Wu
Cc: Ray Ni
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
Cc: Sami Mujawar
Signed-off-by: Zhiguang Liu
---
StandaloneMmPkg/Core/Mmi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/StandaloneMmPkg/Core/Mmi.c b/StandaloneMmPkg/Core/Mmi.c
index e035245c87..fb205df490 100644
--- a/StandaloneMmPkg/Core/Mmi.c
+++ b/StandaloneMmPkg/Core/Mmi.c
@@ -174,6 +174,7 @@ MmiManage (
EFI_STATUS Status;
mMmiManageCallingDepth++;
+ WillReturn = FALSE;
Status = EFI_NOT_FOUND;
ReturnStatus = Status;
if (HandlerType == NULL) {
--
2.31.1.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118268): https://edk2.groups.io/g/devel/message/118268
Mute This Topic: https://groups.io/mt/105725160/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 1/2] MdeModulePkg/SMM: Initialize 'WillReturn' variable
Reviewed-by: Ray Ni
Thanks,
Ray
From: Liu, Zhiguang
Sent: Thursday, April 25, 2024 12:40
To: devel@edk2.groups.io
Cc: Liu, Zhiguang ; Liming Gao
; Wu, Jiaxin ; Ni, Ray
; Laszlo Ersek
Subject: [PATCH 1/2] MdeModulePkg/SMM: Initialize 'WillReturn' variable
The local variable 'WillReturn' was being used without prior
initialization in some code paths.
This patch ensures that 'WillReturn' is properly initialized
to prevent undefined behavior.
Cc: Liming Gao
Cc: Jiaxin Wu
Cc: Ray Ni
Cc: Laszlo Ersek
Signed-off-by: Zhiguang Liu
---
MdeModulePkg/Core/PiSmmCore/Smi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/MdeModulePkg/Core/PiSmmCore/Smi.c
b/MdeModulePkg/Core/PiSmmCore/Smi.c
index a84a1f48d3..6b56fa5f69 100644
--- a/MdeModulePkg/Core/PiSmmCore/Smi.c
+++ b/MdeModulePkg/Core/PiSmmCore/Smi.c
@@ -152,6 +152,7 @@ SmiManage (
PERF_FUNCTION_BEGIN ();
mSmiManageCallingDepth++;
+ WillReturn = FALSE;
Status = EFI_NOT_FOUND;
ReturnStatus = Status;
if (HandlerType == NULL) {
--
2.31.1.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118267): https://edk2.groups.io/g/devel/message/118267
Mute This Topic: https://groups.io/mt/105725159/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v3 00/13] Add SmmRelocationLib
I checked the AMD64 Architecture Programmer's Manual and it says below:
--- AMD64 manual ---
SMM-revision Level—Bits 15:0. Specifies the version of SMM supported by the
processor. The SMM-revision level is of the form 0_xx64h, where xx starts with
00 and is incremented for later revisions to the SMM mechanism.
---
That means the SMMRevId is 0_xx64h for AMD64 processor. But I am not sure what
the value is for AMD32 processor. Maybe 0 according to the OVMF logic.
--- OVMF's logic ---
AMD_SMRAM_SAVE_STATE_MAP *CpuSaveState;
CpuSaveState = (AMD_SMRAM_SAVE_STATE_MAP *)(UINTN)(SMM_DEFAULT_SMBASE +
SMRAM_SAVE_STATE_MAP_OFFSET);
if ((CpuSaveState->x86.SMMRevId & 0x) == 0) {
CpuSaveState->x86.SMBASE = (UINT32)SmBase;
} else {
CpuSaveState->x64.SMBASE = (UINT32)SmBase;
}
--
But, I am very suspicious about the logic in AMD's version as below:
--- AMD's version
SmmSaveStateRegisterLma = (UINT8)EFI_MM_SAVE_STATE_REGISTER_LMA_32BIT;
LMAValue = (UINT32)AsmReadMsr64 (EFER_ADDRESS) & LMA;
if (LMAValue) {
SmmSaveStateRegisterLma = (UINT8)EFI_MM_SAVE_STATE_REGISTER_LMA_64BIT;
}
---
The above logic detects the current CPU mode and 64bit save state area layout
is used if it's running in 64bit.
But if a AMD64 CPU runs in 32bit mode, the above logic causes the 32bit save
state area layout is used. It's not right!
The save state area layout does not depend on the CPU running mode, but whether
it's a legacy CPU or a 64-capable CPU.
Jiaxin, I agree that the confusion should be cleaned up by AMD experts. Let's
not change any existing behavior.
Thanks,
Ray
From: Wu, Jiaxin
Sent: Thursday, April 25, 2024 8:54
To: Gerd Hoffmann
Cc: devel@edk2.groups.io ; Ni, Ray ;
Zeng, Star ; Kumar, Rahul R ;
Dong, Guo ; Rhodes, Sean ; Lu, James
; Guo, Gua ; Ard Biesheuvel
; Yao, Jiewen ; Abdul Lateef
Attar ; Abner Chang ; Tom
Lendacky
Subject: RE: [edk2-devel] [PATCH v3 00/13] Add SmmRelocationLib
> >
> > AMD version is not work for IA32X64 ovmf.
> >
> > I checked the detailed: CpuSaveState->x64 is always used for OVMF no
> matter IA32 or X64, while AMD is not, which is decided by the MSR
> EFER_ADDRESS LMA bit check.
>
> Hmm, probably because only PEI runs in 32-bit mode whereas DXE and SMM
> run in 64-bit mode, so 32-bit PEI has to prepare things for the 64-bit
> SMM.
>
> > There is a potential issue/open in OVMF why need use the X64
> > CpuSaveState for IA32. Before this open resolved, I still prefer to
> > keep use the ovmf specific lib instance.
>
> Yes, lets stick to the ovmf version for now, and maybe remove it later
> when fixing the ia32 ovmf builds.
>
Ok, no problem.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118266): https://edk2.groups.io/g/devel/message/118266
Mute This Topic: https://groups.io/mt/105593568/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] MdeModulePkg: Fix MAT SplitRecord() Logic introduce one bug and will cause SUT reset when boot to windows
So this is just junk unallocated memory that we are reporting as a type it *could* be if an allocation occurs to minimize failures of ExitBootServices. Which is questionable. But in terms of attributes, I would expect we either have this unallocated memory marked the same as the bin type or better, mark it RP if we can (Taylor is making a change to set RP on free memory by default, so we would have this in the page table, but we would need to decide what we tell the OS). [Ray] When reviewing today's logic of memory protection through page table, I feel that it was designed improperly in the beginning. My rough thought is: * All memory is RP initially (as you said Taylor will do that) * Allocated memory is mapped as either RO or XD, depending on code/data. Or RP if it's a guard page. Maybe I am not aware of some limitations of the above idea. The limitations prevented the initial design be in this way. Or what Taylor will do aligns to the idea? Thanks, Ray -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#118006): https://edk2.groups.io/g/devel/message/118006 Mute This Topic: https://groups.io/mt/105477564/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v3 00/13] Add SmmRelocationLib
Jiaxin, I see Abdul from AMD has given R-B. I assume that's sufficient for merging this patch. Thanks, Ray From: Wu, Jiaxin Sent: Thursday, April 18, 2024 16:03 To: devel@edk2.groups.io ; Wu, Jiaxin Cc: Ni, Ray ; Zeng, Star ; Gerd Hoffmann ; Kumar, Rahul R ; Dong, Guo ; Rhodes, Sean ; Lu, James ; Guo, Gua ; Ard Biesheuvel ; Yao, Jiewen ; Abdul Lateef Attar ; Abner Chang ; Tom Lendacky Subject: RE: [edk2-devel] [PATCH v3 00/13] Add SmmRelocationLib Hi Tom & Abner, Could you help check & review AMD related patch? > UefiCpuPkg/SmmRelocationLib: Add library instance for AMD Thanks, Jiaxin > -Original Message- > From: devel@edk2.groups.io On Behalf Of Wu, > Jiaxin > Sent: Thursday, April 18, 2024 2:56 PM > To: devel@edk2.groups.io > Cc: Ni, Ray ; Zeng, Star ; Gerd > Hoffmann ; Kumar, Rahul R ; > Dong, Guo ; Rhodes, Sean ; > Lu, James ; Guo, Gua ; Ard > Biesheuvel ; Yao, Jiewen > ; Abdul Lateef Attar ; > Abner Chang ; Tom Lendacky > > Subject: [edk2-devel] [PATCH v3 00/13] Add SmmRelocationLib > > PR: https://github.com/tianocore/edk2/pull/5546 > > Intel plans to separate the smbase relocation logic from > PiSmmCpuDxeSmm driver, and the related behavior will be > moved to the new interface defined by the SmmRelocationLib > class. > > The SmmRelocationLib class provides the SmmRelocationInit() > interface for platform to do the smbase relocation, which > shall provide below 2 functionalities: > 1. Relocate smbases for each processor. > 2. Create the gSmmBaseHobGuid HOB. > > With SmmRelocationLib, PiSmmCpuDxeSmm driver (which runs at > a later phase) can be simplfied as below for SMM init: > 1. Consume the gSmmBaseHobGuid HOB for the relocated smbases > for each Processor. > 2. Execute the early SMM Init. > > Cc: Ray Ni > Cc: Zeng Star > Cc: Gerd Hoffmann > Cc: Rahul Kumar > Cc: Guo Dong > Cc: Sean Rhodes > Cc: James Lu > Cc: Gua Guo > Cc: Ard Biesheuvel > Cc: Jiewen Yao > Cc: Abdul Lateef Attar > Cc: Abner Chang > Cc: Tom Lendacky > Signed-off-by: Jiaxin Wu > > Jiaxin Wu (13): > UefiCpuPkg: Add SmmRelocationLib class > UefiCpuPkg/SmmRelocationLib: Add SmmRelocationLib library instance > UefiCpuPkg/SmmRelocationLib: Rename global variables > UefiCpuPkg/SmmRelocationLib: Avoid unnecessary memory allocation > UefiCpuPkg/SmmRelocationLib: Remove unnecessary global variable > UefiCpuPkg/SmmRelocationLib: Add library instance for AMD > OvmfPkg/SmmRelocationLib: Add library instance for OVMF > OvmfPkg/PlatformInitLib: Create gEfiSmmSmramMemoryGuid > OvmfPkg: Refine SmmAccess implementation > OvmfPkg/SmmCpuFeaturesLib: Check Smbase Relocation is done or not > OvmfPkg/PlatformPei: Relocate SmBases in PEI phase > UefiPayloadPkg/UefiPayloadPkg.dsc: Include SmmRelocationLib > UefiCpuPkg/PiSmmCpuDxeSmm: Remove SmBases relocation logic > > OvmfPkg/AmdSev/AmdSevX64.dsc | 1 + > OvmfPkg/CloudHv/CloudHvX64.dsc | 1 + > OvmfPkg/Library/PlatformInitLib/MemDetect.c| 104 ++-- > .../Library/PlatformInitLib/PlatformInitLib.inf| 6 +- > .../Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c | 33 +- > .../Library/SmmRelocationLib}/Ia32/Semaphore.c | 13 +- > .../Library/SmmRelocationLib}/Ia32/SmmInit.nasm| 83 +++- > .../SmmRelocationLib/InternalSmmRelocationLib.h| 127 + > .../Library/SmmRelocationLib/SmmRelocationLib.c| 549 > + > .../Library/SmmRelocationLib/SmmRelocationLib.inf | 60 +++ > .../SmmRelocationLib/SmramSaveStateConfig.c| 100 > .../Library/SmmRelocationLib}/X64/Semaphore.c | 13 +- > .../Library/SmmRelocationLib}/X64/SmmInit.nasm | 85 +++- > OvmfPkg/Microvm/MicrovmX64.dsc | 1 + > OvmfPkg/OvmfPkgIa32.dsc| 1 + > OvmfPkg/OvmfPkgIa32X64.dsc | 1 + > OvmfPkg/OvmfPkgX64.dsc | 1 + > OvmfPkg/PlatformPei/Platform.c | 3 + > OvmfPkg/PlatformPei/Platform.h | 5 + > OvmfPkg/PlatformPei/PlatformPei.inf| 5 +- > OvmfPkg/PlatformPei/SmmRelocation.c| 80 +++ > OvmfPkg/SmmAccess/SmmAccess2Dxe.c | 4 +- > OvmfPkg/SmmAccess/SmmAccess2Dxe.inf| 5 + > OvmfPkg/SmmAccess/SmmAccessPei.c | 88 +--- > OvmfPkg/SmmAccess/SmmAccessPei.inf | 7 +- > OvmfPkg/SmmAccess/SmramInternal.c | 73 +-- > OvmfPkg/SmmAccess/SmramInternal.h | 18 +- > UefiCpuPkg/Include/Library/SmmRelocationLib.h | 42 ++ > .../SmmRelocationLib/
Re: [edk2-devel] [PATCH v3 13/13] UefiCpuPkg/PiSmmCpuDxeSmm: Remove SmBases relocation logic
+ //
+ // Check whether the Required TileSize is enough.
+ //
+ if (TileSize > SIZE_8KB) {
+DEBUG ((DEBUG_ERROR, "The Range of Smbase in SMRAM is not enough --
Required TileSize = 0x%08x, Actual TileSize = 0x%08x\n", TileSize, SIZE_8KB));
+FreePool (mCpuHotPlugData.SmBase);
+FreePool (gSmmCpuPrivate->ProcessorInfo);
+CpuDeadLoop ();
+return RETURN_BUFFER_TOO_SMALL;
}
[Ray] Can you move the "TileSize" check just below the original TileSize
calculation logic? Others look good to me.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117967): https://edk2.groups.io/g/devel/message/117967
Mute This Topic: https://groups.io/mt/105593584/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v3 05/13] UefiCpuPkg/SmmRelocationLib: Remove unnecessary global variable
UINT64
EFIAPI
HookReturnFromSmm (
- IN UINTN CpuIndex,
IN OUT SMRAM_SAVE_STATE_MAP *CpuState,
IN UINT64NewInstructionPointer32,
IN UINT64NewInstructionPointer
)
{
diff --git a/UefiCpuPkg/Library/SmmRelocationLib/X64/Semaphore.c
b/UefiCpuPkg/Library/SmmRelocationLib/X64/Semaphore.c
index 53f3084363..cd6778e3fc 100644
--- a/UefiCpuPkg/Library/SmmRelocationLib/X64/Semaphore.c
+++ b/UefiCpuPkg/Library/SmmRelocationLib/X64/Semaphore.c
@@ -26,18 +26,16 @@ SmmRelocationSemaphoreComplete32 (
/**
Hook return address of SMM Save State so that semaphore code
can be executed immediately after AP exits SMM to indicate to
the BSP that an AP has exited SMM after SMBASE relocation.
- @param[in] CpuIndex The processor index.
@param[in] RebasedFlag A pointer to a flag that is set to TRUE
immediately after AP exits SMM.
**/
VOID
SemaphoreHook (
- IN UINTN CpuIndex,
IN volatile BOOLEAN *RebasedFlag
)
{
SMRAM_SAVE_STATE_MAP *CpuState;
UINTN TempValue;
@@ -49,11 +47,10 @@ SemaphoreHook (
4
);
CpuState = (SMRAM_SAVE_STATE_MAP
*)(UINTN)(SMM_DEFAULT_SMBASE + SMRAM_SAVE_STATE_MAP_OFFSET);
mSmmRelocationOriginalAddress = HookReturnFromSmm (
-CpuIndex,
CpuState,
(UINT64)(UINTN),
(UINT64)(UINTN)
);
[Ray] Can you split the removal of CpuIndex parameter in a new patch? Others
look good to me.
--
2.16.2.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117962): https://edk2.groups.io/g/devel/message/117962
Mute This Topic: https://groups.io/mt/105593573/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v3 04/13] UefiCpuPkg/SmmRelocationLib: Avoid unnecessary memory allocation
Reviewed-by: Ray Ni
Thanks,
Ray
From: Wu, Jiaxin
Sent: Thursday, April 18, 2024 14:55
To: devel@edk2.groups.io
Cc: Ni, Ray ; Zeng, Star ; Gerd Hoffmann
; Kumar, Rahul R
Subject: [PATCH v3 04/13] UefiCpuPkg/SmmRelocationLib: Avoid unnecessary memory
allocation
Since SMM relocation is performed serially for each CPU, there is
no need to allocate buffers for all CPUs to store the SmBase
address in mSmBase and the Rebased flag in mRebased. A defined
global variable is sufficient.
This patch focuses on the mSmBase and mRebased global variables
to prevent unnecessary memory allocation for these variables.
Cc: Ray Ni
Cc: Zeng Star
Cc: Gerd Hoffmann
Cc: Rahul Kumar
Signed-off-by: Jiaxin Wu
---
.../Library/SmmRelocationLib/SmmRelocationLib.c| 201 +
1 file changed, 90 insertions(+), 111 deletions(-)
diff --git a/UefiCpuPkg/Library/SmmRelocationLib/SmmRelocationLib.c
b/UefiCpuPkg/Library/SmmRelocationLib/SmmRelocationLib.c
index ca98f06a05..3694a07cbb 100644
--- a/UefiCpuPkg/Library/SmmRelocationLib/SmmRelocationLib.c
+++ b/UefiCpuPkg/Library/SmmRelocationLib/SmmRelocationLib.c
@@ -25,31 +25,57 @@ EFI_PROCESSOR_INFORMATION *mProcessorInfo = NULL;
// IDT used during SMM Init
//
IA32_DESCRIPTOR gcSmmInitIdtr;
//
-// Smbase for all CPUs
+// Smbase for current CPU
//
-UINT64 *mSmBase = NULL;
+UINT64 mSmBase;
//
-// SmBase Rebased flag for all CPUs
+// SmBase Rebased flag for current CPU
//
-volatile BOOLEAN *mRebased;
+volatile BOOLEAN mRebased;
+
+/**
+ This function will get the SmBase for CpuIndex.
+
+ @param[in] CpuIndexThe processor index.
+ @param[in] SmmRelocationStart The start address of Smm relocated memory
in SMRAM.
+ @param[in] TileSizeThe total size required for a CPU save
state, any
+ additional CPU-specific context and the
size of code
+ for the SMI entry point.
+
+ @retval The value of SmBase for CpuIndex.
+
+**/
+UINTN
+GetSmBase (
+ IN UINTN CpuIndex,
+ IN EFI_PHYSICAL_ADDRESS SmmRelocationStart,
+ IN UINTN TileSize
+ )
+{
+ return (UINTN)(SmmRelocationStart) + CpuIndex * TileSize -
SMM_HANDLER_OFFSET;
+}
/**
This function will create SmBase for all CPUs.
- @param[in] SmBasePointer to SmBase for all CPUs.
+ @param[in] SmmRelocationStart The start address of Smm relocated memory
in SMRAM.
+ @param[in] TileSizeThe total size required for a CPU save
state, any
+ additional CPU-specific context and the
size of code
+ for the SMI entry point.
@retval EFI_SUCCESS Create SmBase for all CPUs successfully.
@retval OthersFailed to create SmBase for all CPUs.
**/
EFI_STATUS
CreateSmmBaseHob (
- IN UINT64 *SmBase
+ IN EFI_PHYSICAL_ADDRESS SmmRelocationStart,
+ IN UINTN TileSize
)
{
UINTN Index;
SMM_BASE_HOB_DATA *SmmBaseHobData;
UINT32 CpuCount;
@@ -90,11 +116,11 @@ CreateSmmBaseHob (
DEBUG ((DEBUG_INFO, "CreateSmmBaseHob -
SmmBaseHobData[%d]->NumberOfProcessors: %d\n", HobCount,
SmmBaseHobData->NumberOfProcessors));
for (Index = 0; Index < SmmBaseHobData->NumberOfProcessors; Index++) {
//
// Calculate the new SMBASE address
//
- SmmBaseHobData->SmBase[Index] = SmBase[Index + CpuCount];
+ SmmBaseHobData->SmBase[Index] = GetSmBase (Index + CpuCount,
SmmRelocationStart, TileSize);
DEBUG ((DEBUG_INFO, "CreateSmmBaseHob - SmmBaseHobData[%d]->SmBase[%d]:
0x%08x\n", HobCount, Index, SmmBaseHobData->SmBase[Index]));
}
CpuCount += NumberOfProcessorsInHob;
HobCount++;
@@ -126,18 +152,18 @@ SmmInitHandler (
for (Index = 0; Index < mNumberOfCpus; Index++) {
if (ApicId == (UINT32)mProcessorInfo[Index].ProcessorId) {
//
// Configure SmBase.
//
- ConfigureSmBase (mSmBase[Index]);
+ ConfigureSmBase (mSmBase);
//
// Hook return after RSM to set SMM re-based flag
// SMM re-based flag can't be set before RSM, because SMM save state
context might be override
// by next AP flow before it take effect.
//
- SemaphoreHook (Index, [Index]);
+ SemaphoreHook (Index, );
return;
}
}
ASSERT (FALSE);
@@ -145,14 +171,22 @@ SmmInitHandler (
/**
Relocate SmmBases for each processor.
Execute on first boot and all S3 resumes
+ @param[in] MpServices2 Pointer to this instance of the MpServices.
+ @param[in] SmmRelocationStart The start address of Smm relocated memory
in SMRAM.
+ @param[in] TileSizeThe total size required for a CPU save
state, any
+ additional CPU-specific context and the
size of code
+
Re: [edk2-devel] [PATCH v3 03/13] UefiCpuPkg/SmmRelocationLib: Rename global variables
Reviewed-by: Ray Ni
Thanks,
Ray
From: Wu, Jiaxin
Sent: Thursday, April 18, 2024 14:55
To: devel@edk2.groups.io
Cc: Ni, Ray ; Zeng, Star ; Gerd Hoffmann
; Kumar, Rahul R
Subject: [PATCH v3 03/13] UefiCpuPkg/SmmRelocationLib: Rename global variables
This patch aims to rename global variables for clearer
association with Smm Init, ensuring their names are
distinct from those used in the PiSmmCpuDxeSmm Driver.
Cc: Ray Ni
Cc: Zeng Star
Cc: Gerd Hoffmann
Cc: Rahul Kumar
Signed-off-by: Jiaxin Wu
---
.../Library/SmmRelocationLib/Ia32/SmmInit.nasm | 18 +++
.../SmmRelocationLib/InternalSmmRelocationLib.h| 8 +++
.../Library/SmmRelocationLib/SmmRelocationLib.c| 26 +++---
.../Library/SmmRelocationLib/X64/SmmInit.nasm | 18 +++
4 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/UefiCpuPkg/Library/SmmRelocationLib/Ia32/SmmInit.nasm
b/UefiCpuPkg/Library/SmmRelocationLib/Ia32/SmmInit.nasm
index 3d845e9e16..8916cb7d06 100644
--- a/UefiCpuPkg/Library/SmmRelocationLib/Ia32/SmmInit.nasm
+++ b/UefiCpuPkg/Library/SmmRelocationLib/Ia32/SmmInit.nasm
@@ -16,15 +16,15 @@
extern ASM_PFX(SmmInitHandler)
extern ASM_PFX(mRebasedFlag)
extern ASM_PFX(mSmmRelocationOriginalAddress)
-global ASM_PFX(gPatchSmmCr3)
-global ASM_PFX(gPatchSmmCr4)
-global ASM_PFX(gPatchSmmCr0)
+global ASM_PFX(gPatchSmmInitCr3)
+global ASM_PFX(gPatchSmmInitCr4)
+global ASM_PFX(gPatchSmmInitCr0)
global ASM_PFX(gPatchSmmInitStack)
-global ASM_PFX(gcSmiInitGdtr)
+global ASM_PFX(gcSmmInitGdtr)
global ASM_PFX(gcSmmInitSize)
global ASM_PFX(gcSmmInitTemplate)
%define PROTECT_MODE_CS 0x8
%define PROTECT_MODE_DS 0x20
@@ -81,11 +81,11 @@ CodeSeg64:
DB 0x9b
DB 0xaf; LimitHigh
DB 0 ; BaseHigh
GDT_SIZE equ $ - NullSeg
-ASM_PFX(gcSmiInitGdtr):
+ASM_PFX(gcSmmInitGdtr):
DW GDT_SIZE - 1
DD NullSeg
SECTION .text
@@ -98,22 +98,22 @@ ASM_PFX(SmmStartup):
cpuid
mov ebx, edx; rdmsr will change edx. keep it in
ebx.
and ebx, BIT20 ; extract NX capability bit
shr ebx, 9 ; shift bit to IA32_EFER.NXE[BIT11]
position
mov eax, strict dword 0 ; source operand will be patched
-ASM_PFX(gPatchSmmCr3):
+ASM_PFX(gPatchSmmInitCr3):
mov cr3, eax
-o32 lgdt[cs:ebp + (ASM_PFX(gcSmiInitGdtr) - ASM_PFX(SmmStartup))]
+o32 lgdt[cs:ebp + (ASM_PFX(gcSmmInitGdtr) - ASM_PFX(SmmStartup))]
mov eax, strict dword 0 ; source operand will be patched
-ASM_PFX(gPatchSmmCr4):
+ASM_PFX(gPatchSmmInitCr4):
mov cr4, eax
mov ecx, 0xc080 ; IA32_EFER MSR
rdmsr
or eax, ebx; set NXE bit if NX is available
wrmsr
mov eax, strict dword 0 ; source operand will be patched
-ASM_PFX(gPatchSmmCr0):
+ASM_PFX(gPatchSmmInitCr0):
mov di, PROTECT_MODE_DS
mov cr0, eax
jmp PROTECT_MODE_CS : dword @32bit
BITS 32
diff --git a/UefiCpuPkg/Library/SmmRelocationLib/InternalSmmRelocationLib.h
b/UefiCpuPkg/Library/SmmRelocationLib/InternalSmmRelocationLib.h
index a9d3f271a9..ede61b956f 100644
--- a/UefiCpuPkg/Library/SmmRelocationLib/InternalSmmRelocationLib.h
+++ b/UefiCpuPkg/Library/SmmRelocationLib/InternalSmmRelocationLib.h
@@ -30,17 +30,17 @@
#include
#include
#include
#include
-extern IA32_DESCRIPTOR gcSmiInitGdtr;
+extern IA32_DESCRIPTOR gcSmmInitGdtr;
extern CONST UINT16 gcSmmInitSize;
extern CONST UINT8 gcSmmInitTemplate[];
-X86_ASSEMBLY_PATCH_LABEL gPatchSmmCr0;
-X86_ASSEMBLY_PATCH_LABEL gPatchSmmCr3;
-X86_ASSEMBLY_PATCH_LABEL gPatchSmmCr4;
+X86_ASSEMBLY_PATCH_LABEL gPatchSmmInitCr0;
+X86_ASSEMBLY_PATCH_LABEL gPatchSmmInitCr3;
+X86_ASSEMBLY_PATCH_LABEL gPatchSmmInitCr4;
X86_ASSEMBLY_PATCH_LABEL gPatchSmmInitStack;
//
// The size 0x20 must be bigger than
// the size of template code of SmmInit. Currently,
diff --git a/UefiCpuPkg/Library/SmmRelocationLib/SmmRelocationLib.c
b/UefiCpuPkg/Library/SmmRelocationLib/SmmRelocationLib.c
index 13e62b662d..ca98f06a05 100644
--- a/UefiCpuPkg/Library/SmmRelocationLib/SmmRelocationLib.c
+++ b/UefiCpuPkg/Library/SmmRelocationLib/SmmRelocationLib.c
@@ -22,11 +22,11 @@ UINTN mNumberOfCpus= 1;
EFI_PROCESSOR_INFORMATION *mProcessorInfo = NULL;
//
// IDT used during SMM Init
//
-IA32_DESCRIPTOR gcSmiIdtr;
+IA32_DESCRIPTOR gcSmmInitIdtr;
//
// Smbase for all CPUs
//
UINT64 *mSmBase = NULL;
@@ -118,11 +118,11 @@ SmmInitHandler (
UINTN Index;
//
// Update SMM IDT entries' code segment and load IDT
//
- AsmWriteIdtr ();
+ AsmWriteIdtr ();
ApicId = GetApicId ();
for (Index = 0; Index < mNumberOfCpus; Index++) {
if (ApicId == (UINT32)mProcessorInfo[Index].ProcessorId) {
//
@@ -167,13 +167,13 @@ SmmRelocateBa
Re: [edk2-devel] [PATCH v3 02/13] UefiCpuPkg/SmmRelocationLib: Add SmmRelocationLib library instance
Reviewed-by: Ray Ni
Thanks,
Ray
From: Wu, Jiaxin
Sent: Thursday, April 18, 2024 14:55
To: devel@edk2.groups.io
Cc: Ni, Ray ; Zeng, Star ; Gerd Hoffmann
; Kumar, Rahul R
Subject: [PATCH v3 02/13] UefiCpuPkg/SmmRelocationLib: Add SmmRelocationLib
library instance
This patch just separates the smbase relocation logic from
PiSmmCpuDxeSmm driver, and moves to the SmmRelocationInit
interface. It maintains the original implementation of most
functions and leaves the definitions of global variables
intact. Further refinements to the code are planned for
subsequent patches.
Platform shall consume the interface for the smbase
relocation if need SMM support.
Note:
Before using SmmRelocationLib, the PiSmmCpuDxeSmm driver
allocates the SMRAM to be used for SMI handler and Save
state area of each processor from Smst->AllocatePages().
With SmmRelocationLib, the SMRAM allocation for SMI
handlers and Save state areas is moved to early PEI
phase (Smst->AllocatePages() service is not available).
So, the allocation is done by splitting the SMRAM out of
the SMRAM regions reported from gEfiSmmSMramMemoryGuid.
So, Platform must produce the gEfiSmmSMramMemoryGuid HOB
for SmmRelocationLib usage.
Cc: Ray Ni
Cc: Zeng Star
Cc: Gerd Hoffmann
Cc: Rahul Kumar
Signed-off-by: Jiaxin Wu
---
.../SmmRelocationLib}/Ia32/Semaphore.c | 10 +-
.../SmmRelocationLib}/Ia32/SmmInit.nasm| 67 ++-
.../SmmRelocationLib/InternalSmmRelocationLib.h| 132 +
.../Library/SmmRelocationLib/SmmRelocationLib.c| 600 +
.../Library/SmmRelocationLib/SmmRelocationLib.inf | 61 +++
.../SmmRelocationLib/SmramSaveStateConfig.c| 139 +
.../SmmRelocationLib}/X64/Semaphore.c | 10 +-
.../SmmRelocationLib}/X64/SmmInit.nasm | 69 ++-
UefiCpuPkg/UefiCpuPkg.dsc | 1 +
9 files changed, 1066 insertions(+), 23 deletions(-)
copy UefiCpuPkg/{PiSmmCpuDxeSmm => Library/SmmRelocationLib}/Ia32/Semaphore.c
(79%)
copy UefiCpuPkg/{PiSmmCpuDxeSmm => Library/SmmRelocationLib}/Ia32/SmmInit.nasm
(53%)
create mode 100644
UefiCpuPkg/Library/SmmRelocationLib/InternalSmmRelocationLib.h
create mode 100644 UefiCpuPkg/Library/SmmRelocationLib/SmmRelocationLib.c
create mode 100644 UefiCpuPkg/Library/SmmRelocationLib/SmmRelocationLib.inf
create mode 100644 UefiCpuPkg/Library/SmmRelocationLib/SmramSaveStateConfig.c
copy UefiCpuPkg/{PiSmmCpuDxeSmm => Library/SmmRelocationLib}/X64/Semaphore.c
(84%)
copy UefiCpuPkg/{PiSmmCpuDxeSmm => Library/SmmRelocationLib}/X64/SmmInit.nasm
(64%)
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/Semaphore.c
b/UefiCpuPkg/Library/SmmRelocationLib/Ia32/Semaphore.c
similarity index 79%
copy from UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/Semaphore.c
copy to UefiCpuPkg/Library/SmmRelocationLib/Ia32/Semaphore.c
index a9fcc89dda..ba329d6ba2 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/Semaphore.c
+++ b/UefiCpuPkg/Library/SmmRelocationLib/Ia32/Semaphore.c
@@ -1,15 +1,15 @@
/** @file
-Semaphore mechanism to indicate to the BSP that an AP has exited SMM
-after SMBASE relocation.
+ Semaphore mechanism to indicate to the BSP that an AP has exited SMM
+ after SMBASE relocation.
-Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
-SPDX-License-Identifier: BSD-2-Clause-Patent
+ Copyright (c) 2024, Intel Corporation. All rights reserved.
+ SPDX-License-Identifier: BSD-2-Clause-Patent
**/
-#include "PiSmmCpuDxeSmm.h"
+#include "InternalSmmRelocationLib.h"
UINTN mSmmRelocationOriginalAddress;
volatile BOOLEAN *mRebasedFlag;
/**
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmInit.nasm
b/UefiCpuPkg/Library/SmmRelocationLib/Ia32/SmmInit.nasm
similarity index 53%
copy from UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmInit.nasm
copy to UefiCpuPkg/Library/SmmRelocationLib/Ia32/SmmInit.nasm
index b5e77a1a5b..3d845e9e16 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmInit.nasm
+++ b/UefiCpuPkg/Library/SmmRelocationLib/Ia32/SmmInit.nasm
@@ -1,7 +1,7 @@
;--
;
-; Copyright (c) 2016 - 2018, Intel Corporation. All rights reserved.
+; Copyright (c) 2024, Intel Corporation. All rights reserved.
; SPDX-License-Identifier: BSD-2-Clause-Patent
;
; Module Name:
;
; SmmInit.nasm
@@ -27,15 +27,70 @@ global ASM_PFX(gcSmmInitSize)
global ASM_PFX(gcSmmInitTemplate)
%define PROTECT_MODE_CS 0x8
%define PROTECT_MODE_DS 0x20
-SECTION .text
+SECTION .data
-ASM_PFX(gcSmiInitGdtr):
+NullSeg: DQ 0 ; reserved by architecture
+CodeSeg32:
+DW -1 ; LimitLow
+DW 0 ; BaseLow
+DB 0 ; BaseMid
+DB 0x9b
+DB 0xcf; LimitHigh
+DB 0 ; BaseHigh
+ProtModeCodeSeg32:
+
Re: [edk2-devel] [PATCH v2 02/10] UefiCpuPkg/SmmRelocationLib: Add SmmRelocationLib library instance
Comments below starting with [Ray]
Thanks,
Ray
From: Wu, Jiaxin
Sent: Tuesday, April 16, 2024 20:58
To: Ni, Ray ; devel@edk2.groups.io
Cc: Zeng, Star ; Gerd Hoffmann ; Kumar,
Rahul R
Subject: RE: [PATCH v2 02/10] UefiCpuPkg/SmmRelocationLib: Add SmmRelocationLib
library instance
/**
@@ -30,11 +30,12 @@ SemaphoreHook (
{
SMRAM_SAVE_STATE_MAP *CpuState;
mRebasedFlag = RebasedFlag;
- CpuState = (SMRAM_SAVE_STATE_MAP
*)(UINTN)(SMM_DEFAULT_SMBASE + SMRAM_SAVE_STATE_MAP_OFFSET);
+ CpuState = (SMRAM_SAVE_STATE_MAP *)(UINTN)(SMM_DEFAULT_SMBASE +
SMRAM_SAVE_STATE_MAP_OFFSET);
[Ray.1] This change is unnecessary.
[Jiaxin.1] it’s not only move the code to the new lib, but also do some
adaptation. For example here: the code style change to PASS the CI.
If no this change, can’t pass the CI check.
[Ray] Original code should also pass uncrustify checker. I guess you added one
blank line above so the alignment of "=" is not required.
[Ray.4] Can you evaluate what extra changes are required if allowing the lib
runs in flash area? Basically all global variables cannot be modified at
runtime.
[Jiaxin.4] The Lib needs to depend on the MP service PPI, it shall be called
during post-mem phase, global variables can’t be used?
[Ray] A PEIM could run in flash in post-mem phase. If you pass the values
across routines through parameters, most of the global variables can be avoided.
+ UINTN SmramRanges;
[Ray.6] No need SmramRanges.
[Jiaxin.6] replace it with DescriptorBlock ->NumberOfSmmReservedRegions
directly?
[Ray] yes.
+ //
+ // Increase the number of SMRAM descriptors by 1 to make room for the
ALLOCATED descriptor of size EFI_PAGE_SIZE
+ //
+ NewDescriptorBlock->NumberOfSmmReservedRegions = (UINT32)(SmramRanges + 1);
[Ray.9] NewBlock->NumberOfSmmReservedRegions++;
[Jiaxin.9] Agree since we copied the DescriptorBlock to NewDescriptorBlock
first. But I still think original is more easy to understand.
[Ray] As long as you remove local variable SmramRanges, I am fine.
+
+DEBUG ((DEBUG_INFO, "CreateSmmBaseHob -
SmmBaseHobData[%d]->ProcessorIndex: %03x\n", HobCount,
SmmBaseHobData->ProcessorIndex));
+DEBUG ((DEBUG_INFO, "CreateSmmBaseHob -
SmmBaseHobData[%d]->NumberOfProcessors: %03x\n", HobCount,
SmmBaseHobData->NumberOfProcessors));
+for (Index = 0; Index < SmmBaseHobData->NumberOfProcessors; Index++) {
+ //
+ // Calculate the new SMBASE address
+ //
+ SmmBaseHobData->SmBase[Index] = SmBaseForAllCpus[Index + CpuCount];
[Ray.12] Please re-organize the code so that SmBaseForAllCpus array is not
needed. What we need is only the Cpu0SmBase and TileSize.
[Jiaxin.12] do you mean calculate the value here? --> (UINTN)(Cpu0SmBase)+
Index * TileSize - SMM_HANDLER_OFFSET ?
I init the smbase value in the function of InitSmBaseForAllCpus(), the value
will be used in both ConfigureSmBase & CreateSmmBaseHob.
How about the ConfigureSmBase function during SmmRelocateBases()? What’s reason
you think SmBaseForAllCpus is not good?
[Ray] I just want to avoid unnecessary memory allocation.
+
+ //
+ // Patch SMI stack for SMM base relocation
+ // Note: No need allocate stack for all CPUs since the relocation
+ // occurs serially for each CPU
+ //
+ SmmStackSize = EFI_PAGES_TO_SIZE (EFI_SIZE_TO_PAGES (PcdGet32
(PcdCpuSmmStackSize)));
[Ray.15] PcdCpuSmmStackSize is configured by platform as only platform knows
what kind of SMI handlers will run in SMM env.
But in this case, all code is provided by this lib and stack size should be
fixed, maybe simply 1 page is enough.
[Jiaxin.15] agree, do you prefer this change as another patch or I just update
the hard code value directly in this patch?
[Ray] If the code is inherited from PiSmmCpuDxeSmm driver, you can do that
change in another patch.
+ //
+ // Retrieve the Processor Info for all CPUs
+ //
+ mProcessorInfo = (EFI_PROCESSOR_INFORMATION *)AllocatePool (sizeof
(EFI_PROCESSOR_INFORMATION) * mMaxNumberOfCpus);
[Ray.16] mProcessorInfo is needed when programming the new SMBASE. Then can you
just put the new SMBASE for every CPU in the stack top, or just patch the value
in the code region?
You can do that in a new patch.
[Jiaxin.16] why need such behavior? I only allocate one stack for all cpus with
existing design. The reason see below as I explained:
[Ray] My purpose is to avoid global variables.
+ //
+ // Initialize the SmBase for all CPUs
+ //
+ Status = InitSmBaseForAllCpus ();
[Ray.17] mSmBaseForAllCpus global variable is not needed. We only need
Cpu0Smbase and TileSize and the two can be local variables and passed to
further routines through parameters.
[Jiaxin.17] let me remove the mSmBaseForAllCpus global variable. But I still
think it’s not good to calculate value in different 2 places again and again
(Con
Re: [edk2-devel] [PATCH v4 6/6] StandaloneMmPkg: Support to unregister MMI handler in MMI handlers
Reviewed-by: Ray Ni
Thanks,
Ray
From: Liu, Zhiguang
Sent: Tuesday, April 16, 2024 10:41
To: devel@edk2.groups.io
Cc: Liu, Zhiguang ; Liming Gao
; Wu, Jiaxin ; Ni, Ray
; Laszlo Ersek ; Ard Biesheuvel
; Sami Mujawar
Subject: [PATCH v4 6/6] StandaloneMmPkg: Support to unregister MMI handler in
MMI handlers
This patch fix a use-after-free issue where unregistering an
MMI handler could lead to the deletion of the MMI_HANDLER while it is
still in use by MmiManage(). The fix involves modifying
MmiHandlerUnRegister() to detect whether it is being called from
within the MmiManage() stack. If so, the removal of the MMI_HANDLER
is deferred until MmiManage() has finished executing.
Additionally, due to the possibility of recursive MmiManage() calls,
the unregistration and subsequent removal of the MMI_HANDLER are
ensured to occur only after the outermost MmiManage() invocation has
completed.
Cc: Liming Gao
Cc: Jiaxin Wu
Cc: Ray Ni
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
Cc: Sami Mujawar
Signed-off-by: Zhiguang Liu
---
StandaloneMmPkg/Core/Mmi.c | 161 +++--
1 file changed, 136 insertions(+), 25 deletions(-)
diff --git a/StandaloneMmPkg/Core/Mmi.c b/StandaloneMmPkg/Core/Mmi.c
index 0de6fd17fc..e035245c87 100644
--- a/StandaloneMmPkg/Core/Mmi.c
+++ b/StandaloneMmPkg/Core/Mmi.c
@@ -34,11 +34,51 @@ typedef struct {
LIST_ENTRYLink;// Link on MMI_ENTRY.MmiHandlers
EFI_MM_HANDLER_ENTRY_POINTHandler; // The mm handler's entry point
MMI_ENTRY *MmiEntry;
+ BOOLEAN ToRemove;// To remove this MMI_HANDLER
later
} MMI_HANDLER;
+//
+// mMmiManageCallingDepth is used to track the depth of recursive calls of
MmiManage.
+//
+UINTN mMmiManageCallingDepth = 0;
+
LIST_ENTRY mRootMmiHandlerList = INITIALIZE_LIST_HEAD_VARIABLE
(mRootMmiHandlerList);
LIST_ENTRY mMmiEntryList = INITIALIZE_LIST_HEAD_VARIABLE
(mMmiEntryList);
+/**
+ Remove MmiHandler and free the memory it used.
+ If MmiEntry is empty, remove MmiEntry and free the memory it used.
+
+ @param MmiHandler Points to MMI handler.
+ @param MmiEntryPoints to MMI Entry or NULL for root MMI handlers.
+
+ @retval TRUEMmiEntry is removed.
+ @retval FALSE MmiEntry is not removed.
+**/
+BOOLEAN
+RemoveMmiHandler (
+ IN MMI_HANDLER *MmiHandler,
+ IN MMI_ENTRY*MmiEntry
+ )
+{
+ ASSERT (MmiHandler->ToRemove);
+ RemoveEntryList (>Link);
+ FreePool (MmiHandler);
+
+ //
+ // Remove the MMI_ENTRY if all handlers have been removed.
+ //
+ if (MmiEntry != NULL) {
+if (IsListEmpty (>MmiHandlers)) {
+ RemoveEntryList (>AllEntries);
+ FreePool (MmiEntry);
+ return TRUE;
+}
+ }
+
+ return FALSE;
+}
+
/**
Finds the MMI entry for the requested handler type.
@@ -126,13 +166,16 @@ MmiManage (
{
LIST_ENTRY *Link;
LIST_ENTRY *Head;
+ LIST_ENTRY *EntryLink;
MMI_ENTRY*MmiEntry;
MMI_HANDLER *MmiHandler;
- BOOLEAN SuccessReturn;
+ EFI_STATUS ReturnStatus;
+ BOOLEAN WillReturn;
EFI_STATUS Status;
- Status= EFI_NOT_FOUND;
- SuccessReturn = FALSE;
+ mMmiManageCallingDepth++;
+ Status = EFI_NOT_FOUND;
+ ReturnStatus = Status;
if (HandlerType == NULL) {
//
// Root MMI handler
@@ -171,7 +214,16 @@ MmiManage (
// no additional handlers will be processed and EFI_INTERRUPT_PENDING
will be returned.
//
if (HandlerType != NULL) {
- return EFI_INTERRUPT_PENDING;
+ ReturnStatus = EFI_INTERRUPT_PENDING;
+ WillReturn = TRUE;
+} else {
+ //
+ // If any other handler's result sets ReturnStatus as EFI_SUCCESS,
the return status
+ // will be EFI_SUCCESS.
+ //
+ if (ReturnStatus != EFI_SUCCESS) {
+ReturnStatus = Status;
+ }
}
break;
@@ -183,10 +235,10 @@ MmiManage (
// additional handlers will be processed.
//
if (HandlerType != NULL) {
- return EFI_SUCCESS;
+ WillReturn = TRUE;
}
-SuccessReturn = TRUE;
+ReturnStatus = EFI_SUCCESS;
break;
case EFI_WARN_INTERRUPT_SOURCE_QUIESCED:
@@ -194,7 +246,7 @@ MmiManage (
// If at least one of the handlers returns
EFI_WARN_INTERRUPT_SOURCE_QUIESCED
// then the function will return EFI_SUCCESS.
//
-SuccessReturn = TRUE;
+ReturnStatus = EFI_SUCCESS;
break;
case EFI_WARN_INTERRUPT_SOURCE_PENDING:
@@ -202,6 +254,10 @@ MmiManage (
// If all the handlers returned EFI_WARN_INTERRUPT_SOURCE_PENDING
// then EFI_WARN_INTERRUPT_SOURCE_PENDING will be returned.
//
+if (ReturnStatus != EFI_SUCCESS) {
+ ReturnStatus = Status;
+}
+
break;
default:
@@ -211,13 +267,76 @@ MmiManage (
ASSE
Re: [edk2-devel] [PATCH v4 5/6] MdeModulePkg/SMM: Support to unregister SMI handler in SMI handlers
Reviewed-by: Ray Ni
Thanks,
Ray
From: Liu, Zhiguang
Sent: Tuesday, April 16, 2024 10:41
To: devel@edk2.groups.io
Cc: Liu, Zhiguang ; Liming Gao
; Wu, Jiaxin ; Ni, Ray
; Laszlo Ersek
Subject: [PATCH v4 5/6] MdeModulePkg/SMM: Support to unregister SMI handler in
SMI handlers
This patch fix a use-after-free issue where unregistering an
SMI handler could lead to the deletion of the SMI_HANDLER while it is
still in use by SmiManage(). The fix involves modifying
SmiHandlerUnRegister() to detect whether it is being called from
within the SmiManage() stack. If so, the removal of the SMI_HANDLER
is deferred until SmiManage() has finished executing.
Additionally, due to the possibility of recursive SmiManage() calls,
the unregistration and subsequent removal of the SMI_HANDLER are
ensured to occur only after the outermost SmiManage() invocation has
completed.
Cc: Liming Gao
Cc: Jiaxin Wu
Cc: Ray Ni
Cc: Laszlo Ersek
Signed-off-by: Zhiguang Liu
---
MdeModulePkg/Core/PiSmmCore/PiSmmCore.h | 1 +
MdeModulePkg/Core/PiSmmCore/Smi.c | 164
2 files changed, 139 insertions(+), 26 deletions(-)
diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
index b8a490a8c3..60073c78b4 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
@@ -93,6 +93,7 @@ typedef struct {
SMI_ENTRY *SmiEntry;
VOID*Context;// for profile
UINTN ContextSize; // for profile
+ BOOLEAN ToRemove;// To remove this SMI_HANDLER
later
} SMI_HANDLER;
//
diff --git a/MdeModulePkg/Core/PiSmmCore/Smi.c
b/MdeModulePkg/Core/PiSmmCore/Smi.c
index 2985f989c3..a84a1f48d3 100644
--- a/MdeModulePkg/Core/PiSmmCore/Smi.c
+++ b/MdeModulePkg/Core/PiSmmCore/Smi.c
@@ -8,6 +8,11 @@
#include "PiSmmCore.h"
+//
+// mSmiManageCallingDepth is used to track the depth of recursive calls of
SmiManage.
+//
+UINTN mSmiManageCallingDepth = 0;
+
LIST_ENTRY mSmiEntryList = INITIALIZE_LIST_HEAD_VARIABLE (mSmiEntryList);
SMI_ENTRY mRootSmiEntry = {
@@ -79,6 +84,40 @@ SmmCoreFindSmiEntry (
return SmiEntry;
}
+/**
+ Remove SmiHandler and free the memory it used.
+ If SmiEntry is empty, remove SmiEntry and free the memory it used.
+
+ @param SmiHandler Points to SMI handler.
+ @param SmiEntry Points to SMI Entry or NULL for root SMI handlers.
+
+ @retval TRUESmiEntry is removed.
+ @retval FALSE SmiEntry is not removed.
+**/
+BOOLEAN
+RemoveSmiHandler (
+ IN SMI_HANDLER *SmiHandler,
+ IN SMI_ENTRY*SmiEntry
+ )
+{
+ ASSERT (SmiHandler->ToRemove);
+ RemoveEntryList (>Link);
+ FreePool (SmiHandler);
+
+ //
+ // Remove the SMI_ENTRY if all handlers have been removed.
+ //
+ if (SmiEntry != NULL) {
+if (IsListEmpty (>SmiHandlers)) {
+ RemoveEntryList (>AllEntries);
+ FreePool (SmiEntry);
+ return TRUE;
+}
+ }
+
+ return FALSE;
+}
+
/**
Manage SMI of a particular type.
@@ -104,15 +143,17 @@ SmiManage (
{
LIST_ENTRY *Link;
LIST_ENTRY *Head;
+ LIST_ENTRY *EntryLink;
SMI_ENTRY*SmiEntry;
SMI_HANDLER *SmiHandler;
- BOOLEAN SuccessReturn;
+ EFI_STATUS ReturnStatus;
+ BOOLEAN WillReturn;
EFI_STATUS Status;
PERF_FUNCTION_BEGIN ();
-
- Status= EFI_NOT_FOUND;
- SuccessReturn = FALSE;
+ mSmiManageCallingDepth++;
+ Status = EFI_NOT_FOUND;
+ ReturnStatus = Status;
if (HandlerType == NULL) {
//
// Root SMI handler
@@ -152,7 +193,16 @@ SmiManage (
//
if (HandlerType != NULL) {
PERF_FUNCTION_END ();
- return EFI_INTERRUPT_PENDING;
+ ReturnStatus = EFI_INTERRUPT_PENDING;
+ WillReturn = TRUE;
+} else {
+ //
+ // If any other handler's result sets ReturnStatus as EFI_SUCCESS,
the return status
+ // will be EFI_SUCCESS.
+ //
+ if (ReturnStatus != EFI_SUCCESS) {
+ReturnStatus = Status;
+ }
}
break;
@@ -165,10 +215,10 @@ SmiManage (
//
if (HandlerType != NULL) {
PERF_FUNCTION_END ();
- return EFI_SUCCESS;
+ WillReturn = TRUE;
}
-SuccessReturn = TRUE;
+ReturnStatus = EFI_SUCCESS;
break;
case EFI_WARN_INTERRUPT_SOURCE_QUIESCED:
@@ -176,7 +226,7 @@ SmiManage (
// If at least one of the handlers returns
EFI_WARN_INTERRUPT_SOURCE_QUIESCED
// then the function will return EFI_SUCCESS.
//
-SuccessReturn = TRUE;
+ReturnStatus = EFI_SUCCESS;
break;
case EFI_WARN_INTERRUPT_SOURCE_PENDING:
@@ -184,6 +234,10 @@ SmiManage (
// If all the handlers returned EFI_WARN_INTERRUPT_SOURCE_PENDING
// then EFI_WARN_INTERRUPT_SOURCE_PE
Re: [edk2-devel] [PATCH v4 00/13] Part 2 patch set to add LoongArch support into UefiCpuPkg
PR created for merge: Loongcpu by niruiyu · Pull Request #5560 · tianocore/edk2 (github.com)<https://github.com/tianocore/edk2/pull/5560> Thanks, Ray From: Chao Li Sent: Tuesday, April 16, 2024 10:42 To: devel@edk2.groups.io Cc: Ni, Ray ; Kumar, Rahul R ; Gerd Hoffmann ; Sami Mujawar ; Sunil V L ; Bibo Mao ; Dongyan Qian Subject: [PATCH v4 00/13] Part 2 patch set to add LoongArch support into UefiCpuPkg This patch set adjusted some order in UefiCpuPig alphabetically, added LoongArch libraries and drivers into UefiCpuPkg, it is a continuation of the first patch series v8 submitted at https://edk2.groups.io/g/devel/message/114526. And also separated from https://edk2.groups.io/g/devel/message/116583. This series only contents the changes for UefiCpuPkg. Patch1-Patch4: Reorder some INF files located in UefiCpuPkg alphabetically. Patch5-Patch13: Added Timer, CpuMmuLib, CpuMmuInitLib, MpInitLib, CpuDxe for LoongArch, and added some PCD and header files requested by the above libraries and drivers. Modfied modules: UefiCpuPkg BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4726 BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4734 PR: https://github.com/tianocore/edk2/pull/5483 V1 -> V2: 1. Removed PcdCpuMmuIsEnabled. 2. Removed API GetMemoryRegionAttributes API as it is no longer needed. 3. Patch3, added two empty line in DXE and PEI INF files. 4. Patch5, added the Status check in GetTimeInnanoSecond function. 5. Separated into two series, this is series one, and the second one is OvmfPkg. V2 -> V3: 1. Remove CpuMmuInitLib. 2. Added a new GUID HOB named PROCESSOR_RESOURCE_HOG_GUID. 3. Following Ray suggest, adjust CpuMmuLib API, rename the API name. 4. Rename the PcdCpuExceptionVectorBaseAddress to PcdLoongArch64ExceptionVectorBaseAddress. 5. Enable CpuMmio2Dxe in LoongArch. V3 -> V4: Patch 10, use flexible arrays in PROCESSOR_RESOURCE_DATA. Cc: Ray Ni Cc: Rahul Kumar Cc: Gerd Hoffmann Cc: Sami Mujawar Cc: Sunil V L Cc: Bibo Mao Cc: Dongyan Qian Chao Li (13): UefiCpuPkg/CpuTimerLib: Reorder the INF file alphabetically UefiCpuPkg/CpuExceptionHandlerLib: Reorder the INF files alphabetically UefiCpuPkg/MpInitLib: Reorder the INF files alphabetically UefiCpuPkg/CpuDxe: Reorder the INF file alphabetically UefiCpuPkg: Add LoongArch64 CPU Timer instance UefiCpuPkg: Add CPU exception library for LoongArch UefiCpuPkg: Add CpuMmuLib.h to UefiCpuPkg UefiCpuPkg: Added a new PCD named PcdLoongArchExceptionVectorBaseAddress UefiCpuPkg: Add CpuMmuLib to UefiCpuPkg UefiCpuPkg: Add a new GUID to store the processors resource UefiCpuPkg: Add multiprocessor library for LoongArch64 UefiCpuPkg: Add CpuDxe driver for LoongArch64 UefiCpuPkg/UefiCpuPkg.dsc: Add CpuMmio2Dxe.inf to LoongArch64 field UefiCpuPkg/CpuDxe/CpuDxe.inf | 39 +- UefiCpuPkg/CpuDxe/LoongArch64/CpuDxe.c| 514 ++ UefiCpuPkg/CpuDxe/LoongArch64/CpuDxe.h| 288 +++ UefiCpuPkg/CpuDxe/LoongArch64/CpuMp.c | 544 ++ UefiCpuPkg/CpuDxe/LoongArch64/Exception.c | 159 ++ .../Include/Guid/ProcessorResourceHob.h | 29 + UefiCpuPkg/Include/Library/CpuMmuLib.h| 41 + .../DxeCpuExceptionHandlerLib.inf | 37 +- .../LoongArch/DxeExceptionLib.c | 198 ++ .../LoongArch/ExceptionCommon.c | 171 ++ .../LoongArch/ExceptionCommon.h | 131 ++ .../LoongArch64/ArchExceptionHandler.c| 268 +++ .../LoongArch64/ExceptionHandlerAsm.S | 366 .../LoongArch/SecPeiExceptionLib.c| 102 ++ .../PeiCpuExceptionHandlerLib.inf | 16 +- .../SecPeiCpuExceptionHandlerLib.inf | 31 +- .../SmmCpuExceptionHandlerLib.inf | 16 +- UefiCpuPkg/Library/CpuMmuLib/CpuMmuLib.inf| 39 + UefiCpuPkg/Library/CpuMmuLib/CpuMmuLib.uni| 14 + .../Library/CpuMmuLib/LoongArch64/CpuMmu.c| 784 .../Library/CpuMmuLib/LoongArch64/Page.h | 33 + .../LoongArch64/TlbExceptionHandle.S | 51 + .../LoongArch64/TlbExceptionHandle.h | 36 + .../CpuMmuLib/LoongArch64/TlbInvalid.S| 24 + .../CpuMmuLib/LoongArch64/TlbInvalid.h| 24 + .../Library/CpuTimerLib/BaseCpuTimerLib.inf | 17 +- .../CpuTimerLib/LoongArch64/CpuTimerLib.c | 250 +++ UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf | 42 +- .../Library/MpInitLib/LoongArch64/DxeMpLib.c | 480 + .../Library/MpInitLib/LoongArch64/MpLib.c | 1626 + .../Library/MpInitLib/LoongArch64/MpLib.h | 350 .../Library/MpInitLib/LoongArch64/PeiMpLib.c | 381 UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf | 40 +- UefiCpuPkg/UefiCpuPkg.dec | 13 + UefiCpuPkg/UefiCpuPkg.dsc |7 + 35 files changed, 7082 insertions(+), 79 deletions(-) create mode 100644 UefiCpuPkg/CpuDxe/LoongArch64/CpuDxe.c create mode 100644 Ue
Re: [edk2-devel] [PATCH v2 03/10] UefiCpuPkg/SmmRelocationLib: Add library instance for AMD
Acked-by: Ray Ni
Thanks,
Ray
From: Wu, Jiaxin
Sent: Monday, April 15, 2024 21:30
To: devel@edk2.groups.io
Cc: Abdul Lateef Attar ; Abner Chang
; Tom Lendacky ; Ni, Ray
; Zeng, Star ; Gerd Hoffmann
; Kumar, Rahul R
Subject: [PATCH v2 03/10] UefiCpuPkg/SmmRelocationLib: Add library instance for
AMD
Due to the definition difference of SMRAM Save State,
SmmBase config in SMRAM Save State for AMD is also different.
This patch provides the AmdSmmRelocationLib library instance
to handle the SMRAM Save State difference.
Cc: Abdul Lateef Attar
Cc: Abner Chang
Cc: Tom Lendacky
Cc: Ray Ni
Cc: Zeng Star
Cc: Gerd Hoffmann
Cc: Rahul Kumar
Signed-off-by: Jiaxin Wu
---
...mmRelocationLib.inf => AmdSmmRelocationLib.inf} | 5 +-
...SaveStateConfig.c => AmdSmramSaveStateConfig.c} | 93 ++
UefiCpuPkg/UefiCpuPkg.dsc | 1 +
3 files changed, 46 insertions(+), 53 deletions(-)
copy UefiCpuPkg/Library/SmmRelocationLib/{SmmRelocationLib.inf =>
AmdSmmRelocationLib.inf} (89%)
copy UefiCpuPkg/Library/SmmRelocationLib/{SmramSaveStateConfig.c =>
AmdSmramSaveStateConfig.c} (50%)
diff --git a/UefiCpuPkg/Library/SmmRelocationLib/SmmRelocationLib.inf
b/UefiCpuPkg/Library/SmmRelocationLib/AmdSmmRelocationLib.inf
similarity index 89%
copy from UefiCpuPkg/Library/SmmRelocationLib/SmmRelocationLib.inf
copy to UefiCpuPkg/Library/SmmRelocationLib/AmdSmmRelocationLib.inf
index 6581fa2dad..710cd1948b 100644
--- a/UefiCpuPkg/Library/SmmRelocationLib/SmmRelocationLib.inf
+++ b/UefiCpuPkg/Library/SmmRelocationLib/AmdSmmRelocationLib.inf
@@ -13,18 +13,18 @@
##
[Defines]
INF_VERSION= 0x00010005
BASE_NAME = SmmRelocationLib
- FILE_GUID = 853E97B3-790C-4EA3-945C-8F622FC47FE8
+ FILE_GUID = 65C74DCD-0D09-494A-8BFF-A64226EB8054
MODULE_TYPE= PEIM
VERSION_STRING = 1.0
LIBRARY_CLASS = SmmRelocationLib
[Sources]
InternalSmmRelocationLib.h
- SmramSaveStateConfig.c
+ AmdSmramSaveStateConfig.c
SmmRelocationLib.c
[Sources.Ia32]
Ia32/Semaphore.c
Ia32/SmmInit.nasm
@@ -40,11 +40,10 @@
[LibraryClasses]
BaseLib
BaseMemoryLib
CpuExceptionHandlerLib
- CpuLib
DebugLib
HobLib
LocalApicLib
MemoryAllocationLib
PcdLib
diff --git a/UefiCpuPkg/Library/SmmRelocationLib/SmramSaveStateConfig.c
b/UefiCpuPkg/Library/SmmRelocationLib/AmdSmramSaveStateConfig.c
similarity index 50%
copy from UefiCpuPkg/Library/SmmRelocationLib/SmramSaveStateConfig.c
copy to UefiCpuPkg/Library/SmmRelocationLib/AmdSmramSaveStateConfig.c
index fb69b2b5c5..95a1ce8d46 100644
--- a/UefiCpuPkg/Library/SmmRelocationLib/SmramSaveStateConfig.c
+++ b/UefiCpuPkg/Library/SmmRelocationLib/AmdSmramSaveStateConfig.c
@@ -1,14 +1,17 @@
/** @file
Config SMRAM Save State for SmmBases Relocation.
+ Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
Copyright (c) 2024, Intel Corporation. All rights reserved.
SPDX-License-Identifier: BSD-2-Clause-Patent
**/
#include "InternalSmmRelocationLib.h"
-#include
+#include
+
+#define EFER_ADDRESS 0XC080ul
/**
Determine the mode of the CPU at the time an SMI occurs
@retval EFI_MM_SAVE_STATE_REGISTER_LMA_32BIT 32 bit.
@@ -18,44 +21,18 @@
UINT8
CheckMmSaveStateRegisterLma (
VOID
)
{
- CPUID_VERSION_INFO_EAX RegEax;
- CPUID_EXTENDED_CPU_SIG_EDX RegEdx;
- UINTN FamilyId;
- UINTN ModelId;
- UINT32 Eax;
- UINT8 SmmSaveStateRegisterLma;
-
- //
- // Determine the mode of the CPU at the time an SMI occurs
- // Intel(R) 64 and IA-32 Architectures Software Developer's Manual
- // Volume 3C, Section 34.4.1.1
- //
- RegEax.Uint32 = GetCpuFamilyModel ();
- FamilyId = RegEax.Bits.FamilyId;
- ModelId = RegEax.Bits.Model;
- if ((FamilyId == 0x06) || (FamilyId == 0x0f)) {
-ModelId = ModelId | RegEax.Bits.ExtendedModelId << 4;
- }
+ UINT8 SmmSaveStateRegisterLma;
+ UINT32 LMAValue;
- RegEdx.Uint32 = 0;
- AsmCpuid (CPUID_EXTENDED_FUNCTION, , NULL, NULL, NULL);
- if (Eax >= CPUID_EXTENDED_CPU_SIG) {
-AsmCpuid (CPUID_EXTENDED_CPU_SIG, NULL, NULL, NULL, &(RegEdx.Uint32));
- }
-
- SmmSaveStateRegisterLma = EFI_MM_SAVE_STATE_REGISTER_LMA_32BIT;
- if (RegEdx.Bits.LM) {
-SmmSaveStateRegisterLma = EFI_MM_SAVE_STATE_REGISTER_LMA_64BIT;
- }
+ SmmSaveStateRegisterLma = EFI_SMM_SAVE_STATE_REGISTER_LMA_32BIT;
- if (FamilyId == 0x06) {
-if ((ModelId == 0x17) || (ModelId == 0x0f) || (ModelId == 0x1c)) {
- SmmSaveStateRegisterLma = EFI_MM_SAVE_STATE_REGISTER_LMA_64BIT;
-}
+ LMAValue = (UINT32)AsmReadMsr64 (EFER_ADDRESS) & LMA;
+ if (LMAValue) {
+SmmSaveStateRegisterLma = EFI_SMM_SAVE_STATE_REGISTER_LMA_64BIT;
}
return SmmSaveStateRegi
Re: [edk2-devel] [PATCH v4 10/13] UefiCpuPkg: Add a new GUID to store the processors resource
Reviewed-by: Ray Ni
Thanks,
Ray
From: Chao Li
Sent: Tuesday, April 16, 2024 10:44
To: devel@edk2.groups.io
Cc: Ni, Ray ; Kumar, Rahul R ; Gerd
Hoffmann
Subject: [PATCH v4 10/13] UefiCpuPkg: Add a new GUID to store the processors
resource
On a multi-processor system, if the BSP dose not know how many APs are
online or cannot wake up the AP via broadcast, it can collect AP
resouces before wakeing up the AP and add a new HOB to save the
processor resouces.
Cc: Ray Ni
Cc: Rahul Kumar
Cc: Gerd Hoffmann
Signed-off-by: Chao Li
---
.../Include/Guid/ProcessorResourceHob.h | 29 +++
UefiCpuPkg/UefiCpuPkg.dec | 3 ++
2 files changed, 32 insertions(+)
create mode 100644 UefiCpuPkg/Include/Guid/ProcessorResourceHob.h
diff --git a/UefiCpuPkg/Include/Guid/ProcessorResourceHob.h
b/UefiCpuPkg/Include/Guid/ProcessorResourceHob.h
new file mode 100644
index 00..9890cc3ea9
--- /dev/null
+++ b/UefiCpuPkg/Include/Guid/ProcessorResourceHob.h
@@ -0,0 +1,29 @@
+/** @file
+ Processor resource HOB
+
+ If BSP does not known how many cores are online or the platform cannot
+ wake up AP via broadcast, this HOB can be used to store the processor
+ resource data that may come from ACPI or FDT, etc.
+
+ Copyright (c) 2024, Loongson Technology Corporation Limited. All rights
reserved.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef PROCESSOR_RESOURCE_HOB_H_
+#define PROCESSOR_RESOURCE_HOB_H_
+
+#define PROCESSOR_RESOURCE_HOB_GUID \
+ { \
+0xb855c7fe, 0xa758, 0x701f, { 0xa7, 0x30, 0x87, 0xf3, 0x9c, 0x03, 0x46,
0x7e } \
+ }
+
+typedef struct {
+ UINT32NumberOfProcessor;
+ UINTN ApicId[];
+} PROCESSOR_RESOURCE_DATA;
+
+extern EFI_GUID gProcessorResourceHobGuid;
+
+#endif
diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index 1b890e975c..8ca3b7a5a6 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -96,6 +96,9 @@ [Guids]
## Include/Guid/MpInformation2.h
gMpInformation2HobGuid = { 0x417a7f64, 0xf4e9, 0x4b32, {0x84, 0x6a,
0x5c, 0xc4, 0xd8, 0x62, 0x18, 0x79 }}
+ ## Include/Guid/ProcessorResourceHob.h
+ gProcessorResourceHobGuid = { 0xb855c7fe, 0xa758, 0x701f, { 0xa7, 0x30,
0x87, 0xf3, 0x9c, 0x03, 0x46, 0x7e }}
+
[Protocols]
## Include/Protocol/SmmCpuService.h
gEfiSmmCpuServiceProtocolGuid = { 0x1d202cab, 0xc8ab, 0x4d5c, { 0x94,
0xf7, 0x3c, 0xfc, 0xc0, 0xd3, 0xd3, 0x35 }}
--
2.27.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117839): https://edk2.groups.io/g/devel/message/117839
Mute This Topic: https://groups.io/mt/105550160/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 02/10] UefiCpuPkg/SmmRelocationLib: Add SmmRelocationLib library instance
Comments below starting with [Ray.xx]
Thanks,
Ray
/**
@@ -30,11 +30,12 @@ SemaphoreHook (
{
SMRAM_SAVE_STATE_MAP *CpuState;
mRebasedFlag = RebasedFlag;
- CpuState = (SMRAM_SAVE_STATE_MAP
*)(UINTN)(SMM_DEFAULT_SMBASE + SMRAM_SAVE_STATE_MAP_OFFSET);
+ CpuState = (SMRAM_SAVE_STATE_MAP *)(UINTN)(SMM_DEFAULT_SMBASE +
SMRAM_SAVE_STATE_MAP_OFFSET);
[Ray.1] This change is unnecessary.
+;---
+
+%include "StuffRsbNasm.inc"
+
+global ASM_PFX(gcSmmInitIdtr)
+global ASM_PFX(gcSmmInitGdtr)
+
+extern ASM_PFX(SmmInitHandler)
+extern ASM_PFX(mRebasedFlag)
+extern ASM_PFX(mSmmRelocationOriginalAddress)
+
+global ASM_PFX(gPatchSmmCr3)
+global ASM_PFX(gPatchSmmCr4)
+global ASM_PFX(gPatchSmmCr0)
+global ASM_PFX(gPatchSmmInitStack)
+global ASM_PFX(gcSmmInitSize)
+global ASM_PFX(gcSmmInitTemplate)
[Ray.2] Can you create another patch after this patch to rename the global
variables/functions to avoid using the same as PiSmmCpuDxeSmm driver?
+
+**/
+
+#ifndef INTERNAL_SMM_RELOCATION_LIB_H_
+#define INTERNAL_SMM_RELOCATION_LIB_H_
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
[Ray.3] Can you double confirm if all above headers are needed?
+
+extern UINT64 *mSmBaseForAllCpus;
+
+extern IA32_DESCRIPTOR gcSmmInitGdtr;
+extern IA32_DESCRIPTOR gcSmmInitIdtr;
+extern CONST UINT16 gcSmmInitSize;
+extern CONST UINT8 gcSmmInitTemplate[];
+
+X86_ASSEMBLY_PATCH_LABEL gPatchSmmCr0;
+X86_ASSEMBLY_PATCH_LABEL gPatchSmmCr3;
+X86_ASSEMBLY_PATCH_LABEL gPatchSmmCr4;
+X86_ASSEMBLY_PATCH_LABEL gPatchSmmInitStack;
[Ray.4] Can you evaluate what extra changes are required if allowing the lib
runs in flash area? Basically all global variables cannot be modified at
runtime.
+**/
+EFI_STATUS
+SplitSmramHobForSmmRelocation (
+ IN UINT64SmmRelocationSize,
+ IN OUT EFI_PHYSICAL_ADDRESS *SmmRelocationStart
+ )
+{
+ EFI_HOB_GUID_TYPE *GuidHob;
+ EFI_SMRAM_HOB_DESCRIPTOR_BLOCK *DescriptorBlock;
+ EFI_SMRAM_HOB_DESCRIPTOR_BLOCK *NewDescriptorBlock;
+ UINTN BufferSize;
[Ray.5] How about Block, NewBlock, NewBlockSize? It's simpler and easy to
understand.
+ UINTN SmramRanges;
[Ray.6] No need SmramRanges.
+
+ NewDescriptorBlock = NULL;
[Ray.7] No need of this line.
+
+ //
+ // Retrieve the GUID HOB data that contains the set of SMRAM descriptors
+ //
+ GuidHob = GetFirstGuidHob ();
+ if (GuidHob == NULL) {
+return EFI_NOT_FOUND;
+ }
+
+ DescriptorBlock = (EFI_SMRAM_HOB_DESCRIPTOR_BLOCK *)GET_GUID_HOB_DATA
(GuidHob);
+
+ //
+ // Allocate one extra EFI_SMRAM_DESCRIPTOR to describe SMRAM memory that
contains a pointer
+ // to the Smm relocated memory.
[Ray.8] "pointer" is a bit confusing.
"Allocate one extra EFI_SMRAM_DESCRIPTOR to describe smram carved out for all
SMBASE."
+ //
+ SmramRanges = DescriptorBlock->NumberOfSmmReservedRegions;
+ BufferSize = sizeof (EFI_SMRAM_HOB_DESCRIPTOR_BLOCK) + (SmramRanges *
sizeof (EFI_SMRAM_DESCRIPTOR));
+
+ NewDescriptorBlock = (EFI_SMRAM_HOB_DESCRIPTOR_BLOCK *)BuildGuidHob (
+
,
+ BufferSize
+ );
+ ASSERT (NewDescriptorBlock != NULL);
+ if (NewDescriptorBlock == NULL) {
+return EFI_DEVICE_ERROR;
+ }
+
+ //
+ // Copy old EFI_SMRAM_HOB_DESCRIPTOR_BLOCK to new allocated region
+ //
+ CopyMem ((VOID *)NewDescriptorBlock, DescriptorBlock, BufferSize - sizeof
(EFI_SMRAM_DESCRIPTOR));
+
+ //
+ // Increase the number of SMRAM descriptors by 1 to make room for the
ALLOCATED descriptor of size EFI_PAGE_SIZE
+ //
+ NewDescriptorBlock->NumberOfSmmReservedRegions = (UINT32)(SmramRanges + 1);
[Ray.9] NewBlock->NumberOfSmmReservedRegions++;
+
+ ASSERT (SmramRanges >= 1);
+ //
+ // Copy last entry to the end - we assume TSEG is last entry.
+ //
+ CopyMem (>Descriptor[SmramRanges],
>Descriptor[SmramRanges - 1], sizeof
(EFI_SMRAM_DESCRIPTOR));
+
+ //
+ // Update the entry in the array with a size of SmmRelocationSize and put
into the ALLOCATED state
+ //
+ NewDescriptorBlock->Descriptor[SmramRanges - 1].PhysicalSize =
SmmRelocationSize;
+ NewDescriptorBlock->Descriptor[SmramRanges - 1].RegionState |= EFI_ALLOCATED;
+
+ //
+ // Return the start address of Smm relocated memory in SMRAM.
+ //
+ if (SmmRelocationStart != NULL) {
[Ray.10] It's a local function and we know SmmRelocationStart is never NULL. No
need the if-check.
+EFI_STATUS
+CreateSmmBaseHob (
+ IN UINT64 *SmBaseForAllCpus
+ )
+{
+ UINTN Index;
+ SMM_BASE_HOB_DATA *SmmBaseHobData;
+ UINT32 CpuCount;
+ UINT32
Re: [edk2-devel] [PATCH v2 01/10] UefiCpuPkg: Add SmmRelocationLib class
Reviewed-by: Ray Ni Thanks, Ray From: Wu, Jiaxin Sent: Monday, April 15, 2024 21:30 To: devel@edk2.groups.io Cc: Ni, Ray ; Zeng, Star ; Gerd Hoffmann ; Kumar, Rahul R Subject: [PATCH v2 01/10] UefiCpuPkg: Add SmmRelocationLib class Intel plans to separate the smbase relocation logic from PiSmmCpuDxeSmm driver, and the related behavior will be moved to the new interface defined by the SmmRelocationLib class. The SmmRelocationLib class provides the SmmRelocationInit() interface for platform to do the smbase relocation, which shall provide below 2 functionalities: 1. Relocate smbases for each processor. 2. Create the gSmmBaseHobGuid HOB. With SmmRelocationLib, PiSmmCpuDxeSmm driver (which runs at a later phase) shall: 1. Consume the gSmmBaseHobGuid HOB for the relocated smbases for each Processor. 2. Execute the early SMM Init. This patch just provides the SmmRelocationLib class. Cc: Ray Ni Cc: Zeng Star Cc: Gerd Hoffmann Cc: Rahul Kumar Signed-off-by: Jiaxin Wu --- UefiCpuPkg/Include/Library/SmmRelocationLib.h | 42 +++ UefiCpuPkg/UefiCpuPkg.dec | 3 ++ 2 files changed, 45 insertions(+) create mode 100644 UefiCpuPkg/Include/Library/SmmRelocationLib.h diff --git a/UefiCpuPkg/Include/Library/SmmRelocationLib.h b/UefiCpuPkg/Include/Library/SmmRelocationLib.h new file mode 100644 index 00..999a5b46d1 --- /dev/null +++ b/UefiCpuPkg/Include/Library/SmmRelocationLib.h @@ -0,0 +1,42 @@ +/** @file + Header file for SMM Relocation Library. + + The SmmRelocationLib class provides the SmmRelocationInit() + interface for platform to do the smbase relocation, which + shall provide below 2 functionalities: + 1. Relocate SmBases for each processor. + 2. Create the SmBase HOB (gSmmBaseHobGuid). + + With SmmRelocationLib, PiSmmCpuDxeSmm driver (which runs at a later phase) + shall: + 1. Consume the gSmmBaseHobGuid for the relocated smbase for each Processor. + 2. Execute early SMM init. + + Copyright (c) 2024, Intel Corporation. All rights reserved. + SPDX-License-Identifier: BSD-2-Clause-Patent + +**/ + +#ifndef SMM_RELOCATION_LIB_H_ +#define SMM_RELOCATION_LIB_H_ + +#include + +/** + CPU SmmBase Relocation Init. + + This function is to relocate CPU SmmBase. + + @param[in] MpServices2Pointer to this instance of the MpServices. + + @retval EFI_SUCCESS CPU SmmBase Relocated successfully. + @retval OthersCPU SmmBase Relocation failed. + +**/ +EFI_STATUS +EFIAPI +SmmRelocationInit ( + IN EDKII_PEI_MP_SERVICES2_PPI *MpServices2 + ); + +#endif diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec index 571b59b36f..1d7890f19e 100644 --- a/UefiCpuPkg/UefiCpuPkg.dec +++ b/UefiCpuPkg/UefiCpuPkg.dec @@ -65,10 +65,13 @@ MmSaveStateLib|Include/Library/MmSaveStateLib.h ## @libraryclass Provides functions for SMM CPU Sync Operation. SmmCpuSyncLib|Include/Library/SmmCpuSyncLib.h + ## @libraryclass Provides functions for SMM Relocation Operation. + SmmRelocationLib|Include/Library/SmmRelocationLib.h + [LibraryClasses.RISCV64] ## @libraryclass Provides functions to manage MMU features on RISCV64 CPUs. ## RiscVMmuLib|Include/Library/BaseRiscVMmuLib.h -- 2.16.2.windows.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#117815): https://edk2.groups.io/g/devel/message/117815 Mute This Topic: https://groups.io/mt/105535805/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 1/1] MdeModulePkg/XhciDxe: Reset endpoint while USB Transaction error
Liming,
Can you give a R-B?
Thanks,
Ray
From: Cai, Xianglei
Sent: Friday, April 12, 2024 9:53
To: Lewandowski, Krzysztof ;
devel@edk2.groups.io ; Ni, Ray ; Liming
Gao
Cc: Huang, Jenny ; Shih, More
Subject: RE: [PATCH 1/1] MdeModulePkg/XhciDxe: Reset endpoint while USB
Transaction error
@Ni, Ray<mailto:ray...@intel.com> @Liming
Gao<mailto:gaolim...@byosoft.com.cn>Would you like to merge the patch to
upstream?
Thanks,
Xianglei
From: Lewandowski, Krzysztof
Sent: Thursday, April 11, 2024 9:45 PM
To: devel@edk2.groups.io
Cc: Ni, Ray ; Liming Gao ; Huang,
Jenny ; Shih, More ; Cai, Xianglei
Subject: Re: [PATCH 1/1] MdeModulePkg/XhciDxe: Reset endpoint while USB
Transaction error
Looks good to me.
Reviewed-by: Krzysztof Lewandowski
mailto:krzysztof.lewandow...@intel.com>>
From: Cai, Xianglei mailto:xianglei@intel.com>>
Sent: Wednesday, April 10, 2024 09:02
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
mailto:devel@edk2.groups.io>>
Cc: Cai, Xianglei mailto:xianglei@intel.com>>; Ni,
Ray mailto:ray...@intel.com>>; Liming Gao
mailto:gaolim...@byosoft.com.cn>>; Lewandowski,
Krzysztof
mailto:krzysztof.lewandow...@intel.com>>;
Huang, Jenny mailto:jenny.hu...@intel.com>>; Shih, More
mailto:more.s...@intel.com>>
Subject: [PATCH 1/1] MdeModulePkg/XhciDxe: Reset endpoint while USB Transaction
error
https://bugzilla.tianocore.org/show_bug.cgi?id=4556
Based on XHCI spec 4.8.3, software should do the
reset endpoint while USB Transaction occur.
Also add the error code for USB Transaction error
since UEFI spec don't have the related definition.
Cc: Ray Ni
mailto:ray...@intel.com>>
Cc: Liming Gao
mailto:gaolim...@byosoft.com.cn>>
Cc: Krzysztof Lewandowski
mailto:krzysztof.lewandow...@intel.com>>
Cc: Jenny Huang
mailto:jenny.hu...@intel.com>>
Cc: More Shih
mailto:more.s...@intel.com>>
Signed-off-by: Xianglei Cai
mailto:xianglei@intel.com>>
---
MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c | 2 +-
MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c | 2 +-
MdePkg/Include/Protocol/UsbIo.h | 21 +++--
3 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
index f4e61d223c1b..63cc29b26536 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
@@ -825,7 +825,7 @@ XhcTransfer (
*TransferResult = Urb->Result;
*DataLength = Urb->Completed;
- if ((*TransferResult == EFI_USB_ERR_STALL) || (*TransferResult ==
EFI_USB_ERR_BABBLE)) {
+ if ((*TransferResult == EFI_USB_ERR_STALL) || (*TransferResult ==
EFI_USB_ERR_BABBLE) || (*TransferResult == EFI_USB_ERR_TRANSACTION)) {
ASSERT (Status == EFI_DEVICE_ERROR);
RecoveryStatus = XhcRecoverHaltedEndpoint (Xhc, Urb);
if (EFI_ERROR (RecoveryStatus)) {
diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
index 05528a478baf..e77852f62f10 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
@@ -1193,7 +1193,7 @@ XhcCheckUrbResult (
goto EXIT;
case TRB_COMPLETION_USB_TRANSACTION_ERROR:
-CheckedUrb->Result |= EFI_USB_ERR_TIMEOUT;
+CheckedUrb->Result |= EFI_USB_ERR_TRANSACTION;
CheckedUrb->Finished = TRUE;
DEBUG ((DEBUG_ERROR, "XhcCheckUrbResult: TRANSACTION_ERROR!
Completecode = %x\n", EvtTrb->Completecode));
goto EXIT;
diff --git a/MdePkg/Include/Protocol/UsbIo.h b/MdePkg/Include/Protocol/UsbIo.h
index a780b4e07b44..211ef0c94156 100644
--- a/MdePkg/Include/Protocol/UsbIo.h
+++ b/MdePkg/Include/Protocol/UsbIo.h
@@ -50,16 +50,17 @@ typedef enum {
//
// USB Transfer Results
//
-#define EFI_USB_NOERROR 0x00
-#define EFI_USB_ERR_NOTEXECUTE 0x01
-#define EFI_USB_ERR_STALL 0x02
-#define EFI_USB_ERR_BUFFER 0x04
-#define EFI_USB_ERR_BABBLE 0x08
-#define EFI_USB_ERR_NAK 0x10
-#define EFI_USB_ERR_CRC 0x20
-#define EFI_USB_ERR_TIMEOUT 0x40
-#define EFI_USB_ERR_BITSTUFF0x80
-#define EFI_USB_ERR_SYSTEM 0x100
+#define EFI_USB_NOERROR 0x00
+#define EFI_USB_ERR_NOTEXECUTE 0x01
+#define EFI_USB_ERR_STALL0x02
+#define EFI_USB_ERR_BUFFER 0x04
+#define EFI_USB_ERR_BABBLE 0x08
+#define EFI_USB_ERR_NAK 0x10
+#define EFI_USB_ERR_CRC 0x20
+#define EFI_USB_ERR_TIMEOUT 0x40
+#define EFI_USB_ERR_BITSTUFF 0x80
+#define EFI_USB_ERR_SYSTEM 0x100
+#define EFI_USB_ERR_TRANSACTION 0x200
/**
Async USB transfer callback routine.
--
2.42.0.windows.2
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent t
Re: [edk2-devel] [PATCH v3 00/13] Part 2 patch set to add LoongArch support into UefiCpuPkg
Chao, I've replied all of your patches. Only for patch "[edk2-devel] [PATCH v3 10/13] UefiCpuPkg: Add a new GUID to store the processors resource", I have one comment. Others look good to me. Thanks, Ray From: Chao Li Sent: Friday, April 12, 2024 15:32 To: devel@edk2.groups.io Cc: Ni, Ray ; Kumar, Rahul R ; Gerd Hoffmann ; Sami Mujawar ; Sunil V L ; Bibo Mao ; Dongyan Qian Subject: [PATCH v3 00/13] Part 2 patch set to add LoongArch support into UefiCpuPkg This patch set adjusted some order in UefiCpuPig alphabetically, added LoongArch libraries and drivers into UefiCpuPkg, it is a continuation of the first patch series v8 submitted at https://edk2.groups.io/g/devel/message/114526. And also separated from https://edk2.groups.io/g/devel/message/116583. This series only contents the changes for UefiCpuPkg. Patch1-Patch4: Reorder some INF files located in UefiCpuPkg alphabetically. Patch5-Patch13: Added Timer, CpuMmuLib, CpuMmuInitLib, MpInitLib, CpuDxe for LoongArch, and added some PCD and header files requested by the above libraries and drivers. Modfied modules: UefiCpuPkg BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4726 BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4734 PR: https://github.com/tianocore/edk2/pull/5483 V1 -> V2: 1. Removed PcdCpuMmuIsEnabled. 2. Removed API GetMemoryRegionAttributes API as it is no longer needed. 3. Patch3, added two empty line in DXE and PEI INF files. 4. Patch5, added the Status check in GetTimeInnanoSecond function. 5. Separated into two series, this is series one, and the second one is OvmfPkg. V2 -> V3: 1. Remove CpuMmuInitLib. 2. Added a new GUID HOB named PROCESSOR_RESOURCE_HOG_GUID. 3. Following Ray suggest, adjust CpuMmuLib API, rename the API name. 4. Rename the PcdCpuExceptionVectorBaseAddress to PcdLoongArch64ExceptionVectorBaseAddress. 5. Enable CpuMmio2Dxe in LoongArch. Cc: Ray Ni Cc: Rahul Kumar Cc: Gerd Hoffmann Cc: Sami Mujawar Cc: Sunil V L Cc: Bibo Mao Cc: Dongyan Qian Chao Li (13): UefiCpuPkg/CpuTimerLib: Reorder the INF file alphabetically UefiCpuPkg/CpuExceptionHandlerLib: Reorder the INF files alphabetically UefiCpuPkg/MpInitLib: Reorder the INF files alphabetically UefiCpuPkg/CpuDxe: Reorder the INF file alphabetically UefiCpuPkg: Add LoongArch64 CPU Timer instance UefiCpuPkg: Add CPU exception library for LoongArch UefiCpuPkg: Add CpuMmuLib.h to UefiCpuPkg UefiCpuPkg: Added a new PCD named PcdLoongArchExceptionVectorBaseAddress UefiCpuPkg: Add CpuMmuLib to UefiCpuPkg UefiCpuPkg: Add a new GUID to store the processors resource UefiCpuPkg: Add multiprocessor library for LoongArch64 UefiCpuPkg: Add CpuDxe driver for LoongArch64 UefiCpuPkg/UefiCpuPkg.dsc: Add CpuMmio2Dxe.inf to LoongArch64 field UefiCpuPkg/CpuDxe/CpuDxe.inf | 39 +- UefiCpuPkg/CpuDxe/LoongArch64/CpuDxe.c| 439 + UefiCpuPkg/CpuDxe/LoongArch64/CpuDxe.h| 288 +++ UefiCpuPkg/CpuDxe/LoongArch64/CpuMp.c | 544 ++ UefiCpuPkg/CpuDxe/LoongArch64/Exception.c | 159 ++ .../Include/Guid/ProcessorResourceHob.h | 29 + UefiCpuPkg/Include/Library/CpuMmuLib.h| 41 + .../DxeCpuExceptionHandlerLib.inf | 37 +- .../LoongArch/DxeExceptionLib.c | 198 ++ .../LoongArch/ExceptionCommon.c | 171 ++ .../LoongArch/ExceptionCommon.h | 131 ++ .../LoongArch64/ArchExceptionHandler.c| 268 +++ .../LoongArch64/ExceptionHandlerAsm.S | 366 .../LoongArch/SecPeiExceptionLib.c| 102 ++ .../PeiCpuExceptionHandlerLib.inf | 16 +- .../SecPeiCpuExceptionHandlerLib.inf | 31 +- .../SmmCpuExceptionHandlerLib.inf | 16 +- UefiCpuPkg/Library/CpuMmuLib/CpuMmuLib.inf| 39 + UefiCpuPkg/Library/CpuMmuLib/CpuMmuLib.uni| 14 + .../Library/CpuMmuLib/LoongArch64/CpuMmu.c| 785 .../Library/CpuMmuLib/LoongArch64/Page.h | 33 + .../LoongArch64/TlbExceptionHandle.S | 51 + .../LoongArch64/TlbExceptionHandle.h | 36 + .../CpuMmuLib/LoongArch64/TlbInvalid.S| 24 + .../CpuMmuLib/LoongArch64/TlbInvalid.h| 24 + .../Library/CpuTimerLib/BaseCpuTimerLib.inf | 17 +- .../CpuTimerLib/LoongArch64/CpuTimerLib.c | 250 +++ UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf | 42 +- .../Library/MpInitLib/LoongArch64/DxeMpLib.c | 480 + .../Library/MpInitLib/LoongArch64/MpLib.c | 1626 + .../Library/MpInitLib/LoongArch64/MpLib.h | 350 .../Library/MpInitLib/LoongArch64/PeiMpLib.c | 381 UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf | 40 +- UefiCpuPkg/UefiCpuPkg.dec | 13 + UefiCpuPkg/UefiCpuPkg.dsc |7 + 35 files changed, 7008 insertions(+), 79 deletions(-) create mode 100644 UefiCpuPkg/CpuDxe/LoongArch64/CpuDxe.c create mode 100644 UefiCpuPkg/Cp
Re: [edk2-devel] [PATCH v3 13/13] UefiCpuPkg/UefiCpuPkg.dsc: Add CpuMmio2Dxe.inf to LoongArch64 field
Reviewed-by: Ray Ni Thanks, Ray From: Chao Li Sent: Friday, April 12, 2024 15:34 To: devel@edk2.groups.io Cc: Ni, Ray ; Kumar, Rahul R ; Gerd Hoffmann Subject: [PATCH v3 13/13] UefiCpuPkg/UefiCpuPkg.dsc: Add CpuMmio2Dxe.inf to LoongArch64 field LoongArch64 requires CpuMmio2Dxe, add it into LoongArch64 field. Cc: Ray Ni Cc: Rahul Kumar Cc: Gerd Hoffmann Signed-off-by: Chao Li --- UefiCpuPkg/UefiCpuPkg.dsc | 1 + 1 file changed, 1 insertion(+) diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc index e92ceb6466..1af5a0c525 100644 --- a/UefiCpuPkg/UefiCpuPkg.dsc +++ b/UefiCpuPkg/UefiCpuPkg.dsc @@ -213,6 +213,7 @@ [Components.RISCV64] [Components.LOONGARCH64] UefiCpuPkg/Library/CpuMmuLib/CpuMmuLib.inf + UefiCpuPkg/CpuMmio2Dxe/CpuMmio2Dxe.inf [BuildOptions] *_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES -- 2.27.0 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#117743): https://edk2.groups.io/g/devel/message/117743 Mute This Topic: https://groups.io/mt/105478504/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v3 09/13] UefiCpuPkg: Add CpuMmuLib to UefiCpuPkg
Acked-by: Ray Ni
Thanks,
Ray
From: Chao Li
Sent: Friday, April 12, 2024 15:34
To: devel@edk2.groups.io
Cc: Ni, Ray ; Kumar, Rahul R ; Gerd
Hoffmann ; Baoqi Zhang ; Dongyan
Qian ; Xianglai Li ; Bibo Mao
Subject: [PATCH v3 09/13] UefiCpuPkg: Add CpuMmuLib to UefiCpuPkg
Add a new base library named CpuMmuLib and add a LoongArch64 instance
with in the library.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4734
Cc: Ray Ni
Cc: Rahul Kumar
Cc: Gerd Hoffmann
Signed-off-by: Chao Li
Co-authored-by: Baoqi Zhang
Co-authored-by: Dongyan Qian
Co-authored-by: Xianglai Li
Co-authored-by: Bibo Mao
Acked-by: Gerd Hoffmann
---
UefiCpuPkg/Library/CpuMmuLib/CpuMmuLib.inf| 39 +
UefiCpuPkg/Library/CpuMmuLib/CpuMmuLib.uni| 14 +
.../Library/CpuMmuLib/LoongArch64/CpuMmu.c| 785 ++
.../Library/CpuMmuLib/LoongArch64/Page.h | 33 +
.../LoongArch64/TlbExceptionHandle.S | 51 ++
.../LoongArch64/TlbExceptionHandle.h | 36 +
.../CpuMmuLib/LoongArch64/TlbInvalid.S| 24 +
.../CpuMmuLib/LoongArch64/TlbInvalid.h| 24 +
UefiCpuPkg/UefiCpuPkg.dsc | 3 +
9 files changed, 1009 insertions(+)
create mode 100644 UefiCpuPkg/Library/CpuMmuLib/CpuMmuLib.inf
create mode 100644 UefiCpuPkg/Library/CpuMmuLib/CpuMmuLib.uni
create mode 100644 UefiCpuPkg/Library/CpuMmuLib/LoongArch64/CpuMmu.c
create mode 100644 UefiCpuPkg/Library/CpuMmuLib/LoongArch64/Page.h
create mode 100644
UefiCpuPkg/Library/CpuMmuLib/LoongArch64/TlbExceptionHandle.S
create mode 100644
UefiCpuPkg/Library/CpuMmuLib/LoongArch64/TlbExceptionHandle.h
create mode 100644 UefiCpuPkg/Library/CpuMmuLib/LoongArch64/TlbInvalid.S
create mode 100644 UefiCpuPkg/Library/CpuMmuLib/LoongArch64/TlbInvalid.h
diff --git a/UefiCpuPkg/Library/CpuMmuLib/CpuMmuLib.inf
b/UefiCpuPkg/Library/CpuMmuLib/CpuMmuLib.inf
new file mode 100644
index 00..5eecfb4838
--- /dev/null
+++ b/UefiCpuPkg/Library/CpuMmuLib/CpuMmuLib.inf
@@ -0,0 +1,39 @@
+## @file
+# CPU Memory Manager Unit library instance.
+#
+# Copyright (c) 2024 Loongson Technology Corporation Limited. All rights
reserved.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+ INF_VERSION= 1.29
+ BASE_NAME = CpuMmuLib
+ MODULE_UNI_FILE= CpuMmuLib.uni
+ FILE_GUID = DA8F0232-FB14-42F0-922C-63104D2C70BE
+ MODULE_TYPE= BASE
+ VERSION_STRING = 1.0
+ LIBRARY_CLASS = CpuMmuLib
+
+#
+# VALID_ARCHITECTURES = LOONGARCH64
+#
+
+[Sources.LoongArch64]
+ LoongArch64/TlbInvalid.S | GCC
+ LoongArch64/TlbExceptionHandle.S | GCC
+ LoongArch64/CpuMmu.c
+ LoongArch64/Page.h
+ LoongArch64/TlbInvalid.h
+
+[Packages]
+ MdePkg/MdePkg.dec
+ UefiCpuPkg/UefiCpuPkg.dec
+
+[LibraryClasses]
+ DebugLib
+ MemoryAllocationLib
+
+[Pcd.LoongArch64]
+ gUefiCpuPkgTokenSpaceGuid.PcdLoongArchExceptionVectorBaseAddress ##
CONSUMES
diff --git a/UefiCpuPkg/Library/CpuMmuLib/CpuMmuLib.uni
b/UefiCpuPkg/Library/CpuMmuLib/CpuMmuLib.uni
new file mode 100644
index 00..2408f2f90b
--- /dev/null
+++ b/UefiCpuPkg/Library/CpuMmuLib/CpuMmuLib.uni
@@ -0,0 +1,14 @@
+// /** @file
+// CPU Memory Manager Unit library instance.
+//
+// CPU Memory Manager Unit library instance.
+//
+// Copyright (c) 2024, Loongson Technology Corporation Limited. All rights
reserved.
+//
+// SPDX-License-Identifier: BSD-2-Clause-Patent
+//
+// **/
+
+#string STR_MODULE_ABSTRACT #language en-US "CPU Memory Manager
Unit library instance."
+
+#string STR_MODULE_DESCRIPTION #language en-US "CPU Memory Manager
Unit library instance."
diff --git a/UefiCpuPkg/Library/CpuMmuLib/LoongArch64/CpuMmu.c
b/UefiCpuPkg/Library/CpuMmuLib/LoongArch64/CpuMmu.c
new file mode 100644
index 00..6d77a1221f
--- /dev/null
+++ b/UefiCpuPkg/Library/CpuMmuLib/LoongArch64/CpuMmu.c
@@ -0,0 +1,785 @@
+/** @file
+
+ CPU Memory Map Unit Handler Library common functions.
+
+ Copyright (c) 2011-2020, ARM Limited. All rights reserved.
+ Copyright (c) 2016, Linaro Limited. All rights reserved.
+ Copyright (c) 2017, Intel Corporation. All rights reserved.
+ Copyright (c) 2023, Ventana Micro Systems Inc. All Rights Reserved.
+ Copyright (c) 2024 Loongson Technology Corporation Limited. All rights
reserved.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "TlbInvalid.h"
+#include "TlbExceptionHandle.h"
+#include "Page.h"
+
+/**
+ Check to see if mmu successfully initializes.
+
+ @param VOID.
+
+ @retval TRUE Initialization has been completed.
+ FALSE Initialization did not complete.
+**/
+STATIC
+BOOLEAN
+MmuIsInit (
+ VOID
+ )
+{
+ if (CsrRead (LOONGARCH_CSR_PGDL) != 0) {
+retur
Re: [edk2-devel] [PATCH v3 08/13] UefiCpuPkg: Added a new PCD named PcdLoongArchExceptionVectorBaseAddress
Reviewed-by: Ray Ni Thanks, Ray From: Chao Li Sent: Friday, April 12, 2024 15:34 To: devel@edk2.groups.io Cc: Ni, Ray ; Kumar, Rahul R ; Gerd Hoffmann Subject: [PATCH v3 08/13] UefiCpuPkg: Added a new PCD named PcdLoongArchExceptionVectorBaseAddress Added PcdLoongArchExceptionVectorBaseAddress use for storing the CPU exception vector base address. This PCD can be populated at build time or changed at runtime, and is used only by LoongArch. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4734 Cc: Ray Ni Cc: Rahul Kumar Cc: Gerd Hoffmann Signed-off-by: Chao Li Acked-by: Gerd Hoffmann --- UefiCpuPkg/UefiCpuPkg.dec | 6 ++ 1 file changed, 6 insertions(+) diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec index ca744fab55..1b890e975c 100644 --- a/UefiCpuPkg/UefiCpuPkg.dec +++ b/UefiCpuPkg/UefiCpuPkg.dec @@ -3,6 +3,7 @@ # # Copyright (c) 2007 - 2023, Intel Corporation. All rights reserved. # Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved. +# Copyright (c) 2024, Loongson Technology Corporation Limited. All rights reserved. # # SPDX-License-Identifier: BSD-2-Clause-Patent # @@ -414,6 +415,11 @@ [PcdsFixedAtBuild.RISCV64] # 10 - 57bit mode. gUefiCpuPkgTokenSpaceGuid.PcdCpuRiscVMmuMaxSatpMode|10|UINT32|0x6021 +[PcdsFixedAtBuild.LOONGARCH64, PcdsPatchableInModule.LOONGARCH64, PcdsDynamic.LOONGARCH64, PcdsDynamicEx.LOONGARCH64] + ## This PCD Contains the pointer to a CPU exception vector base address. + # @Prompt The pointer to a CPU exception vector base address. + gUefiCpuPkgTokenSpaceGuid.PcdLoongArchExceptionVectorBaseAddress|0x0|UINT64|0x6022 + [PcdsDynamic, PcdsDynamicEx] ## Contains the pointer to a CPU S3 data buffer of structure ACPI_CPU_DATA. # @Prompt The pointer to a CPU S3 data buffer. -- 2.27.0 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#117740): https://edk2.groups.io/g/devel/message/117740 Mute This Topic: https://groups.io/mt/105478499/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v3 07/13] UefiCpuPkg: Add CpuMmuLib.h to UefiCpuPkg
Reviewed-by: Ray Ni
Thanks,
Ray
From: Chao Li
Sent: Friday, April 12, 2024 15:34
To: devel@edk2.groups.io
Cc: Ni, Ray ; Kumar, Rahul R ; Gerd
Hoffmann ; Leif Lindholm ; Ard
Biesheuvel ; Sami Mujawar ;
Sunil V L ; Warkentin, Andrei
Subject: [PATCH v3 07/13] UefiCpuPkg: Add CpuMmuLib.h to UefiCpuPkg
Add a new header file CpuMmuLib.h, whitch is referenced from
ArmPkg/Include/Library/ArmMmuLib.h. Currently, only support for
LoongArch64 is added, and more architectures can be accommodated in the
future.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4734
Cc: Ray Ni
Cc: Rahul Kumar
Cc: Gerd Hoffmann
Cc: Leif Lindholm
Cc: Ard Biesheuvel
Cc: Sami Mujawar
Cc: Sunil V L
Cc: Andrei Warkentin
Signed-off-by: Chao Li
Acked-by: Gerd Hoffmann
---
UefiCpuPkg/Include/Library/CpuMmuLib.h | 41 ++
UefiCpuPkg/UefiCpuPkg.dec | 4 +++
2 files changed, 45 insertions(+)
create mode 100644 UefiCpuPkg/Include/Library/CpuMmuLib.h
diff --git a/UefiCpuPkg/Include/Library/CpuMmuLib.h
b/UefiCpuPkg/Include/Library/CpuMmuLib.h
new file mode 100644
index 00..e6cfbd5168
--- /dev/null
+++ b/UefiCpuPkg/Include/Library/CpuMmuLib.h
@@ -0,0 +1,41 @@
+/** @file
+
+ Copyright (c) 2024 Loongson Technology Corporation Limited. All rights
reserved.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef CPU_MMU_LIB_H_
+#define CPU_MMU_LIB_H_
+
+#include
+
+/**
+ Maps the memory region in the page table to the specified attributes.
+
+ @param[in, out] PageTable The pointer to the page table to update, or
pointer to NULL
+ if a new page table is to be created.
+ @param[in] PageWalkCfgThe page walk controller configure.
+ @param[in] BaseAddressThe base address of the memory region to set
the Attributes.
+ @param[in] Length The length of the memory region to set the
Attributes.
+ @param[in] Attributes The bitmask of attributes to set, which refer
to UEFI SPEC
+ 7.2.3(EFI_BOOT_SERVICES.GetMemoryMap()).
+ @param[in] AttributeMask Mask of memory attributes to take into
account.
+
+ @retval EFI_SUCCESSThe Attributes was set successfully or Length
is 0.
+ @retval EFI_INVALID_PARAMETER PageTable is NULL.
+ @retval EFI_UNSUPPORTED*PageTable is NULL.
+**/
+EFI_STATUS
+EFIAPI
+MemoryRegionMap (
+ IN OUT UINTN *PageTable OPTIONAL,
+ IN UINT64PageWalkCfg,
+ IN EFI_PHYSICAL_ADDRESS BaseAddress,
+ IN UINT64Length,
+ IN UINT64Attributes,
+ IN UINT64AttributeMask
+ );
+
+#endif // CPU_MMU_LIB_H_
diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index 571b59b36f..ca744fab55 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -72,6 +72,10 @@ [LibraryClasses.RISCV64]
##
RiscVMmuLib|Include/Library/BaseRiscVMmuLib.h
+[LibraryClasses.LoongArch64]
+ ## @libraryclass Provides functions for the memory management unit.
+ CpuMmuLib|Include/Library/CpuMmuLib.h
+
[Guids]
gUefiCpuPkgTokenSpaceGuid = { 0xac05bf33, 0x995a, 0x4ed4, { 0xaa, 0xb8,
0xef, 0x7a, 0xe8, 0xf, 0x5c, 0xb0 }}
gMsegSmramGuid = { 0x5802bce4, 0x, 0x4e33, { 0xa1, 0x30,
0xeb, 0xad, 0x27, 0xf0, 0xe4, 0x39 }}
--
2.27.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117739): https://edk2.groups.io/g/devel/message/117739
Mute This Topic: https://groups.io/mt/105478496/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v3 10/13] UefiCpuPkg: Add a new GUID to store the processors resource
+
+typedef struct {
+ UINT32NumberOfProcessor;
+ UINTN *ApicId;
[Ray] How about "UINTN ApicId[]"? The difference between the two is your
version contains an 8-byte pointer pointing to somewhere else. My version
implies the APIC ID array is just after "NumberOfProcessor".
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117738): https://edk2.groups.io/g/devel/message/117738
Mute This Topic: https://groups.io/mt/105478501/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v1 13/13] UefiCpuPkg/PiSmmCpuDxeSmm: Remove SmBases relocation logic
@@ -348,14 +336,10 @@ SmmInitHandler (
[Ray.1] Can you rename this function to a different name? Originally it was
really a handler to initialize SMM env called from SmmInit.nasm. But today it's
purely to initialize the SMM env.
How about "InitializeSmm"? And "EFIAPI" is not needed as it's not called from
ASEMBLY anymore.
{
UINT32 ApicId;
UINTNIndex;
BOOLEAN IsBsp;
- //
- // Update SMM IDT entries' code segment and load IDT
- //
- AsmWriteIdtr ();
[Ray.2]
OK.
The IDTR update is needed when it's called from SmmInit.nasm as IDTR is not
updated there.
But it's not needed when it's called from SmmEntry.nasm as IDTR is updated
there.
Other changes look good to me.
From: Wu, Jiaxin
Sent: Wednesday, April 10, 2024 21:57
To: devel@edk2.groups.io
Cc: Ni, Ray ; Zeng, Star ; Gerd Hoffmann
; Kumar, Rahul R
Subject: [PATCH v1 13/13] UefiCpuPkg/PiSmmCpuDxeSmm: Remove SmBases relocation
logic
This patch is to remove legacy SmBase relocation in
PiSmmCpuDxeSmm Driver, and the SmBase relocation
behavior will be in the SmmRelocationInit interface:
1. Relocate smbases for each processor.
2. Create the gSmmBaseHobGuid HOB.
Then, PiSmmCpuDxeSmm driver can be simplified to:
1. Consume the gSmmBaseHobGuid for the smbase.
2. ExecuteFirstSmiInit for early SMM Init.
Cc: Ray Ni
Cc: Zeng Star
Cc: Gerd Hoffmann
Cc: Rahul Kumar
Signed-off-by: Jiaxin Wu
---
UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c| 21 +-
UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/Semaphore.c | 42
UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmInit.nasm | 96
UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c| 6 +-
UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 322 ++-
UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 98
UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf | 4 -
UefiCpuPkg/PiSmmCpuDxeSmm/SmramSaveState.c | 69 --
UefiCpuPkg/PiSmmCpuDxeSmm/X64/Semaphore.c| 69 --
UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.nasm | 146
10 files changed, 30 insertions(+), 843 deletions(-)
delete mode 100644 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/Semaphore.c
delete mode 100644 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmInit.nasm
delete mode 100644 UefiCpuPkg/PiSmmCpuDxeSmm/X64/Semaphore.c
delete mode 100644 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.nasm
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
index b14c289a27..d67fb49890 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
@@ -639,27 +639,14 @@ InitializeCpuProcedure (
//
InitializeCpuBeforeRebase (IsBsp);
}
if (IsBsp) {
-DEBUG ((DEBUG_INFO, "SmmRestoreCpu: mSmmRelocated is %d\n",
mSmmRelocated));
-
//
-// Check whether Smm Relocation is done or not.
-// If not, will do the SmmBases Relocation here!!!
+// Issue SMI IPI (All Excluding Self SMM IPI + BSP SMM IPI) to execute
first SMI init.
//
-if (!mSmmRelocated) {
- //
- // Restore SMBASE for BSP and all APs
- //
- SmmRelocateBases ();
-} else {
- //
- // Issue SMI IPI (All Excluding Self SMM IPI + BSP SMM IPI) to execute
first SMI init.
- //
- ExecuteFirstSmiInit ();
-}
+ExecuteFirstSmiInit ();
}
//
// Skip initialization if mAcpiCpuData is not valid
//
@@ -978,13 +965,13 @@ InitSmmS3ResumeState (
SmmS3ResumeState->SmmS3StackBase =
(EFI_PHYSICAL_ADDRESS)(UINTN)AllocatePages (EFI_SIZE_TO_PAGES
((UINTN)SmmS3ResumeState->SmmS3StackSize));
if (SmmS3ResumeState->SmmS3StackBase == 0) {
SmmS3ResumeState->SmmS3StackSize = 0;
}
-SmmS3ResumeState->SmmS3Cr0 = mSmmCr0;
+SmmS3ResumeState->SmmS3Cr0 = (UINT32)AsmReadCr0 ();
SmmS3ResumeState->SmmS3Cr3 = Cr3;
-SmmS3ResumeState->SmmS3Cr4 = mSmmCr4;
+SmmS3ResumeState->SmmS3Cr4 = (UINT32)AsmReadCr4 ();
if (sizeof (UINTN) == sizeof (UINT64)) {
SmmS3ResumeState->Signature = SMM_S3_RESUME_SMM_64;
}
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/Semaphore.c
b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/Semaphore.c
deleted file mode 100644
index a9fcc89dda..00
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/Semaphore.c
+++ /dev/null
@@ -1,42 +0,0 @@
-/** @file
-Semaphore mechanism to indicate to the BSP that an AP has exited SMM
-after SMBASE relocation.
-
-Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
-SPDX-License-Identifier: BSD-2-Clause-Patent
-
-**/
-
-#include "PiSmmCpuDxeSmm.h"
-
-UINTN mSmmRelocationOriginalAddress;
-volatile BOOLEAN *mRebasedFlag;
-
-/**
- Hook return address of SMM Save State so that semaphore code
- can be executed immediately after AP exits SMM to indicate to
- the BSP that an AP has exited SMM after SMBASE relocation.
-
- @param[in] CpuIndex The processor index.
- @param[in] RebasedFlag A pointer to a flag that is set to TRUE
- imm
Re: [edk2-devel] [PATCH v1 12/13] OvmfPkg/PlatformPei: Relocate SmBases in PEI phase
+STATIC CONST EFI_PEI_NOTIFY_DESCRIPTOR mMpServices2Notify = {
+ EFI_PEI_PPI_DESCRIPTOR_NOTIFY_CALLBACK | // Flags
+ EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST,
+ , // Guid
+ OnMpServices2Available // Notify
+};
+
+VOID
+InstallSmmRelocationCallback (
[Ray.1] This function name is confusing. It's like installing a callback when
smm relocation happens. How about "RelocateSmBase"?
+ VOID
+ )
+{
+ EFI_STATUS Status;
+
+ Status = PeiServicesNotifyPpi ();
+ if (EFI_ERROR (Status)) {
+DEBUG ((
+ DEBUG_ERROR,
+ "%a: failed to set up MP Services2 callback: %r\n",
+ __func__,
+ Status
+ ));
+ }
+}
--
2.16.2.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117625): https://edk2.groups.io/g/devel/message/117625
Mute This Topic: https://groups.io/mt/105442006/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v1 11/13] OvmfPkg/SmmCpuFeaturesLib: Check Smbase Relocation is done or not
Reviewed-by: Ray Ni
Thanks,
Ray
From: Wu, Jiaxin
Sent: Wednesday, April 10, 2024 21:57
To: devel@edk2.groups.io
Cc: Ard Biesheuvel ; Yao, Jiewen
; Gerd Hoffmann ; Ni, Ray
Subject: [PATCH v1 11/13] OvmfPkg/SmmCpuFeaturesLib: Check Smbase Relocation is
done or not
Based on gSmmBaseHobGuid:
If gSmmBaseHobGuid found, means SmBase info has been relocated
and recorded in the SmBase array.
So, this patch check smbase relocation is done or not in
SmmCpuFeaturesInitializeProcessor().
With SmmRelocationLib, gSmmBaseHobGuid will be always created.
Here this patch just makes the function/logic correct. The SMM
Relocation logic can be totally cleaned from the
SmmCpuFeaturesLib. But it will happen in the future patch set,
this patch does not target to the cleanup work.
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Cc: Gerd Hoffmann
Cc: Ray Ni
Signed-off-by: Jiaxin Wu
---
.../Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c | 33 ++
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
index 63822b126e..0a6f33c2b1 100644
--- a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
+++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
@@ -26,10 +26,16 @@
//
// EFER register LMA bit
//
#define LMA BIT10
+//
+// Indicate SmBase for each Processors has been relocated or not. If TRUE,
+// means no need to do the relocation in SmmCpuFeaturesInitializeProcessor().
+//
+BOOLEAN mSmmCpuFeaturesSmmRelocated;
+
/**
The constructor function
@param[in] ImageHandle The firmware allocated handle for the EFI image.
@param[in] SystemTable A pointer to the EFI System Table.
@@ -44,13 +50,13 @@ SmmCpuFeaturesLibConstructor (
IN EFI_SYSTEM_TABLE *SystemTable
)
{
//
// If gSmmBaseHobGuid found, means SmBase info has been relocated and
recorded
- // in the SmBase array. ASSERT it's not supported in OVMF.
+ // in the SmBase array.
//
- ASSERT (GetFirstGuidHob () == NULL);
+ mSmmCpuFeaturesSmmRelocated = (BOOLEAN)(GetFirstGuidHob ()
!= NULL);
//
// No need to program SMRRs on our virtual platform.
//
return EFI_SUCCESS;
@@ -90,20 +96,25 @@ SmmCpuFeaturesInitializeProcessor (
)
{
AMD_SMRAM_SAVE_STATE_MAP *CpuState;
//
- // Configure SMBASE.
+ // No need to configure SMBASE if SmBase relocation has been done.
//
- CpuState = (AMD_SMRAM_SAVE_STATE_MAP *)(UINTN)(
- SMM_DEFAULT_SMBASE +
- SMRAM_SAVE_STATE_MAP_OFFSET
- );
- if ((CpuState->x86.SMMRevId & 0x) == 0) {
-CpuState->x86.SMBASE = (UINT32)CpuHotPlugData->SmBase[CpuIndex];
- } else {
-CpuState->x64.SMBASE = (UINT32)CpuHotPlugData->SmBase[CpuIndex];
+ if (!mSmmCpuFeaturesSmmRelocated) {
+//
+// Configure SMBASE.
+//
+CpuState = (AMD_SMRAM_SAVE_STATE_MAP *)(UINTN)(
+ SMM_DEFAULT_SMBASE +
+ SMRAM_SAVE_STATE_MAP_OFFSET
+ );
+if ((CpuState->x86.SMMRevId & 0x) == 0) {
+ CpuState->x86.SMBASE = (UINT32)CpuHotPlugData->SmBase[CpuIndex];
+} else {
+ CpuState->x64.SMBASE = (UINT32)CpuHotPlugData->SmBase[CpuIndex];
+}
}
//
// No need to program SMRRs on our virtual platform.
//
--
2.16.2.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117624): https://edk2.groups.io/g/devel/message/117624
Mute This Topic: https://groups.io/mt/105442004/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v1 09/13] OvmfPkg/SmmAccess: Consume gEfiSmmSmramMemoryGuid
Do you think it makes sense to combine this with #10? Otherwise, with this
patch the OVMF is broken.
Thanks,
Ray
From: Wu, Jiaxin
Sent: Wednesday, April 10, 2024 21:57
To: devel@edk2.groups.io
Cc: Ard Biesheuvel ; Yao, Jiewen
; Gerd Hoffmann ; Ni, Ray
Subject: [PATCH v1 09/13] OvmfPkg/SmmAccess: Consume gEfiSmmSmramMemoryGuid
This patch refines the SmmAccess implementation:
1. SmramMap will be retrieved from the
gEfiSmmSmramMemoryGuid instead of original from
the TSEG Memory Base register.
2. Remove the gEfiAcpiVariableGuid creation, thus
the DESCRIPTOR_INDEX definition can be also cleaned.
The gEfiAcpiVariableGuid HOB will be created in the
OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf.
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Cc: Gerd Hoffmann
Cc: Ray Ni
Signed-off-by: Jiaxin Wu
---
OvmfPkg/SmmAccess/SmmAccess2Dxe.c | 4 +-
OvmfPkg/SmmAccess/SmmAccess2Dxe.inf | 5 +++
OvmfPkg/SmmAccess/SmmAccessPei.c| 88 +++--
OvmfPkg/SmmAccess/SmmAccessPei.inf | 7 +--
OvmfPkg/SmmAccess/SmramInternal.c | 73 +++---
OvmfPkg/SmmAccess/SmramInternal.h | 18 +---
6 files changed, 41 insertions(+), 154 deletions(-)
diff --git a/OvmfPkg/SmmAccess/SmmAccess2Dxe.c
b/OvmfPkg/SmmAccess/SmmAccess2Dxe.c
index 4b9e6df37f..3371592de7 100644
--- a/OvmfPkg/SmmAccess/SmmAccess2Dxe.c
+++ b/OvmfPkg/SmmAccess/SmmAccess2Dxe.c
@@ -4,11 +4,11 @@
Q35 TSEG is expected to have been verified and set up by the SmmAccessPei
driver.
Copyright (C) 2013, 2015, Red Hat, Inc.
- Copyright (c) 2009 - 2010, Intel Corporation. All rights reserved.
+ Copyright (c) 2009 - 2024, Intel Corporation. All rights reserved.
SPDX-License-Identifier: BSD-2-Clause-Patent
**/
@@ -113,12 +113,10 @@ SmmAccess2DxeGetCapabilities (
IN OUT UINTN *SmramMapSize,
IN OUT EFI_SMRAM_DESCRIPTOR*SmramMap
)
{
return SmramAccessGetCapabilities (
- This->LockState,
- This->OpenState,
SmramMapSize,
SmramMap
);
}
diff --git a/OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
b/OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
index d86381d0fb..d9f01a13c4 100644
--- a/OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
+++ b/OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
@@ -3,10 +3,11 @@
#
# Q35 TSEG is expected to have been verified and set up by the SmmAccessPei
# driver.
#
# Copyright (C) 2013, 2015, Red Hat, Inc.
+# Copyright (c) 2024 Intel Corporation.
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
##
@@ -39,17 +40,21 @@
DebugLib
PcdLib
PciLib
UefiBootServicesTableLib
UefiDriverEntryPoint
+ HobLib
[Protocols]
gEfiSmmAccess2ProtocolGuid ## PRODUCES
[FeaturePcd]
gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
+[Guids]
+ gEfiSmmSmramMemoryGuid # ALWAYS_CONSUMED
+
[Pcd]
gUefiOvmfPkgTokenSpaceGuid.PcdQ35SmramAtDefaultSmbase
gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes
[Depex]
diff --git a/OvmfPkg/SmmAccess/SmmAccessPei.c b/OvmfPkg/SmmAccess/SmmAccessPei.c
index 0e57b7804c..9459bcc989 100644
--- a/OvmfPkg/SmmAccess/SmmAccessPei.c
+++ b/OvmfPkg/SmmAccess/SmmAccessPei.c
@@ -9,21 +9,19 @@
This PEIM runs from RAM, so we can write to variables with static storage
duration.
Copyright (C) 2013, 2015, Red Hat, Inc.
- Copyright (c) 2010, Intel Corporation. All rights reserved.
+ Copyright (c) 2010 - 2024, Intel Corporation. All rights reserved.
SPDX-License-Identifier: BSD-2-Clause-Patent
**/
-#include
#include
#include
#include
-#include
#include
#include
#include
#include
#include
@@ -62,14 +60,10 @@ SmmAccessPeiOpen (
IN EFI_PEI_SERVICES**PeiServices,
IN PEI_SMM_ACCESS_PPI *This,
IN UINTN DescriptorIndex
)
{
- if (DescriptorIndex >= DescIdxCount) {
-return EFI_INVALID_PARAMETER;
- }
-
//
// According to current practice, DescriptorIndex is not considered at all,
// beyond validating it.
//
return SmramAccessOpen (>LockState, >OpenState);
@@ -100,14 +94,10 @@ SmmAccessPeiClose (
IN EFI_PEI_SERVICES**PeiServices,
IN PEI_SMM_ACCESS_PPI *This,
IN UINTN DescriptorIndex
)
{
- if (DescriptorIndex >= DescIdxCount) {
-return EFI_INVALID_PARAMETER;
- }
-
//
// According to current practice, DescriptorIndex is not considered at all,
// beyond validating it.
//
return SmramAccessClose (>LockState, >OpenState);
@@ -137,14 +127,10 @@ SmmAccessPeiLock (
IN EFI_PEI_SERVICES**PeiServices,
IN PEI_SMM_ACCESS_PPI *This,
IN UINTN DescriptorIndex
)
{
- if (DescriptorIndex >= DescIdxCount) {
-return EFI_INVALID_PARAMETER;
- }
-
//
// According to current practice, DescriptorIndex is not considered at all,
// beyond validating it.
//
return SmramAccessLock (>LockState, >OpenState);
@@ -176,12 +162,10 @@ SmmAccessPei
Re: [edk2-devel] [PATCH v1 10/13] OvmfPkg/PlatformInitLib: Create gEfiAcpiVariableGuid
Which patch removes this HOB creation from SmmAccess driver? Thanks, Ray From: Wu, Jiaxin Sent: Wednesday, April 10, 2024 21:57 To: devel@edk2.groups.io Cc: Ard Biesheuvel ; Yao, Jiewen ; Gerd Hoffmann ; Ni, Ray Subject: [PATCH v1 10/13] OvmfPkg/PlatformInitLib: Create gEfiAcpiVariableGuid This patch is for OVMF to create the gEfiAcpiVariableGuid since it has been removed from the SmmAccess driver. Cc: Ard Biesheuvel Cc: Jiewen Yao Cc: Gerd Hoffmann Cc: Ray Ni Signed-off-by: Jiaxin Wu --- OvmfPkg/Library/PlatformInitLib/MemDetect.c | 9 + OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf | 1 + 2 files changed, 10 insertions(+) diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c b/OvmfPkg/Library/PlatformInitLib/MemDetect.c index 8b98256225..f451c9d80c 100644 --- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c +++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c @@ -41,10 +41,11 @@ Module Name: #include #include #include +#include #include #define MEGABYTE_SHIFT 20 VOID @@ -1050,10 +1051,11 @@ PlatformQemuInitializeRam ( UINT32 TsegSize; UINTN BufferSize; UINT8 SmramRanges; EFI_PEI_HOB_POINTERSHob; EFI_SMRAM_HOB_DESCRIPTOR_BLOCK *SmramHobDescriptorBlock; +VOID*GuidHob; TsegSize = PlatformInfoHob->Q35TsegMbytes * SIZE_1MB; PlatformAddMemoryRangeHob (BASE_1MB, PlatformInfoHob->LowMemory - TsegSize); PlatformAddReservedMemoryBaseSizeHob ( PlatformInfoHob->LowMemory - TsegSize, @@ -1080,10 +1082,17 @@ PlatformQemuInitializeRam ( SmramHobDescriptorBlock->Descriptor[0].PhysicalStart = PlatformInfoHob->LowMemory - TsegSize; SmramHobDescriptorBlock->Descriptor[0].CpuStart = PlatformInfoHob->LowMemory - TsegSize; SmramHobDescriptorBlock->Descriptor[0].PhysicalSize = EFI_PAGE_SIZE; SmramHobDescriptorBlock->Descriptor[0].RegionState = EFI_SMRAM_CLOSED | EFI_CACHEABLE | EFI_ALLOCATED; +// +// Create gEfiAcpiVariableGuid +// +GuidHob = BuildGuidHob (, sizeof (EFI_SMRAM_DESCRIPTOR)); +ASSERT (GuidHob != NULL); +CopyMem (GuidHob, >Descriptor[0], sizeof (EFI_SMRAM_DESCRIPTOR)); + // // Create second SMRAM descriptor, which is free and will be used by SMM foundation. // SmramHobDescriptorBlock->Descriptor[1].PhysicalStart = SmramHobDescriptorBlock->Descriptor[0].PhysicalStart + EFI_PAGE_SIZE; SmramHobDescriptorBlock->Descriptor[1].CpuStart = SmramHobDescriptorBlock->Descriptor[0].CpuStart + EFI_PAGE_SIZE; diff --git a/OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf b/OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf index 2bb1c0296f..21e6efa5e0 100644 --- a/OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf +++ b/OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf @@ -56,10 +56,11 @@ [LibraryClasses.X64] TdxLib [Guids] gEfiSmmSmramMemoryGuid + gEfiAcpiVariableGuid [Pcd] gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable -- 2.16.2.windows.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#117621): https://edk2.groups.io/g/devel/message/117621 Mute This Topic: https://groups.io/mt/105442002/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v1 08/13] OvmfPkg/PlatformInitLib: Create gEfiSmmSmramMemoryGuid
I think the commit message can have more details to help OVMF developers
understand the needs of this patch.
E.g.:
Before using SmmRelocationLib, the PiSmmCpuDxeSmm driver allocates the SMRAM
to be used for SMI handler + save state area of each processor from
Smst->AllocatePages().
With SmmRelocationLib, the SMRAM allocation for SMI handlers and save state
areas is moved to early PEI phase when the Smst->AllocatePages() service is not
available. So, the allocation is done by
splitting the SMRAM out of the SMRAM regions reported from Guid HOB
(gEfiSmmSMramMemoryGuid).
However, OVMF platform does not produce the GUID HOB. This patch produces the
HOB..
Thanks,
Ray
From: Wu, Jiaxin
Sent: Wednesday, April 10, 2024 21:57
To: devel@edk2.groups.io
Cc: Ard Biesheuvel ; Yao, Jiewen
; Gerd Hoffmann ; Ni, Ray
Subject: [PATCH v1 08/13] OvmfPkg/PlatformInitLib: Create gEfiSmmSmramMemoryGuid
SmmRelocationLib instance will reserve the memory from
gEfiSmmSmramMemoryGuid for the smbase relocation.
So, system must produce the gEfiSmmSmramMemoryGuid.
This patch is for the OVMF to produce the
gEfiSmmSmramMemoryGuid HOB.
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Cc: Gerd Hoffmann
Cc: Ray Ni
Signed-off-by: Jiaxin Wu
---
OvmfPkg/Library/PlatformInitLib/MemDetect.c| 97 +-
.../Library/PlatformInitLib/PlatformInitLib.inf| 5 +-
2 files changed, 64 insertions(+), 38 deletions(-)
diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
index 7b6e5102ad..8b98256225 100644
--- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
+++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
@@ -1,9 +1,9 @@
/**@file
Memory Detection for Virtual Machines.
- Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
+ Copyright (c) 2006 - 2024, Intel Corporation. All rights reserved.
SPDX-License-Identifier: BSD-2-Clause-Patent
Module Name:
MemDetect.c
@@ -41,10 +41,12 @@ Module Name:
#include
#include
#include
+#include
+
#define MEGABYTE_SHIFT 20
VOID
EFIAPI
PlatformQemuUc32BaseInitialization (
@@ -1027,52 +1029,73 @@ PlatformQemuInitializeRam (
//
// Determine total memory size available
//
PlatformGetSystemMemorySizeBelow4gb (PlatformInfoHob);
- if (PlatformInfoHob->BootMode == BOOT_ON_S3_RESUME) {
-//
-// Create the following memory HOB as an exception on the S3 boot path.
+ //
+ // CpuMpPei saves the original contents of the borrowed area in permanent
+ // PEI RAM, in a backup buffer allocated with the normal PEI services.
+ // CpuMpPei restores the original contents ("returns" the borrowed area) at
+ // End-of-PEI. End-of-PEI in turn is emitted by S3Resume2Pei before
+ // transferring control to the OS's wakeup vector in the FACS.
+ //
+ // We expect any other PEIMs that "borrow" memory similarly to CpuMpPei to
+ // restore the original contents. Furthermore, we expect all such PEIMs
+ // (CpuMpPei included) to claim the borrowed areas by producing memory
+ // allocation HOBs, and to honor preexistent memory allocation HOBs when
+ // looking for an area to borrow.
+ //
+ QemuInitializeRamBelow1gb (PlatformInfoHob);
+
+ if (PlatformInfoHob->SmmSmramRequire) {
+UINT32 TsegSize;
+UINTN BufferSize;
+UINT8 SmramRanges;
+EFI_PEI_HOB_POINTERSHob;
+EFI_SMRAM_HOB_DESCRIPTOR_BLOCK *SmramHobDescriptorBlock;
+
+TsegSize = PlatformInfoHob->Q35TsegMbytes * SIZE_1MB;
+PlatformAddMemoryRangeHob (BASE_1MB, PlatformInfoHob->LowMemory -
TsegSize);
+PlatformAddReservedMemoryBaseSizeHob (
+ PlatformInfoHob->LowMemory - TsegSize,
+ TsegSize,
+ TRUE
+ );
+
+SmramRanges = 2;
+BufferSize = sizeof (EFI_SMRAM_HOB_DESCRIPTOR_BLOCK) + (SmramRanges - 1)
* sizeof (EFI_SMRAM_DESCRIPTOR);
+
+Hob.Raw = BuildGuidHob (
+,
+BufferSize
+);
+ASSERT (Hob.Raw);
+
+SmramHobDescriptorBlock =
(EFI_SMRAM_HOB_DESCRIPTOR_BLOCK *)(Hob.Raw);
+SmramHobDescriptorBlock->NumberOfSmmReservedRegions = SmramRanges;
+
//
-// Normally we'd create memory HOBs only on the normal boot path. However,
-// CpuMpPei specifically needs such a low-memory HOB on the S3 path as
-// well, for "borrowing" a subset of it temporarily, for the AP startup
-// vector.
+// Create first SMRAM descriptor, which contains data structures used in
S3 resume.
+// One page is enough for the data structure
//
-// CpuMpPei saves the original contents of the borrowed area in permanent
-// PEI RAM, in a backup buffer allocated with the normal PEI services.
-// CpuMpPei restores the original contents ("returns" the borrowed area) at
-// End-of-PEI. End-of-PEI in tur
Re: [edk2-devel] [PATCH v1 05/13] UefiCpuPkg/UefiCpuPkg.dsc: Include SmmRelocationLib in UefiCpuPkg
Please change the DSC in the earlier patch that adds the lib instance and avoid this patch. Thanks, Ray From: Wu, Jiaxin Sent: Wednesday, April 10, 2024 21:57 To: devel@edk2.groups.io Cc: Ni, Ray ; Zeng, Star ; Gerd Hoffmann ; Kumar, Rahul R Subject: [PATCH v1 05/13] UefiCpuPkg/UefiCpuPkg.dsc: Include SmmRelocationLib in UefiCpuPkg This patch just includes SmmRelocationLib in UefiCpuPkg. Cc: Ray Ni Cc: Zeng Star Cc: Gerd Hoffmann Cc: Rahul Kumar Signed-off-by: Jiaxin Wu --- UefiCpuPkg/UefiCpuPkg.dsc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc index 10b33594e5..631a850c78 100644 --- a/UefiCpuPkg/UefiCpuPkg.dsc +++ b/UefiCpuPkg/UefiCpuPkg.dsc @@ -194,10 +194,13 @@ UnitTestResultReportLib|UnitTestFrameworkPkg/Library/UnitTestResultReportLib/UnitTestResultReportLibConOut.inf } UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveStateLib.inf UefiCpuPkg/Library/MmSaveStateLib/IntelMmSaveStateLib.inf UefiCpuPkg/Library/SmmCpuFeaturesLib/AmdSmmCpuFeaturesLib.inf + UefiCpuPkg/Library/SmmRelocationLib/SmmRelocationLib.inf + UefiCpuPkg/Library/SmmRelocationLib/OvmfSmmRelocationLib.inf + UefiCpuPkg/Library/SmmRelocationLib/AmdSmmRelocationLib.inf [Components.X64] UefiCpuPkg/Library/CpuExceptionHandlerLib/UnitTest/DxeCpuExceptionHandlerLibUnitTest.inf [Components.RISCV64] -- 2.16.2.windows.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#117612): https://edk2.groups.io/g/devel/message/117612 Mute This Topic: https://groups.io/mt/105441994/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v1 03/13] UefiCpuPkg/SmmRelocationLib: Add library instance for OVMF
No. Please do not create a OVMF specific lib instance in UefiCpuPkg.
Thanks,
Ray
From: Wu, Jiaxin
Sent: Wednesday, April 10, 2024 21:57
To: devel@edk2.groups.io
Cc: Ni, Ray ; Zeng, Star ; Ard
Biesheuvel ; Yao, Jiewen ;
Gerd Hoffmann ; Kumar, Rahul R
Subject: [PATCH v1 03/13] UefiCpuPkg/SmmRelocationLib: Add library instance for
OVMF
Due to the definition difference of SMRAM Save State,
SmmBase config in SMRAM Save State for OVMF is also different.
This patch provides the OvmfSmmRelocationLib library instance
to handle the SMRAM Save State difference.
Cc: Ray Ni
Cc: Zeng Star
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Cc: Gerd Hoffmann
Cc: Rahul Kumar
Signed-off-by: Jiaxin Wu
---
.../SmmRelocationLib/OvmfSmmRelocationLib.inf | 61
.../SmmRelocationLib/OvmfSmramSaveStateConfig.c| 107 +
2 files changed, 168 insertions(+)
create mode 100644 UefiCpuPkg/Library/SmmRelocationLib/OvmfSmmRelocationLib.inf
create mode 100644
UefiCpuPkg/Library/SmmRelocationLib/OvmfSmramSaveStateConfig.c
diff --git a/UefiCpuPkg/Library/SmmRelocationLib/OvmfSmmRelocationLib.inf
b/UefiCpuPkg/Library/SmmRelocationLib/OvmfSmmRelocationLib.inf
new file mode 100644
index 00..eba1129ac2
--- /dev/null
+++ b/UefiCpuPkg/Library/SmmRelocationLib/OvmfSmmRelocationLib.inf
@@ -0,0 +1,61 @@
+## @file
+# SMM Relocation Lib for each processor.
+#
+# This Lib produces the SMM_BASE_HOB in HOB database which tells
+# the PiSmmCpuDxeSmm driver (runs at a later phase) about the new
+# SMBASE for each processor. PiSmmCpuDxeSmm driver installs the
+# SMI handler at the SMM_BASE_HOB.SmBase[Index]+0x8000 for processor
+# Index.
+#
+# Copyright (c) 2024, Intel Corporation. All rights reserved.
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+ INF_VERSION= 0x00010005
+ BASE_NAME = SmmRelocationLib
+ FILE_GUID = 51834F51-CCE0-4743-B553-935D0C8A53FF
+ MODULE_TYPE= PEIM
+ VERSION_STRING = 1.0
+ LIBRARY_CLASS = SmmRelocationLib
+
+[Sources]
+ InternalSmmRelocationLib.h
+ OvmfSmramSaveStateConfig.c
+ SmmRelocationLib.c
+
+[Sources.Ia32]
+ Ia32/Semaphore.c
+ Ia32/SmmInit.nasm
+
+[Sources.X64]
+ X64/Semaphore.c
+ X64/SmmInit.nasm
+
+[Packages]
+ MdePkg/MdePkg.dec
+ MdeModulePkg/MdeModulePkg.dec
+ UefiCpuPkg/UefiCpuPkg.dec
+
+[LibraryClasses]
+ BaseLib
+ BaseMemoryLib
+ CpuExceptionHandlerLib
+ DebugLib
+ HobLib
+ LocalApicLib
+ MemoryAllocationLib
+ PcdLib
+ PeiServicesLib
+
+[Guids]
+ gSmmBaseHobGuid ## HOB ALWAYS_PRODUCED
+ gEfiSmmSmramMemoryGuid## CONSUMES
+
+[Pcd]
+ gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber
+ gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackSize ## CONSUMES
+
+[FeaturePcd]
+ gUefiCpuPkgTokenSpaceGuid.PcdCpuHotPlugSupport##
CONSUMES
diff --git a/UefiCpuPkg/Library/SmmRelocationLib/OvmfSmramSaveStateConfig.c
b/UefiCpuPkg/Library/SmmRelocationLib/OvmfSmramSaveStateConfig.c
new file mode 100644
index 00..505b1d694a
--- /dev/null
+++ b/UefiCpuPkg/Library/SmmRelocationLib/OvmfSmramSaveStateConfig.c
@@ -0,0 +1,107 @@
+/** @file
+ Config SMRAM Save State for SmmBases Relocation.
+
+ Copyright (c) 2024, Intel Corporation. All rights reserved.
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+#include "InternalSmmRelocationLib.h"
+#include
+
+/**
+ This function configures the SmBase on the currently executing CPU.
+
+ @param[in] CpuIndex The index of the CPU.
+ @param[in,out] CpuState Pointer to SMRAM Save State Map for the
+ currently executing CPU. On out, SmBase
is
+ updated to the new value.
+
+**/
+VOID
+EFIAPI
+ConfigureSmBase (
+ IN UINTN CpuIndex,
+ IN OUT SMRAM_SAVE_STATE_MAP *CpuState
+ )
+{
+ AMD_SMRAM_SAVE_STATE_MAP *CpuSaveState;
+
+ CpuSaveState = (AMD_SMRAM_SAVE_STATE_MAP *)CpuState;
+
+ if ((CpuSaveState->x86.SMMRevId & 0x) == 0) {
+CpuSaveState->x86.SMBASE = (UINT32)mSmBaseForAllCpus[CpuIndex];
+ } else {
+CpuSaveState->x64.SMBASE = (UINT32)mSmBaseForAllCpus[CpuIndex];
+ }
+}
+
+/**
+ This function updates the SMRAM save state on the currently executing CPU
+ to resume execution at a specific address after an RSM instruction. This
+ function must evaluate the SMRAM save state to determine the execution mode
+ the RSM instruction resumes and update the resume execution address with
+ either NewInstructionPointer32 or NewInstructionPoint. The auto HALT restart
+ flag in the SMRAM save state must always be cleared. This function returns
+ the value of the instruction pointer from the SMRAM save state that was
+ replaced. If this function returns 0, then the SMRAM save st
Re: [edk2-devel] [PATCH v1 02/13] UefiCpuPkg/SmmRelocationLib: Add SmmRelocationLib library instance
Not sure if "--find-copies-harder" helps to detect that the new files are
copies of existing files.
Can you try in next version if some comments request a new version of patch?
Thanks,
Ray
From: Wu, Jiaxin
Sent: Wednesday, April 10, 2024 21:57
To: devel@edk2.groups.io
Cc: Ni, Ray ; Zeng, Star ; Gerd Hoffmann
; Kumar, Rahul R
Subject: [PATCH v1 02/13] UefiCpuPkg/SmmRelocationLib: Add SmmRelocationLib
library instance
This patch separates the smbase relocation logic from
PiSmmCpuDxeSmm driver, and moves to the
SmmRelocationInit interface.
Platform shall consume the interface for the smbase
relocation if need SMM support.
Cc: Ray Ni
Cc: Zeng Star
Cc: Gerd Hoffmann
Cc: Rahul Kumar
Signed-off-by: Jiaxin Wu
---
.../Library/SmmRelocationLib/Ia32/Semaphore.c | 43 ++
.../Library/SmmRelocationLib/Ia32/SmmInit.nasm | 157 +
.../SmmRelocationLib/InternalSmmRelocationLib.h| 141 +
.../Library/SmmRelocationLib/SmmRelocationLib.c| 659 +
.../Library/SmmRelocationLib/SmmRelocationLib.inf | 61 ++
.../SmmRelocationLib/SmramSaveStateConfig.c| 91 +++
.../Library/SmmRelocationLib/X64/Semaphore.c | 70 +++
.../Library/SmmRelocationLib/X64/SmmInit.nasm | 207 +++
8 files changed, 1429 insertions(+)
create mode 100644 UefiCpuPkg/Library/SmmRelocationLib/Ia32/Semaphore.c
create mode 100644 UefiCpuPkg/Library/SmmRelocationLib/Ia32/SmmInit.nasm
create mode 100644
UefiCpuPkg/Library/SmmRelocationLib/InternalSmmRelocationLib.h
create mode 100644 UefiCpuPkg/Library/SmmRelocationLib/SmmRelocationLib.c
create mode 100644 UefiCpuPkg/Library/SmmRelocationLib/SmmRelocationLib.inf
create mode 100644 UefiCpuPkg/Library/SmmRelocationLib/SmramSaveStateConfig.c
create mode 100644 UefiCpuPkg/Library/SmmRelocationLib/X64/Semaphore.c
create mode 100644 UefiCpuPkg/Library/SmmRelocationLib/X64/SmmInit.nasm
diff --git a/UefiCpuPkg/Library/SmmRelocationLib/Ia32/Semaphore.c
b/UefiCpuPkg/Library/SmmRelocationLib/Ia32/Semaphore.c
new file mode 100644
index 00..ace3221cfc
--- /dev/null
+++ b/UefiCpuPkg/Library/SmmRelocationLib/Ia32/Semaphore.c
@@ -0,0 +1,43 @@
+/** @file
+ Semaphore mechanism to indicate to the BSP that an AP has exited SMM
+ after SMBASE relocation.
+
+ Copyright (c) 2024, Intel Corporation. All rights reserved.
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include "InternalSmmRelocationLib.h"
+
+UINTN mSmmRelocationOriginalAddress;
+volatile BOOLEAN *mRebasedFlag;
+
+/**
+ Hook return address of SMM Save State so that semaphore code
+ can be executed immediately after AP exits SMM to indicate to
+ the BSP that an AP has exited SMM after SMBASE relocation.
+
+ @param[in] CpuIndex The processor index.
+ @param[in] RebasedFlag A pointer to a flag that is set to TRUE
+ immediately after AP exits SMM.
+
+**/
+VOID
+SemaphoreHook (
+ IN UINTN CpuIndex,
+ IN volatile BOOLEAN *RebasedFlag
+ )
+{
+ SMRAM_SAVE_STATE_MAP *CpuState;
+
+ mRebasedFlag = RebasedFlag;
+
+ CpuState = (SMRAM_SAVE_STATE_MAP *)(UINTN)(SMM_DEFAULT_SMBASE +
SMRAM_SAVE_STATE_MAP_OFFSET);
+
+ mSmmRelocationOriginalAddress = (UINTN)HookReturnFromSmm (
+ CpuIndex,
+ CpuState,
+
(UINT64)(UINTN),
+
(UINT64)(UINTN)
+ );
+}
diff --git a/UefiCpuPkg/Library/SmmRelocationLib/Ia32/SmmInit.nasm
b/UefiCpuPkg/Library/SmmRelocationLib/Ia32/SmmInit.nasm
new file mode 100644
index 00..cb8b030693
--- /dev/null
+++ b/UefiCpuPkg/Library/SmmRelocationLib/Ia32/SmmInit.nasm
@@ -0,0 +1,157 @@
+;--
;
+; Copyright (c) 2024, Intel Corporation. All rights reserved.
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+; Module Name:
+;
+; SmmInit.nasm
+;
+; Abstract:
+;
+; Functions for relocating SMBASE's for all processors
+;
+;---
+
+%include "StuffRsbNasm.inc"
+
+global ASM_PFX(gcSmiIdtr)
+global ASM_PFX(gcSmiGdtr)
+
+extern ASM_PFX(SmmInitHandler)
+extern ASM_PFX(mRebasedFlag)
+extern ASM_PFX(mSmmRelocationOriginalAddress)
+
+global ASM_PFX(gPatchSmmCr3)
+global ASM_PFX(gPatchSmmCr4)
+global ASM_PFX(gPatchSmmCr0)
+global ASM_PFX(gPatchSmmInitStack)
+global ASM_PFX(gcSmmInitSize)
+global ASM_PFX(gcSmmInitTemplate)
+
+%define PROTECT_MODE_CS 0x8
+%define PROTECT_MODE_DS 0x20
+
+SECTION .data
+
+NullSeg: DQ 0 ; reserved by architecture
+CodeSeg32:
+DW -1 ; LimitLow
+DW 0 ; BaseLow
+DB 0 ; BaseMid
+DB 0x9b
+DB 0
Re: [edk2-devel] [PATCH v1 00/13] Add SmmRelocationLib
Jiaxin, can you kindly share a PR in GitHub so that it will be easier to review?
Thanks,
Ray
From: Wu, Jiaxin
Sent: Wednesday, April 10, 2024 21:57
To: devel@edk2.groups.io
Cc: Ni, Ray ; Zeng, Star ; Gerd Hoffmann
; Kumar, Rahul R ; Dong, Guo
; Rhodes, Sean ; Lu, James
; Guo, Gua ; Ard Biesheuvel
; Yao, Jiewen
Subject: [PATCH v1 00/13] Add SmmRelocationLib
Intel plans to separate the smbase relocation logic from
PiSmmCpuDxeSmm driver, and the related behavior will be
moved to the new interface defined by the SmmRelocationLib
class.
The SmmRelocationLib class provides the SmmRelocationInit()
interface for platform to do the smbase relocation, which
shall provide below 2 functionalities:
1. Relocate smbases for each processor.
2. Create the gSmmBaseHobGuid HOB.
With SmmRelocationLib, PiSmmCpuDxeSmm driver (which runs at
a later phase) can be simplfied as below for SMM init:
1. Consume the gSmmBaseHobGuid HOB for the relocated smbases
for each Processor.
2. Execute the early SMM Init.
Cc: Ray Ni
Cc: Zeng Star
Cc: Gerd Hoffmann
Cc: Rahul Kumar
Cc: Guo Dong
Cc: Sean Rhodes
Cc: James Lu
Cc: Gua Guo
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Signed-off-by: Jiaxin Wu
Jiaxin Wu (13):
UefiCpuPkg: Add SmmRelocationLib class
UefiCpuPkg/SmmRelocationLib: Add SmmRelocationLib library instance
UefiCpuPkg/SmmRelocationLib: Add library instance for OVMF
UefiCpuPkg/SmmRelocationLib: Add library instance for AMD
UefiCpuPkg/UefiCpuPkg.dsc: Include SmmRelocationLib in UefiCpuPkg
UefiPayloadPkg/UefiPayloadPkg.dsc: Include SmmRelocationLib
OvmfPkg: Include SmmRelocationLib in OvmfPkg
OvmfPkg/PlatformInitLib: Create gEfiSmmSmramMemoryGuid
OvmfPkg/SmmAccess: Consume gEfiSmmSmramMemoryGuid
OvmfPkg/PlatformInitLib: Create gEfiAcpiVariableGuid
OvmfPkg/SmmCpuFeaturesLib: Check Smbase Relocation is done or not
OvmfPkg/PlatformPei: Relocate SmBases in PEI phase
UefiCpuPkg/PiSmmCpuDxeSmm: Remove SmBases relocation logic
OvmfPkg/AmdSev/AmdSevX64.dsc | 1 +
OvmfPkg/CloudHv/CloudHvX64.dsc | 1 +
OvmfPkg/Library/PlatformInitLib/MemDetect.c| 104 ++--
.../Library/PlatformInitLib/PlatformInitLib.inf| 6 +-
.../Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c | 33 +-
OvmfPkg/Microvm/MicrovmX64.dsc | 1 +
OvmfPkg/OvmfPkgIa32.dsc| 1 +
OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
OvmfPkg/OvmfPkgX64.dsc | 1 +
OvmfPkg/PlatformPei/Platform.c | 1 +
OvmfPkg/PlatformPei/Platform.h | 5 +
OvmfPkg/PlatformPei/PlatformPei.inf| 5 +-
OvmfPkg/PlatformPei/SmmRelocation.c| 80 +++
OvmfPkg/SmmAccess/SmmAccess2Dxe.c | 4 +-
OvmfPkg/SmmAccess/SmmAccess2Dxe.inf| 5 +
OvmfPkg/SmmAccess/SmmAccessPei.c | 88 +--
OvmfPkg/SmmAccess/SmmAccessPei.inf | 7 +-
OvmfPkg/SmmAccess/SmramInternal.c | 73 +--
OvmfPkg/SmmAccess/SmramInternal.h | 18 +-
UefiCpuPkg/Include/Library/SmmRelocationLib.h | 42 ++
.../SmmRelocationLib/AmdSmmRelocationLib.inf | 61 ++
.../SmmRelocationLib/AmdSmramSaveStateConfig.c | 109
.../SmmRelocationLib}/Ia32/Semaphore.c | 13 +-
.../Library/SmmRelocationLib/Ia32/SmmInit.nasm | 157 +
.../SmmRelocationLib/InternalSmmRelocationLib.h| 141 +
.../SmmRelocationLib/OvmfSmmRelocationLib.inf | 61 ++
.../SmmRelocationLib/OvmfSmramSaveStateConfig.c| 107
.../Library/SmmRelocationLib/SmmRelocationLib.c| 659 +
.../Library/SmmRelocationLib/SmmRelocationLib.inf | 61 ++
.../SmmRelocationLib/SmramSaveStateConfig.c| 91 +++
.../SmmRelocationLib}/X64/Semaphore.c | 13 +-
.../SmmRelocationLib}/X64/SmmInit.nasm | 93 ++-
UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c | 21 +-
UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmInit.nasm| 96 ---
UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 6 +-
UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 322 +-
UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 98 ---
UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf | 4 -
UefiCpuPkg/PiSmmCpuDxeSmm/SmramSaveState.c | 69 ---
UefiCpuPkg/UefiCpuPkg.dec | 3 +
UefiCpuPkg/UefiCpuPkg.dsc | 3 +
UefiPayloadPkg/UefiPayloadPkg.dsc | 2 +
42 files changed, 1850 insertions(+), 817 deletions(-)
create mode 100644 OvmfPkg/PlatformPei/SmmRelocation.c
create mode 100644 UefiCpuPkg/Include/Library/SmmRelocationLib.h
create mode 100644 UefiCpuPkg/Library/SmmRelocationLib/AmdSmmRelocationLib.inf
create mode 100644
UefiCpuPkg/Library/SmmRelocationLib/AmdSmramSaveStateConfig.c
rename UefiCpuPkg/{PiSmmCpuDxeSmm =>
Library/SmmRelocation
Re: [edk2-devel] [PATCH v3 0/6] Support to unregister SMI handler in SMI handlers
Reviewed-by: Ray Ni Thanks, Ray From: devel@edk2.groups.io on behalf of Zhiguang Liu Sent: Wednesday, April 10, 2024 15:49 To: devel@edk2.groups.io Cc: Liu, Zhiguang Subject: [edk2-devel] [PATCH v3 0/6] Support to unregister SMI handler in SMI handlers Months ago, I sent patch set to fix potential issues in the usage of SMI handler unregistering SMI handler. Discussion can be found in below link: https://edk2.groups.io/g/devel/topic/103925794#114251 The conclusion was to only support SMI handler unregistering itself, and not allow SMI handler unregistering other handlers, because we thought there would be no such usage. However, recently, I find in some platform, there is kind of usage. To also support SMI handler unregistering other handlers, this patch set use a totally different design. So I revert the former ones first to make the code more readable. Thank Laszlo for bring up the initial idea for the new design. V2: Code refine based on Ray's comments Zhiguang Liu (6): Revert 2ec8f0c6407f062441b205b900038933865c7b3c Revert 049ff6c39c73edd3709c05bd0e46184320471358 Revert 17b28722008eab745ce186b72cd325944cbe6bf0 Revert ae1079b386a597108a8070652bf7cdaa4ec3dda3 MdeModulePkg/SMM: Support to unregister SMI handler in SMI handlers StandaloneMmPkg: Support to unregister MMI handler in MMI handlers MdeModulePkg/Core/PiSmmCore/PiSmmCore.h | 1 + MdeModulePkg/Core/PiSmmCore/Smi.c | 198 --- StandaloneMmPkg/Core/Mmi.c | 200 +--- 3 files changed, 292 insertions(+), 107 deletions(-) -- 2.31.1.windows.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#117580): https://edk2.groups.io/g/devel/message/117580 Mute This Topic: https://groups.io/mt/105437953/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2] IntelFsp2Pkg: Optional Plugin for FSP SecCore/PeiCore Rebasing
Reviewed-by: Ray Ni
Thanks,
Ray
From: Liu, Zhiguang
Sent: Wednesday, April 10, 2024 15:08
To: devel@edk2.groups.io
Cc: Liu, Zhiguang ; Chiu, Chasel
; Desimone, Nathaniel L
; Duggapu, Chinni B
; Zeng, Star ; Kuo, Ted
; S, Ashraf Ali ; Susovan Mohapatra
; Ni, Ray
Subject: [PATCH v2] IntelFsp2Pkg: Optional Plugin for FSP SecCore/PeiCore
Rebasing
Note this plugin only applies to 64-bit PSP
This optional plugin is designed to execute before the FSP SecCore to
rebase SecCore and PeiCore during runtime. If the FSP binary requires
rebasing at runtime, this module should be included within the FSP
binary. Additionally, specific patches must be applied to ensure proper
functionality. In the absence of this module, manual patching of API
offsets within the FSP header is necessary. To illustrate, let's
consider a scenario within FSP-S where 'FspSiliconInitEntry' is the
initial API to be executed post-rebase. Rather than directly inputting
the 'FspSiliconInit' offset into the 'FspSiliconInitEntryOffset' field
of the FSP header, the entry point of this module should be used.
Furthermore, the 'FspSiliconInit' offset should be placed into
'AsmGetFspOriginalEntry', which signifies the address to which this
module will jump.
It is also essential to patch the image bases of SecCore and PeiCore
to enable the rebasing functionality of this module.
The following is an example of how to apply the necessary patches:
Patch Address Patch Value
PreFspSec:_ModuleEntryPoint - [0x]
PreFspSec:SecCoreRelativeOffPreFspSec:AsmGetFspSecCoreImageBase
- Fsp24SecCoreS:BASE
PreFspSec:PeiCoreRelativeOffPreFspSec:AsmGetFspPeiCoreImageBase
- PeiCore:BASE
PreFspSec:SecEntryRelativeOff PreFspSec:AsmGetFspOriginalEntry
- Fsp24SecCoreS:FspSiliconInitApi
Cc: Chasel Chiu
Cc: Nate DeSimone
Cc: Duggapu Chinni B
Cc: Star Zeng
Cc: Ted Kuo
Cc: Ashraf Ali S
Cc: Susovan Mohapatra
Cc: Ray Ni
Signed-off-by: Zhiguang Liu
---
IntelFsp2Pkg/IntelFsp2Pkg.dsc | 5 +
IntelFsp2Pkg/PreFspSec/PreFspSec.c| 115 ++
IntelFsp2Pkg/PreFspSec/PreFspSec.inf | 62 ++
.../PreFspSec/X64/PreFspSecCommon.nasm| 94 ++
4 files changed, 276 insertions(+)
create mode 100644 IntelFsp2Pkg/PreFspSec/PreFspSec.c
create mode 100644 IntelFsp2Pkg/PreFspSec/PreFspSec.inf
create mode 100644 IntelFsp2Pkg/PreFspSec/X64/PreFspSecCommon.nasm
diff --git a/IntelFsp2Pkg/IntelFsp2Pkg.dsc b/IntelFsp2Pkg/IntelFsp2Pkg.dsc
index f236a7010b..a2cc29c940 100644
--- a/IntelFsp2Pkg/IntelFsp2Pkg.dsc
+++ b/IntelFsp2Pkg/IntelFsp2Pkg.dsc
@@ -33,6 +33,8 @@
SerialPortLib|MdePkg/Library/BaseSerialPortLibNull/BaseSerialPortLibNull.inf
ReportStatusCodeLib|MdePkg/Library/BaseReportStatusCodeLibNull/BaseReportStatusCodeLibNull.inf
DebugDeviceLib|IntelFsp2Pkg/Library/BaseDebugDeviceLibNull/BaseDebugDeviceLibNull.inf
+ PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
+
PeCoffExtraActionLib|MdePkg/Library/BasePeCoffExtraActionLibNull/BasePeCoffExtraActionLibNull.inf
# FSP override
DebugLib|IntelFsp2Pkg/Library/BaseFspDebugLibSerialPort/BaseFspDebugLibSerialPort.inf
@@ -75,6 +77,9 @@
IntelFsp2Pkg/FspSecCore/Fsp24SecCoreS.inf
IntelFsp2Pkg/FspNotifyPhase/FspNotifyPhasePeim.inf
+[Components.X64]
+ IntelFsp2Pkg/PreFspSec/PreFspSec.inf
+
[PcdsFixedAtBuild.common]
gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x1f
gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80080046
diff --git a/IntelFsp2Pkg/PreFspSec/PreFspSec.c
b/IntelFsp2Pkg/PreFspSec/PreFspSec.c
new file mode 100644
index 00..b3b52b8064
--- /dev/null
+++ b/IntelFsp2Pkg/PreFspSec/PreFspSec.c
@@ -0,0 +1,115 @@
+/** @file
+
+ Copyright (c) 2024, Intel Corporation. All rights reserved.
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include
+#include "Guid/FspHeaderFile.h"
+#include
+#include
+#include
+#include
+
+/**
+ This fuction gets SecCore image base
+
+ @return SecCore image base, or zero if no patch in nasm code
+
+**/
+UINTN
+EFIAPI
+AsmGetFspSecCoreImageBase (
+ VOID
+ );
+
+/**
+ This fuction gets PeiCore image base
+
+ @return PeiCore image base, or zero if no patch in nasm code
+
+**/
+UINTN
+EFIAPI
+AsmGetFspPeiCoreImageBase (
+ VOID
+ );
+
+/**
+ Relocate Pe/Te Image
+
+ @param[in] ImageBaseAddress Image base address
+
+ @retval EFI_SUCCESS Image is relocated successfully
+ @retval OthersImage is not relocated successfully
+**/
+EFI_STATUS
+RelocatePeTeImage (
+ UINT64 ImageBaseAddress
+ )
+{
+ RETURN_STATUS Status;
+ PE_COFF_LOADER_IMAGE_CONTEXT ImageContext;
+
+ ZeroMem (, sizeof (ImageContext));
+
+ ImageContext.Handle= (VOID *)ImageBaseAddress;
+ ImageContext.ImageRead = PeCoffLoaderImageReadFromMemory;
+
Re: [edk2-devel] [PATCH 1/3] OptionRomPkg: Update the comments of GetInformation function
Pedro,
I didn't notice your mail and merged the patch.:(
Your comments to the commit messages are good to me.
However, I am ok with the changes to the function header of an existing
implementation.
Thanks,
Ray
From: Pedro Falcato
Sent: Tuesday, April 9, 2024 10:12
To: Shang, Qingyu
Cc: devel@edk2.groups.io ; Ni, Ray ;
Gahan Saraiya
Subject: Re: [PATCH 1/3] OptionRomPkg: Update the comments of GetInformation
function
On Mon, Apr 8, 2024 at 10:48 AM Qingyu wrote:
>
> Refer to Uefi spec 2.10 section 11.11.2, add a new retval
> EFI_NOT_FOUND to EFI_ADAPTER_INFORMATION_PROTOCOL.GetInformation().
> Reference: [mantis #1866] - GetInfo() of Adapter Information
> Protocol should have a provision for IHV to return no data.
Let's reword this commit message a bit, shall we? Something like this:
Add a new return value EFI_NOT_FOUND to
EFI_ADAPTER_INFORMATION_PROTOCOL.GetInformation(), according to UEFI
spec 2.10 section 11.11.2.
This brings the documentation up to par with UEFI 2.10.
Reference: [mantis #1866] - GetInfo() of Adapter Information
Protocol should have a provision for IHV to return no data.
I'm not sure about the commit title too, but it's late here and I
can't figure out a nice succinct description. Maybe:
"OptionRomPkg/UndiRuntimeDxe: Update UndiAipGetInfo's docs to UEFI spec 2.10"
>
> Cc: Pedro Falcato
Why was I CC'd on this? /me is confused
> Cc: Ray Ni
> Signed-off-by: Qingyu
> Signed-off-by: Gahan Saraiya
> ---
> Drivers/OptionRomPkg/UndiRuntimeDxe/Undi32.h | 5 -
> Drivers/OptionRomPkg/UndiRuntimeDxe/UndiAipImpl.c | 5 -
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/Drivers/OptionRomPkg/UndiRuntimeDxe/Undi32.h
> b/Drivers/OptionRomPkg/UndiRuntimeDxe/Undi32.h
> index 31c55a8e11..665221e952 100644
> --- a/Drivers/OptionRomPkg/UndiRuntimeDxe/Undi32.h
> +++ b/Drivers/OptionRomPkg/UndiRuntimeDxe/Undi32.h
> @@ -350,7 +350,9 @@ VOID PxeUpdate (NIC_DATA_INSTANCE *NicPtr, PXE_SW_UNDI
> *PxePtr);
>
>This function returns information of type InformationType from the adapter.
>If an adapter does not support the requested informational type, then
> - EFI_UNSUPPORTED is returned.
> + EFI_UNSUPPORTED is returned. If an adapter does not contain Information for
> + the requested InformationType, it fills InformationBlockSize with 0 and
> + returns EFI_NOT_FOUND.
>
>@param[in] This A pointer to the
> EFI_ADAPTER_INFORMATION_PROTOCOL instance.
>@param[in] InformationTypeA pointer to an EFI_GUID that defines
> the contents of InformationBlock.
> @@ -360,6 +362,7 @@ VOID PxeUpdate (NIC_DATA_INSTANCE *NicPtr, PXE_SW_UNDI
> *PxePtr);
>
>@retval EFI_SUCCESSThe InformationType information was
> retrieved.
>@retval EFI_UNSUPPORTEDThe InformationType is not known.
> + @retval EFI_NOT_FOUND Information is not available for the
> requested information type.
>@retval EFI_DEVICE_ERROR The device reported an error.
>@retval EFI_OUT_OF_RESOURCES The request could not be completed due
> to a lack of resources.
>@retval EFI_INVALID_PARAMETER This is NULL.
> diff --git a/Drivers/OptionRomPkg/UndiRuntimeDxe/UndiAipImpl.c
> b/Drivers/OptionRomPkg/UndiRuntimeDxe/UndiAipImpl.c
> index 21151a076f..d80ce65da9 100644
> --- a/Drivers/OptionRomPkg/UndiRuntimeDxe/UndiAipImpl.c
> +++ b/Drivers/OptionRomPkg/UndiRuntimeDxe/UndiAipImpl.c
> @@ -18,7 +18,9 @@ EFI_GUID mSupportedInfoTypes[] = {
>
>This function returns information of type InformationType from the adapter.
>If an adapter does not support the requested informational type, then
> - EFI_UNSUPPORTED is returned.
> + EFI_UNSUPPORTED is returned. If an adapter does not contain Information for
> + the requested InformationType, it fills InformationBlockSize with 0 and
> + returns EFI_NOT_FOUND.
>
>@param[in] This A pointer to the
> EFI_ADAPTER_INFORMATION_PROTOCOL instance.
>@param[in] InformationTypeA pointer to an EFI_GUID that defines
> the contents of InformationBlock.
> @@ -28,6 +30,7 @@ EFI_GUID mSupportedInfoTypes[] = {
>
>@retval EFI_SUCCESSThe InformationType information was
> retrieved.
>@retval EFI_UNSUPPORTEDThe InformationType is not known.
> + @retval EFI_NOT_FOUND Information is not available for the
> requested information type.
>@retval EFI_DEVICE_ERROR The device reported an error.
>@retval EFI_OUT_OF_RESOURCES The request could not be completed due
> to a lack of resources.
>@retval EFI_INVALID_PARAMETER This is NULL.
In any case, since I've been meaning to say this for some tim
Re: [edk2-devel] [PATCH 1/3] OptionRomPkg: Update the comments of GetInformation function
merged.
Thanks,
Ray
From: Shang, Qingyu
Sent: Monday, April 8, 2024 17:47
To: devel@edk2.groups.io
Cc: Pedro Falcato ; Ni, Ray ; Gahan
Saraiya
Subject: [PATCH 1/3] OptionRomPkg: Update the comments of GetInformation
function
Refer to Uefi spec 2.10 section 11.11.2, add a new retval
EFI_NOT_FOUND to EFI_ADAPTER_INFORMATION_PROTOCOL.GetInformation().
Reference: [mantis #1866] - GetInfo() of Adapter Information
Protocol should have a provision for IHV to return no data.
Cc: Pedro Falcato
Cc: Ray Ni
Signed-off-by: Qingyu
Signed-off-by: Gahan Saraiya
---
Drivers/OptionRomPkg/UndiRuntimeDxe/Undi32.h | 5 -
Drivers/OptionRomPkg/UndiRuntimeDxe/UndiAipImpl.c | 5 -
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/Drivers/OptionRomPkg/UndiRuntimeDxe/Undi32.h
b/Drivers/OptionRomPkg/UndiRuntimeDxe/Undi32.h
index 31c55a8e11..665221e952 100644
--- a/Drivers/OptionRomPkg/UndiRuntimeDxe/Undi32.h
+++ b/Drivers/OptionRomPkg/UndiRuntimeDxe/Undi32.h
@@ -350,7 +350,9 @@ VOID PxeUpdate (NIC_DATA_INSTANCE *NicPtr, PXE_SW_UNDI
*PxePtr);
This function returns information of type InformationType from the adapter.
If an adapter does not support the requested informational type, then
- EFI_UNSUPPORTED is returned.
+ EFI_UNSUPPORTED is returned. If an adapter does not contain Information for
+ the requested InformationType, it fills InformationBlockSize with 0 and
+ returns EFI_NOT_FOUND.
@param[in] This A pointer to the
EFI_ADAPTER_INFORMATION_PROTOCOL instance.
@param[in] InformationTypeA pointer to an EFI_GUID that defines the
contents of InformationBlock.
@@ -360,6 +362,7 @@ VOID PxeUpdate (NIC_DATA_INSTANCE *NicPtr, PXE_SW_UNDI
*PxePtr);
@retval EFI_SUCCESSThe InformationType information was
retrieved.
@retval EFI_UNSUPPORTEDThe InformationType is not known.
+ @retval EFI_NOT_FOUND Information is not available for the
requested information type.
@retval EFI_DEVICE_ERROR The device reported an error.
@retval EFI_OUT_OF_RESOURCES The request could not be completed due to
a lack of resources.
@retval EFI_INVALID_PARAMETER This is NULL.
diff --git a/Drivers/OptionRomPkg/UndiRuntimeDxe/UndiAipImpl.c
b/Drivers/OptionRomPkg/UndiRuntimeDxe/UndiAipImpl.c
index 21151a076f..d80ce65da9 100644
--- a/Drivers/OptionRomPkg/UndiRuntimeDxe/UndiAipImpl.c
+++ b/Drivers/OptionRomPkg/UndiRuntimeDxe/UndiAipImpl.c
@@ -18,7 +18,9 @@ EFI_GUID mSupportedInfoTypes[] = {
This function returns information of type InformationType from the adapter.
If an adapter does not support the requested informational type, then
- EFI_UNSUPPORTED is returned.
+ EFI_UNSUPPORTED is returned. If an adapter does not contain Information for
+ the requested InformationType, it fills InformationBlockSize with 0 and
+ returns EFI_NOT_FOUND.
@param[in] This A pointer to the
EFI_ADAPTER_INFORMATION_PROTOCOL instance.
@param[in] InformationTypeA pointer to an EFI_GUID that defines the
contents of InformationBlock.
@@ -28,6 +30,7 @@ EFI_GUID mSupportedInfoTypes[] = {
@retval EFI_SUCCESSThe InformationType information was
retrieved.
@retval EFI_UNSUPPORTEDThe InformationType is not known.
+ @retval EFI_NOT_FOUND Information is not available for the
requested information type.
@retval EFI_DEVICE_ERROR The device reported an error.
@retval EFI_OUT_OF_RESOURCES The request could not be completed due to
a lack of resources.
@retval EFI_INVALID_PARAMETER This is NULL.
--
2.39.1.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117565): https://edk2.groups.io/g/devel/message/117565
Mute This Topic: https://groups.io/mt/105398061/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 00/13] Part 2 patch set to add LoongArch support into UefiCpuPkg
Chao, Current patch introduces the CpuMmuInitLib which contains ConfigureMemoryManagementUnit () API. You told me the API will be called by a PEIM. Then, the new proposal is to move the library code into that PEIM. I don't quite understand your needs of the new GUID to store the memory map resource. How is the GUID used to store the memory map resource? Can the PEIM be placed in edk2-platforms repo? Thanks, Ray From: Chao Li Sent: Tuesday, April 9, 2024 12:29 To: devel@edk2.groups.io ; Ni, Ray ; Gerd Hoffmann Cc: Kumar, Rahul R ; Sami Mujawar ; Sunil V L ; Bibo Mao ; Dongyan Qian Subject: Re: [edk2-devel] [PATCH v2 00/13] Part 2 patch set to add LoongArch support into UefiCpuPkg Hi Ray, I'm willing change it to a PEIM if it doesn't fit as a library. I think if it is a PEIM, we need a new GUID to sotre the memory map resouce, or use an already defined GUID. I will put it under the UefiCpuPkg, called CpuMmuInitPei, folder: UefiCpuPkg/CpuMmuInitPei/LoongArch64/. May I? Thanks, Chao On 2024/4/9 10:06, Ni, Ray wrote: Chao, Sorry I missed your mail. If ConfigureMemoryManagementUnit() is called in PEI, can you move the logic to a LoongArch specific PEIM? My concern is we may need more review on the lib API ConfigureMemoryManagementUnit() if we position it as a library. If we move the logic in a PEIM and the implementation becomes a PEIM internal logic, we can lower the quality expectation of the function prototype as no other module is able to call it. Thanks, Ray For patches 10, 11: Can the lib be avoided if the logic is implemented in CpuDxe driver? This library is will be called in the PEI stage, so I can't move it under the CpuDxe. This library is the low-level libary of CpuMmuLib, which will consume CpuMmuLIb to configure the MMU. This way is suggested by Laszlo, who saied if CpuMmuLib can not content the configure API(high-level libary is the basecal libaray, it should not include the configure API), we can split it into two, where the hight-livel is CpuMmuLib, and the low-level is CpuMmuInitLib. For patch 12(UefiCpuPkg: Add multiprocessor library for LoongArch64): Reviewed-by: Ray Ni <mailto:ray...@intel.com> For patch 13: Please make accordingly changes when you address comments for patch 8. OK. Thanks, Ray From: Gerd Hoffmann <mailto:kra...@redhat.com> Sent: Friday, March 22, 2024 20:39 To: Chao Li <mailto:lic...@loongson.cn> Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io>; Ni, Ray <mailto:ray...@intel.com>; Kumar, Rahul R <mailto:rahul.r.ku...@intel.com>; Sami Mujawar <mailto:sami.muja...@arm.com>; Sunil V L <mailto:suni...@ventanamicro.com>; Bibo Mao <mailto:maob...@loongson.cn>; Dongyan Qian <mailto:qiandong...@loongson.cn> Subject: Re: [PATCH v2 00/13] Part 2 patch set to add LoongArch support into UefiCpuPkg On Wed, Mar 20, 2024 at 04:41:52PM +0800, Chao Li wrote: > This patch set adjusted some order in UefiCpuPig alphabetically, added > LoongArch libraries and drivers into UefiCpuPkg, it is a continuation of > the first patch series v8 submitted at > https://edk2.groups.io/g/devel/message/114526. > > And also separated from https://edk2.groups.io/g/devel/message/116583. > > This series only contents the changes for UefiCpuPkg. > > Patch1-Patch4: Reorder some INF files located in UefiCpuPkg > alphabetically. > > Patch5-Patch13: Added Timer, CpuMmuLib, CpuMmuInitLib, MpInitLib, CpuDxe > for LoongArch, and added some PCD and header files requested by the > above libraries and drivers. > > Modfied modules: UefiCpuPkg > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4726 > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4734 > > PR: https://github.com/tianocore/edk2/pull/5483 > > V1 -> V2: > 1. Removed PcdCpuMmuIsEnabled. > 2. Removed API GetMemoryRegionAttributes API as it is no longer needed. > 3. Patch3, added two empty line in DXE and PEI INF files. > 4. Patch5, added the Status check in GetTimeInnanoSecond function. > 5. Separated into two series, this is series one, and the second one is > OvmfPkg. While I can't comment on the loongarch architecture details the code and the integration into build system looks overall sane to me. Series: Acked-by: Gerd Hoffmann <mailto:kra...@redhat.com> take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#117529): https://edk2.groups.io/g/devel/message/117529 Mute This Topic: https://groups.io/mt/105041080/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] IntelFsp2Pkg: Optional Plugin for FSP SecCore/PeiCore Rebasing
This optional plugin is designed to execute before the FSP SecCore to
rebase SecCore and PeiCore during runtime. If the FSP binary requires
rebasing at runtime, this module should be included within the FSP
binary. Additionally, specific patches must be applied to ensure proper
functionality.
In the absence of this module, manual patching of API offsets within
the FSP header is necessary. To illustrate, let's consider a scenario
within FSP-S where 'FspSiliconInitEntry' is the initial API to be
executed post-rebase.
Rather than directly inputting the 'FspSiliconInit' offset into the
'FspSiliconInitEntryOffset' field of the FSP header, the entry point
of this module should be used.
Furthermore, the 'FspSiliconInit' offset should be placed into
'AsmGetFspSecEntry', which signifies the address to which this module
will jump.
It is also essential to patch the image bases of SecCore and PeiCore
to enable the rebasing functionality of this module.
The following is an example of how to apply the necessary patches:
Patch Address Patch Value
PreFspSecS:_ModuleEntryPoint - [0x]
PreFspSecS:SecCoreRelativeOff PreFspSecS:AsmGetFspSecCore
- Fsp24SecCoreS:BASE
PreFspSecS:PeiCoreRelativeOff PreFspSecS:AsmGetFspPeiCore
- PeiCore:BASE
PreFspSecS:SecEntryRelativeOff PreFspSecS:AsmGetFspSecEntry
- Fsp24SecCoreS:FspSiliconInitApi
[Ray.1] Can you emphasize this optional plug-in only applies to 64bit FSP?
+/**
+ Relocate Pe/Te Image
+
+ @param[in] ImageBaseAddress Image base address
+
+ @retval EFI_SUCCESS Image is relocated successfully
+ @retval OthersImage is not relocated successfully
+**/
+EFI_STATUS
+RelocatePeTeImage (
+ UINT64 ImageBaseAddress
+ )
+{
+ RETURN_STATUS Status;
+ PE_COFF_LOADER_IMAGE_CONTEXT ImageContext;
+
+ ZeroMem (, sizeof (ImageContext));
+
+ ImageContext.Handle= (VOID *)ImageBaseAddress;
+ ImageContext.ImageRead = PeCoffLoaderImageReadFromMemory;
+
+ Status = PeCoffLoaderGetImageInfo ();
+ if (EFI_ERROR (Status)) {
+ASSERT_EFI_ERROR (Status);
+return Status;
+ }
+
+ ImageContext.ImageAddress = (EFI_PHYSICAL_ADDRESS)(UINTN)ImageBaseAddress;
+
+ //
+ // rebase the image
+ //
+ Status = PeCoffLoaderRelocateImage ();
+
+ ASSERT_EFI_ERROR (Status);
+ return Status;
+}
+
+/**
+ This function will patch the Sec Core and Pei Core in current FSP.
+**/
+VOID
+EFIAPI
+FspPatchSecAndPeiCore (
[Ray.2] Can you rename it as "Fsp*Relocate*SecAndPeiCore"?
It's to align with "RelocatePeTeImage".
+;
+;
+global ASM_PFX(_ModuleEntryPoint)
+ASM_PFX(_ModuleEntryPoint):
+ PUSHA_64
+ call ASM_PFX(FspPatchSecAndPeiCore)
+ POPA_64
+ call ASM_PFX(AsmGetFspSecEntry)
+ jmprax
+
+global ASM_PFX(AsmGetFspSecCore)
[Ray.3] rename as AsmGetFspSecCoreImageBase and add function header.
+ASM_PFX(AsmGetFspSecCore):
+ lea rax, [ASM_PFX(AsmGetFspSecCore)]
+ mov rcx, rax
+ xor rdx, rdx
+ DB0x48, 0x2d ; sub rax, 0x
+global ASM_PFX(SecCoreRelativeOff)
+ASM_PFX(SecCoreRelativeOff):
+ DD0; This value can be patched by the build
script if need to rebase SecCore
[Ray.4] ; RAX = SecCore image base at runtime, RCX = AsmGetFspSecCore runtime
address
+ xchgrax, rcx ; After exchange, rcx is the value be
subtract by the patched value
+ ; rax == rcx means patched value is zero
[Ray.5] ; RCX = SecCore image base at runtime, RAX = AsmGetFspSecCore runtime
address.
; If SecCoreRelativeOff is not patched, RCX = RAX = AsmGetFspSecCore runtime
address. This happens when there is no SecCore in the binary.
+ CMPXCHG rcx, rdx ; if (rcx == rax) {rcx = rdx (0) } else {rax
= rcx (SecCore image base at runtime)}
+ mov rax, rcx
+ ret
+
+global ASM_PFX(AsmGetFspPeiCore)
+ASM_PFX(AsmGetFspPeiCore):
+ lea rax, [ASM_PFX(AsmGetFspPeiCore)]
+ mov rcx, rax
+ xor rdx, rdx
+ DB0x48, 0x2d ; sub rax, 0x
+global ASM_PFX(PeiCoreRelativeOff)
+ASM_PFX(PeiCoreRelativeOff):
+ DD0; This value can be patched by the build
script if need to rebase PeiCore
+ xchgrax, rcx ; After exchange, rcx is the value be
subtract by the patched value
+ ; rax == rcx means patched value is zero
+ CMPXCHG rcx, rdx ; if (rcx == rax) {rcx = rdx} else {rax =
rcx}
+ mov rax, rcx
+ ret
+
[Ray.6] rename it as AsmGetFspOriginalEntry.
+global ASM_PFX(AsmGetFspSecEntry)
+ASM_PFX(AsmGetFspSecEntry):
+ lea rax, [ASM_PFX(AsmGetFspSecEntry)]
+ DB0x48, 0x2d ; sub rax, 0x
+global ASM_PFX(SecEntryRelativeOff)
+ASM_PFX(SecEntryRelativeOff):
+ DD0x12345678 ;
Re: [edk2-devel] [PATCH v2 00/13] Part 2 patch set to add LoongArch support into UefiCpuPkg
Chao, Sorry I missed your mail. If ConfigureMemoryManagementUnit() is called in PEI, can you move the logic to a LoongArch specific PEIM? My concern is we may need more review on the lib API ConfigureMemoryManagementUnit() if we position it as a library. If we move the logic in a PEIM and the implementation becomes a PEIM internal logic, we can lower the quality expectation of the function prototype as no other module is able to call it. Thanks, Ray For patches 10, 11: Can the lib be avoided if the logic is implemented in CpuDxe driver? This library is will be called in the PEI stage, so I can't move it under the CpuDxe. This library is the low-level libary of CpuMmuLib, which will consume CpuMmuLIb to configure the MMU. This way is suggested by Laszlo, who saied if CpuMmuLib can not content the configure API(high-level libary is the basecal libaray, it should not include the configure API), we can split it into two, where the hight-livel is CpuMmuLib, and the low-level is CpuMmuInitLib. For patch 12(UefiCpuPkg: Add multiprocessor library for LoongArch64): Reviewed-by: Ray Ni <mailto:ray...@intel.com> For patch 13: Please make accordingly changes when you address comments for patch 8. OK. Thanks, Ray From: Gerd Hoffmann <mailto:kra...@redhat.com> Sent: Friday, March 22, 2024 20:39 To: Chao Li <mailto:lic...@loongson.cn> Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io>; Ni, Ray <mailto:ray...@intel.com>; Kumar, Rahul R <mailto:rahul.r.ku...@intel.com>; Sami Mujawar <mailto:sami.muja...@arm.com>; Sunil V L <mailto:suni...@ventanamicro.com>; Bibo Mao <mailto:maob...@loongson.cn>; Dongyan Qian <mailto:qiandong...@loongson.cn> Subject: Re: [PATCH v2 00/13] Part 2 patch set to add LoongArch support into UefiCpuPkg On Wed, Mar 20, 2024 at 04:41:52PM +0800, Chao Li wrote: > This patch set adjusted some order in UefiCpuPig alphabetically, added > LoongArch libraries and drivers into UefiCpuPkg, it is a continuation of > the first patch series v8 submitted at > https://edk2.groups.io/g/devel/message/114526. > > And also separated from https://edk2.groups.io/g/devel/message/116583. > > This series only contents the changes for UefiCpuPkg. > > Patch1-Patch4: Reorder some INF files located in UefiCpuPkg > alphabetically. > > Patch5-Patch13: Added Timer, CpuMmuLib, CpuMmuInitLib, MpInitLib, CpuDxe > for LoongArch, and added some PCD and header files requested by the > above libraries and drivers. > > Modfied modules: UefiCpuPkg > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4726 > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4734 > > PR: https://github.com/tianocore/edk2/pull/5483 > > V1 -> V2: > 1. Removed PcdCpuMmuIsEnabled. > 2. Removed API GetMemoryRegionAttributes API as it is no longer needed. > 3. Patch3, added two empty line in DXE and PEI INF files. > 4. Patch5, added the Status check in GetTimeInnanoSecond function. > 5. Separated into two series, this is series one, and the second one is > OvmfPkg. While I can't comment on the loongarch architecture details the code and the integration into build system looks overall sane to me. Series: Acked-by: Gerd Hoffmann <mailto:kra...@redhat.com> take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#117516): https://edk2.groups.io/g/devel/message/117516 Mute This Topic: https://groups.io/mt/105041080/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 1/3] OptionRomPkg: Update the comments of GetInformation function
Reviewed-by: Ray Ni
Thanks,
Ray
From: Shang, Qingyu
Sent: Monday, April 8, 2024 17:47
To: devel@edk2.groups.io
Cc: Pedro Falcato ; Ni, Ray ; Gahan
Saraiya
Subject: [PATCH 1/3] OptionRomPkg: Update the comments of GetInformation
function
Refer to Uefi spec 2.10 section 11.11.2, add a new retval
EFI_NOT_FOUND to EFI_ADAPTER_INFORMATION_PROTOCOL.GetInformation().
Reference: [mantis #1866] - GetInfo() of Adapter Information
Protocol should have a provision for IHV to return no data.
Cc: Pedro Falcato
Cc: Ray Ni
Signed-off-by: Qingyu
Signed-off-by: Gahan Saraiya
---
Drivers/OptionRomPkg/UndiRuntimeDxe/Undi32.h | 5 -
Drivers/OptionRomPkg/UndiRuntimeDxe/UndiAipImpl.c | 5 -
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/Drivers/OptionRomPkg/UndiRuntimeDxe/Undi32.h
b/Drivers/OptionRomPkg/UndiRuntimeDxe/Undi32.h
index 31c55a8e11..665221e952 100644
--- a/Drivers/OptionRomPkg/UndiRuntimeDxe/Undi32.h
+++ b/Drivers/OptionRomPkg/UndiRuntimeDxe/Undi32.h
@@ -350,7 +350,9 @@ VOID PxeUpdate (NIC_DATA_INSTANCE *NicPtr, PXE_SW_UNDI
*PxePtr);
This function returns information of type InformationType from the adapter.
If an adapter does not support the requested informational type, then
- EFI_UNSUPPORTED is returned.
+ EFI_UNSUPPORTED is returned. If an adapter does not contain Information for
+ the requested InformationType, it fills InformationBlockSize with 0 and
+ returns EFI_NOT_FOUND.
@param[in] This A pointer to the
EFI_ADAPTER_INFORMATION_PROTOCOL instance.
@param[in] InformationTypeA pointer to an EFI_GUID that defines the
contents of InformationBlock.
@@ -360,6 +362,7 @@ VOID PxeUpdate (NIC_DATA_INSTANCE *NicPtr, PXE_SW_UNDI
*PxePtr);
@retval EFI_SUCCESSThe InformationType information was
retrieved.
@retval EFI_UNSUPPORTEDThe InformationType is not known.
+ @retval EFI_NOT_FOUND Information is not available for the
requested information type.
@retval EFI_DEVICE_ERROR The device reported an error.
@retval EFI_OUT_OF_RESOURCES The request could not be completed due to
a lack of resources.
@retval EFI_INVALID_PARAMETER This is NULL.
diff --git a/Drivers/OptionRomPkg/UndiRuntimeDxe/UndiAipImpl.c
b/Drivers/OptionRomPkg/UndiRuntimeDxe/UndiAipImpl.c
index 21151a076f..d80ce65da9 100644
--- a/Drivers/OptionRomPkg/UndiRuntimeDxe/UndiAipImpl.c
+++ b/Drivers/OptionRomPkg/UndiRuntimeDxe/UndiAipImpl.c
@@ -18,7 +18,9 @@ EFI_GUID mSupportedInfoTypes[] = {
This function returns information of type InformationType from the adapter.
If an adapter does not support the requested informational type, then
- EFI_UNSUPPORTED is returned.
+ EFI_UNSUPPORTED is returned. If an adapter does not contain Information for
+ the requested InformationType, it fills InformationBlockSize with 0 and
+ returns EFI_NOT_FOUND.
@param[in] This A pointer to the
EFI_ADAPTER_INFORMATION_PROTOCOL instance.
@param[in] InformationTypeA pointer to an EFI_GUID that defines the
contents of InformationBlock.
@@ -28,6 +30,7 @@ EFI_GUID mSupportedInfoTypes[] = {
@retval EFI_SUCCESSThe InformationType information was
retrieved.
@retval EFI_UNSUPPORTEDThe InformationType is not known.
+ @retval EFI_NOT_FOUND Information is not available for the
requested information type.
@retval EFI_DEVICE_ERROR The device reported an error.
@retval EFI_OUT_OF_RESOURCES The request could not be completed due to
a lack of resources.
@retval EFI_INVALID_PARAMETER This is NULL.
--
2.39.1.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117515): https://edk2.groups.io/g/devel/message/117515
Mute This Topic: https://groups.io/mt/105398061/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v3 00/24] Provide SEV-SNP support for running under an SVSM
I think I've acked all patches in UefiCpuPkg.
Please let me know if any other patches need my review.
Thanks,
Ray
From: devel@edk2.groups.io on behalf of Lendacky, Thomas
via groups.io
Sent: Wednesday, April 3, 2024 2:16
To: devel@edk2.groups.io ; Yao, Jiewen
; Liming Gao ; Ni, Ray
; Liu, Zhiguang ; Kinney, Michael D
; Guo, Gua ; Dong, Guo
; Lu, James ; Rhodes, Sean
; Kumar, Rahul R
Cc: Ard Biesheuvel ; Aktas, Erdem
; Gerd Hoffmann ; Xu, Min M
; Michael Roth ; Anatol Belski
; Anthony Perard ;
Corvin Köhne ; Jianyong Wu ; Rebecca
Cran
Subject: Re: [edk2-devel] [PATCH v3 00/24] Provide SEV-SNP support for running
under an SVSM
Re-pinging the list/maintainers. Still awaiting feedback/reviews/acks on
the changes.
Thanks,
Tom
On 3/26/24 13:34, Tom Lendacky wrote:
> Any issues with this version of the series? Still looking for
> Reviewed-by's for the MdePkg, UefiCpuPkg and UefiPayloadPkg related
> patches.
>
> Once I get those, I'll submit the edk2-platform patches to support the
> new library as a response to these patches for a quick review.
>
> Thanks,
> Tom
>
> On 3/8/24 09:29, Tom Lendacky wrote:
>>
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
>>
>> This series adds SEV-SNP support for running OVMF under an Secure VM
>> Service Module (SVSM) at a less privileged VM Privilege Level (VMPL).
>> By running at a less priviledged VMPL, the SVSM can be used to provide
>> services, e.g. a virtual TPM, for the guest OS within the SEV-SNP
>> confidential VM (CVM) rather than trust such services from the
>> hypervisor.
>>
>> Currently, OVMF expects to run at the highest VMPL, VMPL0, and there are
>> certain SNP related operations that require that VMPL level.
>> Specifically,
>> the PVALIDATE instruction and the RMPADJUST instruction when setting the
>> the VMSA attribute of a page (used when starting APs).
>>
>> If OVMF is to run at a less privileged VMPL, e.g. VMPL2, then it must
>> use an SVSM (which is running at VMPL0) to perform the operations that
>> it is no longer able to perform.
>>
>> When running under an SVSM, OVMF must know the APIC IDs of the vCPUs that
>> it will be starting. As a result, the GHCB APIC ID retrieval action must
>> be performed. Since this service can also work with SEV-SNP running at
>> VMPL0, the patches to make use of this feature are near the beginning of
>> the series.
>>
>> How OVMF interacts with and uses the SVSM is documented in the SVSM
>> specification [1] and the GHCB specification [2].
>>
>> This support creates a new AmdSvsmLib library that is used by MpInitLib.
>> The edk2-platforms repo requires updates/patches to add the new library
>> requirement. To accomodate that, this series could be split between:
>>
>> patch number 12:
>>UefiCpuPkg/AmdSvsmLib: Create the AmdSvsmLib library to support an
>> SVSM
>>
>> and patch number 13:
>>UefiPayloadPkg: Prepare UefiPayloadPkg to use the AmdSvsmLib library
>>
>> The updates to edk2-platforms can be applied at the split.
>>
>> This series introduces support to run OVMF under an SVSM. It consists
>> of:
>>- Retrieving the list of vCPU APIC IDs and starting up all APs without
>> performing a broadcast SIPI
>>- Reorganizing the page state change support to not directly use the
>> GHCB buffer since an SVSM will use the calling area buffer, instead
>>- Detecting the presence of an SVSM
>>- When not running at VMPL0, invoking the SVSM for page validation and
>> VMSA page creation/deletion
>>- Detecting and allowing OVMF to run in a VMPL other than 0 when an
>> SVSM is present
>>
>> The series is based off of commit:
>>
>>e60529df58e4 ("UefiPayloadPkg: Make Dsc accomodative of other archs")
>>
>> [1]
>> https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
>> [2]
>> https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56421.pdf
>>
>> Cc: Anatol Belski
>> Cc: Anthony Perard
>> Cc: Ard Biesheuvel
>> Cc: Corvin Köhne
>> Cc: Erdem Aktas
>> Cc: Gerd Hoffmann
>> Cc: Gua Guo
>> Cc: Guo Dong
>> Cc: James Lu
>> Cc: Jianyong Wu
>> Cc: Jiewen Yao
>> Cc: Laszlo Ersek
>> Cc: Liming Gao
>> Cc: Michael D Kinney
>> Cc: Michael Roth
>> Cc: Min Xu
>> Cc: Rahul Kumar
>> Cc: Ray Ni
>> Cc: Rebecca Cran
>> Cc: Sean Rhodes
>> Cc: Zhiguang Liu
>>
>> ---
>>
>> Changes in v3:
>> - Ren
Re: [edk2-devel] [PATCH v3 03/24] UefiCpuPkg/MpInitLib: Always use AP Create if GhcbApicIds HOB is present
Acked-by: Ray Ni
Thanks,
Ray
From: devel@edk2.groups.io on behalf of Lendacky, Thomas
via groups.io
Sent: Friday, March 8, 2024 23:30
To: devel@edk2.groups.io
Cc: Ard Biesheuvel ; Aktas, Erdem
; Gerd Hoffmann ; Yao, Jiewen
; Laszlo Ersek ; Liming Gao
; Kinney, Michael D ; Xu,
Min M ; Liu, Zhiguang ; Kumar,
Rahul R ; Ni, Ray ; Michael Roth
Subject: [edk2-devel] [PATCH v3 03/24] UefiCpuPkg/MpInitLib: Always use AP
Create if GhcbApicIds HOB is present
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
Currently, the first time an AP is started for an SEV-SNP guest, it relies
on the VMSA as set by the hypervisor. If the list of APIC IDs has been
retrieved, this is not necessary. The list of APIC IDs will be identified
by a GUIDed HOB. If the GUIDed HOB is present, use the SEV-SNP AP Create
protocol to start the AP for the first time and each time thereafter.
Cc: Gerd Hoffmann
Cc: Laszlo Ersek
Cc: Rahul Kumar
Cc: Ray Ni
Reviewed-by: Gerd Hoffmann
Signed-off-by: Tom Lendacky
---
UefiCpuPkg/UefiCpuPkg.dec | 5 +-
UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf | 1 +
UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf | 1 +
UefiCpuPkg/Include/Guid/GhcbApicIds.h | 17 +
UefiCpuPkg/Library/MpInitLib/MpLib.h | 15 +++-
UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c| 21 +-
UefiCpuPkg/Library/MpInitLib/MpLib.c | 9 ++-
UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c | 78 ++--
8 files changed, 133 insertions(+), 14 deletions(-)
diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index 571b59b36f0a..c31d8b6736cf 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -2,7 +2,7 @@
# This Package provides UEFI compatible CPU modules and libraries.
#
# Copyright (c) 2007 - 2023, Intel Corporation. All rights reserved.
-# Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
+# Copyright (C) 2023 - 2024, Advanced Micro Devices, Inc. All rights
reserved.
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
@@ -91,6 +91,9 @@ [Guids]
## Include/Guid/MpInformation2.h
gMpInformation2HobGuid = { 0x417a7f64, 0xf4e9, 0x4b32, {0x84, 0x6a,
0x5c, 0xc4, 0xd8, 0x62, 0x18, 0x79 }}
+ ## Include/Guid/GhcbApicIds.h
+ gGhcbApicIdsGuid = { 0xbc964338, 0xee39, 0x4fc8, { 0xa2, 0x24,
0x10, 0x10, 0x8b, 0x17, 0x80, 0x1b }}
+
[Protocols]
## Include/Protocol/SmmCpuService.h
gEfiSmmCpuServiceProtocolGuid = { 0x1d202cab, 0xc8ab, 0x4d5c, { 0x94,
0xf7, 0x3c, 0xfc, 0xc0, 0xd3, 0xd3, 0x35 }}
diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
index 55e46d4a1fad..69950fcd1289 100644
--- a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
+++ b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
@@ -68,6 +68,7 @@ [Guids]
gEfiEventExitBootServicesGuid ## CONSUMES ## Event
gEfiEventLegacyBootGuid ## SOMETIMES_CONSUMES ## Event
gEdkiiMicrocodePatchHobGuid ## SOMETIMES_CONSUMES ## HOB
+ gGhcbApicIdsGuid ## SOMETIMES_CONSUMES ## HOB
[Pcd]
gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber##
CONSUMES
diff --git a/UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
b/UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
index bc3d716aa951..22f74a814534 100644
--- a/UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
+++ b/UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
@@ -76,3 +76,4 @@ [Ppis]
[Guids]
gEdkiiS3SmmInitDoneGuid
gEdkiiMicrocodePatchHobGuid
+ gGhcbApicIdsGuid ## SOMETIMES_CONSUMES
diff --git a/UefiCpuPkg/Include/Guid/GhcbApicIds.h
b/UefiCpuPkg/Include/Guid/GhcbApicIds.h
new file mode 100644
index ..9d5bfcb0de22
--- /dev/null
+++ b/UefiCpuPkg/Include/Guid/GhcbApicIds.h
@@ -0,0 +1,17 @@
+/** @file
+ APIC ID list retrieved for an SEV-ES/SEV-SNP guest via the GHCB.
+
+ Copyright (C) 2024, Advanced Micro Devices, Inc. All rights reserved.
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef GHCB_APIC_IDS_H_
+#define GHCB_APIC_IDS_H_
+
+#define GHCB_APIC_IDS_GUID \
+ { 0xbc964338, 0xee39, 0x4fc8, { 0xa2, 0x24, 0x10, 0x10, 0x8b, 0x17, 0x80,
0x1b }}
+
+extern EFI_GUID gGhcbApicIdsGuid;
+
+#endif
diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.h
b/UefiCpuPkg/Library/MpInitLib/MpLib.h
index d26035559f22..65e05c4806f5 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.h
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.h
@@ -2,7 +2,7 @@
Common header file for MP Initialize Library.
Copyright (c) 2016 - 2023, Intel Corporation. All rights reserved.
- Copyright (c) 2020, AMD Inc. All rights reserved.
+ Copyright (c) 2020 - 2024, AMD Inc. All rights reserved.
SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -924,6 +924,19 @@ SevSnpCreateAP (
IN INTN ProcessorNumber
);
+/**
+ Determine if the SEV-SNP AP Create protocol
Re: [edk2-devel] [PATCH v3 12/24] UefiCpuPkg/AmdSvsmLib: Create the AmdSvsmLib library to support an SVSM
Acked-by: Ray Ni Thanks, Ray From: devel@edk2.groups.io on behalf of Lendacky, Thomas via groups.io Sent: Friday, March 8, 2024 23:31 To: devel@edk2.groups.io Cc: Ard Biesheuvel ; Aktas, Erdem ; Gerd Hoffmann ; Yao, Jiewen ; Laszlo Ersek ; Liming Gao ; Kinney, Michael D ; Xu, Min M ; Liu, Zhiguang ; Kumar, Rahul R ; Ni, Ray ; Michael Roth Subject: [edk2-devel] [PATCH v3 12/24] UefiCpuPkg/AmdSvsmLib: Create the AmdSvsmLib library to support an SVSM BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654 In order to support an SEV-SNP guest running under an SVSM at VMPL1 or lower, a new library must be created. This library includes an interface to detect if running under an SVSM, an interface to return the current VMPL, an interface to perform memory validation and an interface to set or clear the attribute that allows a page to be used as a VMSA. Cc: Gerd Hoffmann Cc: Laszlo Ersek Cc: Rahul Kumar Cc: Ray Ni Acked-by: Gerd Hoffmann Signed-off-by: Tom Lendacky --- UefiCpuPkg/UefiCpuPkg.dec| 3 + UefiCpuPkg/UefiCpuPkg.dsc| 4 +- UefiCpuPkg/Library/AmdSvsmLibNull/AmdSvsmLibNull.inf | 27 + UefiCpuPkg/Include/Library/AmdSvsmLib.h | 101 ++ UefiCpuPkg/Library/AmdSvsmLibNull/AmdSvsmLibNull.c | 108 UefiCpuPkg/Library/AmdSvsmLibNull/AmdSvsmLibNull.uni | 13 +++ 6 files changed, 255 insertions(+), 1 deletion(-) diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec index c31d8b6736cf..d1bff93ae2e0 100644 --- a/UefiCpuPkg/UefiCpuPkg.dec +++ b/UefiCpuPkg/UefiCpuPkg.dec @@ -52,6 +52,9 @@ [LibraryClasses.IA32, LibraryClasses.X64] ## @libraryclass Provides function to support CcExit processing. CcExitLib|Include/Library/CcExitLib.h + ## @libraryclass Provides function to support AmdSvsm processing. + AmdSvsmLib|Include/Library/AmdSvsmLib.h + ## @libraryclass Provides function to get CPU cache information. CpuCacheInfoLib|Include/Library/CpuCacheInfoLib.h diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc index 10b33594e586..422e50c92b48 100644 --- a/UefiCpuPkg/UefiCpuPkg.dsc +++ b/UefiCpuPkg/UefiCpuPkg.dsc @@ -2,7 +2,7 @@ # UefiCpuPkg Package # # Copyright (c) 2007 - 2023, Intel Corporation. All rights reserved. -# Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved. +# Copyright (C) 2023 - 2024, Advanced Micro Devices, Inc. All rights reserved. # # SPDX-License-Identifier: BSD-2-Clause-Patent # @@ -61,6 +61,7 @@ [LibraryClasses] PeCoffExtraActionLib|MdePkg/Library/BasePeCoffExtraActionLibNull/BasePeCoffExtraActionLibNull.inf TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf CcExitLib|UefiCpuPkg/Library/CcExitLibNull/CcExitLibNull.inf + AmdSvsmLib|UefiCpuPkg/Library/AmdSvsmLibNull/AmdSvsmLibNull.inf MicrocodeLib|UefiCpuPkg/Library/MicrocodeLib/MicrocodeLib.inf SmmCpuRendezvousLib|UefiCpuPkg/Library/SmmCpuRendezvousLib/SmmCpuRendezvousLib.inf CpuPageTableLib|UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableLib.inf @@ -159,6 +160,7 @@ [Components.IA32, Components.X64] UefiCpuPkg/Library/SmmCpuFeaturesLib/StandaloneMmCpuFeaturesLib.inf UefiCpuPkg/Library/SmmCpuSyncLib/SmmCpuSyncLib.inf UefiCpuPkg/Library/CcExitLibNull/CcExitLibNull.inf + UefiCpuPkg/Library/AmdSvsmLibNull/AmdSvsmLibNull.inf UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.inf UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationSmm.inf UefiCpuPkg/SecCore/SecCore.inf diff --git a/UefiCpuPkg/Library/AmdSvsmLibNull/AmdSvsmLibNull.inf b/UefiCpuPkg/Library/AmdSvsmLibNull/AmdSvsmLibNull.inf new file mode 100644 index ..45a189540941 --- /dev/null +++ b/UefiCpuPkg/Library/AmdSvsmLibNull/AmdSvsmLibNull.inf @@ -0,0 +1,27 @@ +## @file +# AmdSvsm Base Support Library. +# +# Copyright (C) 2024, Advanced Micro Devices, Inc. All rights reserved. +# SPDX-License-Identifier: BSD-2-Clause-Patent +# +## + +[Defines] + INF_VERSION= 1.29 + BASE_NAME = AmdSvsmLibNull + MODULE_UNI_FILE= AmdSvsmLibNull.uni + FILE_GUID = 62b45e0f-c9b4-45ce-a5b3-41762709b3d9 + MODULE_TYPE= BASE + VERSION_STRING = 1.0 + LIBRARY_CLASS = AmdSvsmLib + +[Sources.common] + AmdSvsmLibNull.c + +[Packages] + MdePkg/MdePkg.dec + UefiCpuPkg/UefiCpuPkg.dec + +[LibraryClasses] + BaseLib + diff --git a/UefiCpuPkg/Include/Library/AmdSvsmLib.h b/UefiCpuPkg/Include/Library/AmdSvsmLib.h new file mode 100644 index ..40e0e5bd4259 --- /dev/null +++ b/UefiCpuPkg/Include/Library/AmdSvsmLib.h @@ -0,0 +1,101 @@ +/** @file + Public header file for the AmdSvsmLib. + + This library class defines some routines used for invoking an SVSM when the + guest is not running at VMPL0. + + Copyright (C) 2024, Advanced Micro Devices, Inc. All
Re: [edk2-devel] [PATCH v3 16/24] UefiCpuPkg/MpInitLib: Use AmdSvsmSnpVmsaRmpAdjust() to set/clear VMSA
Acked-by: Ray Ni
Thanks,
Ray
From: Tom Lendacky
Sent: Friday, March 8, 2024 23:29
To: devel@edk2.groups.io
Cc: Ard Biesheuvel ; Aktas, Erdem
; Gerd Hoffmann ; Yao, Jiewen
; Laszlo Ersek ; Liming Gao
; Kinney, Michael D ; Xu,
Min M ; Liu, Zhiguang ; Kumar,
Rahul R ; Ni, Ray ; Michael Roth
Subject: [PATCH v3 16/24] UefiCpuPkg/MpInitLib: Use AmdSvsmSnpVmsaRmpAdjust()
to set/clear VMSA
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
The RMPADJUST instruction is used to change the VMSA attribute of a page,
but the VMSA attribute can only be changed when running at VMPL0. To
prepare for running at a less priviledged VMPL, use the AmdSvsmLib library
API to perform the RMPADJUST. The AmdSvsmLib library will perform the
proper operation on behalf of the caller.
Cc: Gerd Hoffmann
Cc: Laszlo Ersek
Cc: Rahul Kumar
Cc: Ray Ni
Acked-by: Gerd Hoffmann
Signed-off-by: Tom Lendacky
---
UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf | 1 +
UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf | 1 +
UefiCpuPkg/Library/MpInitLib/MpLib.h | 14 -
UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c| 20
UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c | 54 +++-
5 files changed, 9 insertions(+), 81 deletions(-)
diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
index 69950fcd1289..19745437f005 100644
--- a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
+++ b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
@@ -57,6 +57,7 @@ [LibraryClasses]
SynchronizationLib
PcdLib
CcExitLib
+ AmdSvsmLib
MicrocodeLib
[LibraryClasses.X64]
CpuPageTableLib
diff --git a/UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
b/UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
index 22f74a814534..679e51a1acd5 100644
--- a/UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
+++ b/UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
@@ -53,6 +53,7 @@ [LibraryClasses]
PeiServicesLib
PcdLib
CcExitLib
+ AmdSvsmLib
MicrocodeLib
[Pcd]
diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.h
b/UefiCpuPkg/Library/MpInitLib/MpLib.h
index 65e05c4806f5..179f8e585b5d 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.h
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.h
@@ -883,20 +883,6 @@ FillExchangeInfoDataSevEs (
IN volatile MP_CPU_EXCHANGE_INFO *ExchangeInfo
);
-/**
- 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.
diff --git a/UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c
b/UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c
index 0478e92317f1..963bd62494b9 100644
--- a/UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c
+++ b/UefiCpuPkg/Library/MpInitLib/Ia32/AmdSev.c
@@ -49,26 +49,6 @@ SevSnpCreateAP (
ASSERT (FALSE);
}
-/**
- 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
- )
-{
- //
- // RMPADJUST is not supported in 32-bit mode
- //
- return RETURN_UNSUPPORTED;
-}
-
/**
Determine if the SEV-SNP AP Create protocol should be used.
diff --git a/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c
b/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c
index bd12a5ee2fcb..981135621384 100644
--- a/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c
+++ b/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.c
@@ -10,6 +10,7 @@
#include "MpLib.h"
#include
+#include
#include
#include
@@ -38,20 +39,15 @@ SevSnpPerformApAction (
BOOLEAN InterruptState;
UINT64ExitInfo1;
UINT64ExitInfo2;
- UINT32RmpAdjustStatus;
UINT64VmgExitStatus;
+ EFI_STATUSVmsaStatus;
if (Action == SVM_VMGEXIT_SNP_AP_CREATE) {
//
-// To turn the page into a recognized VMSA page, issue RMPADJUST:
-// Target VMPL but numerically higher than current VMPL
-// Target PermissionMask is not used
+// Turn the page into a recognized VMSA page.
//
-RmpAdjustStatus = SevSnpRmpAdjust (
-(EFI_PHYSICAL_ADDRESS)(UINTN)SaveArea,
-TRUE
-);
-if (RmpAdjustStatus != 0) {
+VmsaStatus = AmdSvsmSnpVmsaRmpAdjust (SaveArea, ApicId, TRUE);
+if (EFI_ERROR (VmsaStatus)) {
DEBUG ((DEBUG_INFO, "SEV-SNP: RMPADJUST failed for VMSA creation\n"));
ASSERT (FALSE);
@@ -94,11 +90,8 @@ SevSnpPerformApAction (
// Make the current VMSA not runnable and accessible to be
// reprogrammed.
//
-RmpAdjustStat
Re: [edk2-devel] [edk2-platforms V2 3/3] MinPlatformPkg: Sort ApicIdOrderTable by special rules
Reviewed-by: Ray Ni
Thanks,
Ray
From: Tan, Dun
Sent: Monday, April 1, 2024 14:04
To: devel@edk2.groups.io
Cc: Ni, Ray ; Lou, Yun ; Chiu, Chasel
; Desimone, Nathaniel L
; Liming Gao ; Dong,
Eric
Subject: [edk2-platforms V2 3/3] MinPlatformPkg: Sort ApicIdOrderTable by
special rules
Sort ApicIdOrderTable by following special rules:
1. Make sure BSP is the first entry.
2. For APs, big core first, then small core.
With this implementation, BIOS can present cores in order
of relative performance in MADT. Linux OS would schedule
cores by the order that they are presented in the MADT
LocalX2ApicStruct entries.Then Linux OS would think of
this as relative performance order. This implementation
can benefit the linux os usage case.
Signed-off-by: Dun Tan
Cc: Ray Ni
Cc: Jason Lou
Cc: Chasel Chiu
Cc: Nate DeSimone
Cc: Liming Gao
Cc: Eric Dong
---
Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c | 63
+++
1 file changed, 63 insertions(+)
diff --git a/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c
b/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c
index 1fa70e3df9..389df48824 100644
--- a/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c
+++ b/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c
@@ -132,6 +132,62 @@ AppendCpuMapTableEntry (
}
+/**
+ Sort CpuApicIdOrderTable based on the following rules:
+ 1.Make sure BSP is the first entry.
+ 2.Big core first, then small core.
+
+ @param[in] CpuApicIdOrderTable Pointer to EFI_CPU_ID_ORDER_MAP
+ @param[in] CountNumber to EFI_CPU_ID_ORDER_MAP
+ @param[in] BspIndex BSP index
+**/
+VOID
+SortApicIdOrderTable (
+ IN EFI_CPU_ID_ORDER_MAP *CpuApicIdOrderTable,
+ IN UINTN Count,
+ IN UINTN BspIndex
+ )
+{
+ UINTN Index;
+ UINTN SubIndex;
+ EFI_CPU_ID_ORDER_MAP SortBuffer;
+
+ //
+ // Put BSP at the first entry.
+ //
+ if (BspIndex != 0) {
+CopyMem (, [BspIndex], sizeof
(EFI_CPU_ID_ORDER_MAP));
+CopyMem ([1], CpuApicIdOrderTable, (BspIndex) * sizeof
(EFI_CPU_ID_ORDER_MAP));
+CopyMem (CpuApicIdOrderTable, , sizeof (EFI_CPU_ID_ORDER_MAP));
+ }
+
+ //
+ // If there are more than 2 cores, perform insertion sort for rest cores
except the bsp in first entry
+ // to move big cores in front of small cores.
+ // Also the original order based on the MpService index inside big cores and
small cores are retained.
+ //
+ for (Index = 2; Index < Count; Index++) {
+if (CpuApicIdOrderTable[Index].CoreType == CPUID_CORE_TYPE_INTEL_ATOM) {
+ continue;
+}
+
+CopyMem (, [Index], sizeof
(EFI_CPU_ID_ORDER_MAP));
+
+for (SubIndex = Index - 1; SubIndex >= 1; SubIndex--) {
+ if (CpuApicIdOrderTable[SubIndex].CoreType ==
CPUID_CORE_TYPE_INTEL_ATOM) {
+CopyMem ([SubIndex + 1],
[SubIndex], sizeof (EFI_CPU_ID_ORDER_MAP));
+ } else {
+//
+// Except the BSP, all cores in front of SubIndex must be big cores.
+//
+break;
+ }
+}
+
+CopyMem ([SubIndex + 1], , sizeof
(EFI_CPU_ID_ORDER_MAP));
+ }
+}
+
/**
Get CPU core type.
@@ -174,6 +230,7 @@ CreateCpuLocalApicInTable (
EFI_CPU_ID_ORDER_MAP *CpuIdMapPtr;
UINT32Socket;
UINT32CpuidMaxInput;
+ UINTN BspIndex;
Status = EFI_SUCCESS;
@@ -198,6 +255,10 @@ CreateCpuLocalApicInTable (
);
+if ((ProcessorInfoBuffer.StatusFlag & PROCESSOR_AS_BSP_BIT) != 0) {
+ BspIndex = Index;
+}
+
CpuIdMapPtr = (EFI_CPU_ID_ORDER_MAP *) [Index];
if ((ProcessorInfoBuffer.StatusFlag & PROCESSOR_ENABLED_BIT) != 0) {
CpuIdMapPtr->ApicId = (UINT32)ProcessorInfoBuffer.ProcessorId;
@@ -230,6 +291,8 @@ CreateCpuLocalApicInTable (
}
}
+ SortApicIdOrderTable (CpuApicIdOrderTable, mNumberOfCpus, BspIndex);
+
DEBUG ((DEBUG_INFO, "::ACPI:: APIC ID Order Table Init. mNumOfBitShift =
%x\n", mNumOfBitShift));
DebugDisplayReOrderTable (CpuApicIdOrderTable);
--
2.31.1.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117285): https://edk2.groups.io/g/devel/message/117285
Mute This Topic: https://groups.io/mt/105259125/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-platforms V2 2/3] MinPlatformPkg: Get CoreType for all cores
Reviewed-by: Ray Ni
Thanks,
Ray
From: Tan, Dun
Sent: Monday, April 1, 2024 14:04
To: devel@edk2.groups.io
Cc: Ni, Ray ; Lou, Yun ; Chiu, Chasel
; Desimone, Nathaniel L
; Liming Gao ; Dong,
Eric
Subject: [edk2-platforms V2 2/3] MinPlatformPkg: Get CoreType for all cores
Add a new field CoreType in EFI_CPU_ID_ORDER_MAP
and get CoreType for all cores.
Signed-off-by: Dun Tan
Cc: Ray Ni
Cc: Jason Lou
Cc: Chasel Chiu
Cc: Nate DeSimone
Cc: Liming Gao
Cc: Eric Dong
---
Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c | 50
++
1 file changed, 46 insertions(+), 4 deletions(-)
diff --git a/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c
b/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c
index 62a7da290a..1fa70e3df9 100644
--- a/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c
+++ b/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c
@@ -18,6 +18,7 @@ typedef struct {
UINT32 Flags;
UINT32 SocketNum;
UINT32 Thread;
+ UINT8CoreType;
} EFI_CPU_ID_ORDER_MAP;
//
@@ -71,15 +72,16 @@ DebugDisplayReOrderTable (
{
UINT32 Index;
- DEBUG ((DEBUG_INFO, "Index AcpiProcId ApicId Thread Flags Skt\n"));
+ DEBUG ((DEBUG_INFO, "Index AcpiProcId ApicId Thread Flags Skt
CoreType\n"));
for (Index = 0; Index < mNumberOfCpus; Index++) {
-DEBUG ((DEBUG_INFO, " %02d 0x%02X 0x%02X %d %d
%d\n",
+DEBUG ((DEBUG_INFO, " %02d 0x%02X 0x%02X %d %d
%d 0x%x\n",
Index,
CpuApicIdOrderTable[Index].AcpiProcessorUid,
CpuApicIdOrderTable[Index].ApicId,
CpuApicIdOrderTable[Index].Thread,
CpuApicIdOrderTable[Index].Flags,
- CpuApicIdOrderTable[Index].SocketNum));
+ CpuApicIdOrderTable[Index].SocketNum,
+ CpuApicIdOrderTable[Index].CoreType));
}
}
@@ -130,6 +132,31 @@ AppendCpuMapTableEntry (
}
+/**
+ Get CPU core type.
+
+ @param[in] CpuApicIdOrderTable Point to a buffer which will be
filled in Core type information.
+**/
+VOID
+EFIAPI
+CollectCpuCoreType (
+ IN EFI_CPU_ID_ORDER_MAP *CpuApicIdOrderTable
+ )
+{
+ UINTNApNumber;
+ EFI_STATUS Status;
+ CPUID_NATIVE_MODEL_ID_AND_CORE_TYPE_EAX NativeModelIdAndCoreTypeEax;
+
+ Status = mMpService->WhoAmI (
+ mMpService,
+
+ );
+ ASSERT_EFI_ERROR (Status);
+
+ AsmCpuidEx (CPUID_HYBRID_INFORMATION, CPUID_HYBRID_INFORMATION_MAIN_LEAF,
, NULL, NULL, NULL);
+ CpuApicIdOrderTable[ApNumber].CoreType =
(UINT8)NativeModelIdAndCoreTypeEax.Bits.CoreType;
+}
+
/**
Collect all processors information and create a Cpu Apic Id table.
@@ -146,8 +173,23 @@ CreateCpuLocalApicInTable (
UINT32CurrProcessor;
EFI_CPU_ID_ORDER_MAP *CpuIdMapPtr;
UINT32Socket;
+ UINT32CpuidMaxInput;
- Status = EFI_SUCCESS;
+ Status = EFI_SUCCESS;
+
+ AsmCpuid (CPUID_SIGNATURE, , NULL, NULL, NULL);
+ if (CpuidMaxInput >= CPUID_HYBRID_INFORMATION) {
+CollectCpuCoreType (CpuApicIdOrderTable);
+mMpService->StartupAllAPs (
+ mMpService, // This
+ (EFI_AP_PROCEDURE) CollectCpuCoreType,// Procedure
+ TRUE, // SingleThread
+ NULL, // WaitEvent
+ 0,//
TimeoutInMicrosecsond
+ CpuApicIdOrderTable, //
ProcedureArgument
+ NULL // FailedCpuList
+ );
+ }
for (CurrProcessor = 0, Index = 0; CurrProcessor < mNumberOfCpus;
CurrProcessor++, Index++) {
Status = mMpService->GetProcessorInfo (
--
2.31.1.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117284): https://edk2.groups.io/g/devel/message/117284
Mute This Topic: https://groups.io/mt/105259124/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-platforms V2 1/3] MinPlatformPkg: Remove the global variable mForceX2ApicId
Reviewed-by: Ray Ni
Thanks,
Ray
From: Tan, Dun
Sent: Monday, April 1, 2024 14:04
To: devel@edk2.groups.io
Cc: Ni, Ray ; Lou, Yun ; Chiu, Chasel
; Desimone, Nathaniel L
; Liming Gao ; Dong,
Eric
Subject: [edk2-platforms V2 1/3] MinPlatformPkg: Remove the global variable
mForceX2ApicId
This global variable mForceX2ApicId is not assigned
to any value in code and will be initialized to 0 when
the driver is loaded. So remove the global variable
and related code that will not be executed.
Signed-off-by: Dun Tan
Cc: Ray Ni
Cc: Jason Lou
Cc: Chasel Chiu
Cc: Nate DeSimone
Cc: Liming Gao
Cc: Eric Dong
---
Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c
b/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c
index 2a833ec99c..62a7da290a 100644
--- a/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c
+++ b/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c
@@ -53,7 +53,6 @@ VOID *mLocalTable[] = {
EFI_ACPI_TABLE_PROTOCOL *mAcpiTable;
UINT32 mNumOfBitShift = 6;
-BOOLEAN mForceX2ApicId;
BOOLEAN mX2ApicEnabled;
EFI_MP_SERVICES_PROTOCOL*mMpService;
@@ -163,14 +162,6 @@ CreateCpuLocalApicInTable (
CpuIdMapPtr->Thread = ProcessorInfoBuffer.Location.Thread;
CpuIdMapPtr->Flags = ((ProcessorInfoBuffer.StatusFlag &
PROCESSOR_ENABLED_BIT) != 0);
CpuIdMapPtr->SocketNum = ProcessorInfoBuffer.Location.Package;
-
- //update processorbitMask
- if (CpuIdMapPtr->Flags == 1) {
-if (mForceX2ApicId) {
- CpuIdMapPtr->SocketNum&= 0x7;
- CpuIdMapPtr->AcpiProcessorUid &= 0xFF; //keep lower 8bit due to use
Proc obj in dsdt
-}
- }
} else { //not enabled
CpuIdMapPtr->ApicId = (UINT32)-1;
CpuIdMapPtr->Thread = (UINT32)-1;
@@ -1537,7 +1528,6 @@ InstallAcpiPlatform (
}
DEBUG ((DEBUG_INFO, "mX2ApicEnabled - 0x%x\n", mX2ApicEnabled));
- DEBUG ((DEBUG_INFO, "mForceX2ApicId - 0x%x\n", mForceX2ApicId));
// support up to 64 threads/socket
AsmCpuidEx (CPUID_EXTENDED_TOPOLOGY, 1, , NULL, NULL, NULL);
--
2.31.1.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117282): https://edk2.groups.io/g/devel/message/117282
Mute This Topic: https://groups.io/mt/105259123/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-platforms V2] MinPlatformPkg: Corret AcpiProcessorUid in MADT
Reviewed-by: Ray Ni
Thanks,
Ray
From: Tan, Dun
Sent: Monday, April 1, 2024 13:59
To: devel@edk2.groups.io
Cc: Ni, Ray ; Lou, Yun ; Chiu, Chasel
; Desimone, Nathaniel L
; Liming Gao ; Dong,
Eric
Subject: [edk2-platforms V2] MinPlatformPkg: Corret AcpiProcessorUid in MADT
Change AcpiProcessorUid in CpuApicIdOrderTable to
the index in MpService regardless of disabled core.
Let's take a simple example:
There are 2 enabled cores and 1 disabled core.
APICID Index in MpService
0x_0
0x_0010(disbaled) 1
0x_00402
With current implementation, the results of the x2apic
structure entries in MADT are:
MADT Entry APICID AcpiProcessorUid
0 0x_ 0
1 0x_0040 1
The AcpiProcessorUid will be associated with the
processor device defined in DSDT/SSDT. To make sure
the x2apic structure entries in MADT can be mapped to
the right processor devices in DSDT, the AcpiProcessorUid
of the second x2apic structure entry in MADT should
be kept as 2, which is the core index in MpService.
Signed-off-by: Dun Tan
Cc: Ray Ni
Cc: Jason Lou
Cc: Chasel Chiu
Cc: Nate DeSimone
Cc: Liming Gao
Cc: Eric Dong
---
Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c
b/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c
index 2a833ec99c..f6ea7454d3 100644
--- a/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c
+++ b/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c
@@ -190,7 +190,7 @@ CreateCpuLocalApicInTable (
//
for (Socket = 0; Socket < FixedPcdGet32 (PcdMaxCpuSocketCount); Socket++) {
for (CurrProcessor = 0, Index = 0; CurrProcessor < mNumberOfCpus;
CurrProcessor++) {
- if (CpuApicIdOrderTable[CurrProcessor].Flags &&
(CpuApicIdOrderTable[CurrProcessor].SocketNum == Socket)) {
+ if (CpuApicIdOrderTable[CurrProcessor].SocketNum == Socket) {
CpuApicIdOrderTable[CurrProcessor].AcpiProcessorUid =
(CpuApicIdOrderTable[CurrProcessor].SocketNum << mNumOfBitShift) + Index;
Index++;
}
--
2.31.1.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117283): https://edk2.groups.io/g/devel/message/117283
Mute This Topic: https://groups.io/mt/105259071/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 6/6] StandaloneMmPkg: Support to unregister MMI handler in MMI handlers
Zhiguang,
I feel that you could simplify the logic in MmiManage () by adding a new local
variable to cache the return status.
Can you think about that and come up with a new version of patch?
Also, the list maninpulation logics are duplicated in MmiManage () and
Unregister(). can you try to avoid it?
Thanks,
Ray
From: Liu, Zhiguang
Sent: Monday, March 18, 2024 10:19
To: devel@edk2.groups.io
Cc: Liu, Zhiguang ; Liming Gao
; Wu, Jiaxin ; Ni, Ray
; Laszlo Ersek ; Ard Biesheuvel
; Sami Mujawar
Subject: [PATCH 6/6] StandaloneMmPkg: Support to unregister MMI handler in MMI
handlers
Unregistering MMI handler will free the MMI_HANDLER. However, the
MmiManage() may be using the link node from MMI_HANDLER for loop if
the unregistering happens in MMI handlers.
To avoid that, the idea is to inform MmiHandlerUnRegister() whether
it's running or not running on the stack of MmiManage(), and to
postpone MMI_HANDLER deletion until after the loop finishes.
Cc: Liming Gao
Cc: Jiaxin Wu
Cc: Ray Ni
Cc: Laszlo Ersek
Cc: Ray Ni
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
Cc: Sami Mujawar
Signed-off-by: Zhiguang Liu
---
StandaloneMmPkg/Core/Mmi.c | 102 +++--
1 file changed, 98 insertions(+), 4 deletions(-)
diff --git a/StandaloneMmPkg/Core/Mmi.c b/StandaloneMmPkg/Core/Mmi.c
index 0de6fd17fc..d9cdd1f1a7 100644
--- a/StandaloneMmPkg/Core/Mmi.c
+++ b/StandaloneMmPkg/Core/Mmi.c
@@ -34,8 +34,14 @@ typedef struct {
LIST_ENTRYLink;// Link on MMI_ENTRY.MmiHandlers
EFI_MM_HANDLER_ENTRY_POINTHandler; // The mm handler's entry point
MMI_ENTRY *MmiEntry;
+ BOOLEAN NeedDeleted; // To delete this MMI_HANDLER
later
} MMI_HANDLER;
+//
+// mMmiManageCallingDepth is used to track the depth of recursive calls of
MmiManage.
+//
+UINTN mMmiManageCallingDepth = 0;
+
LIST_ENTRY mRootMmiHandlerList = INITIALIZE_LIST_HEAD_VARIABLE
(mRootMmiHandlerList);
LIST_ENTRY mMmiEntryList = INITIALIZE_LIST_HEAD_VARIABLE
(mMmiEntryList);
@@ -126,11 +132,14 @@ MmiManage (
{
LIST_ENTRY *Link;
LIST_ENTRY *Head;
+ LIST_ENTRY *EntryLink;
MMI_ENTRY*MmiEntry;
MMI_HANDLER *MmiHandler;
BOOLEAN SuccessReturn;
+ BOOLEAN CanReturn;
EFI_STATUS Status;
+ mMmiManageCallingDepth++;
Status= EFI_NOT_FOUND;
SuccessReturn = FALSE;
if (HandlerType == NULL) {
@@ -171,7 +180,12 @@ MmiManage (
// no additional handlers will be processed and EFI_INTERRUPT_PENDING
will be returned.
//
if (HandlerType != NULL) {
- return EFI_INTERRUPT_PENDING;
+ //
+ // Won't go to next Handler, and will return with
EFI_INTERRUPT_PENDING later
+ //
+ SuccessReturn = FALSE;
+ Status= EFI_INTERRUPT_PENDING;
+ CanReturn = TRUE;
}
break;
@@ -183,7 +197,10 @@ MmiManage (
// additional handlers will be processed.
//
if (HandlerType != NULL) {
- return EFI_SUCCESS;
+ //
+ // Won't go to next Handler, and return with EFI_SUCCESS
+ //
+ CanReturn = TRUE;
}
SuccessReturn = TRUE;
@@ -211,12 +228,78 @@ MmiManage (
ASSERT_EFI_ERROR (Status);
break;
}
+
+if (CanReturn) {
+ break;
+}
}
if (SuccessReturn) {
Status = EFI_SUCCESS;
}
+ ASSERT (mMmiManageCallingDepth > 0);
+ mMmiManageCallingDepth--;
+
+ //
+ // The MmiHandlerUnRegister won't take effect inside MmiManage.
+ // Before returned from MmiManage, delete the MmiHandler which is
+ // marked as NeedDeleted.
+ // Note that MmiManage can be called recursively.
+ //
+ if (mMmiManageCallingDepth == 0) {
+//
+// Go through all MmiHandler in root Mmi handlers
+//
+for ( Link = GetFirstNode ()
+ ; !IsNull (, Link);
+ )
+{
+ MmiHandler = CR (Link, MMI_HANDLER, Link, MMI_HANDLER_SIGNATURE);
+ Link = GetNextNode (, Link);
+ if (MmiHandler->NeedDeleted) {
+//
+// Remove MmiHandler if the NeedDeleted is set.
+//
+RemoveEntryList (>Link);
+FreePool (MmiHandler);
+ }
+}
+
+//
+// Go through all MmiHandler in non-root MMI handlers
+//
+for ( EntryLink = GetFirstNode ()
+ ; !IsNull (, EntryLink);
+ )
+{
+ MmiEntry = CR (EntryLink, MMI_ENTRY, AllEntries, MMI_ENTRY_SIGNATURE);
+ EntryLink = GetNextNode (, EntryLink);
+ for ( Link = GetFirstNode (>MmiHandlers)
+; !IsNull (>MmiHandlers, Link);
+)
+ {
+MmiHandler = CR (Link, MMI_HANDLER, Link, MMI_HANDLER_SIGNATURE);
+Link = GetNextNode (>MmiHandlers, Link);
+if (MmiHandler->NeedDeleted) {
+ //
+ // Remove MmiHandler if the NeedDeleted is set.
+ //
+
Re: [edk2-devel] [PATCH v2 00/13] Part 2 patch set to add LoongArch support into UefiCpuPkg
Chao, Thank you for your patience for preparing the new version of patches. However, I still have following minor comments: For patches 1~6: Reviewed-by: Ray Ni For patches 7: can you define meaning of bits in the Attributes/Mask? It seems you are reusing the definitions defined for 7.2.3 EFI_BOOT_SERVICES.GetMemoryMap(). It's fine. But please mention that in comments. Also please use UINT64 for Attributes instead of UINTN. For patches 8: Can you rename PcdCpuExceptionVectorBaseAddress to PcdLoongArch64ExceptionVectorBaseAddress and put the PCD definition/reference in the DEC/INF LoongArch64 section? For patches 9: Please make accordingly changes when you address comments for patch 7. For patches 10, 11: Can the lib be avoided if the logic is implemented in CpuDxe driver? For patch 12(UefiCpuPkg: Add multiprocessor library for LoongArch64): Reviewed-by: Ray Ni For patch 13: Please make accordingly changes when you address comments for patch 8. Thanks, Ray From: Gerd Hoffmann Sent: Friday, March 22, 2024 20:39 To: Chao Li Cc: devel@edk2.groups.io ; Ni, Ray ; Kumar, Rahul R ; Sami Mujawar ; Sunil V L ; Bibo Mao ; Dongyan Qian Subject: Re: [PATCH v2 00/13] Part 2 patch set to add LoongArch support into UefiCpuPkg On Wed, Mar 20, 2024 at 04:41:52PM +0800, Chao Li wrote: > This patch set adjusted some order in UefiCpuPig alphabetically, added > LoongArch libraries and drivers into UefiCpuPkg, it is a continuation of > the first patch series v8 submitted at > https://edk2.groups.io/g/devel/message/114526. > > And also separated from https://edk2.groups.io/g/devel/message/116583. > > This series only contents the changes for UefiCpuPkg. > > Patch1-Patch4: Reorder some INF files located in UefiCpuPkg > alphabetically. > > Patch5-Patch13: Added Timer, CpuMmuLib, CpuMmuInitLib, MpInitLib, CpuDxe > for LoongArch, and added some PCD and header files requested by the > above libraries and drivers. > > Modfied modules: UefiCpuPkg > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4726 > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4734 > > PR: https://github.com/tianocore/edk2/pull/5483 > > V1 -> V2: > 1. Removed PcdCpuMmuIsEnabled. > 2. Removed API GetMemoryRegionAttributes API as it is no longer needed. > 3. Patch3, added two empty line in DXE and PEI INF files. > 4. Patch5, added the Status check in GetTimeInnanoSecond function. > 5. Separated into two series, this is series one, and the second one is > OvmfPkg. While I can't comment on the loongarch architecture details the code and the integration into build system looks overall sane to me. Series: Acked-by: Gerd Hoffmann take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#117077): https://edk2.groups.io/g/devel/message/117077 Mute This Topic: https://groups.io/mt/105041080/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 07/13] UefiCpuPkg: Add CpuMmuLib.h to UefiCpuPkg
Just curious, how many modules need to call this API?
If there is only one (I guess CpuDxe driver), should LoongArch CPU driver
implement the logic internally so that the lib class/API can be avoided?
Thanks,
Ray
From: Chao Li
Sent: Wednesday, March 20, 2024 16:43
To: devel@edk2.groups.io
Cc: Ni, Ray ; Kumar, Rahul R ; Gerd
Hoffmann ; Leif Lindholm ; Ard
Biesheuvel ; Sami Mujawar ;
Sunil V L ; Warkentin, Andrei
Subject: [PATCH v2 07/13] UefiCpuPkg: Add CpuMmuLib.h to UefiCpuPkg
Add a new header file CpuMmuLib.h, whitch is referenced from
ArmPkg/Include/Library/ArmMmuLib.h. Currently, only support for
LoongArch64 is added, and more architectures can be accommodated in the
future.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4734
Cc: Ray Ni
Cc: Rahul Kumar
Cc: Gerd Hoffmann
Cc: Leif Lindholm
Cc: Ard Biesheuvel
Cc: Sami Mujawar
Cc: Sunil V L
Cc: Andrei Warkentin
Signed-off-by: Chao Li
Acked-by: Gerd Hoffmann
---
UefiCpuPkg/Include/Library/CpuMmuLib.h | 55 ++
UefiCpuPkg/UefiCpuPkg.dec | 4 ++
2 files changed, 59 insertions(+)
create mode 100644 UefiCpuPkg/Include/Library/CpuMmuLib.h
diff --git a/UefiCpuPkg/Include/Library/CpuMmuLib.h
b/UefiCpuPkg/Include/Library/CpuMmuLib.h
new file mode 100644
index 00..26d2d65524
--- /dev/null
+++ b/UefiCpuPkg/Include/Library/CpuMmuLib.h
@@ -0,0 +1,33 @@
+/** @file
+
+ Copyright (c) 2024 Loongson Technology Corporation Limited. All rights
reserved.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef CPU_MMU_LIB_H_
+#define CPU_MMU_LIB_H_
+
+#include
+
+/**
+ Sets the Attributes of the specified memory region.
+
+ @param[in] BaseAddressThe base address of the memory region to set the
Attributes.
+ @param[in] Length The length of the memory region to set the
Attributes.
+ @param[in] Attributes The Attributes to be set.
+ @param[in] AttributeMask Mask of memory attributes to take into account.
+
+ @retval EFI_SUCCESSThe Attributes was set successfully
+**/
+EFI_STATUS
+EFIAPI
+SetMemoryRegionAttributes (
+ IN EFI_PHYSICAL_ADDRESS BaseAddress,
+ IN UINTN Length,
+ IN UINTN Attributes,
+ IN UINT64AttributeMask
+ );
+
+#endif // CPU_MMU_LIB_H_
diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index 571b59b36f..ca744fab55 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -72,6 +72,10 @@ [LibraryClasses.RISCV64]
##
RiscVMmuLib|Include/Library/BaseRiscVMmuLib.h
+[LibraryClasses.LoongArch64]
+ ## @libraryclass Provides functions for the memory management unit.
+ CpuMmuLib|Include/Library/CpuMmuLib.h
+
[Guids]
gUefiCpuPkgTokenSpaceGuid = { 0xac05bf33, 0x995a, 0x4ed4, { 0xaa, 0xb8,
0xef, 0x7a, 0xe8, 0xf, 0x5c, 0xb0 }}
gMsegSmramGuid = { 0x5802bce4, 0x, 0x4e33, { 0xa1, 0x30,
0xeb, 0xad, 0x27, 0xf0, 0xe4, 0x39 }}
--
2.27.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117075): https://edk2.groups.io/g/devel/message/117075
Mute This Topic: https://groups.io/mt/105041094/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 07/13] UefiCpuPkg: Add CpuMmuLib.h to UefiCpuPkg
2 comments:
1.
Atrributes is type of UINTN but Mask is type of UINT64. Should they follow the
same UINT64 type?
2.
The header file does not define the meaning of each bit. As a reference,
MdeModulePkg/Include/Ppi/MemoryAttribute.h defines 3 bits can be used for
memory permission setting.
@Ard Biesheuvel<mailto:ardb+tianoc...@kernel.org>,
Do you think that MdeModulePkg/Include/Ppi/MemoryAttribute.h misses a
capability to return the attributes of a given range of memory address?
For your reference, Chao defined a lib API as below to serve the same request:
/**
Finds the first of the length and memory properties of the memory region
corresponding
to the specified base address.
@param[in] BaseAddress To find the base address of the memory
region.
@param[in, out] RegionLength Pointer holding:
- At entry, the length of the memory
region
expected to be found.
- At exit, the length of the memory
region found.
@param[out] RegionAttributes Properties of the memory region found.
@retval EFI_SUCCESSThe corresponding memory area was successfully found
EFI_NOT_FOUNDNo memory area found
**/
EFI_STATUS
EFIAPI
GetMemoryRegionAttributes (
IN UINTN BaseAddress,
IN OUT UINTN *RegionLength,
OUTUINTN *RegionAttributes
);
I hope we can align the lib API and PPI definition to one so that the lib API
can be dropped in future (not in this round of patch).
Thanks,
Ray
From: Chao Li
Sent: Wednesday, March 20, 2024 16:43
To: devel@edk2.groups.io
Cc: Ni, Ray ; Kumar, Rahul R ; Gerd
Hoffmann ; Leif Lindholm ; Ard
Biesheuvel ; Sami Mujawar ;
Sunil V L ; Warkentin, Andrei
Subject: [PATCH v2 07/13] UefiCpuPkg: Add CpuMmuLib.h to UefiCpuPkg
Add a new header file CpuMmuLib.h, whitch is referenced from
ArmPkg/Include/Library/ArmMmuLib.h. Currently, only support for
LoongArch64 is added, and more architectures can be accommodated in the
future.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4734
Cc: Ray Ni
Cc: Rahul Kumar
Cc: Gerd Hoffmann
Cc: Leif Lindholm
Cc: Ard Biesheuvel
Cc: Sami Mujawar
Cc: Sunil V L
Cc: Andrei Warkentin
Signed-off-by: Chao Li
Acked-by: Gerd Hoffmann
---
UefiCpuPkg/Include/Library/CpuMmuLib.h | 55 ++
UefiCpuPkg/UefiCpuPkg.dec | 4 ++
2 files changed, 59 insertions(+)
create mode 100644 UefiCpuPkg/Include/Library/CpuMmuLib.h
diff --git a/UefiCpuPkg/Include/Library/CpuMmuLib.h
b/UefiCpuPkg/Include/Library/CpuMmuLib.h
new file mode 100644
index 00..26d2d65524
--- /dev/null
+++ b/UefiCpuPkg/Include/Library/CpuMmuLib.h
@@ -0,0 +1,33 @@
+/** @file
+
+ Copyright (c) 2024 Loongson Technology Corporation Limited. All rights
reserved.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef CPU_MMU_LIB_H_
+#define CPU_MMU_LIB_H_
+
+#include
+
+/**
+ Sets the Attributes of the specified memory region.
+
+ @param[in] BaseAddressThe base address of the memory region to set the
Attributes.
+ @param[in] Length The length of the memory region to set the
Attributes.
+ @param[in] Attributes The Attributes to be set.
+ @param[in] AttributeMask Mask of memory attributes to take into account.
+
+ @retval EFI_SUCCESSThe Attributes was set successfully
+**/
+EFI_STATUS
+EFIAPI
+SetMemoryRegionAttributes (
+ IN EFI_PHYSICAL_ADDRESS BaseAddress,
+ IN UINTN Length,
+ IN UINTN Attributes,
+ IN UINT64AttributeMask
+ );
+
+#endif // CPU_MMU_LIB_H_
diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index 571b59b36f..ca744fab55 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -72,6 +72,10 @@ [LibraryClasses.RISCV64]
##
RiscVMmuLib|Include/Library/BaseRiscVMmuLib.h
+[LibraryClasses.LoongArch64]
+ ## @libraryclass Provides functions for the memory management unit.
+ CpuMmuLib|Include/Library/CpuMmuLib.h
+
[Guids]
gUefiCpuPkgTokenSpaceGuid = { 0xac05bf33, 0x995a, 0x4ed4, { 0xaa, 0xb8,
0xef, 0x7a, 0xe8, 0xf, 0x5c, 0xb0 }}
gMsegSmramGuid = { 0x5802bce4, 0x, 0x4e33, { 0xa1, 0x30,
0xeb, 0xad, 0x27, 0xf0, 0xe4, 0x39 }}
--
2.27.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117074): https://edk2.groups.io/g/devel/message/117074
Mute This Topic: https://groups.io/mt/105041094/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 02/13] UefiCpuPkg/CpuExceptionHandlerLib: Reorder the INF files alphabetically
I feel that ordering alphabetically may break the logical groups. For example, below two might be placed in a reverse way. CpuExceptionCommon.h CpuExceptionCommon.c But luckily, you didn't re-order the above to make .c above .h. So, you are not simply ordering them alphabetically. Nevertheless, the current changes look good to me. Reviewed-by: Ray Ni Thanks, Ray From: Chao Li Sent: Wednesday, March 20, 2024 16:42 To: devel@edk2.groups.io Cc: Ni, Ray ; Kumar, Rahul R ; Gerd Hoffmann Subject: [PATCH v2 02/13] UefiCpuPkg/CpuExceptionHandlerLib: Reorder the INF files alphabetically Some of the order is not in alphabetical, reorder. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4726 Cc: Ray Ni Cc: Rahul Kumar Cc: Gerd Hoffmann Signed-off-by: Chao Li Acked-by: Gerd Hoffmann --- .../DxeCpuExceptionHandlerLib.inf | 20 +-- .../PeiCpuExceptionHandlerLib.inf | 16 +++ .../SecPeiCpuExceptionHandlerLib.inf | 12 +-- .../SmmCpuExceptionHandlerLib.inf | 16 +++ 4 files changed, 32 insertions(+), 32 deletions(-) diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf index fdbebadab9..aabcabff0f 100644 --- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf +++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf @@ -22,21 +22,21 @@ [Defines] # [Sources.Ia32] - Ia32/ExceptionHandlerAsm.nasm - Ia32/ExceptionTssEntryAsm.nasm Ia32/ArchExceptionHandler.c Ia32/ArchInterruptDefs.h + Ia32/ExceptionHandlerAsm.nasm + Ia32/ExceptionTssEntryAsm.nasm [Sources.X64] - X64/ExceptionHandlerAsm.nasm X64/ArchExceptionHandler.c X64/ArchInterruptDefs.h + X64/ExceptionHandlerAsm.nasm [Sources.common] CpuExceptionCommon.h CpuExceptionCommon.c - PeiDxeSmmCpuException.c DxeException.c + PeiDxeSmmCpuException.c [Pcd] gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard @@ -53,14 +53,14 @@ [Packages] [LibraryClasses] BaseLib - SerialPortLib - PrintLib - SynchronizationLib + CcExitLib + DebugLib LocalApicLib - PeCoffGetEntryPointLib MemoryAllocationLib - DebugLib - CcExitLib + PeCoffGetEntryPointLib + PrintLib + SerialPortLib + SynchronizationLib [BuildOptions] XCODE:*_*_X64_NASM_FLAGS = -D NO_ABSOLUTE_RELOCS_IN_TEXT diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf index 3bcaff5c5f..3a11516e32 100644 --- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf +++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf @@ -22,15 +22,15 @@ [Defines] # [Sources.Ia32] - Ia32/ExceptionHandlerAsm.nasm - Ia32/ExceptionTssEntryAsm.nasm Ia32/ArchExceptionHandler.c Ia32/ArchInterruptDefs.h + Ia32/ExceptionHandlerAsm.nasm + Ia32/ExceptionTssEntryAsm.nasm [Sources.X64] - X64/SecPeiExceptionHandlerAsm.nasm X64/ArchExceptionHandler.c X64/ArchInterruptDefs.h + X64/SecPeiExceptionHandlerAsm.nasm [Sources.common] CpuExceptionCommon.h @@ -45,14 +45,14 @@ [Packages] [LibraryClasses] BaseLib - SerialPortLib - PrintLib - LocalApicLib - PeCoffGetEntryPointLib + CcExitLib HobLib + LocalApicLib MemoryAllocationLib + PeCoffGetEntryPointLib + PrintLib + SerialPortLib SynchronizationLib - CcExitLib [Pcd] gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard# CONSUMES diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf b/UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf index e7b1144f69..f8e597d86d 100644 --- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf +++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf @@ -22,15 +22,15 @@ [Defines] # [Sources.Ia32] - Ia32/ExceptionHandlerAsm.nasm - Ia32/ExceptionTssEntryAsm.nasm Ia32/ArchExceptionHandler.c Ia32/ArchInterruptDefs.h + Ia32/ExceptionHandlerAsm.nasm + Ia32/ExceptionTssEntryAsm.nasm [Sources.X64] - X64/SecPeiExceptionHandlerAsm.nasm X64/ArchExceptionHandler.c X64/ArchInterruptDefs.h + X64/SecPeiExceptionHandlerAsm.nasm [Sources.common] CpuExceptionCommon.h @@ -44,11 +44,11 @@ [Packages] [LibraryClasses] BaseLib - SerialPortLib - PrintLib + CcExitLib LocalApicLib PeCoffGetEntryPointLib - CcExitLib + PrintLib + SerialPortLib [Pcd] gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf b/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf index 27f0b96fa9..cc280a6ee7 100644 --- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf +++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib
Re: [edk2-devel] [PATCH v2 01/13] UefiCpuPkg/CpuTimerLib: Reorder the INF file alphabetically
Reviewed-by: Ray Ni Thanks, Ray From: Chao Li Sent: Wednesday, March 20, 2024 16:42 To: devel@edk2.groups.io Cc: Ni, Ray ; Kumar, Rahul R ; Gerd Hoffmann Subject: [PATCH v2 01/13] UefiCpuPkg/CpuTimerLib: Reorder the INF file alphabetically Some of the order is not in alphabetical, reorder. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4726 Cc: Ray Ni Cc: Rahul Kumar Cc: Gerd Hoffmann Signed-off-by: Chao Li Acked-by: Gerd Hoffmann --- UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf index de0648de91..f0f4ae902a 100644 --- a/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf +++ b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf @@ -28,8 +28,8 @@ [Packages] [LibraryClasses] BaseLib - PcdLib DebugLib + PcdLib [Pcd] gUefiCpuPkgTokenSpaceGuid.PcdCpuCoreCrystalClockFrequency ## CONSUMES -- 2.27.0 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#117019): https://edk2.groups.io/g/devel/message/117019 Mute This Topic: https://groups.io/mt/105041086/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2] IntelFsp2WrapperPkg: Error handling of FspmWrapperInit()
Reviewed-by: Ray Ni
Thanks,
Ray
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Du Lin
> Sent: Thursday, March 14, 2024 10:02 AM
> To: devel@edk2.groups.io
> Cc: Lin, Du ; S, Ashraf Ali ; Chiu,
> Chasel ; Chen, Gang C ;
> Duggapu, Chinni B ; Desimone, Nathaniel L
> ; Zeng, Star ;
> Mohapatra, Susovan ; Kuo, Ted
>
> Subject: [edk2-devel] [PATCH v2] IntelFsp2WrapperPkg: Error handling of
> FspmWrapperInit()
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4701
>
> The error handling of FspmWrapperInit() is limited to ASSERT
> statements only, which only works in debug builds, but not in
> release builds.
> Fix the issue by enhancing the error handling of FspmWrapperInit()
> to cover both debug builds and release builds.
>
> Signed-off-by: Du Lin
> Cc: Ashraf Ali S
> Cc: Chasel Chiu
> Cc: Chen Gang C
> Cc: Duggapu Chinni B
> Cc: Nate DeSimone
> Cc: Star Zeng
> Cc: Susovan Mohapatra
> Cc: Ted Kuo
> ---
> IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c | 8
>
> 1 file changed, 8 insertions(+)
>
> diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> index ba0c742fea..7f1deb9542 100644
> --- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> +++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> @@ -197,12 +197,20 @@ FspmWrapperInit (
>
>MeasurementExcludedFvPpi = AllocatePool (sizeof
> (*MeasurementExcludedFvPpi));
>ASSERT (MeasurementExcludedFvPpi != NULL);
> + if (MeasurementExcludedFvPpi == NULL) {
> +return EFI_OUT_OF_RESOURCES;
> + }
> +
>MeasurementExcludedFvPpi->Count = 1;
>MeasurementExcludedFvPpi->Fv[0].FvBase = PcdGet32
> (PcdFspmBaseAddress);
>MeasurementExcludedFvPpi->Fv[0].FvLength =
> ((EFI_FIRMWARE_VOLUME_HEADER *)(UINTN)PcdGet32
> (PcdFspmBaseAddress))->FvLength;
>
>MeasurementExcludedPpiList = AllocatePool (sizeof
> (*MeasurementExcludedPpiList));
>ASSERT (MeasurementExcludedPpiList != NULL);
> + if (MeasurementExcludedPpiList == NULL) {
> +return EFI_OUT_OF_RESOURCES;
> + }
> +
>MeasurementExcludedPpiList->Flags = EFI_PEI_PPI_DESCRIPTOR_PPI |
> EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST;
>MeasurementExcludedPpiList->Guid =
>
>MeasurementExcludedPpiList->Ppi = MeasurementExcludedFvPpi;
> --
> 2.44.0.windows.1
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116726): https://edk2.groups.io/g/devel/message/116726
Mute This Topic: https://groups.io/mt/104919472/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] IntelFsp2WrapperPkg: Error handling of FspmWrapperInit()
> - ASSERT (MeasurementExcludedFvPpi != NULL);
> + if (MeasurementExcludedFvPpi == NULL) {
> +ASSERT (FALSE);
I prefer the original meaningful assertion instead of ASSERT (FALSE).
Adding if-check is a good change to me.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116713): https://edk2.groups.io/g/devel/message/116713
Mute This Topic: https://groups.io/mt/104886876/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] Maintainers.txt: remove Laszlo's entries
This is a good idea to have a CREDITS file in edk2 repo. Pedro, would you mind initiating one? Thanks, Ray From: devel@edk2.groups.io on behalf of Pedro Falcato Sent: Friday, March 8, 2024 23:07 To: devel@edk2.groups.io ; ler...@redhat.com Cc: Kinney, Michael D ; Andrew Fish ; Ard Biesheuvel ; Gerd Hoffmann ; Yao, Jiewen ; Leif Lindholm ; Kumar, Rahul R ; Ni, Ray ; Sami Mujawar Subject: Re: [edk2-devel] [PATCH] Maintainers.txt: remove Laszlo's entries On Fri, Mar 8, 2024 at 9:14 AM Laszlo Ersek wrote: > > On 3/6/24 23:22, Michael D Kinney wrote: > > Reviewed-by: Michael D Kinney > > Merged as commit ccf91b518f22, via > <https://github.com/tianocore/edk2/pull/5450>. > > Thank you all for everything, Thank you for your great (and often thankless) work throughout the whole of EDK2 and OVMF. It was great to have learned from you throughout the years. PS: CREDITS file anyone? -- Pedro -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#116573): https://edk2.groups.io/g/devel/message/116573 Mute This Topic: https://groups.io/mt/104775206/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] Maintainers.txt: remove Laszlo's entries
Laszlo, Thank you for all you've done to edk2 and especially UefiCpuPkg review. Reviewed-by: Ray Ni Thanks, Ray From: Laszlo Ersek Sent: Thursday, March 7, 2024 5:05 To: edk2-devel-groups-io Cc: Andrew Fish ; Ard Biesheuvel ; Gerd Hoffmann ; Yao, Jiewen ; Leif Lindholm ; Kinney, Michael D ; Kumar, Rahul R ; Ni, Ray ; Sami Mujawar Subject: [PATCH] Maintainers.txt: remove Laszlo's entries Red Hat and I have mutually and amicably agreed to separate. Remove my entries from "Maintainers.txt". Cc: Andrew Fish Cc: Ard Biesheuvel Cc: Gerd Hoffmann Cc: Jiewen Yao Cc: Leif Lindholm Cc: Michael D Kinney Cc: Rahul Kumar Cc: Ray Ni Cc: Sami Mujawar Signed-off-by: Laszlo Ersek --- Notes: I'd like to merge this patch very soon, but not before merging the following series: * [PATCH v2 00/10] clean up ProcessLibraryConstructorList() declarations in SEC modules msgid <20240305113843.68812-1-ler...@redhat.com> https://edk2.groups.io/g/devel/message/116367 * [edk2-platforms PATCH v2 0/4] clean up ProcessLibraryConstructorList() declarations in SEC modules msgid <20240305120126.70259-1-ler...@redhat.com> https://edk2.groups.io/g/devel/message/116378 Maintainers.txt | 3 --- 1 file changed, 3 deletions(-) diff --git a/Maintainers.txt b/Maintainers.txt index 9038f9eb3005..799f27f914ce 100644 --- a/Maintainers.txt +++ b/Maintainers.txt @@ -151,7 +151,6 @@ ArmVirtPkg F: ArmVirtPkg/ W: https://github.com/tianocore/tianocore.github.io/wiki/ArmVirtPkg M: Ard Biesheuvel [ardbiesheuvel] -M: Laszlo Ersek [lersek] R: Leif Lindholm [leiflindholm] R: Sami Mujawar [samimujawar] R: Gerd Hoffmann [kraxel] @@ -462,7 +461,6 @@ F: OvmfPkg/ W: http://www.tianocore.org/ovmf/ M: Ard Biesheuvel [ardbiesheuvel] M: Jiewen Yao [jyao1] -M: Laszlo Ersek [lersek] R: Gerd Hoffmann [kraxel] S: Maintained @@ -622,7 +620,6 @@ UefiCpuPkg F: UefiCpuPkg/ W: https://github.com/tianocore/tianocore.github.io/wiki/UefiCpuPkg M: Ray Ni [niruiyu] -M: Laszlo Ersek [lersek] R: Rahul Kumar [rahul1-kumar] R: Gerd Hoffmann [kraxel] -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#116572): https://edk2.groups.io/g/devel/message/116572 Mute This Topic: https://groups.io/mt/104775206/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack overflow issue due to nested interrupts
Michael, do you have any updated patch? Thanks, Ray From: Michael Brown Sent: Friday, March 1, 2024 19:10 To: Paolo Bonzini Cc: Ni, Ray ; devel@edk2.groups.io ; Kinney, Michael D ; Liming Gao ; Laszlo Ersek Subject: Re: [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack overflow issue due to nested interrupts On 01/03/2024 09:33, Paolo Bonzini wrote: > On Fri, Mar 1, 2024 at 10:27 AM Michael Brown wrote: >> It's possible that it doesn't matter. The new logic will effectively >> mean that RestoreTPL() will restore not only the TPL but also the >> interrupts-enabled state to whatever existed at the time of the >> corresponding RaiseTPL(). > > Right: that's what my comment says > > + // However, when the handler calls RestoreTPL > + // before returning, we want to keep interrupts disabled. This > + // restores the exact state at the beginning of the handler, > + // before the call to RaiseTPL(): low TPL and interrupts disabled. > > but indeed it applies beyond interrupt handlers. It might even be a bugfix. Right. I'm leaning towards treating this as a bugfix: essentially tightening up the semantics of RestoreTPL() to mean: - any callbacks in the range OldTpl < Tpl < gEfiCurrentTpl will be dispatched with interrupts unconditionally enabled - the TPL will be restored to OldTpl - the interrupt state will be restored to the value it had when the TPL was last raised from OldTpl It feels as though this should be able to be cleanly modelled with a single global state array BOOLEAN mSavedInterruptState[TPL_HIGH_LEVEL] (or possibly a bitmask, though using the array avoids having to disable interrupts just to write a value). I still need to think through the subtleties, to make sure it could cope with pathological edge cases such as OldTpl = gBS->RaiseTPL (TPL_HIGH_LEVEL); ... gBS->RestoreTPL (OldTpl); gBS->RestoreTPL (OldTpl); or OldTpl = gBS->RaiseTPL (TPL_HIGH_LEVEL - 1); gBS->RaiseTPL (TPL_HIGH_LEVEL); .. gBS->RestoreTPL (OldTpl); I think that at least one of the above pathological usage patterns would break the existing mInterruptedTplMask patches, since they currently clear state in RestoreTPL() and so will not correctly handle a duplicate call to RestoreTPL(). I'll try to get a patch put together over the weekend. Thanks, Michael -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#116352): https://edk2.groups.io/g/devel/message/116352 Mute This Topic: https://groups.io/mt/104642317/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack overflow issue due to nested interrupts
Paolo, Happy weekends! Thanks! I will read it on my next Monday. Thanks, Ray > -Original Message- > From: Paolo Bonzini > Sent: Friday, March 1, 2024 4:44 PM > To: Ni, Ray > Cc: devel@edk2.groups.io; Kinney, Michael D ; > Liming Gao ; Laszlo Ersek ; > Michael Brown > Subject: Re: [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack overflow issue > due to nested interrupts > > One fix is needed in the code. > > On Thu, Feb 29, 2024 at 2:04 PM Ray Ni wrote: > > + // > > + // Save the "Interrupted TPL" (TPL that was interrupted). > > + // > > + mInterruptedTplMask |= (UINTN)(1 << gEfiCurrentTpl); > > +} > >} > > > + // > > + // Clear interrupted TPL level mask, but do not re-enable interrupts > here > > + // This will return to CoreTimerTick() and interrupts will be > re-enabled > > + // when the timer interrupt handlers returns from interrupt > context. > > + // > > + ASSERT ((INTN)gEfiCurrentTpl == HighBitSet64 > (mInterruptedTplMask)); > > + mInterruptedTplMask &= ~(UINTN)(1 << gEfiCurrentTpl); > > +} > >} > > Both of these need to use "1U" to avoid sign extending bit 31 into bits > 31..63. > > The same issue is (in three places) present in my own version of the patch. :( > > Paolo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#116226): https://edk2.groups.io/g/devel/message/116226 Mute This Topic: https://groups.io/mt/104642317/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v1 1/1] MdeModulePkg/AcpiTableDxe: Select ACPI memory type by PCD
Aaron,
Can you share more background of this change?
Thanks,
Ray
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Aaron Li
> Sent: Friday, March 1, 2024 2:04 PM
> To: devel@edk2.groups.io
> Cc: Liu, Zhiguang ; Bi, Dandan
> ; Liming Gao ; Liu, Yun Y
>
> Subject: [edk2-devel] [PATCH v1 1/1] MdeModulePkg/AcpiTableDxe: Select
> ACPI memory type by PCD
>
> UEFI spec defined ACPI Tables at boot time can be contained in memory of
> type EfiACPIReclaimMemory or EfiAcpiMemoryNVS, although InstallAcpiTable
> with AcpiTableProtocol will only allocate memory with type
> EfiACPIReclaimMemory (Except FACS).
>
> This patch provides an optional method controlled by PCD to switch all
> ACPI allocated memory from EfiACPIReclaimMemory to EfiAcpiMemoryNVS.
> If the PcdAcpiMemoryUseNvs is set to TRUE, all ACPI allocated memory
> will using EfiAcpiMemoryNVS.
>
> Cc: Zhiguang Liu
> Cc: Dandan Bi
> Cc: Liming Gao
> Cc: Liu Yun
> Signed-off-by: Aaron Li
> ---
> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c | 37
> +++-
> MdeModulePkg/MdeModulePkg.dec
> | 6
> MdeModulePkg/MdeModulePkg.uni
> | 7
> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf| 1 +
> 4 files changed, 43 insertions(+), 8 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
> b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
> index e09bc9b704f5..6c3dbad90345 100644
> --- a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
> +++ b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
> @@ -340,6 +340,7 @@ ReallocateAcpiTableBuffer (
>EFI_ACPI_TABLE_INSTANCE TempPrivateData;
>EFI_STATUS Status;
>UINT64 CurrentData;
> + EFI_MEMORY_TYPE AcpiAllocateMemoryType;
>
>CopyMem (, AcpiTableInstance, sizeof
> (EFI_ACPI_TABLE_INSTANCE));
>//
> @@ -359,6 +360,12 @@ ReallocateAcpiTableBuffer (
> NewMaxTableNumber * sizeof (UINT32);
>}
>
> + if (PcdGetBool (PcdAcpiMemoryUseNvs)) {
> +AcpiAllocateMemoryType = EfiACPIMemoryNVS;
> + } else {
> +AcpiAllocateMemoryType = EfiACPIReclaimMemory;
> + }
> +
>if (mAcpiTableAllocType != AllocateAnyPages) {
> //
> // Allocate memory in the lower 32 bit of address range for
> @@ -372,13 +379,13 @@ ReallocateAcpiTableBuffer (
> PageAddress = 0x;
> Status = gBS->AllocatePages (
> mAcpiTableAllocType,
> - EfiACPIReclaimMemory,
> + AcpiAllocateMemoryType,
> EFI_SIZE_TO_PAGES (TotalSize),
>
> );
>} else {
> Status = gBS->AllocatePool (
> -EfiACPIReclaimMemory,
> +AcpiAllocateMemoryType,
> TotalSize,
> (VOID **)
> );
> @@ -512,6 +519,7 @@ AddTableToList (
>EFI_PHYSICAL_ADDRESS AllocPhysAddress;
>UINT64Buffer64;
>BOOLEAN AddToRsdt;
> + EFI_MEMORY_TYPE AcpiAllocateMemoryType;
>
>//
>// Check for invalid input parameters
> @@ -550,6 +558,12 @@ AddTableToList (
>CurrentTableList->TableSize = CurrentTableSize;
>CurrentTableList->PoolAllocation = FALSE;
>
> + if (PcdGetBool (PcdAcpiMemoryUseNvs)) {
> +AcpiAllocateMemoryType = EfiACPIMemoryNVS;
> + } else {
> +AcpiAllocateMemoryType = EfiACPIReclaimMemory;
> + }
> +
>//
>// Allocation memory type depends on the type of the table
>//
> @@ -585,7 +599,7 @@ AddTableToList (
> // such as AArch64 that allocate multiples of 64 KB
> //
> Status = gBS->AllocatePool (
> -EfiACPIReclaimMemory,
> +AcpiAllocateMemoryType,
> CurrentTableList->TableSize,
> (VOID **)>Table
> );
> @@ -596,7 +610,7 @@ AddTableToList (
> //
> Status = gBS->AllocatePages (
> mAcpiTableAllocType,
> -EfiACPIReclaimMemory,
> +AcpiAllocateMemoryType,
> EFI_SIZE_TO_PAGES (CurrentTableList->TableSize),
>
> );
> @@ -1944,6 +1958,7 @@ AcpiTableAcpiTableConstructor (
>UINTN RsdpTableSize;
>UINT8 *Pointer;
>EFI_PHYSICAL_ADDRESS PageAddress;
> + EFI_MEMORY_TYPE AcpiAllocateMemoryType;
>
>//
>// Check for invalid input parameters
> @@ -1978,17 +1993,23 @@ AcpiTableAcpiTableConstructor (
> RsdpTableSize += sizeof
> (EFI_ACPI_1_0_ROOT_SYSTEM_DESCRIPTION_POINTER);
>}
>
> + if (PcdGetBool (PcdAcpiMemoryUseNvs)) {
> +AcpiAllocateMemoryType = EfiACPIMemoryNVS;
> + } else {
> +AcpiAllocateMemoryType = EfiACPIReclaimMemory;
> + }
> +
>if (mAcpiTableAllocType != AllocateAnyPages) {
Re: [edk2-devel] [PATCH v3 4/4] StandaloneMmPkg: Disallow unregister MMI handler in other MMI handler
Reviewed-by: Ray Ni
Thanks,
Ray
> -Original Message-
> From: Liu, Zhiguang
> Sent: Friday, March 1, 2024 11:02 AM
> To: devel@edk2.groups.io
> Cc: Liu, Zhiguang ; Liming Gao
> ; Wu, Jiaxin ; Ni, Ray
> ; Laszlo Ersek ; Ard Biesheuvel
> ; Sami Mujawar
> Subject: [PATCH v3 4/4] StandaloneMmPkg: Disallow unregister MMI handler
> in other MMI handler
>
> In last patch, we add code support to unregister MMI handler inside
> itself. However, the code doesn't support unregister MMI handler
> insider other MMI handler. While this is not a must-have usage.
> So add check to disallow unregister MMI handler in other MMI handler.
>
> Cc: Liming Gao
> Cc: Jiaxin Wu
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Cc: Ard Biesheuvel
> Cc: Sami Mujawar
> Cc: Ray Ni
> Signed-off-by: Zhiguang Liu
> ---
> StandaloneMmPkg/Core/Mmi.c | 32 +++-
> 1 file changed, 23 insertions(+), 9 deletions(-)
>
> diff --git a/StandaloneMmPkg/Core/Mmi.c b/StandaloneMmPkg/Core/Mmi.c
> index c1a1d76e85..9e52072bf7 100644
> --- a/StandaloneMmPkg/Core/Mmi.c
> +++ b/StandaloneMmPkg/Core/Mmi.c
> @@ -36,8 +36,9 @@ typedef struct {
>MMI_ENTRY *MmiEntry;
> } MMI_HANDLER;
>
> -LIST_ENTRY mRootMmiHandlerList = INITIALIZE_LIST_HEAD_VARIABLE
> (mRootMmiHandlerList);
> -LIST_ENTRY mMmiEntryList = INITIALIZE_LIST_HEAD_VARIABLE
> (mMmiEntryList);
> +LIST_ENTRY mRootMmiHandlerList = INITIALIZE_LIST_HEAD_VARIABLE
> (mRootMmiHandlerList);
> +LIST_ENTRY mMmiEntryList = INITIALIZE_LIST_HEAD_VARIABLE
> (mMmiEntryList);
> +MMI_HANDLER *mCurrentMmiHandler = NULL;
>
> /**
>Finds the MMI entry for the requested handler type.
> @@ -161,13 +162,19 @@ MmiManage (
> // get next node before handler is executed, since LIST_ENTRY that
> // Link points to may be freed if unregister MMI handler.
> //
> -Link = Link->ForwardLink;
> -Status = MmiHandler->Handler (
> - (EFI_HANDLE)MmiHandler,
> - Context,
> - CommBuffer,
> - CommBufferSize
> - );
> +Link = Link->ForwardLink;
> +//
> +// Assign gCurrentMmiHandle before calling the MMI handler and
> +// set to NULL when it returns.
> +//
> +mCurrentMmiHandler = MmiHandler;
> +Status = MmiHandler->Handler (
> + (EFI_HANDLE)MmiHandler,
> + Context,
> + CommBuffer,
> + CommBufferSize
> + );
> +mCurrentMmiHandler = NULL;
>
> switch (Status) {
>case EFI_INTERRUPT_PENDING:
> @@ -314,6 +321,13 @@ MmiHandlerUnRegister (
> return EFI_INVALID_PARAMETER;
>}
>
> + //
> + // Do not allow to unregister MMI Handler inside other MMI Handler
> + //
> + if ((mCurrentMmiHandler != NULL) && (mCurrentMmiHandler !=
> MmiHandler)) {
> +return EFI_INVALID_PARAMETER;
> + }
> +
>MmiEntry = MmiHandler->MmiEntry;
>
>RemoveEntryList (>Link);
> --
> 2.31.1.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116209): https://edk2.groups.io/g/devel/message/116209
Mute This Topic: https://groups.io/mt/104657669/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v3 2/4] MdeModulePkg/SMM: Disallow unregister SMI handler in other SMI handler
Reviewed-by: Ray Ni
Thanks,
Ray
> -Original Message-
> From: Liu, Zhiguang
> Sent: Friday, March 1, 2024 11:02 AM
> To: devel@edk2.groups.io
> Cc: Liu, Zhiguang ; Liming Gao
> ; Wu, Jiaxin ; Ni, Ray
> ; Laszlo Ersek
> Subject: [PATCH v3 2/4] MdeModulePkg/SMM: Disallow unregister SMI
> handler in other SMI handler
>
> In last patch, we add code support to unregister SMI handler inside
> itself. However, the code doesn't support unregister SMI handler
> insider other SMI handler. While this is not a must-have usage.
> So add check to disallow unregister SMI handler in other SMI handler.
>
> Cc: Liming Gao
> Cc: Jiaxin Wu
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Signed-off-by: Zhiguang Liu
> ---
> MdeModulePkg/Core/PiSmmCore/Smi.c | 29
> +
> 1 file changed, 21 insertions(+), 8 deletions(-)
>
> diff --git a/MdeModulePkg/Core/PiSmmCore/Smi.c
> b/MdeModulePkg/Core/PiSmmCore/Smi.c
> index 3489c130fd..b3a81ac877 100644
> --- a/MdeModulePkg/Core/PiSmmCore/Smi.c
> +++ b/MdeModulePkg/Core/PiSmmCore/Smi.c
> @@ -8,7 +8,8 @@
>
> #include "PiSmmCore.h"
>
> -LIST_ENTRY mSmiEntryList = INITIALIZE_LIST_HEAD_VARIABLE
> (mSmiEntryList);
> +SMI_HANDLER *mCurrentSmiHandler = NULL;
> +LIST_ENTRY mSmiEntryList = INITIALIZE_LIST_HEAD_VARIABLE
> (mSmiEntryList);
>
> SMI_ENTRY mRootSmiEntry = {
>SMI_ENTRY_SIGNATURE,
> @@ -142,13 +143,18 @@ SmiManage (
> // Link points to may be freed if unregister SMI handler.
> //
> Link = Link->ForwardLink;
> -
> -Status = SmiHandler->Handler (
> - (EFI_HANDLE)SmiHandler,
> - Context,
> - CommBuffer,
> - CommBufferSize
> - );
> +//
> +// Assign gCurrentSmiHandle before calling the SMI handler and
> +// set to NULL when it returns.
> +//
> +mCurrentSmiHandler = SmiHandler;
> +Status = SmiHandler->Handler (
> + (EFI_HANDLE)SmiHandler,
> + Context,
> + CommBuffer,
> + CommBufferSize
> + );
> +mCurrentSmiHandler = NULL;
>
> switch (Status) {
>case EFI_INTERRUPT_PENDING:
> @@ -328,6 +334,13 @@ SmiHandlerUnRegister (
> return EFI_INVALID_PARAMETER;
>}
>
> + //
> + // Do not allow to unregister SMI Handler inside other SMI Handler
> + //
> + if ((mCurrentSmiHandler != NULL) && (mCurrentSmiHandler !=
> SmiHandler)) {
> +return EFI_INVALID_PARAMETER;
> + }
> +
>SmiEntry = SmiHandler->SmiEntry;
>
>RemoveEntryList (>Link);
> --
> 2.31.1.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116208): https://edk2.groups.io/g/devel/message/116208
Mute This Topic: https://groups.io/mt/104657667/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack overflow issue due to nested interrupts
I think we are all aligned on the purpose. It's to avoid enabling the
interrupts in the end of RestoreTPL (HIGH->non-HIGH) in the interrupt context.
The discussion is about how to implement it.
Michael Brown's idea is to avoid changing DxeCore but add a customized
RaiseTpl/RestoreTpl implementation in a lib and request Timer driver calls it.
That lib was implemented very smartly. It includes while-loop,
implicitly-recursive, implicitly-requiring NESTED_INTERRUPT_STATE in global
storage not in stack as local variable.
I really do NOT like the future that every timer driver calls that lib to avoid
the potential stack overflow. It's so complicated! And it's called in every
10ms!!
Paolo,
I don't fully understand your patch especially the following changes.
3 comments embedded.
@@ -161,5 +191,46 @@ CoreRestoreTpl (
IN EFI_TPL NewTpl
)
{
+ BOOLEAN InInterruptHandler = FALSE;
+
+ //
+ // Unwind the nested interrupt handlers up to the required
+ // TPL, paying attention not to overflow the stack. While
+ // not strictly necessary according to the specification,
+ // accept the possibility that multiple RaiseTPL calls are
+ // undone by a single RestoreTPL
+ //
+ while ((INTN)NewTpl <= HighBitSet64 (mInterruptedTplMask)) {
1. why "<="? I thought when RestoreTPL() is called there are only two cases:
a. NewTpl == HighBitSet64 (...)
b. NewTpl > HighBitSet64 (...)
1.a is the case when TimerInterruptHandler() or CoreTimerTick() restores
TPL from HIGH to non-HIGH.
1.b is the case when the pending event backs call RaiseTPL/RestoreTPL().
Because only pending events whose TPL > "Interrupted TPL" can run, the
RestoreTPL() call from the event callbacks cannot change the TPL to a value
less than or equal to "Interrupted TPL".
So, I think "<=" can be "==".
2. can you explain a bit more about the reason of "while"?
+UINTN InterruptedTpl = HighBitSet64 (mInterruptedTplMask);
+mInterruptedTplMask &= ~(UINTN)(1 << InterruptedTpl);
+
+ASSERT (GetInterruptState () == FALSE);
+InInterruptHandler = TRUE;
+
+//
+// Take the TPL down a notch to allow event notifications to be
+// dispatched. This will implicitly re-enable interrupts (if
+// InterruptedTPL is below TPL_HIGH_LEVEL), even though we are
+// still inside the interrupt handler, but the new TPL will
+// be set while they are disabled.
+//
+// DesiredInterruptState must be FALSE to ensure that the
+// stack does not blow up. If we used, as in the final call
+// below, "InterruptedTpl < TPL_HIGH_LEVEL", the timer interrupt
+// handler could be invoked repeatedly in the small window between
+// CoreSetInterruptState (TRUE) and the IRET instruction.
+//
+CoreRestoreTplInternal (InterruptedTpl, FALSE);
+
+if (InterruptedTpl == NewTpl) {
+ break;
3. "break" or "return"? I think we should exit from this function.
+}
+ }
+
+ //
+ // If we get here with InInterruptHandler == TRUE, an interrupt
+ // handler forgot to restore the TPL.
+ //
+ ASSERT (!InInterruptHandler);
CoreRestoreTplInternal (NewTpl, NewTpl < TPL_HIGH_LEVEL);
}
Thanks,
Ray
> -Original Message-
> From: Paolo Bonzini
> Sent: Friday, March 1, 2024 8:14 AM
> To: Ni, Ray
> Cc: devel@edk2.groups.io; Kinney, Michael D ;
> Liming Gao ; Laszlo Ersek ;
> Michael Brown
> Subject: Re: [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack overflow issue
> due to nested interrupts
>
> On Thu, Feb 29, 2024 at 2:04 PM Ray Ni wrote:
> > @@ -134,9 +262,9 @@ CoreRestoreTpl (
> >}
> >
> >//
> > - // Set the new value
> > + // Set the new TPL with interrupt disabled.
> >//
> > -
> > + CoreSetInterruptState (FALSE);
> >gEfiCurrentTpl = NewTpl;
> >
> >//
> > @@ -144,7 +272,22 @@ CoreRestoreTpl (
> >// interrupts are enabled
> >//
> >if (gEfiCurrentTpl < TPL_HIGH_LEVEL) {
> > -CoreSetInterruptState (TRUE);
> > +if ((INTN)gEfiCurrentTpl > HighBitSet64 (mInterruptedTplMask)) {
> > + //
> > + // Only enable interrupts if restoring to a level above the highest
> > + // interrupted TPL level. This allows interrupt nesting, but only
> > for
> > + // events at higher TPL level than the current TPL level.
> > + //
> > + CoreSetInterruptState (TRUE);
> > +} else {
> > + //
> > + // Clear interrupted TPL level mask, but do not re-enable interrupts
> here
> > + // This will return to CoreTimerTick() and interrupts will be
> re-enabled
> > + // when the timer interrupt handlers returns from interrupt
> context.
> > + //
> > + ASSERT
[edk2-devel] [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack overflow issue due to nested interrupts
Assuming the current TPL is TPL_APPLICATION, RaiseTPL (TPL_APPLICATION -> HIGH) and RestoreTPL (TPL_HIGH -> TPL_APPLICATION) are called in the timer interrupt context. RestoreTPL() will lower the TPL from TPL_HIGH to TPL_NOTIFY first, enable the interrupts and dispatch pending events associated with TPL_NOTIFY. Then it will lower TPL to TPL_CALLBACK, enable the interrupts and dispatch pending events associated with TPL_CALLBACK. In the end, it will lower the TPL to TPL_APPLICATION with interrupt enabled. However, it's possible that another timer interrupt happens just in the end of RestoreTPL() function when TPL is TPL_APPLICATION. CPU runs into the interrupt context but the contents pushed to the stack in the outer interrupt context haven't been fully popped. In the nested interrupt context, if 3rd interrupt happens just in the end of RestoreTPL() function, CPU runs to interrupt context again but the contents pushed to the stack in the 2nd interrupt context haven't been fully popped. The situation can repeat infinitely that could result in stack overflow. A ideal solution is to not keep the interrupt disabled when RestoreTPL(TPL_HIGH -> not TPL_HIGH) is executed in the timer interrupt context because the interrupt handler will re-enable the interrupt with arch specific instructions (e.g.: IRET for x86). The patch introduces mInterruptedTplMask which tells RestoreTPL() if it's called in the interrupt context and whether it should defer enabling the interrupt. Signed-off-by: Michael D Kinney Signed-off-by: Ray Ni Cc: Liming Gao Cc: Laszlo Ersek Cc: Michael Brown Cc: Paolo Bonzini --- MdeModulePkg/Core/Dxe/Event/Tpl.c | 151 +- 1 file changed, 147 insertions(+), 4 deletions(-) diff --git a/MdeModulePkg/Core/Dxe/Event/Tpl.c b/MdeModulePkg/Core/Dxe/Event/Tpl.c index 8ce456f968..f2206bc788 100644 --- a/MdeModulePkg/Core/Dxe/Event/Tpl.c +++ b/MdeModulePkg/Core/Dxe/Event/Tpl.c @@ -9,6 +9,100 @@ SPDX-License-Identifier: BSD-2-Clause-Patent #include "DxeMain.h" #include "Event.h" +// +// It's used to support nested interrupts. +// The bit position is the TPL that was interrupted. +// The bit is set when the TPL is interrupted. +// +// Example 1): +// Assume system runs at TPL_APPLICATION (4) and there is no pending event. +// +// Timer interrupt happens. CPU runs to the interrupt context. +// 1. Interrupt context (Interrupted TPL = TPL_APPLICATION): +// CoreRaiseTpl(TPL_APPLICATION -> TPL_HIGH) is called where +// mInterruptedTplMask is changed from 0 to 0x10. +// +// Note: CoreRaiseTpl(TPL_HIGH) could be called from Timer driver, or CoreTimerTick(). +// If it's called from both, the 2nd call in CoreTimerTick() will not change mInterruptedTplMask +// as it's a TPL raise from TPL_HIGH to TPL_HIGH. +// +// When CoreRestoreTpl(TPL_HIGH -> TPL_APPLICATION) is called, because there is no pending event it will +// lower TPL to TPL_APPLICATION, but with interrupts disabled as the TPL_APPLICATION bit is set in +// mInterruptedTplMask. +// mInterruptedTplMask is changed from 0x10 to 0. +// +// Example 2): +// Assume system runs at TPL_APPLICATION (4) and there is only one event at TPL_CALLBACK (8) which will +// register another event at TPL_NOTIFY (16). +// +// Timer interrupt happens. CPU runs to the (outer) interrupt context. +// 1. Outer interrupt context (Interrupted TPL = TPL_APPLICATION): +// CoreRaiseTpl(TPL_APPLICATION -> TPL_HIGH) is called where +// mInterruptedTplMask is changed from 0 to 0x10. +// +// When CoreRestoreTpl(TPL_HIGH -> TPL_APPLICATION) is called, because there is one event at +// TPL_CALLBACK (8) it will lower TPL to TPL_CALLBACK, enable the interrupts and dispatch it. +// +// The event registers another event associating with TPL_NOTIFY. +// +// 2nd timer interrupt happens. CPU runs to the inner-1/nested-1 interrupt context. +// +// 2. Inner-1/nested-1 interrupt context (Interrupted TPL = TPL_CALLBACK): +// CoreRaiseTpl(TPL_CALLBACK -> TPL_HIGH) is called where +// mInterruptedTplMask is changed from 0x10 to 0x110. +// +// When CoreRestoreTpl(TPL_HIGH -> TPL_CALLBACK) is called, because there is one event at +// TPL_NOTIFY (16) it will lower TPL to TPL_NOTIFY, enable the interrupts and dispatch it. +// +// 3rd timer interrupt happens. CPU runs to the inner-2/nested-2 interrupt context. +// +// 3. Inner-2/nested-2 interrupt context (Interrupt TPL = TPL_NOTIFY): +// CoreRaiseTpl(TPL_NOTIFY -> TPL_HIGH) is called where +// mInterruptedTplMask is changed from 0x110 to 0x10110. +// +// CoreTimerTick() signals mEfiCheckTimerEvent which queues a event at TPL_HIGH - 1. +// +// When CoreRestoreTpl(TPL_HIGH -> TPL_NOTIFY) is called, because there is one event at +// TPL_HIGH - 1 (30) it will lower TPL to TPL_HIGH - 1, enable the interrupts and dispatch it. +// +// 4th timer
[edk2-devel] [PATCH 0/2] Fix stack overflow issue due to nested interrupts
Ray Ni (2): UefiCpuPkg/CpuDxe: Return correct interrupt state MdeModulePkg/DxeCore: Fix stack overflow issue due to nested interrupts MdeModulePkg/Core/Dxe/Event/Tpl.c | 151 +- UefiCpuPkg/CpuDxe/CpuDxe.c| 10 +- 2 files changed, 150 insertions(+), 11 deletions(-) -- 2.39.1.windows.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#116165): https://edk2.groups.io/g/devel/message/116165 Mute This Topic: https://groups.io/mt/104642315/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH 1/2] UefiCpuPkg/CpuDxe: Return correct interrupt state
CpuDxe driver uses a global C variable to record the interrupt state.
The state variable is updated every time CpuArch.EnableInterrupt() or
CpuArch.DisableInterrupt() is called.
CpuArch.GetInterruptState() simply returns the state variable.
But when CpuArch.GetInterruptState() is called in the interrupt
context, even the interrupt state is enabled before interrupt
happens, because the interrupt is not disabled through
CpuArch.DisableInterrupts(), CpuArch.GetInterruptState() still
returns that the interrupt state is enabled.
It's not correct.
The commit removes the C global variable and always reads the
interrupt state from CPU register.
Signed-off-by: Ray Ni
Cc: Laszlo Ersek
Cc: Rahul Kumar
Cc: Gerd Hoffmann
---
UefiCpuPkg/CpuDxe/CpuDxe.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c b/UefiCpuPkg/CpuDxe/CpuDxe.c
index bf03978710..0349c761ff 100644
--- a/UefiCpuPkg/CpuDxe/CpuDxe.c
+++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
@@ -15,8 +15,7 @@
//
// Global Variables
//
-BOOLEAN InterruptState = FALSE;
-EFI_HANDLE mCpuHandle = NULL;
+EFI_HANDLE mCpuHandle = NULL;
BOOLEAN mIsFlushingGCD;
BOOLEAN mIsAllocatingPageTable = FALSE;
UINT64 mTimerPeriod = 0;
@@ -89,8 +88,6 @@ CpuEnableInterrupt (
)
{
EnableInterrupts ();
-
- InterruptState = TRUE;
return EFI_SUCCESS;
}
@@ -110,8 +107,6 @@ CpuDisableInterrupt (
)
{
DisableInterrupts ();
-
- InterruptState = FALSE;
return EFI_SUCCESS;
}
@@ -136,7 +131,8 @@ CpuGetInterruptState (
return EFI_INVALID_PARAMETER;
}
- *State = InterruptState;
+ *State = GetInterruptState ();
+
return EFI_SUCCESS;
}
--
2.39.1.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116166): https://edk2.groups.io/g/devel/message/116166
Mute This Topic: https://groups.io/mt/104642316/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 1/4] MdeModulePkg/SMM: Support to unregister SMI handler inside SMI handler
Reviewed-by: Ray Ni
Thanks,
Ray
> -Original Message-
> From: Liu, Zhiguang
> Sent: Wednesday, February 28, 2024 10:28 AM
> To: devel@edk2.groups.io
> Cc: Liu, Zhiguang ; Liming Gao
> ; Wu, Jiaxin ; Ni, Ray
> ; Laszlo Ersek
> Subject: [PATCH v2 1/4] MdeModulePkg/SMM: Support to unregister SMI
> handler inside SMI handler
>
> To support unregister SMI handler inside SMI handler itself,
> get next node before SMI handler is executed, since LIST_ENTRY that
> Link points to may be freed if unregister SMI handler in SMI handler
> itself.
>
> Cc: Liming Gao
> Cc: Jiaxin Wu
> Reviewed-by: Ray Ni
> Reviewed-by: Laszlo Ersek
> Signed-off-by: Zhiguang Liu
> ---
> MdeModulePkg/Core/PiSmmCore/Smi.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/MdeModulePkg/Core/PiSmmCore/Smi.c
> b/MdeModulePkg/Core/PiSmmCore/Smi.c
> index 2985f989c3..3489c130fd 100644
> --- a/MdeModulePkg/Core/PiSmmCore/Smi.c
> +++ b/MdeModulePkg/Core/PiSmmCore/Smi.c
> @@ -134,8 +134,14 @@ SmiManage (
>
>Head = >SmiHandlers;
>
> - for (Link = Head->ForwardLink; Link != Head; Link = Link->ForwardLink) {
> + for (Link = Head->ForwardLink; Link != Head;) {
> SmiHandler = CR (Link, SMI_HANDLER, Link, SMI_HANDLER_SIGNATURE);
> +//
> +// To support unregister SMI handler inside SMI handler itself,
> +// get next node before handler is executed, since LIST_ENTRY that
> +// Link points to may be freed if unregister SMI handler.
> +//
> +Link = Link->ForwardLink;
>
> Status = SmiHandler->Handler (
> (EFI_HANDLE)SmiHandler,
> --
> 2.31.1.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116164): https://edk2.groups.io/g/devel/message/116164
Mute This Topic: https://groups.io/mt/104616992/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 3/4] StandaloneMmPkg: Support to unregister MMI handler inside MMI handler
Reviewed-by: Ray Ni
Thanks,
Ray
> -Original Message-
> From: Laszlo Ersek
> Sent: Wednesday, February 28, 2024 4:47 PM
> To: devel@edk2.groups.io; Liu, Zhiguang
> Cc: Liming Gao ; Wu, Jiaxin
> ; Ni, Ray ; Ard Biesheuvel
> ; Sami Mujawar
> Subject: Re: [edk2-devel] [PATCH v2 3/4] StandaloneMmPkg: Support to
> unregister MMI handler inside MMI handler
>
> On 2/28/24 03:27, Zhiguang Liu wrote:
> > To support unregister MMI handler inside MMI handler itself,
> > get next node before MMI handler is executed, since LIST_ENTRY that
> > Link points to may be freed if unregister MMI handler in MMI handler
> > itself.
> >
> > Cc: Liming Gao
> > Cc: Jiaxin Wu
> > Cc: Ray Ni
> > Cc: Laszlo Ersek
> > Cc: Ard Biesheuvel
> > Cc: Sami Mujawar
> > Signed-off-by: Zhiguang Liu
> > ---
> > StandaloneMmPkg/Core/Mmi.c | 9 +++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/StandaloneMmPkg/Core/Mmi.c
> b/StandaloneMmPkg/Core/Mmi.c
> > index 0de6fd17fc..c1a1d76e85 100644
> > --- a/StandaloneMmPkg/Core/Mmi.c
> > +++ b/StandaloneMmPkg/Core/Mmi.c
> > @@ -154,9 +154,14 @@ MmiManage (
> > Head = >MmiHandlers;
> >}
> >
> > - for (Link = Head->ForwardLink; Link != Head; Link = Link->ForwardLink) {
> > + for (Link = Head->ForwardLink; Link != Head;) {
> > MmiHandler = CR (Link, MMI_HANDLER, Link,
> MMI_HANDLER_SIGNATURE);
> > -
> > +//
> > +// To support unregister MMI handler inside MMI handler itself,
> > +// get next node before handler is executed, since LIST_ENTRY that
> > +// Link points to may be freed if unregister MMI handler.
> > +//
> > +Link = Link->ForwardLink;
> > Status = MmiHandler->Handler (
> > (EFI_HANDLE)MmiHandler,
> > Context,
>
> Reviewed-by: Laszlo Ersek
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116163): https://edk2.groups.io/g/devel/message/116163
Mute This Topic: https://groups.io/mt/104616994/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v3 0/6] UefiCpuPkg/MpInitLib: Add support for multiple MP_HAND_OFF HOBs
Thank you, Laszlo!
The changes you made look good to me.
By the way, is the following a common way to call out additional changes?
> +[ler...@redhat.com: define one local variable per line [Ray]]
Thanks,
Ray
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Laszlo
> Ersek
> Sent: Monday, February 26, 2024 11:20 PM
> To: devel@edk2.groups.io; kra...@redhat.com
> Cc: Ni, Ray ; Kumar, Rahul R ;
> Oliver Steffen
> Subject: Re: [edk2-devel] [PATCH v3 0/6] UefiCpuPkg/MpInitLib: Add support
> for multiple MP_HAND_OFF HOBs
>
> On 2/22/24 17:01, Gerd Hoffmann wrote:
> > Needed to boot guests with thousands of vcpus.
> >
> > v3:
> > - refine comments and commit messages.
> > - fix MaxCpusPerHob calculation.
> > - pick up review tags.
> > - add patch to speed up GetBspNumber a bit.
> > v2:
> > - rework HOB loops for better performance: O(n) instead of O(n^2).
> >
> > Gerd Hoffmann (6):
> > UefiCpuPkg/MpInitLib: Add support for multiple HOBs to
> GetMpHandOffHob
> > UefiCpuPkg/MpInitLib: Add support for multiple HOBs to
> GetBspNumber()
> > UefiCpuPkg/MpInitLib: Add support for multiple HOBs to
> > SwitchApContext()
> > UefiCpuPkg/MpInitLib: Add support for multiple HOBs to
> > MpInitLibInitialize
> > UefiCpuPkg/MpInitLib: Add support for multiple HOBs to
> SaveCpuMpData()
> > UefiCpuPkg/MpInitLib: return early in GetBspNumber()
> >
> > UefiCpuPkg/Library/MpInitLib/MpLib.h| 14 ++-
> > UefiCpuPkg/Library/MpInitLib/MpLib.c| 157
> +++-
> > UefiCpuPkg/Library/MpInitLib/PeiMpLib.c | 44 ---
> > 3 files changed, 142 insertions(+), 73 deletions(-)
> >
>
> BTW, differences in PR#5410 relative to v3 as posted:
>
> 1: 678ed78d24a3 ! 1: ecd6c4bb3396 UefiCpuPkg/MpInitLib: Add support
> for multiple HOBs to GetMpHandOffHob
> @@ Commit message
>
> Signed-off-by: Gerd Hoffmann
> Message-Id: <20240222160106.686484-2-kra...@redhat.com>
> +Reviewed-by: Ray Ni
> +Reviewed-by: Laszlo Ersek
>
> ## UefiCpuPkg/Library/MpInitLib/MpLib.h ##
> @@ UefiCpuPkg/Library/MpInitLib/MpLib.h: SwitchApContext (
> 2: 23b3e66f9935 = 2: 189467980103 UefiCpuPkg/MpInitLib: Add support
> for multiple HOBs to GetBspNumber()
> 3: e712d36775d0 = 3: 8ab0f63c0f04 UefiCpuPkg/MpInitLib: Add support
> for multiple HOBs to SwitchApContext()
> 4: 9a81417f4b76 ! 4: 995a8ace7801 UefiCpuPkg/MpInitLib: Add support
> for multiple HOBs to MpInitLibInitialize
> @@ Commit message
> Signed-off-by: Gerd Hoffmann
> Reviewed-by: Ray Ni
> Message-Id: <20240222160106.686484-5-kra...@redhat.com>
> +Reviewed-by: Laszlo Ersek
>
> ## UefiCpuPkg/Library/MpInitLib/MpLib.c ##
> @@ UefiCpuPkg/Library/MpInitLib/MpLib.c: MpInitLibInitialize (
> 5: 3a089b25725e ! 5: f23c0d125e48 UefiCpuPkg/MpInitLib: Add support
> for multiple HOBs to SaveCpuMpData()
> @@ Commit message
>
> Signed-off-by: Gerd Hoffmann
> Message-Id: <20240222160106.686484-6-kra...@redhat.com>
> +Reviewed-by: Ray Ni
> +Reviewed-by: Laszlo Ersek
> +[ler...@redhat.com: define one local variable per line [Ray]]
>
> ## UefiCpuPkg/Library/MpInitLib/PeiMpLib.c ##
> @@ UefiCpuPkg/Library/MpInitLib/PeiMpLib.c: SaveCpuMpData (
> IN CPU_MP_DATA *CpuMpData
> )
> {
> -+ UINT32 MaxCpusPerHob, CpusInHob;
> ++ UINT32 MaxCpusPerHob;
> ++ UINT32 CpusInHob;
> UINT64 Data64;
> - UINTNIndex;
> -+ UINT32 Index, HobBase;
> ++ UINT32 Index;
> ++ UINT32 HobBase;
> CPU_INFO_IN_HOB *CpuInfoInHob;
> MP_HAND_OFF *MpHandOff;
> UINTNMpHandOffSize;
> 6: 09435495e6e1 ! 6: fbd8a114cd6e UefiCpuPkg/MpInitLib: return early
> in GetBspNumber()
> @@ Commit message
> Suggested-by: Laszlo Ersek
> Signed-off-by: Gerd Hoffmann
> Message-Id: <20240222160106.686484-7-kra...@redhat.com>
> +Reviewed-by: Ray Ni
> +Reviewed-by: Laszlo Ersek
> +[ler...@redhat.com: s/ASSERT (FALSE)/ASSERT_EFI_ERROR
> (EFI_NOT_FOUND)/ [Ray]]
>
> ## UefiCpuPkg/Library/MpInitLib/MpLib.c ##
> @@ UefiCpuPkg/Library/MpInitLib/MpLib.c: GetBspNumber (
> @@ UefiCpuPkg/Library/MpInitLib/MpLib.c: GetBspNumber (
> - ASSERT (BspNumber != MAX_UINT32);
> -
> - return BspNumber;
> -+ ASSERT (FALSE);
> ++ ASSERT_EFI_ERROR (EFI_NOT_FOUND);
> + return 0;
> }
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116002): https://edk2.groups.io/g/devel/message/116002
Mute This Topic: https://groups.io/mt/104510905/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v3 1/6] UefiCpuPkg/MpInitLib: Add support for multiple HOBs to GetMpHandOffHob
> + @param[in] MpHandOff Previous HOB body. Pass NULL to get the > first HOB. Can you replace "...HOB Body. Pass NULL..." with "...HOB Body. Pass NULL..."? Your current comments contain two spaces. With that, Reviewed-by: Ray Ni -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#115865): https://edk2.groups.io/g/devel/message/115865 Mute This Topic: https://groups.io/mt/104510907/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v3 6/6] UefiCpuPkg/MpInitLib: return early in GetBspNumber()
> + ASSERT (FALSE); How about ASSERT (EFI_NOT_FOUND)? Which is more meaningful than FALSE. No matter you change or not, Reviewed-by: Ray Ni > + return 0; > } > > /** > -- > 2.43.2 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#115864): https://edk2.groups.io/g/devel/message/115864 Mute This Topic: https://groups.io/mt/104510913/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v3 5/6] UefiCpuPkg/MpInitLib: Add support for multiple HOBs to SaveCpuMpData()
Thanks,
Ray
> -Original Message-
> From: Gerd Hoffmann
> Sent: Friday, February 23, 2024 12:01 AM
> To: devel@edk2.groups.io
> Cc: Laszlo Ersek ; Ni, Ray ; Kumar,
> Rahul R ; Oliver Steffen ;
> Gerd Hoffmann
> Subject: [PATCH v3 5/6] UefiCpuPkg/MpInitLib: Add support for multiple
> HOBs to SaveCpuMpData()
>
> Add support for splitting Hand-Off data into multiple HOBs.
> This is required for VMs with thousands of CPUs.
>
> Signed-off-by: Gerd Hoffmann
> ---
> UefiCpuPkg/Library/MpInitLib/PeiMpLib.c | 44 +++--
> 1 file changed, 27 insertions(+), 17 deletions(-)
>
> diff --git a/UefiCpuPkg/Library/MpInitLib/PeiMpLib.c
> b/UefiCpuPkg/Library/MpInitLib/PeiMpLib.c
> index f80e00edcff3..00d48c2ab531 100644
> --- a/UefiCpuPkg/Library/MpInitLib/PeiMpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/PeiMpLib.c
> @@ -126,35 +126,45 @@ SaveCpuMpData (
>IN CPU_MP_DATA *CpuMpData
>)
> {
> + UINT32 MaxCpusPerHob, CpusInHob;
>UINT64 Data64;
> - UINTNIndex;
> + UINT32 Index, HobBase;
Can you please split the local variable declarations in multiple lines?
With that, Reviewed-by: Ray Ni
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115863): https://edk2.groups.io/g/devel/message/115863
Mute This Topic: https://groups.io/mt/104510911/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 4/5] UefiCpuPkg/MpInitLib: Add support for multiple HOBs to MpInitLibInitialize
I prefer HOB instead of dynamic PCD. And let's keep the new singleton HOB structure as an internal interface between PEI MpInitLib and DXE MpInitLib. Thanks, Ray > -Original Message- > From: Gerd Hoffmann > Sent: Thursday, February 22, 2024 8:29 PM > To: Laszlo Ersek > Cc: devel@edk2.groups.io; Oliver Steffen ; Kumar, > Rahul R ; Ni, Ray > Subject: Re: [edk2-devel] [PATCH v2 4/5] UefiCpuPkg/MpInitLib: Add support > for multiple HOBs to MpInitLibInitialize > > Hi, > > > The code looks otherwise OK, but I'm not happy that > > WaitLoopExecutionMode (and StartupSignalValue) are replicated over all > > the HOBs, just like in v1. IMO, that will only make it harder for others > > to understand the code / data structures, and therefore it increases > > technical debt. > > > > I understand that Ray is OK with that, so I won't try to block the > > patch, but I'm not comfortable giving it an R-b myself, due to the > > increase in technical debt. > > I can try to address that, but this certainly will be a separate > patch. > > Given that the HOB structure is defined in locally in the library > I assume this is considered private and there are no compatibility > concerns when changing the structs? > > Any preference where the fields should be moved to? PCD? Separate > HOB? Something else? > > take care, > Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#115861): https://edk2.groups.io/g/devel/message/115861 Mute This Topic: https://groups.io/mt/104472311/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 02/23] MdePkg: GHCB APIC ID retrieval support definitions
> +//
> +// Get APIC IDs
> +//
> +#define EFI_APIC_IDS_GUID \
> + { 0xbc964338, 0xee39, 0x4fc8, { 0xa2, 0x24, 0x10, 0x10, 0x8b, 0x17, 0x80,
> 0x1b }}
> +extern EFI_GUID gEfiApicIdsGuid;
Since the above GUID is associated with the structure below, how about
rename the GUID from "gEfiApicIdsGuid" which is very general to a specific
name "gGhcbApicIdsGuid"?
+ @Yao, Jiewen, @Xu, Min M for comments.
> +
> +typedef struct {
> + UINT32NumEntries;
> + UINT32ApicIds[];
> +} GHCB_APIC_IDS;
> +
> //
> // SEV-ES save area mapping structures used for SEV-SNP AP Creation.
> // Only the fields required to be set to a non-zero value are defined.
> --
> 2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115860): https://edk2.groups.io/g/devel/message/115860
Mute This Topic: https://groups.io/mt/104512930/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 2/5] UefiCpuPkg/MpInitLib: Add support for multiple HOBs to GetBspNumber()
> > + @param[in] FirstMpHandOff Pointer to first MpHandOff HOB. > > ... also, it would be more precise to say "first MpHandOff HOB body". > "body" is a very good term that emphasizes it doesn't point to a separate storage. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#115796): https://edk2.groups.io/g/devel/message/115796 Mute This Topic: https://groups.io/mt/104472310/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] UefiCpuPkg: add volatile qualifier to page table related variable
> > I agree with the idea (I think it's a necessary change, or put
> > differently, an improvement, even though I may not be convinced that it
> > is a *sufficient* improvement; but let's not rehash all that here
> > again); however, I think the implementation is not the greatest.
> >
> > Volatile-qualifying the local variables does not seem useful for
> > anything. It's fine -- actually: it's beneficial -- if the compiler
> > optimizes accesses to those locals -- being on the stack -- as heavily
> > as it can. In other words, those parts of the patch look like a small
> > performance regression.
I did experiment using MSVC compiler with below code:
int main () {
int x;
x = 3;
return 0;
}
If building the above code in optimized mode, the disassembly does not contain
any reference to local variable x.
But if I changed "int x" to "volatile int x", the compiler does not optimize
out the
assignment of x.
So, it means the "volatile" matters even when it applies local variables.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115795): https://edk2.groups.io/g/devel/message/115795
Mute This Topic: https://groups.io/mt/104483610/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 3/5] UefiCpuPkg/MpInitLib: Add support for multiple HOBs to SwitchApContext()
Reviewed-by: Ray Ni
Thanks,
Ray
> -Original Message-
> From: Gerd Hoffmann
> Sent: Wednesday, February 21, 2024 1:50 AM
> To: devel@edk2.groups.io
> Cc: Oliver Steffen ; Laszlo Ersek
> ; Kumar, Rahul R ; Ni, Ray
> ; Gerd Hoffmann
> Subject: [PATCH v2 3/5] UefiCpuPkg/MpInitLib: Add support for multiple
> HOBs to SwitchApContext()
>
> Rename the MpHandOff parameter to FirstMpHandOff. Add loops so the
> function inspects all HOBs present in the system.
>
> Signed-off-by: Gerd Hoffmann
> ---
> UefiCpuPkg/Library/MpInitLib/MpLib.h | 2 +-
> UefiCpuPkg/Library/MpInitLib/MpLib.c | 35 ++--
> 2 files changed, 24 insertions(+), 13 deletions(-)
>
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.h
> b/UefiCpuPkg/Library/MpInitLib/MpLib.h
> index bc2a0232291d..b5214b904b41 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.h
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.h
> @@ -482,7 +482,7 @@ GetWakeupBuffer (
> **/
> VOID
> SwitchApContext (
> - IN MP_HAND_OFF *MpHandOff
> + IN CONST MP_HAND_OFF *FirstMpHandOff
>);
>
> /**
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> index 8f198ff6d817..c13de34e5769 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> @@ -1938,31 +1938,42 @@ GetBspNumber (
>This procedure allows the AP to switch to another section of
>memory and continue its loop there.
>
> - @param[in] MpHandOff Pointer to MP hand-off data structure.
> + @param[in] FirstMpHandOff Pointer to first MP hand-off HOB.
> **/
> VOID
> SwitchApContext (
> - IN MP_HAND_OFF *MpHandOff
> + IN CONST MP_HAND_OFF *FirstMpHandOff
>)
> {
> - UINTN Index;
> - UINT32 BspNumber;
> + UINTN Index;
> + UINT32 BspNumber;
> + CONST MP_HAND_OFF *MpHandOff;
>
> - BspNumber = GetBspNumber (MpHandOff);
> + BspNumber = GetBspNumber (FirstMpHandOff);
>
> - for (Index = 0; Index < MpHandOff->CpuCount; Index++) {
> -if (Index != BspNumber) {
> - *(UINTN
> *)(UINTN)MpHandOff->Info[Index].StartupProcedureAddress =
> (UINTN)SwitchContextPerAp;
> - *(UINT32 *)(UINTN)MpHandOff->Info[Index].StartupSignalAddress
> = MpHandOff->StartupSignalValue;
> + for (MpHandOff = FirstMpHandOff;
> + MpHandOff != NULL;
> + MpHandOff = GetNextMpHandOffHob (MpHandOff))
> + {
> +for (Index = 0; Index < MpHandOff->CpuCount; Index++) {
> + if (MpHandOff->ProcessorIndex + Index != BspNumber) {
> +*(UINTN
> *)(UINTN)MpHandOff->Info[Index].StartupProcedureAddress =
> (UINTN)SwitchContextPerAp;
> +*(UINT32
> *)(UINTN)MpHandOff->Info[Index].StartupSignalAddress =
> MpHandOff->StartupSignalValue;
> + }
> }
>}
>
>//
>// Wait all APs waken up if this is not the 1st broadcast of SIPI
>//
> - for (Index = 0; Index < MpHandOff->CpuCount; Index++) {
> -if (Index != BspNumber) {
> - WaitApWakeup ((UINT32
> *)(UINTN)(MpHandOff->Info[Index].StartupSignalAddress));
> + for (MpHandOff = FirstMpHandOff;
> + MpHandOff != NULL;
> + MpHandOff = GetNextMpHandOffHob (MpHandOff))
> + {
> +for (Index = 0; Index < MpHandOff->CpuCount; Index++) {
> + if (MpHandOff->ProcessorIndex + Index != BspNumber) {
> +WaitApWakeup ((UINT32
> *)(UINTN)(MpHandOff->Info[Index].StartupSignalAddress));
> + }
> }
>}
> }
> --
> 2.43.2
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115713): https://edk2.groups.io/g/devel/message/115713
Mute This Topic: https://groups.io/mt/104472306/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] UefiCpuPkg: add volatile qualifier to page table related variable
Reviewed-by: Ray Ni
Thanks,
Ray
> -Original Message-
> From: Zhou, Jianfeng
> Sent: Wednesday, February 21, 2024 9:25 AM
> To: devel@edk2.groups.io
> Cc: Zhou, Jianfeng ; Ni, Ray ;
> Laszlo Ersek ; Kumar, Rahul R
> ; Gerd Hoffmann
> Subject: [PATCH] UefiCpuPkg: add volatile qualifier to page table related
> variable
>
> Add volatile qualifier to page table related variable to prevent
> compiler from optimizing away the variables which may lead to
> unexpected result.
>
> Signed-off-by: Zhou Jianfeng
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Cc: Rahul Kumar
> Cc: Gerd Hoffmann
> ---
> UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c | 12
> ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> b/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> index 2ea40666cc..5cf6e8fea0 100644
> --- a/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> +++ b/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> @@ -26,7 +26,7 @@ PageTableLibSetPte4K (
>IN IA32_MAP_ATTRIBUTE *Mask
>
>)
>
> {
>
> - IA32_PTE_4K LocalPte4K;
>
> + volatile IA32_PTE_4K LocalPte4K;
>
>
>
>LocalPte4K.Uint64 = Pte4K->Uint64;
>
>if (Mask->Bits.PageTableBaseAddressLow ||
> Mask->Bits.PageTableBaseAddressHigh) {
>
> @@ -78,7 +78,7 @@ PageTableLibSetPte4K (
>}
>
>
>
>if (Pte4K->Uint64 != LocalPte4K.Uint64) {
>
> -Pte4K->Uint64 = LocalPte4K.Uint64;
>
> +*(volatile UINT64 *)&(Pte4K->Uint64) = LocalPte4K.Uint64;
>
>}
>
> }
>
>
>
> @@ -100,7 +100,7 @@ PageTableLibSetPleB (
>IN IA32_MAP_ATTRIBUTE *Mask
>
>)
>
> {
>
> - IA32_PAGE_LEAF_ENTRY_BIG_PAGESIZE LocalPleB;
>
> + volatile IA32_PAGE_LEAF_ENTRY_BIG_PAGESIZE LocalPleB;
>
>
>
>LocalPleB.Uint64 = PleB->Uint64;
>
>if (Mask->Bits.PageTableBaseAddressLow ||
> Mask->Bits.PageTableBaseAddressHigh) {
>
> @@ -154,7 +154,7 @@ PageTableLibSetPleB (
>}
>
>
>
>if (PleB->Uint64 != LocalPleB.Uint64) {
>
> -PleB->Uint64 = LocalPleB.Uint64;
>
> +*(volatile UINT64 *)&(PleB->Uint64) = LocalPleB.Uint64;
>
>}
>
> }
>
>
>
> @@ -200,7 +200,7 @@ PageTableLibSetPnle (
>IN IA32_MAP_ATTRIBUTE*Mask
>
>)
>
> {
>
> - IA32_PAGE_NON_LEAF_ENTRY LocalPnle;
>
> + volatile IA32_PAGE_NON_LEAF_ENTRY LocalPnle;
>
>
>
>LocalPnle.Uint64 = Pnle->Uint64;
>
>if (Mask->Bits.Present) {
>
> @@ -231,7 +231,7 @@ PageTableLibSetPnle (
>LocalPnle.Bits.WriteThrough = 0;
>
>LocalPnle.Bits.CacheDisabled = 0;
>
>if (Pnle->Uint64 != LocalPnle.Uint64) {
>
> -Pnle->Uint64 = LocalPnle.Uint64;
>
> +*(volatile UINT64 *)&(Pnle->Uint64) = LocalPnle.Uint64;
>
>}
>
> }
>
>
>
> --
> 2.31.1.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115712): https://edk2.groups.io/g/devel/message/115712
Mute This Topic: https://groups.io/mt/104483610/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] UefiCpuPkg: Fix IN OUT parameters marked as IN
Reviewed-by: Ray Ni
Thanks,
Ray
> -Original Message-
> From: Zhou, Jianfeng
> Sent: Wednesday, February 21, 2024 9:25 AM
> To: devel@edk2.groups.io
> Cc: Zhou, Jianfeng ; Ni, Ray ;
> Laszlo Ersek ; Kumar, Rahul R
> ; Gerd Hoffmann
> Subject: [PATCH] UefiCpuPkg: Fix IN OUT parameters marked as IN
>
> Some IN OUT parameters in CpuPageTableMap.c were mistakenly marked as
> IN.
> "IN" replaced with "IN OUT" in the following interfaces:
>
> PageTableLibSetPte4K(): Pte4K
> PageTableLibSetPleB(): PleB
> PageTableLibSetPle(): Ple
> PageTableLibSetPnle(): Pnle
>
> Signed-off-by: Zhou Jianfeng
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Cc: Rahul Kumar
> Cc: Gerd Hoffmann
> ---
> .../Library/CpuPageTableLib/CpuPageTableMap.c | 32 +--
> 1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> b/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> index ae4caf8dfe..2ea40666cc 100644
> --- a/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> +++ b/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
> @@ -20,10 +20,10 @@
> **/
>
> VOID
>
> PageTableLibSetPte4K (
>
> - IN IA32_PTE_4K *Pte4K,
>
> - IN UINT64 Offset,
>
> - IN IA32_MAP_ATTRIBUTE *Attribute,
>
> - IN IA32_MAP_ATTRIBUTE *Mask
>
> + IN OUT IA32_PTE_4K *Pte4K,
>
> + IN UINT64 Offset,
>
> + IN IA32_MAP_ATTRIBUTE *Attribute,
>
> + IN IA32_MAP_ATTRIBUTE *Mask
>
>)
>
> {
>
>IA32_PTE_4K LocalPte4K;
>
> @@ -94,10 +94,10 @@ PageTableLibSetPte4K (
> **/
>
> VOID
>
> PageTableLibSetPleB (
>
> - IN IA32_PAGE_LEAF_ENTRY_BIG_PAGESIZE *PleB,
>
> - IN UINT64 Offset,
>
> - IN IA32_MAP_ATTRIBUTE *Attribute,
>
> - IN IA32_MAP_ATTRIBUTE *Mask
>
> + IN OUT IA32_PAGE_LEAF_ENTRY_BIG_PAGESIZE *PleB,
>
> + IN UINT64 Offset,
>
> + IN IA32_MAP_ATTRIBUTE *Attribute,
>
> + IN IA32_MAP_ATTRIBUTE *Mask
>
>)
>
> {
>
>IA32_PAGE_LEAF_ENTRY_BIG_PAGESIZE LocalPleB;
>
> @@ -171,11 +171,11 @@ PageTableLibSetPleB (
> **/
>
> VOID
>
> PageTableLibSetPle (
>
> - IN UINTN Level,
>
> - IN IA32_PAGING_ENTRY *Ple,
>
> - IN UINT64 Offset,
>
> - IN IA32_MAP_ATTRIBUTE *Attribute,
>
> - IN IA32_MAP_ATTRIBUTE *Mask
>
> + IN UINTN Level,
>
> + IN OUT IA32_PAGING_ENTRY *Ple,
>
> + IN UINT64 Offset,
>
> + IN IA32_MAP_ATTRIBUTE *Attribute,
>
> + IN IA32_MAP_ATTRIBUTE *Mask
>
>)
>
> {
>
>if (Level == 1) {
>
> @@ -195,9 +195,9 @@ PageTableLibSetPle (
> **/
>
> VOID
>
> PageTableLibSetPnle (
>
> - IN IA32_PAGE_NON_LEAF_ENTRY *Pnle,
>
> - IN IA32_MAP_ATTRIBUTE*Attribute,
>
> - IN IA32_MAP_ATTRIBUTE*Mask
>
> + IN OUT IA32_PAGE_NON_LEAF_ENTRY *Pnle,
>
> + IN IA32_MAP_ATTRIBUTE*Attribute,
>
> + IN IA32_MAP_ATTRIBUTE*Mask
>
>)
>
> {
>
>IA32_PAGE_NON_LEAF_ENTRY LocalPnle;
>
> --
> 2.31.1.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115711): https://edk2.groups.io/g/devel/message/115711
Mute This Topic: https://groups.io/mt/104483605/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 5/5] UefiCpuPkg/MpInitLib: Add support for multiple HOBs to SaveCpuMpData()
>
> + MaxCpusPerHob = (MAX_UINT16 - sizeof (EFI_HOB_GUID_TYPE) - sizeof
> (MP_HAND_OFF)) / sizeof (PROCESSOR_HAND_OFF);
Above formula assumes the maximum HOB length could be 0x.
But actually the maximum HOB length could be only 0xFFF8 because
PeiCore::PeiCreateHob() contains following logic:
if (0x1 - Length <= 0x7) {
return EFI_INVALID_PARAMETER;
}
Length = (UINT16)((Length + 0x7) & (~0x7));
The if-check is to guarantee (Length + 0x7) & ~0x7 doesn't produce value 0
when the Length > 0xFFF8.
So, that means the formula should use 0xFFF8 instead of 0x (MAX_UINT16).
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115707): https://edk2.groups.io/g/devel/message/115707
Mute This Topic: https://groups.io/mt/104472313/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 4/5] UefiCpuPkg/MpInitLib: Add support for multiple HOBs to MpInitLibInitialize
> > Loop over all MP_HAND_OFF HOBs instead of expecting a single HOB > covering all CPUs in the system. > > Add a new HaveMpHandOff variable to track whenever MP_HAND_OFF HOBs > are The commit message may need to be updated as "HaveMpHandOff" variable is gone in this version. With that, Reviewed-by: Ray Ni -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#115706): https://edk2.groups.io/g/devel/message/115706 Mute This Topic: https://groups.io/mt/104472311/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 2/5] UefiCpuPkg/MpInitLib: Add support for multiple HOBs to GetBspNumber()
Reviewed-by: Ray Ni
Thanks,
Ray
> -Original Message-
> From: Gerd Hoffmann
> Sent: Wednesday, February 21, 2024 1:50 AM
> To: devel@edk2.groups.io
> Cc: Oliver Steffen ; Laszlo Ersek
> ; Kumar, Rahul R ; Ni, Ray
> ; Gerd Hoffmann
> Subject: [PATCH v2 2/5] UefiCpuPkg/MpInitLib: Add support for multiple
> HOBs to GetBspNumber()
>
> Rename the MpHandOff parameter to FirstMpHandOff. Add a loop so the
> function inspects all HOBs present in the system.
>
> Signed-off-by: Gerd Hoffmann
> ---
> UefiCpuPkg/Library/MpInitLib/MpLib.c | 23 +++
> 1 file changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> index e764bc9e4228..8f198ff6d817 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> @@ -1894,26 +1894,33 @@ CheckAllAPs (
> /**
>This function Get BspNumber.
>
> - @param[in] MpHandOffPointer to MpHandOff
> + @param[in] FirstMpHandOff Pointer to first MpHandOff HOB.
>@return BspNumber
> **/
> UINT32
> GetBspNumber (
> - IN CONST MP_HAND_OFF *MpHandOff
> + IN CONST MP_HAND_OFF *FirstMpHandOff
>)
> {
> - UINT32 ApicId;
> - UINT32 BspNumber;
> - UINT32 Index;
> + UINT32 ApicId;
> + UINT32 BspNumber;
> + UINT32 Index;
> + CONST MP_HAND_OFF *MpHandOff;
>
>//
>// Get the processor number for the BSP
>//
>BspNumber = MAX_UINT32;
>ApicId= GetInitialApicId ();
> - for (Index = 0; Index < MpHandOff->CpuCount; Index++) {
> -if (MpHandOff->Info[Index].ApicId == ApicId) {
> - BspNumber = Index;
> +
> + for (MpHandOff = FirstMpHandOff;
> + MpHandOff != NULL;
> + MpHandOff = GetNextMpHandOffHob (MpHandOff))
> + {
> +for (Index = 0; Index < MpHandOff->CpuCount; Index++) {
> + if (MpHandOff->Info[Index].ApicId == ApicId) {
> +BspNumber = MpHandOff->ProcessorIndex + Index;
> + }
> }
>}
>
> --
> 2.43.2
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115705): https://edk2.groups.io/g/devel/message/115705
Mute This Topic: https://groups.io/mt/104472310/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 2/5] UefiCpuPkg/MpInitLib: Add support for multiple HOBs to GetBspNumber()
Reviewed-by: Ray Ni
Thanks,
Ray
> -Original Message-
> From: Gerd Hoffmann
> Sent: Wednesday, February 21, 2024 1:50 AM
> To: devel@edk2.groups.io
> Cc: Oliver Steffen ; Laszlo Ersek
> ; Kumar, Rahul R ; Ni, Ray
> ; Gerd Hoffmann
> Subject: [PATCH v2 2/5] UefiCpuPkg/MpInitLib: Add support for multiple
> HOBs to GetBspNumber()
>
> Rename the MpHandOff parameter to FirstMpHandOff. Add a loop so the
> function inspects all HOBs present in the system.
>
> Signed-off-by: Gerd Hoffmann
> ---
> UefiCpuPkg/Library/MpInitLib/MpLib.c | 23 +++
> 1 file changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> index e764bc9e4228..8f198ff6d817 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> @@ -1894,26 +1894,33 @@ CheckAllAPs (
> /**
>This function Get BspNumber.
>
> - @param[in] MpHandOffPointer to MpHandOff
> + @param[in] FirstMpHandOff Pointer to first MpHandOff HOB.
>@return BspNumber
> **/
> UINT32
> GetBspNumber (
> - IN CONST MP_HAND_OFF *MpHandOff
> + IN CONST MP_HAND_OFF *FirstMpHandOff
>)
> {
> - UINT32 ApicId;
> - UINT32 BspNumber;
> - UINT32 Index;
> + UINT32 ApicId;
> + UINT32 BspNumber;
> + UINT32 Index;
> + CONST MP_HAND_OFF *MpHandOff;
>
>//
>// Get the processor number for the BSP
>//
>BspNumber = MAX_UINT32;
>ApicId= GetInitialApicId ();
> - for (Index = 0; Index < MpHandOff->CpuCount; Index++) {
> -if (MpHandOff->Info[Index].ApicId == ApicId) {
> - BspNumber = Index;
> +
> + for (MpHandOff = FirstMpHandOff;
> + MpHandOff != NULL;
> + MpHandOff = GetNextMpHandOffHob (MpHandOff))
> + {
> +for (Index = 0; Index < MpHandOff->CpuCount; Index++) {
> + if (MpHandOff->Info[Index].ApicId == ApicId) {
> +BspNumber = MpHandOff->ProcessorIndex + Index;
> + }
> }
>}
>
> --
> 2.43.2
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115704): https://edk2.groups.io/g/devel/message/115704
Mute This Topic: https://groups.io/mt/104472310/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 1/5] UefiCpuPkg/MpInitLib: Add support for multiple HOBs to GetMpHandOffHob
> -Original Message- > From: Gerd Hoffmann > Sent: Wednesday, February 21, 2024 1:50 AM > To: devel@edk2.groups.io > Cc: Oliver Steffen ; Laszlo Ersek > ; Kumar, Rahul R ; Ni, Ray > ; Gerd Hoffmann > Subject: [PATCH v2 1/5] UefiCpuPkg/MpInitLib: Add support for multiple > HOBs to GetMpHandOffHob > > Rename the function to GetNextMpHandOffHob(), add MP_HAND_OFF > parameter. > When called with NULL pointer return the first HOB, otherwise return the > next in the chain. > > Also add the function prototype to the MpLib.h header file. > > Signed-off-by: Gerd Hoffmann > --- > UefiCpuPkg/Library/MpInitLib/MpLib.h | 12 > UefiCpuPkg/Library/MpInitLib/MpLib.c | 26 -- > 2 files changed, 28 insertions(+), 10 deletions(-) > > diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.h > b/UefiCpuPkg/Library/MpInitLib/MpLib.h > index a96a6389c17d..bc2a0232291d 100644 > --- a/UefiCpuPkg/Library/MpInitLib/MpLib.h > +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.h > @@ -485,6 +485,18 @@ SwitchApContext ( >IN MP_HAND_OFF *MpHandOff >); > > +/** > + Get pointer to next MP_HAND_OFF GUIDed HOB. > + > + @param[in] MpHandOff Previous HOB. Pass NULL to get the first > HOB. Can you please emphasize in above comments that MpHandOff points to the GUIDed HOB data? The function implementation assumes that. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#115703): https://edk2.groups.io/g/devel/message/115703 Mute This Topic: https://groups.io/mt/104472308/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 5/5] UefiCpuPkg/MpInitLib: Add support for multiple HOBs to SaveCpuMpData()
>
> > +
> > + if (CpuMpData->ApLoopMode != ApInHltLoop) {
> > +MpHandOff->StartupSignalValue= MP_HAND_OFF_SIGNAL;
> > +MpHandOff->WaitLoopExecutionMode = sizeof (VOID *);
> > + }
> > +}
>
> As noted elsewhere, these fields don't belong in the loop (they don't
> belong to MP_HAND_OFF, going forward); the two of them together should
> form a new singleton structure.
>
I agree the StartupSignalValue and WaitLoopExecutionMode are duplicated fields
if multiple MP_HAND_OFF instances are created.
I am ok to leave them as duplicates in this patch series.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115638): https://edk2.groups.io/g/devel/message/115638
Mute This Topic: https://groups.io/mt/104369848/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 1/5] UefiCpuPkg/MpInitLib: Add ProcessorIndex argument to GetMpHandOffHob()
> > That will only work if the HOBs are returned in ProcessorIndex order. > > That happens to be the case in my testing; the HOBs are returned in the > same order they are created by patch #5 of this series. > > Is that behavior guaranteed? MdePkg/Include/Library/HobLib.h doesn't > say anything about the ordering. The HOB item order follows when it's created. The HOB structure implicitly guarantees it. I am aware that in a production server UEFI firmware, the number of HOB items is huge. Enumerating the HOB list multiple times is a big cost. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#115619): https://edk2.groups.io/g/devel/message/115619 Mute This Topic: https://groups.io/mt/104369841/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v1 2/2] UefiCpuPkg/PiSmmCpuDxeSmm: Check BspIndex first before lock cmpxchg
> This patch makes me uncomfortable. I understand what it intends to do, > and the intent is not wrong, but we're again treating "volatile UINT32" > as atomic, and non-reorderable against the > InterlockedCompareExchange32(). This kind of "optimization" is what > people write cautionary tales about, later. It would be nice to see a > semi-formal *proof* that this cannot backfire. Laszlo, Thanks for the questions. I was OOO in the past 10 days for Chinese New Year. From Chapter 9 "Multiple-Processor Management", section 9.2.2 "Memory Ordering in P6 and More Recent Processor Families", I read the following: In a single-processor system for memory regions defined as write-back cacheable, the memory ordering model respects the following principles...: * ... * Reads or writes cannot be reordered with I/O instructions, locked instructions, or serializing instructions. So, it guarantees/proves "read of BspIndex" performs before "InterlockedCompareExchange32()/lock comxchg". I think that can resolve one of your concern regarding the "ordering". I don't quite understand your concern regarding the "atomic". -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#115585): https://edk2.groups.io/g/devel/message/115585 Mute This Topic: https://groups.io/mt/104094808/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] UefiCpuPkg: code refine
> -PleB->Uint64 = LocalPleB.Uint64; > > +*(volatile UINT64 *)&(PleB->Uint64) = LocalPleB.Uint64; Jianfeng, If "volatile" is to tell compiler to generate single "mov" instruction for the assignment. I am curious how it works in 32bit env where the general purpose registers are 32bit width? Thanks, Ray -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#115581): https://edk2.groups.io/g/devel/message/115581 Mute This Topic: https://groups.io/mt/104256295/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 5/5] UefiCpuPkg/MpInitLib: Add support for multiple HOBs to SaveCpuMpData()
> + STATIC CONST UINT32 CpusPerHob = 128; 1. Can you refer to https://github.com/tianocore/edk2/blob/9979c887ef54023c9e262242db02c92d11b7f1e5/UefiCpuPkg/CpuMpPei/CpuMpPei.c#L572 to avoid hardcode 128? The MP_HAND_OFF structure change may cause 128 an invalid value. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#115580): https://edk2.groups.io/g/devel/message/115580 Mute This Topic: https://groups.io/mt/104369848/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 4/5] UefiCpuPkg/MpInitLib: Add support for multiple HOBs to MpInitLibInitialize
> - MpHandOff = GetMpHandOffHob (0);
> - if (MpHandOff == NULL) {
> + MaxLogicalProcessorNumber = 0;
> + HaveMpHandOff = FALSE;
1. Can we cache the first MpHandOff instance? It can be used as an indicator to
replace "HaveMpHandOff",
and also can speed up the HOB enumeration in later logic.
> +
> + while ((MpHandOff = GetMpHandOffHob
> (MaxLogicalProcessorNumber)) != 0) {
2. Can you use "!= NULL" instead of "!= 0"?
> +DEBUG ((
> + DEBUG_INFO,
> + "%a: ProcessorIndex=%u CpuCount=%u\n",
> + __func__,
> + MpHandOff->ProcessorIndex,
> + MpHandOff->CpuCount
> + ));
3. can you add an assertion "ASSERT (MaxLogicalProcessorNumber ==
MpHandOff->ProcessorIndex);"?
It's to ensure no gap or overlap.
> +MaxLogicalProcessorNumber += MpHandOff->CpuCount;
> +HaveMpHandOff = TRUE;
> + }
> +
> + if (!HaveMpHandOff) {
4. "HaveMpHandOff == TRUE" --> "FirstMpHandOff != NULL"
> + for (HobIndex = 0; HobIndex < MpHandOff->CpuCount; HobIndex++)
5. How about "ProcessorIndexInHob"? "HobIndex" is a bit confusing.
>
> +MpHandOff = GetMpHandOffHob (0);
6. All the GetMpHandOffHob(0) can be replaced with "FirstMpHandOff".
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115579): https://edk2.groups.io/g/devel/message/115579
Mute This Topic: https://groups.io/mt/104369843/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 3/5] UefiCpuPkg/MpInitLib: Add support for multiple HOBs to SwitchApContext()
SwitchApContext() can cache the first instance of MpHandOffHob so that the
second enumeration can avoid searching
for the MpHandOffHob from the top of HOB list.
> VOID
> SwitchApContext (
> - IN MP_HAND_OFF *MpHandOff
> + VOID
>)
> {
> - UINTN Index;
> - UINT32 BspNumber;
> + UINTNIndex;
> + UINT32 BspNumber;
> + MP_HAND_OFF *MpHandOff;
>
>BspNumber = GetBspNumber ();
>
> - for (Index = 0; Index < MpHandOff->CpuCount; Index++) {
> -if (Index != BspNumber) {
> - *(UINTN
> *)(UINTN)MpHandOff->Info[Index].StartupProcedureAddress =
> (UINTN)SwitchContextPerAp;
> - *(UINT32 *)(UINTN)MpHandOff->Info[Index].StartupSignalAddress
> = MpHandOff->StartupSignalValue;
> + for (MpHandOff = GetMpHandOffHob (0);
> + MpHandOff != NULL;
> + MpHandOff = GetMpHandOffHob (MpHandOff->ProcessorIndex +
> MpHandOff->CpuCount))
> + {
> +for (Index = 0; Index < MpHandOff->CpuCount; Index++) {
> + if (MpHandOff->ProcessorIndex + Index != BspNumber) {
> +*(UINTN
> *)(UINTN)MpHandOff->Info[Index].StartupProcedureAddress =
> (UINTN)SwitchContextPerAp;
> +*(UINT32
> *)(UINTN)MpHandOff->Info[Index].StartupSignalAddress =
> MpHandOff->StartupSignalValue;
> + }
> }
>}
>
>//
>// Wait all APs waken up if this is not the 1st broadcast of SIPI
>//
> - for (Index = 0; Index < MpHandOff->CpuCount; Index++) {
> -if (Index != BspNumber) {
> - WaitApWakeup ((UINT32
> *)(UINTN)(MpHandOff->Info[Index].StartupSignalAddress));
> + for (MpHandOff = GetMpHandOffHob (0);
> + MpHandOff != NULL;
> + MpHandOff = GetMpHandOffHob (MpHandOff->ProcessorIndex +
> MpHandOff->CpuCount))
> + {
> +for (Index = 0; Index < MpHandOff->CpuCount; Index++) {
> + if (MpHandOff->ProcessorIndex + Index != BspNumber) {
> +WaitApWakeup ((UINT32
> *)(UINTN)(MpHandOff->Info[Index].StartupSignalAddress));
> + }
> }
>}
> }
> @@ -2226,7 +2235,7 @@ MpInitLibInitialize (
>// enables the APs to switch to a different memory section and
> continue their
>// looping process there.
>//
> - SwitchApContext (MpHandOff);
> + SwitchApContext ();
>//
>// Wait for all APs finished initialization
>//
> --
> 2.43.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115578): https://edk2.groups.io/g/devel/message/115578
Mute This Topic: https://groups.io/mt/104369847/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 2/5] UefiCpuPkg/MpInitLib: Add support for multiple HOBs to GetBspNumber()
Since MpHandOff HOBs are created by the PEI instance of MpInitLib, I am ok that
the consumer (DXE instance)
assumes the HOB instances are created in the order of ProcessorIndex.
Please update the patch accordingly with the change of GetMpHandOffHob() I
commented to patch #1.
Thanks,
Ray
> -Original Message-
> From: Gerd Hoffmann
> Sent: Thursday, February 15, 2024 5:32 PM
> To: devel@edk2.groups.io
> Cc: Oliver Steffen ; Ni, Ray ; Laszlo
> Ersek ; Kumar, Rahul R ;
> Gerd Hoffmann
> Subject: [PATCH 2/5] UefiCpuPkg/MpInitLib: Add support for multiple HOBs to
> GetBspNumber()
>
> Remove the MpHandOff parameter. This is not useful in case multiple
> HOBs are present in the system. The function will use GetMpHandOffHob()
> to loop over all HOBs instead.
>
> Signed-off-by: Gerd Hoffmann
> ---
> UefiCpuPkg/Library/MpInitLib/MpLib.c | 26 --
> 1 file changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> index e0a2366073a7..8e6cf50ed171 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> @@ -1894,26 +1894,32 @@ CheckAllAPs (
> /**
>This function Get BspNumber.
>
> - @param[in] MpHandOffPointer to MpHandOff
>@return BspNumber
> **/
> UINT32
> GetBspNumber (
> - IN CONST MP_HAND_OFF *MpHandOff
> + VOID
>)
> {
> - UINT32 ApicId;
> - UINT32 BspNumber;
> - UINT32 Index;
> + UINT32 ApicId;
> + UINT32 BspNumber;
> + UINT32 Index;
> + MP_HAND_OFF *MpHandOff;
>
>//
>// Get the processor number for the BSP
>//
>BspNumber = MAX_UINT32;
>ApicId= GetInitialApicId ();
> - for (Index = 0; Index < MpHandOff->CpuCount; Index++) {
> -if (MpHandOff->Info[Index].ApicId == ApicId) {
> - BspNumber = Index;
> +
> + for (MpHandOff = GetMpHandOffHob (0);
> + MpHandOff != NULL;
> + MpHandOff = GetMpHandOffHob (MpHandOff->ProcessorIndex +
> MpHandOff->CpuCount))
> + {
> +for (Index = 0; Index < MpHandOff->CpuCount; Index++) {
> + if (MpHandOff->Info[Index].ApicId == ApicId) {
> +BspNumber = MpHandOff->ProcessorIndex + Index;
> + }
> }
>}
>
> @@ -1941,7 +1947,7 @@ SwitchApContext (
>UINTN Index;
>UINT32 BspNumber;
>
> - BspNumber = GetBspNumber (MpHandOff);
> + BspNumber = GetBspNumber ();
>
>for (Index = 0; Index < MpHandOff->CpuCount; Index++) {
> if (Index != BspNumber) {
> @@ -2191,7 +2197,7 @@ MpInitLibInitialize (
> }
>
> CpuMpData->CpuCount = MpHandOff->CpuCount;
> -CpuMpData->BspNumber = GetBspNumber (MpHandOff);
> +CpuMpData->BspNumber = GetBspNumber ();
> CpuInfoInHob = (CPU_INFO_IN_HOB
> *)(UINTN)CpuMpData->CpuInfoInHob;
> for (Index = 0; Index < CpuMpData->CpuCount; Index++) {
>InitializeSpinLock (>CpuData[Index].ApLock);
> --
> 2.43.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115577): https://edk2.groups.io/g/devel/message/115577
Mute This Topic: https://groups.io/mt/104369845/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 1/5] UefiCpuPkg/MpInitLib: Add ProcessorIndex argument to GetMpHandOffHob()
>EFI_HOB_GUID_TYPE *GuidHob;
>MP_HAND_OFF*MpHandOff;
>
> - MpHandOff = NULL;
> - GuidHob = GetFirstGuidHob ();
> - if (GuidHob != NULL) {
> + for (GuidHob = GetFirstGuidHob ();
> + GuidHob != NULL;
> + GuidHob = GetNextGuidHob (, GET_NEXT_HOB
> (GuidHob)))
> + {
> MpHandOff = (MP_HAND_OFF *)GET_GUID_HOB_DATA (GuidHob);
> +if (MpHandOff->ProcessorIndex == ProcessorIndex) {
> + return MpHandOff;
> +}
Gerd,
The code is doing correctly but I have concerns about the performance impact.
With the prototype GetMpHandOffHob(), callers call it multiple times to
enumerate all HOB instances.
But every call is a HOB list enumeration from top of the HOB list which may be
slow in a platform
that contains lots of HOB items and the MpHandOff HOB instances happen to be in
the very bottom.
How about add another parameter "HobStart" to GetMpHandOffHob()? So that only
the first call to
GetMpHandOffHob() is a HOB list enumeration from top, latter calls start from
the next HOB of the previous
found MpHandOff HOB instance.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115576): https://edk2.groups.io/g/devel/message/115576
Mute This Topic: https://groups.io/mt/104369841/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [Patch 1/1] PcAtChipsetPkg/HpetTimerDxe: Fix nested interrupt time accuracy
Reviewed-by: Ray Ni Thanks, Ray > -Original Message- > From: Kinney, Michael D > Sent: Saturday, January 27, 2024 3:56 PM > To: devel@edk2.groups.io > Cc: Ni, Ray > Subject: [Patch 1/1] PcAtChipsetPkg/HpetTimerDxe: Fix nested interrupt time > accuracy > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4659 > > When HPET timer is used as the timer interrupt and nested > interrupts into the HPET timer interrupt handler occur, the > elapsed time passed into the DXE Core is sometime too large > and this causes the DXE Core internal system time to run too > fast. Fix the logic so the previous main counter value stored > in the module global variable mPreviousMainCounter is always > captured before the timer notification function is called. > > Without this change, mPreviousMainCounter is updated after > the timer notification function is called and when nesting > occurs, it updates with the value from the first level of > nesting which is further back in time than the interrupt from > the deepest level of nesting. This causes the next two timer > interrupts to compute a TimerPeriod that is twice the actual > time period since the last interrupt and this causes the DXE > Core internal time to run faster than expected. > > Cc: Ray Ni > Signed-off-by: Michael D Kinney > --- > PcAtChipsetPkg/HpetTimerDxe/HpetTimer.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/PcAtChipsetPkg/HpetTimerDxe/HpetTimer.c > b/PcAtChipsetPkg/HpetTimerDxe/HpetTimer.c > index 427572c2ff6d..e74777fbc6f4 100644 > --- a/PcAtChipsetPkg/HpetTimerDxe/HpetTimer.c > +++ b/PcAtChipsetPkg/HpetTimerDxe/HpetTimer.c > @@ -387,11 +387,18 @@ TimerInterruptHandler ( > 1 > ); > > +// > +// Save main counter value before calling notification function > +// that may enable interrupts and allow interrupt nesting. > +// > +mPreviousMainCounter = MainCounter; > + > // > // Call registered notification function passing in the time since the > last > // interrupt in 100 ns units. > // > mTimerNotifyFunction (TimerPeriod); > +return; >} > >// > -- > 2.40.1.windows.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#114649): https://edk2.groups.io/g/devel/message/114649 Mute This Topic: https://groups.io/mt/103992760/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
