[edk2-devel] [PATCH v2 10/10] OvmfPkg/ResetVector: wire up 5-level paging for SEV

[Gerd Hoffmann]

Turn the GetSevCBitMaskAbove31 OneTimeCall into a macro because we
need that twice (for 4-level and 5-level paging).  Change include
order to allow AmdSev.asm macros being used in PageTables64.asm.

Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/ResetVector/Ia32/AmdSev.asm   | 16 
 OvmfPkg/ResetVector/Ia32/PageTables64.asm | 14 +-
 OvmfPkg/ResetVector/ResetVector.nasmb |  4 ++--
 3 files changed, 23 insertions(+), 11 deletions(-)

diff --git a/OvmfPkg/ResetVector/Ia32/AmdSev.asm 
b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
index cbb86871636f..c577f5572f04 100644
--- a/OvmfPkg/ResetVector/Ia32/AmdSev.asm
+++ b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
@@ -146,6 +146,14 @@ BITS32
 jmp %%TerminateHlt
 %endmacro
 
+; Get the C-bit mask above 31.
+; Modified: EDX
+;
+; The value is returned in the EDX
+%macro GetSevCBitMaskAbove31 0
+mov edx, dword[SEV_ES_WORK_AREA_ENC_MASK + 4]
+%endmacro
+
 ; Terminate the guest due to unexpected response code.
 SevEsUnexpectedRespTerminate:
 TerminateVmgExitTERM_UNEXPECTED_RESP_CODE
@@ -191,14 +199,6 @@ pageTableEntries4kLoop:
 SevClearPageEncMaskForGhcbPageExit:
 OneTimeCallRet SevClearPageEncMaskForGhcbPage
 
-; Get the C-bit mask above 31.
-; Modified: EDX
-;
-; The value is returned in the EDX
-GetSevCBitMaskAbove31:
-mov   edx, dword[SEV_ES_WORK_AREA_ENC_MASK + 4]
-OneTimeCallRet GetSevCBitMaskAbove31
-
 %endif
 
 ; Check if Secure Encrypted Virtualization (SEV) features are enabled.
diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
index 29ce155eed8d..92d134441abe 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
@@ -247,11 +247,23 @@ SevInit:
 ; SEV workflow
 ;
 ClearOvmfPageTables
+%if PG_5_LEVEL
+Check5LevelPaging Sev4Level
 ; If SEV is enabled, the C-bit position is always above 31.
 ; The mask will be saved in the EDX and applied during the
 ; the page table build below.
-OneTimeCall   GetSevCBitMaskAbove31
+GetSevCBitMaskAbove31
+CreatePageTables5Level edx
+Enable5LevelPaging
+jmp SevCommon
+Sev4Level:
+%endif
+; If SEV is enabled, the C-bit position is always above 31.
+; The mask will be saved in the EDX and applied during the
+; the page table build below.
+GetSevCBitMaskAbove31
 CreatePageTables4Level edx
+SevCommon:
 ; Clear the C-bit from the GHCB page if the SEV-ES is enabled.
 OneTimeCall   SevClearPageEncMaskForGhcbPage
 OneTimeCall   SevClearVcHandlerAndStack
diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb 
b/OvmfPkg/ResetVector/ResetVector.nasmb
index 2bd80149e58b..ba83bc7b3124 100644
--- a/OvmfPkg/ResetVector/ResetVector.nasmb
+++ b/OvmfPkg/ResetVector/ResetVector.nasmb
@@ -92,6 +92,8 @@
 %define SNP_SEC_MEM_BASE_DESC_3   (CPUID_BASE + CPUID_SIZE + 
SEV_SNP_KERNEL_HASHES_SIZE)
 %define SNP_SEC_MEM_SIZE_DESC_3   (FixedPcdGet32 (PcdOvmfPeiMemFvBase) - 
SNP_SEC_MEM_BASE_DESC_3)
 
+%include "Ia32/AmdSev.asm"
+
 %ifdef ARCH_X64
   #include 
 
@@ -144,8 +146,6 @@
   %include "X64/OvmfSevMetadata.asm"
 %endif
 
-%include "Ia32/AmdSev.asm"
-
 %include "Ia16/Real16ToFlat32.asm"
 %include "Ia16/Init16.asm"
 
-- 
2.44.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116223): https://edk2.groups.io/g/devel/message/116223
Mute This Topic: https://groups.io/mt/104660118/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 08/10] OvmfPkg/ResetVector: wire up 5-level paging for TDX

[Gerd Hoffmann]

BSP workflow is quite simliar to the non-coco case.

TDX_WORK_AREA_PGTBL_READY is used to record the paging mode:
  1 == 4-level paging
  2 == 5-level paging

APs will look at TDX_WORK_AREA_PGTBL_READY to figure whenever
they should enable 5-level paging or not.

Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/ResetVector/Ia32/IntelTdx.asm | 13 -
 OvmfPkg/ResetVector/Ia32/PageTables64.asm | 16 
 2 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/ResetVector/Ia32/IntelTdx.asm 
b/OvmfPkg/ResetVector/Ia32/IntelTdx.asm
index c6b86019dfb9..7d775591a05b 100644
--- a/OvmfPkg/ResetVector/Ia32/IntelTdx.asm
+++ b/OvmfPkg/ResetVector/Ia32/IntelTdx.asm
@@ -179,7 +179,7 @@ InitTdx:
 ;
 ; Modified:  EAX, EDX
 ;
-; 0-NonTdx, 1-TdxBsp, 2-TdxAps
+; 0-NonTdx, 1-TdxBsp, 2-TdxAps, 3-TdxAps5Level
 ;
 CheckTdxFeaturesBeforeBuildPagetables:
 xor eax, eax
@@ -200,6 +200,17 @@ TdxPostBuildPageTables:
 mov byte[TDX_WORK_AREA_PGTBL_READY], 1
 OneTimeCallRet TdxPostBuildPageTables
 
+%if PG_5_LEVEL
+
+;
+; Set byte[TDX_WORK_AREA_PGTBL_READY] to 2
+;
+TdxPostBuildPageTables5Level:
+mov byte[TDX_WORK_AREA_PGTBL_READY], 2
+OneTimeCallRet TdxPostBuildPageTables5Level
+
+%endif
+
 ;
 ; Check if TDX is enabled
 ;
diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
index e15945da0476..b922c845f297 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
@@ -44,6 +44,7 @@ BITS32
 
 %define TDX_BSP 1
 %define TDX_AP  2
+%define TDX_AP_5_LEVEL  3
 
 ;
 ; For OVMF, build some initial page tables at
@@ -214,7 +215,14 @@ SetCr3ForPageTables64:
 jeTdxBspInit
 cmp   eax, TDX_AP
 jeSetCr3
+%if PG_5_LEVEL
+cmp   eax, TDX_AP_5_LEVEL
+jne   CheckForSev
+Enable5LevelPaging
+jmp   SetCr3
+%endif
 
+CheckForSev:
 ; Check whether the SEV is active and populate the SevEsWorkArea
 OneTimeCall   CheckSevFeatures
 cmp   byte[WORK_AREA_GUEST_TYPE], 1
@@ -253,6 +261,14 @@ TdxBspInit:
 ; TDX BSP workflow
 ;
 ClearOvmfPageTables
+%if PG_5_LEVEL
+Check5LevelPaging Tdx4Level
+CreatePageTables5Level 0
+OneTimeCall TdxPostBuildPageTables5Level
+Enable5LevelPaging
+jmp SetCr3
+Tdx4Level:
+%endif
 CreatePageTables4Level 0
 OneTimeCall TdxPostBuildPageTables
 jmp SetCr3
-- 
2.44.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116222): https://edk2.groups.io/g/devel/message/116222
Mute This Topic: https://groups.io/mt/104660117/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 09/10] OvmfPkg/ResetVector: leave SEV VC handler installed longer

[Gerd Hoffmann]

When running in SEV mode keep the VC handler installed.
Add a function to uninstall it later.

This allows using the cpuid instruction in SetCr3ForPageTables64,
which is needed to check for la57 & 1G page support.

Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/ResetVector/Ia32/AmdSev.asm   | 12 ++--
 OvmfPkg/ResetVector/Ia32/PageTables64.asm |  1 +
 OvmfPkg/ResetVector/Main.asm  |  4 
 3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/ResetVector/Ia32/AmdSev.asm 
b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
index 23e4c5ebbe92..cbb86871636f 100644
--- a/OvmfPkg/ResetVector/Ia32/AmdSev.asm
+++ b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
@@ -320,9 +320,9 @@ NoSevEsVcHlt:
 NoSevPass:
 xor   eax, eax
 
-SevExit:
 ;
-; Clear exception handlers and stack
+; When NOT running in SEV mode: clear exception handlers and stack here.
+; Otherwise: SevClearVcHandlerAndStack must be called later.
 ;
 push  eax
 mov   eax, ADDR_OF(IdtrClear)
@@ -330,8 +330,16 @@ SevExit:
 pop   eax
 mov   esp, 0
 
+SevExit:
 OneTimeCallRet CheckSevFeatures
 
+SevClearVcHandlerAndStack:
+; Clear exception handlers and stack
+mov   eax, ADDR_OF(IdtrClear)
+lidt  [cs:eax]
+mov   esp, 0
+OneTimeCallRet SevClearVcHandlerAndStack
+
 ; Start of #VC exception handling routines
 ;
 
diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
index b922c845f297..29ce155eed8d 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
@@ -254,6 +254,7 @@ SevInit:
 CreatePageTables4Level edx
 ; Clear the C-bit from the GHCB page if the SEV-ES is enabled.
 OneTimeCall   SevClearPageEncMaskForGhcbPage
+OneTimeCall   SevClearVcHandlerAndStack
 jmp SetCr3
 
 TdxBspInit:
diff --git a/OvmfPkg/ResetVector/Main.asm b/OvmfPkg/ResetVector/Main.asm
index 46cfa87c4c0a..88b25db3bc9e 100644
--- a/OvmfPkg/ResetVector/Main.asm
+++ b/OvmfPkg/ResetVector/Main.asm
@@ -80,7 +80,11 @@ SearchBfv:
 ; Set the OVMF/SEV work area as appropriate.
 ;
 OneTimeCall CheckSevFeatures
+cmp byte[WORK_AREA_GUEST_TYPE], 1
+jnz NoSevIa32
+OneTimeCall SevClearVcHandlerAndStack
 
+NoSevIa32:
 ;
 ; Restore initial EAX value into the EAX register
 ;
-- 
2.44.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116221): https://edk2.groups.io/g/devel/message/116221
Mute This Topic: https://groups.io/mt/104660115/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 07/10] OvmfPkg/ResetVector: print post codes for 4/5 level paging

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Laszlo Ersek 
---
 OvmfPkg/ResetVector/Ia32/PageTables64.asm | 8 
 1 file changed, 8 insertions(+)

diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
index 2d7fd523e4b1..e15945da0476 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
@@ -69,6 +69,10 @@ BITS32
 ; Argument: upper 32 bits of the page table entries
 ;
 %macro CreatePageTables4Level 1
+
+; indicate 4-level paging
+debugShowPostCode 0x41
+
 ;
 ; Top level Page Directory Pointers (1 * 512GB entry)
 ;
@@ -153,6 +157,10 @@ BITS32
 ; level 3 directory.
 ;
 %macro CreatePageTables5Level 1
+
+; indicate 5-level paging
+debugShowPostCode 0x51
+
 ; level 5
 mov dword[PT_ADDR (0)], PT_ADDR (0x1000) + PAGE_PDE_DIRECTORY_ATTR
 mov dword[PT_ADDR (4)], %1
-- 
2.44.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116219): https://edk2.groups.io/g/devel/message/116219
Mute This Topic: https://groups.io/mt/104660113/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 06/10] OvmfPkg/ResetVector: add 5-level paging support

[Gerd Hoffmann]

Add macros to check for 5-level paging and gigabyte page support.
Enable 5-level paging for the non-confidential-computing case.

Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/ResetVector/ResetVector.inf   |   1 +
 OvmfPkg/ResetVector/Ia32/PageTables64.asm | 100 ++
 OvmfPkg/ResetVector/ResetVector.nasmb |   1 +
 3 files changed, 102 insertions(+)

diff --git a/OvmfPkg/ResetVector/ResetVector.inf 
b/OvmfPkg/ResetVector/ResetVector.inf
index a4154ca90c28..65f71b05a02e 100644
--- a/OvmfPkg/ResetVector/ResetVector.inf
+++ b/OvmfPkg/ResetVector/ResetVector.inf
@@ -64,3 +64,4 @@ [FixedPcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsSize
+  gEfiMdeModulePkgTokenSpaceGuid.PcdUse5LevelPageTable
diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
index 84a7b4efc019..2d7fd523e4b1 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
@@ -101,6 +101,97 @@ BITS32
 loop.pageTableEntriesLoop4Level
 %endmacro
 
+;
+; Check whenever 5-level paging can be used
+;
+; Argument: jump label for 4-level paging
+;
+%macro Check5LevelPaging 1
+; check for cpuid leaf 0x07
+mov eax, 0x00
+cpuid
+cmp eax, 0x07
+jb  %1
+
+; check for la57 (aka 5-level paging)
+mov eax, 0x07
+mov ecx, 0x00
+cpuid
+bt  ecx, 16
+jnc %1
+
+; check for cpuid leaf 0x8001
+mov eax, 0x8000
+cpuid
+cmp eax, 0x8001
+jb  %1
+
+; check for 1g pages
+mov eax, 0x8001
+cpuid
+bt  edx, 26
+jnc %1
+%endmacro
+
+;
+; Create page tables for 5-level paging with gigabyte pages
+;
+; Argument: upper 32 bits of the page table entries
+;
+; We have 6 pages available for the early page tables,
+; we use four of them:
+;PT_ADDR(0)  - level 5 directory
+;PT_ADDR(0x1000) - level 4 directory
+;PT_ADDR(0x2000) - level 2 directory (0 -> 1GB)
+;PT_ADDR(0x3000) - level 3 directory
+;
+; The level 2 directory for the first gigabyte has the same
+; physical address in both 4-level and 5-level paging mode,
+; SevClearPageEncMaskForGhcbPage depends on this.
+;
+; The 1 GB -> 4 GB range is mapped using 1G pages in the
+; level 3 directory.
+;
+%macro CreatePageTables5Level 1
+; level 5
+mov dword[PT_ADDR (0)], PT_ADDR (0x1000) + PAGE_PDE_DIRECTORY_ATTR
+mov dword[PT_ADDR (4)], %1
+
+; level 4
+mov dword[PT_ADDR (0x1000)], PT_ADDR (0x3000) + PAGE_PDE_DIRECTORY_ATTR
+mov dword[PT_ADDR (0x1004)], %1
+
+; level 3 (1x -> level 2, 3x 1GB)
+mov dword[PT_ADDR (0x3000)], PT_ADDR (0x2000) + PAGE_PDE_DIRECTORY_ATTR
+mov dword[PT_ADDR (0x3004)], %1
+mov dword[PT_ADDR (0x3008)], (1 << 30) + PAGE_PDE_LARGEPAGE_ATTR
+mov dword[PT_ADDR (0x300c)], %1
+mov dword[PT_ADDR (0x3010)], (2 << 30) + PAGE_PDE_LARGEPAGE_ATTR
+mov dword[PT_ADDR (0x3014)], %1
+mov dword[PT_ADDR (0x3018)], (3 << 30) + PAGE_PDE_LARGEPAGE_ATTR
+mov dword[PT_ADDR (0x301c)], %1
+
+;
+; level 2 (512 * 2MB entries => 1GB)
+;
+mov ecx, 0x200
+.pageTableEntriesLoop5Level:
+mov eax, ecx
+dec eax
+shl eax, 21
+add eax, PAGE_PDE_LARGEPAGE_ATTR
+mov dword[ecx * 8 + PT_ADDR (0x2000 - 8)], eax
+mov dword[(ecx * 8 + PT_ADDR (0x2000 - 8)) + 4], %1
+loop.pageTableEntriesLoop5Level
+%endmacro
+
+%macro Enable5LevelPaging 0
+; set la57 bit in cr4
+mov eax, cr4
+bts eax, 12
+mov cr4, eax
+%endmacro
+
 ;
 ; Modified:  EAX, EBX, ECX, EDX
 ;
@@ -125,6 +216,13 @@ SetCr3ForPageTables64:
 ; normal (non-CoCo) workflow
 ;
 ClearOvmfPageTables
+%if PG_5_LEVEL
+Check5LevelPaging Paging4Level
+CreatePageTables5Level 0
+Enable5LevelPaging
+jmp SetCr3
+Paging4Level:
+%endif
 CreatePageTables4Level 0
 jmp SetCr3
 
@@ -152,6 +250,8 @@ TdxBspInit:
 jmp SetCr3
 
 SetCr3:
+;
+; common workflow
 ;
 ; Set CR3 now that the paging structures are available
 ;
diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb 
b/OvmfPkg/ResetVector/ResetVector.nasmb
index 366a70fb9992..2bd80149e58b 100644
--- a/OvmfPkg/ResetVector/ResetVector.nasmb
+++ b/OvmfPkg/ResetVector/ResetVector.nasmb
@@ -53,6 +53,7 @@
 
 %define WORK_AREA_GUEST_TYPE  (FixedPcdGet32 (PcdOvmfWorkAreaBase))
 %define PT_ADDR(Offset)   (FixedPcdGet32 
(PcdOvmfSecPageTablesBase) + (Offset))
+%define PG_5_LEVEL(FixedPcdGetBool (PcdUse5LevelPageTable))
 
 %define GHCB_PT_ADDR  (FixedPcdGet32 
(PcdOvmfSecGhcbPageTableBase))
 %define GHCB_BASE (FixedPcdGet32 (PcdOvmfSecGhcbBase))
-- 
2.44.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/

[edk2-devel] [PATCH v2 05/10] OvmfPkg/ResetVector: split SEV and non-CoCo workflows

[Gerd Hoffmann]

Use separate control flows for SEV and non-CoCo cases.

SevClearPageEncMaskForGhcbPage and GetSevCBitMaskAbove31 will now only
be called when running in SEV mode, so the SEV check in these functions
is not needed any more.

No functional change.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Laszlo Ersek 
---
 OvmfPkg/ResetVector/Ia32/AmdSev.asm   | 14 +-
 OvmfPkg/ResetVector/Ia32/PageTables64.asm | 17 ++---
 2 files changed, 15 insertions(+), 16 deletions(-)

diff --git a/OvmfPkg/ResetVector/Ia32/AmdSev.asm 
b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
index 043c88a7abbe..23e4c5ebbe92 100644
--- a/OvmfPkg/ResetVector/Ia32/AmdSev.asm
+++ b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
@@ -154,10 +154,6 @@ SevEsUnexpectedRespTerminate:
 
 ; If SEV-ES is enabled then initialize and make the GHCB page shared
 SevClearPageEncMaskForGhcbPage:
-; Check if SEV is enabled
-cmp   byte[WORK_AREA_GUEST_TYPE], 1
-jnz   SevClearPageEncMaskForGhcbPageExit
-
 ; Check if SEV-ES is enabled
 mov   ecx, 1
 bt[SEV_ES_WORK_AREA_STATUS_MSR], ecx
@@ -195,20 +191,12 @@ pageTableEntries4kLoop:
 SevClearPageEncMaskForGhcbPageExit:
 OneTimeCallRet SevClearPageEncMaskForGhcbPage
 
-; Check if SEV is enabled, and get the C-bit mask above 31.
+; Get the C-bit mask above 31.
 ; Modified: EDX
 ;
 ; The value is returned in the EDX
 GetSevCBitMaskAbove31:
-xor   edx, edx
-
-; Check if SEV is enabled
-cmp   byte[WORK_AREA_GUEST_TYPE], 1
-jnz   GetSevCBitMaskAbove31Exit
-
 mov   edx, dword[SEV_ES_WORK_AREA_ENC_MASK + 4]
-
-GetSevCBitMaskAbove31Exit:
 OneTimeCallRet GetSevCBitMaskAbove31
 
 %endif
diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
index 166e80293c89..84a7b4efc019 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
@@ -118,15 +118,26 @@ SetCr3ForPageTables64:
 
 ; Check whether the SEV is active and populate the SevEsWorkArea
 OneTimeCall   CheckSevFeatures
+cmp   byte[WORK_AREA_GUEST_TYPE], 1
+jzSevInit
 
+;
+; normal (non-CoCo) workflow
+;
+ClearOvmfPageTables
+CreatePageTables4Level 0
+jmp SetCr3
+
+SevInit:
+;
+; SEV workflow
+;
+ClearOvmfPageTables
 ; If SEV is enabled, the C-bit position is always above 31.
 ; The mask will be saved in the EDX and applied during the
 ; the page table build below.
 OneTimeCall   GetSevCBitMaskAbove31
-
-ClearOvmfPageTables
 CreatePageTables4Level edx
-
 ; Clear the C-bit from the GHCB page if the SEV-ES is enabled.
 OneTimeCall   SevClearPageEncMaskForGhcbPage
 jmp SetCr3
-- 
2.44.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116218): https://edk2.groups.io/g/devel/message/116218
Mute This Topic: https://groups.io/mt/104660112/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 04/10] OvmfPkg/ResetVector: split TDX BSP workflow

[Gerd Hoffmann]

Create a separate control flow for TDX BSP.

TdxPostBuildPageTables will now only be called when running in TDX
mode, so the TDX check in that function is not needed any more.

No functional change.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Laszlo Ersek 
---
 OvmfPkg/ResetVector/Ia32/IntelTdx.asm |  4 
 OvmfPkg/ResetVector/Ia32/PageTables64.asm | 15 ++-
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/OvmfPkg/ResetVector/Ia32/IntelTdx.asm 
b/OvmfPkg/ResetVector/Ia32/IntelTdx.asm
index 06794baef81d..c6b86019dfb9 100644
--- a/OvmfPkg/ResetVector/Ia32/IntelTdx.asm
+++ b/OvmfPkg/ResetVector/Ia32/IntelTdx.asm
@@ -197,11 +197,7 @@ NotTdx:
 ; Set byte[TDX_WORK_AREA_PGTBL_READY] to 1
 ;
 TdxPostBuildPageTables:
-cmp byte[WORK_AREA_GUEST_TYPE], VM_GUEST_TDX
-jne ExitTdxPostBuildPageTables
 mov byte[TDX_WORK_AREA_PGTBL_READY], 1
-
-ExitTdxPostBuildPageTables:
 OneTimeCallRet TdxPostBuildPageTables
 
 ;
diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
index 14cc2c33aa3d..166e80293c89 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
@@ -112,7 +112,7 @@ SetCr3ForPageTables64:
 ; is set.
 OneTimeCall   CheckTdxFeaturesBeforeBuildPagetables
 cmp   eax, TDX_BSP
-jeClearOvmfPageTables
+jeTdxBspInit
 cmp   eax, TDX_AP
 jeSetCr3
 
@@ -124,16 +124,21 @@ SetCr3ForPageTables64:
 ; the page table build below.
 OneTimeCall   GetSevCBitMaskAbove31
 
-ClearOvmfPageTables:
 ClearOvmfPageTables
 CreatePageTables4Level edx
 
 ; Clear the C-bit from the GHCB page if the SEV-ES is enabled.
 OneTimeCall   SevClearPageEncMaskForGhcbPage
+jmp SetCr3
 
-; TDX will do some PostBuildPages task, such as setting
-; byte[TDX_WORK_AREA_PGTBL_READY].
-OneTimeCall   TdxPostBuildPageTables
+TdxBspInit:
+;
+; TDX BSP workflow
+;
+ClearOvmfPageTables
+CreatePageTables4Level 0
+OneTimeCall TdxPostBuildPageTables
+jmp SetCr3
 
 SetCr3:
 ;
-- 
2.44.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116217): https://edk2.groups.io/g/devel/message/116217
Mute This Topic: https://groups.io/mt/104660111/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 00/10] OvmfPkg/ResetVector: cleanup and add 5-level paging support.

[Gerd Hoffmann]

So I ran with the suggestion by Laszlo to move the page table setup into
macros and untangle the non-CoCo / TDX / SEV code paths.  The first five
patches of the series are doing that (without functional changes).

Support for 5-level paging is added by the following five patches.  This
way it is indeed easier to understand.  Additional bonus is that the
patches can be splitted into smaller pieces and 5-level paging for the
three cases (non-CoCo / TDX / SEC) can be enabled independently.

The SEV patches (#9 + #10) are included here for completeness, but it is
probably a good idea to merge them only after 5-level paging support was
added to BaseMemEncryptSevLib.  This way we can turn on 5-level paging
support without breaking SEV.

v2 changes:
 - remove SetCr3La57 label, use Enable5LevelPaging macro instead.
 - turn GetSevCBitMaskAbove31 into a macro.
 - comment fixes.

Gerd Hoffmann (10):
  OvmfPkg/ResetVector: improve page table flag names
  OvmfPkg/ResetVector: add ClearOvmfPageTables macro
  OvmfPkg/ResetVector: add CreatePageTables4Level macro
  OvmfPkg/ResetVector: split TDX BSP workflow
  OvmfPkg/ResetVector: split SEV and non-CoCo workflows
  OvmfPkg/ResetVector: add 5-level paging support
  OvmfPkg/ResetVector: print post codes for 4/5 level paging
  OvmfPkg/ResetVector: wire up 5-level paging for TDX
  OvmfPkg/ResetVector: leave SEV VC handler installed longer
  OvmfPkg/ResetVector: wire up 5-level paging for SEV

 OvmfPkg/ResetVector/ResetVector.inf   |   1 +
 OvmfPkg/ResetVector/Ia32/AmdSev.asm   |  40 ++-
 OvmfPkg/ResetVector/Ia32/IntelTdx.asm |  17 +-
 OvmfPkg/ResetVector/Ia32/PageTables64.asm | 299 +-
 OvmfPkg/ResetVector/Main.asm  |   4 +
 OvmfPkg/ResetVector/ResetVector.nasmb |   5 +-
 6 files changed, 272 insertions(+), 94 deletions(-)

-- 
2.44.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116215): https://edk2.groups.io/g/devel/message/116215
Mute This Topic: https://groups.io/mt/104660109/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 02/10] OvmfPkg/ResetVector: add ClearOvmfPageTables macro

[Gerd Hoffmann]

Move code to clear the page tables to a nasm macro.
No functional change.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Laszlo Ersek 
---
 OvmfPkg/ResetVector/Ia32/PageTables64.asm | 35 ---
 1 file changed, 19 insertions(+), 16 deletions(-)

diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
index 6fec6f2beeea..378ba2feeb4f 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
@@ -45,6 +45,24 @@ BITS32
 %define TDX_BSP 1
 %define TDX_AP  2
 
+;
+; For OVMF, build some initial page tables at
+; PcdOvmfSecPageTablesBase - (PcdOvmfSecPageTablesBase + 0x6000).
+;
+; This range should match with PcdOvmfSecPageTablesSize which is
+; declared in the FDF files.
+;
+; At the end of PEI, the pages tables will be rebuilt into a
+; more permanent location by DxeIpl.
+;
+%macro ClearOvmfPageTables 0
+mov ecx, 6 * 0x1000 / 4
+xor eax, eax
+.clearPageTablesMemoryLoop:
+mov dword[ecx * 4 + PT_ADDR (0) - 4], eax
+loop.clearPageTablesMemoryLoop
+%endmacro
+
 ;
 ; Modified:  EAX, EBX, ECX, EDX
 ;
@@ -69,22 +87,7 @@ SetCr3ForPageTables64:
 OneTimeCall   GetSevCBitMaskAbove31
 
 ClearOvmfPageTables:
-;
-; For OVMF, build some initial page tables at
-; PcdOvmfSecPageTablesBase - (PcdOvmfSecPageTablesBase + 0x6000).
-;
-; This range should match with PcdOvmfSecPageTablesSize which is
-; declared in the FDF files.
-;
-; At the end of PEI, the pages tables will be rebuilt into a
-; more permanent location by DxeIpl.
-;
-
-mov ecx, 6 * 0x1000 / 4
-xor eax, eax
-clearPageTablesMemoryLoop:
-mov dword[ecx * 4 + PT_ADDR (0) - 4], eax
-loopclearPageTablesMemoryLoop
+ClearOvmfPageTables
 
 ;
 ; Top level Page Directory Pointers (1 * 512GB entry)
-- 
2.44.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116216): https://edk2.groups.io/g/devel/message/116216
Mute This Topic: https://groups.io/mt/104660110/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 03/10] OvmfPkg/ResetVector: add CreatePageTables4Level macro

[Gerd Hoffmann]

Move code to create 4-level page tables to a nasm macro.
No functional change.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Laszlo Ersek 
---
 OvmfPkg/ResetVector/Ia32/PageTables64.asm | 70 +--
 1 file changed, 39 insertions(+), 31 deletions(-)

diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
index 378ba2feeb4f..14cc2c33aa3d 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
@@ -63,6 +63,44 @@ BITS32
 loop.clearPageTablesMemoryLoop
 %endmacro
 
+;
+; Create page tables for 4-level paging
+;
+; Argument: upper 32 bits of the page table entries
+;
+%macro CreatePageTables4Level 1
+;
+; Top level Page Directory Pointers (1 * 512GB entry)
+;
+mov dword[PT_ADDR (0)], PT_ADDR (0x1000) + PAGE_PDE_DIRECTORY_ATTR
+mov dword[PT_ADDR (4)], %1
+
+;
+; Next level Page Directory Pointers (4 * 1GB entries => 4GB)
+;
+mov dword[PT_ADDR (0x1000)], PT_ADDR (0x2000) + PAGE_PDE_DIRECTORY_ATTR
+mov dword[PT_ADDR (0x1004)], %1
+mov dword[PT_ADDR (0x1008)], PT_ADDR (0x3000) + PAGE_PDE_DIRECTORY_ATTR
+mov dword[PT_ADDR (0x100C)], %1
+mov dword[PT_ADDR (0x1010)], PT_ADDR (0x4000) + PAGE_PDE_DIRECTORY_ATTR
+mov dword[PT_ADDR (0x1014)], %1
+mov dword[PT_ADDR (0x1018)], PT_ADDR (0x5000) + PAGE_PDE_DIRECTORY_ATTR
+mov dword[PT_ADDR (0x101C)], %1
+
+;
+; Page Table Entries (2048 * 2MB entries => 4GB)
+;
+mov ecx, 0x800
+.pageTableEntriesLoop4Level:
+mov eax, ecx
+dec eax
+shl eax, 21
+add eax, PAGE_PDE_LARGEPAGE_ATTR
+mov dword[ecx * 8 + PT_ADDR (0x2000 - 8)], eax
+mov dword[(ecx * 8 + PT_ADDR (0x2000 - 8)) + 4], %1
+loop.pageTableEntriesLoop4Level
+%endmacro
+
 ;
 ; Modified:  EAX, EBX, ECX, EDX
 ;
