date:20230104

[edk2-devel] [PATCH V1 1/1] OvmfPkg/IntelTdxX64: Raise DXEFV size to 13MB

2023-01-04 Thread Min Xu

From: Min M Xu 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4236

Similarly to the "cadence" mentioned in commit d272449 ("OvmfPkg:
raise DXEFV size to 11 MB", 2018-05-29), it's been ~1.75 years since
commit 5e75c4d ("OvmfPkg: raise DXEFV size to 12 MB", 2020-03-11),
and we've outgrown DXEFV again (with NOOPT builds).  Increase the DXEFV
size of IntelTdxX64 to 13MB now.

Tested on:
 - X64, Intel's TDX platform, RHEL-8.6 guest

Test steps:
 - Configure 4 vCPUs and 4G memory
 - boot and bring up the RHEL 8.6 guest

Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: Gerd Hoffmann 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Julien Grall 
Cc: Laszlo Ersek 
Cc: Peter Grehan 
Cc: Rebecca Cran 
Cc: Sebastien Boeuf 
Cc: Tom Lendacky 
Signed-off-by: Min Xu 
---
 OvmfPkg/IntelTdx/IntelTdxX64.fdf | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.fdf b/OvmfPkg/IntelTdx/IntelTdxX64.fdf
index e79ad3e10217..0bb70ee2b7c3 100644
--- a/OvmfPkg/IntelTdx/IntelTdxX64.fdf
+++ b/OvmfPkg/IntelTdx/IntelTdxX64.fdf
@@ -62,10 +62,10 @@ FV = SECFV
 
 [FD.MEMFD]
 BaseAddress   = $(MEMFD_BASE_ADDRESS)
-Size  = 0xD0
+Size  = 0xE0
 ErasePolarity = 1
 BlockSize = 0x1
-NumBlocks = 0xD0
+NumBlocks = 0xE0
 
 0x00|0x006000
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
@@ -97,7 +97,7 @@ 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCp
 0x01|0x01
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
 
-0x10|0xC0
+0x10|0xD0
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
 FV = DXEFV
 
-- 
2.29.2.windows.2



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

Re: [edk2-devel] [PATCH] UefiCpuPkg:Fixed AsmRelocateApLoopStart and ensure allocated memory <4GB

2023-01-04 Thread Yuanhao Xie

-The above commit message is not quite clear.
-How about "Fix 32bit version AsmRelocateApLoopStart to retrieve the parameters 
from correct stack offset"?
-I also recommend that you split to 2 patches because the code change here 
fixes two bugs.

Ok, I will split it as 2 patches with updated commit messages.

- Have you confirmed that the 32bit Linux boot hangs without the changes and 
succeeds with the changes?

Yes, I confirmed.
It hangs at: "CpuDxe: Level 5 paging = 0" without code changes. With 
the code changes, the "debug.log" continues to read 
"MpInitChangeApLoopCallback() done!". Linux debug messages are also displayed 
on the terminal.

Thanks,
Yuanhao
-Original Message-
From: Ni, Ray  
Sent: Thursday, January 5, 2023 2:29 PM
To: devel@edk2.groups.io; Xie, Yuanhao 
Cc: Laszlo Ersek ; Gerd Hoffmann ; Ard 
Biesheuvel 
Subject: RE: [edk2-devel] [PATCH] UefiCpuPkg:Fixed AsmRelocateApLoopStart and 
ensure allocated memory <4GB

> Fixed AsmRelocateApLoopStart stack offset in Ia32.

The above commit message is not quite clear.
How about "Fix 32bit version AsmRelocateApLoopStart to retrieve the parameters 
from correct stack offset"?

I also recommend that you split to 2 patches because the code change here fixes 
two bugs.

Have you confirmed that the 32bit Linux boot hangs without the changes and 
succeeds with the changes?

Thanks,
Ray


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

Re: [edk2-devel] [PATCH v1] IntelSiliconPkg: Add FVI_SMBIOS_TYPE definition in FirmwareVersionInfo.h

2023-01-04 Thread Ni, Ray

Which spec defines 0xDD?

> -Original Message-
> From: Chang, Hunter 
> Sent: Wednesday, January 4, 2023 3:47 PM
> To: devel@edk2.groups.io
> Cc: Chang, Hunter ; Ni, Ray ; 
> Chaganty, Rangasai V
> ; Oram, Isaac W ; S, 
> Ashraf Ali 
> Subject: [PATCH v1] IntelSiliconPkg: Add FVI_SMBIOS_TYPE definition in 
> FirmwareVersionInfo.h
> 
> From: Hunter Chang 
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4242
> 
> Define a macro for SmbiosFeaturePkg usage which named
> INTEL_FVI_SMBIOS_TYPE and initialized to 0xDD in
> IndustryStandard/FirmwareVersionInfo.h
> 
> Signed-off-by: Hunter Chang 
> 
> Cc: Ray Ni 
> Cc: Rangasai V Chaganty 
> Cc: Isaac Oram 
> Cc: Ashraf Ali S 
> ---
>  Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/FirmwareVersionInfo.h 
> | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git 
> a/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/FirmwareVersionInfo.h
> b/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/FirmwareVersionInfo.h
> index b30bc3f9e7..466cb8e7d2 100644
> --- 
> a/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/FirmwareVersionInfo.h
> +++ 
> b/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/FirmwareVersionInfo.h
> @@ -18,6 +18,7 @@
>  #include 
> 
> 
> 
>  #define INTEL_FIRMWARE_VERSION_INFO_GROUP_NAME"Firmware Version Info"
> 
> +#define INTEL_FVI_SMBIOS_TYPE 0xDD
> 
> 
> 
>  #pragma pack(1)
> 
> 
> 
> --
> 2.26.2.windows.1



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

Re: [edk2-devel] [PATCH] UefiCpuPkg:Fixed AsmRelocateApLoopStart and ensure allocated memory <4GB

2023-01-04 Thread Ni, Ray

> Fixed AsmRelocateApLoopStart stack offset in Ia32.

The above commit message is not quite clear.
How about "Fix 32bit version AsmRelocateApLoopStart to retrieve the parameters 
from correct stack offset"?

I also recommend that you split to 2 patches because the code change here fixes 
two bugs.

Have you confirmed that the 32bit Linux boot hangs without the changes and 
succeeds with the changes?

Thanks,
Ray


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

[edk2-devel] [PATCH] UefiCpuPkg:Fixed AsmRelocateApLoopStart and ensure allocated memory <4GB

2023-01-04 Thread Yuanhao Xie

Kept 4GB allocation limit for the case that APs are still transferred to
32-bit protected mode on long mode DXE.
Fixed AsmRelocateApLoopStart stack offset in Ia32.

Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=4234

Cc: Eric Dong eric.d...@intel.com
Cc: Ray Ni ray...@intel.com
Cc: Rahul Kumar rahul1.ku...@intel.com
Signed-off-by: Yuanhao Xie 
---
 UefiCpuPkg/Library/MpInitLib/DxeMpLib.c   | 35 ---
 .../Library/MpInitLib/Ia32/MpFuncs.nasm   |  9 ++---
 2 files changed, 25 insertions(+), 19 deletions(-)

diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c 
b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
index beab06a5b1..1994ee44c2 100644
--- a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
@@ -389,7 +389,7 @@ RelocateApLoop (
   MpInitLibWhoAmI ();
   CpuMpData= GetCpuMpData ();
   MwaitSupport = IsMwaitSupport ();
-  if (StandardSignatureIsAuthenticAMD ()) {
+  if (StandardSignatureIsAuthenticAMD () && (sizeof (UINTN) == sizeof 
(UINT64))) {
 StackStart   = CpuMpData->UseSevEsAPMethod ? 
CpuMpData->SevEsAPResetStackStart : mReservedTopOfApStack;
 AsmRelocateApLoopFuncAmd = 
(ASM_RELOCATE_AP_LOOP_AMD)(UINTN)mReservedApLoopFunc;
 AsmRelocateApLoopFuncAmd (
@@ -480,6 +480,7 @@ InitMpGlobalData (
   EFI_GCD_MEMORY_SPACE_DESCRIPTOR  MemDesc;
   UINTNStackBase;
   CPU_INFO_IN_HOB  *CpuInfoInHob;
+  EFI_PHYSICAL_ADDRESS Address;
 
   SaveCpuMpData (CpuMpData);
 
@@ -536,9 +537,9 @@ InitMpGlobalData (
 
   //
   // Avoid APs access invalid buffer data which allocated by BootServices,
-  // so we will allocate reserved data for AP loop code. We also need to
-  // allocate this buffer below 4GB due to APs may be transferred to 32bit
-  // protected mode on long mode DXE.
+  // so we will allocate reserved data for AP loop code. We need to
+  // allocate this buffer below 4GB for the case that APs are transferred
+  // to 32-bit protected mode on long mode DXE.
   // Allocating it in advance since memory services are not available in
   // Exit Boot Services callback function.
   //
@@ -555,19 +556,25 @@ InitMpGlobalData (
  )
);
 
-  mReservedTopOfApStack = (UINTN)AllocateReservedPages (EFI_SIZE_TO_PAGES 
(ApSafeBufferSize));
-  ASSERT (mReservedTopOfApStack != 0);
-  ASSERT ((mReservedTopOfApStack & (UINTN)(CPU_STACK_ALIGNMENT - 1)) == 0);
-  ASSERT ((AP_SAFE_STACK_SIZE & (CPU_STACK_ALIGNMENT - 1)) == 0);
-
-  mReservedApLoopFunc = (VOID *)(mReservedTopOfApStack + CpuMpData->CpuCount * 
AP_SAFE_STACK_SIZE);
-  if (StandardSignatureIsAuthenticAMD ()) {
+  if (StandardSignatureIsAuthenticAMD () && (sizeof (UINTN) == sizeof 
(UINT64))) {
+Address = BASE_4GB - 1;
+Status  = gBS->AllocatePages (
+ AllocateMaxAddress,
+ EfiReservedMemoryType,
+ EFI_SIZE_TO_PAGES (ApSafeBufferSize),
+ 
+ );
+ASSERT_EFI_ERROR (Status);
+mReservedApLoopFunc = (VOID *)((UINTN)Address + CpuMpData->CpuCount * 
AP_SAFE_STACK_SIZE);
 CopyMem (
   mReservedApLoopFunc,
   CpuMpData->AddressMap.RelocateApLoopFuncAddressAmd,
   CpuMpData->AddressMap.RelocateApLoopFuncSizeAmd
   );
   } else {
+Address = (UINTN)AllocateReservedPages (EFI_SIZE_TO_PAGES 
(ApSafeBufferSize));
+ASSERT (Address != 0);
+mReservedApLoopFunc = (VOID *)((UINTN)Address + CpuMpData->CpuCount * 
AP_SAFE_STACK_SIZE);
 CopyMem (
   mReservedApLoopFunc,
   CpuMpData->AddressMap.RelocateApLoopFuncAddress,
@@ -575,12 +582,14 @@ InitMpGlobalData (
   );
 
 mApPageTable = CreatePageTable (
- mReservedTopOfApStack,
+ (UINTN)Address,
  ApSafeBufferSize
  );
   }
 
-  mReservedTopOfApStack += CpuMpData->CpuCount * AP_SAFE_STACK_SIZE;
+  mReservedTopOfApStack = (UINTN)Address + CpuMpData->CpuCount * 
AP_SAFE_STACK_SIZE;
+  ASSERT ((mReservedTopOfApStack & (UINTN)(CPU_STACK_ALIGNMENT - 1)) == 0);
+  ASSERT ((AP_SAFE_STACK_SIZE & (CPU_STACK_ALIGNMENT - 1)) == 0);
 
   Status = gBS->CreateEvent (
   EVT_TIMER | EVT_NOTIFY_SIGNAL,
diff --git a/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm 
b/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
index bfcdbd31c1..5cffa632ab 100644
--- a/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
+++ b/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
@@ -219,20 +219,17 @@ SwitchToRealProcEnd:
 RendezvousFunnelProcEnd:
 
 
;-
-;  AsmRelocateApLoop (MwaitSupport, ApTargetCState, PmCodeSegment, 
TopOfApStack, CountTofinish, Pm16CodeSegment, SevEsAPJumpTable, WakeupBuffer);
-;
-;  The last three parameters (Pm16CodeSegment, SevEsAPJumpTable and 
WakeupBuffer) are
-;  specific to SEV-ES support and are not applicable on IA32.
+;

Re: [edk2-devel] [PATCH 1/1] Platform/RISC-V/PlatformPkg:fix image link error

2023-01-04 Thread Sunil V L

Thanks for the patch!.

Reviewed-by: Sunil V L 

On Thu, Jan 05, 2023 at 11:02:43AM +0800, Dongdong Zhang wrote:
> Hi, all
> Sorry, forgot to add Maintainer and Reviewer.
> Add Sunil V L 
> Add Daniel Schaefer 
> 
> > -原始邮件-发件人:"Dongdong Zhang" 
> > 发送时间:2022-12-28 13:45:50 
> > (星期三)收件人:devel@edk2.groups.io抄送:zhuwen...@eswincomputing.com, 
> > zhen...@eswincomputing.com, jinyanji...@eswincomputing.com, "Dongdong 
> > Zhang" 主题:[PATCH 1/1] 
> > Platform/RISC-V/PlatformPkg:fix image link error
> > 
> > Edk2OpensbiPlatformWrapperLib Library and RiscVSpecialPlatformLib
> > Library mark the serial number in the figure is opposite to
> > the text description, fix it and adjust the text order.
> > 
> > Signed-off-by: Dongdong Zhang 
> > ---
> >  Platform/RISC-V/PlatformPkg/Readme.md | 14 --
> >  1 file changed, 8 insertions(+), 6 deletions(-)
> > 
> > diff --git a/Platform/RISC-V/PlatformPkg/Readme.md 
> > b/Platform/RISC-V/PlatformPkg/Readme.md
> > index 5a344a8..d7166ba 100644
> > --- a/Platform/RISC-V/PlatformPkg/Readme.md
> > +++ b/Platform/RISC-V/PlatformPkg/Readme.md
> > @@ -35,19 +35,21 @@ are from OpenSBI project. edk2 libraries are introduced 
> > as the wrapper libraries
> >  [Indicated as #2 in the figure](#risc-v-edk2-port-design-diagrams)
> >  > ***OpenSbiPlatformLib*** provides the generic RISC-V platform 
> > initialization code. Platform vendor can just utilize this library if they 
> > don't have additional requirements on the platform initialization.
> >  
> > -# RiscVSpecialPlatformLib Library
> > -[Indicated as #3 in the figure](#risc-v-edk2-port-design-diagrams)
> > -> The major use case of this library is to facilitate the interfaces for 
> > platform vendors to provide the special
> > -platform initialization based on the generic platform initialization 
> > library.
> > -
> >  # Edk2OpensbiPlatformWrapperLib Library
> > -[Indicated as #4 in the figure](#risc-v-edk2-port-design-diagrams)
> > +
> > +[Indicated as #3 in the figure](#risc-v-edk2-port-design-diagrams)
> >  > In order to providing the flexibility to edk2 RISC-V firmware solution, 
> > ***Edk2OpensbiPlatformWrapperLib*** is the wrapper library of 
> > [OpenSbiPlatformLib](#OpenSbiPlatformLib-library) to provide the interfaces 
> > for OEM. The ***platform_ops_address***in the generic platform structure is 
> > replaced with ***Edk2OpensbiplatformOps*** in SEC
> >  module. The platform function invoked by OpenSBI core is hooked to 
> > ***Edk2OpensbiPlatformWrapperLib***. This gives
> >  a change to OEM for implementing platform-specific initialization before 
> > and after the generic platform code. OEM
> >  can override this library under their platform folder on demand without 
> > touching ***RiscVOpensbiLib*** library
> >  source files and other common source files.
> >  
> > +# RiscVSpecialPlatformLib Library
> > +
> > +[Indicated as #4 in the figure](#risc-v-edk2-port-design-diagrams)
> > +> The major use case of this library is to facilitate the interfaces for 
> > platform vendors to provide the special
> > +platform initialization based on the generic platform initialization 
> > library.
> > +
> >  # Next Phase Address and Privilege Mode
> >  [Indicated as #5 in the figure](#risc-v-edk2-port-design-diagrams)
> >  > Once OpenSBI finishes the boot initialization, it will jump to the next 
> > phase with the default privilege set to
> > -- 
> > 2.17.1


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

[edk2-devel] [PATCH] Readme: Fix invalid URL

2023-01-04 Thread Dongdong Zhang

The README link of the EDK2 code repository has been changed.

Signed-off-by: Dongdong Zhang 
---
 Readme.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Readme.md b/Readme.md
index 93e4dc5..624f9a6 100644
--- a/Readme.md
+++ b/Readme.md
@@ -9,7 +9,7 @@ please see
 The majority of the content in the EDK II open source project uses a
 [BSD-2-Clause Plus Patent License](License.txt).  Additional details on EDK II
 open source project code contributions can be found in the edk2 repository
-[Readme.md](https://github.com/tianocore/edk2/blob/master/Readme.md).
+[Readme.md](https://github.com/tianocore/edk2/blob/master/ReadMe.rst).
 The EDK II Platforms open source project contains the following components that
 are covered by additional licenses:
 
-- 
2.17.1



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

Re: [edk2-devel] [PATCH 0/1] OvmfPkg/PlatformInitLib: catch QEMU's CPU hotplug reg block regression

2023-01-04 Thread Guo, Gua

@Kinney, Michael D I create a PR to fix it. 
Could you help me for code review and push it to unlock the failure ?
URL: https://github.com/tianocore/edk2/pull/3842/



-Original Message-
From: Kinney, Michael D 
Sent: Thursday, January 5, 2023 7:35 AM
To: devel@edk2.groups.io; ler...@redhat.com; Guo, Gua 
Cc: Ard Biesheuvel ; Brijesh Singh 
; Aktas, Erdem ; Gerd Hoffmann 
; James Bottomley ; Yao, Jiewen 
; Justen, Jordan L ; Xu, Min M 
; Boeuf, Sebastien ; Tom 
Lendacky ; Kinney, Michael D 

Subject: RE: [edk2-devel] [PATCH 0/1] OvmfPkg/PlatformInitLib: catch QEMU's CPU 
hotplug reg block regression



Hi Laszlo,



Unit test code coverage was enabled just a couple days ago in CI.  Looks like 
you uncovered a corner case that was missed that should not generate a CI 
failure.



I have asked Gua to investigate.



Thanks,



Mike



> -Original Message-

> From: devel@edk2.groups.io 
> mailto:devel@edk2.groups.io>> On Behalf Of Laszlo

> Ersek

> Sent: Wednesday, January 4, 2023 7:13 AM

> To: devel@edk2.groups.io

> Cc: Ard Biesheuvel 
> mailto:ardb+tianoc...@kernel.org>>; Brijesh Singh

> mailto:brijesh.si...@amd.com>>; Aktas, Erdem 
> mailto:erdemak...@google.com>>; Gerd

> Hoffmann mailto:kra...@redhat.com>>; James Bottomley 
> mailto:j...@linux.ibm.com>>;

> Yao, Jiewen mailto:jiewen@intel.com>>; Justen, 
> Jordan L

> mailto:jordan.l.jus...@intel.com>>; Xu, Min M 
> mailto:min.m...@intel.com>>; Boeuf,

> Sebastien mailto:sebastien.bo...@intel.com>>; Tom 
> Lendacky

> mailto:thomas.lenda...@amd.com>>

> Subject: [edk2-devel] [PATCH 0/1] OvmfPkg/PlatformInitLib: catch

> QEMU's CPU hotplug reg block regression

>

> Repo:   https://pagure.io/lersek/edk2.git

> Branch: cpuhp-reg-catch-4250

> Test build: https://github.com/tianocore/edk2/pull/3853

> Bugzilla:   https://bugzilla.tianocore.org/show_bug.cgi?id=4250

>

> NOTE: the test build linked above (in the github.com CI env) *failed*.

> That's because the CI environment is affected by this very QEMU bug!

>

> Namely, the following checks failed -- due to the intentional hang

> introduced in this patch:

>

> - PlatformCI_OvmfPkg_Ubuntu_GCC5_PR (12 tests)

> - PlatformCI_OvmfPkg_Windows_VS2019_PR (11 tests)

>

> (The Build_VS2019_TARGET_CODE_COVERAGE and

> Build_GCC5_TARGET_CODE_COVERAGE tests also failed, but those seem

> bogus to me.)

>

> All 12+11=23 PlatformCI_OvmfPkg_* checks failed due to timeout, and

> the firmware logs of the DEBUG and NOOPT builds end with:

>

> > INFO - PlatformMaxCpuCountInitialization: Broken CPU hotplug register 
> > block: Present=0 Possible=1.

> > INFO - PlatformMaxCpuCountInitialization: Switch QEMU's acceleration from 
> > TCG to KVM, or update QEMU.

> > INFO - PlatformMaxCpuCountInitialization: Refer to 
> > .

> > INFO - ASSERT

> > /home/vsts/work/1/s/OvmfPkg/Library/PlatformInitLib/Platform.c(574):

> > ((BOOLEAN)(0==1))

>

> So I'm not proposing to merge this immediately; something must be

> fixed

> first:

>

> - use KVM in the CI env, or

>

> - delay this patch until my QEMU fix is merged, and a new release is

>   made, and the new QEMU release is packaged by the distros, and the new

>   distro packages are picked up by github.com CI.

>

> Suggestions?

>

> Thanks,

> Laszlo

>

> Cc: Ard Biesheuvel 
> mailto:ardb+tianoc...@kernel.org>>

> Cc: Brijesh Singh mailto:brijesh.si...@amd.com>>

> Cc: Erdem Aktas mailto:erdemak...@google.com>>

> Cc: Gerd Hoffmann mailto:kra...@redhat.com>>

> Cc: James Bottomley mailto:j...@linux.ibm.com>>

> Cc: Jiewen Yao mailto:jiewen@intel.com>>

> Cc: Jordan Justen 
> mailto:jordan.l.jus...@intel.com>>

> Cc: Min Xu mailto:min.m...@intel.com>>

> Cc: Sebastien Boeuf 
> mailto:sebastien.bo...@intel.com>>

> Cc: Tom Lendacky mailto:thomas.lenda...@amd.com>>

>

> Laszlo Ersek (1):

>   OvmfPkg/PlatformInitLib: catch QEMU's CPU hotplug reg block

> regression

>

>  OvmfPkg/Library/PlatformInitLib/Platform.c | 34 

>  1 file changed, 34 insertions(+)

>

>

>

> 

>




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

[edk2-devel] Event: TianoCore Community Meeting - APAC/NAMO - Thursday, January 5, 2023 #cal-reminder

2023-01-04 Thread Group Notification

*Reminder: TianoCore Community Meeting - APAC/NAMO*

*When:*
Thursday, January 5, 2023
7:30pm to 8:30pm
(UTC-08:00) America/Los Angeles

*Where:*
https://teams.microsoft.com/l/meetup-join/19%3ameeting_Y2M1NDE3ODYtN2M3Yy00MDMxLTk3OWYtMTlkNjhlNWFlMjA2%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%226e4ce4c4-1242-431b-9a51-92cd01a5df3c%22%7d

*Organizer:* Miki Demeter

View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=1650221 )

*Description:*



Microsoft Teams meeting

*Join on your computer or mobile app*

Click here to join the meeting ( 
https://teams.microsoft.com/l/meetup-join/19%3ameeting_Y2M1NDE3ODYtN2M3Yy00MDMxLTk3OWYtMTlkNjhlNWFlMjA2%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%226e4ce4c4-1242-431b-9a51-92cd01a5df3c%22%7d
 )

Meeting ID: 283 318 374 436
Passcode: 633zLo

Download Teams ( https://www.microsoft.com/en-us/microsoft-teams/download-app ) 
| Join on the web ( https://www.microsoft.com/microsoft-teams/join-a-meeting )

*Join with a video conferencing device*

te...@conf.intel.com

Video Conference ID: 119 493 012 8

Alternate VTC instructions ( 
https://conf.intel.com/teams/?conf=1194930128=teams=conf.intel.com=test_call
 )

Learn More ( https://aka.ms/JoinTeamsMeeting ) | Meeting options ( 
https://teams.microsoft.com/meetingOptions/?organizerId=6e4ce4c4-1242-431b-9a51-92cd01a5df3c=46c98d88-e344-4ed4-8496-4ed7712e255d=19_meeting_Y2M1NDE3ODYtN2M3Yy00MDMxLTk3OWYtMTlkNjhlNWFlMjA2@thread.v2=0=en-US
 )




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

Re: [edk2-devel] [PATCH v1 0/2] Enable LoongArch64 in uefi-sct

2023-01-04 Thread Chao Li


Hi Maintainers,

Could you help review this patch set?

Thanks,
Chao

在 2022/12/14 16:36, Chao Li 写道:

LoongArch64 support was merged into edk2 and edk2-platforms, enable it
in edk2-test now.

BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=4192

Cc: G Edhaya Chandran
Cc: Barton Gao
Cc: Carolyn Gjertsen
Cc: Samer El-Haj-Mahmoud
Cc: Eric Jin
Cc: Supreeth Venkatesh
Signed-off-by: Chao Li

Chao Li (2):
   uefi-sct/SctPkg: Add LoongArch64 platform support
   uefi-sct/SctPkg: Enable LoongArch64 building

  .../Application/InstallSct/InstallSctDef.h|   4 +
  .../Library/SctLib/LoongArch64/SctLibPlat.h   |  32 ++
  .../Library/SctLib/LoongArch64/initplat.c |  45 +++
  uefi-sct/SctPkg/Library/SctLib/SctLib.inf |   6 +
  .../SCRT/SCRTApp/LoongArch64/GoVirtual.S  |  41 +++
  .../SCRT/SCRTApp/LoongArch64/VirtualMemory.c  | 177 
  uefi-sct/SctPkg/SCRT/SCRTApp/SCRTApp.inf  |   5 +
  .../SCRT/SCRTDriver/LoongArch64/Debug.c   |  81 ++
  .../SctPkg/SCRT/SCRTDriver/LoongArch64/Dump.c |  68 +
  .../SctPkg/SCRT/SCRTDriver/LoongArch64/Io.c   | 136 +
  .../SctPkg/SCRT/SCRTDriver/SCRTDriver.inf |   6 +
  .../BlackBoxTest/DebugSupportBBTest.inf   |   6 +
  .../DebugSupportBBTestCacheFunction.c | 136 +
  ...ugSupportBBTestExceptionCallbackFunction.c | 273 ++
  .../BlackBoxTest/LoongArch64/PlatformIsa.c|  29 ++
  .../Usb2Hc/BlackBoxTest/Usb2HcTest.inf|   4 +
  .../BlackBoxTest/LoongArch64/TimerInterrupt.c |  38 +++
  .../Protocol/UsbHc/BlackBoxTest/UsbHcTest.inf |   4 +
  .../SCT/Framework/ENTS/EasLib/EntsLib.inf |   5 +
  .../ENTS/EasLib/LoongArch64/EntsLibPlat.h |  56 
  .../ENTS/EasLib/LoongArch64/InitPlat.c|  55 
  .../SctPkg/Tools/Source/GenBin/GNUmakefile|   4 +
  uefi-sct/SctPkg/UEFI/IHV_SCT.dsc  |  12 +-
  uefi-sct/SctPkg/UEFI/Protocol/DebugSupport.h  | 101 ++-
  uefi-sct/SctPkg/UEFI/UEFI_SCT.dsc |  15 +-
  uefi-sct/SctPkg/build.sh  |  10 +-
  26 files changed, 1343 insertions(+), 6 deletions(-)
  create mode 100644 uefi-sct/SctPkg/Library/SctLib/LoongArch64/SctLibPlat.h
  create mode 100644 uefi-sct/SctPkg/Library/SctLib/LoongArch64/initplat.c
  create mode 100644 uefi-sct/SctPkg/SCRT/SCRTApp/LoongArch64/GoVirtual.S
  create mode 100644 uefi-sct/SctPkg/SCRT/SCRTApp/LoongArch64/VirtualMemory.c
  create mode 100644 uefi-sct/SctPkg/SCRT/SCRTDriver/LoongArch64/Debug.c
  create mode 100644 uefi-sct/SctPkg/SCRT/SCRTDriver/LoongArch64/Dump.c
  create mode 100644 uefi-sct/SctPkg/SCRT/SCRTDriver/LoongArch64/Io.c
  create mode 100644 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/DebugSupport/BlackBoxTest/LoongArch64/DebugSupportBBTestCacheFunction.c
  create mode 100644 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/DebugSupport/BlackBoxTest/LoongArch64/DebugSupportBBTestExceptionCallbackFunction.c
  create mode 100644 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/DebugSupport/BlackBoxTest/LoongArch64/PlatformIsa.c
  create mode 100644 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/UsbHc/BlackBoxTest/LoongArch64/TimerInterrupt.c
  create mode 100644 
uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/LoongArch64/EntsLibPlat.h
  create mode 100644 
uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/LoongArch64/InitPlat.c




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

[edk2-devel] [PATCH] CryptoPkg/Library: add -Wno-unused-but-set-variable for openssl

2023-01-04 Thread Chen, Gang C

The GCC warning fix is not in 1.1.1x. Ignore the warning type
-Wno-unused-but-set-variable with GCC compiler in the build option.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Signed-off-by: Gang Chen 
---
 CryptoPkg/Library/OpensslLib/OpensslLib.inf  | 2 ++
 CryptoPkg/Library/OpensslLib/OpensslLibAccel.inf | 2 ++
 CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf| 2 ++
 CryptoPkg/Library/OpensslLib/OpensslLibFull.inf  | 2 ++
 CryptoPkg/Library/OpensslLib/OpensslLibFullAccel.inf | 2 ++
 5 files changed, 10 insertions(+)

diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf 
b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
index 60c6c24b0a..8daab2fe55 100644
--- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
+++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
@@ -641,6 +641,8 @@
   GCC:*_CLANG35_*_CC_FLAGS = -std=c99 -Wno-error=uninitialized
   GCC:*_CLANG38_*_CC_FLAGS = -std=c99 -Wno-error=uninitialized
   GCC:*_CLANGPDB_*_CC_FLAGS = -std=c99 -Wno-error=uninitialized 
-Wno-error=incompatible-pointer-types -Wno-error=pointer-sign 
-Wno-error=implicit-function-declaration -Wno-error=ignored-pragma-optimize
+  # Revisit after switching to 3.0 branch
+  GCC:*_GCC5_*_CC_FLAGS= -Wno-unused-but-set-variable
 
   # suppress the following warnings in openssl so we don't break the build 
with warnings-as-errors:
   # 1295: Deprecated declaration  - give arg types
diff --git a/CryptoPkg/Library/OpensslLib/OpensslLibAccel.inf 
b/CryptoPkg/Library/OpensslLib/OpensslLibAccel.inf
index 103ef7bda2..b7e553df17 100644
--- a/CryptoPkg/Library/OpensslLib/OpensslLibAccel.inf
+++ b/CryptoPkg/Library/OpensslLib/OpensslLibAccel.inf
@@ -689,6 +689,8 @@
   GCC:*_CLANG35_*_CC_FLAGS = -std=c99 -Wno-error=uninitialized
   GCC:*_CLANG38_*_CC_FLAGS = -std=c99 -Wno-error=uninitialized
   GCC:*_CLANGPDB_*_CC_FLAGS = -std=c99 -Wno-error=uninitialized 
-Wno-error=incompatible-pointer-types -Wno-error=pointer-sign 
-Wno-error=implicit-function-declaration -Wno-error=ignored-pragma-optimize
+  # Revisit after switching to 3.0 branch
+  GCC:*_GCC5_*_CC_FLAGS= -Wno-unused-but-set-variable
 
   # suppress the following warnings in openssl so we don't break the build 
with warnings-as-errors:
   # 1295: Deprecated declaration  - give arg types
diff --git a/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf 
b/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
index c4eaea888c..2472c1f663 100644
--- a/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
+++ b/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
@@ -591,6 +591,8 @@
   GCC:*_CLANG35_*_CC_FLAGS = -std=c99 -Wno-error=uninitialized
   GCC:*_CLANG38_*_CC_FLAGS = -std=c99 -Wno-error=uninitialized
   GCC:*_CLANGPDB_*_CC_FLAGS = -std=c99 -Wno-error=uninitialized 
-Wno-error=incompatible-pointer-types -Wno-error=pointer-sign 
-Wno-error=implicit-function-declaration -Wno-error=ignored-pragma-optimize
+  # Revisit after switching to 3.0 branch
+  GCC:*_GCC5_*_CC_FLAGS= -Wno-unused-but-set-variable
 
   # suppress the following warnings in openssl so we don't break the build 
with warnings-as-errors:
   # 1295: Deprecated declaration  - give arg types
diff --git a/CryptoPkg/Library/OpensslLib/OpensslLibFull.inf 
b/CryptoPkg/Library/OpensslLib/OpensslLibFull.inf
index 309e43055c..94c53a07c0 100644
--- a/CryptoPkg/Library/OpensslLib/OpensslLibFull.inf
+++ b/CryptoPkg/Library/OpensslLib/OpensslLibFull.inf
@@ -696,6 +696,8 @@
   GCC:*_CLANG35_*_CC_FLAGS = -std=c99 -Wno-error=uninitialized
   GCC:*_CLANG38_*_CC_FLAGS = -std=c99 -Wno-error=uninitialized
   GCC:*_CLANGPDB_*_CC_FLAGS = -std=c99 -Wno-error=uninitialized 
-Wno-error=incompatible-pointer-types -Wno-error=pointer-sign 
-Wno-error=implicit-function-declaration -Wno-error=ignored-pragma-optimize
+  # Revisit after switching to 3.0 branch
+  GCC:*_GCC5_*_CC_FLAGS= -Wno-unused-but-set-variable
 
   # suppress the following warnings in openssl so we don't break the build 
with warnings-as-errors:
   # 1295: Deprecated declaration  - give arg types
diff --git a/CryptoPkg/Library/OpensslLib/OpensslLibFullAccel.inf 
b/CryptoPkg/Library/OpensslLib/OpensslLibFullAccel.inf
index 4b79bd..78e6f0e112 100644
--- a/CryptoPkg/Library/OpensslLib/OpensslLibFullAccel.inf
+++ b/CryptoPkg/Library/OpensslLib/OpensslLibFullAccel.inf
@@ -744,6 +744,8 @@
   GCC:*_CLANG35_*_CC_FLAGS = -std=c99 -Wno-error=uninitialized
   GCC:*_CLANG38_*_CC_FLAGS = -std=c99 -Wno-error=uninitialized
   GCC:*_CLANGPDB_*_CC_FLAGS = -std=c99 -Wno-error=uninitialized 
-Wno-error=incompatible-pointer-types -Wno-error=pointer-sign 
-Wno-error=implicit-function-declaration -Wno-error=ignored-pragma-optimize
+  # Revisit after switching to 3.0 branch
+  GCC:*_GCC5_*_CC_FLAGS= -Wno-unused-but-set-variable
 
   # suppress the following warnings in openssl so we don't break the build 
with warnings-as-errors:
   # 1295: Deprecated declaration  - give arg types
-- 
2.38.1



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

Re: [edk2-devel][edk2-platforms][PATCH V1 1/1] WhitleyOpenBoardPkg/AcpiTables: Fix EFI_ACPI_GPE0_BLK_LEN calculation

2023-01-04 Thread Chiu, Chasel



Reviewed-by: Chasel Chiu 


> -Original Message-
> From: Oram, Isaac W 
> Sent: Wednesday, January 4, 2023 5:34 PM
> To: devel@edk2.groups.io
> Cc: Oram, Isaac W ; Desimone, Nathaniel L
> ; Chiu, Chasel ;
> Sinha, Ankit ; Ponnusamy, Suresh
> 
> Subject: [edk2-devel][edk2-platforms][PATCH V1 1/1]
> WhitleyOpenBoardPkg/AcpiTables: Fix EFI_ACPI_GPE0_BLK_LEN calculation
> 
> Block length incorrectly calculated off of the block width.
> Reverted EFI_ACPI_GPE0_BLK_WIDTH change and added #defines for
> X_GPE0 and X_GPE1 contents.
> 
> Cc: Nate DeSimone 
> Cc: Chasel Chiu 
> Cc: Ankit Sinha 
> Cc: Suresh Ponnusamy 
> Signed-off-by: Isaac Oram 
> ---
>  .../Features/Acpi/AcpiTables/Fadt/Fadt62.aslc | 16 +++---
>  .../WhitleyOpenBoardPkg/Include/Acpi/Fadt.h   | 21
> ++-
>  2 files changed, 28 insertions(+), 9 deletions(-)
> 
> diff --git
> a/Platform/Intel/WhitleyOpenBoardPkg/Features/Acpi/AcpiTables/Fadt/Fa
> dt62.aslc
> b/Platform/Intel/WhitleyOpenBoardPkg/Features/Acpi/AcpiTables/Fadt/Fa
> dt62.aslc
> index f37cf0a508..b7f15ef716 100644
> ---
> a/Platform/Intel/WhitleyOpenBoardPkg/Features/Acpi/AcpiTables/Fadt/Fa
> dt62.aslc
> +++
> b/Platform/Intel/WhitleyOpenBoardPkg/Features/Acpi/AcpiTables/Fadt/F
> +++ adt62.aslc
> @@ -143,19 +143,19 @@ EFI_ACPI_6_2_FIXED_ACPI_DESCRIPTION_TABLE
> Fadt = {
>//
>// X_General Purpose Event 0 Register Block
>//
> -  {EFI_ACPI_GPE0_BLK_ADDRESS_SPACE_ID,
> -  EFI_ACPI_GPE0_BLK_BIT_WIDTH,
> -  EFI_ACPI_GPE0_BLK_BIT_OFFSET,
> +  {EFI_ACPI_X_GPE0_BLK_ADDRESS_SPACE_ID,
> +  EFI_ACPI_X_GPE0_BLK_BIT_WIDTH,
> +  EFI_ACPI_X_GPE0_BLK_BIT_OFFSET,
>EFI_ACPI_6_2_BYTE,
> -  EFI_ACPI_GPE0_BLK_ADDRESS},
> +  EFI_ACPI_X_GPE0_BLK_ADDRESS},
>//
>// X_General Purpose Event 1 Register Block
>//
> -  {EFI_ACPI_GPE1_BLK_ADDRESS_SPACE_ID,
> -  EFI_ACPI_GPE1_BLK_BIT_WIDTH,
> -  EFI_ACPI_GPE1_BLK_BIT_OFFSET,
> +  {EFI_ACPI_X_GPE1_BLK_ADDRESS_SPACE_ID,
> +  EFI_ACPI_X_GPE1_BLK_BIT_WIDTH,
> +  EFI_ACPI_X_GPE1_BLK_BIT_OFFSET,
>EFI_ACPI_6_2_UNDEFINED,
> -  EFI_ACPI_GPE1_BLK_ADDRESS}
> +  EFI_ACPI_X_GPE1_BLK_ADDRESS}
>  };
> 
>  VOID*
> diff --git a/Platform/Intel/WhitleyOpenBoardPkg/Include/Acpi/Fadt.h
> b/Platform/Intel/WhitleyOpenBoardPkg/Include/Acpi/Fadt.h
> index ebfd21b6cc..8857879370 100644
> --- a/Platform/Intel/WhitleyOpenBoardPkg/Include/Acpi/Fadt.h
> +++ b/Platform/Intel/WhitleyOpenBoardPkg/Include/Acpi/Fadt.h
> @@ -152,10 +152,19 @@ For Watson Creek we set this to 0 and then
> dynamically update this to 1 in the D  // Information  //  #define
> EFI_ACPI_GPE0_BLK_ADDRESS_SPACE_ID  EFI_ACPI_6_2_SYSTEM_IO
> -#define EFI_ACPI_GPE0_BLK_BIT_WIDTH 0 // size of
> R_PCH_ACPI_GPE0_STS_127_96 + R_PCH_ACPI_GPE0_EN_127_96
> +#define EFI_ACPI_GPE0_BLK_BIT_WIDTH 0x100 // size of
> R_PCH_ACPI_GPE0_STS_127_96 + R_PCH_ACPI_GPE0_EN_127_96
>  #define EFI_ACPI_GPE0_BLK_BIT_OFFSET0x00
>  #define EFI_ACPI_GPE0_BLK_ADDRESS
> (EFI_ACPI_PM1A_EVT_BLK_ADDRESS + 0x80)
> 
> +//
> +// X General Purpose Event 0 Register Block Generic Address //
> +Information // #define EFI_ACPI_X_GPE0_BLK_ADDRESS_SPACE_ID
> +EFI_ACPI_6_2_SYSTEM_IO
> +#define EFI_ACPI_X_GPE0_BLK_BIT_WIDTH 0x00
> +#define EFI_ACPI_X_GPE0_BLK_BIT_OFFSET0x00
> +#define EFI_ACPI_X_GPE0_BLK_ADDRESS
> EFI_ACPI_GPE0_BLK_ADDRESS
> +
>  //
>  // General Purpose Event 1 Register Block Generic Address  // Information
> @@ -164,6 +173,16 @@ For Watson Creek we set this to 0 and then
> dynamically update this to 1 in the D
>  #define EFI_ACPI_GPE1_BLK_BIT_WIDTH 0x0
>  #define EFI_ACPI_GPE1_BLK_BIT_OFFSET0x0
>  #define EFI_ACPI_GPE1_BLK_ADDRESS   0x0
> +
> +//
> +// X General Purpose Event 1 Register Block Generic Address //
> +Information // #define EFI_ACPI_X_GPE1_BLK_ADDRESS_SPACE_ID
> +EFI_ACPI_6_2_SYSTEM_IO
> +#define EFI_ACPI_X_GPE1_BLK_BIT_WIDTH 0x00
> +#define EFI_ACPI_X_GPE1_BLK_BIT_OFFSET0x00
> +#define EFI_ACPI_X_GPE1_BLK_ADDRESS   0x00
> +
>  //
>  // Reset Register Generic Address Information  //
> --
> 2.39.0.windows.1



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

Re: [edk2-devel] [PATCH 1/1] Platform/RISC-V/PlatformPkg:fix image link error

2023-01-04 Thread Dongdong Zhang

Hi, all
Sorry, forgot to add Maintainer and Reviewer.
Add Sunil V L 
Add Daniel Schaefer 

> -原始邮件-发件人:"Dongdong Zhang" 
> 发送时间:2022-12-28 13:45:50 
> (星期三)收件人:devel@edk2.groups.io抄送:zhuwen...@eswincomputing.com, 
> zhen...@eswincomputing.com, jinyanji...@eswincomputing.com, "Dongdong Zhang" 
> 主题:[PATCH 1/1] 
> Platform/RISC-V/PlatformPkg:fix image link error
> 
> Edk2OpensbiPlatformWrapperLib Library and RiscVSpecialPlatformLib
> Library mark the serial number in the figure is opposite to
> the text description, fix it and adjust the text order.
> 
> Signed-off-by: Dongdong Zhang 
> ---
>  Platform/RISC-V/PlatformPkg/Readme.md | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/Platform/RISC-V/PlatformPkg/Readme.md 
> b/Platform/RISC-V/PlatformPkg/Readme.md
> index 5a344a8..d7166ba 100644
> --- a/Platform/RISC-V/PlatformPkg/Readme.md
> +++ b/Platform/RISC-V/PlatformPkg/Readme.md
> @@ -35,19 +35,21 @@ are from OpenSBI project. edk2 libraries are introduced 
> as the wrapper libraries
>  [Indicated as #2 in the figure](#risc-v-edk2-port-design-diagrams)
>  > ***OpenSbiPlatformLib*** provides the generic RISC-V platform 
> initialization code. Platform vendor can just utilize this library if they 
> don't have additional requirements on the platform initialization.
>  
> -# RiscVSpecialPlatformLib Library
> -[Indicated as #3 in the figure](#risc-v-edk2-port-design-diagrams)
> -> The major use case of this library is to facilitate the interfaces for 
> platform vendors to provide the special
> -platform initialization based on the generic platform initialization library.
> -
>  # Edk2OpensbiPlatformWrapperLib Library
> -[Indicated as #4 in the figure](#risc-v-edk2-port-design-diagrams)
> +
> +[Indicated as #3 in the figure](#risc-v-edk2-port-design-diagrams)
>  > In order to providing the flexibility to edk2 RISC-V firmware solution, 
> ***Edk2OpensbiPlatformWrapperLib*** is the wrapper library of 
> [OpenSbiPlatformLib](#OpenSbiPlatformLib-library) to provide the interfaces 
> for OEM. The ***platform_ops_address***in the generic platform structure is 
> replaced with ***Edk2OpensbiplatformOps*** in SEC
>  module. The platform function invoked by OpenSBI core is hooked to 
> ***Edk2OpensbiPlatformWrapperLib***. This gives
>  a change to OEM for implementing platform-specific initialization before and 
> after the generic platform code. OEM
>  can override this library under their platform folder on demand without 
> touching ***RiscVOpensbiLib*** library
>  source files and other common source files.
>  
> +# RiscVSpecialPlatformLib Library
> +
> +[Indicated as #4 in the figure](#risc-v-edk2-port-design-diagrams)
> +> The major use case of this library is to facilitate the interfaces for 
> platform vendors to provide the special
> +platform initialization based on the generic platform initialization library.
> +
>  # Next Phase Address and Privilege Mode
>  [Indicated as #5 in the figure](#risc-v-edk2-port-design-diagrams)
>  > Once OpenSBI finishes the boot initialization, it will jump to the next 
> phase with the default privilege set to
> -- 
> 2.17.1


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

Re: [edk2-devel] [PATCH] Platform/Intel/WhitleyOpenBoardPkg:Add CpuPageTableLib.

2023-01-04 Thread Isaac Oram

I am assuming that we can drop this because you added to DxeCoreLibs.dsc which 
WhitleyOpenBoardPkg consumes.

Thanks,

Isaac


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

Re: [edk2-devel] edk2-platforms, continuous integration, testing, and you

2023-01-04 Thread Sean


Pedro,

Thanks.  Happy to get some feedback.  I hope others also provide 
feedback.  :)



Regarding the Edk2 tools & CI meeting:  If we scheduled the Jan 16th 
meeting for Jan 17th at 8am Pacific (should be 5 pm your time) would 
that work?  In the meeting we have discussed that we need to rotate the 
time of the meetings to accommodate more world wide attendance and given 
the standard time would fall on a US holiday it seems like a good week 
to do it.  Could you make it that day?


At a minimum we could talk about your packages:

Like should ext4 really depend on redfishpkg?  More likely the library 
should be promoted to a more "core" package.


Could your qemu open board pkg be built using stuart and setup to run 
tests?  More details about the goals and plans for the qemu open board pkg.



Thanks

Sean




On 1/4/2023 3:57 PM, Pedro Falcato wrote:

Sean,

Thank you for making edk2 better :)

I have replied to your github discussion with a bunch of my ideas, as 
both a feature package maintainer and platform maintainer.

(https://github.com/tianocore/edk2/discussions/3721#discussioncomment-4596465)

I'm willing to discuss these things further as long as it's not at 
*checks edk2 tools & CI meeting time* 1am (email, chat, 1-on-1, you 
name it).
I am also interested in getting QemuOpenBoardPkg into your platform CI 
initiative as it's a simple platform that only requires QEMU to boot 
(plus a copy of edk2-platforms and edk2 to build).


--
Pedro



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

[edk2-devel][edk2-platforms][PATCH V1 1/1] WhitleyOpenBoardPkg/AcpiTables: Fix EFI_ACPI_GPE0_BLK_LEN calculation

2023-01-04 Thread Isaac Oram

Block length incorrectly calculated off of the block width.
Reverted EFI_ACPI_GPE0_BLK_WIDTH change and added #defines
for X_GPE0 and X_GPE1 contents.

Cc: Nate DeSimone 
Cc: Chasel Chiu 
Cc: Ankit Sinha 
Cc: Suresh Ponnusamy 
Signed-off-by: Isaac Oram 
---
 .../Features/Acpi/AcpiTables/Fadt/Fadt62.aslc | 16 +++---
 .../WhitleyOpenBoardPkg/Include/Acpi/Fadt.h   | 21 ++-
 2 files changed, 28 insertions(+), 9 deletions(-)

diff --git 
a/Platform/Intel/WhitleyOpenBoardPkg/Features/Acpi/AcpiTables/Fadt/Fadt62.aslc 
b/Platform/Intel/WhitleyOpenBoardPkg/Features/Acpi/AcpiTables/Fadt/Fadt62.aslc
index f37cf0a508..b7f15ef716 100644
--- 
a/Platform/Intel/WhitleyOpenBoardPkg/Features/Acpi/AcpiTables/Fadt/Fadt62.aslc
+++ 
b/Platform/Intel/WhitleyOpenBoardPkg/Features/Acpi/AcpiTables/Fadt/Fadt62.aslc
@@ -143,19 +143,19 @@ EFI_ACPI_6_2_FIXED_ACPI_DESCRIPTION_TABLE Fadt = {
   //
   // X_General Purpose Event 0 Register Block
   //
-  {EFI_ACPI_GPE0_BLK_ADDRESS_SPACE_ID,
-  EFI_ACPI_GPE0_BLK_BIT_WIDTH,
-  EFI_ACPI_GPE0_BLK_BIT_OFFSET,
+  {EFI_ACPI_X_GPE0_BLK_ADDRESS_SPACE_ID,
+  EFI_ACPI_X_GPE0_BLK_BIT_WIDTH,
+  EFI_ACPI_X_GPE0_BLK_BIT_OFFSET,
   EFI_ACPI_6_2_BYTE,
-  EFI_ACPI_GPE0_BLK_ADDRESS},
+  EFI_ACPI_X_GPE0_BLK_ADDRESS},
   //
   // X_General Purpose Event 1 Register Block
   //
-  {EFI_ACPI_GPE1_BLK_ADDRESS_SPACE_ID,
-  EFI_ACPI_GPE1_BLK_BIT_WIDTH,
-  EFI_ACPI_GPE1_BLK_BIT_OFFSET,
+  {EFI_ACPI_X_GPE1_BLK_ADDRESS_SPACE_ID,
+  EFI_ACPI_X_GPE1_BLK_BIT_WIDTH,
+  EFI_ACPI_X_GPE1_BLK_BIT_OFFSET,
   EFI_ACPI_6_2_UNDEFINED,
-  EFI_ACPI_GPE1_BLK_ADDRESS}
+  EFI_ACPI_X_GPE1_BLK_ADDRESS}
 };
 
 VOID*
diff --git a/Platform/Intel/WhitleyOpenBoardPkg/Include/Acpi/Fadt.h 
b/Platform/Intel/WhitleyOpenBoardPkg/Include/Acpi/Fadt.h
index ebfd21b6cc..8857879370 100644
--- a/Platform/Intel/WhitleyOpenBoardPkg/Include/Acpi/Fadt.h
+++ b/Platform/Intel/WhitleyOpenBoardPkg/Include/Acpi/Fadt.h
@@ -152,10 +152,19 @@ For Watson Creek we set this to 0 and then dynamically 
update this to 1 in the D
 // Information
 //
 #define EFI_ACPI_GPE0_BLK_ADDRESS_SPACE_ID  EFI_ACPI_6_2_SYSTEM_IO
-#define EFI_ACPI_GPE0_BLK_BIT_WIDTH 0 // size of 
R_PCH_ACPI_GPE0_STS_127_96 + R_PCH_ACPI_GPE0_EN_127_96
+#define EFI_ACPI_GPE0_BLK_BIT_WIDTH 0x100 // size of 
R_PCH_ACPI_GPE0_STS_127_96 + R_PCH_ACPI_GPE0_EN_127_96
 #define EFI_ACPI_GPE0_BLK_BIT_OFFSET0x00
 #define EFI_ACPI_GPE0_BLK_ADDRESS   (EFI_ACPI_PM1A_EVT_BLK_ADDRESS + 
0x80)
 
+//
+// X General Purpose Event 0 Register Block Generic Address
+// Information
+//
+#define EFI_ACPI_X_GPE0_BLK_ADDRESS_SPACE_ID  EFI_ACPI_6_2_SYSTEM_IO
+#define EFI_ACPI_X_GPE0_BLK_BIT_WIDTH 0x00
+#define EFI_ACPI_X_GPE0_BLK_BIT_OFFSET0x00
+#define EFI_ACPI_X_GPE0_BLK_ADDRESS   EFI_ACPI_GPE0_BLK_ADDRESS
+
 //
 // General Purpose Event 1 Register Block Generic Address
 // Information
@@ -164,6 +173,16 @@ For Watson Creek we set this to 0 and then dynamically 
update this to 1 in the D
 #define EFI_ACPI_GPE1_BLK_BIT_WIDTH 0x0
 #define EFI_ACPI_GPE1_BLK_BIT_OFFSET0x0
 #define EFI_ACPI_GPE1_BLK_ADDRESS   0x0
+
+//
+// X General Purpose Event 1 Register Block Generic Address
+// Information
+//
+#define EFI_ACPI_X_GPE1_BLK_ADDRESS_SPACE_ID  EFI_ACPI_6_2_SYSTEM_IO
+#define EFI_ACPI_X_GPE1_BLK_BIT_WIDTH 0x00
+#define EFI_ACPI_X_GPE1_BLK_BIT_OFFSET0x00
+#define EFI_ACPI_X_GPE1_BLK_ADDRESS   0x00
+
 //
 // Reset Register Generic Address Information
 //
-- 
2.39.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#97960): https://edk2.groups.io/g/devel/message/97960
Mute This Topic: https://groups.io/mt/96064620/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] FIX MinPlatformPkg PCIE Base typecasting error.

2023-01-04 Thread Isaac Oram

Pushed as eb3950b842..6198c1c497

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Isaac Oram
Sent: Wednesday, January 4, 2023 4:30 PM
To: S, Ashraf Ali ; devel@edk2.groups.io
Cc: Ni, Ray ; Chaganty, Rangasai V 
; Chiu, Chasel ; 
Desimone, Nathaniel L ; Gao, Liming 
; Dong, Eric 
Subject: Re: [edk2-devel] [PATCH v2] FIX MinPlatformPkg PCIE Base typecasting 
error.

Reviewed-by: Isaac Oram 

Note I had to fix your author format from S, Ashraf Ali to match 
convention/use.  I believe that you can fix this in your groups.io settings 
since your signoff is correct implies git is correct.

-Original Message-
From: S, Ashraf Ali  
Sent: Sunday, December 25, 2022 10:06 PM
To: devel@edk2.groups.io
Cc: S, Ashraf Ali ; Ni, Ray ; 
Chaganty, Rangasai V ; Oram, Isaac W 
; Chiu, Chasel ; Desimone, 
Nathaniel L ; Gao, Liming 
; Dong, Eric 
Subject: [PATCH v2] FIX MinPlatformPkg PCIE Base typecasting error.

PCIE Base Address is 64bit PCD and the Mem Limit UINT64.
so typecasting to 32bit is not needed.

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

Signed-off-by: Ashraf Ali S 
Cc: Ray Ni 
Cc: Rangasai V Chaganty 
Cc: Isaac Oram 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Isaac Oram 
Cc: Liming Gao 
Cc: Eric Dong 
---
 .../Pci/Library/PciHostBridgeLibSimple/PciHostBridgeLibSimple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHostBridgeLibSimple.c
 
b/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHostBridgeLibSimple.c
index 0e3fee28b5..e38975eee5 100644
--- 
a/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHostBridgeLibSimple.c
+++ 
b/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHostBridgeLibSimple.c
@@ -90,7 +90,7 @@ PciHostBridgeGetRootBridges (
   if (PcdGet32(PcdPciReservedMemLimit) != 0) {
 mRootBridgeTemplate.Mem.Limit = PcdGet32 (PcdPciReservedMemLimit);
   } else {
-mRootBridgeTemplate.Mem.Limit = (UINT32) PcdGet64 
(PcdPciExpressBaseAddress) - 1;
+mRootBridgeTemplate.Mem.Limit = PcdGet64 (PcdPciExpressBaseAddress) - 1;
   }
 
   mRootBridgeTemplate.MemAbove4G.Base = PcdGet64 
(PcdPciReservedMemAbove4GBBase);
-- 
2.33.0.windows.1








-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#97959): https://edk2.groups.io/g/devel/message/97959
Mute This Topic: https://groups.io/mt/95884079/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] FIX MinPlatformPkg PCIE Base typecasting error.

2023-01-04 Thread Isaac Oram

Reviewed-by: Isaac Oram 

Note I had to fix your author format from S, Ashraf Ali to match 
convention/use.  I believe that you can fix this in your groups.io settings 
since your signoff is correct implies git is correct.

-Original Message-
From: S, Ashraf Ali  
Sent: Sunday, December 25, 2022 10:06 PM
To: devel@edk2.groups.io
Cc: S, Ashraf Ali ; Ni, Ray ; 
Chaganty, Rangasai V ; Oram, Isaac W 
; Chiu, Chasel ; Desimone, 
Nathaniel L ; Gao, Liming 
; Dong, Eric 
Subject: [PATCH v2] FIX MinPlatformPkg PCIE Base typecasting error.

PCIE Base Address is 64bit PCD and the Mem Limit UINT64.
so typecasting to 32bit is not needed.

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

Signed-off-by: Ashraf Ali S 
Cc: Ray Ni 
Cc: Rangasai V Chaganty 
Cc: Isaac Oram 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Isaac Oram 
Cc: Liming Gao 
Cc: Eric Dong 
---
 .../Pci/Library/PciHostBridgeLibSimple/PciHostBridgeLibSimple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHostBridgeLibSimple.c
 
b/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHostBridgeLibSimple.c
index 0e3fee28b5..e38975eee5 100644
--- 
a/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHostBridgeLibSimple.c
+++ 
b/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHostBridgeLibSimple.c
@@ -90,7 +90,7 @@ PciHostBridgeGetRootBridges (
   if (PcdGet32(PcdPciReservedMemLimit) != 0) {
 mRootBridgeTemplate.Mem.Limit = PcdGet32 (PcdPciReservedMemLimit);
   } else {
-mRootBridgeTemplate.Mem.Limit = (UINT32) PcdGet64 
(PcdPciExpressBaseAddress) - 1;
+mRootBridgeTemplate.Mem.Limit = PcdGet64 (PcdPciExpressBaseAddress) - 1;
   }
 
   mRootBridgeTemplate.MemAbove4G.Base = PcdGet64 
(PcdPciReservedMemAbove4GBBase);
-- 
2.33.0.windows.1



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

Re: [edk2-devel] [edk2-platforms][PATCH 3/3] IpmiFeaturePkg: Add reference of IpmiBaseLib

2023-01-04 Thread Isaac Oram

Reviewed-by: Isaac Oram 

-Original Message-
From: abner.ch...@amd.com  
Sent: Friday, December 23, 2022 5:27 AM
To: devel@edk2.groups.io
Cc: Oram, Isaac W ; Desimone, Nathaniel L 
; Gao, Liming ; 
Nickle Wang ; Igor Kulchytskyy 
Subject: [edk2-platforms][PATCH 3/3] IpmiFeaturePkg: Add reference of 
IpmiBaseLib

From: Abner Chang 

Add reference of IpmiBaseLib

Signed-off-by: Abner Chang 
Cc: Isaac Oram 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Nickle Wang 
Cc: Igor Kulchytskyy 
---
 .../OutOfBandManagement/IpmiFeaturePkg/IpmiFeaturePkg.dec| 5 +
 1 file changed, 5 insertions(+)

diff --git 
a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/IpmiFeaturePkg.dec 
b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/IpmiFeaturePkg.dec
index 48f4ebf931..4344ad31be 100644
--- a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/IpmiFeaturePkg.dec
+++ b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/IpmiFeaturePkg.d
+++ ec
@@ -8,6 +8,7 @@
 # for the build infrastructure.
 #
 # Copyright (c) 2019-2021, Intel Corporation. All rights reserved.
+# Copyright (C) 2022 Advanced Micro Devices, Inc. All rights 
+reserved.
 #
 # SPDX-License-Identifier: BSD-2-Clause-Patent  # @@ -38,6 +39,10 @@
   #
   IpmiCommandLib|Include/Library/IpmiPlatformHookLib.h
 
+  ## @libraryclass  Provides an API for the base IPMI library  #  
+ IpmiBaseLib|Include/Library/IpmiBaseLib.h
+
 [Guids]
   gIpmiFeaturePkgTokenSpaceGuid  =  {0xc05283f6, 0xd6a8, 0x48f3, {0x9b, 0x59, 
0xfb, 0xca, 0x71, 0x32, 0x0f, 0x12}}
 
--
2.37.1.windows.1



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

Re: [edk2-devel] [edk2-platforms][PATCH 2/3] IpmiFeaturePkg/IpmiCommandLib: Add IPMI functions

2023-01-04 Thread Isaac Oram

Reviewed-by: Isaac Oram 

If you are making changes, I would note/request improvement for:

IpmiGetSystemUuid ();
Please align local variable columns as is convention in this file.

IpmiGetChannelInfo ();
Should we check that input pointers are not null?  Other functions don't, so I 
wouldn't block commit for this, but if you are fixing other things, it seems 
beneficial to add some error checking.

Regards,
Isaac

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Chang, Abner via 
groups.io
Sent: Friday, December 23, 2022 5:27 AM
To: devel@edk2.groups.io
Cc: Oram, Isaac W ; Desimone, Nathaniel L 
; Gao, Liming ; 
Nickle Wang ; Igor Kulchytskyy 
Subject: [edk2-devel] [edk2-platforms][PATCH 2/3] 
IpmiFeaturePkg/IpmiCommandLib: Add IPMI functions

From: Abner Chang 

Add functions to get system UUID and LAN configuration parameter.

Signed-off-by: Abner Chang 
Cc: Isaac Oram 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Nickle Wang 
Cc: Igor Kulchytskyy 
---
 .../IpmiCommandLib/IpmiCommandLibNetFnApp.c   | 81 +++
 .../IpmiCommandLibNetFnTransport.c| 36 +
 2 files changed, 117 insertions(+)

diff --git 
a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Library/IpmiCommandLib/IpmiCommandLibNetFnApp.c
 
b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Library/IpmiCommandLib/IpmiCommandLibNetFnApp.c
index addabc554e..e89ba27d15 100644
--- 
a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Library/IpmiCommandLib/IpmiCommandLibNetFnApp.c
+++ b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Library/IpmiComm
+++ andLib/IpmiCommandLibNetFnApp.c
@@ -2,6 +2,8 @@
   IPMI Command - NetFnApp.
 
   Copyright (c) 2018 - 2021, Intel Corporation. All rights reserved.
+  Copyright (C) 2022 Advanced Micro Devices, Inc. All rights 
+ reserved.
+
   SPDX-License-Identifier: BSD-2-Clause-Patent  **/
 
@@ -245,3 +247,82 @@ IpmiSendMessage (
  );
   return Status;
 }
+
+/**
+  This function gets the system UUID.
+
+  @param[out] SystemGuid   The pointer to retrieve system UUID.
+
+  @retval EFI_SUCCESS   UUID is returned.
+  @retval EFI_INVALID_PARAMETER SystemGuid is a NULL pointer.
+  @retval OthersOther errors.
+
+**/
+EFI_STATUS
+EFIAPI
+IpmiGetSystemUuid (
+  OUT EFI_GUID *SystemGuid
+  )
+{
+  EFI_STATUS  Status;
+  IPMI_GET_SYSTEM_UUID_RESPONSE GetSystemUuidResponse;
+  UINT32 RequestSize;
+  UINT32 ResponseSize;
+
+  if (SystemGuid == NULL) {
+return EFI_INVALID_PARAMETER;
+  }
+  RequestSize = 0;
+  ResponseSize = sizeof (IPMI_GET_SYSTEM_UUID_RESPONSE);
+  Status = IpmiSubmitCommand (
+ IPMI_NETFN_APP,
+ IPMI_APP_GET_SYSTEM_GUID,
+ (VOID *)NULL,
+ RequestSize,
+ (VOID *),
+ 
+ );
+  if (!EFI_ERROR (Status) && GetSystemUuidResponse.CompletionCode == 
IPMI_COMP_CODE_NORMAL) {
+CopyMem (
+  (VOID *)SystemGuid,
+  (VOID *),
+  sizeof (EFI_GUID)
+  );
+  }
+  return Status;
+}
+
+/**
+  This function gets the channel information.
+
+  @param[in] GetChannelInfoRequest   The get channel information 
request.
+  @param[in] GetChannelInfoResponse  The get channel information 
response.
+  @param[in,out] GetChannelInfoResponseSize  When input, the expected size of 
response.
+ When output, the exact size of 
the returned
+  response.
+
+  @retval EFI_SUCCESS  Get channel information successfully.
+  @retval Others   Other errors.
+
+**/
+EFI_STATUS
+EFIAPI
+IpmiGetChannelInfo (
+  IN  IPMI_GET_CHANNEL_INFO_REQUEST  *GetChannelInfoRequest,
+  OUT IPMI_GET_CHANNEL_INFO_RESPONSE *GetChannelInfoResponse,
+  OUT UINT32 *GetChannelInfoResponseSize
+  )
+{
+  EFI_STATUS Status;
+
+  *GetChannelInfoResponseSize = sizeof 
+(IPMI_GET_CHANNEL_INFO_RESPONSE);
+  Status = IpmiSubmitCommand (
+ IPMI_NETFN_APP,
+ IPMI_APP_GET_CHANNEL_INFO,
+ (UINT8 *)GetChannelInfoRequest,
+ sizeof (IPMI_GET_CHANNEL_INFO_REQUEST),
+ (UINT8 *)GetChannelInfoResponse,
+ GetChannelInfoResponseSize
+ );
+  return Status;
+}
diff --git 
a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Library/IpmiCommandLib/IpmiCommandLibNetFnTransport.c
 
b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Library/IpmiCommandLib/IpmiCommandLibNetFnTransport.c
index 7dfcf86126..135a905844 100644
--- 
a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Library/IpmiCommandLib/IpmiCommandLibNetFnTransport.c
+++ b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Library/IpmiComm
+++ andLib/IpmiCommandLibNetFnTransport.c
@@ -2,6 +2,8 @@
   IPMI Command - NetFnTransport.
 
   Copyright (c) 2018 - 2021, Intel Corporation. All rights reserved.
+  Copyright (C) 2022 Advanced Micro Devices, Inc. All rights 
+ reserved.
+
   SPDX-License-Identifier:

Re: [edk2-devel] [edk2-platforms][PATCH 1/3] Features/IpmiFeaturePkg: Add IPMI functions

2023-01-04 Thread Isaac Oram

Abner,

The @param and IN, OUT tagging on the parameters do not match for 
IpmiGetChannelInfo and IpmiGetLanConfigurationParameters functions.  Please 
align and comment the expected usage and input handling that the API 
implementation is expected to provide.

Regards,
Isaac


-Original Message-
From: devel@edk2.groups.io  On Behalf Of Chang, Abner via 
groups.io
Sent: Friday, December 23, 2022 5:27 AM
To: devel@edk2.groups.io
Cc: Oram, Isaac W ; Desimone, Nathaniel L 
; Gao, Liming ; 
Nickle Wang ; Igor Kulchytskyy 
Subject: [edk2-devel] [edk2-platforms][PATCH 1/3] Features/IpmiFeaturePkg: Add 
IPMI functions

From: Abner Chang 

Add functions to get system UUID and LAN configuration parameter.

Signed-off-by: Abner Chang 
Cc: Isaac Oram 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Nickle Wang 
Cc: Igor Kulchytskyy 
---
 .../Include/Library/IpmiCommandLib.h  | 60 +++
 1 file changed, 60 insertions(+)

diff --git 
a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Include/Library/IpmiCommandLib.h
 
b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Include/Library/IpmiCommandLib.h
index 18f9d123c9..c816750544 100644
--- 
a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Include/Library/IpmiCommandLib.h
+++ b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Include/Library/
+++ IpmiCommandLib.h
@@ -2,6 +2,8 @@
   This library abstract how to send/receive IPMI command.
 
 Copyright (c) 2018-2021, Intel Corporation. All rights reserved.
+Copyright (C) 2022 Advanced Micro Devices, Inc. All rights 
+reserved.
+
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -88,6 +90,43 @@ IpmiSendMessage (
   IN OUT UINT32  *SendMessageResponseSize
   );
 
+/**
+  This function gets the system UUID.
+
+  @param[out] SystemGuid   The pointer to retrieve system UUID.
+
+  @retval EFI_SUCCESS   UUID is returned.
+  @retval EFI_INVALID_PARAMETER SystemGuid is a NULL pointer.
+  @retval OthersOther errors.
+
+**/
+EFI_STATUS
+EFIAPI
+IpmiGetSystemUuid (
+  OUT EFI_GUID *SystemGuid
+  );
+
+/**
+  This function gets the channel information.
+
+  @param[in] GetChannelInfoRequest   The get channel information 
request.
+  @param[in] GetChannelInfoResponse  The get channel information 
response.
+  @param[in,out] GetChannelInfoResponseSize  When input, the expected size of 
response.
+ When output, the exact size of 
the returned
+  response.
+
+  @retval EFI_SUCCESS  Get channel information successfully.
+  @retval Others   Other errors.
+
+**/
+EFI_STATUS
+EFIAPI
+IpmiGetChannelInfo (
+  IN  IPMI_GET_CHANNEL_INFO_REQUEST  *GetChannelInfoRequest,
+  OUT IPMI_GET_CHANNEL_INFO_RESPONSE *GetChannelInfoResponse,
+  OUT UINT32 *GetChannelInfoResponseSize
+  );
+
 //
 // NetFnTransport
 //
@@ -114,6 +153,27 @@ IpmiGetSolConfigurationParameters (
   IN OUT UINT32  
*GetConfigurationParametersResponseSize
   );
 
+/**
+  This function gets the LAN configuration parameter.
+
+  @param[in] GetLanConfigurationParametersRequest   Request data
+  @param[in] GetLanConfigurationParametersResponse  Response data
+  @param[in,out] GetLanConfigurationParametersSize  When input, the 
expected size of response data.
+When out, the exact  
size of response data.
+
+  @retval EFI_SUCCESS  Lan configuration parameter is returned in the 
response.
+  @retval Others   Other errors.
+
+**/
+
+EFI_STATUS
+EFIAPI
+IpmiGetLanConfigurationParameters (
+  IN   IPMI_GET_LAN_CONFIGURATION_PARAMETERS_REQUEST  
*GetLanConfigurationParametersRequest,
+  OUT  IPMI_GET_LAN_CONFIGURATION_PARAMETERS_RESPONSE 
*GetLanConfigurationParametersResponse,
+  IN OUT UINT32   
*GetLanConfigurationParametersSize
+  );
+
 //
 // NetFnChasis
 //
--
2.37.1.windows.1








-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#97955): https://edk2.groups.io/g/devel/message/97955
Mute This Topic: https://groups.io/mt/95844504/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 03/16] ArmVirtPkg: make EFI_LOADER_DATA non-executable

2023-01-04 Thread Alexander Graf




On 04.01.23 14:13, Alexander Graf wrote:


On 04.01.23 10:35, Ard Biesheuvel wrote:
On Tue, 3 Jan 2023 at 23:47, dann frazier 
 wrote:

On Tue, Jan 03, 2023 at 08:39:24PM +0100, Alexander Graf wrote:

Hey Ard,

On 03.01.23 10:59, Ard Biesheuvel wrote:
On Thu, 29 Dec 2022 at 19:00, dann frazier 
 wrote:

On Mon, Nov 28, 2022 at 04:46:10PM +0100, Gerd Hoffmann wrote:

On Mon, Sep 26, 2022 at 10:24:58AM +0200, Ard Biesheuvel wrote:
When the memory protections were implemented and enabled on 
ArmVirtQemu

5+ years ago, we had to work around the fact that GRUB at the time
expected EFI_LOADER_DATA to be executable, as that is the 
memory type it

allocates when loading its modules.

This has been fixed in GRUB in August 2017, so by now, we 
should be able
to tighten this, and remove execute permissions from 
EFI_LOADER_DATA

allocations.

Data point: https://bugzilla.redhat.com/show_bug.cgi?id=2149020
tl;dr: fedora 37 grub.efi is still broken.

This is also the case with existing Ubuntu releases, as well as
AlmaLinux 9.1 and RHEL 8.7[*]. While it does appear to be fixed for
the upcoming Ubuntu 23.04 (presumably via [**]), I plan to revert 
this
patch in Debian/Ubuntu until it is more ubiquitous. Do you want 
to do

the same upstream? I'm not sure at what point it would make sense to
reintroduce it, given we can't force users to upgrade their 
bootloaders.



Thanks for the report.

You can override PCDs on the build command line, so I suggest you use
that for building these images as long as it is needed.

E.g,, append this to the build.sh command line

--pcd PcdDxeNxMemoryProtectionPolicy=0xC0007FD1

to undo the effects of this patch.

I do not intend to revert this patch - the trend under EFI is towards
much stricter memory permissions, also on the MS side, and this is
especially important under CC scenarios. And if 5+ years is not
sufficient for out-of-tree GRUB to catch up, what is the point of
waiting for it?


I think we need to be smarter here. ArmVirtPkg is used by a lot of
virtualization software - such as QEMU. Typically, users (and 
developers)

expect that an update to a newer version will preserve compatibility.

Let me contrive an example: In 1 year, QEMU updates to the latest 
AAVMF. It
ships that as part of its pc-bios directory. Suddenly, we 
accidentally break
old (immutable!) iso images that used to work. So someone that 
updates QEMU

to a newer version will have a regression in running a Fedora 37
installation. Or RHEL 8.7 installation. Not good :).

Outside of OSVs providing new iso images, there is also not much 
you can do
about this. The grub binary here runs way before any updater code 
that could

pull a fixed version from the internet.

What alternatives do we have? Assuming grub is the only offender we 
have to
worry about, is there a way we can identify that the allocation 
came from an

unpatched version? Or have a database of hashes (with all known grub
binaries that have this bug in existing isos) that would force 
disable NX
protection for it if we hit it? Or disable NX when Secure Boot is 
disabled?


I really think we need to be a bit more creative than make NX 
mandatory in
all cases when we know the are immutable images out there that 
won't work

with it, otherwise we break very legit use cases.

While it has its own issues, I suppose another way to go about it is
for distributors to provide multiple AAVMF_CODE images, and perhaps
invent a "feature" flag for the json descriptor for management tools
to select an appropriate one.


I don't think having different versions of the image makes sense, tbh,
but of course, this is up to the distros.

Compatibility with ancient downstream GRUB builds is not a goal of the
EDK2 upstream, so as long as distros can tweak the build to their
needs, I don't see a reason to revert this change upstream.



First of all, I don't think we should revert this change. We should 
augment it to give users the out-of-the-box experience they expect.


On top of that, I don't think it's a problem of "distros". Every 
consumer of AAVMF will run into this problem as soon as their users 
will want to run any Red Hat OS (installer / image) all the way into 
2022. That's  very likely >90% of the user base. Because of that, I'm 
pretty sure no Cloud vendor will be able to enable NX in its current 
shape for example.


I'm very happy to see NX proliferate through the stack, but let's 
please make sure we do it compatibly by default, otherwise the net 
result is that *everyone* who compiles AAVMF will disable NX by 
default again - and all you end up with is more frustration and more 
downstream code / forks.


IMHO the most obvious approach would be a fingerprint based override. 
There should be a finite number of known broken grub binaries. If we 
just maintain a database with them and then apply some magic when we 
detect such a binary gets loaded, we'll have tightened security by 
default, without breaking backwards compat.


For environments

Re: [edk2-devel] edk2-platforms, continuous integration, testing, and you

2023-01-04 Thread Pedro Falcato

Sean,

Thank you for making edk2 better :)

I have replied to your github discussion with a bunch of my ideas, as both
a feature package maintainer and platform maintainer.
(
https://github.com/tianocore/edk2/discussions/3721#discussioncomment-4596465
)

I'm willing to discuss these things further as long as it's not at *checks
edk2 tools & CI meeting time* 1am (email, chat, 1-on-1, you name it).
I am also interested in getting QemuOpenBoardPkg into your platform CI
initiative as it's a simple platform that only requires QEMU to boot (plus
a copy of edk2-platforms and edk2 to build).

--
Pedro


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

Re: [edk2-devel] [PATCH 0/1] OvmfPkg/PlatformInitLib: catch QEMU's CPU hotplug reg block regression

2023-01-04 Thread Michael D Kinney

Hi Laszlo,

Unit test code coverage was enabled just a couple days ago in CI.  Looks like 
you uncovered a corner case that was missed that should not generate a CI 
failure.

I have asked Gua to investigate.

Thanks,

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Laszlo Ersek
> Sent: Wednesday, January 4, 2023 7:13 AM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Brijesh Singh 
> ; Aktas, Erdem ; Gerd
> Hoffmann ; James Bottomley ; Yao, 
> Jiewen ; Justen, Jordan L
> ; Xu, Min M ; Boeuf, Sebastien 
> ; Tom Lendacky
> 
> Subject: [edk2-devel] [PATCH 0/1] OvmfPkg/PlatformInitLib: catch QEMU's CPU 
> hotplug reg block regression
> 
> Repo:   https://pagure.io/lersek/edk2.git
> Branch: cpuhp-reg-catch-4250
> Test build: https://github.com/tianocore/edk2/pull/3853
> Bugzilla:   https://bugzilla.tianocore.org/show_bug.cgi?id=4250
> 
> NOTE: the test build linked above (in the github.com CI env) *failed*.
> That's because the CI environment is affected by this very QEMU bug!
> 
> Namely, the following checks failed -- due to the intentional hang
> introduced in this patch:
> 
> - PlatformCI_OvmfPkg_Ubuntu_GCC5_PR (12 tests)
> - PlatformCI_OvmfPkg_Windows_VS2019_PR (11 tests)
> 
> (The Build_VS2019_TARGET_CODE_COVERAGE and
> Build_GCC5_TARGET_CODE_COVERAGE tests also failed, but those seem bogus
> to me.)
> 
> All 12+11=23 PlatformCI_OvmfPkg_* checks failed due to timeout, and the
> firmware logs of the DEBUG and NOOPT builds end with:
> 
> > INFO - PlatformMaxCpuCountInitialization: Broken CPU hotplug register 
> > block: Present=0 Possible=1.
> > INFO - PlatformMaxCpuCountInitialization: Switch QEMU's acceleration from 
> > TCG to KVM, or update QEMU.
> > INFO - PlatformMaxCpuCountInitialization: Refer to 
> > .
> > INFO - ASSERT 
> > /home/vsts/work/1/s/OvmfPkg/Library/PlatformInitLib/Platform.c(574): 
> > ((BOOLEAN)(0==1))
> 
> So I'm not proposing to merge this immediately; something must be fixed
> first:
> 
> - use KVM in the CI env, or
> 
> - delay this patch until my QEMU fix is merged, and a new release is
>   made, and the new QEMU release is packaged by the distros, and the new
>   distro packages are picked up by github.com CI.
> 
> Suggestions?
> 
> Thanks,
> Laszlo
> 
> Cc: Ard Biesheuvel 
> Cc: Brijesh Singh 
> Cc: Erdem Aktas 
> Cc: Gerd Hoffmann 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Jordan Justen 
> Cc: Min Xu 
> Cc: Sebastien Boeuf 
> Cc: Tom Lendacky 
> 
> Laszlo Ersek (1):
>   OvmfPkg/PlatformInitLib: catch QEMU's CPU hotplug reg block regression
> 
>  OvmfPkg/Library/PlatformInitLib/Platform.c | 34 
>  1 file changed, 34 insertions(+)
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH] UefiPayloadPkg: Move RTC PCD to dynamic PCD

2023-01-04 Thread Guo Dong



Reviewed-by: Guo Dong 

-Original Message-
From: Liu, KasimX  
Sent: Wednesday, December 28, 2022 1:13 AM
To: devel@edk2.groups.io
Cc: Liu, KasimX ; Dong, Guo ; Ni, Ray 
; Lu, James ; Guo, Gua 
Subject: [PATCH] UefiPayloadPkg: Move RTC PCD to dynamic PCD

From: KasimX Liu 

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

In order to remove RTC_INDEX/RTC_TARGET from the UplBuild macro list,change the 
RTC_INDEX /RTC_TARGET type from PcdsFixedAtBuild to PcdsDynamicEx

Cc: Guo Dong 
Cc: Ray Ni 
Cc: James Lu 
Cc: Gua Guo 
Signed-off-by: KasimX Liu 
---
 UefiPayloadPkg/UefiPayloadPkg.dsc | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc 
b/UefiPayloadPkg/UefiPayloadPkg.dsc
index 12e80a9e74..a1a3c74290 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.dsc
+++ b/UefiPayloadPkg/UefiPayloadPkg.dsc
@@ -472,8 +472,6 @@
 !endif  [PcdsPatchableInModule.X64]-  
gPcAtChipsetPkgTokenSpaceGuid.PcdRtcIndexRegister|$(RTC_INDEX_REGISTER)-  
gPcAtChipsetPkgTokenSpaceGuid.PcdRtcTargetRegister|$(RTC_TARGET_REGISTER) !if 
$(NETWORK_DRIVER_ENABLE) == TRUE   
gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections|TRUE !endif@@ -580,6 
+578,9 @@
   gUefiCpuPkgTokenSpaceGuid.PcdSevEsIsEnabled|0   
gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration|TRUE +  
gPcAtChipsetPkgTokenSpaceGuid.PcdRtcIndexRegister|$(RTC_INDEX_REGISTER)+  
gPcAtChipsetPkgTokenSpaceGuid.PcdRtcTargetRegister|$(RTC_TARGET_REGISTER)+ 

 # # Components Section - list of all EDK II Modules needed by this Platform.-- 
2.32.0.windows.2



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

Re: [edk2-devel] [PATCH] UefiPayloadPkg: remove the change that get platform specific logic

2023-01-04 Thread Guo Dong



Reviewed-by: Guo Dong 

-Original Message-
From: Lin, MarsX  
Sent: Tuesday, January 3, 2023 12:45 AM
To: devel@edk2.groups.io
Cc: Lin, MarsX ; Dong, Guo ; Ni, Ray 
; Rhodes, Sean ; Lu, James 
; Guo, Gua 
Subject: [PATCH] UefiPayloadPkg: remove the change that get platform specific 
logic

From: MarsX Lin 

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

Since UefiPayloadPkg had supported multiple firmware volume, remove the 
platform specific logic via protocol

Cc: Guo Dong 
Cc: Ray Ni 
Cc: Sean Rhodes 
Cc: James Lu 
Cc: Gua Guo 

Signed-off-by: MarsX Lin 
---
 .../Protocol/PlatformBootManagerOverride.h| 84 ---
 .../PlatformBootManager.c | 27 --
 .../PlatformBootManagerLib.inf|  1 -
 UefiPayloadPkg/UefiPayloadPkg.dec |  2 -
 4 files changed, 114 deletions(-)
 delete mode 100644 
UefiPayloadPkg/Include/Protocol/PlatformBootManagerOverride.h

diff --git a/UefiPayloadPkg/Include/Protocol/PlatformBootManagerOverride.h 
b/UefiPayloadPkg/Include/Protocol/PlatformBootManagerOverride.h
deleted file mode 100644
index 878ddc044b..00
--- a/UefiPayloadPkg/Include/Protocol/PlatformBootManagerOverride.h
+++ /dev/null
@@ -1,84 +0,0 @@
-/** @file-  This file defines the Univeral Payload Platform BootManager 
Protocol.--  Copyright (c) 2021, Intel Corporation. All rights reserved.-  
SPDX-License-Identifier: BSD-2-Clause-Patent-**/--#ifndef 
__PLATFORM_BOOT_MANAGER_OVERRIDE_H__-#define 
__PLATFORM_BOOT_MANAGER_OVERRIDE_H__--/**-  Do the platform specific action 
before the console is connected.--  Such as:-Update console variable;-
Register new Driver or Boot;-Signal ReadyToLock event.--  This 
function will override the default behavior in 
PlatformBootManagerLib-**/-typedef-VOID-(EFIAPI 
*UNIVERSAL_PAYLOAD_PLATFORM_BOOT_MANAGER_OVERRIDE_BEFORE_CONSOLE)(-  VOID-  
);--/**-  Do the platform specific action after the console is connected.--  
Such as:-Dynamically switch output mode;-Signal console ready platform 
customized event;-Run diagnostics like memory testing;-Connect certain 
devices;-Dispatch aditional option roms.--  This function will override the 
default behavior in PlatformBootManagerLib-**/-typedef-VOID-(EFIAPI 
*UNIVERSAL_PAYLOAD_PLATFORM_BOOT_MANAGER_OVERRIDE_AFTER_CONSOLE)(-  VOID-  
);--/**-  This function is called each second during the boot manager waits the 
timeout.-  This function will override the default behavior in 
PlatformBootManagerLib--  @param TimeoutRemain  The remaining 
timeout.-**/-typedef-VOID-(EFIAPI 
*UNIVERSAL_PAYLOAD_PLATFORM_BOOT_MANAGER_OVERRIDE_WAIT_CALLBACK)(-  UINT16  
TimeoutRemain-  );--/**-  The function is called when no boot option could 
be launched,-  including platform recovery options and options pointing to 
applications-  built into firmware volumes.--  If this function returns, BDS 
attempts to enter an infinite loop.-  This function will override the default 
behavior in PlatformBootManagerLib-**/-typedef-VOID-(EFIAPI 
*UNIVERSAL_PAYLOAD_PLATFORM_BOOT_MANAGER_OVERRIDE_UNABLE_TO_BOOT)(-  VOID-  
);--///-/// Provides an interface to override the default behavior in 
PlatformBootManagerLib,-/// so platform can provide its own platform specific 
logic through this protocol-///-typedef struct {-  
UNIVERSAL_PAYLOAD_PLATFORM_BOOT_MANAGER_OVERRIDE_BEFORE_CONSOLE
BeforeConsole;-  UNIVERSAL_PAYLOAD_PLATFORM_BOOT_MANAGER_OVERRIDE_AFTER_CONSOLE 
AfterConsole;-  
UNIVERSAL_PAYLOAD_PLATFORM_BOOT_MANAGER_OVERRIDE_WAIT_CALLBACK 
WaitCallback;-  UNIVERSAL_PAYLOAD_PLATFORM_BOOT_MANAGER_OVERRIDE_UNABLE_TO_BOOT 
   UnableToBoot;-} 
UNIVERSAL_PAYLOAD_PLATFORM_BOOT_MANAGER_OVERRIDE_PROTOCOL;--extern GUID  
gUniversalPayloadPlatformBootManagerOverrideProtocolGuid;--#endifdiff --git 
a/UefiPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManager.c 
b/UefiPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManager.c
index a92a260a6e..62637ae6aa 100644
--- a/UefiPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManager.c
+++ b/UefiPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManager.
+++ c
@@ -9,12 +9,9 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
  #include "PlatformBootManager.h" #include "PlatformConsole.h"-#include 
 #include  
#include  
-UNIVERSAL_PAYLOAD_PLATFORM_BOOT_MANAGER_OVERRIDE_PROTOCOL  
*mUniversalPayloadPlatformBootManagerOverrideInstance = NULL;- /**   Signal 
EndOfDxe event and install SMM Ready to lock protocol. @@ -167,17 +164,6 @@ 
PlatformBootManagerBeforeConsole (
   EFI_INPUT_KEY CustomKey;   EFI_INPUT_KEY 
Down;   EFI_BOOT_MANAGER_LOAD_OPTION  BootOption;-  EFI_STATUS  
  Status;--  Status = gBS->LocateProtocol 
(, NULL, (VOID 
**));-  if (EFI_ERROR 
(Status)) {-mUniversalPayloadPlatformBootManagerOverrideInstance = NULL;-  
}--  if (mUniversalPayloadPlatformBootManagerOverrideInstance != NULL) {-

Re: [edk2-devel] [PATCH] UefiPayloadPkg: Move RTC PCD to dynamic PCD

2023-01-04 Thread Guo Dong



From: Guo Dong 

-Original Message-
From: Liu, KasimX  
Sent: Wednesday, December 28, 2022 1:13 AM
To: devel@edk2.groups.io
Cc: Liu, KasimX ; Dong, Guo ; Ni, Ray 
; Lu, James ; Guo, Gua 
Subject: [PATCH] UefiPayloadPkg: Move RTC PCD to dynamic PCD

From: KasimX Liu 

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

In order to remove RTC_INDEX/RTC_TARGET from the UplBuild macro list,change the 
RTC_INDEX /RTC_TARGET type from PcdsFixedAtBuild to PcdsDynamicEx

Cc: Guo Dong 
Cc: Ray Ni 
Cc: James Lu 
Cc: Gua Guo 
Signed-off-by: KasimX Liu 
---
 UefiPayloadPkg/UefiPayloadPkg.dsc | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc 
b/UefiPayloadPkg/UefiPayloadPkg.dsc
index 12e80a9e74..a1a3c74290 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.dsc
+++ b/UefiPayloadPkg/UefiPayloadPkg.dsc
@@ -472,8 +472,6 @@
 !endif  [PcdsPatchableInModule.X64]-  
gPcAtChipsetPkgTokenSpaceGuid.PcdRtcIndexRegister|$(RTC_INDEX_REGISTER)-  
gPcAtChipsetPkgTokenSpaceGuid.PcdRtcTargetRegister|$(RTC_TARGET_REGISTER) !if 
$(NETWORK_DRIVER_ENABLE) == TRUE   
gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections|TRUE !endif@@ -580,6 
+578,9 @@
   gUefiCpuPkgTokenSpaceGuid.PcdSevEsIsEnabled|0   
gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration|TRUE +  
gPcAtChipsetPkgTokenSpaceGuid.PcdRtcIndexRegister|$(RTC_INDEX_REGISTER)+  
gPcAtChipsetPkgTokenSpaceGuid.PcdRtcTargetRegister|$(RTC_TARGET_REGISTER)+ 

 # # Components Section - list of all EDK II Modules needed by this Platform.-- 
2.32.0.windows.2



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

[edk2-devel] edk2-platforms, continuous integration, testing, and you

2023-01-04 Thread Sean

There has been a long standing ask to/from the Edk2/UEFI community to 
improve the code contribution process, quality, and consistency of the 
edk2-platforms repository.


In the weekly Tianocore Tools & CI meeting this topic has come up and 
was discussed at the last meeting (12/12) Tools & CI Meeting - 
2022-12-12 - YouTube 




There are two asks.

1. If you own any feature package or platform in edk2-platforms please 
get involved in the discussion.  The CI system should reflect the tests 
and features that are important to the contributors of the repository.


A CI system for Edk2-Platforms · Discussion #3721 · tianocore/edk2 
(github.com) 



2.  If you own a feature package help get your package passing "Core CI" 
and look at enabling more testing (host based unit tests and/or on 
device functional tests).


There is a branch here: spbrogan/edk2-platforms at enable_ci_v1 
(github.com) 
 where I 
have started to enable Core CI (started with Ext4Pkg and 
Usb3DebugFeaturePkg as examples).




Thanks

Sean





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

[edk2-devel] [PATCH] ArmVirtPkg/ArmVirtQemu: Avoid early ID map on ThunderX

2023-01-04 Thread Ard Biesheuvel

The early ID map used by ArmVirtQemu uses ASID scoped non-global
mappings, as this allows us to switch to the permanent ID map seamlessly
without the need for explicit TLB maintenance.

However, this triggers a known erratum on ThunderX, which does not
tolerate non-global mappings that are executable at EL1, as this appears
to result in I-cache corruption. (Linux disables the KPTI based Meltdown
mitigation on ThunderX for the same reason)

So work around this, by detecting the CPU implementor and part number,
and proceeding without the early ID map if a ThunderX CPU is detected.

Note that this requires the C code to be built with strict alignment
again, as we may end up executing it with the MMU and caches off.

Signed-off-by: Ard Biesheuvel 
---
 ArmVirtPkg/ArmVirtQemu.dsc|  6 ++
 ArmVirtPkg/Library/ArmPlatformLibQemu/AArch64/ArmPlatformHelper.S | 18 
++
 2 files changed, 24 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index f77443229e8e..340b36f69c2c 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -31,6 +31,7 @@ [Defines]
   DEFINE SECURE_BOOT_ENABLE  = FALSE
   DEFINE TPM2_ENABLE = FALSE
   DEFINE TPM2_CONFIG_ENABLE  = FALSE
+  DEFINE CAVIUM_ERRATUM_27456= FALSE
 
   #
   # Network definition
@@ -117,7 +118,12 @@ [LibraryClasses.common.UEFI_DRIVER]
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
 
 [BuildOptions]
+!if $(CAVIUM_ERRATUM_27456) == TRUE
+  GCC:*_*_AARCH64_CC_XIPFLAGS = -mno-strict-align
+  GCC:*_*_AARCH64_PP_FLAGS= -DCAVIUM_ERRATUM_27456
+!else
   GCC:*_*_AARCH64_CC_XIPFLAGS ==
+!endif
 
 !include NetworkPkg/NetworkBuildOptions.dsc.inc
 
diff --git a/ArmVirtPkg/Library/ArmPlatformLibQemu/AArch64/ArmPlatformHelper.S 
b/ArmVirtPkg/Library/ArmPlatformLibQemu/AArch64/ArmPlatformHelper.S
index 05ccc7f9f043..962f1ba3a4d7 100644
--- a/ArmVirtPkg/Library/ArmPlatformLibQemu/AArch64/ArmPlatformHelper.S
+++ b/ArmVirtPkg/Library/ArmPlatformLibQemu/AArch64/ArmPlatformHelper.S
@@ -44,8 +44,26 @@
 
 
 ASM_FUNC(ArmPlatformPeiBootAction)
+#ifdef CAVIUM_ERRATUM_27456
+  /*
+   * On Cavium ThunderX, using non-global mappings that are executable at EL1
+   * results in I-cache corruption. So just avoid the early ID mapping there.
+   *
+   * MIDR implementor   0x43
+   * MIDR part numbers  0xA1 0xA2
+   */
+  mrsx0, midr_el1// read the MIDR into X0
+  ubfx   x1, x0, #6, #10 // grab part number bits [11:2]
+  ubfx   x0, x0, #24, #8 // grab implementor id
+  movx2, #0xA0 >> 2
+  cmpx0, #0x43   // compare implementor id
+  ccmp   x1, x2, #0, eq  // compare part# bits [11:2]
+  b.eq   .Lreturn
+#endif
+
   mrsx0, CurrentEL   // check current exception level
   tbzx0, #3, 0f  // bail if above EL1
+.Lreturn:
   ret
 
 0:mov_i  x0, mairval
-- 
2.39.0



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

[edk2-devel] Event: TianoCore Community Meeting EMEA/NAMO - Thursday, January 5, 2023 #cal-reminder

2023-01-04 Thread Group Notification

*Reminder: TianoCore Community Meeting EMEA/NAMO*

*When:*
Thursday, January 5, 2023
8:00am to 9:00am
(UTC-08:00) America/Los Angeles

*Where:*
Microsoft Teams meeting Join on your computer or mobile app Click here to join 
the meeting Meeting ID: 226 323 011 029 Passcode: hMRCj6 Download Teams | Join 
on the web Join with a video conferencing device te...@conf.intel.com Video 
Conference ID: 112 716 814 3 Alternate VTC instructions Learn More | Meeting 
options

*Organizer:* Miki Demeter

View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=1650227 )

*Description:*



Microsoft Teams meeting

*Join on your computer or mobile app*

Click here to join the meeting ( 
https://teams.microsoft.com/l/meetup-join/19%3ameeting_MTAyZGJhNjMtYzQ4Mi00MTUxLWFlMWMtOGU0MWNlZDk4NjY5%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%226e4ce4c4-1242-431b-9a51-92cd01a5df3c%22%7d
 )

Meeting ID: 226 323 011 029
Passcode: hMRCj6

Download Teams ( https://www.microsoft.com/en-us/microsoft-teams/download-app ) 
| Join on the web ( https://www.microsoft.com/microsoft-teams/join-a-meeting )

*Join with a video conferencing device*

te...@conf.intel.com

Video Conference ID: 112 716 814 3

Alternate VTC instructions ( 
https://conf.intel.com/teams/?conf=1127168143=teams=conf.intel.com=test_call
 )

Learn More ( https://aka.ms/JoinTeamsMeeting ) | Meeting options ( 
https://teams.microsoft.com/meetingOptions/?organizerId=6e4ce4c4-1242-431b-9a51-92cd01a5df3c=46c98d88-e344-4ed4-8496-4ed7712e255d=19_meeting_MTAyZGJhNjMtYzQ4Mi00MTUxLWFlMWMtOGU0MWNlZDk4NjY5@thread.v2=0=en-US
 )




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

[edk2-devel] [PATCH 1/1] OvmfPkg/PlatformInitLib: catch QEMU's CPU hotplug reg block regression

2023-01-04 Thread Laszlo Ersek

In QEMU v5.1.0, the CPU hotplug register block misbehaves: the negotiation
protocol is (effectively) broken such that it suggests that switching from
the legacy interface to the modern interface works, but in reality the
switch never happens. The symptom has been witnessed when using TCG
acceleration; KVM seems to mask the issue. The issue persists with the
following (latest) stable QEMU releases: v5.2.0, v6.2.0, v7.2.0. Currently
there is no stable release that addresses the problem.

The QEMU bug confuses the Present and Possible counting in function
PlatformMaxCpuCountInitialization(), in
"OvmfPkg/Library/PlatformInitLib/Platform.c". OVMF ends up with Present=0
Possible=1. This in turn further confuses MpInitLib in UefiCpuPkg (hence
firmware-time multiprocessing will be broken). Worse, CPU hot(un)plug with
SMI will be summarily broken in OvmfPkg/CpuHotplugSmm, which (considering
the privilege level of SMM) is not that great.

Detect the issue in PlatformMaxCpuCountInitialization(), and print an
error message and *hang* if the issue is present.

The problem was originally reported by Ard [0]. We analyzed it at [1] and
[2]. A QEMU patch was sent at [3].

[0] https://bugzilla.tianocore.org/show_bug.cgi?id=4234#c2

[1] https://bugzilla.tianocore.org/show_bug.cgi?id=4234#c3

[2] IO port write width clamping differs between TCG and KVM
http://mid.mail-archive.com/aaedee84-d3ed-a4f9-21e7-d221a28d1683@redhat.com
https://lists.gnu.org/archive/html/qemu-devel/2023-01/msg00199.html

[3] acpi: cpuhp: fix guest-visible maximum access size to the legacy reg block
http://mid.mail-archive.com/20230104090138.214862-1-lersek@redhat.com
https://lists.gnu.org/archive/html/qemu-devel/2023-01/msg00278.html

NOTE: PlatformInitLib is used in the following platform DSCs:

  OvmfPkg/AmdSev/AmdSevX64.dsc
  OvmfPkg/CloudHv/CloudHvX64.dsc
  OvmfPkg/IntelTdx/IntelTdxX64.dsc
  OvmfPkg/Microvm/MicrovmX64.dsc
  OvmfPkg/OvmfPkgIa32.dsc
  OvmfPkg/OvmfPkgIa32X64.dsc
  OvmfPkg/OvmfPkgX64.dsc

but I can only test this change with the last three platforms, running on
QEMU.

Test results:

  TCG  QEMU OVMF result
   patched  patched
  ---  ---  ---  -
  000CPU counts OK (KVM masks the QEMU bug)
  001CPU counts OK (KVM masks the QEMU bug)
  010CPU counts OK (QEMU fix, but KVM masks the QEMU
 bug anyway)
  011CPU counts OK (QEMU fix, but KVM masks the QEMU
 bug anyway)
  100boot with broken CPU counts (original QEMU bug)
  101broken CPU count caught (boot hangs)
  110CPU counts OK (QEMU fix)
  111CPU counts OK (QEMU fix)

Cc: Ard Biesheuvel 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: Gerd Hoffmann 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Min Xu 
Cc: Sebastien Boeuf 
Cc: Tom Lendacky 
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=4250
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Library/PlatformInitLib/Platform.c | 34 
 1 file changed, 34 insertions(+)

diff --git a/OvmfPkg/Library/PlatformInitLib/Platform.c 
b/OvmfPkg/Library/PlatformInitLib/Platform.c
index 3e13c5d4b34f..034282df5aab 100644
--- a/OvmfPkg/Library/PlatformInitLib/Platform.c
+++ b/OvmfPkg/Library/PlatformInitLib/Platform.c
@@ -541,6 +541,40 @@ PlatformMaxCpuCountInitialization (
 ASSERT (Selected == Possible || Selected == 0);
   } while (Selected > 0);
 
+  //
+  // Sanity check: we need at least 1 present CPU (CPU#0 is always 
present).
+  //
+  // The legacy-to-modern switching of the CPU hotplug register block got
+  // broken (for TCG) in QEMU v5.1.0. Refer to "IO port write width 
clamping
+  // differs between TCG and KVM" at
+  // 

+  // or at
+  // .
+  //
+  // A fix was submitted after QEMU v7.2.0: "[PATCH] acpi: cpuhp: fix
+  // guest-visible maximum access size to the legacy reg block".
+  //
+  // If we're affected by this QEMU bug, then we must not continue: it
+  // confuses the multiprocessing in UefiCpuPkg/Library/MpInitLib, and
+  // breaks CPU hot(un)plug with SMI in OvmfPkg/CpuHotplugSmm.
+  //
+  if (Present == 0) {
+DEBUG ((
+  DEBUG_ERROR,
+  "%a: Broken CPU hotplug register block: Present=%u Possible=%u.\n"
+  "%a: Switch QEMU's acceleration from TCG to KVM, or update QEMU.\n"
+  "%a: Refer to "
+  ".\n",
+  __FUNCTION__,
+  Present,
+  Possible,
+  __FUNCTION__,
+  __FUNCTION__
+  ));
+ASSERT (FALSE);
+CpuDeadLoop ();
+  }
+

[edk2-devel] [PATCH 0/1] OvmfPkg/PlatformInitLib: catch QEMU's CPU hotplug reg block regression

2023-01-04 Thread Laszlo Ersek

Repo:   https://pagure.io/lersek/edk2.git
Branch: cpuhp-reg-catch-4250
Test build: https://github.com/tianocore/edk2/pull/3853
Bugzilla:   https://bugzilla.tianocore.org/show_bug.cgi?id=4250

NOTE: the test build linked above (in the github.com CI env) *failed*.
That's because the CI environment is affected by this very QEMU bug!

Namely, the following checks failed -- due to the intentional hang
introduced in this patch:

- PlatformCI_OvmfPkg_Ubuntu_GCC5_PR (12 tests)
- PlatformCI_OvmfPkg_Windows_VS2019_PR (11 tests)

(The Build_VS2019_TARGET_CODE_COVERAGE and
Build_GCC5_TARGET_CODE_COVERAGE tests also failed, but those seem bogus
to me.)

All 12+11=23 PlatformCI_OvmfPkg_* checks failed due to timeout, and the
firmware logs of the DEBUG and NOOPT builds end with:

> INFO - PlatformMaxCpuCountInitialization: Broken CPU hotplug register block: 
> Present=0 Possible=1.
> INFO - PlatformMaxCpuCountInitialization: Switch QEMU's acceleration from TCG 
> to KVM, or update QEMU.
> INFO - PlatformMaxCpuCountInitialization: Refer to 
> .
> INFO - ASSERT 
> /home/vsts/work/1/s/OvmfPkg/Library/PlatformInitLib/Platform.c(574): 
> ((BOOLEAN)(0==1))

So I'm not proposing to merge this immediately; something must be fixed
first:

- use KVM in the CI env, or

- delay this patch until my QEMU fix is merged, and a new release is
  made, and the new QEMU release is packaged by the distros, and the new
  distro packages are picked up by github.com CI.

Suggestions?

Thanks,
Laszlo

Cc: Ard Biesheuvel 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: Gerd Hoffmann 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Min Xu 
Cc: Sebastien Boeuf 
Cc: Tom Lendacky 

Laszlo Ersek (1):
  OvmfPkg/PlatformInitLib: catch QEMU's CPU hotplug reg block regression

 OvmfPkg/Library/PlatformInitLib/Platform.c | 34 
 1 file changed, 34 insertions(+)



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

[edk2-devel] [PATCH V1 1/1] OvmfPkg/AcpiPlatformDxe: Add back log and fix code cohesion

2023-01-04 Thread Min Xu

From: Min M Xu 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4237

Commit 9fdc70af6ba8 breaks log analysis and code cohesion in
AcpiPlatformDxe. See the detailed information in BZ#4237.

There are below changes in this patch:
1) Add back debug log
2) Add error checking and handling if InstallProtocolInterface failed.
3) Delete the QemuAcpiTableNotify.h because it is superfluous.
4) Delete the global variable "mQemuAcpiHandle" instead of a local
   variable.
5) Install the QEMU_ACPI_TABLE_NOTIFY_PROTOCOL with a NULL associated
   interface.

Above changes 2/4/5 are applied in both CloudHvAcpi.c and QemuFwCfgAcpi.c.

Cc: Laszlo Ersek 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Tom Lendacky 
Cc: Sebastien Boeuf 
Reported-by: Laszlo Ersek 
Signed-off-by: Min Xu 
---
 OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c | 25 +--
 OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c   | 42 +--
 .../Include/Protocol/QemuAcpiTableNotify.h| 27 
 3 files changed, 42 insertions(+), 52 deletions(-)
 delete mode 100644 OvmfPkg/Include/Protocol/QemuAcpiTableNotify.h

diff --git a/OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c 
b/OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c
index cbe8bb9b0c75..81f387438a64 100644
--- a/OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c
+++ b/OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c
@@ -18,13 +18,9 @@
 
 #include 
 #include 
-#include  // 
QEMU_ACPI_TABLE_NOTIFY_PROTOCOL
 
 #include "AcpiPlatform.h"
 
-EFI_HANDLE   mChAcpiHandle = NULL;
-QEMU_ACPI_TABLE_NOTIFY_PROTOCOL  mChAcpiNotifyProtocol;
-
 EFI_STATUS
 EFIAPI
 InstallCloudHvTablesTdx (
@@ -33,13 +29,15 @@ InstallCloudHvTablesTdx (
 {
   EFI_STATUS  Status;
   UINTN   TableHandle;
+  EFI_HANDLE  ChAcpiHandle;
 
   EFI_PEI_HOB_POINTERS Hob;
   EFI_ACPI_DESCRIPTION_HEADER  *CurrentTable;
   EFI_ACPI_DESCRIPTION_HEADER  *DsdtTable;
 
-  DsdtTable   = NULL;
-  TableHandle = 0;
+  DsdtTable= NULL;
+  TableHandle  = 0;
+  ChAcpiHandle = NULL;
 
   Hob.Guid = (EFI_HOB_GUID_TYPE *)GetFirstGuidHob 
();
 
@@ -92,12 +90,15 @@ InstallCloudHvTablesTdx (
   // Install a protocol to notify that the ACPI table provided by CH is
   // ready.
   //
-  gBS->InstallProtocolInterface (
- ,
- ,
- EFI_NATIVE_INTERFACE,
- 
- );
+  Status = gBS->InstallProtocolInterface (
+  ,
+  ,
+  EFI_NATIVE_INTERFACE,
+  NULL
+  );
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
 
   return EFI_SUCCESS;
 }
diff --git a/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c 
b/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
index c8dee17c13e6..22340b13e3ee 100644
--- a/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
+++ b/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
@@ -19,10 +19,7 @@
 #include// QemuFwCfgS3Enabled()
 #include  // gBS
 
-#include 
 #include "AcpiPlatform.h"
-EFI_HANDLE   mQemuAcpiHandle = NULL;
-QEMU_ACPI_TABLE_NOTIFY_PROTOCOL  mAcpiNotifyProtocol;
 
 //
 // The user structure for the ordered collection that will track the fw_cfg
@@ -1103,6 +1100,9 @@ InstallQemuFwCfgTables (
   ORDERED_COLLECTION_ENTRY  *TrackerEntry, *TrackerEntry2;
   ORDERED_COLLECTION*SeenPointers;
   ORDERED_COLLECTION_ENTRY  *SeenPointerEntry, *SeenPointerEntry2;
+  EFI_HANDLEQemuAcpiHandle;
+
+  QemuAcpiHandle = NULL;
 
   Status = QemuFwCfgFindFile ("etc/table-loader", , );
   if (EFI_ERROR (Status)) {
@@ -1249,6 +1249,20 @@ InstallQemuFwCfgTables (
 }
   }
 
+  //
+  // Install a protocol to notify that the ACPI table provided by Qemu is
+  // ready.
+  //
+  Status = gBS->InstallProtocolInterface (
+  ,
+  ,
+  EFI_NATIVE_INTERFACE,
+  NULL
+  );
+  if (EFI_ERROR (Status)) {
+goto UninstallAcpiTables;
+  }
+
   //
   // Translating the condensed QEMU_LOADER_WRITE_POINTER commands to ACPI S3
   // Boot Script opcodes has to be the last operation in this function, because
@@ -1275,17 +1289,19 @@ UninstallAcpiTables:
   --Installed;
   AcpiProtocol->UninstallAcpiTable (AcpiProtocol, InstalledKey[Installed]);
 }
+
+//
+// Uninstall the notification if it has been installed.
+//
+if (QemuAcpiHandle != NULL) {
+  gBS->UninstallProtocolInterface (
+ QemuAcpiHandle,
+ ,
+ NULL
+ );
+}
   } else {
-//
-// Install a protocol to notify that the ACPI table provided by Qemu is
-// ready.
-//
-gBS->InstallProtocolInterface (
-   ,
-   ,
-   EFI_NATIVE_INTERFACE,
-   
-   );
+DEBUG ((DEBUG_INFO, "%a: installed %d tables\n", __FUNCTION__, Installed));
   }
 
   for (SeenPointerEntry = OrderedCollectionMin (SeenPointers);
diff --git a/OvmfPkg/Include/Protocol/QemuAcpiTableNotify.h 
b/OvmfPkg/Include/Protocol/QemuAcpiTableNotify.h

[edk2-devel] [PATCH] FatPkg/EnhancedFatDxe: Fix various Coverity issues

2023-01-04 Thread Ranbir Singh via groups.io

The functions FatGetDirEntInfo and FatOpenDirEnt in the file
FatPkg/EnhancedFatDxe/DirectoryManage.c contains the code statements

Cluster            = (Entry->FileClusterHigh << 16) | Entry->FileCluster;
and
OFile->FileCluster = ((DirEnt->Entry.FileClusterHigh) << 16) | 
(DirEnt->Entry.FileCluster);

respectively. In both these statements, there is an "Operand1" with
type "UINT16" (16 bits, unsigned) which is promoted in the operation
"(Operand1 << 16) | Operand2" to type "int" (32 bits, signed), then
sign-extended to type "unsigned long long" (64 bits, unsigned). If the
result of "(Operand1 << 16) | Operand2" is greater than 0x7FFF,
the upper bits of the result will all be 1. So to avoid sign-extension,
typecast "Operand1" with UINTN which is the data type of the variable
on the LHS of the assignment.

The function FatInitializeDiskCache in the file
FatPkg/EnhancedFatDxe/DiskCache.c evaluates an expression

FAT_DATACACHE_GROUP_COUNT << DiskCache[CacheData].PageAlignment
and
assigns it to DataCacheSize which is of type UINTN;

As per Coverity report,
FAT_DATACACHE_GROUP_COUNT << DiskCache[CacheData].PageAlignment is a
potentially overflowing expression with type "int" (32 bits, signed)
evaluated using 32-bit arithmetic, and then used in a context that
expects an expression of type "UINTN" (64 bits, unsigned).
To avoid overflow, cast "FAT_DATACACHE_GROUP_COUNT" to type "UINTN".

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4249
Signed-off-by: Ranbir Singh 
---
FatPkg/EnhancedFatDxe/DirectoryManage.c | 4 ++--
FatPkg/EnhancedFatDxe/DiskCache.c       | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/FatPkg/EnhancedFatDxe/DirectoryManage.c 
b/FatPkg/EnhancedFatDxe/DirectoryManage.c
index 723fc35f38..cdae864be0 100644
--- a/FatPkg/EnhancedFatDxe/DirectoryManage.c
+++ b/FatPkg/EnhancedFatDxe/DirectoryManage.c
@@ -474,7 +474,7 @@ FatGetDirEntInfo (
Info       = Buffer;
Info->Size = ResultSize;
if ((Entry->Attributes & FAT_ATTRIBUTE_DIRECTORY) != 0) {
-      Cluster            = (Entry->FileClusterHigh << 16) | Entry->FileCluster;
+      Cluster            = ((UINTN)(Entry->FileClusterHigh) << 16) | 
(UINTN)Entry->FileCluster;
Info->PhysicalSize = FatPhysicalDirSize (Volume, Cluster);
Info->FileSize     = Info->PhysicalSize;
} else {
@@ -1167,7 +1167,7 @@ FatOpenDirEnt (
//
Volume             = Parent->Volume;
OFile->FullPathLen = Parent->FullPathLen + 1 + StrLen (DirEnt->FileString);
-      OFile->FileCluster = ((DirEnt->Entry.FileClusterHigh) << 16) | 
(DirEnt->Entry.FileCluster);
+      OFile->FileCluster = ((UINTN)(DirEnt->Entry.FileClusterHigh) << 16) | 
(DirEnt->Entry.FileCluster);
InsertTailList (>ChildHead, >ChildLink);
} else {
//
diff --git a/FatPkg/EnhancedFatDxe/DiskCache.c 
b/FatPkg/EnhancedFatDxe/DiskCache.c
index d1a34a6a64..d56e338586 100644
--- a/FatPkg/EnhancedFatDxe/DiskCache.c
+++ b/FatPkg/EnhancedFatDxe/DiskCache.c
@@ -477,7 +477,7 @@ FatInitializeDiskCache (
DiskCache[CacheFat].BaseAddress   = Volume->FatPos;
DiskCache[CacheFat].LimitAddress  = Volume->FatPos + Volume->FatSize;
FatCacheSize                      = FatCacheGroupCount << 
DiskCache[CacheFat].PageAlignment;
-  DataCacheSize                     = FAT_DATACACHE_GROUP_COUNT << 
DiskCache[CacheData].PageAlignment;
+  DataCacheSize                     = (UINTN)FAT_DATACACHE_GROUP_COUNT << 
DiskCache[CacheData].PageAlignment;
//
// Allocate the Fat Cache buffer
//
--
2.36.1.windows.1


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

Re: [edk2-devel] [PATCH 1/1] Maintainers.txt: designate Gerd Hoffmann as UefiCpuPkg reviewer

2023-01-04 Thread Ni, Ray

Reviewed-by: Ray Ni 

> -Original Message-
> From: Laszlo Ersek 
> Sent: Wednesday, January 4, 2023 12:06 AM
> To: devel@edk2.groups.io
> Cc: Andrew Fish ; Dong, Eric ; Gerd 
> Hoffmann ; Leif
> Lindholm ; Kinney, Michael D 
> ; Kumar, Rahul R
> ; Ni, Ray 
> Subject: [PATCH 1/1] Maintainers.txt: designate Gerd Hoffmann as UefiCpuPkg 
> reviewer
> 
> I suggest that Gerd be notified about all UefiCpuPkg patches, so he may
> take a quick look at, or (by his preference) even test, the proposed
> change, in a genuine QEMU/KVM environment.
> 
> Assuming this patch is accepted -- subsequently, please *wait* for Gerd's
> approval on UefiCpuPkg patches, before merging them.
> 
> Notes:
> 
> - It's perfectly fine for a reviewer to give an A-b just so the review
>   process be unblocked, if they don't have anything to add, or don't have
>   time to review or test in detail. The point is that someone outside of
>   Intel should *consistently get a chance* to raise concerns about
>   UefiCpuPkg patches before they are merged.
> 
> - My A-b's and R-b's on UefiCpuPkg patches were never supposed to be
>   "sufficient", only "necessary", for merging. The intent is the same
>   here, with Gerd's designation as a reviewer.
> 
> Cc: Andrew Fish 
> Cc: Eric Dong 
> Cc: Gerd Hoffmann 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Cc: Rahul Kumar 
> Cc: Ray Ni 
> Signed-off-by: Laszlo Ersek 
> ---
>  Maintainers.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 13e1335a57dd..3399981bbae7 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -605,6 +605,7 @@ W: 
> https://github.com/tianocore/tianocore.github.io/wiki/UefiCpuPkg
>  M: Eric Dong  [ydong10]
>  M: Ray Ni  [niruiyu]
>  R: Rahul Kumar  [rahul1-kumar]
> +R: Gerd Hoffmann  [kraxel]
> 
>  UefiCpuPkg: Sec related modules
>  F: UefiCpuPkg/SecCore/


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

[edk2-devel] Event: TianoCore edk2-test Bug Triage Meeting - Thursday, January 5, 2023 #cal-reminder

2023-01-04 Thread Group Notification

*Reminder: TianoCore edk2-test Bug Triage Meeting*

*When:*
Thursday, January 5, 2023
10:00pm to 11:00pm
(UTC+08:00) Asia/Shanghai

*Where:*
https://armltd.zoom.us/j/91247522013?pwd=ei9nUndTbG9oWEROS2M1aVREZkpiQT09=addon

*Organizer:* Edhaya Chandran edhaya.chand...@arm.com ( 
edhaya.chand...@arm.com?subject=Re:%20Event:%20TianoCore%20edk2-test%20Bug%20Triage%20Meeting
 )

View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=1650226 )

*Description:*


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

Re: [edk2-devel] 回复: [edk2-devel] 回复: 回复: [edk2-devel] 回复: [edk2-devel] 回复: [edk2-devel] FW: [PATCH] ShellPkg: Displaying SMBIOS Type38 fields in formatted manner

2023-01-04 Thread Prakash K via groups.io

Hi Gaoliming,

I have updated the commit message title with the package name.
After updating the commit message title, CI check failed and it is not related 
to ShellPkg changes.
Kindly help to check it.

Thanks,
Prakash K


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

[edk2-devel] [PATCH V1 1/1] SecurityPkg: Move TdTcg2Dxe from OvmfPkg to SecurityPkg

2023-01-04 Thread Min Xu

From: Min M Xu 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4194

The TdTcg2Dxe lives in the OvmfPkg instead of the SecurityPkg. Having
the TdTcg2Dxe at the same place as Tcg2Dxe will be easier for platforms to
consume.

Definition of PcdCcEventlogAcpiTableLaml and PcdCcEventlogAcpiTableLasa
are also moved from OvmfPkg.dec to SecurityPkg.dec.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Arti Gupta 
Signed-off-by: Min Xu 
---
 OvmfPkg/IntelTdx/IntelTdxX64.dsc| 2 +-
 OvmfPkg/IntelTdx/IntelTdxX64.fdf| 2 +-
 OvmfPkg/OvmfPkg.dec | 6 --
 SecurityPkg/SecurityPkg.dec | 6 ++
 SecurityPkg/SecurityPkg.dsc | 5 +
 .../Tcg}/TdTcg2Dxe/MeasureBootPeCoff.c  | 0
 {OvmfPkg/IntelTdx => SecurityPkg/Tcg}/TdTcg2Dxe/TdTcg2Dxe.c | 0
 .../IntelTdx => SecurityPkg/Tcg}/TdTcg2Dxe/TdTcg2Dxe.inf| 5 ++---
 8 files changed, 15 insertions(+), 11 deletions(-)
 rename {OvmfPkg/IntelTdx => SecurityPkg/Tcg}/TdTcg2Dxe/MeasureBootPeCoff.c 
(100%)
 rename {OvmfPkg/IntelTdx => SecurityPkg/Tcg}/TdTcg2Dxe/TdTcg2Dxe.c (100%)
 rename {OvmfPkg/IntelTdx => SecurityPkg/Tcg}/TdTcg2Dxe/TdTcg2Dxe.inf (93%)

diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
index 6ec64df91871..5bd74639b448 100644
--- a/OvmfPkg/IntelTdx/IntelTdxX64.dsc
+++ b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
@@ -774,7 +774,7 @@
   #
   # Cc Measurement Protocol for Td guest
   #
-  OvmfPkg/IntelTdx/TdTcg2Dxe/TdTcg2Dxe.inf {
+  SecurityPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.inf {
 
   HashLib|SecurityPkg/Library/HashLibTdx/HashLibTdx.inf
   NULL|SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf
diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.fdf b/OvmfPkg/IntelTdx/IntelTdxX64.fdf
index e79ad3e10217..a57bbcee8986 100644
--- a/OvmfPkg/IntelTdx/IntelTdxX64.fdf
+++ b/OvmfPkg/IntelTdx/IntelTdxX64.fdf
@@ -298,7 +298,7 @@ INF  
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
 #
 # EFI_CC_MEASUREMENT_PROTOCOL
 #
-INF OvmfPkg/IntelTdx/TdTcg2Dxe/TdTcg2Dxe.inf
+INF SecurityPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.inf
 
 

 
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 693925a1dc7a..e07546f4a701 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -459,12 +459,6 @@
   #2 - set by GOP Driver.
   gUefiOvmfPkgTokenSpaceGuid.PcdVideoResolutionSource|0|UINT8|0x64
 
-  ## This PCD records LAML field in CC EVENTLOG ACPI table.
-  gUefiOvmfPkgTokenSpaceGuid.PcdCcEventlogAcpiTableLaml|0|UINT32|0x66
-
-  ## This PCD records LASA field in CC EVENTLOG ACPI table.
-  gUefiOvmfPkgTokenSpaceGuid.PcdCcEventlogAcpiTableLasa|0|UINT64|0x67
-
 [PcdsFeatureFlag]
   gUefiOvmfPkgTokenSpaceGuid.PcdQemuBootOrderPciTranslation|TRUE|BOOLEAN|0x1c
   gUefiOvmfPkgTokenSpaceGuid.PcdQemuBootOrderMmioTranslation|FALSE|BOOLEAN|0x1d
diff --git a/SecurityPkg/SecurityPkg.dec b/SecurityPkg/SecurityPkg.dec
index 358b3dc543a1..8257f11d17c7 100644
--- a/SecurityPkg/SecurityPkg.dec
+++ b/SecurityPkg/SecurityPkg.dec
@@ -574,5 +574,11 @@
   # @Prompt Tpm2AcpiTableLasa LASA field in TPM2 ACPI table.
   gEfiSecurityPkgTokenSpaceGuid.PcdTpm2AcpiTableLasa|0|UINT64|0x00010023
 
+  ## This PCD records LAML field in CC EVENTLOG ACPI table.
+  gEfiSecurityPkgTokenSpaceGuid.PcdCcEventlogAcpiTableLaml|0|UINT32|0x00010025
+
+  ## This PCD records LASA field in CC EVENTLOG ACPI table.
+  gEfiSecurityPkgTokenSpaceGuid.PcdCcEventlogAcpiTableLasa|0|UINT64|0x00010026
+
 [UserExtensions.TianoCore."ExtraFiles"]
   SecurityPkgExtra.uni
diff --git a/SecurityPkg/SecurityPkg.dsc b/SecurityPkg/SecurityPkg.dsc
index 2f679c87a92f..3bad5375c01a 100644
--- a/SecurityPkg/SecurityPkg.dsc
+++ b/SecurityPkg/SecurityPkg.dsc
@@ -296,6 +296,11 @@
 [Components.X64]
   SecurityPkg/Library/HashLibTdx/HashLibTdx.inf
   SecurityPkg/Library/SecTpmMeasurementLib/SecTpmMeasurementLibTdx.inf
+  SecurityPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.inf {
+
+  HashLib|SecurityPkg/Library/HashLibTdx/HashLibTdx.inf
+  NULL|SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf
+  }
 
 [Components.IA32, Components.X64]
   SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
diff --git a/OvmfPkg/IntelTdx/TdTcg2Dxe/MeasureBootPeCoff.c 
b/SecurityPkg/Tcg/TdTcg2Dxe/MeasureBootPeCoff.c
similarity index 100%
rename from OvmfPkg/IntelTdx/TdTcg2Dxe/MeasureBootPeCoff.c
rename to SecurityPkg/Tcg/TdTcg2Dxe/MeasureBootPeCoff.c
diff --git a/OvmfPkg/IntelTdx/TdTcg2Dxe/TdTcg2Dxe.c 
b/SecurityPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.c
similarity index 100%
rename from OvmfPkg/IntelTdx/TdTcg2Dxe/TdTcg2Dxe.c
rename to SecurityPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.c
diff --git a/OvmfPkg/IntelTdx/TdTcg2Dxe/TdTcg2Dxe.inf 
b/SecurityPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.inf
similarity index 93%
rename from OvmfPkg/IntelTdx/TdTcg2Dxe/TdTcg2Dxe.inf
rename to

Re: [edk2-devel] [PATCH v3 03/16] ArmVirtPkg: make EFI_LOADER_DATA non-executable

2023-01-04 Thread Alexander Graf




On 04.01.23 10:35, Ard Biesheuvel wrote:

On Tue, 3 Jan 2023 at 23:47, dann frazier  wrote:

On Tue, Jan 03, 2023 at 08:39:24PM +0100, Alexander Graf wrote:

Hey Ard,

On 03.01.23 10:59, Ard Biesheuvel wrote:

On Thu, 29 Dec 2022 at 19:00, dann frazier  wrote:

On Mon, Nov 28, 2022 at 04:46:10PM +0100, Gerd Hoffmann wrote:

On Mon, Sep 26, 2022 at 10:24:58AM +0200, Ard Biesheuvel wrote:

When the memory protections were implemented and enabled on ArmVirtQemu
5+ years ago, we had to work around the fact that GRUB at the time
expected EFI_LOADER_DATA to be executable, as that is the memory type it
allocates when loading its modules.

This has been fixed in GRUB in August 2017, so by now, we should be able
to tighten this, and remove execute permissions from EFI_LOADER_DATA
allocations.

Data point: https://bugzilla.redhat.com/show_bug.cgi?id=2149020
tl;dr: fedora 37 grub.efi is still broken.

This is also the case with existing Ubuntu releases, as well as
AlmaLinux 9.1 and RHEL 8.7[*]. While it does appear to be fixed for
the upcoming Ubuntu 23.04 (presumably via [**]), I plan to revert this
patch in Debian/Ubuntu until it is more ubiquitous. Do you want to do
the same upstream? I'm not sure at what point it would make sense to
reintroduce it, given we can't force users to upgrade their bootloaders.


Thanks for the report.

You can override PCDs on the build command line, so I suggest you use
that for building these images as long as it is needed.

E.g,, append this to the build.sh command line

--pcd PcdDxeNxMemoryProtectionPolicy=0xC0007FD1

to undo the effects of this patch.

I do not intend to revert this patch - the trend under EFI is towards
much stricter memory permissions, also on the MS side, and this is
especially important under CC scenarios. And if 5+ years is not
sufficient for out-of-tree GRUB to catch up, what is the point of
waiting for it?


I think we need to be smarter here. ArmVirtPkg is used by a lot of
virtualization software - such as QEMU. Typically, users (and developers)
expect that an update to a newer version will preserve compatibility.

Let me contrive an example: In 1 year, QEMU updates to the latest AAVMF. It
ships that as part of its pc-bios directory. Suddenly, we accidentally break
old (immutable!) iso images that used to work. So someone that updates QEMU
to a newer version will have a regression in running a Fedora 37
installation. Or RHEL 8.7 installation. Not good :).

Outside of OSVs providing new iso images, there is also not much you can do
about this. The grub binary here runs way before any updater code that could
pull a fixed version from the internet.

What alternatives do we have? Assuming grub is the only offender we have to
worry about, is there a way we can identify that the allocation came from an
unpatched version? Or have a database of hashes (with all known grub
binaries that have this bug in existing isos) that would force disable NX
protection for it if we hit it? Or disable NX when Secure Boot is disabled?

I really think we need to be a bit more creative than make NX mandatory in
all cases when we know the are immutable images out there that won't work
with it, otherwise we break very legit use cases.

While it has its own issues, I suppose another way to go about it is
for distributors to provide multiple AAVMF_CODE images, and perhaps
invent a "feature" flag for the json descriptor for management tools
to select an appropriate one.


I don't think having different versions of the image makes sense, tbh,
but of course, this is up to the distros.

Compatibility with ancient downstream GRUB builds is not a goal of the
EDK2 upstream, so as long as distros can tweak the build to their
needs, I don't see a reason to revert this change upstream.



First of all, I don't think we should revert this change. We should 
augment it to give users the out-of-the-box experience they expect.


On top of that, I don't think it's a problem of "distros". Every 
consumer of AAVMF will run into this problem as soon as their users will 
want to run any Red Hat OS (installer / image) all the way into 2022. 
That's  very likely >90% of the user base. Because of that, I'm pretty 
sure no Cloud vendor will be able to enable NX in its current shape for 
example.


I'm very happy to see NX proliferate through the stack, but let's please 
make sure we do it compatibly by default, otherwise the net result is 
that *everyone* who compiles AAVMF will disable NX by default again - 
and all you end up with is more frustration and more downstream code / 
forks.


IMHO the most obvious approach would be a fingerprint based override. 
There should be a finite number of known broken grub binaries. If we 
just maintain a database with them and then apply some magic when we 
detect such a binary gets loaded, we'll have tightened security by 
default, without breaking backwards compat.


For environments that know they're running in environments with CC 
requirements, we can

Re: [edk2-devel] [PATCH v3 03/16] ArmVirtPkg: make EFI_LOADER_DATA non-executable

2023-01-04 Thread Gerd Hoffmann

On Wed, Jan 04, 2023 at 01:04:41PM +0100, Ard Biesheuvel wrote:
> On Wed, 4 Jan 2023 at 12:11, Gerd Hoffmann  wrote:
> >
> >   Hi,
> >
> > > > > > --pcd PcdDxeNxMemoryProtectionPolicy=0xC0007FD1
> >
> > Can this also be flipped at runtime?
> 
> Currently, it is fixed or patchable, which means that you can override
> it at build time only. I don't think making this a dynamic PCD would
> be difficult, and on QEMU, we can set the value early enough if we key
> it off fw_cfg or something like that.
> 
> But that implies that you need a 'permissive' mode to invoke QEMU,
> which ends up being always enabled, most likely, so I'm not sure this
> is an improvement.

It works both ways.  Being able to enable nx protection at runtime on
builds which have it disabled by default would be quite useful.  Write
test cases.  Write reproducer instructions which don't include building
edk2 yourself.

take care,
  Gerd



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

Re: [edk2-devel] [PATCH 0/4] fixes for BZs 3876, 4235, 4236

2023-01-04 Thread Laszlo Ersek

On 1/4/23 10:46, Ard Biesheuvel wrote:
> On Tue, 3 Jan 2023 at 16:03, Laszlo Ersek  wrote:
>>
>> Repo:   https://pagure.io/lersek/edk2.git
>> Branch: smorgasboard
>>
>> Round-up series of small patches, for the BZs noted in the subject.
>>
>> Successful test build: .
>>
>> Regarding runtime testing: notes have been captured in the commit
>> messages. For testing, I first reverted 7bda8c648192^..3f378450dfaf, due
>> to BZ 4234.
>>
>> Cc: Anthony Perard 
>> Cc: Ard Biesheuvel 
>> Cc: Brijesh Singh 
>> Cc: Erdem Aktas 
>> Cc: Eric Dong 
>> Cc: Gerd Hoffmann 
>> Cc: James Bottomley 
>> Cc: Jiewen Yao 
>> Cc: Jordan Justen 
>> Cc: Julien Grall 
>> Cc: Min Xu 
>> Cc: Peter Grehan 
>> Cc: Rahul Kumar 
>> Cc: Ray Ni 
>> Cc: Rebecca Cran 
>> Cc: Sebastien Boeuf 
>> Cc: Tom Lendacky 
>>
>> Laszlo Ersek (4):
>>   OvmfPkg/QemuVideoDxe/VbeShim.sh: remove end-of-options delimiter for
>> nasm
>>   OvmfPkg: raise DXEFV size to 13 MB in the traditional platform FDFs
>>   UefiCpuPkg/SmmCpuFeaturesLib: drop obsolete API implementation
>>   OvmfPkg/SmmCpuFeaturesLib: drop obsolete API implementation
>>
> 
> Merged as #3852 - thanks for the fixes
> 

Thank you for the quick merge!
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#97935): https://edk2.groups.io/g/devel/message/97935
Mute This Topic: https://groups.io/mt/96029298/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 03/16] ArmVirtPkg: make EFI_LOADER_DATA non-executable

2023-01-04 Thread Ard Biesheuvel

On Wed, 4 Jan 2023 at 12:11, Gerd Hoffmann  wrote:
>
>   Hi,
>
> > > > > You can override PCDs on the build command line, so I suggest you use
> > > > > that for building these images as long as it is needed.
> > > > >
> > > > > E.g,, append this to the build.sh command line
> > > > >
> > > > > --pcd PcdDxeNxMemoryProtectionPolicy=0xC0007FD1
> > > > >
> > > > > to undo the effects of this patch.
>
> Can this also be flipped at runtime?

Currently, it is fixed or patchable, which means that you can override
it at build time only. I don't think making this a dynamic PCD would
be difficult, and on QEMU, we can set the value early enough if we key
it off fw_cfg or something like that.

But that implies that you need a 'permissive' mode to invoke QEMU,
which ends up being always enabled, most likely, so I'm not sure this
is an improvement.

> Does this pcd work the same way on all architectures?
>

In principle, yes. However, I cannot vouch for the X86 code not doing
dodgy things with data regions, so whether the same *value* works
reliably across all architectures is a separate matter.

> > I don't think having different versions of the image makes sense, tbh,
> > but of course, this is up to the distros.
>
> Fedora has reverted the patch for now, and I don't see how we can enable
> that anytime soon given that RHEL-8,9 with loong support times ship
> broken grub binaries today.
>

Yeah. This is really disappointing.

> > Compatibility with ancient downstream GRUB builds is not a goal of the
> > EDK2 upstream, so as long as distros can tweak the build to their
> > needs, I don't see a reason to revert this change upstream.
>
> The versions are not that ancient.  The problem is more that upstream
> grub is really slow on integrating patches so every distro does carry
> a huge pile of downstream patches.  And they seem to re-introduce the
> bug ...
>
> But, yes, just reverting upstream too doesn't look like a good option
> either, we need at least a little pressure to get things fixed.
>

Indeed.


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

Re: [edk2-devel] [PATCH 1/1] Maintainers.txt: designate Gerd Hoffmann as UefiCpuPkg reviewer

2023-01-04 Thread Gerd Hoffmann

On Tue, Jan 03, 2023 at 05:05:39PM +0100, Laszlo Ersek wrote:
> I suggest that Gerd be notified about all UefiCpuPkg patches, so he may
> take a quick look at, or (by his preference) even test, the proposed
> change, in a genuine QEMU/KVM environment.
> 
> Assuming this patch is accepted -- subsequently, please *wait* for Gerd's
> approval on UefiCpuPkg patches, before merging them.
> 
> Notes:
> 
> - It's perfectly fine for a reviewer to give an A-b just so the review
>   process be unblocked, if they don't have anything to add, or don't have
>   time to review or test in detail. The point is that someone outside of
>   Intel should *consistently get a chance* to raise concerns about
>   UefiCpuPkg patches before they are merged.
> 
> - My A-b's and R-b's on UefiCpuPkg patches were never supposed to be
>   "sufficient", only "necessary", for merging. The intent is the same
>   here, with Gerd's designation as a reviewer.
> 
> Cc: Andrew Fish 
> Cc: Eric Dong 
> Cc: Gerd Hoffmann 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Cc: Rahul Kumar 
> Cc: Ray Ni 
> Signed-off-by: Laszlo Ersek 

Acked-by: Gerd Hoffmann 

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#97933): https://edk2.groups.io/g/devel/message/97933
Mute This Topic: https://groups.io/mt/96030658/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 03/16] ArmVirtPkg: make EFI_LOADER_DATA non-executable

2023-01-04 Thread Gerd Hoffmann

  Hi,

> > > > You can override PCDs on the build command line, so I suggest you use
> > > > that for building these images as long as it is needed.
> > > >
> > > > E.g,, append this to the build.sh command line
> > > >
> > > > --pcd PcdDxeNxMemoryProtectionPolicy=0xC0007FD1
> > > >
> > > > to undo the effects of this patch.

Can this also be flipped at runtime?
Does this pcd work the same way on all architectures?

> I don't think having different versions of the image makes sense, tbh,
> but of course, this is up to the distros.

Fedora has reverted the patch for now, and I don't see how we can enable
that anytime soon given that RHEL-8,9 with loong support times ship
broken grub binaries today.

> Compatibility with ancient downstream GRUB builds is not a goal of the
> EDK2 upstream, so as long as distros can tweak the build to their
> needs, I don't see a reason to revert this change upstream.

The versions are not that ancient.  The problem is more that upstream
grub is really slow on integrating patches so every distro does carry
a huge pile of downstream patches.  And they seem to re-introduce the
bug ...

But, yes, just reverting upstream too doesn't look like a good option
either, we need at least a little pressure to get things fixed.

take care,
  Gerd



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

[edk2-devel] [PATCH] SecurityPkg/Tcg/Tcg2Config: Fix REVERSE_INULL Coverity issue

2023-01-04 Thread Ranbir Singh via groups.io

The function Tcg2ConfigDriverEntryPoint at the point of creating a
private data structure makes a call to AllocateCopyPool and stores
the return value in PrivateData. Thereafter it does a check

ASSERT (PrivateData != NULL);

but this is applicable only in DEBUG mode. In Release mode, the code
continues further and will dereference "PrivateData" which will lead
to CRASH if PrivateData is NULL.

Hence, for safety add PrivateData NULL pointer check and return from
there saying EFI_OUT_OF_RESOURCES when PrivateData is NULL.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4229
Signed-off-by: Ranbir Singh 
---
SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c | 4 
1 file changed, 4 insertions(+)

diff --git a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c 
b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
index edf5f0fc77..f023b3ccb8 100644
--- a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
+++ b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
@@ -283,6 +283,10 @@ Tcg2ConfigDriverEntryPoint (
//
PrivateData = AllocateCopyPool (sizeof (TCG2_CONFIG_PRIVATE_DATA), 
);
ASSERT (PrivateData != NULL);
+  if (PrivateData == NULL) {
+    return EFI_OUT_OF_RESOURCES;
+  }
+
mTcg2ConfigPrivateDate = PrivateData;
//
// Install private GUID.
--
2.36.1.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#97931): https://edk2.groups.io/g/devel/message/97931
Mute This Topic: https://groups.io/mt/96047753/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 13/14] ArmPkg: Turn off spellcheck audit mode

2023-01-04 Thread Ard Biesheuvel

On Thu, 15 Dec 2022 at 17:38, Michael Kubacki
 wrote:
>
> On 12/15/2022 5:42 AM, Leif Lindholm wrote:
> > On Wed, Dec 14, 2022 at 19:04:06 -0500, Michael Kubacki wrote:
> >> I'm just trying to understand your position.
> >>
> >> Are you saying you would rather people check in typos and then later have
> >> patches come into the package to fix them?
> >>
> >> For example, like these:
> >>
> >> - ArmVirtPkg: https://edk2.groups.io/g/devel/message/97021
> >> - ArmPkg: https://edk2.groups.io/g/devel/message/97022
> >>
> >> Why not just have the code checked in without typos in the first place?
> >
> > A little fairy once whispered in my ear that if I stopped myself and
> > tried to rephrase whenever I found myself using the work "just", I
> > would meet less friction in context-stripping communication mediums
> > such as email. They weren't wrong.
> >
>
> This topic is met with friction regardless of how it is phrased.
>
> The friction exists because the community chose to enable spell checking
> in CI and it is not wanted here.
>
> The mechanism chosen to ignore words was through YAML files rather than
> a button. A common YAML file can store words for the whole project and
> packages can add package-specific words. The community was expected to
> make the contributions necessary in the common file to minimize impact
> on package maintainers.
>
> The spellcheck log outputs the exact code that needs to be copied/pasted
> to the exception list - whether the global list or package list. If you
> run CI locally, you can copy/paste the exact lines needed.
>
> This is a patch series I work on in my spare time to try to improve the
> project. I am tired of Ard's dismissive and passive aggressive responses
> such as those in https://edk2.groups.io/g/devel/message/97433 so I
> revoke the series and will let others decide what they want to do.
>

I don't think this is a fair characterization of my response. I
explained in detail why I think rigid spellcheck rules are
counter-productive and do not contribute to the quality of what gets
deployed to devices.

Nevertheless, I apologize if my frustration with the recent CI changes
managed to seep through, although I should also mention that I am a
big fan of the pre-merge build and boot tests, as they have been a
huge help in my workflow. Only the rigid enforcement of standards that
are purely cosmetic is what bothers me, especially because finding the
error messages (and suggestions for improvement) in the complex UI is
not as straight-forward as it is made out to be.

That said, it would be helpful if you could respond to the actual
points I made, rather than dismissing them wholesale as a
passive-aggressive and hostile response. You have presented your
contribution as a take-it-or-leave-it style change, rather than
engaging with Leif and me as the package maintainers to converge on
something that we can all agree on.

You may have also missed my question/invitation regarding
collaboration on IBT/BTI enablement in UEFI.

Kind regards,
Ard.

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

[edk2-devel] [PATCH] UefiCpuPkg/Universal/Acpi/S3Resume2Pei: Fix FORWARD_NULL Coverity issue

2023-01-04 Thread Ranbir Singh via groups.io

The function S3ResumeExecuteBootScript at the point of preparing data
for return back makes a call to AllocatePool and stores the return
value in PeiS3ResumeState. Thereafter it does a check

if (PeiS3ResumeState == NULL) {

The if block further has ASSERT (FALSE); If PeiS3ResumeState is NULL,
then the if check passes and ASSERT hits, but this is applicable only
in DEBUG mode. In Release mode, the code comes out of this if block
and will dereference "PeiS3ResumeState" which will lead to CRASH.

Hence, for safety do not let the flow come out of the above if block.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4227
Signed-off-by: Ranbir Singh 
---
UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c | 5 +
1 file changed, 5 insertions(+)

diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c 
b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
index e82f179569..b6b2e1f99c 100644
--- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
+++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
@@ -884,6 +884,11 @@ S3ResumeExecuteBootScript (
(EFI_SOFTWARE_PEI_MODULE | EFI_SW_PEI_EC_S3_RESUME_FAILED)
);
ASSERT (FALSE);
+    //
+    // Never run to here
+    //
+    CpuDeadLoop ();
+    return;
}

DEBUG ((DEBUG_INFO, "PeiS3ResumeState - %x\r\n", PeiS3ResumeState));
--
2.36.1.windows.1


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

Re: [edk2-devel] [PATCH 0/4] fixes for BZs 3876, 4235, 4236

2023-01-04 Thread Ard Biesheuvel

On Tue, 3 Jan 2023 at 16:03, Laszlo Ersek  wrote:
>
> Repo:   https://pagure.io/lersek/edk2.git
> Branch: smorgasboard
>
> Round-up series of small patches, for the BZs noted in the subject.
>
> Successful test build: .
>
> Regarding runtime testing: notes have been captured in the commit
> messages. For testing, I first reverted 7bda8c648192^..3f378450dfaf, due
> to BZ 4234.
>
> Cc: Anthony Perard 
> Cc: Ard Biesheuvel 
> Cc: Brijesh Singh 
> Cc: Erdem Aktas 
> Cc: Eric Dong 
> Cc: Gerd Hoffmann 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Jordan Justen 
> Cc: Julien Grall 
> Cc: Min Xu 
> Cc: Peter Grehan 
> Cc: Rahul Kumar 
> Cc: Ray Ni 
> Cc: Rebecca Cran 
> Cc: Sebastien Boeuf 
> Cc: Tom Lendacky 
>
> Laszlo Ersek (4):
>   OvmfPkg/QemuVideoDxe/VbeShim.sh: remove end-of-options delimiter for
> nasm
>   OvmfPkg: raise DXEFV size to 13 MB in the traditional platform FDFs
>   UefiCpuPkg/SmmCpuFeaturesLib: drop obsolete API implementation
>   OvmfPkg/SmmCpuFeaturesLib: drop obsolete API implementation
>

Merged as #3852 - thanks for the fixes


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#97928): https://edk2.groups.io/g/devel/message/97928
Mute This Topic: https://groups.io/mt/96029298/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 03/16] ArmVirtPkg: make EFI_LOADER_DATA non-executable

2023-01-04 Thread Ard Biesheuvel

On Tue, 3 Jan 2023 at 23:47, dann frazier  wrote:
>
> On Tue, Jan 03, 2023 at 08:39:24PM +0100, Alexander Graf wrote:
> > Hey Ard,
> >
> > On 03.01.23 10:59, Ard Biesheuvel wrote:
> > > On Thu, 29 Dec 2022 at 19:00, dann frazier  
> > > wrote:
> > > > On Mon, Nov 28, 2022 at 04:46:10PM +0100, Gerd Hoffmann wrote:
> > > > > On Mon, Sep 26, 2022 at 10:24:58AM +0200, Ard Biesheuvel wrote:
> > > > > > When the memory protections were implemented and enabled on 
> > > > > > ArmVirtQemu
> > > > > > 5+ years ago, we had to work around the fact that GRUB at the time
> > > > > > expected EFI_LOADER_DATA to be executable, as that is the memory 
> > > > > > type it
> > > > > > allocates when loading its modules.
> > > > > >
> > > > > > This has been fixed in GRUB in August 2017, so by now, we should be 
> > > > > > able
> > > > > > to tighten this, and remove execute permissions from EFI_LOADER_DATA
> > > > > > allocations.
> > > > > Data point: https://bugzilla.redhat.com/show_bug.cgi?id=2149020
> > > > > tl;dr: fedora 37 grub.efi is still broken.
> > > > This is also the case with existing Ubuntu releases, as well as
> > > > AlmaLinux 9.1 and RHEL 8.7[*]. While it does appear to be fixed for
> > > > the upcoming Ubuntu 23.04 (presumably via [**]), I plan to revert this
> > > > patch in Debian/Ubuntu until it is more ubiquitous. Do you want to do
> > > > the same upstream? I'm not sure at what point it would make sense to
> > > > reintroduce it, given we can't force users to upgrade their bootloaders.
> > > >
> > > Thanks for the report.
> > >
> > > You can override PCDs on the build command line, so I suggest you use
> > > that for building these images as long as it is needed.
> > >
> > > E.g,, append this to the build.sh command line
> > >
> > > --pcd PcdDxeNxMemoryProtectionPolicy=0xC0007FD1
> > >
> > > to undo the effects of this patch.
> > >
> > > I do not intend to revert this patch - the trend under EFI is towards
> > > much stricter memory permissions, also on the MS side, and this is
> > > especially important under CC scenarios. And if 5+ years is not
> > > sufficient for out-of-tree GRUB to catch up, what is the point of
> > > waiting for it?
> >
> >
> > I think we need to be smarter here. ArmVirtPkg is used by a lot of
> > virtualization software - such as QEMU. Typically, users (and developers)
> > expect that an update to a newer version will preserve compatibility.
> >
> > Let me contrive an example: In 1 year, QEMU updates to the latest AAVMF. It
> > ships that as part of its pc-bios directory. Suddenly, we accidentally break
> > old (immutable!) iso images that used to work. So someone that updates QEMU
> > to a newer version will have a regression in running a Fedora 37
> > installation. Or RHEL 8.7 installation. Not good :).
> >
> > Outside of OSVs providing new iso images, there is also not much you can do
> > about this. The grub binary here runs way before any updater code that could
> > pull a fixed version from the internet.
> >
> > What alternatives do we have? Assuming grub is the only offender we have to
> > worry about, is there a way we can identify that the allocation came from an
> > unpatched version? Or have a database of hashes (with all known grub
> > binaries that have this bug in existing isos) that would force disable NX
> > protection for it if we hit it? Or disable NX when Secure Boot is disabled?
> >
> > I really think we need to be a bit more creative than make NX mandatory in
> > all cases when we know the are immutable images out there that won't work
> > with it, otherwise we break very legit use cases.
>
> While it has its own issues, I suppose another way to go about it is
> for distributors to provide multiple AAVMF_CODE images, and perhaps
> invent a "feature" flag for the json descriptor for management tools
> to select an appropriate one.
>

I don't think having different versions of the image makes sense, tbh,
but of course, this is up to the distros.

Compatibility with ancient downstream GRUB builds is not a goal of the
EDK2 upstream, so as long as distros can tweak the build to their
needs, I don't see a reason to revert this change upstream.


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

[edk2-devel] [PATCH] SecurityPkg/Library/HashLibBaseCryptoRouter: Fix NULL_RETURNS Coverity issue

2023-01-04 Thread Ranbir Singh via groups.io

In file SecurityPkg/Library/HashLibBaseCryptoRouter/
HashLibBaseCryptoRouterPei.c, the function
CheckSupportedHashMaskMismatch calls InternalGetHashInterfaceHob and
stores return value in HashInterfaceHobLast. Thereafter, it does

ASSERT (HashInterfaceHobLast != NULL);

but this comes into play only in DEBUG mode. In Release mode, the
code continues to proceed to dereferencing "HashInterfaceHobLast"
which will lead to CRASH if HashInterfaceHobLast is NULL.

Hence, for safety add HashInterfaceHobLast NULL pointer check before
accessing further field values.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4225
Signed-off-by: Ranbir Singh 
---
.../HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c       | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c 
b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
index eeb424b6c3..0c8315ed03 100644
--- a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
+++ b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
@@ -108,7 +108,8 @@ CheckSupportedHashMaskMismatch (
HashInterfaceHobLast = InternalGetHashInterfaceHob ();
ASSERT (HashInterfaceHobLast != NULL);

-  if ((HashInterfaceHobLast->SupportedHashMask != 0) &&
+  if ((HashInterfaceHobLast != NULL) &&
+      (HashInterfaceHobLast->SupportedHashMask != 0) &&
(HashInterfaceHobCurrent->SupportedHashMask != 
HashInterfaceHobLast->SupportedHashMask))
{
DEBUG ((
--
2.36.1.windows.1


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

[edk2-devel] [PATCH] NetworkPkg/Dhcp6Dxe: Fix FORWARD_NULL Coverity issue

2023-01-04 Thread Ranbir Singh via groups.io

The function Dhcp6HandleStateful checks

if (Instance->Config == NULL) {
goto ON_CONTINUE;
}

At label ON_CONTINUE, UdpIoRecvDatagram function is called and if for
whatever reasons its return value is not EFI_SUCCESS, then the check
if (EFI_ERROR (Status)) at label ON_EXIT passes leading to invokation
of Dhcp6CleanupSession function in which

ASSERT (Instance->Config);

will get hit in DEBUG mode and in RELEASE mode, the code continues to
dereference Instance->Config in the check

if (Instance->Config->IaInfoEvent != NULL) {

which will lead to CRASH as Instance->Config is NULL.

Hence, for safety add Instance->Config NULL pointer check before
calling Dhcp6CleanupSession.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4223
Signed-off-by: Ranbir Singh 
---
NetworkPkg/Dhcp6Dxe/Dhcp6Io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/NetworkPkg/Dhcp6Dxe/Dhcp6Io.c b/NetworkPkg/Dhcp6Dxe/Dhcp6Io.c
index dcd01e6268..2c924d373f 100644
--- a/NetworkPkg/Dhcp6Dxe/Dhcp6Io.c
+++ b/NetworkPkg/Dhcp6Dxe/Dhcp6Io.c
@@ -2636,7 +2636,7 @@ ON_CONTINUE:
0
);
ON_EXIT:
-  if (EFI_ERROR (Status)) {
+  if (EFI_ERROR (Status) && (Instance->Config != NULL)) {
Dhcp6CleanupSession (Instance, Status);
}
}
--
2.36.1.windows.1


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

[edk2-devel] [PATCH] MdeModulePkg/Bus/Usb/UsbMouseDxe: Fix REVERSE_INULL Coverity issue

2023-01-04 Thread Ranbir Singh via groups.io

The function USBMouseDriverBindingStart do have

ASSERT (UsbMouseDevice != NULL);

after AllocateZeroPool, but it is applicable only in DEBUG mode.
In RELEASE mode, the code proceeds to dereference "UsbMouseDevice"
which will lead to CRASH.

Hence, for safety add NULL pointer checks always. The ASSERT may be
retained or it may be deleted whatever is deemed more appropriate.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4222
Signed-off-by: Ranbir Singh 
---
MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouse.c | 4 
1 file changed, 4 insertions(+)

diff --git a/MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouse.c 
b/MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouse.c
index 451d4b934f..621d09713b 100644
--- a/MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouse.c
+++ b/MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouse.c
@@ -161,6 +161,10 @@ USBMouseDriverBindingStart (

UsbMouseDevice = AllocateZeroPool (sizeof (USB_MOUSE_DEV));
ASSERT (UsbMouseDevice != NULL);
+  if (UsbMouseDevice == NULL) {
+    Status = EFI_OUT_OF_RESOURCES;
+    goto ErrorExit;
+  }

UsbMouseDevice->UsbIo     = UsbIo;
UsbMouseDevice->Signature = USB_MOUSE_DEV_SIGNATURE;
--
2.36.1.windows.1


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

[edk2-devel] [PATCH] MdeModulePkg/Bus/Pci/XhciDxe: Fix FORWARD_NULL Coverity issues

2023-01-04 Thread Ranbir Singh via groups.io

The functions UsbHcGetHostAddrForPciAddr, UsbHcGetPciAddrForHostAddr
and UsbHcFreeMem do have

ASSERT ((Block != NULL));

statements after for loop, but these are applicable only in DEBUG mode.
In RELEASE mode, if for whatever reasons there is no match inside for
loop and the loop exits because of Block != NULL; condition, then there
is no "Block" NULL pointer check afterwards and the code proceeds to do
dereferencing "Block" which will lead to CRASH.

Hence, for safety add NULL pointer checks always.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4221
Signed-off-by: Ranbir Singh 
---
MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c | 11 +++
1 file changed, 11 insertions(+)

diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c
index d0ad1582e4..869ae6ec8a 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c
@@ -261,6 +261,10 @@ UsbHcGetPciAddrForHostAddr (
}

ASSERT ((Block != NULL));
+  if (Block == NULL) {
+    return 0;
+  }
+
//
// calculate the pci memory address for host memory address.
//
@@ -310,6 +314,10 @@ UsbHcGetHostAddrForPciAddr (
}

ASSERT ((Block != NULL));
+  if (Block == NULL) {
+    return 0;
+  }
+
//
// calculate the pci memory address for host memory address.
//
@@ -590,6 +598,9 @@ UsbHcFreeMem (
// the caller has passed in a wrong memory point
//
ASSERT (Block != NULL);
+  if (Block == NULL) {
+    return;
+  }

//
// Release the current memory block if it is empty and not the head
--
2.36.1.windows.1


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

Re: [edk2-devel] [PATCH v1] IntelSiliconPkg: Add FVI_SMBIOS_TYPE definition in FirmwareVersionInfo.h

2023-01-04 Thread Ashraf Ali S

Reviewed-by: S, Ashraf Ali 

-Original Message-
From: Chang, Hunter  
Sent: Wednesday, January 4, 2023 1:17 PM
To: devel@edk2.groups.io
Cc: Chang, Hunter ; Ni, Ray ; 
Chaganty, Rangasai V ; Oram, Isaac W 
; S, Ashraf Ali 
Subject: [PATCH v1] IntelSiliconPkg: Add FVI_SMBIOS_TYPE definition in 
FirmwareVersionInfo.h

From: Hunter Chang 

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

Define a macro for SmbiosFeaturePkg usage which named INTEL_FVI_SMBIOS_TYPE and 
initialized to 0xDD in IndustryStandard/FirmwareVersionInfo.h

Signed-off-by: Hunter Chang 

Cc: Ray Ni 
Cc: Rangasai V Chaganty 
Cc: Isaac Oram 
Cc: Ashraf Ali S 
---
 Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/FirmwareVersionInfo.h | 
1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/FirmwareVersionInfo.h 
b/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/FirmwareVersionInfo.h
index b30bc3f9e7..466cb8e7d2 100644
--- 
a/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/FirmwareVersionInfo.h
+++ b/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/FirmwareVer
+++ sionInfo.h
@@ -18,6 +18,7 @@
 #include   #define 
INTEL_FIRMWARE_VERSION_INFO_GROUP_NAME"Firmware Version Info"+#define 
INTEL_FVI_SMBIOS_TYPE 0xDD  #pragma pack(1) -- 
2.26.2.windows.1



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

54 matches

Mail list logo