@@ -88,37 +126,7 @@ SetCr3ForPageTables64:
 
 ClearOvmfPageTables:
 ClearOvmfPageTables
-
-;
-; Top level Page Directory Pointers (1 * 512GB entry)
-;
-mov dword[PT_ADDR (0)], PT_ADDR (0x1000) + PAGE_PDE_DIRECTORY_ATTR
-mov dword[PT_ADDR (4)], edx
-
-;
-; Next level Page Directory Pointers (4 * 1GB entries => 4GB)
-;
-mov dword[PT_ADDR (0x1000)], PT_ADDR (0x2000) + PAGE_PDE_DIRECTORY_ATTR
-mov dword[PT_ADDR (0x1004)], edx
-mov dword[PT_ADDR (0x1008)], PT_ADDR (0x3000) + PAGE_PDE_DIRECTORY_ATTR
-mov dword[PT_ADDR (0x100C)], edx
-mov dword[PT_ADDR (0x1010)], PT_ADDR (0x4000) + PAGE_PDE_DIRECTORY_ATTR
-mov dword[PT_ADDR (0x1014)], edx
-mov dword[PT_ADDR (0x1018)], PT_ADDR (0x5000) + PAGE_PDE_DIRECTORY_ATTR
-mov dword[PT_ADDR (0x101C)], edx
-
-;
-; Page Table Entries (2048 * 2MB entries => 4GB)
-;
-mov ecx, 0x800
-pageTableEntriesLoop:
-mov eax, ecx
-dec eax
-shl eax, 21
-add eax, PAGE_PDE_LARGEPAGE_ATTR
-mov [ecx * 8 + PT_ADDR (0x2000 - 8)], eax
-mov [(ecx * 8 + PT_ADDR (0x2000 - 8)) + 4], edx
-looppageTableEntriesLoop
+CreatePageTables4Level edx
 
 ; Clear the C-bit from the GHCB page if the SEV-ES is enabled.
 OneTimeCall   SevClearPageEncMaskForGhcbPage
-- 
2.44.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116214): https://edk2.groups.io/g/devel/message/116214
Mute This Topic: https://groups.io/mt/104660108/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 01/10] OvmfPkg/ResetVector: improve page table flag names

[Gerd Hoffmann]

Add comments, rename some of the PAGE_* flags and combined attributes.
Specifically use "LARGEPAGE" instead of "2M" because that bit is used
for both 2M and 1G large pages.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Laszlo Ersek 
---
 OvmfPkg/ResetVector/Ia32/PageTables64.asm | 39 +--
 1 file changed, 22 insertions(+), 17 deletions(-)

diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
index 317cad430f29..6fec6f2beeea 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
@@ -10,6 +10,7 @@
 
 BITS32
 
+; common for all levels
 %define PAGE_PRESENT0x01
 %define PAGE_READ_WRITE 0x02
 %define PAGE_USER_SUPERVISOR0x04
@@ -17,25 +18,29 @@ BITS32
 %define PAGE_CACHE_DISABLE 0x010
 %define PAGE_ACCESSED  0x020
 %define PAGE_DIRTY 0x040
-%define PAGE_PAT   0x080
 %define PAGE_GLOBAL   0x0100
-%define PAGE_2M_MBO0x080
-%define PAGE_2M_PAT  0x01000
+
+; page table entries (level 1)
+%define PAGE_PTE_PAT   0x080
+
+; page directory entries (level 2+)
+%define PAGE_PDE_LARGEPAGE 0x080
+%define PAGE_PDE_PAT 0x01000
 
 %define PAGE_4K_PDE_ATTR (PAGE_ACCESSED + \
   PAGE_DIRTY + \
   PAGE_READ_WRITE + \
   PAGE_PRESENT)
 
-%define PAGE_2M_PDE_ATTR (PAGE_2M_MBO + \
-  PAGE_ACCESSED + \
-  PAGE_DIRTY + \
-  PAGE_READ_WRITE + \
-  PAGE_PRESENT)
+%define PAGE_PDE_LARGEPAGE_ATTR (PAGE_PDE_LARGEPAGE + \
+ PAGE_ACCESSED + \
+ PAGE_DIRTY + \
+ PAGE_READ_WRITE + \
+ PAGE_PRESENT)
 
-%define PAGE_PDP_ATTR (PAGE_ACCESSED + \
-   PAGE_READ_WRITE + \
-   PAGE_PRESENT)
+%define PAGE_PDE_DIRECTORY_ATTR (PAGE_ACCESSED + \
+ PAGE_READ_WRITE + \
+ PAGE_PRESENT)
 
 %define TDX_BSP 1
 %define TDX_AP  2
@@ -84,19 +89,19 @@ clearPageTablesMemoryLoop:
 ;
 ; Top level Page Directory Pointers (1 * 512GB entry)
 ;
-mov dword[PT_ADDR (0)], PT_ADDR (0x1000) + PAGE_PDP_ATTR
+mov dword[PT_ADDR (0)], PT_ADDR (0x1000) + PAGE_PDE_DIRECTORY_ATTR
 mov dword[PT_ADDR (4)], edx
 
 ;
 ; Next level Page Directory Pointers (4 * 1GB entries => 4GB)
 ;
-mov dword[PT_ADDR (0x1000)], PT_ADDR (0x2000) + PAGE_PDP_ATTR
+mov dword[PT_ADDR (0x1000)], PT_ADDR (0x2000) + PAGE_PDE_DIRECTORY_ATTR
 mov dword[PT_ADDR (0x1004)], edx
-mov dword[PT_ADDR (0x1008)], PT_ADDR (0x3000) + PAGE_PDP_ATTR
+mov dword[PT_ADDR (0x1008)], PT_ADDR (0x3000) + PAGE_PDE_DIRECTORY_ATTR
 mov dword[PT_ADDR (0x100C)], edx
-mov dword[PT_ADDR (0x1010)], PT_ADDR (0x4000) + PAGE_PDP_ATTR
+mov dword[PT_ADDR (0x1010)], PT_ADDR (0x4000) + PAGE_PDE_DIRECTORY_ATTR
 mov dword[PT_ADDR (0x1014)], edx
-mov dword[PT_ADDR (0x1018)], PT_ADDR (0x5000) + PAGE_PDP_ATTR
+mov dword[PT_ADDR (0x1018)], PT_ADDR (0x5000) + PAGE_PDE_DIRECTORY_ATTR
 mov dword[PT_ADDR (0x101C)], edx
 
 ;
@@ -107,7 +112,7 @@ pageTableEntriesLoop:
 mov eax, ecx
 dec eax
 shl eax, 21
-add eax, PAGE_2M_PDE_ATTR
+add eax, PAGE_PDE_LARGEPAGE_ATTR
 mov [ecx * 8 + PT_ADDR (0x2000 - 8)], eax
 mov [(ecx * 8 + PT_ADDR (0x2000 - 8)) + 4], edx
 looppageTableEntriesLoop
-- 
2.44.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116213): https://edk2.groups.io/g/devel/message/116213
Mute This Topic: https://groups.io/mt/104660107/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1] MdeModulePkg/Core/Pei: Improve the copy performance

[Li, Zhihao]

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4697

EvacuateTempRam function will copy the temporary memory context to the rebased
pages and the raw pages. Migrations of rebased PEIMs is from cache to memory,
while raw PEIMs is from memory to memory. So the migrations of raw PEIMs
is slower than rebased PEIMs. Experimental data indicates that changing the 
source
address of raw PEIMs migration will improve performance by 35%.

Cc: Liming Gao 
Signed-off-by: Zhihao Li 
---
 MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c 
b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
index 4cd8c843cd..ca37bde482 100644
--- a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
+++ b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
@@ -1,7 +1,7 @@
 /** @file
   EFI PEI Core dispatch services
 
-Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2024, Intel Corporation. All rights reserved.
 (C) Copyright 2016 Hewlett Packard Enterprise Development LP
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -1305,7 +1305,7 @@ EvacuateTempRam (
 );
 ASSERT_EFI_ERROR (Status);
 RawDataFvHeader = (EFI_FIRMWARE_VOLUME_HEADER *)(UINTN)FvHeaderAddress;
-CopyMem (RawDataFvHeader, MigratedFvHeader, (UINTN)FvHeader->FvLength);
+CopyMem (RawDataFvHeader, FvHeader, (UINTN)FvHeader->FvLength);
 MigratedFvInfo.FvDataBase = (UINT32)(UINTN)RawDataFvHeader;
   }
 
-- 
2.26.2.windows.1

Re: [edk2-devel] [PATCH v1 1/1] MdeModulePkg/AcpiTableDxe: Select ACPI memory type by PCD

[Ni, Ray]

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 (&TempPrivateData, 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),
>   &PageAddress
>   );
>} else {
>  Status = gBS->AllocatePool (
> -EfiACPIReclaimMemory,
> +AcpiAllocateMemoryType,
>  TotalSize,
>  (VOID **)&Pointer
>  );
> @@ -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 **)&CurrentTableList->Table
>  );
> @@ -596,7 +610,7 @@ AddTableToList (
>  //
>  Status = gBS->AllocatePages (
>  mAcpiTableAllocType,
> -EfiACPIReclaimMemory,
> +AcpiAllocateMemoryType,
>  EFI_SIZE_TO_PAGES (CurrentTableList->TableSize),
>  &AllocPhysAddress
>  );
> @@ -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 = EfiACPIReclaimM

[edk2-devel] [PATCH v1 1/1] MdeModulePkg/AcpiTableDxe: Select ACPI memory type by PCD

[Aaron Li]

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 (&TempPrivateData, 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),
  &PageAddress
  );
   } else {
 Status = gBS->AllocatePool (
-EfiACPIReclaimMemory,
+AcpiAllocateMemoryType,
 TotalSize,
 (VOID **)&Pointer
 );
@@ -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 **)&CurrentTableList->Table
 );
@@ -596,7 +610,7 @@ AddTableToList (
 //
 Status = gBS->AllocatePages (
 mAcpiTableAllocType,
-EfiACPIReclaimMemory,
+AcpiAllocateMemoryType,
 EFI_SIZE_TO_PAGES (CurrentTableList->TableSize),
 &AllocPhysAddress
 );
@@ -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) {
 PageAddress = 0x;
 Status  = gBS->AllocatePages (
  mAcpiTableAllocType,
- EfiACPIReclaimMemory,
+ AcpiAllocateMemoryType,
  EFI_SIZE_TO_PAGES (RsdpTableSize),
  &PageAddress
  );
   } else {
 Status = gBS->AllocatePool (
-EfiACPIReclaimMemory,
+AcpiAllocateMemoryType,

Re: [edk2-devel] [PATCH v3 4/4] StandaloneMmPkg: Disallow unregister MMI handler in other MMI handler

[Ni, Ray]

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 (&MmiHandler->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

[Ni, Ray]

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 (&SmiHandler->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

[Ni, Ray]

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 ((INTN)gEfiCurrentTpl == HighBitSet64
> (mInterruptedTplMask));
> > +  mInterruptedTplMask &= ~(UINTN)(1 << gEfiCurrentTpl);
> > +}
> >}
> 
> Ok, now I understand what's going on and it's indeed the same logic as
> NestedInterruptTplLib, with DisableInterruptsOnIret() replaced by
> skipping CoreSetInterruptState(TRUE). It's similar to what I proposed
> elsew

[edk2-devel] [PATCH v3 4/4] StandaloneMmPkg: Disallow unregister MMI handler in other MMI handler

[Zhiguang Liu]

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 (&MmiHandler->Link);
-- 
2.31.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116206): https://edk2.groups.io/g/devel/message/116206
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]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3 3/4] StandaloneMmPkg: Support to unregister MMI handler inside MMI handler

[Zhiguang Liu]

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 
Reviewed-by: Ray Ni 
Reviewed-by: 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 = &MmiEntry->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,
-- 
2.31.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116205): https://edk2.groups.io/g/devel/message/116205
Mute This Topic: https://groups.io/mt/104657668/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3 2/4] MdeModulePkg/SMM: Disallow unregister SMI handler in other SMI handler

[Zhiguang Liu]

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 (&SmiHandler->Link);
-- 
2.31.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116204): https://edk2.groups.io/g/devel/message/116204
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]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3 1/4] MdeModulePkg/SMM: Support to unregister SMI handler inside SMI handler

[Zhiguang Liu]

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 = &SmiEntry->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 (#116203): https://edk2.groups.io/g/devel/message/116203
Mute This Topic: https://groups.io/mt/104657665/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3 0/4] Support to unregister SMI handler inside SMI handler

[Zhiguang Liu]

This patch set is to support to unregister SMI handler inside SMI handler,
also add check to not allow unregister SMI handler in other SMI handler.
This patch set also have the same logic in StandaloneMmPkg.
Because no change on the first patch, I kept the R-B for it.

V3:
Minor change on patch #2 and patch #4:
gCurrentSmiHandler -> mCurrentSmiHandler
change ASSERT to return EFI_INVALID_PARAMETER

Zhiguang Liu (4):
  MdeModulePkg/SMM: Support to unregister SMI handler inside SMI handler
  MdeModulePkg/SMM: Disallow unregister SMI handler in other SMI handler
  StandaloneMmPkg: Support to unregister MMI handler inside MMI handler
  StandaloneMmPkg: Disallow unregister MMI handler in other MMI handler

 MdeModulePkg/Core/PiSmmCore/Smi.c | 37 ++---
 StandaloneMmPkg/Core/Mmi.c| 39 +++
 2 files changed, 57 insertions(+), 19 deletions(-)

-- 
2.31.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116202): https://edk2.groups.io/g/devel/message/116202
Mute This Topic: https://groups.io/mt/104657663/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH] BaseTools: PcdValueInit enhancement

[Yuting Yang]

Enhance PcdValueInit for storage saving

Cc: Rebecca Cran rebe...@bsdio.com
Cc: Liming Gao gaolim...@byosoft.com.cn
Cc: Bob Feng bob.c.f...@intel.com
Signed-off-by: Yuting Yang 
---
 .../Source/Python/Workspace/DscBuildData.py   | 43 ++-
 1 file changed, 33 insertions(+), 10 deletions(-)

diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py 
b/BaseTools/Source/Python/Workspace/DscBuildData.py
index 5df184f9c8..e83188f4b3 100644
--- a/BaseTools/Source/Python/Workspace/DscBuildData.py
+++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
@@ -1820,6 +1820,7 @@ class DscBuildData(PlatformBuildClassObject):
 def GenerateSizeFunction(self, Pcd):
 CApp = "// Default Value in Dec \n"
 CApp = CApp + "void Cal_%s_%s_Size(UINT32 *Size){\n" % 
(Pcd.TokenSpaceGuidCName, Pcd.TokenCName)
+CAppList = []
 
 if Pcd.IsArray() and Pcd.Capacity[-1] != "-1":
 CApp += "  *Size = (sizeof (%s) > *Size ? sizeof (%s) : *Size);\n" 
% (Pcd.DatumType,Pcd.DatumType)
@@ -1869,7 +1870,8 @@ class DscBuildData(PlatformBuildClassObject):
 (".".join((Pcd.TokenSpaceGuidCName, 
Pcd.TokenCName, FieldName.strip('.'))), FieldList[FieldName.strip(".")][1], 
FieldList[FieldName.strip(".")][2]))
 Value, ValueSize = ParseFieldValue(Value)
 if not Pcd.IsArray():
-CApp = CApp + '  __FLEXIBLE_SIZE(*Size, %s, %s, %d / 
__ARRAY_ELEMENT_SIZE(%s, %s) + ((%d %% __ARRAY_ELEMENT_SIZE(%s, %s)) ? 1 : 0)); 
 // From %s Line %d Value %s \n' % (Pcd.DatumType, FieldName.strip("."), 
ValueSize, Pcd.DatumType, FieldName.strip("."), ValueSize, Pcd.DatumType, 
FieldName.strip("."), FieldList[FieldName.strip(".")][1], 
FieldList[FieldName.strip(".")][2], FieldList[FieldName.strip(".")][0]);
+CAppInfo = '  __FLEXIBLE_SIZE(*Size, %s, %s, %d / 
__ARRAY_ELEMENT_SIZE(%s, %s) + ((%d %% __ARRAY_ELEMENT_SIZE(%s, %s)) ? 1 : 0)); 
 // From %s Line %d Value %s \n' % (Pcd.DatumType, FieldName.strip("."), 
ValueSize, Pcd.DatumType, FieldName.strip("."), ValueSize, Pcd.DatumType, 
FieldName.strip("."), FieldList[FieldName.strip(".")][1], 
FieldList[FieldName.strip(".")][2], FieldList[FieldName.strip(".")][0]);
+CAppList.append(CAppInfo.split(' //')[0])
 else:
 NewFieldName = ''
 FieldName_ori = FieldName.strip('.')
@@ -1880,7 +1882,8 @@ class DscBuildData(PlatformBuildClassObject):
 FieldName = NewFieldName + FieldName
 while '[' in FieldName and not Pcd.IsArray():
 FieldName = FieldName.rsplit('[', 1)[0]
-CApp = CApp + '  __FLEXIBLE_SIZE(*Size, %s, %s, %d); 
// From %s Line %d Value %s\n' % (Pcd.DatumType, FieldName.strip("."), 
Array_Index + 1, FieldList[FieldName_ori][1], FieldList[FieldName_ori][2], 
FieldList[FieldName_ori][0])
+CAppInfo = '  __FLEXIBLE_SIZE(*Size, %s, %s, %d); // 
From %s Line %d Value %s\n' % (Pcd.DatumType, FieldName.strip("."), Array_Index 
+ 1, FieldList[FieldName_ori][1], FieldList[FieldName_ori][2], 
FieldList[FieldName_ori][0])
+CAppList.append(CAppInfo.split(' //')[0])
 flexisbale_size_statement_cache = set()
 for skuname in Pcd.SkuOverrideValues:
 if skuname == TAB_COMMON:
@@ -1908,7 +1911,10 @@ class DscBuildData(PlatformBuildClassObject):
 
(".".join((Pcd.TokenSpaceGuidCName, Pcd.TokenCName, FieldName.strip('.'))), 
FieldList[FieldName.strip(".")][1], FieldList[FieldName.strip(".")][2]))
 Value, ValueSize = ParseFieldValue(Value)
 if not Pcd.IsArray():
-CApp = CApp + '  __FLEXIBLE_SIZE(*Size, 
%s, %s, %d / __ARRAY_ELEMENT_SIZE(%s, %s) + ((%d %% __ARRAY_ELEMENT_SIZE(%s, 
%s)) ? 1 : 0)); // From %s Line %d Value %s\n' % (Pcd.DatumType, 
FieldName.strip("."), ValueSize, Pcd.DatumType, FieldName.strip("."), 
ValueSize, Pcd.DatumType, FieldName.strip("."), 
FieldList[FieldName.strip(".")][1], FieldList[FieldName.strip(".")][2], 
FieldList[FieldName.strip(".")][0]);
+CAppInfo = '  __FLEXIBLE_SIZE(*Size, %s, 
%s, %d / __ARRAY_ELEMENT_SIZE(%s, %s) + ((%d %% __ARRAY_ELEMENT_SIZE(%s, %s)) ? 
1 : 0)); // From %s Line %d Value %s\n' % (Pcd.DatumType, FieldName.strip("."), 
ValueSize, Pcd.DatumType, FieldName.strip("."), ValueSize, Pcd.DatumType, 
FieldName.strip("."), FieldList[FieldName.strip(".")][1], 
FieldList[FieldName.strip(".")][2], FieldList[FieldName.strip(".")][0]);
+CAppInfoWithoutComment = CAppInfo.split(' 
//')[0]
+if CAppInfoWithoutComment not in CAppList:
+CAppList.append(CAppInfoWithoutComment)

[edk2-devel] [PATCH v3 3/3] OvmfPkg/RiscVVirt: Disable Svpbmt extension

[Tuan Phan]

Disable Svpbmt extension as QEMU not enables it in default config.

Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Cc: Sunil V L 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tuan Phan 
---
 OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc 
b/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
index 6bc7c90f31dc..b8338d2eb5f5 100644
--- a/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
+++ b/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
@@ -203,7 +203,7 @@
   gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
 
 [PcdsFixedAtBuild.common]
-  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0xFFFC
+  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0xFFF8
   gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength|100
   gEfiMdePkgTokenSpaceGuid.PcdMaximumAsciiStringLength|100
   gEfiMdePkgTokenSpaceGuid.PcdMaximumLinkedListLength|0
-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116199): https://edk2.groups.io/g/devel/message/116199
Mute This Topic: https://groups.io/mt/104656467/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3 2/3] UefiCpuPkg: RISC-V: MMU: Support Svpbmt extension

[Tuan Phan]

The GCD EFI_MEMORY_UC and EFI_MEMORY_WC memory attributes will be
supported when Svpbmt extension available.

Cc: Gerd Hoffmann 
Cc: Laszlo Ersek 
Cc: Rahul Kumar 
Cc: Ray Ni 
Signed-off-by: Tuan Phan 
---
 .../Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c | 101 +++---
 .../BaseRiscVMmuLib/BaseRiscVMmuLib.inf   |   1 +
 2 files changed, 88 insertions(+), 14 deletions(-)

diff --git a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c 
b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
index 826a1d32a1d4..f4419bb8f380 100644
--- a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
+++ b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
@@ -36,6 +36,11 @@
 #define PTE_PPN_SHIFT 10
 #define RISCV_MMU_PAGE_SHIFT  12
 
+#define RISCV_CPU_FEATURE_PBMT_BITMASK  BIT2
+#define PTE_PBMT_NC BIT61
+#define PTE_PBMT_IO BIT62
+#define PTE_PBMT_MASK   (PTE_PBMT_NC | PTE_PBMT_IO)
+
 STATIC UINTN  mModeSupport[] = { SATP_MODE_SV57, SATP_MODE_SV48, 
SATP_MODE_SV39, SATP_MODE_OFF };
 STATIC UINTN  mMaxRootTableLevel;
 STATIC UINTN  mBitPerLevel;
@@ -489,32 +494,89 @@ UpdateRegionMapping (
 /**
   Convert GCD attribute to RISC-V page attribute.
 
-  @param  GcdAttributes The GCD attribute.
+  @param  GcdAttributes   The GCD attribute.
+  @param  RiscVAttribtues The pointer of RISC-V page attribute.
 
-  @return   The RISC-V page attribute.
+  @retval EFI_INVALID_PARAMETER   The RiscVAttribtues is NULL or cache type 
mask not valid.
+  @retval EFI_SUCCESS The operation succesfully.
 
 **/
 STATIC
-UINTN
+EFI_STATUS
 GcdAttributeToPageAttribute (
-  IN UINTN  GcdAttributes
+  IN UINTN   GcdAttributes,
+  OUT UINTN  *RiscVAttributes
   )
 {
-  UINTN  RiscVAttributes;
+  UINT64   CacheTypeMask;
+  BOOLEAN  PmbtExtEnabled = (PcdGet64 (PcdRiscVFeatureOverride) & 
RISCV_CPU_FEATURE_PBMT_BITMASK) ? TRUE : FALSE;
 
-  RiscVAttributes = RISCV_PG_R | RISCV_PG_W | RISCV_PG_X;
+  if (!RiscVAttributes) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  *RiscVAttributes = RISCV_PG_R | RISCV_PG_W | RISCV_PG_X;
 
   // Determine protection attributes
   if ((GcdAttributes & EFI_MEMORY_RO) != 0) {
-RiscVAttributes &= ~(RISCV_PG_W);
+*RiscVAttributes &= ~(RISCV_PG_W);
   }
 
   // Process eXecute Never attribute
   if ((GcdAttributes & EFI_MEMORY_XP) != 0) {
-RiscVAttributes &= ~RISCV_PG_X;
+*RiscVAttributes &= ~RISCV_PG_X;
+  }
+
+  CacheTypeMask = GcdAttributes & EFI_CACHE_ATTRIBUTE_MASK;
+  if ((CacheTypeMask != 0) &&
+  (((CacheTypeMask - 1) & CacheTypeMask) != 0))
+  {
+DEBUG (
+  (
+   DEBUG_ERROR,
+   "%a: The cache type mask (0x%llX) should contain exactly one bit set\n",
+   __func__,
+   CacheTypeMask
+  )
+  );
+return EFI_INVALID_PARAMETER;
   }
 
-  return RiscVAttributes;
+  switch (CacheTypeMask) {
+case EFI_MEMORY_UC:
+  if (PmbtExtEnabled) {
+*RiscVAttributes |= PTE_PBMT_IO;
+  } else {
+DEBUG (
+  (
+   DEBUG_VERBOSE,
+   "%a: EFI_MEMORY_UC set but Pmbt extension not available\n",
+   __func__
+  )
+  );
+  }
+
+  break;
+case EFI_MEMORY_WC:
+  if (PmbtExtEnabled) {
+*RiscVAttributes |= PTE_PBMT_NC;
+  } else {
+DEBUG (
+  (
+   DEBUG_VERBOSE,
+   "%a: EFI_MEMORY_WC set but Pmbt extension not available\n",
+   __func__
+  )
+  );
+  }
+
+  break;
+default:
+  // Default PMA mode
+  break;
+  }
+
+  return EFI_SUCCESS;
 }
 
 /**
@@ -537,21 +599,32 @@ RiscVSetMemoryAttributes (
   IN UINTN Attributes
   )
 {
-  UINTN  PageAttributesSet;
+  UINTN   PageAttributesSet;
+  UINTN   PageAttributesClear;
+  EFI_STATUS  Status;
 
-  PageAttributesSet = GcdAttributeToPageAttribute (Attributes);
+  Status = GcdAttributeToPageAttribute (Attributes, &PageAttributesSet);
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
 
   if (!RiscVMmuEnabled ()) {
 return EFI_SUCCESS;
   }
 
+  PageAttributesClear = PTE_ATTRIBUTES_MASK;
+  if ((PcdGet64 (PcdRiscVFeatureOverride) & RISCV_CPU_FEATURE_PBMT_BITMASK) != 
0) {
+PageAttributesClear |= PTE_PBMT_MASK;
+  }
+
   DEBUG (
 (
  DEBUG_VERBOSE,
- "%a: Set %llX page attribute 0x%X\n",
+ "%a: %llX: set attributes 0x%X, clear attributes 0x%X\n",
  __func__,
  BaseAddress,
- PageAttributesSet
+ PageAttributesSet,
+ PageAttributesClear
 )
 );
 
@@ -559,7 +632,7 @@ RiscVSetMemoryAttributes (
BaseAddress,
Length,
PageAttributesSet,
-   PTE_ATTRIBUTES_MASK,
+   PageAttributesClear,
(UINTN *)RiscVGetRootTranslateTable (),
TRUE
);
diff --git a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf 
b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
index 51ebe1750e97..1dbaa81f3608 100644
--- a/UefiCpuPkg/

[edk2-devel] [PATCH v3 1/3] MdePkg.dec: RISC-V: Define override bit for Svpbmt extension

[Tuan Phan]

Define the BIT 2 as the override bit for Svpbmt extension. This will
be used by RISC-V MMU library to support EFI_MEMORY_UC and
EFI_MEMORY_WC.

Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Zhiguang Liu 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tuan Phan 
---
 MdePkg/MdePkg.dec | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 0459418906f8..6850acb96b92 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -2407,6 +2407,8 @@
   # previous stage has feature enabled and user wants to disable it.
   # BIT 1 = Supervisor Time Compare (Sstc). This bit is relevant only if
   # previous stage has feature enabled and user wants to disable it.
+  # BIT 2 = Page-Based Memory Types (Pbmt). This bit is relevant only if
+  # previous stage has feature enabled and user wants to disable it.
   #
   
gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0x|UINT64|0x69
 
-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116197): https://edk2.groups.io/g/devel/message/116197
Mute This Topic: https://groups.io/mt/104656465/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3 0/3] RISC-V: Support Svpbmt extension

[Tuan Phan]

This series adds support for RISC-V Svpbmt extension.

The GCD EFI_MEMORY_UC and EFI_MEMORY_WC attributes will
be mapped to IO and NC mode defined in PBMT field.

v3:
  - Addressed Laszlo's comments.
v2:
  - Generated patch for each package.

Tuan Phan (3):
  MdePkg.dec: RISC-V: Define override bit for Svpbmt extension
  UefiCpuPkg: RISC-V: MMU: Support Svpbmt extension
  OvmfPkg/RiscVVirt: Disable Svpbmt extension

 MdePkg/MdePkg.dec |   2 +
 OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc   |   2 +-
 .../Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c | 101 +++---
 .../BaseRiscVMmuLib/BaseRiscVMmuLib.inf   |   1 +
 4 files changed, 91 insertions(+), 15 deletions(-)

-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116196): https://edk2.groups.io/g/devel/message/116196
Mute This Topic: https://groups.io/mt/104656464/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-redfish-client][PATCH 00/13] use Redfish HTTP protocol

[Nickle Wang via groups.io]

Hi Mike,



> May I know why didn't you remove

> RedfishClientPkg/PrivateLibrary/RedfishLib completely?



Yes, Abner and I had discussed this before. RedfishLib brings some difficulty 
to maintain because it is private library in two separated repositories.



Before we go and remove it, we like to make sure that no one is using it. @Igor 
Kulchytskyy, if my memory serves me well, you mentioned 
that AMI is using RedfishLib. Is it ok for us to remove RedfishLib in 
RedfishCientPkg (not RedfishPkg)?



Thanks,

Nickle



> -Original Message-

> From: Mike Maslenkin 

> Sent: Friday, March 1, 2024 8:08 AM

> To: devel@edk2.groups.io; Nickle Wang 

> Cc: Abner Chang ; Igor Kulchytskyy 

> Subject: Re: [edk2-devel] [edk2-redfish-client][PATCH 00/13] use Redfish HTTP

> protocol

>

> External email: Use caution opening links or attachments

>

>

> Good work, Nickle!

>

> On Thu, Feb 29, 2024 at 11:53 AM Nickle Wang via groups.io

> mailto:nicklew=nvidia@groups.io>> wrote:

> >

> > Redfish HTTP protocol is introduced to edk2 RedfishPkg. Update

> > RedfishClientPkg to use RedfishHttpLib. And remove the use of

> > RedfishHttpCacheLib.

> >

> > I also replace several functions from RedfishLib with the function

> > provided in RedfishHttpLib. In this way, there is no dependency on

> > RedfishLib in RedfishClientPkg.

>

> May I know why didn't you remove

> RedfishClientPkg/PrivateLibrary/RedfishLib completely?

> I've been looking at this library for a long time and started improving it 
> with this

> set.

> Eventually I realized that the improved functions are not used in 
> RedfishClientPkg.

> Then I just deleted RedfishClientPkg/PrivateLibrary and

> RedfishClientPkg/PrivateInclude/Library/RedfishLib.h,

> tuned the dec and dsc files, and I successfully built the package.

> Removing this library is a big improvement since it duplicates RedfishLib from

> RedfishPkg.

> and their headers no longer conflict.

>

> Regards,

> Mike.

>

>

> >

> > I noticed that there is false alarm in uncrustify check. When there

> > are deleted files, uncrustiry cannot check them and trigger uncrustify

> > failure.

> >

> > Pull request is created here for testing CI:

> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith

> > ub.com%2Ftianocore%2Fedk2-redfish-

> client%2Fpull%2F79&data=05%7C02%7Cni

> >

> cklew%40nvidia.com%7C44d7d139b40b4acff94508dc3983b3df%7C43083d1572

> 7340

> >

> c1b7db39efd9ccc17a%7C0%7C0%7C638448485034820142%7CUnknown%7CTW

> FpbGZsb3

> >

> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D

> %7

> >

> C0%7C%7C%7C&sdata=ocqaIR0%2BtKvx8ETphWlWFX2uZIQbQvDKWkn7D36c2z

> 0%3D&res

> > erved=0

> >

> > Signed-off-by: Nickle Wang mailto:nick...@nvidia.com>>

> > Cc: Abner Chang mailto:abner.ch...@amd.com>>

> > Cc: Igor Kulchytskyy mailto:ig...@ami.com>>

> >

> > Nickle Wang (13):

> >   RedfishClientPkg/.github: do not run uncrustify to deleted file.

> >   RedfishClientPkg: remove RedfishHttpCacheLib

> >   RedfishClientPkg: ues RedfishHttpLib

> >   RedfishClientPkg/RedfishResourceConfigLib: ues RedfishHttpLib

> >   RedfishClientPkg/RedfishFeatureUtilityLib: ues RedfishHttpLib

> >   RedfishClientPkg/RedfishVersionLib: ues RedfishHttpLib

> >   RedfishClientPkg/BiosDxe: ues RedfishHttpLib

> >   RedfishClientPkg/BootOptionDxe: ues RedfishHttpLib

> >   RedfishClientPkg/BootOptionCollectionDxe: ues RedfishHttpLib

> >   RedfishClientPkg/ComputerSystemDxe: ues RedfishHttpLib

> >   RedfishClientPkg/ComputerSystemCollectionDxe: ues RedfishHttpLib

> >   RedfishClientPkg/MemoryDxe: ues RedfishHttpLib

> >   RedfishClientPkg/MemoryCollectionDxe: ues RedfishHttpLib

> >

> >  RedfishClientPkg/RedfishClientPkg.dec |   1 -

> >  RedfishClientPkg/RedfishClientLibs.dsc.inc|   2 +-

> >  RedfishClientPkg/RedfishClientPkg.dsc |   1 -

> >  .../Features/Bios/v1_0_9/Dxe/BiosDxe.inf  |   3 +-

> >  .../BootOption/v1_0_4/Dxe/BootOptionDxe.inf   |   5 +-

> >  .../BootOptionCollectionDxe.inf   |   5 +-

> >  .../v1_13_0/Dxe/ComputerSystemDxe.inf |   3 +-

> >  .../v1_5_0/Dxe/ComputerSystemDxe.inf  |   3 +-

> >  .../ComputerSystemCollectionDxe.inf   |   3 +-

> >  .../Features/Memory/V1_7_1/Dxe/MemoryDxe.inf  |   3 +-

> >  .../MemoryCollectionDxe.inf   |   3 +-

> >  .../EdkIIRedfishResourceConfigLib.inf |   2 +-

> >  .../RedfishFeatureUtilityLib.inf  |   3 +-

> >  .../RedfishHttpCacheLib.inf   |  48 --

> >  .../RedfishVersionLib/RedfishVersionLib.inf   |   3 +-

> >  .../Library/EdkIIRedfishResourceConfigLib.h   |   4 +-

> >  .../Library/RedfishFeatureUtilityLib.h|  46 +-

> >  .../Include/Library/RedfishHttpCacheLib.h |  59 --

> >  .../Include/RedfishCollectionCommon.h |   3 +-

> >  .../Include/RedfishResourceCommon.h   |   3 +-

> >  .../RedfishFeatureUtilityInternal.h

Re: [edk2-devel] [RFC PATCH 1/1] ArmPkg,MdePkg: move ArmLib.h to MdePkg

[Yao, Jiewen]

Sure.

When we say "dependency", what we really mean is the dependency in INF file, 
not "dependency" in DSC file.

>From package release perspective, only INF is the interface to other package. 
The DSC is only the package internal stuff, you can create multiple DSCs or 
add/remove DSC freely.

Having "dependency" in DSC does not matter.
Having dependency in INF is something we should care about.

Thank you
Yao, Jiewen


> -Original Message-
> From: Leif Lindholm 
> Sent: Tuesday, February 13, 2024 1:38 AM
> To: Pierre Gondois ; devel@edk2.groups.io; Yao,
> Jiewen 
> Cc: Ard Biesheuvel ; Liming Gao
> ; Kinney, Michael D ;
> Sami Mujawar ; Liu, Zhiguang
> 
> Subject: Re: [RFC PATCH 1/1] ArmPkg,MdePkg: move ArmLib.h to MdePkg
> 
> Jiewen, can you clarify what you said back in
> https://edk2.groups.io/g/devel/message/111551
> ?
> 
> On 2024-02-12 17:24, Pierre Gondois wrote:
> >>> A ArmLibNull.inf library might also need to be created. If the
> >>> OpensslLibFullAccel.inf module will depend on the ArmLib library,
> >>> a Null implementation will be necessary for non-Arm architectures.
> >>
> >> Can ArmLib be declared under a [LibraryClasses.AArch64,
> >> LibraryClasses.ARM]? Have I forgotten something that we discussed back
> >> in ... November?
> >
> >  From [1], it seems the MdePkg/CryptoPkg should build without a dependency
> > on the ArmPkg. This is currently not really the case. cf. [2].
> >
> > However, having a ArmLibNull implementation in the MdePkg would allow to
> > avoid going in this direction when providing libraries to CryptoPkg.dsc.
> >
> > (Just in case, I think this ArmLibNull is a minor point.)
> 
> Well, sure, it is now.
> Until we need a RiscV64LibNull, LoongarchLibNull, ...
> 
> > [1] https://edk2.groups.io/g/devel/message/111545
> > [2]
> >
> https://github.com/tianocore/edk2/blob/8801c75b4d77c2e6e06b3ddc8560e0db
> 590f6342/CryptoPkg/CryptoPkg.dsc#L117
> >
> >>
> >>> Otherwise I could apply and run the CryptoPkg/Arm native instructions
> >>> patchset on top of this patch.
> >>>
> >>> ---
> >>>
> >>> As a side note, it also seems that:
> >>> - ArmPkg/Include/Chipset/ArmCortexA5x.h
> >>>     isn't used anymore in edk2/edk2-platorms
> >>> - ArmPkg/Include/Chipset/ArmCortexA9.h
> >>>     is barely used in edk2-platforms.
> >>> Maybe the files should have been removed/simplified as part of
> >>> - cffa7925a293 ("ArmPkg: remove ArmCpuLib header and implementations")
> >>> - a913ad02479d ("ArmPlatformPkg: remove ArmVExpressPkg")
> >>
> >> I think you're right.
> >> Well, ArmCortexA9.h is still *used*, but I can't imagine the Arm branch
> >> of ArmVExpressLib has been build by anyone for some time. And surely the
> >> inclusion of ArmVExpressLibSec in ArmVExpress-FVP-AArch64.dsc is
> >> superfluous (such that that .inf can be deleted)?
> >
> > The file could just be moved in the Library. I assume you/Sami/Ard
> > will know more on the usage of the library itself,
> 
> Sami?
> 
> /
>  Leif
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116193): https://edk2.groups.io/g/devel/message/116193
Mute This Topic: https://groups.io/mt/102731845/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 Bonzini]

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 ((INTN)gEfiCurrentTpl == HighBitSet64 (mInterruptedTplMask));
> +  mInterruptedTplMask &= ~(UINTN)(1 << gEfiCurrentTpl);
> +}
>}

Ok, now I understand what's going on and it's indeed the same logic as
NestedInterruptTplLib, with DisableInterruptsOnIret() replaced by
skipping CoreSetInterruptState(TRUE). It's similar to what I proposed
elsewhere in the thread, just written differenty.

I agree with Michael Brown that the spec is unclear on the state of
the interrupt flag on exit from gBS->RestoreTPL(), but perhaps this
change is feasible if the interrupt handlers just raise the TPL first
and restore it last.

Just as an exercise for me to understand the code better, I tried
rewriting the code in terms of the CoreRestoreTplInternal() function
that I proposed. I find it easier to read, but I guess that's a bit in
the eye of the beholder, and it is a little more defensively coded. I
attach it (untested beyond compilation) for reference.

Paolo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116192): https://edk2.groups.io/g/devel/message/116192
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]
-=-=-=-=-=-=-=-=-=-=-=-


From 23c4f60cf79f29ab5eff55a02c72bb504804d02a Mon Sep 17 00:00:00 2001
From: Paolo Bonzini 
Date: Thu, 29 Feb 2024 23:54:50 +0100
Subject: [PATCH 1/2] MdeModulePkg: introduce CoreRestoreTplInternal()
Content-Type: text/plain; charset=UTF-8

Introduce a function that restores the TPL just like gBS->RestoreTPL(),
but can optionally return with interrupts disabled.  This can be used
from interrupt handlers, so that any nested interrupt handler will only
see an elevated TPL and not the value on entry to the interrupt handler.

Signed-off-by: Paolo Bonzini 
---
 MdeModulePkg/Core/Dxe/Event/Tpl.c | 46 +--
 1 file changed, 31 insertions(+), 15 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Event/Tpl.c b/MdeModulePkg/Core/Dxe/Event/Tpl.c
index b33f80573c..fe95ea3896 100644
--- a/MdeModulePkg/Core/Dxe/Event/Tpl.c
+++ b/MdeModulePkg/Core/Dxe/Event/Tpl.c
@@ -90,10 +90,11 @@ CoreRaiseTpl (
   @param  NewTpl  New, lower, task priority
 
 **/
-VOID
+static VOID
 EFIAPI
-CoreRestoreTpl (
-  IN EFI_TPL  NewTpl
+CoreRestoreTplInternal (
+  IN EFI_TPL  NewTpl,
+  IN BOOLEAN  DesiredInterruptState
   )
 {
   EFI_TPL  OldTpl;
@@ -107,11 +108,6 @@ CoreRestoreTpl (
 
   ASSERT (VALID_TPL (NewTpl));
 
-  //
-  // If lowering below HIGH_LEVEL, make sure
-  // interrupts are enabled
-  //
-
   if ((OldTpl >= TPL_HIGH_LEVEL) &&  (NewTpl < TPL_HIGH_LEVEL)) {
 gEfiCurrentTpl = TPL_HIGH_LEVEL;
   }
@@ -126,6 +122,11 @@ CoreRestoreTpl (
 }
 
 gEfiCurrentTpl = PendingTpl;
+
+//
+// If lowering below HIGH_LEVEL, make sure
+// interrupts are enabled
+//
 if (gEfiCurrentTpl < TPL_HIGH_LEVEL) {
   CoreSetInterruptState (TRUE);
 }
@@ -134,16 +135,31 @@ CoreRestoreTpl (
   }
 
   //
-  // Set the new value
+  // Set the new TPL with interrupt disabled.  If DesiredInterruptState
+  // is FALSE, this ensures that any nested interrupt handler will only
+  // see an elevated TPL and not NewTpl.
   //
-
+  CoreSetInterruptState (FALSE);
   gEfiCurrentTpl = NewTpl;
 
-  //
-  // If lowering below HIGH_LEVEL, make sure
-  // interrupts are enabled
-  //
-  if (gEfiCurrentTpl < TPL_HIGH_LEVEL) {
+  if (DesiredInterruptState) {
+ASSERT(gEfiCurrentTpl < TPL_HIGH_LEVEL);
 CoreSetInterruptState (TRUE);
   }
 }
+
+/**
+  Lowers the task priority to the previous value.   If the new
+  priority unmasks events at a higher priority, they are dispatched.
+
+  @param  NewTpl  New, lower, task priority
+
+**/
+VOID
+EFIAPI
+CoreRestoreTpl (
+  IN EFI_TPL NewTpl
+  )
+{
+  CoreRestoreTplInternal (NewTpl, NewTpl < TPL_

Re: [edk2-devel] [edk2-redfish-client][PATCH 00/13] use Redfish HTTP protocol

[Mike Maslenkin]

Good work, Nickle!

On Thu, Feb 29, 2024 at 11:53 AM Nickle Wang via groups.io
 wrote:
>
> Redfish HTTP protocol is introduced to edk2 RedfishPkg. Update
> RedfishClientPkg to use RedfishHttpLib. And remove the use of
> RedfishHttpCacheLib.
>
> I also replace several functions from RedfishLib with the function
> provided in RedfishHttpLib. In this way, there is no dependency on
> RedfishLib in RedfishClientPkg.

May I know why didn't you remove
RedfishClientPkg/PrivateLibrary/RedfishLib completely?
I've been looking at this library for a long time and started
improving it with this set.
Eventually I realized that the improved functions are not used in
RedfishClientPkg.
Then I just deleted RedfishClientPkg/PrivateLibrary and
RedfishClientPkg/PrivateInclude/Library/RedfishLib.h,
tuned the dec and dsc files, and I successfully built the package.
Removing this library is a big improvement since it duplicates
RedfishLib from RedfishPkg.
and their headers no longer conflict.

Regards,
Mike.


>
> I noticed that there is false alarm in uncrustify check. When there
> are deleted files, uncrustiry cannot check them and trigger uncrustify
> failure.
>
> Pull request is created here for testing CI:
> https://github.com/tianocore/edk2-redfish-client/pull/79
>
> Signed-off-by: Nickle Wang 
> Cc: Abner Chang 
> Cc: Igor Kulchytskyy 
>
> Nickle Wang (13):
>   RedfishClientPkg/.github: do not run uncrustify to deleted file.
>   RedfishClientPkg: remove RedfishHttpCacheLib
>   RedfishClientPkg: ues RedfishHttpLib
>   RedfishClientPkg/RedfishResourceConfigLib: ues RedfishHttpLib
>   RedfishClientPkg/RedfishFeatureUtilityLib: ues RedfishHttpLib
>   RedfishClientPkg/RedfishVersionLib: ues RedfishHttpLib
>   RedfishClientPkg/BiosDxe: ues RedfishHttpLib
>   RedfishClientPkg/BootOptionDxe: ues RedfishHttpLib
>   RedfishClientPkg/BootOptionCollectionDxe: ues RedfishHttpLib
>   RedfishClientPkg/ComputerSystemDxe: ues RedfishHttpLib
>   RedfishClientPkg/ComputerSystemCollectionDxe: ues RedfishHttpLib
>   RedfishClientPkg/MemoryDxe: ues RedfishHttpLib
>   RedfishClientPkg/MemoryCollectionDxe: ues RedfishHttpLib
>
>  RedfishClientPkg/RedfishClientPkg.dec |   1 -
>  RedfishClientPkg/RedfishClientLibs.dsc.inc|   2 +-
>  RedfishClientPkg/RedfishClientPkg.dsc |   1 -
>  .../Features/Bios/v1_0_9/Dxe/BiosDxe.inf  |   3 +-
>  .../BootOption/v1_0_4/Dxe/BootOptionDxe.inf   |   5 +-
>  .../BootOptionCollectionDxe.inf   |   5 +-
>  .../v1_13_0/Dxe/ComputerSystemDxe.inf |   3 +-
>  .../v1_5_0/Dxe/ComputerSystemDxe.inf  |   3 +-
>  .../ComputerSystemCollectionDxe.inf   |   3 +-
>  .../Features/Memory/V1_7_1/Dxe/MemoryDxe.inf  |   3 +-
>  .../MemoryCollectionDxe.inf   |   3 +-
>  .../EdkIIRedfishResourceConfigLib.inf |   2 +-
>  .../RedfishFeatureUtilityLib.inf  |   3 +-
>  .../RedfishHttpCacheLib.inf   |  48 --
>  .../RedfishVersionLib/RedfishVersionLib.inf   |   3 +-
>  .../Library/EdkIIRedfishResourceConfigLib.h   |   4 +-
>  .../Library/RedfishFeatureUtilityLib.h|  46 +-
>  .../Include/Library/RedfishHttpCacheLib.h |  59 --
>  .../Include/RedfishCollectionCommon.h |   3 +-
>  .../Include/RedfishResourceCommon.h   |   3 +-
>  .../RedfishFeatureUtilityInternal.h   |   3 +-
>  .../RedfishHttpCacheLibInternal.h |  63 --
>  .../Features/Bios/v1_0_9/Common/BiosCommon.c  |  92 +--
>  .../Features/Bios/v1_0_9/Dxe/BiosDxe.c| 113 +--
>  .../v1_0_4/Common/BootOptionCommon.c  |  45 +-
>  .../BootOption/v1_0_4/Dxe/BootOptionDxe.c |  86 +-
>  .../BootOptionCollectionDxe.c |  26 +-
>  .../v1_13_0/Common/ComputerSystemCommon.c |  68 +-
>  .../v1_13_0/Dxe/ComputerSystemDxe.c   |  85 +-
>  .../v1_5_0/Common/ComputerSystemCommon.c  |  68 +-
>  .../v1_5_0/Dxe/ComputerSystemDxe.c|  84 +-
>  .../ComputerSystemCollectionDxe.c |  15 +-
>  .../Memory/V1_7_1/Common/MemoryCommon.c   |  86 +-
>  .../Features/Memory/V1_7_1/Dxe/MemoryDxe.c| 111 +--
>  .../MemoryCollectionDxe/MemoryCollectionDxe.c |  15 +-
>  .../EdkIIRedfishResourceConfigLib.c   |   6 +-
>  .../RedfishFeatureUtilityLib.c| 182 +---
>  .../RedfishHttpCacheLib/RedfishHttpCacheLib.c | 774 --
>  .../RedfishVersionLib/RedfishVersionLib.c |  24 +-
>  .github/workflows/uncrustify-check.sh |  17 +-
>  40 files changed, 328 insertions(+), 1838 deletions(-)
>  delete mode 100644 
> RedfishClientPkg/Library/RedfishHttpCacheLib/RedfishHttpCacheLib.inf
>  delete mode 100644 RedfishClientPkg/Include/Library/RedfishHttpCacheLib.h
>  delete mode 100644 
> RedfishClientPkg/Library/RedfishHttpCacheLib/RedfishHttpCacheLibInternal.h
>  delete mode 100644 
> RedfishClientPkg/Library/RedfishHttpCacheLib/RedfishHttpCacheLib.c
>
> --
> 2.34.1
>
>
>
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group

Re: [edk2-devel] [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack overflow issue due to nested interrupts

[Paolo Bonzini]

On 2/29/24 20:22, Michael Brown wrote:

The design of NestedInterruptTplLib is that each nested interrupt must increase 
the TPL, but if I understand correctly there is a hole here:

   //
   // Call RestoreTPL() to allow event notifications to be
   // dispatched.  This will implicitly re-enable interrupts.
   //
   gBS->RestoreTPL (InterruptedTPL);

   //
   // Re-disable interrupts after the call to RestoreTPL() to ensure
   // that we have exclusive access to the shared state.
   //
   DisableInterrupts ();

because gBS->RestoreTPL will unconditionally enable interrupts if InterruptedTPL 
< TPL_HIGH_LEVEL.


There's no hole there.


Yes, what I meant is that the whole of NestedInterruptTplLib is designed 
around plugging that hole.  But if you can avoid re-enabling interrupts 
at the end of CoreRestoreTpl(), you don't need DisableInterruptsOnIret() 
anymore.


See the comments in the code for further details - I made them fairly 
extensive.  🙂


Yup, I remember. :)

If possible, the easiest solution would be to merge 
NestedInterruptTplLib into Core DXE.


The question with that approach would be how to cleanly violate the 
abstraction layer that separates the timer interrupt handler (existing 
in a separate DXE driver executable) from the implementation of 
CoreRestoreTplInternal() (existing in core DXE and not exposed via the 
boot services table).


See outline in the other mail I have sent.

Paolo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116190): https://edk2.groups.io/g/devel/message/116190
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 Bonzini]

On 2/29/24 20:16, Kinney, Michael D wrote:




-Original Message-
From: Paolo Bonzini 
Sent: Thursday, February 29, 2024 11:04 AM
To: Ni, Ray ; devel@edk2.groups.io
Cc: 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 2/29/24 14:02, Ray Ni wrote:

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.


How do non-OVMF platforms solve the issue?  Do they just have the same
bug as in https://bugzilla.tianocore.org/show_bug.cgi?id=4162 ?


Yes.  This same issue can be reproduced on non-OVMF platforms.

This proposal here is an attempt to integrate a common fix into the DXE Core.

I would agree conceptually that integrating the NestedInterruptTplLib work
into the DXE Core is another option.

I believe the root cause of all of these scenarios is enabling interrupts
in RestoreTPL() when processing a timer interrupt between the last processed
event and the return from the interrupt handler. Ther are some instances
of the Timer Arch Protocol implementation that call Raise/Restore TPL, so
we want a DXE Core change that is compatible with the DXE Core doing 
Raise/Restore
when processing a timer interrupt and the Timer Arch Protocol implementation
also doing the Raise/Restore TPL.


Ok, now I understand better.

The reason why the NestedInterruptTplLib was introduced (as opposed to 
doing it in core DXE) was to enable returning with disabled interrupts 
from the nested interrupt handler, but I think it can be done with a 
function like the CoreRestoreTplInternal() I outlined in the previous 
email, which is the same as current CoreRestoreTpl() but finishes with


  if (!DesiredInterruptState) {
CoreSetInterruptState (FALSE);
  }
  gEfiCurrentTpl = NewTpl;
  if (DesiredInterruptState) {
ASSERT (gEfiCurrentTpl < TPL_HIGH_LEVEL);
CoreSetInterruptState (TRUE);
  }

The new CoreRaiseTpl would be the same as in Ray and your patch, while 
the CoreRestoreTpl would be something like this:


if (NewTpl == HighBitSet64 (mInterruptedTplMask)) {
  static NESTED_INTERRUPT_STATE NestedInterruptState;
  mInterruptedTplMask &= ~(UINTN)(1 << NewTpl);
  //
  // Use the deferred invocation logic that is currently
  // in NestedInterruptTplLib.
  //
  // But unlike current NestedInterruptRestoreTPL(), if the logic
  // is part of core DXE, the
  //
  //gBS->RestoreTPL (InterruptedTPL);
  //DisableInterrupts ();
  //
  // pair that requires "disable interrupts on IRET" logic can
  // be done without ever enabling interrupts,  with
  // CoreRestoreTplInternal(InterruptedTPL, FALSE)
  //
  // As an aside, NestedInterruptState might as well become a
  // pair of globals.
  //
  NestedInterruptRestoreTPL (NewTpl, &NestedInterruptState);
} else {
  CoreRestoreTplInternal(NewTpl, NewTpl < TPL_HIGH_LEVEL);
}

Requiring matching raise/restore pairs is a bit scary.  It can be 
avoided by changing the "if" to a


  while (NewTpl >= HighBitSet64 (mInterruptedTplMask))
mInterruptedTplMask &=
  ~(UINTN)(1 << HighBitSet64 (mInterruptedTplMask));

Then, if inlining NestedInterruptRestoreTPL() allows simplifications, 
they can be done on top after the merge of NestedInterruptTplLib.  In 
particular, I suspect that the while loop above can be unified with the 
loop in NestedInterruptRestoreTPL().  But again, that would be best 
reviewed as a separate change.


All this, as Michael said, is however conditional on being able to deal 
with the TPL_HIGH_LEVEL+STI shenanigans that Windows does.


Paolo



The design of NestedInterruptTplLib is that each nested interrupt must
increase the TPL, but if I understand correctly there is a hole here:

//
// Call RestoreTPL() to allow event notifications to be
// dispatched.  This will implicitly re-enable interrupts.
//
gBS->RestoreTPL (InterruptedTPL);

//
// Re-disable interrupts after the call to RestoreTPL() to ensure
// that we have exclusive access to the shared state.
//
DisableInterrupts ();

because gBS->RestoreTPL will unconditionally enable interrupts if
InterruptedTPL < TPL_HIGH_LEVEL.


If possible, the easiest solution would be to merge
NestedInterruptTplLib into Core DXE.  This way, instead of calling
gBS->RestoreTPL, NestedInterruptTplLib can call a custom version of
CoreRestoreTpl that exits with interrupts disabled.  That is, something
like

VOID EFIAPI CoreRestoreTplInternal(IN EFI_TPL NewTpl,
 IN BOOLEAN InterruptState)
{
//
// The caller can request disabled interrupts to access shared
// state, but TPL_HIGH_LEVEL must *not* have them enabled.
//
ASSERT(!(NewTpl == TPL_HIGH_LEVEL && InterruptState));

 

Re: [edk2-devel] [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack overflow issue due to nested interrupts

[Michael Brown]

On 29/02/2024 19:26, Michael D Kinney wrote:

I think one advantage of this new proposal is to prevent
an extra level of nesting and use of stack resources in
that extra level.


I think that's a negligible benefit.  In the scenario as I outlined for 
NestedInterruptTplLib, there is potentially one more interrupt stack 
frame, but in that case the inner handler can only consume a small and 
fixed amount of stack space since it will not call RestoreTPL() (and so 
will not dispatch events, etc).


Thanks,

Michael



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116188): https://edk2.groups.io/g/devel/message/116188
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

[Michael Brown]

On 29/02/2024 19:09, Michael D Kinney wrote:

"When the DXE Foundation is notified that the EFI_CPU_ARCH_PROTOCOL has
been installed, then the full version of the Boot Service RestoreTPL()
can be made available.  When an attempt is made to restore the TPL
level
to level below EFI_TPL_HIGH_LEVEL, then the DXE Foundation should use
the services of the EFI_CPU_ARCH_PROTOCOL to enable interrupts."


I would claim that this spec is perhaps incomplete in this area that
that incomplete description is what allows the window for interrupt
nesting to occur.  This language is correct for UEFI code that calls
Raise/Restore TPL once the CPU Arch Protocol is available.  It does
not cover the required behavior to prevent nesting when processing
a timer interrupt.  This could be considered a gap in the UEFI/PI
spec content.


I think it's important that we don't phrase it as preventing interrupt 
nesting.  The UEFI design *requires* that nested interrupts be allowed 
to happen, since callbacks at TPL_CALLBACK are allowed to wait for 
events at TPL_NOTIFY, and this can't happen without the existence of 
nested interrupts.


The problem is not nested interrupts per se: the problem is the 
potential for unlimited stack consumption.



- How does the proposed patch react to an interrupt occurring
(illegally) at TPL_HIGH_LEVEL (as happens with some versions of
Windows)?  As far as I can tell, it will result in mInterruptedTplMask
having bit 31 set but never cleared.  What impact will this have?


This behavior could potentially break any UEFI code that sets TPL to
TPL_HIGH_LEVEL as a lock, which can then cause any number of
undefined behaviors.  I am curious of you have a way to reproduce
this failure for testing purposed.

I would agree that any proposed change needs to comprehend this
Scenario if it can be reproduced with shipping OS images.


https://bugzilla.redhat.com/show_bug.cgi?id=2189136 was the original bug 
report in which it was discovered that Windows 11 would call 
RaiseTPL(TPL_HIGH_LEVEL) and then enable interrupts using the STI 
instruction.


It would be interesting to hear from anyone at Microsoft as to why this 
happens!



- How does the proposed patch react to potentially mismatched
RaisedTPL()/RestoreTPL() calls (e.g. oldTpl = RaiseTPL(TPL_CALLBACK)
followed by RaiseTPL(TPL_NOTIFY) followed by a single
RestoreTPL(oldTpl))?


The proposed patch only changes behavior when processing a timer
interrupt.  I do not think there would be any changes in behavior
for UEFI code that makes that sequence of calls.


The patch affects all callers of RaiseTPL() and RestoreTPL().  Given 
that it creates a new piece of shared state (mInterruptedTplMask), I'd 
like to see some kind of proof that it can correctly handle an arbitrary 
sequence of calls from unknown third-party code.


For example: consider an interrupt at TPL_APPLICATION with a third-party 
timer interrupt handler that does something like:


  OldTpl = RaiseTPL (TPL_HIGH_LEVEL);

  ... send EOI, call timer tick function, etc ...

  if (OldTpl < TPL_NOTIFY) {
RestoreTPL (TPL_NOTIFY);
... do some weird OEM-specific thing ...
  }

  RestoreTPL ( OldTpl );

This is arguably a valid sequence of calls to RaiseTPL()/RestoreTPL(). 
With the patch as-is, mInterruptedTplMask will have flagged the 
TPL_APPLICATION bit but not the TPL_NOTIFY bit, and so the call to 
RestoreTPL(TPL_NOTIFY) *will* re-enable interrupts, which is against the 
intention of the patch.


Thanks,

Michael



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116187): https://edk2.groups.io/g/devel/message/116187
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

[Michael D Kinney]

I think one advantage of this new proposal is to prevent 
an extra level of nesting and use of stack resources in 
that extra level.

The nesting depth is then both predictable and minimized
for a given set of supported TPL levels.

Mike

> -Original Message-
> From: Michael Brown 
> Sent: Thursday, February 29, 2024 11:22 AM
> To: devel@edk2.groups.io; pbonz...@redhat.com; Ni, Ray
> 
> Cc: Kinney, Michael D ; Liming Gao
> ; Laszlo Ersek 
> Subject: Re: [edk2-devel] [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack
> overflow issue due to nested interrupts
> 
> On 29/02/2024 19:04, Paolo Bonzini wrote:
> > On 2/29/24 14:02, Ray Ni wrote:
> >> 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.
> >
> > How do non-OVMF platforms solve the issue?  Do they just have the
> same
> > bug as in https://bugzilla.tianocore.org/show_bug.cgi?id=4162 ?
> 
> Yes, they have that bug (or one of the bugs mentioned in that long
> discussion, depending on which particular implementation choices have
> been made).
> 
> > The design of NestedInterruptTplLib is that each nested interrupt
> must
> > increase the TPL, but if I understand correctly there is a hole here:
> >
> >    //
> >    // Call RestoreTPL() to allow event notifications to be
> >    // dispatched.  This will implicitly re-enable interrupts.
> >    //
> >    gBS->RestoreTPL (InterruptedTPL);
> >
> >    //
> >    // Re-disable interrupts after the call to RestoreTPL() to ensure
> >    // that we have exclusive access to the shared state.
> >    //
> >    DisableInterrupts ();
> >
> > because gBS->RestoreTPL will unconditionally enable interrupts if
> > InterruptedTPL < TPL_HIGH_LEVEL.
> 
> There's no hole there.
> 
> Yes, interrupts will be temporarily reenabled, but the whole function
> of
> NestedInterruptTplLib is to safely allow for this window in which
> interrupts have been (annoyingly) enabled by RestoreTPL().
> 
> If another interrupt *does* occur within that window, the inner
> interrupt handler will call NestedInterruptRestoreTPL(), which will
> take
> the code path leading to the "DEFERRAL INVOCATION POINT", and will
> therefore *not* call RestoreTPL() within that stack frame.  The inner
> interrupt returns at TPL_HIGH_LEVEL with interrupts still disabled, and
> execution is therefore guaranteed to immediately reach the "DEFERRAL
> RETURN POINT" in the outer interrupt handler.  The deferred call to
> RestoreTPL() is then safely executed in the context of the outer
> interrupt handler (i.e. with zero increase in stack usage, hence a
> guarantee of no stack overflow).
> 
> See the comments in the code for further details - I made them fairly
> extensive.  :)
> 
> > If possible, the easiest solution would be to merge
> > NestedInterruptTplLib into Core DXE.
> 
> The question with that approach would be how to cleanly violate the
> abstraction layer that separates the timer interrupt handler (existing
> in a separate DXE driver executable) from the implementation of
> CoreRestoreTplInternal() (existing in core DXE and not exposed via the
> boot services table).
> 
> Thanks,
> 
> Michael



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116186): https://edk2.groups.io/g/devel/message/116186
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

[Michael Brown]

On 29/02/2024 19:04, Paolo Bonzini wrote:

On 2/29/24 14:02, Ray Ni wrote:
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.


How do non-OVMF platforms solve the issue?  Do they just have the same 
bug as in https://bugzilla.tianocore.org/show_bug.cgi?id=4162 ?


Yes, they have that bug (or one of the bugs mentioned in that long 
discussion, depending on which particular implementation choices have 
been made).


The design of NestedInterruptTplLib is that each nested interrupt must 
increase the TPL, but if I understand correctly there is a hole here:


   //
   // Call RestoreTPL() to allow event notifications to be
   // dispatched.  This will implicitly re-enable interrupts.
   //
   gBS->RestoreTPL (InterruptedTPL);

   //
   // Re-disable interrupts after the call to RestoreTPL() to ensure
   // that we have exclusive access to the shared state.
   //
   DisableInterrupts ();

because gBS->RestoreTPL will unconditionally enable interrupts if 
InterruptedTPL < TPL_HIGH_LEVEL.


There's no hole there.

Yes, interrupts will be temporarily reenabled, but the whole function of 
NestedInterruptTplLib is to safely allow for this window in which 
interrupts have been (annoyingly) enabled by RestoreTPL().


If another interrupt *does* occur within that window, the inner 
interrupt handler will call NestedInterruptRestoreTPL(), which will take 
the code path leading to the "DEFERRAL INVOCATION POINT", and will 
therefore *not* call RestoreTPL() within that stack frame.  The inner 
interrupt returns at TPL_HIGH_LEVEL with interrupts still disabled, and 
execution is therefore guaranteed to immediately reach the "DEFERRAL 
RETURN POINT" in the outer interrupt handler.  The deferred call to 
RestoreTPL() is then safely executed in the context of the outer 
interrupt handler (i.e. with zero increase in stack usage, hence a 
guarantee of no stack overflow).


See the comments in the code for further details - I made them fairly 
extensive.  :)


If possible, the easiest solution would be to merge 
NestedInterruptTplLib into Core DXE.


The question with that approach would be how to cleanly violate the 
abstraction layer that separates the timer interrupt handler (existing 
in a separate DXE driver executable) from the implementation of 
CoreRestoreTplInternal() (existing in core DXE and not exposed via the 
boot services table).


Thanks,

Michael



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116185): https://edk2.groups.io/g/devel/message/116185
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

[Michael D Kinney]

> -Original Message-
> From: Paolo Bonzini 
> Sent: Thursday, February 29, 2024 11:04 AM
> To: Ni, Ray ; devel@edk2.groups.io
> Cc: 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 2/29/24 14:02, Ray Ni wrote:
> > 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.
> 
> How do non-OVMF platforms solve the issue?  Do they just have the same
> bug as in https://bugzilla.tianocore.org/show_bug.cgi?id=4162 ?

Yes.  This same issue can be reproduced on non-OVMF platforms.

This proposal here is an attempt to integrate a common fix into the DXE Core.

I would agree conceptually that integrating the NestedInterruptTplLib work
into the DXE Core is another option.

I believe the root cause of all of these scenarios is enabling interrupts
in RestoreTPL() when processing a timer interrupt between the last processed
event and the return from the interrupt handler. Ther are some instances
of the Timer Arch Protocol implementation that call Raise/Restore TPL, so
we want a DXE Core change that is compatible with the DXE Core doing 
Raise/Restore
when processing a timer interrupt and the Timer Arch Protocol implementation
also doing the Raise/Restore TPL.

> 
> The design of NestedInterruptTplLib is that each nested interrupt must
> increase the TPL, but if I understand correctly there is a hole here:
> 
>//
>// Call RestoreTPL() to allow event notifications to be
>// dispatched.  This will implicitly re-enable interrupts.
>//
>gBS->RestoreTPL (InterruptedTPL);
> 
>//
>// Re-disable interrupts after the call to RestoreTPL() to ensure
>// that we have exclusive access to the shared state.
>//
>DisableInterrupts ();
> 
> because gBS->RestoreTPL will unconditionally enable interrupts if
> InterruptedTPL < TPL_HIGH_LEVEL.
> 
> 
> If possible, the easiest solution would be to merge
> NestedInterruptTplLib into Core DXE.  This way, instead of calling
> gBS->RestoreTPL, NestedInterruptTplLib can call a custom version of
> CoreRestoreTpl that exits with interrupts disabled.  That is, something
> like
> 
> VOID EFIAPI CoreRestoreTplInternal(IN EFI_TPL NewTpl,
> IN BOOLEAN InterruptState)
> {
>//
>// The caller can request disabled interrupts to access shared
>// state, but TPL_HIGH_LEVEL must *not* have them enabled.
>//
>ASSERT(!(NewTpl == TPL_HIGH_LEVEL && InterruptState));
> 
>// ...
> 
>gEfiCurrentTpl = NewTpl;
>CoreSetInterruptState (InterruptState);
> }
> 
> Now, CoreRestoreTpl is just
> 
>//
>// If lowering below HIGH_LEVEL, make sure
>// interrupts are enabled
>//
>CoreRestoreTplInternal(NewTpl, NewTpl < TPL_HIGH_LEVEL);
> 
> whereas NestedInterruptRestoreTPL can do
> 
>//
>// Call RestoreTPL() to allow event notifications to be
>// dispatched.  This will implicitly re-enable interrupts,
>// but only if events have to be dispatched.
>//
>CoreRestoreTplInternal(InterruptedTPL, FALSE);
> 
>//
>// Interrupts are now disabled, so we can access shared state.
>//
> 
> This avoids the unlimited nesting of interrupts because each stack
> frame
> will indeed have a higher TPL than the outer version.
> 
> Paolo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116184): https://edk2.groups.io/g/devel/message/116184
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

[Michael D Kinney]

> -Original Message-
> From: Michael Brown 
> Sent: Thursday, February 29, 2024 9:39 AM
> To: Kinney, Michael D ;
> devel@edk2.groups.io; Ni, Ray 
> Cc: Liming Gao ; Laszlo Ersek
> ; Paolo Bonzini 
> Subject: Re: [edk2-devel] [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack
> overflow issue due to nested interrupts
> 
> On 29/02/2024 16:43, Kinney, Michael D wrote:
> > Hi Michael,
> >
> > Can you provide a pointer to the UEFI Spec statement this breaks?
> 
> II-9.7.1.3 RestoreTPL():
> 
> "When the DXE Foundation is notified that the EFI_CPU_ARCH_PROTOCOL has
> been installed, then the full version of the Boot Service RestoreTPL()
> can be made available.  When an attempt is made to restore the TPL
> level
> to level below EFI_TPL_HIGH_LEVEL, then the DXE Foundation should use
> the services of the EFI_CPU_ARCH_PROTOCOL to enable interrupts."

I would claim that this spec is perhaps incomplete in this area that
that incomplete description is what allows the window for interrupt
nesting to occur.  This language is correct for UEFI code that calls
Raise/Restore TPL once the CPU Arch Protocol is available.  It does
not cover the required behavior to prevent nesting when processing
a timer interrupt.  This could be considered a gap in the UEFI/PI
spec content.

> 
> I suspect this is sufficient to veto the proposed design, though we
> could argue that the loosely worded "should" is technically not "must".
> 
> 
> If we still want to proceed with this design, then I have several other
> questions:
> 
> - How does the proposed patch react to an interrupt occurring
> (illegally) at TPL_HIGH_LEVEL (as happens with some versions of
> Windows)?  As far as I can tell, it will result in mInterruptedTplMask
> having bit 31 set but never cleared.  What impact will this have?

This behavior could potentially break any UEFI code that sets TPL to
TPL_HIGH_LEVEL as a lock, which can then cause any number of 
undefined behaviors.  I am curious of you have a way to reproduce 
this failure for testing purposed.

I would agree that any proposed change needs to comprehend this
Scenario if it can be reproduced with shipping OS images.

> 
> - How does the proposed patch react to potentially mismatched
> RaisedTPL()/RestoreTPL() calls (e.g. oldTpl = RaiseTPL(TPL_CALLBACK)
> followed by RaiseTPL(TPL_NOTIFY) followed by a single
> RestoreTPL(oldTpl))?

The proposed patch only changes behavior when processing a timer
interrupt.  I do not think there would be any changes in behavior
for UEFI code that makes that sequence of calls.  

> 
> 
> I believe the proposed patch is attempting to establish a new invariant
> as follows:
> 
> Once an interrupt has occured at a given TPL, then that *TPL* is
> conceptually considered to be in an "interrupted" state.  The *only*
> thing that can clear this "interrupted" state from the TPL is to return
> from the interrupt handler.
> 
> Note that this conceptual definition does not perfectly align with the
> bit flags in mInterruptedTplMask, since those bits will necessarily be
> set only some time after the interrupt occurs, and will have to be
> cleared before returning from the interrupt.  However, it is the
> conceptual definition that is relevant to the invariant.
> 
> The new invariant is that no code may execute at an "interrupted" TPL
> with interrupts enabled.  It is legitimate for code to raise to a
> higher
> TPL and to enable interrupts while there, and it is legitimate for code
> to execute in an "interrupted" TPL with interrupts disabled, but it is
> not legitimate for any code to reenable interrupts while still at an
> "interrupted" TPL.
> 
> It would be good to call out this invariant explicitly, so that authors
> of interrupt handlers are aware of the restrictions.  It would also
> clarify some of the logic (e.g. it provides the reason why interrupts
> must be disabled before lowering gEfiCurrentTpl in CoreRestoreTpl()).
> 
> It's also generally easier to reason about a stated invariant than to
> extrapolate from a list of complicated examples.

I agree that the proposed code change should describe the change in 
this way, and that the examples currently included in comments would
be better in a BZ.

> 
> Thanks,
> 
> Michael



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116183): https://edk2.groups.io/g/devel/message/116183
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

[Michael D Kinney]

Hi Paolo,

The proposed change does not disable interrupts at TPL below TPL_HIGH_LEVEL 
when processing event handlers.

It only prevents interrupts being enabled in the window from the last event 
processed in a timer interrupt and the return from the timer interrupt handler.

This is a window where the only control flows are in the DXE Core and the exit 
of the timer interrupt handler.

Mike

From: devel@edk2.groups.io  On Behalf Of Paolo Bonzini
Sent: Thursday, February 29, 2024 9:40 AM
To: Kinney, Michael D 
Cc: Michael Brown ; edk2-devel-groups-io 
; Ni, Ray ; Liming Gao 
; Laszlo Ersek 
Subject: Re: [edk2-devel] [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack overflow 
issue due to nested interrupts


Il gio 29 feb 2024, 17:45 Kinney, Michael D 
mailto:michael.d.kin...@intel.com>> ha scritto:
Hi Michael,

Can you provide a pointer to the UEFI Spec statement this breaks?

The spec does say that interrupts are disabled for TPL_HIGH_LEVEL, but indeed 
it doesn't say they are always enabled at lower levels. However, if the 
interrupts aren't always enabled whenever you're below TPL_HIGH_LEVEL, you get 
priority inversions (and deadlocks).

For example, if you end up running with interrupts disabled at TPL_CALLBACK, 
you are disabling the dispatching of timers at TPL_NOTIFY.

I guess this can be deduced from these two passages:

- "The functions in these queues are invoked in FIFO order, starting with the 
highest priority level queue and proceeding to the lowest priority queue that 
is unmasked by the current TPL"

- "If Type is TimerRelative and TriggerTime is 0, then the timer event will be 
signaled on the next timer tick" (in the description of gBS->SetTimer)

Paolo


Thanks,

Mike

> -Original Message-
> From: Michael Brown mailto:mc...@ipxe.org>>
> Sent: Thursday, February 29, 2024 5:23 AM
> To: devel@edk2.groups.io; Ni, Ray 
> mailto:ray...@intel.com>>
> Cc: Kinney, Michael D 
> mailto:michael.d.kin...@intel.com>>; Liming Gao
> mailto:gaolim...@byosoft.com.cn>>; Laszlo Ersek 
> mailto:ler...@redhat.com>>; Paolo
> Bonzini mailto:pbonz...@redhat.com>>
> Subject: Re: [edk2-devel] [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack
> overflow issue due to nested interrupts
>
> On 29/02/2024 13:02, Ni, Ray wrote:
> > 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.
>
> NACK.  This breaks the specification-defined behaviour for
> RestoreTPL().
>
> What guarantees do we have that there is no code anywhere in the world
> that relies upon RestoreTPL() unconditionally re-enabling interrupts.
>
> I also find this code substantially harder to follow than
> NestedInterruptTplLib (which does not break any specified behaviour).
>
> Thanks,
>
> Michael



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116182): https://edk2.groups.io/g/devel/message/116182
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 Bonzini]

On 2/29/24 14:02, Ray Ni wrote:

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.


How do non-OVMF platforms solve the issue?  Do they just have the same 
bug as in https://bugzilla.tianocore.org/show_bug.cgi?id=4162 ?


The design of NestedInterruptTplLib is that each nested interrupt must 
increase the TPL, but if I understand correctly there is a hole here:


  //
  // Call RestoreTPL() to allow event notifications to be
  // dispatched.  This will implicitly re-enable interrupts.
  //
  gBS->RestoreTPL (InterruptedTPL);

  //
  // Re-disable interrupts after the call to RestoreTPL() to ensure
  // that we have exclusive access to the shared state.
  //
  DisableInterrupts ();

because gBS->RestoreTPL will unconditionally enable interrupts if 
InterruptedTPL < TPL_HIGH_LEVEL.



If possible, the easiest solution would be to merge 
NestedInterruptTplLib into Core DXE.  This way, instead of calling 
gBS->RestoreTPL, NestedInterruptTplLib can call a custom version of 
CoreRestoreTpl that exits with interrupts disabled.  That is, something like


VOID EFIAPI CoreRestoreTplInternal(IN EFI_TPL NewTpl,
   IN BOOLEAN InterruptState)
{
  //
  // The caller can request disabled interrupts to access shared
  // state, but TPL_HIGH_LEVEL must *not* have them enabled.
  //
  ASSERT(!(NewTpl == TPL_HIGH_LEVEL && InterruptState));

  // ...

  gEfiCurrentTpl = NewTpl;
  CoreSetInterruptState (InterruptState);
}

Now, CoreRestoreTpl is just

  //
  // If lowering below HIGH_LEVEL, make sure
  // interrupts are enabled
  //
  CoreRestoreTplInternal(NewTpl, NewTpl < TPL_HIGH_LEVEL);

whereas NestedInterruptRestoreTPL can do

  //
  // Call RestoreTPL() to allow event notifications to be
  // dispatched.  This will implicitly re-enable interrupts,
  // but only if events have to be dispatched.
  //
  CoreRestoreTplInternal(InterruptedTPL, FALSE);

  //
  // Interrupts are now disabled, so we can access shared state.
  //

This avoids the unlimited nesting of interrupts because each stack frame 
will indeed have a higher TPL than the outer version.


Paolo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116181): https://edk2.groups.io/g/devel/message/116181
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 v2] SecurityPkg/SecureBootConfigDxe: Update UI according to UEFI spec

[Felix Polyudov via groups.io]

Reviewed-by: Felix Polyudov 

-Original Message-
From: Tan, Ming 
Sent: Wednesday, February 28, 2024 10:32 PM
To: Yao, Jiewen ; devel@edk2.groups.io; Pingle, Sneha S 
; Felix Polyudov ; Bi, Dandan 

Cc: Xu, Min M 
Subject: [EXTERNAL] RE: [PATCH v2] SecurityPkg/SecureBootConfigDxe: Update UI 
according to UEFI spec


**CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.**

Jiewen:
  This patch is only for UEFI spec mantis 1908 change in SecureBootConfigDxe.
  This spec change just ask some drivers do some modification, it does not ask 
the HII core to be modified, so this spec change will not cause compatibility 
issue.

  For this patch, it only touch the UI setting, did not touch the modification 
of pk, kek, db, dbx, dbt EFI variable.
  I did the following unit test in EmulatorPkg WinHost.exe and Intel AlderLake 
RVP:
  1. In PK Options, Enroll PK, check the "Attempt Secure Boot" is not gray and 
enabled.
  2. In RVP, Set "Attempt Secure Boot" to enable and disable, check it does 
work, and device can boot to Windows.
  3. In PK Options, delete PK, check the "Attempt Secure Boot" is gray and 
disabled.
  4. In DBX Options, Enroll Signature, check it does work, and the "Delete All 
Signature List" is not gray.
  5. In DBX Options, Delete all signature, check it does work, and the "Delete 
All Signature List" is gray after all signatures are deleted.
  6. In KEK Options, Enroll KEK, check it does work.
  7. In KEK Options, Delete KEK, check it does work.
  8. In DB Options, Enroll Signature, check it does work.
  9. In DB Options, Delete Signature, check it does work.
  10. In DBT Options, Enroll Signature, check it does work.
  11. In DBT Options, Delete Signature, check it does work.

  @Pingle, Sneha S Would you like to help to verify the secure boot functions 
again in another Intel RVP?
  @Felix Polyudov Would you like to help to verify this patch with AMI browser? 
Since AMI submitted this UEFI spec change, if verify pass, would you like to 
add a "Reviewed-by' for this patch?
  @Bi, Dandan is HII expert and the reviewer of edk2 HII and UI modules, would 
you like to review this patch? And add a "Reviewed-by" for this patch?


  And I create a PR for this patch: 
https://github.com/tianocore/edk2/pull/5411, all CI checking are passed.

  Thank you.
  Tan Ming.


-Original Message-
From: Yao, Jiewen 
Sent: Wednesday, February 28, 2024 1:56 PM
To: Tan, Ming ; devel@edk2.groups.io
Cc: Xu, Min M 
Subject: RE: [PATCH v2] SecurityPkg/SecureBootConfigDxe: Update UI according to 
UEFI spec

Thanks for the update.

First, would you please clarify which test you have done for this patch set.
Have you tested all previous function to ensure it still works?

Second, would you please clarify if there is any compatibility issue to follow 
the new UEFI 2.10?
For example, what if the core HII is still UEFI 2.9? would that still work?

Third, because I am not HII expert, I would like to have HII expert to comment 
the HII/Browser related change.

Thank you
Yao, Jiewen

> -Original Message-
> From: Tan, Ming 
> Sent: Tuesday, February 27, 2024 10:59 AM
> To: devel@edk2.groups.io
> Cc: Xu, Min M ; Yao, Jiewen 
> Subject: [PATCH v2] SecurityPkg/SecureBootConfigDxe: Update UI
> according to UEFI spec
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4713
>
> In UEFI_Spec_2_10_Aug29.pdf page 1694 section 35.5.4 for
> EFI_BROWSER_ACTION_FORM_OPEN:
> NOTE: EFI_FORM_BROWSER2_PROTOCOL.BrowserCallback() cannot be used with
> this browser action because question values have not been retrieved yet.
>
> So should not call HiiGetBrowserData() and HiiSetBrowserData() in
> FORM_OPEN call back function.
>
> Now call SecureBootExtractConfigFromVariable() to save the change to
> EFI variable, then HII use EFI variable to control the UI.
>
> Cc: Min Xu 
> Cc: Jiewen Yao 
> Signed-off-by: Ming Tan 
> ---
>   V2: Change code style to pass uncrustify check.
>
>  .../SecureBootConfigImpl.c| 37 ++-
>  1 file changed, 20 insertions(+), 17 deletions(-)
>
> diff --git
> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConf
> igIm
> pl.c
> b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConf
> igIm
> pl.c
> index 2c11129526..e2e61d1e07 100644
> ---
> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConf
> igIm
> pl.c
> +++
> b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConf
> igIm
> pl.c
> @@ -3366,6 +3366,8 @@ SecureBootExtractConfigFromVariable (
>  ConfigData->FileEnrollType = UNKNOWN_FILE_TYPE;
>
>}
>
>
>
> +  ConfigData->ListCount = Private->ListCount;
>
> +
>
>//
>
>// If it is Physical Presence User, set the PhysicalPresent to true.
>
>//
>
> @@ -4541,12 +4543,13 @@ SecureBootCallback (
>EFI_HII_POPUP_PROTOCOL  *HiiPopup;
>
>EFI_HII_POPUP_SELECTION UserSelection;
>
>

Re: [edk2-devel] [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack overflow issue due to nested interrupts

[Paolo Bonzini]

Il gio 29 feb 2024, 17:45 Kinney, Michael D  ha
scritto:

> Hi Michael,
>
> Can you provide a pointer to the UEFI Spec statement this breaks?
>

The spec does say that interrupts are disabled for TPL_HIGH_LEVEL, but
indeed it doesn't say they are always enabled at lower levels. However, if
the interrupts aren't always enabled whenever you're below TPL_HIGH_LEVEL,
you get priority inversions (and deadlocks).

For example, if you end up running with interrupts disabled at
TPL_CALLBACK, you are disabling the dispatching of timers at TPL_NOTIFY.

I guess this can be deduced from these two passages:

- "The functions in these queues are invoked in FIFO order, starting with
the highest priority level queue and proceeding to the lowest priority
queue that is unmasked by the current TPL"

- "If Type is TimerRelative and TriggerTime is 0, then the timer event will
be signaled on the next timer tick" (in the description of gBS->SetTimer)

Paolo


> Thanks,
>
> Mike
>
> > -Original Message-
> > From: Michael Brown 
> > Sent: Thursday, February 29, 2024 5:23 AM
> > To: devel@edk2.groups.io; Ni, Ray 
> > Cc: Kinney, Michael D ; Liming Gao
> > ; Laszlo Ersek ; Paolo
> > Bonzini 
> > Subject: Re: [edk2-devel] [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack
> > overflow issue due to nested interrupts
> >
> > On 29/02/2024 13:02, Ni, Ray wrote:
> > > 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.
> >
> > NACK.  This breaks the specification-defined behaviour for
> > RestoreTPL().
> >
> > What guarantees do we have that there is no code anywhere in the world
> > that relies upon RestoreTPL() unconditionally re-enabling interrupts.
> >
> > I also find this code substantially harder to follow than
> > NestedInterruptTplLib (which does not break any specified behaviour).
> >
> > Thanks,
> >
> > Michael
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116179): https://edk2.groups.io/g/devel/message/116179
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

[Michael Brown]

On 29/02/2024 16:43, Kinney, Michael D wrote:

Hi Michael,

Can you provide a pointer to the UEFI Spec statement this breaks?


II-9.7.1.3 RestoreTPL():

"When the DXE Foundation is notified that the EFI_CPU_ARCH_PROTOCOL has 
been installed, then the full version of the Boot Service RestoreTPL() 
can be made available.  When an attempt is made to restore the TPL level 
to level below EFI_TPL_HIGH_LEVEL, then the DXE Foundation should use 
the services of the EFI_CPU_ARCH_PROTOCOL to enable interrupts."


I suspect this is sufficient to veto the proposed design, though we 
could argue that the loosely worded "should" is technically not "must".



If we still want to proceed with this design, then I have several other 
questions:


- How does the proposed patch react to an interrupt occurring 
(illegally) at TPL_HIGH_LEVEL (as happens with some versions of 
Windows)?  As far as I can tell, it will result in mInterruptedTplMask 
having bit 31 set but never cleared.  What impact will this have?


- How does the proposed patch react to potentially mismatched 
RaisedTPL()/RestoreTPL() calls (e.g. oldTpl = RaiseTPL(TPL_CALLBACK) 
followed by RaiseTPL(TPL_NOTIFY) followed by a single RestoreTPL(oldTpl))?



I believe the proposed patch is attempting to establish a new invariant 
as follows:


Once an interrupt has occured at a given TPL, then that *TPL* is 
conceptually considered to be in an "interrupted" state.  The *only* 
thing that can clear this "interrupted" state from the TPL is to return 
from the interrupt handler.


Note that this conceptual definition does not perfectly align with the 
bit flags in mInterruptedTplMask, since those bits will necessarily be 
set only some time after the interrupt occurs, and will have to be 
cleared before returning from the interrupt.  However, it is the 
conceptual definition that is relevant to the invariant.


The new invariant is that no code may execute at an "interrupted" TPL 
with interrupts enabled.  It is legitimate for code to raise to a higher 
TPL and to enable interrupts while there, and it is legitimate for code 
to execute in an "interrupted" TPL with interrupts disabled, but it is 
not legitimate for any code to reenable interrupts while still at an 
"interrupted" TPL.


It would be good to call out this invariant explicitly, so that authors 
of interrupt handlers are aware of the restrictions.  It would also 
clarify some of the logic (e.g. it provides the reason why interrupts 
must be disabled before lowering gEfiCurrentTpl in CoreRestoreTpl()).


It's also generally easier to reason about a stated invariant than to 
extrapolate from a list of complicated examples.


Thanks,

Michael



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116178): https://edk2.groups.io/g/devel/message/116178
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

[Michael D Kinney]

Hi Michael,

Can you provide a pointer to the UEFI Spec statement this breaks?

Thanks,

Mike 

> -Original Message-
> From: Michael Brown 
> Sent: Thursday, February 29, 2024 5:23 AM
> To: devel@edk2.groups.io; Ni, Ray 
> Cc: Kinney, Michael D ; Liming Gao
> ; Laszlo Ersek ; Paolo
> Bonzini 
> Subject: Re: [edk2-devel] [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack
> overflow issue due to nested interrupts
> 
> On 29/02/2024 13:02, Ni, Ray wrote:
> > 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.
> 
> NACK.  This breaks the specification-defined behaviour for
> RestoreTPL().
> 
> What guarantees do we have that there is no code anywhere in the world
> that relies upon RestoreTPL() unconditionally re-enabling interrupts.
> 
> I also find this code substantially harder to follow than
> NestedInterruptTplLib (which does not break any specified behaviour).
> 
> Thanks,
> 
> Michael



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116177): https://edk2.groups.io/g/devel/message/116177
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 09/10] OvmfPkg/ResetVector: leave SEV VC handler installed longer

[Lendacky, Thomas via groups.io]

On 2/22/24 05:54, Gerd Hoffmann wrote:

When running in SEV mode keep the VC handler installed.
Add a function to uninstall it later.

This allows using the cpuid instruction in SetCr3ForPageTables64,
which is needed to check for la57 & 1G page support.

Signed-off-by: Gerd Hoffmann 


Looks good, just one minor comment below.

Reviewed-by: Tom Lendacky 


---
  OvmfPkg/ResetVector/Ia32/AmdSev.asm   | 12 ++--
  OvmfPkg/ResetVector/Ia32/PageTables64.asm |  1 +
  OvmfPkg/ResetVector/Main.asm  |  4 
  3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/ResetVector/Ia32/AmdSev.asm 
b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
index ed94f1dc668f..9063ce1080d3 100644
--- a/OvmfPkg/ResetVector/Ia32/AmdSev.asm
+++ b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
@@ -320,9 +320,9 @@ NoSevEsVcHlt:
  NoSevPass:
  xor   eax, eax
  
-SevExit:

  ;
-; Clear exception handlers and stack
+; When NOT running in SEV mode: clear exception handlers and stack here.
+; Otherwise: SevClearVcHandlerAndStack must be called later.
  ;
  push  eax
  mov   eax, ADDR_OF(IdtrClear)
@@ -330,8 +330,16 @@ SevExit:
  pop   eax
  mov   esp, 0
  
+SevExit:

  OneTimeCallRet CheckSevFeatures
  
+SevClearVcHandlerAndStack:

+; Clear exception handlers and stack
+mov   eax, ADDR_OF(IdtrClear)
+lidt  [cs:eax]
+mov   esp, 0
+OneTimeCallRet SevClearVcHandlerAndStack
+
  ; Start of #VC exception handling routines
  ;
  
diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm b/OvmfPkg/ResetVector/Ia32/PageTables64.asm

index ada3dc0ffbe0..6e2063430802 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
@@ -250,6 +250,7 @@ SevInit:
  CreatePageTables4Level edx
  ; Clear the C-bit from the GHCB page if the SEV-ES is enabled.
  OneTimeCall   SevClearPageEncMaskForGhcbPage
+OneTimeCall   SevClearVcHandlerAndStack
  jmp SetCr3
  
  TdxBspInit:

diff --git a/OvmfPkg/ResetVector/Main.asm b/OvmfPkg/ResetVector/Main.asm
index 46cfa87c4c0a..88b25db3bc9e 100644
--- a/OvmfPkg/ResetVector/Main.asm
+++ b/OvmfPkg/ResetVector/Main.asm
@@ -80,7 +80,11 @@ SearchBfv:
  ; Set the OVMF/SEV work area as appropriate.
  ;
  OneTimeCall CheckSevFeatures
+cmp byte[WORK_AREA_GUEST_TYPE], 1
+jnz NoSevIa32
+OneTimeCall SevClearVcHandlerAndStack


I think it is safe to invoke SevClearVcHandlerAndStack no matter what if 
you want to avoid the cmp and jnz instructions.


Thanks,
Tom

  
+NoSevIa32:

  ;
  ; Restore initial EAX value into the EAX register
  ;



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116176): https://edk2.groups.io/g/devel/message/116176
Mute This Topic: https://groups.io/mt/104506799/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 0/3] RISC-V Edk2 Server Platform Reference board

[Chai, Evan]

1. Create qemu-based server reference board.
2. Fixed the hotkeys not working in SCT UI.

Evan Chai (3):
  RISC-V/PlatformBootManagerLib: add terminal interaction interface
  RiscVPlatformPkg: introduce more Pcds for PCI initialization
  RiscVQemuServerPlatform: create qemu-based server reference board

 
Platform/Qemu/RiscVQemuServerPlatform/Documents/Media/Hand-Off-Block-Hob-List.jpg
   | Bin 0 -> 16901 bytes
 Platform/Qemu/RiscVQemuServerPlatform/Documents/Media/PI_Boot_Phases.jpg   
 | Bin 0 -> 196120 bytes
 
Platform/Qemu/RiscVQemuServerPlatform/Documents/Media/RISC-V_Platform_EDK2_Firmware_Enabling_Philosophy.jpg
 | Bin 0 -> 329871 bytes
 Platform/Qemu/RiscVQemuServerPlatform/Documents/Media/V2_DXE_Foundation-3.jpg  
 | Bin 0 -> 51521 bytes
 
Platform/Qemu/RiscVQemuServerPlatform/Library/PciHostBridgeLibEcam/PciHostBridgeLibEcam.c
   | 386 
++
 
Platform/Qemu/RiscVQemuServerPlatform/Library/PciHostBridgeLibEcam/PciHostBridgeLibEcam.inf
 |  49 
 
Platform/Qemu/RiscVQemuServerPlatform/Library/VirtNorFlashPlatformLib/VirtNorFlashStaticLib.c
   |  42 ++
 
Platform/Qemu/RiscVQemuServerPlatform/Library/VirtNorFlashPlatformLib/VirtNorFlashStaticLib.inf
 |  32 
 Platform/Qemu/RiscVQemuServerPlatform/Readme.md
 | 327 

 Platform/Qemu/RiscVQemuServerPlatform/RiscVQemuServerPlatform.dsc  
 | 703 
+++
 Platform/Qemu/RiscVQemuServerPlatform/RiscVQemuServerPlatform.fdf  
 | 284 
++
 Platform/Qemu/RiscVQemuServerPlatform/RiscVQemuServerPlatform.fdf.inc  
 |  42 ++
 Platform/Qemu/RiscVQemuServerPlatform/Sec/Cpu.c
 |  33 +
 Platform/Qemu/RiscVQemuServerPlatform/Sec/Memory.c 
 | 318 
+++
 Platform/Qemu/RiscVQemuServerPlatform/Sec/Platform.c   
 | 160 
+
 Platform/Qemu/RiscVQemuServerPlatform/Sec/SecEntry.S   
 |  19 +++
 Platform/Qemu/RiscVQemuServerPlatform/Sec/SecMain.c
 | 110 

 Platform/Qemu/RiscVQemuServerPlatform/Sec/SecMain.h
 | 104 
++

[edk2-devel] [PATCH 2/3] RiscVPlatformPkg: introduce more Pcds for PCI initialization

[Chai, Evan]

It is assumed that the current system only supports a single RC
model.

Cc: Andrei Warkentin 
Cc: Sunil V L 
Cc: Yong Li 
Signed-off-by: Evan Chai 
---
 Platform/RISC-V/PlatformPkg/RiscVPlatformPkg.dec | 16 
 1 file changed, 16 insertions(+)

diff --git a/Platform/RISC-V/PlatformPkg/RiscVPlatformPkg.dec 
b/Platform/RISC-V/PlatformPkg/RiscVPlatformPkg.dec
index b45f48fd..8eeafb2b 100644
--- a/Platform/RISC-V/PlatformPkg/RiscVPlatformPkg.dec
+++ b/Platform/RISC-V/PlatformPkg/RiscVPlatformPkg.dec
@@ -1,6 +1,7 @@
 ## @file  RiscVPlatformPkg.dec
 # This Package provides UEFI RISC-V platform modules and libraries.
 #
+# Copyright (c) 2024, Intel Corporation. All rights reserved.
 # Copyright (c) 2021-2022, Hewlett Packard Enterprise Development LP. All 
rights reserved.
 #
 # SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -89,6 +90,21 @@
 [PcdsFeatureFlag]
 
 [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
+  #
+  # RC initialization
+  #
+  gUefiRiscVPlatformPkgTokenSpaceGuid.PcdPciIoBase|0x0|UINT64|0x1200
+  gUefiRiscVPlatformPkgTokenSpaceGuid.PcdPciIoSize|0x0|UINT64|0x1201
+  gUefiRiscVPlatformPkgTokenSpaceGuid.PcdPciMmio32Base|0x0|UINT32|0x1202
+  gUefiRiscVPlatformPkgTokenSpaceGuid.PcdPciMmio32Size|0x0|UINT32|0x1203
+  gUefiRiscVPlatformPkgTokenSpaceGuid.PcdPciMmio64Base|0x0|UINT64|0x1204
+  gUefiRiscVPlatformPkgTokenSpaceGuid.PcdPciMmio64Size|0x0|UINT64|0x1205
+
+  #
+  # Inclusive range of allowed PCI buses.
+  #
+  gUefiRiscVPlatformPkgTokenSpaceGuid.PcdPciBusMin|0x0|UINT32|0x1206
+  gUefiRiscVPlatformPkgTokenSpaceGuid.PcdPciBusMax|0x0|UINT32|0x1207
 
 [UserExtensions.TianoCore."ExtraFiles"]
   RiscVPlatformPkgExtra.uni
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116173): https://edk2.groups.io/g/devel/message/116173
Mute This Topic: https://groups.io/mt/104645142/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 1/3] RISC-V/PlatformBootManagerLib: add terminal interaction interface

[Chai, Evan]

Fixed the hotkey not wokring in SCT(like F5, F6, F9, etc...),
causing all SCT tests to be run only through the command line.
This change provides a standard terminal interaction interface
in the UEFI environment.

Cc: Andrei Warkentin 
Cc: Sunil V L 
Cc: Yong Li 
Signed-off-by: Evan Chai 
---
 
Platform/RISC-V/PlatformPkg/Library/PlatformBootManagerLib/PlatformBootManager.c
  |  7 ++-
 
Platform/RISC-V/PlatformPkg/Library/PlatformBootManagerLib/PlatformBootManager.h
  | 12 +++-
 
Platform/RISC-V/PlatformPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
 |  2 ++
 Platform/RISC-V/PlatformPkg/Library/PlatformBootManagerLib/PlatformData.c  
   | 15 ++-
 4 files changed, 33 insertions(+), 3 deletions(-)

diff --git 
a/Platform/RISC-V/PlatformPkg/Library/PlatformBootManagerLib/PlatformBootManager.c
 
b/Platform/RISC-V/PlatformPkg/Library/PlatformBootManagerLib/PlatformBootManager.c
index 21667f42..c2336a07 100644
--- 
a/Platform/RISC-V/PlatformPkg/Library/PlatformBootManagerLib/PlatformBootManager.c
+++ 
b/Platform/RISC-V/PlatformPkg/Library/PlatformBootManagerLib/PlatformBootManager.c
@@ -2,7 +2,7 @@
   This file include all platform actions
 
 Copyright (c) 2021-2022, Hewlett Packard Enterprise Development LP. All rights 
reserved.
-Copyright (c) 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2024, Intel Corporation. All rights reserved.
 
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -169,6 +169,11 @@ PlatformBootManagerBeforeConsole (
   //
   EfiEventGroupSignal (&gEfiEndOfDxeEventGroupGuid);
 
+  //
+  // Add the hardcoded serial console device path to ConIn, ConOut, ErrOut.
+  //
+  PlatformUefiEnvHotkeyRegister ();
+
   //
   // Update the console variables.
   //
diff --git 
a/Platform/RISC-V/PlatformPkg/Library/PlatformBootManagerLib/PlatformBootManager.h
 
b/Platform/RISC-V/PlatformPkg/Library/PlatformBootManagerLib/PlatformBootManager.h
index 7da15b01..8b71045f 100644
--- 
a/Platform/RISC-V/PlatformPkg/Library/PlatformBootManagerLib/PlatformBootManager.h
+++ 
b/Platform/RISC-V/PlatformPkg/Library/PlatformBootManagerLib/PlatformBootManager.h
@@ -2,7 +2,7 @@
Head file for BDS Platform specific code
 
 Copyright (c) 2016, Hewlett Packard Enterprise Development LP. All rights 
reserved.
-Copyright (c) 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2024, Intel Corporation. All rights reserved.
 
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -106,4 +106,14 @@ PlatformBootManagerShowProgress (
   IN UINTN  PreviousValue
   );
 
+/**
+  It provides a standard interface for interacting with terminal devices in
+  the UEFI environment.
+**/
+VOID
+EFIAPI
+PlatformUefiEnvHotkeyRegister (
+  VOID
+  );
+
 #endif // _PLATFORM_BOOT_MANAGER_H
diff --git 
a/Platform/RISC-V/PlatformPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
 
b/Platform/RISC-V/PlatformPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index caefae3b..0dd0cd67 100644
--- 
a/Platform/RISC-V/PlatformPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ 
b/Platform/RISC-V/PlatformPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -2,6 +2,7 @@
 #  Include all platform action which can be customized by IBV/OEM.
 #
 #  Copyright (c) 2021, Hewlett Packard Enterprise Development LP. All rights 
reserved.
+#  Copyright (c) 2024, Intel Corporation. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -42,6 +43,7 @@
 
 [Guids]
   gEfiEndOfDxeEventGroupGuid
+  gEfiTtyTermGuid
 
 [Protocols]
   gEfiGenericMemTestProtocolGuid  ## CONSUMES
diff --git 
a/Platform/RISC-V/PlatformPkg/Library/PlatformBootManagerLib/PlatformData.c 
b/Platform/RISC-V/PlatformPkg/Library/PlatformBootManagerLib/PlatformData.c
index 4a79c6ca..3b66f3c8 100644
--- a/Platform/RISC-V/PlatformPkg/Library/PlatformBootManagerLib/PlatformData.c
+++ b/Platform/RISC-V/PlatformPkg/Library/PlatformBootManagerLib/PlatformData.c
@@ -3,7 +3,7 @@
   ConIn/ConOut variables.
 
 Copyright (c) 2019, Hewlett Packard Enterprise Development LP. All rights 
reserved.
-Copyright (c) 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2024, Intel Corporation. All rights reserved.
 
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -51,3 +51,16 @@ PLATFORM_CONSOLE_CONNECT_ENTRY  gPlatformConsole[] = {
 0
   }
 };
+
+/**
+  It provides a standard interface for interacting with terminal devices in
+  the UEFI environment.
+**/
+VOID
+EFIAPI
+PlatformUefiEnvHotkeyRegister (
+  VOID
+  )
+{
+  CopyGuid (&gSerialConsoleDevicePath0.TerminalType.Guid, &gEfiTtyTermGuid);
+}
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116172): https://edk2.groups.io/g/devel/message/116172
Mute This Topic: https://groups.io/mt/104645138/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...

[edk2-devel] [PATCH 0/3] RISC-V Edk2 Server Platform Reference board

[Chai, Evan]

1. Create qemu-based server reference board.
2. Fixed the hotkeys not working in SCT UI.

Evan Chai (3):
  RISC-V/PlatformBootManagerLib: add terminal interaction interface
  RiscVPlatformPkg: introduce more Pcds for PCI initialization
  RiscVQemuServerPlatform: create qemu-based server reference board

 
Platform/Qemu/RiscVQemuServerPlatform/Documents/Media/Hand-Off-Block-Hob-List.jpg
   | Bin 0 -> 16901 bytes
 Platform/Qemu/RiscVQemuServerPlatform/Documents/Media/PI_Boot_Phases.jpg   
 | Bin 0 -> 196120 bytes
 
Platform/Qemu/RiscVQemuServerPlatform/Documents/Media/RISC-V_Platform_EDK2_Firmware_Enabling_Philosophy.jpg
 | Bin 0 -> 329871 bytes
 Platform/Qemu/RiscVQemuServerPlatform/Documents/Media/V2_DXE_Foundation-3.jpg  
 | Bin 0 -> 51521 bytes
 
Platform/Qemu/RiscVQemuServerPlatform/Library/PciHostBridgeLibEcam/PciHostBridgeLibEcam.c
   | 386 
++
 
Platform/Qemu/RiscVQemuServerPlatform/Library/PciHostBridgeLibEcam/PciHostBridgeLibEcam.inf
 |  49 
 
Platform/Qemu/RiscVQemuServerPlatform/Library/VirtNorFlashPlatformLib/VirtNorFlashStaticLib.c
   |  42 ++
 
Platform/Qemu/RiscVQemuServerPlatform/Library/VirtNorFlashPlatformLib/VirtNorFlashStaticLib.inf
 |  32 
 Platform/Qemu/RiscVQemuServerPlatform/Readme.md
 | 327 

 Platform/Qemu/RiscVQemuServerPlatform/RiscVQemuServerPlatform.dsc  
 | 703 
+++
 Platform/Qemu/RiscVQemuServerPlatform/RiscVQemuServerPlatform.fdf  
 | 284 
++
 Platform/Qemu/RiscVQemuServerPlatform/RiscVQemuServerPlatform.fdf.inc  
 |  42 ++
 Platform/Qemu/RiscVQemuServerPlatform/Sec/Cpu.c
 |  33 +
 Platform/Qemu/RiscVQemuServerPlatform/Sec/Memory.c 
 | 318 
+++
 Platform/Qemu/RiscVQemuServerPlatform/Sec/Platform.c   
 | 160 
+
 Platform/Qemu/RiscVQemuServerPlatform/Sec/SecEntry.S   
 |  19 +++
 Platform/Qemu/RiscVQemuServerPlatform/Sec/SecMain.c
 | 110 

 Platform/Qemu/RiscVQemuServerPlatform/Sec/SecMain.h
 | 104 
++

Re: [edk2-devel] [PATCH v2 00/23] Provide SEV-SNP support for running under an SVSM

[Lendacky, Thomas via groups.io]

On 2/29/24 08:06, Yao, Jiewen wrote:

Below:


-Original Message-
From: Tom Lendacky 
Sent: Thursday, February 29, 2024 12:20 AM
To: Yao, Jiewen ; devel@edk2.groups.io
Cc: Ard Biesheuvel ; Aktas, Erdem
; Gerd Hoffmann ; Laszlo Ersek
; Liming Gao ; Kinney, Michael
D ; Xu, Min M ; Liu,
Zhiguang ; Kumar, Rahul R ;
Ni, Ray ; Michael Roth 
Subject: Re: [PATCH v2 00/23] Provide SEV-SNP support for running under an
SVSM

On 2/28/24 00:14, Yao, Jiewen wrote:

Some feedback:

1) 0002-MdePkg-GHCB-APIC-ID-retrieval-support-definitions

MdePkg only contains the definition in the standard.

Question: Is EFI_APIC_IDS_GUID definition in some AMD/SVSM specification?


The structure is documented in the GHCB specification, but the GUID is not.

Is the request to move the GUID to someplace other than MdePkg?


[Jiewen] Right. If the GUID is NOT in GHCB spec, then it should be in other 
place, such as OvmfPkg.


Sounds good. I'll move to the UefiCpuPkg since MpInitLib will be using it.








2) 0012-UefiCpuPkg-CcSvsmLib-Create-the-CcSvsmLib-library-to-support-an-

SVSM


I am not sure the position of SVSM.
If the SVSM interface is AMD specific, the it should be AmdSvsmLib.


I believe TDX is also looking at the SVSM for TDX partitioning, but I'm
not certain of that.


If the SVSM interface is generic, then we should define everything in a generic

way.


It is very confusing to mix a generic CcSvsm lib with AMD specific

.

I can certainly change the name to be AMD specific fow now. It can always
be changed to something else later if need be, much like VmgExitLib was
changed to CcExitLib.


[Jiewen] Yes, Intel is planning for SVSM. But it is NOT ready yet.
It is hard for me to discuss it now.

Maybe, please help me understand:
Is CcSvsmLib a generic library / common protocol between OVMF and Coconut-SVSM? 
- Option 1
Or is CcSvsmLib an implementation specific library, and the current API cannot 
be shared with Intel TDX in future? - Option 2

I notice that some API is for option 1 - CcSvsmIsSvsmPresent().
But some API is for option 2 - CcSvsmSnpGetVmpl(), CcSvsmSnpGetCaa(), 
CcSvsmSnpPvalidate(), CcSvsmSnpVmsaRmpAdjust().

How do you plan if TDX need to support SVSM later?
How do you plan if we need to add some generic interaction between OVMF and 
coconut-SVSM, such as vTPM?


There are definitely some things that will be common, 
CcSvsmIsSvsmPresent() and CcSvsmSnpGetCaa(), and some things that will be 
SNP or TDX specific. For example, the concept of turning a page into a 
VMSA page or how the SVSM will be invoked will be different.


For now, I'll create an AMD specific library and then when TDX is ready to 
support an SVSM we can look to see how or what needs to be changed. It 
could be that they need to remain separate if there is not enough in common.


Thanks,
Tom







Thanks,
Tom




Thank you
Yao, Jiewen


-Original Message-
From: Tom Lendacky 
Sent: Friday, February 23, 2024 1:30 AM
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 v2 00/23] Provide SEV-SNP support for running under an SVSM


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 CcSvsmLib library that is used by MpInitLib.
This requires an update to the edk2-platform DSC files to add the new
library. The edk2-platform change would be needed after patch 12, but
before patch 15.

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 dir

Re: [edk2-devel] [PATCH v2 00/23] Provide SEV-SNP support for running under an SVSM

[Yao, Jiewen]

Below:

> -Original Message-
> From: Tom Lendacky 
> Sent: Thursday, February 29, 2024 12:20 AM
> To: Yao, Jiewen ; devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Aktas, Erdem
> ; Gerd Hoffmann ; Laszlo Ersek
> ; Liming Gao ; Kinney, Michael
> D ; Xu, Min M ; Liu,
> Zhiguang ; Kumar, Rahul R ;
> Ni, Ray ; Michael Roth 
> Subject: Re: [PATCH v2 00/23] Provide SEV-SNP support for running under an
> SVSM
> 
> On 2/28/24 00:14, Yao, Jiewen wrote:
> > Some feedback:
> >
> > 1) 0002-MdePkg-GHCB-APIC-ID-retrieval-support-definitions
> >
> > MdePkg only contains the definition in the standard.
> >
> > Question: Is EFI_APIC_IDS_GUID definition in some AMD/SVSM specification?
> 
> The structure is documented in the GHCB specification, but the GUID is not.
> 
> Is the request to move the GUID to someplace other than MdePkg?

[Jiewen] Right. If the GUID is NOT in GHCB spec, then it should be in other 
place, such as OvmfPkg.


> 
> >
> > 2) 0012-UefiCpuPkg-CcSvsmLib-Create-the-CcSvsmLib-library-to-support-an-
> SVSM
> >
> > I am not sure the position of SVSM.
> > If the SVSM interface is AMD specific, the it should be AmdSvsmLib.
> 
> I believe TDX is also looking at the SVSM for TDX partitioning, but I'm
> not certain of that.
> 
> > If the SVSM interface is generic, then we should define everything in a 
> > generic
> way.
> >
> > It is very confusing to mix a generic CcSvsm lib with AMD specific
> .
> 
> I can certainly change the name to be AMD specific fow now. It can always
> be changed to something else later if need be, much like VmgExitLib was
> changed to CcExitLib.

[Jiewen] Yes, Intel is planning for SVSM. But it is NOT ready yet.
It is hard for me to discuss it now.

Maybe, please help me understand:
Is CcSvsmLib a generic library / common protocol between OVMF and Coconut-SVSM? 
- Option 1
Or is CcSvsmLib an implementation specific library, and the current API cannot 
be shared with Intel TDX in future? - Option 2

I notice that some API is for option 1 - CcSvsmIsSvsmPresent().
But some API is for option 2 - CcSvsmSnpGetVmpl(), CcSvsmSnpGetCaa(), 
CcSvsmSnpPvalidate(), CcSvsmSnpVmsaRmpAdjust().

How do you plan if TDX need to support SVSM later?
How do you plan if we need to add some generic interaction between OVMF and 
coconut-SVSM, such as vTPM?



> 
> Thanks,
> Tom
> 
> >
> >
> > Thank you
> > Yao, Jiewen
> >
> >> -Original Message-
> >> From: Tom Lendacky 
> >> Sent: Friday, February 23, 2024 1:30 AM
> >> 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 v2 00/23] Provide SEV-SNP support for running under an SVSM
> >>
> >>
> >> 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 CcSvsmLib library that is used by MpInitLib.
> >> This requires an update to the edk2-platform DSC files to add the new
> >> library. The edk2-platform change would be needed after patch 12, but
> >> before patch 15.
> >>
> >> 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
> >>

Re: [edk2-devel] [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack overflow issue due to nested interrupts

[Michael Brown]

On 29/02/2024 13:02, Ni, Ray wrote:

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.


NACK.  This breaks the specification-defined behaviour for RestoreTPL().

What guarantees do we have that there is no code anywhere in the world 
that relies upon RestoreTPL() unconditionally re-enabling interrupts.


I also find this code substantially harder to follow than 
NestedInterruptTplLib (which does not break any specified behaviour).


Thanks,

Michael



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116168): https://edk2.groups.io/g/devel/message/116168
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]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 2/2] MdeModulePkg/DxeCore: Fix stack overflow issue due to nested interrupts

[Ni, Ray]

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 interru

[edk2-devel] [PATCH 0/2] Fix stack overflow issue due to nested interrupts

[Ni, Ray]

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

[Ni, Ray]

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

[Ni, Ray]

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 = &SmiEntry->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

[Ni, Ray]

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 = &MmiEntry->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] Peims are not gettting Dispatched in EagleStream Platform

[memristor2 via groups.io]

I solved my issue it seems that I fo got to add the crucial PcdPei.inf peim 
(yes all this fuss for a simple mistake) to my fdf file thank you for your help 




Sent with Proton Mail secure email.

On Saturday, February 24th, 2024 at 5:41 PM, memristor2  
wrote:

> 
> 
> 
> 
> 
> Sent with Proton Mail secure email.
> 
> 
> On Saturday, February 24th, 2024 at 5:00 PM, memristor2 via groups.io 
> memristor2=proton...@groups.io wrote:
> 
> > Sent with Proton Mail secure email.
> > 
> > On Saturday, February 24th, 2024 at 12:15 AM, Desimone, Nathaniel L 
> > nathaniel.l.desim...@intel.com wrote:
> > 
> > > > -Original Message-
> > > > From: memristor2 memrist...@proton.me
> > > > Sent: Thursday, February 22, 2024 5:51 AM
> > > > To: Desimone, Nathaniel L nathaniel.l.desim...@intel.com
> > > > Cc: devel@edk2.groups.io; ler...@redhat.com
> > > > Subject: RE: [edk2-devel] Peims are not gettting Dispatched in 
> > > > EagleStream
> > > > Platform
> > > > 
> > > > Thank you. Based on what you told me (memory corruption and and the
> > > > unlikelihood of the stack pointer being NULL) my only suspicion would 
> > > > be the
> > > > microcode I am using, since the only platform dependent parts up until 
> > > > this
> > > > part would be the microcode and the FSP-T and since I am using the FSP 
> > > > for
> > > > EagleStream only the microcode would be left to change.
> > > 
> > > Having correct microcode is absolutely essential for sure. But microcode 
> > > & FSP
> > > are not the only platform dependent components. Any code contained in a
> > > *BoardPkg is considered to be platform dependent in some way. I would be
> > > surprised if simply adding the microcode will fix this problem.
> > > 
> > > > Up until now I was using Whitley's microcode (since EagleStream's 
> > > > hadn't been
> > > > released yet). To be honest I still don't have a proper comprehension 
> > > > of the
> > > > concept of the microcode so I thought maybe I could use Whitley's 
> > > > microcode.
> > > 
> > > Here is what microcode is in a nutshell. Every x86 processor designed 
> > > since
> > > ~1990 is actually a RISC-based CPU design internally. The microcode 
> > > contains a
> > > lookup table that maps each CPU instruction into one or more 
> > > sub-instructions
> > > (sometimes called micro-instructions or micro-OPs (µOPs for short)) which 
> > > are
> > > the instructions that the hidden RISC processor executes. This hidden RISC
> > > processor has an unpublished instruction set that no one outside of the 
> > > CPU
> > > vendor sees.
> > > 
> > > The initial purpose of RISC was to eliminate the need for microcode, as 
> > > the
> > > complex decode engine and ROM consumed transistors that could instead be 
> > > used
> > > for things like a wider ALU. But then in the mid-1990s, a new technology 
> > > came
> > > along called out-of-order execution. The idea behind out-of-order 
> > > execution is
> > > that we can expand the purpose of microcode to be more than just a lookup 
> > > table,
> > > it can actually change the sequence of micro-OPs so that the program runs
> > > faster. So now, microcode is not only a lookup table, but it also 
> > > provides a
> > > programmable instruction scheduler.
> > > 
> > > The use of out-of-order execution was made possible by Moore's law. 
> > > Moore's law
> > > drove rapidly increasing transistor counts during the 1990s. No longer 
> > > would you
> > > need to decide whether to use your transistor budget for microcode or for 
> > > a
> > > wider ALU... you had plenty of transistors so you could do both! Both of 
> > > them
> > > together yields the fastest CPU designs by a large margin. All of these 
> > > factors
> > > came together at once, and suddenly any CPU design that didn't use 
> > > microcode was
> > > obsolete by the year 2000.
> > > 
> > > Fast forward to today, the RISC vs. CISC argument is obsolete. Modern
> > > high-performance CPUs require very complex microcode. The existence of 
> > > that
> > > microcode abstracts most of the differences between traditionally RISC 
> > > ISAs like
> > > ARM and traditionally CISC ISAs like x86.
> > 
> > Thank you I just learned as much as I learned in my Advanced Computer 
> > Architecture course. Your explanations are higly appreciated.
> > 
> > > > But now that EagleStream's microcode has been released I'll try with 
> > > > that and
> > > > let you know whether it works or not. Yet I am still skeptical about it 
> > > > being
> > > > a microcode issue because my thought is that the microcode is procosser
> > > > architecture-based code rather than it being platform-based code. Please
> > > > correct me if I am wrong on this matter.
> > > 
> > > You intuition that it is not a microcode issue is correct. There are a 
> > > lot of
> > > things in the BoardPkg that change with each platform design. For an 
> > > example of
> > > that, try diff'ing KabylakeOpenBoardPkg with AlderlakeOpenBoardPkg.
> 
> I forgot to mention one thing

Re: [edk2-devel] [edk2-platforms][PATCH V2 1/1] Platform/ARM/N1Sdp: Route the Debug Serial Port to IOFPGA UART1

[Sami Mujawar]

Hi Sahil,

Thank you for this patch.

Reviewed-by: Sami Mujawar 

Regards,

Sami Mujawar


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116161): https://edk2.groups.io/g/devel/message/116161
Mute This Topic: https://groups.io/mt/103691696/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] The API in BaseCryptLib can't seed the pseudorandom number generator properly

[Li, Yi]

Hi Eddie,

There will be build error if you didn’t include OpensslLib*.inf but consume 
openssl BaseCryptLib, are you using BaseCryptLibOnProtocolPpi?
This sounds strange, CryptRand should work fine in non-XIP environments, could 
you send me .map file of your application?

Regards,
Yi


From: eddie wang 
Sent: Thursday, February 29, 2024 5:49 PM
To: devel@edk2.groups.io; Li, Yi1 
Subject: Re: [edk2-devel] The API in BaseCryptLib can't seed the pseudorandom 
number generator properly

Hi and many thanks to all of you,
I'm not entirely sure if it's running in a XIP environment, but I think not. 
Our application executed on UEFI interactive shell and it was put in an USB 
device(as the FS0 showed in the screenshot). And here's another question as 
well, because I found that the drbg implementation counld not be fetched in our 
case,  and I discovered that our package did not include 
"OpensslLibCrypto.inf." Could it be connected to our problem?
[cid:image001.png@01DA6B44.21876340]


BR,
Eddie Wang

Li, Yi mailto:yi1...@intel.com>> 於 2024年2月20日 週二 上午9:49寫道：
Hi Eddie,

> the API in CryptPkg "RandomSeed()"(X64, in CryptRandTsc.c) always returned 
> false

Does your code run in a XIP environment? Such like PreMemory stage or other 
cases.
The setup of Randlib in OpenSsl 3.0 relies on global variables, so there may be 
an error if the global variables are read-only.

Regards,
Yi


-Original Message-
From: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>> On Behalf Of Yao, Jiewen
Sent: Tuesday, February 20, 2024 9:11 AM
To: devel@edk2.groups.io; 
ler...@redhat.com; eddie wang 
mailto:qw1562...@gmail.com>>
Subject: Re: [edk2-devel] The API in BaseCryptLib can't seed the pseudorandom 
number generator properly

Thanks Laslo and Eddie.

I am just back from Chinese New Year vocation, still checking email.

If you can file a Bugzilla (https://bugzilla.tianocore.org/) with source code 
of your app, that would be very helpful for us to investigate this issue.


> -Original Message-
> From: devel@edk2.groups.io 
> mailto:devel@edk2.groups.io>> On Behalf Of Laszlo
> Ersek
> Sent: Tuesday, February 20, 2024 4:18 AM
> To: eddie wang mailto:qw1562...@gmail.com>>
> Cc: devel@edk2.groups.io
> Subject: Re: [edk2-devel] The API in BaseCryptLib can't seed the
> pseudorandom number generator properly
>
> On 2/17/24 10:17, eddie wang wrote:
> > Hi Laszlo,
> > After digging dipper,  we found that the *EVP_RAND_fetch *in
> > "rand_new_seed" and "rand_new_drbg" both got NULL in our case. It's
> > meant the DRBG implementation could not be fetched. We also compared
> > it to the case on Linux, and they could both fetched DRBG
> > implementation correctly. Is it possible that the opensslLib 3.0.9
> > caused any compatibility issues with edk2?  Or has anyone else
> > encountered the same problem with these openssl services?
>
> Sorry, I can't say.
>
> If you have a small reproducer UEFI application that works fine when
> built with edk2-stable202305, but does not work when built against
> either edk2-stable202308 or current master, then filing a TianoCore BZ
> (regression) seems justified. (AFAICT it was edk2-stable202308 that
> incorporated the OpenSSL 3.0.9 upgrade, from 1.1.1u.) Attaching the
> source code of the small repro application to the ticket would likely
> be helpful.
>
> Laszlo
>
> > Laszlo Ersek mailto:ler...@redhat.com> 
> > >> 於
> > 2024年2月
> > 15日 週四 下午7:48寫道：
> >
> > On 2/15/24 12:09, eddie wang wrote:
> > > Hi Laszlo,
> > > Thanks for your reply. How can I enable the DEBUGs at RandomSeed()
> > ? Or
> > > any suggesting information that I can provide?
> >
> > Sorry, upon a closer look, I see you had already narrowed it down to
> > RAND_seed() and RAND_status(), which are direct OpenSSL APIs. So my
> > suggestion would amount to adding DEBUGs to OpenSSL, such as to
> > RAND_seed() in
> > "CryptoPkg/Library/OpensslLib/openssl/crypto/rand/rand_lib.c".
> >
> > But, I think you may be able to do just that.
> > "CryptoPkg/Library/Include/CrtLibSupport.h" already includes
> > , and DebugLib is listed under [LibraryClasses] in each
> > instance of OpensslLib. So if you modify your
> > "CryptoPkg/Library/OpensslLib/openssl" submodule directory tree locally,
> > with the following patch:
> >
> > | diff --git a/crypto/rand/rand_lib.c b/crypto/rand/rand_lib.c
> > | index 0fcf4fe3bc1e..e5f105268f52 100644
> > | --- a/crypto/rand/rand_lib.c
> > | +++ b/crypto/rand/rand_lib.c
> > | @@ -257,6 +257,8 @@ void RAND_seed(const void *buf, int num)
> > |  drbg = RAND_get0_primary(NULL);
> > |  if (drbg != NULL && num > 0)
> > |  EVP_RAND_reseed(drbg, 0, NULL, 0, buf, num);
> > | +
> > | +DEBUG ((DEBUG_INFO, "%a: h

Re: [edk2-devel] [PATCH v2 1/1] UefiCpuPkg/MpInitLib: add struct MP_HAND_OFF_CONFIG

[Laszlo Ersek]

On 2/28/24 12:48, Gerd Hoffmann wrote:
> Move the WaitLoopExecutionMode and StartupSignalValue fields to a
> separate HOB with the new struct.
> 
> WaitLoopExecutionMode and StartupSignalValue are independent of
> processor index ranges; they are global to MpInitLib (i.e., the entire
> system). Therefore they shouldn't be repeated in every MpHandOff GUID
> HOB.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  UefiCpuPkg/Library/MpInitLib/MpHandOff.h | 13 ++-
>  UefiCpuPkg/Library/MpInitLib/MpLib.h |  3 +-
>  UefiCpuPkg/Library/MpInitLib/MpLib.c | 47 +---
>  UefiCpuPkg/Library/MpInitLib/PeiMpLib.c  | 34 ++---
>  4 files changed, 75 insertions(+), 22 deletions(-)

Merged as commit dc7cfa9bab74, via
.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116159): https://edk2.groups.io/g/devel/message/116159
Mute This Topic: https://groups.io/mt/104621270/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] 回复: [PATCH] BaseTools/AutoGen: declare ProcessLibraryConstructorList() for SEC modules

[Laszlo Ersek]

On 2/25/24 04:32, gaoliming via groups.io wrote:
> Laszlo:
>   Thanks for your work to make sure this issue be fixed. I agree this change. 
> Reviewed-by: Liming Gao 

Thanks; merged as commit bac9c74080cf, via
.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116158): https://edk2.groups.io/g/devel/message/116158
Mute This Topic: https://groups.io/mt/104558376/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 0/3] OvmfPkg: Add support for 5-level paging

[Laszlo Ersek]

On 2/22/24 11:54, Gerd Hoffmann wrote:
> Patch #1 + #2 fix MdeModulePkg/DxeIplPeim to not assert in case a
> 5-level enabled build runs in 4-level paging mode.
> 
> Patch #3 updates PlatformInitLib for 5-level paging support (update
> PhysBits calculation).
> 
> v4:
>  - drop OvmfPkg/ResetVecor changes, they will be sent as
>separate patch series.
>  - add Ard's ack.
> v3:
>  - add resetvector fixes for sev and tdx
> v2 changes:
>  - fix sev/tdx handling with 5-level paging.
>  - more comments for 5-level page table setup.
>  - improve PAGE_* naming (new patch #3).
>  - rename Page5LevelSupported to Page5LevelEnabled (new patch #2).
>  - pick up some review tags.
> 
> Gerd Hoffmann (3):
>   MdeModulePkg/DxeIplPeim: fix PcdUse5LevelPageTable assert
>   MdeModulePkg/DxeIplPeim: rename variable
>   OvmfPkg/PlatformInitLib: add 5-level paging support
> 
>  .../Core/DxeIplPeim/X64/VirtualMemory.c   | 24 +++
>  OvmfPkg/Library/PlatformInitLib/MemDetect.c   | 63 +--
>  2 files changed, 57 insertions(+), 30 deletions(-)
> 

Series merged as commit range d9a6e7b0b8a6..adebfe121ca0, via
.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116157): https://edk2.groups.io/g/devel/message/116157
Mute This Topic: https://groups.io/mt/104506109/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] The API in BaseCryptLib can't seed the pseudorandom number generator properly

[eddie wang]

Hi and many thanks to all of you,
I'm not entirely sure if it's running in a XIP environment, but I think
not. Our application executed on UEFI interactive shell and it was put in
an USB device(as the FS0 showed in the screenshot). And here's another
question as well, because I found that the drbg implementation counld not
be fetched in our case,  and I discovered that our package did not include
"OpensslLibCrypto.inf." Could it be connected to our problem?
[image: 430.png]


BR,
Eddie Wang

Li, Yi  於 2024年2月20日 週二 上午9:49寫道：

> Hi Eddie,
>
> > the API in CryptPkg "RandomSeed()"(X64, in CryptRandTsc.c) always
> returned false
>
> Does your code run in a XIP environment? Such like PreMemory stage or
> other cases.
> The setup of Randlib in OpenSsl 3.0 relies on global variables, so there
> may be an error if the global variables are read-only.
>
> Regards,
> Yi
>
>
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Yao, Jiewen
> Sent: Tuesday, February 20, 2024 9:11 AM
> To: devel@edk2.groups.io; ler...@redhat.com; eddie wang <
> qw1562...@gmail.com>
> Subject: Re: [edk2-devel] The API in BaseCryptLib can't seed the
> pseudorandom number generator properly
>
> Thanks Laslo and Eddie.
>
> I am just back from Chinese New Year vocation, still checking email.
>
> If you can file a Bugzilla (https://bugzilla.tianocore.org/) with source
> code of your app, that would be very helpful for us to investigate this
> issue.
>
>
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Laszlo
> > Ersek
> > Sent: Tuesday, February 20, 2024 4:18 AM
> > To: eddie wang 
> > Cc: devel@edk2.groups.io
> > Subject: Re: [edk2-devel] The API in BaseCryptLib can't seed the
> > pseudorandom number generator properly
> >
> > On 2/17/24 10:17, eddie wang wrote:
> > > Hi Laszlo,
> > > After digging dipper,  we found that the *EVP_RAND_fetch *in
> > > "rand_new_seed" and "rand_new_drbg" both got NULL in our case. It's
> > > meant the DRBG implementation could not be fetched. We also compared
> > > it to the case on Linux, and they could both fetched DRBG
> > > implementation correctly. Is it possible that the opensslLib 3.0.9
> > > caused any compatibility issues with edk2?  Or has anyone else
> > > encountered the same problem with these openssl services?
> >
> > Sorry, I can't say.
> >
> > If you have a small reproducer UEFI application that works fine when
> > built with edk2-stable202305, but does not work when built against
> > either edk2-stable202308 or current master, then filing a TianoCore BZ
> > (regression) seems justified. (AFAICT it was edk2-stable202308 that
> > incorporated the OpenSSL 3.0.9 upgrade, from 1.1.1u.) Attaching the
> > source code of the small repro application to the ticket would likely
> > be helpful.
> >
> > Laszlo
> >
> > > Laszlo Ersek mailto:ler...@redhat.com>> 於
> > > 2024年2月
> > > 15日 週四 下午7:48寫道：
> > >
> > > On 2/15/24 12:09, eddie wang wrote:
> > > > Hi Laszlo,
> > > > Thanks for your reply. How can I enable the DEBUGs at
> RandomSeed()
> > > ? Or
> > > > any suggesting information that I can provide?
> > >
> > > Sorry, upon a closer look, I see you had already narrowed it down
> to
> > > RAND_seed() and RAND_status(), which are direct OpenSSL APIs. So my
> > > suggestion would amount to adding DEBUGs to OpenSSL, such as to
> > > RAND_seed() in
> > > "CryptoPkg/Library/OpensslLib/openssl/crypto/rand/rand_lib.c".
> > >
> > > But, I think you may be able to do just that.
> > > "CryptoPkg/Library/Include/CrtLibSupport.h" already includes
> > > , and DebugLib is listed under [LibraryClasses] in each
> > > instance of OpensslLib. So if you modify your
> > > "CryptoPkg/Library/OpensslLib/openssl" submodule directory tree
> locally,
> > > with the following patch:
> > >
> > > | diff --git a/crypto/rand/rand_lib.c b/crypto/rand/rand_lib.c
> > > | index 0fcf4fe3bc1e..e5f105268f52 100644
> > > | --- a/crypto/rand/rand_lib.c
> > > | +++ b/crypto/rand/rand_lib.c
> > > | @@ -257,6 +257,8 @@ void RAND_seed(const void *buf, int num)
> > > |  drbg = RAND_get0_primary(NULL);
> > > |  if (drbg != NULL && num > 0)
> > > |  EVP_RAND_reseed(drbg, 0, NULL, 0, buf, num);
> > > | +
> > > | +DEBUG ((DEBUG_INFO, "%a: hello\n", __func__));
> > > |  }
> > > |
> > > |  void RAND_add(const void *buf, int num, double randomness)
> > >
> > > then you should get usable debug messages -- at least it builds
> for me.
> > >
> > > Inserting DEBUGs like this (over multiple rounds of testing /
> narrowing)
> > > should lead you to the exact location that is responsible for the
> > > initialization failure.
> > >
> > > You mention you have encountered the problem with a UEFI
> application.
> > > That is relevant for choosing your DebugLib instance. If you
> already
> > > have a function DebugLib instance for your platform (logging to the

Re: [edk2-devel] [edk2-redfish-client][PATCH 00/13] use Redfish HTTP protocol

[Nickle Wang via groups.io]

Hi Laszlo,

Thanks for your reminder. I enable sendemail.thread now.

Regards,
Nickle

> -Original Message-
> From: Laszlo Ersek 
> Sent: Thursday, February 29, 2024 5:04 PM
> To: devel@edk2.groups.io; Nickle Wang 
> Cc: Abner Chang ; Igor Kulchytskyy 
> Subject: Re: [edk2-devel] [edk2-redfish-client][PATCH 00/13] use Redfish HTTP
> protocol
> 
> External email: Use caution opening links or attachments
> 
> 
> Hi Nickle,
> 
> On 2/29/24 09:52, Nickle Wang via groups.io wrote:
> > Redfish HTTP protocol is introduced to edk2 RedfishPkg. Update
> > RedfishClientPkg to use RedfishHttpLib. And remove the use of
> > RedfishHttpCacheLib.
> >
> > I also replace several functions from RedfishLib with the function
> > provided in RedfishHttpLib. In this way, there is no dependency on
> > RedfishLib in RedfishClientPkg.
> >
> > I noticed that there is false alarm in uncrustify check. When there
> > are deleted files, uncrustiry cannot check them and trigger uncrustify
> > failure.
> >
> > Pull request is created here for testing CI:
> > https://github.com/tianocore/edk2-redfish-client/pull/79
> >
> > Signed-off-by: Nickle Wang 
> > Cc: Abner Chang 
> > Cc: Igor Kulchytskyy 
> >
> > Nickle Wang (13):
> >   RedfishClientPkg/.github: do not run uncrustify to deleted file.
> >   RedfishClientPkg: remove RedfishHttpCacheLib
> >   RedfishClientPkg: ues RedfishHttpLib
> >   RedfishClientPkg/RedfishResourceConfigLib: ues RedfishHttpLib
> >   RedfishClientPkg/RedfishFeatureUtilityLib: ues RedfishHttpLib
> >   RedfishClientPkg/RedfishVersionLib: ues RedfishHttpLib
> >   RedfishClientPkg/BiosDxe: ues RedfishHttpLib
> >   RedfishClientPkg/BootOptionDxe: ues RedfishHttpLib
> >   RedfishClientPkg/BootOptionCollectionDxe: ues RedfishHttpLib
> >   RedfishClientPkg/ComputerSystemDxe: ues RedfishHttpLib
> >   RedfishClientPkg/ComputerSystemCollectionDxe: ues RedfishHttpLib
> >   RedfishClientPkg/MemoryDxe: ues RedfishHttpLib
> >   RedfishClientPkg/MemoryCollectionDxe: ues RedfishHttpLib
> 
> can you please enable (shallow) threading in your git config?
> 
> $ git config sendemail.thread true
> 
> Thanks!
> Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116155): https://edk2.groups.io/g/devel/message/116155
Mute This Topic: https://groups.io/mt/104640214/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-redfish-client][PATCH 00/13] use Redfish HTTP protocol

[Laszlo Ersek]

Hi Nickle,

On 2/29/24 09:52, Nickle Wang via groups.io wrote:
> Redfish HTTP protocol is introduced to edk2 RedfishPkg. Update 
> RedfishClientPkg to use RedfishHttpLib. And remove the use of 
> RedfishHttpCacheLib. 
> 
> I also replace several functions from RedfishLib with the function 
> provided in RedfishHttpLib. In this way, there is no dependency on 
> RedfishLib in RedfishClientPkg.
> 
> I noticed that there is false alarm in uncrustify check. When there
> are deleted files, uncrustiry cannot check them and trigger uncrustify
> failure.
> 
> Pull request is created here for testing CI: 
> https://github.com/tianocore/edk2-redfish-client/pull/79
> 
> Signed-off-by: Nickle Wang 
> Cc: Abner Chang 
> Cc: Igor Kulchytskyy 
> 
> Nickle Wang (13):
>   RedfishClientPkg/.github: do not run uncrustify to deleted file.
>   RedfishClientPkg: remove RedfishHttpCacheLib
>   RedfishClientPkg: ues RedfishHttpLib
>   RedfishClientPkg/RedfishResourceConfigLib: ues RedfishHttpLib
>   RedfishClientPkg/RedfishFeatureUtilityLib: ues RedfishHttpLib
>   RedfishClientPkg/RedfishVersionLib: ues RedfishHttpLib
>   RedfishClientPkg/BiosDxe: ues RedfishHttpLib
>   RedfishClientPkg/BootOptionDxe: ues RedfishHttpLib
>   RedfishClientPkg/BootOptionCollectionDxe: ues RedfishHttpLib
>   RedfishClientPkg/ComputerSystemDxe: ues RedfishHttpLib
>   RedfishClientPkg/ComputerSystemCollectionDxe: ues RedfishHttpLib
>   RedfishClientPkg/MemoryDxe: ues RedfishHttpLib
>   RedfishClientPkg/MemoryCollectionDxe: ues RedfishHttpLib

can you please enable (shallow) threading in your git config?

$ git config sendemail.thread true

Thanks!
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116154): https://edk2.groups.io/g/devel/message/116154
Mute This Topic: https://groups.io/mt/104640214/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-redfish-client][PATCH 13/13] RedfishClientPkg/MemoryCollectionDxe: ues RedfishHttpLib

[Nickle Wang via groups.io]

Use EDK2 RedfishHttpLib to replace RedfishHttpCacheLib and RedfishLib

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
---
 .../MemoryCollectionDxe/MemoryCollectionDxe.inf   |  3 +--
 .../MemoryCollectionDxe/MemoryCollectionDxe.c | 15 ++-
 2 files changed, 3 insertions(+), 15 deletions(-)

diff --git 
a/RedfishClientPkg/Features/MemoryCollectionDxe/MemoryCollectionDxe.inf 
b/RedfishClientPkg/Features/MemoryCollectionDxe/MemoryCollectionDxe.inf
index 67c38f62d..97c59000c 100644
--- a/RedfishClientPkg/Features/MemoryCollectionDxe/MemoryCollectionDxe.inf
+++ b/RedfishClientPkg/Features/MemoryCollectionDxe/MemoryCollectionDxe.inf
@@ -35,13 +35,12 @@
   ConverterCommonLib
   MemoryAllocationLib
   RedfishFeatureUtilityLib
-  RedfishLib
+  RedfishHttpLib
   UefiLib
   UefiDriverEntryPoint
   UefiBootServicesTableLib
   EdkIIRedfishResourceConfigLib
   RedfishVersionLib
-  RedfishHttpCacheLib
 
 [Protocols]
   gEdkIIRedfishConfigHandlerProtocolGuid## CONSUMED
diff --git 
a/RedfishClientPkg/Features/MemoryCollectionDxe/MemoryCollectionDxe.c 
b/RedfishClientPkg/Features/MemoryCollectionDxe/MemoryCollectionDxe.c
index 2127570fb..1b7d74e86 100644
--- a/RedfishClientPkg/Features/MemoryCollectionDxe/MemoryCollectionDxe.c
+++ b/RedfishClientPkg/Features/MemoryCollectionDxe/MemoryCollectionDxe.c
@@ -247,18 +247,7 @@ ReleaseCollectionResource (
   //
   // Release resource
   //
-  if (Private->Response.Payload != NULL) {
-RedfishFreeResponse (
-  Private->Response.StatusCode,
-  Private->Response.HeaderCount,
-  Private->Response.Headers,
-  Private->Response.Payload
-  );
-Private->Response.StatusCode  = NULL;
-Private->Response.HeaderCount = 0;
-Private->Response.Headers = NULL;
-Private->Response.Payload = NULL;
-  }
+  RedfishHttpFreeResponse (&Private->Response);
 
   if (Private->CollectionJson != NULL) {
 FreePool (Private->CollectionJson);
@@ -289,7 +278,7 @@ CollectionHandler (
   //
   // Query collection from Redfish service.
   //
-  Status = RedfishHttpGetResource (Private->RedfishService, 
Private->CollectionUri, &Private->Response, TRUE);
+  Status = RedfishHttpGetResource (Private->RedfishService, 
Private->CollectionUri, NULL, &Private->Response, TRUE);
   if (EFI_ERROR (Status)) {
 DEBUG ((DEBUG_ERROR, "%a, unable to get resource from: %s :%r\n", 
__func__, Private->CollectionUri, Status));
 goto ON_RELEASE;
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116153): https://edk2.groups.io/g/devel/message/116153
Mute This Topic: https://groups.io/mt/104640238/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-redfish-client][PATCH 12/13] RedfishClientPkg/MemoryDxe: ues RedfishHttpLib

[Nickle Wang via groups.io]

Use EDK2 RedfishHttpLib to replace RedfishHttpCacheLib and RedfishLib

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
---
 .../Features/Memory/V1_7_1/Dxe/MemoryDxe.inf  |   3 +-
 .../Memory/V1_7_1/Common/MemoryCommon.c   |  86 ++
 .../Features/Memory/V1_7_1/Dxe/MemoryDxe.c| 111 +-
 3 files changed, 69 insertions(+), 131 deletions(-)

diff --git a/RedfishClientPkg/Features/Memory/V1_7_1/Dxe/MemoryDxe.inf 
b/RedfishClientPkg/Features/Memory/V1_7_1/Dxe/MemoryDxe.inf
index 43039b9f4..687c1a39d 100644
--- a/RedfishClientPkg/Features/Memory/V1_7_1/Dxe/MemoryDxe.inf
+++ b/RedfishClientPkg/Features/Memory/V1_7_1/Dxe/MemoryDxe.inf
@@ -32,12 +32,11 @@
   BaseMemoryLib
   DebugLib
   EdkIIRedfishResourceConfigLib
-  RedfishLib
+  RedfishHttpLib
   RedfishFeatureUtilityLib
   RedfishResourceIdentifyLib
   UefiLib
   UefiDriverEntryPoint
-  RedfishHttpCacheLib
 
 [Protocols]
   gEdkIIRedfishConfigHandlerProtocolGuid  ## PRODUCED
diff --git a/RedfishClientPkg/Features/Memory/V1_7_1/Common/MemoryCommon.c 
b/RedfishClientPkg/Features/Memory/V1_7_1/Common/MemoryCommon.c
index 00a69f748..e873f05ca 100644
--- a/RedfishClientPkg/Features/Memory/V1_7_1/Common/MemoryCommon.c
+++ b/RedfishClientPkg/Features/Memory/V1_7_1/Common/MemoryCommon.c
@@ -2,7 +2,7 @@
   Redfish feature driver implementation - common functions
 
   (C) Copyright 2020-2022 Hewlett Packard Enterprise Development LP
-  Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+  Copyright (c) 2023-2024, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -67,7 +67,7 @@ RedfishConsumeResourceCommon (
 // No change
 //
 DEBUG ((DEBUG_MANAGEABILITY, "%a, ETAG: %s has no change, ignore consume 
action\n", __func__, Private->Uri));
-Status = EFI_ALREADY_STARTED;
+Status = EFI_SUCCESS;
 goto ON_RELEASE;
   }
 
@@ -2154,17 +2154,17 @@ ProvisioningMemoryResource (
   IN  EFI_STRING   ConfigureLang
   )
 {
-  CHAR8   *Json;
-  EFI_STATUS  Status;
-  EFI_STRING  NewResourceLocation;
-  CHAR8   *EtagStr;
-  CHAR8   ResourceId[16];
+  CHAR8 *Json;
+  EFI_STATUSStatus;
+  EFI_STRINGNewResourceLocation;
+  CHAR8 ResourceId[16];
+  REDFISH_RESPONSE  Response;
 
   if (IS_EMPTY_STRING (ConfigureLang) || (Private == NULL)) {
 return EFI_INVALID_PARAMETER;
   }
 
-  EtagStr = NULL;
+  ZeroMem (&Response, sizeof (REDFISH_RESPONSE));
   AsciiSPrint (ResourceId, sizeof (ResourceId), "%d", Index);
 
   Status = ProvisioningMemoryProperties (
@@ -2180,27 +2180,27 @@ ProvisioningMemoryResource (
 return Status;
   }
 
-  Status = CreatePayloadToPostResource (Private->RedfishService, 
Private->Payload, Json, &NewResourceLocation, &EtagStr);
+  Status = RedfishHttpPostResource (Private->RedfishService, Private->Uri, 
Json, &Response);
   if (EFI_ERROR (Status)) {
-DEBUG ((DEBUG_ERROR, "%a, post Memory resource for %s failed: %r\n", 
__func__, ConfigureLang, Status));
+DEBUG ((DEBUG_ERROR, "%a, post Bios resource for %s failed: %r\n", 
__func__, ConfigureLang, Status));
 goto RELEASE_RESOURCE;
   }
 
-  ASSERT (NewResourceLocation != NULL);
-
   //
-  // Keep location of new resource.
+  // Per Redfish spec. the URL of new resource will be returned in "Location" 
header.
   //
-  if (NewResourceLocation != NULL) {
-RedfishSetRedfishUri (ConfigureLang, NewResourceLocation);
+  Status = GetHttpResponseLocation (&Response, &NewResourceLocation);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "%a: cannot find new location: %r\n", __func__, 
Status));
+goto RELEASE_RESOURCE;
   }
 
   //
-  // Handle Etag
+  // Keep location of new resource.
   //
-  if (EtagStr != NULL) {
-SetEtagWithUri (EtagStr, NewResourceLocation);
-FreePool (EtagStr);
+  if (NewResourceLocation != NULL) {
+DEBUG ((DEBUG_MANAGEABILITY, "%a: Location: %s\n", __func__, 
NewResourceLocation));
+RedfishSetRedfishUri (ConfigureLang, NewResourceLocation);
   }
 
 RELEASE_RESOURCE:
@@ -2255,18 +2255,18 @@ ProvisioningMemoryExistResource (
   IN  REDFISH_RESOURCE_COMMON_PRIVATE  *Private
   )
 {
-  EFI_STATUS  Status;
-  EFI_STRING  ConfigureLang;
-  CHAR8   *EtagStr;
-  CHAR8   *Json;
+  EFI_STATUSStatus;
+  EFI_STRINGConfigureLang;
+  CHAR8 *Json;
+  REDFISH_RESPONSE  Response;
 
   if (Private == NULL) {
 return EFI_INVALID_PARAMETER;
   }
 
-  EtagStr   = NULL;
   Json  = NULL;
   ConfigureLang = NULL;
+  ZeroMem (&Response, sizeof (REDFISH_RESPONSE));
 
   ConfigureLang = RedfishGetConfigLanguage (Private->Uri);
   if (ConfigureLang == NULL) {
@@ -2293,23 +2293,17 @@ ProvisioningMemoryExistResource (
 
   DEBUG ((REDFISH_DEBUG_TRACE, "%a, provisioning existing resource for %s\n", 
__func__, ConfigureLang));
   //
-  // PUT back to instance
+  // PATCH back to instance
   //
-  Status = Cre

[edk2-devel] [edk2-redfish-client][PATCH 11/13] RedfishClientPkg/ComputerSystemCollectionDxe: ues RedfishHttpLib

[Nickle Wang via groups.io]

Use EDK2 RedfishHttpLib to replace RedfishHttpCacheLib and RedfishLib

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
---
 .../ComputerSystemCollectionDxe.inf   |  3 +--
 .../ComputerSystemCollectionDxe.c | 15 ++-
 2 files changed, 3 insertions(+), 15 deletions(-)

diff --git 
a/RedfishClientPkg/Features/ComputerSystemCollectionDxe/ComputerSystemCollectionDxe.inf
 
b/RedfishClientPkg/Features/ComputerSystemCollectionDxe/ComputerSystemCollectionDxe.inf
index b848f69f9..7c00f8f56 100644
--- 
a/RedfishClientPkg/Features/ComputerSystemCollectionDxe/ComputerSystemCollectionDxe.inf
+++ 
b/RedfishClientPkg/Features/ComputerSystemCollectionDxe/ComputerSystemCollectionDxe.inf
@@ -35,13 +35,12 @@
   ConverterCommonLib
   MemoryAllocationLib
   RedfishFeatureUtilityLib
-  RedfishLib
+  RedfishHttpLib
   UefiLib
   UefiDriverEntryPoint
   UefiBootServicesTableLib
   EdkIIRedfishResourceConfigLib
   RedfishVersionLib
-  RedfishHttpCacheLib
 
 [Protocols]
   gEdkIIRedfishConfigHandlerProtocolGuid## CONSUMED
diff --git 
a/RedfishClientPkg/Features/ComputerSystemCollectionDxe/ComputerSystemCollectionDxe.c
 
b/RedfishClientPkg/Features/ComputerSystemCollectionDxe/ComputerSystemCollectionDxe.c
index 05d746252..975ba0564 100644
--- 
a/RedfishClientPkg/Features/ComputerSystemCollectionDxe/ComputerSystemCollectionDxe.c
+++ 
b/RedfishClientPkg/Features/ComputerSystemCollectionDxe/ComputerSystemCollectionDxe.c
@@ -256,18 +256,7 @@ ReleaseCollectionResource (
   //
   // Release resource
   //
-  if (Private->Response.Payload != NULL) {
-RedfishFreeResponse (
-  Private->Response.StatusCode,
-  Private->Response.HeaderCount,
-  Private->Response.Headers,
-  Private->Response.Payload
-  );
-Private->Response.StatusCode  = NULL;
-Private->Response.HeaderCount = 0;
-Private->Response.Headers = NULL;
-Private->Response.Payload = NULL;
-  }
+  RedfishHttpFreeResponse (&Private->Response);
 
   if (Private->CollectionJson != NULL) {
 FreePool (Private->CollectionJson);
@@ -298,7 +287,7 @@ CollectionHandler (
   //
   // Query collection from Redfish service.
   //
-  Status = RedfishHttpGetResource (Private->RedfishService, 
Private->CollectionUri, &Private->Response, TRUE);
+  Status = RedfishHttpGetResource (Private->RedfishService, 
Private->CollectionUri, NULL, &Private->Response, TRUE);
   if (EFI_ERROR (Status)) {
 DEBUG ((DEBUG_ERROR, "%a: unable to get resource from: %s :%r\n", 
__func__, Private->CollectionUri, Status));
 goto ON_RELEASE;
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116152): https://edk2.groups.io/g/devel/message/116152
Mute This Topic: https://groups.io/mt/104640235/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-redfish-client][PATCH 10/13] RedfishClientPkg/ComputerSystemDxe: ues RedfishHttpLib

[Nickle Wang via groups.io]

Use EDK2 RedfishHttpLib to replace RedfishHttpCacheLib and RedfishLib

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
---
 .../v1_13_0/Dxe/ComputerSystemDxe.inf |  3 +-
 .../v1_5_0/Dxe/ComputerSystemDxe.inf  |  3 +-
 .../v1_13_0/Common/ComputerSystemCommon.c | 68 +--
 .../v1_13_0/Dxe/ComputerSystemDxe.c   | 85 ---
 .../v1_5_0/Common/ComputerSystemCommon.c  | 68 +--
 .../v1_5_0/Dxe/ComputerSystemDxe.c| 84 --
 6 files changed, 116 insertions(+), 195 deletions(-)

diff --git 
a/RedfishClientPkg/Features/ComputerSystem/v1_13_0/Dxe/ComputerSystemDxe.inf 
b/RedfishClientPkg/Features/ComputerSystem/v1_13_0/Dxe/ComputerSystemDxe.inf
index be1c2164d..40403ac7f 100644
--- a/RedfishClientPkg/Features/ComputerSystem/v1_13_0/Dxe/ComputerSystemDxe.inf
+++ b/RedfishClientPkg/Features/ComputerSystem/v1_13_0/Dxe/ComputerSystemDxe.inf
@@ -32,13 +32,12 @@
   BaseMemoryLib
   DebugLib
   EdkIIRedfishResourceConfigLib
-  RedfishLib
+  RedfishHttpLib
   RedfishFeatureUtilityLib
   RedfishResourceIdentifyLib
   UefiLib
   UefiDriverEntryPoint
   RedfishAddendumLib
-  RedfishHttpCacheLib
 
 [Protocols]
   gEdkIIRedfishConfigHandlerProtocolGuid  ## PRODUCED
diff --git 
a/RedfishClientPkg/Features/ComputerSystem/v1_5_0/Dxe/ComputerSystemDxe.inf 
b/RedfishClientPkg/Features/ComputerSystem/v1_5_0/Dxe/ComputerSystemDxe.inf
index 4e7dc5c7c..46ac2d4e5 100644
--- a/RedfishClientPkg/Features/ComputerSystem/v1_5_0/Dxe/ComputerSystemDxe.inf
+++ b/RedfishClientPkg/Features/ComputerSystem/v1_5_0/Dxe/ComputerSystemDxe.inf
@@ -32,13 +32,12 @@
   BaseMemoryLib
   DebugLib
   EdkIIRedfishResourceConfigLib
-  RedfishLib
+  RedfishHttpLib
   RedfishFeatureUtilityLib
   RedfishResourceIdentifyLib
   UefiLib
   UefiDriverEntryPoint
   RedfishAddendumLib
-  RedfishHttpCacheLib
 
 [Protocols]
   gEdkIIRedfishConfigHandlerProtocolGuid  ## PRODUCED
diff --git 
a/RedfishClientPkg/Features/ComputerSystem/v1_13_0/Common/ComputerSystemCommon.c
 
b/RedfishClientPkg/Features/ComputerSystem/v1_13_0/Common/ComputerSystemCommon.c
index d69fc176a..df22a1c90 100644
--- 
a/RedfishClientPkg/Features/ComputerSystem/v1_13_0/Common/ComputerSystemCommon.c
+++ 
b/RedfishClientPkg/Features/ComputerSystem/v1_13_0/Common/ComputerSystemCommon.c
@@ -2,7 +2,7 @@
   Redfish feature driver implementation - common functions
 
   (C) Copyright 2020-2022 Hewlett Packard Enterprise Development LP
-  Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+  Copyright (c) 2023-2024, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
   Copyright (C) 2024 Advanced Micro Devices, Inc. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -407,18 +407,18 @@ ProvisioningComputerSystemResource (
   IN  EFI_STRING   ConfigureLang
   )
 {
-  CHAR8   *Json;
-  CHAR8   *JsonWithAddendum;
-  EFI_STATUS  Status;
-  EFI_STRING  NewResourceLocation;
-  CHAR8   *EtagStr;
-  CHAR8   ResourceId[16];
+  CHAR8 *Json;
+  CHAR8 *JsonWithAddendum;
+  EFI_STATUSStatus;
+  EFI_STRINGNewResourceLocation;
+  CHAR8 ResourceId[16];
+  REDFISH_RESPONSE  Response;
 
   if (IS_EMPTY_STRING (ConfigureLang) || (Private == NULL)) {
 return EFI_INVALID_PARAMETER;
   }
 
-  EtagStr = NULL;
+  ZeroMem (&Response, sizeof (REDFISH_RESPONSE));
   AsciiSPrint (ResourceId, sizeof (ResourceId), "%d", Index);
 
   Status = ProvisioningComputerSystemProperties (
@@ -466,27 +466,31 @@ ProvisioningComputerSystemResource (
 JsonWithAddendum = NULL;
   }
 
-  Status = CreatePayloadToPostResource (Private->RedfishService, 
Private->Payload, Json, &NewResourceLocation, &EtagStr);
+  Status = RedfishHttpPostResource (Private->RedfishService, Private->Uri, 
Json, &Response);
   if (EFI_ERROR (Status)) {
-DEBUG ((DEBUG_ERROR, "%a: post ComputerSystem resource for %s failed: 
%r\n", __func__, ConfigureLang, Status));
+DEBUG ((DEBUG_ERROR, "%a, post Bios resource for %s failed: %r\n", 
__func__, ConfigureLang, Status));
 goto RELEASE_RESOURCE;
   }
 
-  ASSERT (NewResourceLocation != NULL);
+  //
+  // Per Redfish spec. the URL of new resource will be returned in "Location" 
header.
+  //
+  Status = GetHttpResponseLocation (&Response, &NewResourceLocation);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "%a: cannot find new location: %r\n", __func__, 
Status));
+goto RELEASE_RESOURCE;
+  }
 
   //
   // Keep location of new resource.
   //
   if (NewResourceLocation != NULL) {
+DEBUG ((DEBUG_MANAGEABILITY, "%a: Location: %s\n", __func__, 
NewResourceLocation));
 RedfishSetRedfishUri (ConfigureLang, NewResourceLocation);
   }
 
 RELEASE_RESOURCE:
 
-  if (EtagStr != NULL) {
-FreePool (EtagStr);
-  }
-
   if (NewResourceLocation != NULL) {
 FreePool (NewResourceLocation);
   }
@@ -495,6 +499,8 @@ RELEASE_RESOURCE:
 FreePool (Js

[edk2-devel] [edk2-redfish-client][PATCH 08/13] RedfishClientPkg/BootOptionDxe: ues RedfishHttpLib

[Nickle Wang via groups.io]

Use EDK2 RedfishHttpLib to replace RedfishHttpCacheLib and RedfishLib

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
---
 .../BootOption/v1_0_4/Dxe/BootOptionDxe.inf   |  5 +-
 .../v1_0_4/Common/BootOptionCommon.c  | 45 ++
 .../BootOption/v1_0_4/Dxe/BootOptionDxe.c | 86 ---
 3 files changed, 26 insertions(+), 110 deletions(-)

diff --git a/RedfishClientPkg/Features/BootOption/v1_0_4/Dxe/BootOptionDxe.inf 
b/RedfishClientPkg/Features/BootOption/v1_0_4/Dxe/BootOptionDxe.inf
index 00c1c5bba..cd3c1c711 100644
--- a/RedfishClientPkg/Features/BootOption/v1_0_4/Dxe/BootOptionDxe.inf
+++ b/RedfishClientPkg/Features/BootOption/v1_0_4/Dxe/BootOptionDxe.inf
@@ -1,7 +1,7 @@
 ## @file
 #
 #  (C) Copyright 2020-2022 Hewlett Packard Enterprise Development LP
-#  Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+#  Copyright (c) 2023-2024, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -32,13 +32,12 @@
   BaseMemoryLib
   DebugLib
   EdkIIRedfishResourceConfigLib
-  RedfishLib
+  RedfishHttpLib
   RedfishFeatureUtilityLib
   RedfishResourceIdentifyLib
   UefiLib
   UefiDriverEntryPoint
   RedfishAddendumLib
-  RedfishHttpCacheLib
   UefiBootManagerLib
   DevicePathLib
   BaseLib
diff --git 
a/RedfishClientPkg/Features/BootOption/v1_0_4/Common/BootOptionCommon.c 
b/RedfishClientPkg/Features/BootOption/v1_0_4/Common/BootOptionCommon.c
index f471c01c3..339c8ba04 100644
--- a/RedfishClientPkg/Features/BootOption/v1_0_4/Common/BootOptionCommon.c
+++ b/RedfishClientPkg/Features/BootOption/v1_0_4/Common/BootOptionCommon.c
@@ -2,7 +2,7 @@
   Redfish feature driver implementation - common functions
 
   (C) Copyright 2020-2022 Hewlett Packard Enterprise Development LP
-  Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+  Copyright (c) 2023-2024, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
   Copyright (C) 2024 Advanced Micro Devices, Inc. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -449,7 +449,7 @@ RedfishProvisioningResourceCommon (
 JsonWithAddendum = NULL;
   }
 
-  Status = CreatePayloadToPostResource (Private->RedfishService, 
Private->Payload, Json, NULL, NULL);
+  Status = RedfishHttpPostResource (Private->RedfishService, Private->Uri, 
Json, &Response);
   if (EFI_ERROR (Status)) {
 DEBUG ((DEBUG_ERROR, "%a: post BootOption resource for %s failed: %r\n", 
__func__, BootOptionName, Status));
 goto RELEASE_RESOURCE;
@@ -482,12 +482,7 @@ RELEASE_RESOURCE:
 FreePool (Json);
   }
 
-  RedfishFreeResponse (
-Response.StatusCode,
-Response.HeaderCount,
-Response.Headers,
-Response.Payload
-);
+  RedfishHttpFreeResponse (&Response);
 
   return Status;
 }
@@ -519,7 +514,6 @@ RedfishCheckResourceCommon (
   BOOLEAN   DeleteResourceRequired;
   EFI_STRINGDevicePathString;
   CHAR8 *DevicePathAsciiString;
-  CHAR8 *AsciiUri;
 
   if ((Private == NULL) || IS_EMPTY_STRING (Json)) {
 return EFI_INVALID_PARAMETER;
@@ -531,8 +525,6 @@ RedfishCheckResourceCommon (
   DeleteResourceRequired = FALSE;
   BootOptionName = NULL;
   BootOption = NULL;
-  AsciiUri   = NULL;
-  Response.Payload   = NULL;
   Status = Private->JsonStructProtocol->ToStructure (
   
Private->JsonStructProtocol,
   NULL,
@@ -594,13 +586,7 @@ RedfishCheckResourceCommon (
   //
   if (DeleteResourceRequired) {
 DEBUG ((REDFISH_BOOT_OPTION_DEBUG_TRACE, "%a: boot option %s is deleted in 
system. Delete %s\n", __func__, BootOptionName, Private->Uri));
-AsciiUri = StrUnicodeToAscii (Private->Uri);
-if (AsciiUri == NULL) {
-  Status = EFI_OUT_OF_RESOURCES;
-  goto ON_RELEASE;
-}
-
-Status = RedfishDeleteByUri (Private->RedfishService, AsciiUri, &Response);
+Status = RedfishHttpDeleteResource (Private->RedfishService, Private->Uri, 
&Response);
 if (EFI_ERROR (Status)) {
   DEBUG ((DEBUG_ERROR, "%a: can not delete %s: %r\n", __func__, 
Private->Uri, Status));
 }
@@ -631,16 +617,8 @@ ON_RELEASE:
   //
   // Release resource
   //
-  RedfishFreeResponse (
-Response.StatusCode,
-Response.HeaderCount,
-Response.Headers,
-Response.Payload
-);
+  RedfishHttpFreeResponse (&Response);
 
-  //
-  // Release resource.
-  //
   Private->JsonStructProtocol->DestoryStructure (
  Private->JsonStructProtocol,
  (EFI_REST_JSON_STRUCTURE_HEADER *)BootOption
@@ -650,10 +628,6 @@ ON_RELEASE:
 FreePool (BootOptionName);
   }
 
-  if (AsciiUri != NULL) {
-FreePool (AsciiUri);
-  }
-
   return Status;
 }
 
@@ -748,7 +722,7 @@ RedfishUpdateResourceCommo

[edk2-devel] [edk2-redfish-client][PATCH 09/13] RedfishClientPkg/BootOptionCollectionDxe: ues RedfishHttpLib

[Nickle Wang via groups.io]

Use EDK2 RedfishHttpLib to replace RedfishHttpCacheLib and RedfishLib

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
---
 .../BootOptionCollectionDxe.inf   |  5 ++--
 .../BootOptionCollectionDxe.c | 26 ---
 2 files changed, 7 insertions(+), 24 deletions(-)

diff --git 
a/RedfishClientPkg/Features/BootOptionCollection/BootOptionCollectionDxe.inf 
b/RedfishClientPkg/Features/BootOptionCollection/BootOptionCollectionDxe.inf
index 7977fa461..90aae8e9e 100644
--- a/RedfishClientPkg/Features/BootOptionCollection/BootOptionCollectionDxe.inf
+++ b/RedfishClientPkg/Features/BootOptionCollection/BootOptionCollectionDxe.inf
@@ -3,7 +3,7 @@
 #  Redfish BootOptionCollection collection driver.
 #
 #  (C) Copyright 2020-2022 Hewlett Packard Enterprise Development LP
-#  Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+#  Copyright (c) 2023-2024, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -35,13 +35,12 @@
   ConverterCommonLib
   MemoryAllocationLib
   RedfishFeatureUtilityLib
-  RedfishLib
+  RedfishHttpLib
   UefiLib
   UefiDriverEntryPoint
   UefiBootServicesTableLib
   EdkIIRedfishResourceConfigLib
   RedfishVersionLib
-  RedfishHttpCacheLib
   UefiBootManagerLib
   DevicePathLib
 
diff --git 
a/RedfishClientPkg/Features/BootOptionCollection/BootOptionCollectionDxe.c 
b/RedfishClientPkg/Features/BootOptionCollection/BootOptionCollectionDxe.c
index 54cabcbe8..4f94a4495 100644
--- a/RedfishClientPkg/Features/BootOptionCollection/BootOptionCollectionDxe.c
+++ b/RedfishClientPkg/Features/BootOptionCollection/BootOptionCollectionDxe.c
@@ -3,7 +3,7 @@
   Redfish feature driver implementation - BootOptionCollection
 
   (C) Copyright 2020-2022 Hewlett Packard Enterprise Development LP
-  Copyright (c) 2022-2023, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
+  Copyright (c) 2022-2024, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -169,7 +169,7 @@ MarkBootOptionProcessed (
   // Get boot option reference attribute
   //
   ZeroMem (&Response, sizeof (REDFISH_RESPONSE));
-  Status = RedfishHttpGetResource (RedfishService, Uri, &Response, TRUE);
+  Status = RedfishHttpGetResource (RedfishService, Uri, NULL, &Response, TRUE);
   if (EFI_ERROR (Status) || (Response.Payload == NULL)) {
 DEBUG ((DEBUG_ERROR, "%a: failed to get resource from %s: %r", __func__, 
Uri, Status));
 return Status;
@@ -212,12 +212,7 @@ MarkBootOptionProcessed (
 
 ON_RELEASE:
 
-  RedfishFreeResponse (
-Response.StatusCode,
-Response.HeaderCount,
-Response.Headers,
-Response.Payload
-);
+  RedfishHttpFreeResponse (&Response);
 
   return Status;
 }
@@ -436,18 +431,7 @@ ReleaseCollectionResource (
   //
   // Release resource
   //
-  if (Private->Response.Payload != NULL) {
-RedfishFreeResponse (
-  Private->Response.StatusCode,
-  Private->Response.HeaderCount,
-  Private->Response.Headers,
-  Private->Response.Payload
-  );
-Private->Response.StatusCode  = NULL;
-Private->Response.HeaderCount = 0;
-Private->Response.Headers = NULL;
-Private->Response.Payload = NULL;
-  }
+  RedfishHttpFreeResponse (&Private->Response);
 
   if (Private->CollectionJson != NULL) {
 FreePool (Private->CollectionJson);
@@ -478,7 +462,7 @@ CollectionHandler (
   //
   // Query collection from Redfish service.
   //
-  Status = RedfishHttpGetResource (Private->RedfishService, 
Private->CollectionUri, &Private->Response, TRUE);
+  Status = RedfishHttpGetResource (Private->RedfishService, 
Private->CollectionUri, NULL, &Private->Response, TRUE);
   if (EFI_ERROR (Status)) {
 DEBUG ((DEBUG_ERROR, "%a: unable to get resource from: %s :%r\n", 
__func__, Private->CollectionUri, Status));
 goto ON_RELEASE;
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116148): https://edk2.groups.io/g/devel/message/116148
Mute This Topic: https://groups.io/mt/104640231/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-redfish-client][PATCH 07/13] RedfishClientPkg/BiosDxe: ues RedfishHttpLib

[Nickle Wang via groups.io]

Use EDK2 RedfishHttpLib to replace RedfishHttpCacheLib and RedfishLib

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
---
 .../Features/Bios/v1_0_9/Dxe/BiosDxe.inf  |   3 +-
 .../Features/Bios/v1_0_9/Common/BiosCommon.c  |  92 +++---
 .../Features/Bios/v1_0_9/Dxe/BiosDxe.c| 113 +-
 3 files changed, 74 insertions(+), 134 deletions(-)

diff --git a/RedfishClientPkg/Features/Bios/v1_0_9/Dxe/BiosDxe.inf 
b/RedfishClientPkg/Features/Bios/v1_0_9/Dxe/BiosDxe.inf
index 6ba4c3cfa..a2ac18e61 100644
--- a/RedfishClientPkg/Features/Bios/v1_0_9/Dxe/BiosDxe.inf
+++ b/RedfishClientPkg/Features/Bios/v1_0_9/Dxe/BiosDxe.inf
@@ -32,14 +32,13 @@
   BaseMemoryLib
   DebugLib
   EdkIIRedfishResourceConfigLib
-  RedfishLib
+  RedfishHttpLib
   RedfishFeatureUtilityLib
   RedfishVersionLib
   RedfishResourceIdentifyLib
   UefiLib
   UefiDriverEntryPoint
   RedfishAddendumLib
-  RedfishHttpCacheLib
 
 [Protocols]
   gEdkIIRedfishConfigHandlerProtocolGuid  ## PRODUCED
diff --git a/RedfishClientPkg/Features/Bios/v1_0_9/Common/BiosCommon.c 
b/RedfishClientPkg/Features/Bios/v1_0_9/Common/BiosCommon.c
index f3f993c87..1f3c30147 100644
--- a/RedfishClientPkg/Features/Bios/v1_0_9/Common/BiosCommon.c
+++ b/RedfishClientPkg/Features/Bios/v1_0_9/Common/BiosCommon.c
@@ -2,7 +2,7 @@
   Redfish feature driver implementation - common functions
 
   (C) Copyright 2020-2022 Hewlett Packard Enterprise Development LP
-  Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+  Copyright (c) 2023-2024, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -68,7 +68,7 @@ RedfishConsumeResourceCommon (
 // No change
 //
 DEBUG ((DEBUG_MANAGEABILITY, "%a, ETAG: %s has no change, ignore consume 
action\n", __func__, Private->Uri));
-Status = EFI_ALREADY_STARTED;
+Status = EFI_SUCCESS;
 goto ON_RELEASE;
   }
 
@@ -268,18 +268,18 @@ ProvisioningBiosResource (
   IN  EFI_STRING   ConfigureLang
   )
 {
-  CHAR8   *Json;
-  CHAR8   *JsonWithAddendum;
-  EFI_STATUS  Status;
-  EFI_STRING  NewResourceLocation;
-  CHAR8   *EtagStr;
-  CHAR8   ResourceId[16];
+  CHAR8 *Json;
+  CHAR8 *JsonWithAddendum;
+  EFI_STATUSStatus;
+  EFI_STRINGNewResourceLocation;
+  CHAR8 ResourceId[16];
+  REDFISH_RESPONSE  Response;
 
   if (IS_EMPTY_STRING (ConfigureLang) || (Private == NULL)) {
 return EFI_INVALID_PARAMETER;
   }
 
-  EtagStr = NULL;
+  ZeroMem (&Response, sizeof (REDFISH_RESPONSE));
   AsciiSPrint (ResourceId, sizeof (ResourceId), "%d", Index);
 
   Status = ProvisioningBiosProperties (
@@ -327,27 +327,27 @@ ProvisioningBiosResource (
 JsonWithAddendum = NULL;
   }
 
-  Status = CreatePayloadToPostResource (Private->RedfishService, 
Private->Payload, Json, &NewResourceLocation, &EtagStr);
+  Status = RedfishHttpPostResource (Private->RedfishService, Private->Uri, 
Json, &Response);
   if (EFI_ERROR (Status)) {
 DEBUG ((DEBUG_ERROR, "%a, post Bios resource for %s failed: %r\n", 
__func__, ConfigureLang, Status));
 goto RELEASE_RESOURCE;
   }
 
-  ASSERT (NewResourceLocation != NULL);
-
   //
-  // Keep location of new resource.
+  // Per Redfish spec. the URL of new resource will be returned in "Location" 
header.
   //
-  if (NewResourceLocation != NULL) {
-RedfishSetRedfishUri (ConfigureLang, NewResourceLocation);
+  Status = GetHttpResponseLocation (&Response, &NewResourceLocation);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "%a: cannot find new location: %r\n", __func__, 
Status));
+goto RELEASE_RESOURCE;
   }
 
   //
-  // Handle Etag
+  // Keep location of new resource.
   //
-  if (EtagStr != NULL) {
-SetEtagWithUri (EtagStr, NewResourceLocation);
-FreePool (EtagStr);
+  if (NewResourceLocation != NULL) {
+DEBUG ((DEBUG_MANAGEABILITY, "%a: Location: %s\n", __func__, 
NewResourceLocation));
+RedfishSetRedfishUri (ConfigureLang, NewResourceLocation);
   }
 
 RELEASE_RESOURCE:
@@ -360,6 +360,8 @@ RELEASE_RESOURCE:
 FreePool (Json);
   }
 
+  RedfishHttpFreeResponse (&Response);
+
   return Status;
 }
 
@@ -402,19 +404,19 @@ ProvisioningBiosExistResource (
   IN  REDFISH_RESOURCE_COMMON_PRIVATE  *Private
   )
 {
-  EFI_STATUS  Status;
-  EFI_STRING  ConfigureLang;
-  CHAR8   *EtagStr;
-  CHAR8   *Json;
-  CHAR8   *JsonWithAddendum;
+  EFI_STATUSStatus;
+  EFI_STRINGConfigureLang;
+  CHAR8 *Json;
+  CHAR8 *JsonWithAddendum;
+  REDFISH_RESPONSE  Response;
 
   if (Private == NULL) {
 return EFI_INVALID_PARAMETER;
   }
 
-  EtagStr   = NULL;
   Json  = NULL;
   ConfigureLang = NULL;
+  ZeroMem (&Response, sizeof (REDFISH_RESPONSE));
 
   ConfigureLang = RedfishGetConfigLanguage (Private->Uri);
   if (ConfigureLang == NULL) {
@@ -473,23 +475,17 @@ ProvisioningBiosExistResource (
 
   DEBUG ((REDFIS

[edk2-devel] [edk2-redfish-client][PATCH 06/13] RedfishClientPkg/RedfishVersionLib: ues RedfishHttpLib

[Nickle Wang via groups.io]

Use EDK2 RedfishHttpLib to replace RedfishHttpCacheLib and RedfishLib

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
---
 .../RedfishVersionLib/RedfishVersionLib.inf   |  3 +--
 .../RedfishVersionLib/RedfishVersionLib.c | 24 +++
 2 files changed, 4 insertions(+), 23 deletions(-)

diff --git a/RedfishClientPkg/Library/RedfishVersionLib/RedfishVersionLib.inf 
b/RedfishClientPkg/Library/RedfishVersionLib/RedfishVersionLib.inf
index 10e335af3..5c3f4de39 100644
--- a/RedfishClientPkg/Library/RedfishVersionLib/RedfishVersionLib.inf
+++ b/RedfishClientPkg/Library/RedfishVersionLib/RedfishVersionLib.inf
@@ -36,9 +36,8 @@
   DebugLib
   MemoryAllocationLib
   PcdLib
-  RedfishLib
+  RedfishHttpLib
   JsonLib
-  RedfishHttpCacheLib
 
 [Protocols]
 
diff --git a/RedfishClientPkg/Library/RedfishVersionLib/RedfishVersionLib.c 
b/RedfishClientPkg/Library/RedfishVersionLib/RedfishVersionLib.c
index 828693766..a55238d22 100644
--- a/RedfishClientPkg/Library/RedfishVersionLib/RedfishVersionLib.c
+++ b/RedfishClientPkg/Library/RedfishVersionLib/RedfishVersionLib.c
@@ -14,11 +14,10 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
-#include 
 
 #define REDFISH_VERSION_DEFAULT_STRING  L"v1"
 #define REDFISH_ROOT_URIL"/redfish"
@@ -112,22 +111,12 @@ RedfishGetVersion (
   Status = RedfishHttpGetResource (
  Service,
  REDFISH_ROOT_URI,
+ NULL,
  &Response,
  TRUE
  );
   if (EFI_ERROR (Status)) {
 DEBUG ((DEBUG_ERROR, "%a, RedfishGetByService to %s failed: %r\n", 
__func__, REDFISH_ROOT_URI, Status));
-if (Response.Payload != NULL) {
-  RedfishDumpPayload (Response.Payload);
-  RedfishFreeResponse (
-NULL,
-0,
-NULL,
-Response.Payload
-);
-  Response.Payload = NULL;
-}
-
 goto ON_ERROR;
   }
 
@@ -156,14 +145,7 @@ ON_ERROR:
 VersionString = REDFISH_VERSION_DEFAULT_STRING;
   }
 
-  if (Response.Payload != NULL) {
-RedfishFreeResponse (
-  Response.StatusCode,
-  Response.HeaderCount,
-  Response.Headers,
-  Response.Payload
-  );
-  }
+  RedfishHttpFreeResponse (&Response);
 
   DEBUG ((DEBUG_MANAGEABILITY, "%a: Redfish version - %s\n", __func__, 
VersionString));
   return AllocateCopyPool (StrSize (VersionString), VersionString);
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116146): https://edk2.groups.io/g/devel/message/116146
Mute This Topic: https://groups.io/mt/104640227/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-redfish-client][PATCH 05/13] RedfishClientPkg/RedfishFeatureUtilityLib: ues RedfishHttpLib

[Nickle Wang via groups.io]

- Remove RedfishHttpCacheLib and use EDK2 RedfishHttpLib.
- Remove RedfishLib.
- Remove CreatePayloadToPostResource and CreatePayloadToPatchResource
because we no longer need them.

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
---
 .../RedfishFeatureUtilityLib.inf  |   3 +-
 .../Library/RedfishFeatureUtilityLib.h|  46 +
 .../RedfishFeatureUtilityInternal.h   |   3 +-
 .../RedfishFeatureUtilityLib.c| 182 +-
 4 files changed, 6 insertions(+), 228 deletions(-)

diff --git 
a/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.inf
 
b/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.inf
index d8f3da373..1cb2d5595 100644
--- 
a/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.inf
+++ 
b/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.inf
@@ -40,7 +40,7 @@
   ConverterCommonLib
   DebugLib
   MemoryAllocationLib
-  RedfishLib
+  RedfishHttpLib
   RedfishPlatformConfigLib
   UefiLib
   UefiBootServicesTableLib
@@ -48,7 +48,6 @@
   PrintLib
   HttpLib
   RedfishDebugLib
-  RedfishHttpCacheLib
 
 [Protocols]
   gEdkIIRedfishETagProtocolGuid   ## CONSUMED ##
diff --git a/RedfishClientPkg/Include/Library/RedfishFeatureUtilityLib.h 
b/RedfishClientPkg/Include/Library/RedfishFeatureUtilityLib.h
index 1b6d3f4cf..ba9ea0150 100644
--- a/RedfishClientPkg/Include/Library/RedfishFeatureUtilityLib.h
+++ b/RedfishClientPkg/Include/Library/RedfishFeatureUtilityLib.h
@@ -12,7 +12,7 @@
 #ifndef REDFISH_FEATURE_UTILITY_LIB_H_
 #define REDFISH_FEATURE_UTILITY_LIB_H_
 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -352,50 +352,6 @@ ApplyFeatureSettingsBooleanArrayType (
   IN  RedfishCS_bool_Array  *ArrayHead
   );
 
-/**
-
-  Create HTTP payload and send them to redfish service with POST method.
-
-  @param[in]  Service Redfish service.
-  @param[in]  TargetPayload   Target payload
-  @param[in]  JsonData in JSON format.
-  @param[out] LocationReturned location string from Redfish service.
-  @param[out] EtagReturned ETAG string from Redfish service.
-
-  @retval EFI_SUCCESS Data is sent to redfish service successfully.
-  @retval Others  Errors occur.
-
-**/
-EFI_STATUS
-CreatePayloadToPostResource (
-  IN  REDFISH_SERVICE  *Service,
-  IN  REDFISH_PAYLOAD  *TargetPayload,
-  IN  CHAR8*Json,
-  OUT EFI_STRING   *Location,
-  OUT CHAR8**Etag
-  );
-
-/**
-
-  Create HTTP payload and send them to redfish service with PATCH method.
-
-  @param[in]  Service Redfish service.
-  @param[in]  TargetPayload   Target payload
-  @param[in]  JsonData in JSON format.
-  @param[out] EtagReturned ETAG string from Redfish service.
-
-  @retval EFI_SUCCESS Data is sent to redfish service successfully.
-  @retval Others  Errors occur.
-
-**/
-EFI_STATUS
-CreatePayloadToPatchResource (
-  IN  REDFISH_SERVICE  *Service,
-  IN  REDFISH_PAYLOAD  *TargetPayload,
-  IN  CHAR8*Json,
-  OUT CHAR8**Etag
-  );
-
 /**
 
   Save Redfish URI in database for further use.
diff --git 
a/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityInternal.h
 
b/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityInternal.h
index b4cfca030..b1c2ee468 100644
--- 
a/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityInternal.h
+++ 
b/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityInternal.h
@@ -21,7 +21,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -30,7 +30,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 
diff --git 
a/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c 
b/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c
index 21ce8ddad..cc2b37b79 100644
--- 
a/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c
+++ 
b/RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.c
@@ -154,7 +154,7 @@ SetEtagFromUri (
   }
 
   ZeroMem (&Response, sizeof (Response));
-  Status = RedfishHttpGetResource (RedfishService, Uri, &Response, TRUE);
+  Status = RedfishHttpGetResource (RedfishService, Uri, NULL, &Response, TRUE);
   if (EFI_ERROR (Status)) {
 DEBUG ((DEBUG_ERROR, "%a: get resource from: %s failed\n", __func__, Uri));
 return Status;
@@ -215,14 +215,7 @@ ON_RELEASE:
 FreePool (PendingSettingUri);
   }
 
-  if (Response.Payload != NULL) {
-RedfishFreeResponse (
-  Response.StatusCode,
-  Response.HeaderCount,
-  Response.Headers,
-  Response.Payload
-  );
-  }
+  RedfishHttpFreeResponse (&Response);
 
   return Status;
 }
@@ -1894,175 +1887,6 @@ CheckIsServerEtagSupported (
   return FixedPcdGetBool (PcdRedfishServiceEtagSupported);
 }

[edk2-devel] [edk2-redfish-client][PATCH 04/13] RedfishClientPkg/RedfishResourceConfigLib: ues RedfishHttpLib

[Nickle Wang via groups.io]

Remove RedfishHttpCacheLib and use EDK2 RedfishHttpLib.

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
---
 .../EdkIIRedfishResourceConfigLib.inf   | 2 +-
 .../Include/Library/EdkIIRedfishResourceConfigLib.h | 4 ++--
 .../EdkIIRedfishResourceConfigLib.c | 6 +++---
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git 
a/RedfishClientPkg/Library/EdkIIRedfishResourceConfigLib/EdkIIRedfishResourceConfigLib.inf
 
b/RedfishClientPkg/Library/EdkIIRedfishResourceConfigLib/EdkIIRedfishResourceConfigLib.inf
index a5a81e9a2..2d10445f0 100644
--- 
a/RedfishClientPkg/Library/EdkIIRedfishResourceConfigLib/EdkIIRedfishResourceConfigLib.inf
+++ 
b/RedfishClientPkg/Library/EdkIIRedfishResourceConfigLib/EdkIIRedfishResourceConfigLib.inf
@@ -39,7 +39,7 @@
   MemoryAllocationLib
   RedfishFeatureUtilityLib
   RedfishPlatformConfigLib
-  RedfishHttpCacheLib
+  RedfishHttpLib
 
 [Protocols]
   gEdkIIRedfishResourceConfigProtocolGuid   ## CONSUMES ##
diff --git a/RedfishClientPkg/Include/Library/EdkIIRedfishResourceConfigLib.h 
b/RedfishClientPkg/Include/Library/EdkIIRedfishResourceConfigLib.h
index 561ecbbaf..3aa953cec 100644
--- a/RedfishClientPkg/Include/Library/EdkIIRedfishResourceConfigLib.h
+++ b/RedfishClientPkg/Include/Library/EdkIIRedfishResourceConfigLib.h
@@ -2,7 +2,7 @@
   This file defines the EDKII resource config Library interface.
 
   (C) Copyright 2022 Hewlett Packard Enterprise Development LP
-  Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+  Copyright (c) 2023-2024, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -13,7 +13,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git 
a/RedfishClientPkg/Library/EdkIIRedfishResourceConfigLib/EdkIIRedfishResourceConfigLib.c
 
b/RedfishClientPkg/Library/EdkIIRedfishResourceConfigLib/EdkIIRedfishResourceConfigLib.c
index ed225a23b..5d0944f8c 100644
--- 
a/RedfishClientPkg/Library/EdkIIRedfishResourceConfigLib/EdkIIRedfishResourceConfigLib.c
+++ 
b/RedfishClientPkg/Library/EdkIIRedfishResourceConfigLib/EdkIIRedfishResourceConfigLib.c
@@ -15,8 +15,8 @@
 #include 
 #include 
 #include 
+#include 
 #include 
-#include 
 
 EDKII_REDFISH_RESOURCE_CONFIG_PROTOCOL   
*mRedfishResourceConfigProtocol = NULL;
 EFI_HANDLE   mCachedHandle;
@@ -58,7 +58,7 @@ GetRedfishSchemaInfo (
   }
 
   ZeroMem (&Response, sizeof (Response));
-  Status = RedfishHttpGetResource (RedfishService, Uri, &Response, TRUE);
+  Status = RedfishHttpGetResource (RedfishService, Uri, NULL, &Response, TRUE);
   if (EFI_ERROR (Status)) {
 DEBUG ((DEBUG_ERROR, "%a, failed to get resource from %s: %r", __func__, 
Uri, Status));
 return Status;
@@ -99,7 +99,7 @@ GetRedfishSchemaInfo (
   //
   JsonStructProtocol->DestoryStructure (JsonStructProtocol, Header);
   FreePool (JsonText);
-  RedfishFreeResponse (Response.StatusCode, Response.HeaderCount, 
Response.Headers, Response.Payload);
+  RedfishHttpFreeResponse (&Response);
 
   return EFI_SUCCESS;
 }
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116144): https://edk2.groups.io/g/devel/message/116144
Mute This Topic: https://groups.io/mt/104640225/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-redfish-client][PATCH 03/13] RedfishClientPkg: ues RedfishHttpLib

[Nickle Wang via groups.io]

Use EDK2 RedfishHttpLib to replace RedfishHttpCacheLib and RedfishLib

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
---
 RedfishClientPkg/Include/RedfishCollectionCommon.h | 3 +--
 RedfishClientPkg/Include/RedfishResourceCommon.h   | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/RedfishClientPkg/Include/RedfishCollectionCommon.h 
b/RedfishClientPkg/Include/RedfishCollectionCommon.h
index b1e313da2..f7c870172 100644
--- a/RedfishClientPkg/Include/RedfishCollectionCommon.h
+++ b/RedfishClientPkg/Include/RedfishCollectionCommon.h
@@ -21,13 +21,12 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 
 //
 // Protocols
diff --git a/RedfishClientPkg/Include/RedfishResourceCommon.h 
b/RedfishClientPkg/Include/RedfishResourceCommon.h
index c1286adc1..43a527a05 100644
--- a/RedfishClientPkg/Include/RedfishResourceCommon.h
+++ b/RedfishClientPkg/Include/RedfishResourceCommon.h
@@ -23,7 +23,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -32,7 +32,6 @@
 #include 
 #include 
 #include 
-#include 
 
 //
 // Protocols
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116143): https://edk2.groups.io/g/devel/message/116143
Mute This Topic: https://groups.io/mt/104640217/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-redfish-client][PATCH 02/13] RedfishClientPkg: remove RedfishHttpCacheLib

[Nickle Wang via groups.io]

Remove RedfishHttpCacheLib and use EDK2 RedfishHttpLib.

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
---
 RedfishClientPkg/RedfishClientPkg.dec |   1 -
 RedfishClientPkg/RedfishClientLibs.dsc.inc|   2 +-
 RedfishClientPkg/RedfishClientPkg.dsc |   1 -
 .../RedfishHttpCacheLib.inf   |  48 --
 .../Include/Library/RedfishHttpCacheLib.h |  59 --
 .../RedfishHttpCacheLibInternal.h |  63 --
 .../RedfishHttpCacheLib/RedfishHttpCacheLib.c | 774 --
 7 files changed, 1 insertion(+), 947 deletions(-)
 delete mode 100644 
RedfishClientPkg/Library/RedfishHttpCacheLib/RedfishHttpCacheLib.inf
 delete mode 100644 RedfishClientPkg/Include/Library/RedfishHttpCacheLib.h
 delete mode 100644 
RedfishClientPkg/Library/RedfishHttpCacheLib/RedfishHttpCacheLibInternal.h
 delete mode 100644 
RedfishClientPkg/Library/RedfishHttpCacheLib/RedfishHttpCacheLib.c

diff --git a/RedfishClientPkg/RedfishClientPkg.dec 
b/RedfishClientPkg/RedfishClientPkg.dec
index ce3b6d975..aa018d714 100644
--- a/RedfishClientPkg/RedfishClientPkg.dec
+++ b/RedfishClientPkg/RedfishClientPkg.dec
@@ -27,7 +27,6 @@
   EdkIIRedfishResourceConfigLib|Include/Library/EdkIIRedfishResourceConfigLib.h
   RedfishEventLib|Include/Library/RedfishEventLib.h
   RedfishVersionLib|Include/Library/RedfishVersionLib.h
-  RedfishHttpCacheLib|Include/Library/RedfishHttpCacheLib.h
 
 [LibraryClasses.Common.Private]
   ##  @libraryclass Redfish Helper Library
diff --git a/RedfishClientPkg/RedfishClientLibs.dsc.inc 
b/RedfishClientPkg/RedfishClientLibs.dsc.inc
index 9c7889d2b..8ec27baa3 100644
--- a/RedfishClientPkg/RedfishClientLibs.dsc.inc
+++ b/RedfishClientPkg/RedfishClientLibs.dsc.inc
@@ -42,4 +42,4 @@
   
RedfishVersionLib|RedfishClientPkg/Library/RedfishVersionLib/RedfishVersionLib.inf
   
RedfishAddendumLib|RedfishClientPkg/Library/RedfishAddendumLib/RedfishAddendumLib.inf
   RedfishDebugLib|RedfishPkg/Library/RedfishDebugLib/RedfishDebugLib.inf
-  
RedfishHttpCacheLib|RedfishClientPkg/Library/RedfishHttpCacheLib/RedfishHttpCacheLib.inf
+  RedfishHttpLib|RedfishPkg/Library/RedfishHttpLib/RedfishHttpLib.inf
diff --git a/RedfishClientPkg/RedfishClientPkg.dsc 
b/RedfishClientPkg/RedfishClientPkg.dsc
index 0e3ef1ac9..f37bf93ac 100644
--- a/RedfishClientPkg/RedfishClientPkg.dsc
+++ b/RedfishClientPkg/RedfishClientPkg.dsc
@@ -61,6 +61,5 @@
   
RedfishClientPkg/Library/RedfishFeatureUtilityLib/RedfishFeatureUtilityLib.inf
   RedfishClientPkg/PrivateLibrary/RedfishLib/RedfishLib.inf
   RedfishClientPkg/Library/RedfishAddendumLib/RedfishAddendumLib.inf
-  RedfishClientPkg/Library/RedfishHttpCacheLib/RedfishHttpCacheLib.inf
 
   !include RedfishClientPkg/RedfishClient.dsc.inc
diff --git 
a/RedfishClientPkg/Library/RedfishHttpCacheLib/RedfishHttpCacheLib.inf 
b/RedfishClientPkg/Library/RedfishHttpCacheLib/RedfishHttpCacheLib.inf
deleted file mode 100644
index e76c8b65e..0
--- a/RedfishClientPkg/Library/RedfishHttpCacheLib/RedfishHttpCacheLib.inf
+++ /dev/null
@@ -1,48 +0,0 @@
-## @file
-#  Redfish HTTP cache library helps Redfish application to get Redfish resource
-#  from Redfish service with cache mechanism enabled.
-#
-#  Copyright (c) 2023-2024, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
-#
-#  SPDX-License-Identifier: BSD-2-Clause-Patent
-#
-##
-
-[Defines]
-  INF_VERSION= 0x00010006
-  BASE_NAME  = RedfishHttpCacheLib
-  FILE_GUID  = 21F8FEEC-023C-451D-824D-823058FD9481
-  MODULE_TYPE= DXE_DRIVER
-  VERSION_STRING = 1.0
-  LIBRARY_CLASS  = RedfishHttpCacheLib| DXE_DRIVER UEFI_DRIVER
-  CONSTRUCTOR= RedfishHttpCacheConstructor
-  DESTRUCTOR = RedfishHttpCacheDestructor
-
-#
-#  VALID_ARCHITECTURES   = IA32 X64 EBC
-#
-
-[Sources]
-  RedfishHttpCacheLibInternal.h
-  RedfishHttpCacheLib.c
-
-[Packages]
-  MdePkg/MdePkg.dec
-  MdeModulePkg/MdeModulePkg.dec
-  RedfishPkg/RedfishPkg.dec
-  RedfishClientPkg/RedfishClientPkg.dec
-
-[LibraryClasses]
-  BaseLib
-  DebugLib
-  UefiBootServicesTableLib
-  MemoryAllocationLib
-  RedfishLib
-  UefiLib
-  RedfishDebugLib
-  ReportStatusCodeLib
-  PrintLib
-
-[depex]
-  TRUE
-
diff --git a/RedfishClientPkg/Include/Library/RedfishHttpCacheLib.h 
b/RedfishClientPkg/Include/Library/RedfishHttpCacheLib.h
deleted file mode 100644
index 1277b9814..0
--- a/RedfishClientPkg/Include/Library/RedfishHttpCacheLib.h
+++ /dev/null
@@ -1,59 +0,0 @@
-/** @file
-  This file defines the Redfish HTTP cache library interface.
-
-  Copyright (c) 2023-2024, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
-
-  SPDX-License-Identifier: BSD-2-Clause-Patent
-
-**/
-
-#ifndef REDFISH_HTTP_CACHE_LIB_H_
-#define REDFISH_HTTP_CACHE_LIB_H_
-
-#include 
-#include 
-
-/**
-  Get redfish resource from given resource URI with cache mechanism
-  supported. It's caller's responsibility to Response by

[edk2-devel] [edk2-redfish-client][PATCH 01/13] RedfishClientPkg/.github: do not run uncrustify to deleted file.

[Nickle Wang via groups.io]

Check to see if file exists or not before running uncrustify.
The file in change list may be a deleted file.

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
---
 .github/workflows/uncrustify-check.sh | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/.github/workflows/uncrustify-check.sh 
b/.github/workflows/uncrustify-check.sh
index 7c1765cff..e6cf00b1f 100755
--- a/.github/workflows/uncrustify-check.sh
+++ b/.github/workflows/uncrustify-check.sh
@@ -1,6 +1,6 @@
 #!/bin/bash
 #
-# Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+# Copyright (c) 2023-2024, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
 #
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -40,12 +40,17 @@ fi
 
 for file in $CHANGED_FILES
 do
-  echo "Uncrustify check file: $file"
-  uncrustify -c $CONFIG_FILE -f $file --check
-  if [ $? -ne 0 ]
+  if [ -e "$file" ]
   then
-echo "Uncrustify check failure on file: $file"
-FAILURE=1
+echo "Uncrustify check file: $file"
+uncrustify -c $CONFIG_FILE -f $file --check
+if [ $? -ne 0 ]
+then
+  echo "Uncrustify check failure on file: $file"
+  FAILURE=1
+fi
+  else
+echo "File does not exist (deleted file?): $file"
   fi
 done
 
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116141): https://edk2.groups.io/g/devel/message/116141
Mute This Topic: https://groups.io/mt/104640215/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-redfish-client][PATCH 00/13] use Redfish HTTP protocol

[Nickle Wang via groups.io]

Redfish HTTP protocol is introduced to edk2 RedfishPkg. Update 
RedfishClientPkg to use RedfishHttpLib. And remove the use of 
RedfishHttpCacheLib. 

I also replace several functions from RedfishLib with the function 
provided in RedfishHttpLib. In this way, there is no dependency on 
RedfishLib in RedfishClientPkg.

I noticed that there is false alarm in uncrustify check. When there
are deleted files, uncrustiry cannot check them and trigger uncrustify
failure.

Pull request is created here for testing CI: 
https://github.com/tianocore/edk2-redfish-client/pull/79

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 

Nickle Wang (13):
  RedfishClientPkg/.github: do not run uncrustify to deleted file.
  RedfishClientPkg: remove RedfishHttpCacheLib
  RedfishClientPkg: ues RedfishHttpLib
  RedfishClientPkg/RedfishResourceConfigLib: ues RedfishHttpLib
  RedfishClientPkg/RedfishFeatureUtilityLib: ues RedfishHttpLib
  RedfishClientPkg/RedfishVersionLib: ues RedfishHttpLib
  RedfishClientPkg/BiosDxe: ues RedfishHttpLib
  RedfishClientPkg/BootOptionDxe: ues RedfishHttpLib
  RedfishClientPkg/BootOptionCollectionDxe: ues RedfishHttpLib
  RedfishClientPkg/ComputerSystemDxe: ues RedfishHttpLib
  RedfishClientPkg/ComputerSystemCollectionDxe: ues RedfishHttpLib
  RedfishClientPkg/MemoryDxe: ues RedfishHttpLib
  RedfishClientPkg/MemoryCollectionDxe: ues RedfishHttpLib

 RedfishClientPkg/RedfishClientPkg.dec |   1 -
 RedfishClientPkg/RedfishClientLibs.dsc.inc|   2 +-
 RedfishClientPkg/RedfishClientPkg.dsc |   1 -
 .../Features/Bios/v1_0_9/Dxe/BiosDxe.inf  |   3 +-
 .../BootOption/v1_0_4/Dxe/BootOptionDxe.inf   |   5 +-
 .../BootOptionCollectionDxe.inf   |   5 +-
 .../v1_13_0/Dxe/ComputerSystemDxe.inf |   3 +-
 .../v1_5_0/Dxe/ComputerSystemDxe.inf  |   3 +-
 .../ComputerSystemCollectionDxe.inf   |   3 +-
 .../Features/Memory/V1_7_1/Dxe/MemoryDxe.inf  |   3 +-
 .../MemoryCollectionDxe.inf   |   3 +-
 .../EdkIIRedfishResourceConfigLib.inf |   2 +-
 .../RedfishFeatureUtilityLib.inf  |   3 +-
 .../RedfishHttpCacheLib.inf   |  48 --
 .../RedfishVersionLib/RedfishVersionLib.inf   |   3 +-
 .../Library/EdkIIRedfishResourceConfigLib.h   |   4 +-
 .../Library/RedfishFeatureUtilityLib.h|  46 +-
 .../Include/Library/RedfishHttpCacheLib.h |  59 --
 .../Include/RedfishCollectionCommon.h |   3 +-
 .../Include/RedfishResourceCommon.h   |   3 +-
 .../RedfishFeatureUtilityInternal.h   |   3 +-
 .../RedfishHttpCacheLibInternal.h |  63 --
 .../Features/Bios/v1_0_9/Common/BiosCommon.c  |  92 +--
 .../Features/Bios/v1_0_9/Dxe/BiosDxe.c| 113 +--
 .../v1_0_4/Common/BootOptionCommon.c  |  45 +-
 .../BootOption/v1_0_4/Dxe/BootOptionDxe.c |  86 +-
 .../BootOptionCollectionDxe.c |  26 +-
 .../v1_13_0/Common/ComputerSystemCommon.c |  68 +-
 .../v1_13_0/Dxe/ComputerSystemDxe.c   |  85 +-
 .../v1_5_0/Common/ComputerSystemCommon.c  |  68 +-
 .../v1_5_0/Dxe/ComputerSystemDxe.c|  84 +-
 .../ComputerSystemCollectionDxe.c |  15 +-
 .../Memory/V1_7_1/Common/MemoryCommon.c   |  86 +-
 .../Features/Memory/V1_7_1/Dxe/MemoryDxe.c| 111 +--
 .../MemoryCollectionDxe/MemoryCollectionDxe.c |  15 +-
 .../EdkIIRedfishResourceConfigLib.c   |   6 +-
 .../RedfishFeatureUtilityLib.c| 182 +---
 .../RedfishHttpCacheLib/RedfishHttpCacheLib.c | 774 --
 .../RedfishVersionLib/RedfishVersionLib.c |  24 +-
 .github/workflows/uncrustify-check.sh |  17 +-
 40 files changed, 328 insertions(+), 1838 deletions(-)
 delete mode 100644 
RedfishClientPkg/Library/RedfishHttpCacheLib/RedfishHttpCacheLib.inf
 delete mode 100644 RedfishClientPkg/Include/Library/RedfishHttpCacheLib.h
 delete mode 100644 
RedfishClientPkg/Library/RedfishHttpCacheLib/RedfishHttpCacheLibInternal.h
 delete mode 100644 
RedfishClientPkg/Library/RedfishHttpCacheLib/RedfishHttpCacheLib.c

-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116140): https://edk2.groups.io/g/devel/message/116140
Mute This Topic: https://groups.io/mt/104640214/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/1] UefiCpuPkg/MpInitLib: add struct MP_HAND_OFF_CONFIG

[Laszlo Ersek]

On 2/28/24 12:48, Gerd Hoffmann wrote:
> Move the WaitLoopExecutionMode and StartupSignalValue fields to a
> separate HOB with the new struct.
> 
> WaitLoopExecutionMode and StartupSignalValue are independent of
> processor index ranges; they are global to MpInitLib (i.e., the entire
> system). Therefore they shouldn't be repeated in every MpHandOff GUID
> HOB.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  UefiCpuPkg/Library/MpInitLib/MpHandOff.h | 13 ++-
>  UefiCpuPkg/Library/MpInitLib/MpLib.h |  3 +-
>  UefiCpuPkg/Library/MpInitLib/MpLib.c | 47 +---
>  UefiCpuPkg/Library/MpInitLib/PeiMpLib.c  | 34 ++---
>  4 files changed, 75 insertions(+), 22 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpHandOff.h 
> b/UefiCpuPkg/Library/MpInitLib/MpHandOff.h
> index 77854d6a81f8..ae93b7e3d7c9 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpHandOff.h
> +++ b/UefiCpuPkg/Library/MpInitLib/MpHandOff.h
> @@ -15,7 +15,13 @@
>  0x11e2bd88, 0xed38, 0x4abd, {0xa3, 0x99, 0x21, 0xf2, 0x5f, 0xd0, 0x7a, 
> 0x60 } \
>}
>  
> +#define MP_HANDOFF_CONFIG_GUID \
> +  { \
> +0xdabbd793, 0x7b46, 0x4144, {0x8a, 0xd4, 0x10, 0x1c, 0x7c, 0x08, 0xeb, 
> 0xfa } \
> +  }
> +
>  extern EFI_GUID  mMpHandOffGuid;
> +extern EFI_GUID  mMpHandOffConfigGuid;
>  
>  //
>  // The information required to transfer from the PEI phase to the
> @@ -43,8 +49,11 @@ typedef struct {
>//
>UINT32ProcessorIndex;
>UINT32CpuCount;
> -  UINT32WaitLoopExecutionMode;
> -  UINT32StartupSignalValue;
>PROCESSOR_HAND_OFFInfo[];
>  } MP_HAND_OFF;
> +
> +typedef struct {
> +  UINT32WaitLoopExecutionMode;
> +  UINT32StartupSignalValue;
> +} MP_HAND_OFF_CONFIG;
>  #endif
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.h 
> b/UefiCpuPkg/Library/MpInitLib/MpLib.h
> index 3a7b9896cff4..d26035559f22 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.h
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.h
> @@ -482,7 +482,8 @@ GetWakeupBuffer (
>  **/
>  VOID
>  SwitchApContext (
> -  IN CONST MP_HAND_OFF  *FirstMpHandOff
> +  IN CONST MP_HAND_OFF_CONFIG  *MpHandOffConfig,
> +  IN CONST MP_HAND_OFF *FirstMpHandOff
>);
>  
>  /**
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> index 8c186211fb38..9bac62f289e0 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> @@ -15,6 +15,7 @@
>  
>  EFI_GUID  mCpuInitMpLibHobGuid = CPU_INIT_MP_LIB_HOB_GUID;
>  EFI_GUID  mMpHandOffGuid   = MP_HANDOFF_GUID;
> +EFI_GUID  mMpHandOffConfigGuid = MP_HANDOFF_CONFIG_GUID;
>  
>  /**
>Save the volatile registers required to be restored following INIT IPI.
> @@ -1935,11 +1936,13 @@ GetBspNumber (
>This procedure allows the AP to switch to another section of
>memory and continue its loop there.
>  
> -  @param[in] FirstMpHandOff  Pointer to first MP hand-off HOB body.
> +  @param[in] MpHandOffConfig  Pointer to MP hand-off config HOB body.
> +  @param[in] FirstMpHandOff   Pointer to first MP hand-off HOB body.
>  **/
>  VOID
>  SwitchApContext (
> -  IN CONST MP_HAND_OFF  *FirstMpHandOff
> +  IN CONST MP_HAND_OFF_CONFIG  *MpHandOffConfig,
> +  IN CONST MP_HAND_OFF *FirstMpHandOff
>)
>  {
>UINTN  Index;
> @@ -1955,7 +1958,7 @@ SwitchApContext (
>  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;
> +*(UINT32 *)(UINTN)MpHandOff->Info[Index].StartupSignalAddress   = 
> MpHandOffConfig->StartupSignalValue;
>}
>  }
>}
> @@ -1975,6 +1978,26 @@ SwitchApContext (
>}
>  }
>  
> +/**
> +  Get pointer to MP_HAND_OFF_CONFIG GUIDed HOB body.
> +
> +  @return  The pointer to MP_HAND_OFF_CONFIG structure.
> +**/
> +MP_HAND_OFF_CONFIG *
> +GetMpHandOffConfigHob (
> +  VOID
> +  )
> +{
> +  EFI_HOB_GUID_TYPE  *GuidHob;
> +
> +  GuidHob = GetFirstGuidHob (&mMpHandOffConfigGuid);
> +  if (GuidHob == NULL) {
> +return NULL;
> +  }
> +
> +  return (MP_HAND_OFF_CONFIG *)GET_GUID_HOB_DATA (GuidHob);
> +}
> +
>  /**
>Get pointer to next MP_HAND_OFF GUIDed HOB body.
>  
> @@ -2022,6 +2045,7 @@ MpInitLibInitialize (
>VOID
>)
>  {
> +  MP_HAND_OFF_CONFIG   *MpHandOffConfig;
>MP_HAND_OFF  *FirstMpHandOff;
>MP_HAND_OFF  *MpHandOff;
>CPU_INFO_IN_HOB  *CpuInfoInHob;
> @@ -2239,13 +2263,24 @@ MpInitLibInitialize (
>}
>  }
>  
> +MpHandOffConfig = GetMpHandOffConfigHob ();
> +if (MpHandOffConfig == NULL) {
> +  DEBUG ((
> +DEBUG_ERROR,
> +"%a: at least one MpHandOff HOB, but no MpHandOffConfig HOB\n",
> +__func__
> + 

Re: [edk2-devel] CI: GCC13 and lcov problem

[Laszlo Ersek]

On 2/28/24 14:59, Oliver Steffen wrote:
> Hi,
> 
> I am working on switching the Linux CI jobs over to the Fedora 39 image
> which comes with gcc 13.
> 
> Unfortunately, some jobs fail due to some error related to lcov /
> geninfo, see below.
> 
> Does anybody know from the top of the head what this is about / what to do?
> PR: https://github.com/tianocore/edk2/pull/5412
> 
> Job log:
> 
> INFO - Cmd to run is: lcov --capture --directory
> /__w/1/s/Build/SecurityPkg/HostTest/NOOPT_GCC5/ --output-file
> /__w/1/s/Build/SecurityPkg/HostTest/NOOPT_GCC5/coverage-test.info --rc
> lcov_branch_coverage=1
> INFO - 
> INFO - --Cmd Output Starting---
> INFO - 
> INFO - Capturing coverage data from
> /__w/1/s/Build/SecurityPkg/HostTest/NOOPT_GCC5/
> INFO - geninfo cmd: '/usr/bin/geninfo
> /__w/1/s/Build/SecurityPkg/HostTest/NOOPT_GCC5/ --output-filename
> /__w/1/s/Build/SecurityPkg/HostTest/NOOPT_GCC5/coverage-test.info --rc
> lcov_branch_coverage=1 --memory 0 --branch-coverage'
> INFO - geninfo: WARNING: RC option 'lcov_branch_coverage' is
> deprecated.  Consider using 'branch_coverage. instead.
> (Backward-compatible support will be removed in the future
> INFO - Found gcov version: 13.2.1
> INFO - Using intermediate gcov format
> INFO - Writing temporary data to /tmp/geninfo_datXdcz
> INFO - Scanning /__w/1/s/Build/SecurityPkg/HostTest/NOOPT_GCC5/ for
> .gcda files ...
> INFO - Found 99 data files in /__w/1/s/Build/SecurityPkg/HostTest/NOOPT_GCC5/
> INFO - Processing
> /__w/1/s/Build/SecurityPkg/HostTest/NOOPT_GCC5/X64/UnitTestFrameworkPkg/Library/UnitTestDebugAssertLib/UnitTestDebugAssertLibHost/OUTPUT/UnitTestDebugAssertLibHost.gcda
> INFO - Processing
> /__w/1/s/Build/SecurityPkg/HostTest/NOOPT_GCC5/X64/UnitTestFrameworkPkg/Library/UnitTestPersistenceLibNull/UnitTestPersistenceLibNull/OUTPUT/UnitTestPersistenceLibNull.gcda
> INFO - Processing
> /__w/1/s/Build/SecurityPkg/HostTest/NOOPT_GCC5/X64/UnitTestFrameworkPkg/Library/Posix/DebugLibPosix/DebugLibPosix/OUTPUT/DebugLibPosix.gcda
> INFO - Processing
> /__w/1/s/Build/SecurityPkg/HostTest/NOOPT_GCC5/X64/UnitTestFrameworkPkg/Library/Posix/MemoryAllocationLibPosix/MemoryAllocationLibPosix/OUTPUT/MemoryAllocationLibPosix.gcda
> INFO - Processing
> /__w/1/s/Build/SecurityPkg/HostTest/NOOPT_GCC5/X64/UnitTestFrameworkPkg/Library/UnitTestResultReportLib/UnitTestResultReportLibDebugLib/OUTPUT/UnitTestResultReportLib.gcda
> INFO - Processing
> /__w/1/s/Build/SecurityPkg/HostTest/NOOPT_GCC5/X64/UnitTestFrameworkPkg/Library/UnitTestResultReportLib/UnitTestResultReportLibDebugLib/OUTPUT/UnitTestResultReportLibDebugLib.gcda
> INFO - Processing
> /__w/1/s/Build/SecurityPkg/HostTest/NOOPT_GCC5/X64/UnitTestFrameworkPkg/Library/CmockaLib/CmockaLib/OUTPUT/cmocka/src/cmocka.gcda
> INFO - geninfo: WARNING:
> /__w/1/s/UnitTestFrameworkPkg/Library/CmockaLib/cmocka/src/cmocka.c:725:
> unexecuted block on non-branch line with non-zero hit count.  Use
> "geninfo --rc geninfo_unexecuted_blocks=1 to set count to zero.
> INFO - Processing
> /__w/1/s/Build/SecurityPkg/HostTest/NOOPT_GCC5/X64/UnitTestFrameworkPkg/Library/GoogleTestLib/GoogleTestLib/OUTPUT/googletest/googlemock/src/gmock-all.gcda
> INFO - geninfo: ERROR: "/usr/include/c++/13/bits/stl_tree.h":2129:
> mismatched exception tag for id 1, 1: '1' -> '0'
> INFO -(use "geninfo --ignore-errors mismatch ..." to bypass this 
> error)
> INFO - 
> INFO - --Cmd Output Finished---
> INFO - - Running Time (mm:ss): 00:00 --
> INFO - --- Return Code: 0x0001 
> INFO - 
> ERROR - UnitTest Coverage: Failed to build coverage data for tested files.
> ERROR - Plugin Failed: Host-Based Unit Test Runner returned 1
> CRITICAL - Post Build failed
> PROGRESS - End time: 2024-02-26 16:18:23.207202Total time Elapsed: 
> 0:00:32
> ERROR - --->Test Failed: Host Unit Test Compiler Plugin NOOPT returned 1

Seems like lcov / geninfo cannot convert the collected gcov coverage
data file to a "trace file". The geninfo manual says,

--ignore-errors errors

Specify a list of errors after which to continue processing.

Use this option to specify a list of one or more classes of errors
after which geninfo should continue processing instead of aborting.
Note that the tool will generate a warning (rather than a fatal
error) unless you ignore the error two (or more) times:

geninfo ... --ignore-errors unused,unused

errors can be a comma-separated list of the following keywords:

[...]

mismatch: Inconsistent entries found in trace file:

branch expression (3rd field in the .info file 'BRDA' entry) of
merge data does not match, or

function execution count (FNDA:...) but no function declaration
(FN:...).

I think