Re: [edk2-devel] [PATCH] Fix cyclic dependency error on OptionROM build

[Konstantin Aladyshev]

Thanks, Bob!

Sorry, somehow I've missed it.
Has EDK2 moved to the GitHub PR system instead of a mailing list for patches?
Do I need to open PR for my subsequent patches, or just send them to
the mailing list like before?

Best regards,
Konstatin Aladyshev



On Tue, Jan 17, 2023 at 8:17 AM Feng, Bob C  wrote:
>
> Konstantin,
>
>
>
> The patch missed “Signed-off-by:”, I help you add it and open a PR 
> https://github.com/tianocore/edk2/pull/3909 for merge.
>
>
>
> Thanks,
>
> Bob
>
> From: devel@edk2.groups.io  On Behalf Of Bob Feng
> Sent: Tuesday, January 17, 2023 1:05 PM
> To: Jake Garver ; Konstantin Aladyshev 
> ; devel@edk2.groups.io
> Cc: Gao, Liming ; Chen, Christine 
> 
> Subject: Re: [edk2-devel] [PATCH] Fix cyclic dependency error on OptionROM 
> build
>
>
>
> Reviewed-by: Bob Feng 
>
>
>
> From: Jake Garver 
> Sent: Wednesday, December 14, 2022 2:48 AM
> To: Konstantin Aladyshev ; devel@edk2.groups.io
> Cc: Feng, Bob C ; Gao, Liming 
> ; Chen, Christine 
> Subject: Re: [PATCH] Fix cyclic dependency error on OptionROM build
>
>
>
> Thanks, Konstantin,
>
>
>
> I approve this version.
>
>
>
> Thanks,
>
> Jake
>
> 
>
> From: Konstantin Aladyshev 
> Sent: Tuesday, December 13, 2022 11:22 AM
> To: devel@edk2.groups.io 
> Cc: bob.c.f...@intel.com ; gaolim...@byosoft.com.cn 
> ; yuwei.c...@intel.com ; Jake 
> Garver ; Konstantin Aladyshev 
> Subject: [PATCH] Fix cyclic dependency error on OptionROM build
>
>
>
> External email: Use caution opening links or attachments
>
>
> EDKII build system supports OptionROM generation if particular PCI_*
> defines are present in the module INF file:
> ```
> [Defines]
>   ...
>   PCI_VENDOR_ID  = <...>
>   PCI_DEVICE_ID  = <...>
>   PCI_CLASS_CODE = <...>
>   PCI_REVISION   = <...>
> ```
> Although after the commit d372ab585a2cdc5348af5f701c56c631235fe698
> ("BaseTools/Conf: Fix Dynamic-Library-File template") it is no longer
> possible.
> The build system fails with the error:
> ```
> Cyclic dependency detected while generating rule for
> "<...>/DEBUG/<...>.efi" file
> ```
> Remove "$(DEBUG_DIR)(+)$(MODULE_NAME).efi" from the 'dll' output files
> to fix the cyclic dependency.
> ---
>  BaseTools/Conf/build_rule.template | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/BaseTools/Conf/build_rule.template 
> b/BaseTools/Conf/build_rule.template
> index af4819de92..21ccd864fa 100755
> --- a/BaseTools/Conf/build_rule.template
> +++ b/BaseTools/Conf/build_rule.template
> @@ -342,7 +342,6 @@
>
>
>  
>
>  $(OUTPUT_DIR)(+)$(MODULE_NAME).efi
>
> -$(DEBUG_DIR)(+)$(MODULE_NAME).efi
>
>  $(OUTPUT_DIR)(+)$(MODULE_NAME).map
>
>
>
>  
>
> --
> 2.34.1
>
> 


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

Re: [edk2-devel] [PATCH] UefiCpuPkg: Fix SMM code hangs when InitPaging

[Wu, Jiaxin]

Reviewed-by: Wu, Jiaxin 



> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Zeng,
> Star
> Sent: Thursday, January 12, 2023 8:12 PM
> To: devel@edk2.groups.io; Liu, Zhiguang 
> Cc: Ni, Ray ; Kumar, Rahul R ;
> Dong, Eric ; Tan, Dun ; Zeng,
> Star 
> Subject: Re: [edk2-devel] [PATCH] UefiCpuPkg: Fix SMM code hangs when
> InitPaging
> 
> Reviewed-by: Star Zeng 
> 
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of
> Zhiguang Liu
> Sent: Wednesday, January 4, 2023 1:41 PM
> To: devel@edk2.groups.io
> Cc: Liu, Zhiguang ; Ni, Ray ;
> Kumar, Rahul R ; Dong, Eric 
> Subject: [edk2-devel] [PATCH] UefiCpuPkg: Fix SMM code hangs when
> InitPaging
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4246
> 
> In function InitPaging, NumberOfPml5Entries is calculated by below code
> NumberOfPml5Entries = (UINTN)LShiftU64 (1, SizeOfMemorySpace - 48); If
> the SizeOfMemorySpace is larger than 48, NumberOfPml5Entries will be
> larger than 1. However, this doesn't make sense if the hardware doesn't
> support 5 level page table.
> 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Signed-off-by: Eric Dong 
> Signed-off-by: Zhiguang Liu 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> index c1efda7126..c597b39b8c 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> @@ -1,7 +1,7 @@
>  /** @file
>  Enable SMM profile.
> 
> -Copyright (c) 2012 - 2019, Intel Corporation. All rights reserved.
> +Copyright (c) 2012 - 2023, Intel Corporation. All rights reserved.
>  Copyright (c) 2017 - 2020, AMD Incorporated. All rights reserved.
> 
>  SPDX-License-Identifier: BSD-2-Clause-Patent @@ -587,15 +587,17 @@
> InitPaging (
>  }
> 
>  SizeOfMemorySpace = HighBitSet64 (gPhyMask) + 1;
> +ASSERT (SizeOfMemorySpace <= 52);
> +
>  //
> -// Calculate the table entries of PML4E and PDPTE.
> +// Calculate the table entries of PML5E, PML4E and PDPTE.
>  //
>  NumberOfPml5Entries = 1;
> -if (SizeOfMemorySpace > 48) {
> +if (Enable5LevelPaging && (SizeOfMemorySpace > 48)) {
>NumberOfPml5Entries = (UINTN)LShiftU64 (1, SizeOfMemorySpace - 48);
> -  SizeOfMemorySpace   = 48;
>  }
> 
> +SizeOfMemorySpace   = SizeOfMemorySpace > 48 ? 48 :
> SizeOfMemorySpace;
>  NumberOfPml4Entries = 1;
>  if (SizeOfMemorySpace > 39) {
>NumberOfPml4Entries = (UINTN)LShiftU64 (1, SizeOfMemorySpace - 39);
> --
> 2.31.1.windows.1
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH] UefiCpuPkg: Fix SMM code hangs when InitPaging

[Ni, Ray]

Reviewed-by: Ray Ni 

> -Original Message-
> From: Liu, Zhiguang 
> Sent: Wednesday, January 4, 2023 1:41 PM
> To: devel@edk2.groups.io
> Cc: Liu, Zhiguang ; Ni, Ray ; 
> Kumar, Rahul R ; Dong,
> Eric 
> Subject: [PATCH] UefiCpuPkg: Fix SMM code hangs when InitPaging
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4246
> 
> In function InitPaging, NumberOfPml5Entries is calculated by below code
> NumberOfPml5Entries = (UINTN)LShiftU64 (1, SizeOfMemorySpace - 48);
> If the SizeOfMemorySpace is larger than 48, NumberOfPml5Entries will be
> larger than 1. However, this doesn't make sense if the hardware doesn't
> support 5 level page table.
> 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Signed-off-by: Eric Dong 
> Signed-off-by: Zhiguang Liu 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> index c1efda7126..c597b39b8c 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> @@ -1,7 +1,7 @@
>  /** @file
>  Enable SMM profile.
> 
> -Copyright (c) 2012 - 2019, Intel Corporation. All rights reserved.
> +Copyright (c) 2012 - 2023, Intel Corporation. All rights reserved.
>  Copyright (c) 2017 - 2020, AMD Incorporated. All rights reserved.
> 
>  SPDX-License-Identifier: BSD-2-Clause-Patent
> @@ -587,15 +587,17 @@ InitPaging (
>  }
> 
>  SizeOfMemorySpace = HighBitSet64 (gPhyMask) + 1;
> +ASSERT (SizeOfMemorySpace <= 52);
> +
>  //
> -// Calculate the table entries of PML4E and PDPTE.
> +// Calculate the table entries of PML5E, PML4E and PDPTE.
>  //
>  NumberOfPml5Entries = 1;
> -if (SizeOfMemorySpace > 48) {
> +if (Enable5LevelPaging && (SizeOfMemorySpace > 48)) {
>NumberOfPml5Entries = (UINTN)LShiftU64 (1, SizeOfMemorySpace - 48);
> -  SizeOfMemorySpace   = 48;
>  }
> 
> +SizeOfMemorySpace   = SizeOfMemorySpace > 48 ? 48 : SizeOfMemorySpace;
>  NumberOfPml4Entries = 1;
>  if (SizeOfMemorySpace > 39) {
>NumberOfPml4Entries = (UINTN)LShiftU64 (1, SizeOfMemorySpace - 39);
> --
> 2.31.1.windows.1



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

Re: [edk2-devel] [PATCH] UefiCpuPkg: Fix SMM code hangs when InitPaging

[Ni, Ray]

+ Gerd.

> -Original Message-
> From: Liu, Zhiguang 
> Sent: Wednesday, January 4, 2023 1:41 PM
> To: devel@edk2.groups.io
> Cc: Liu, Zhiguang ; Ni, Ray ; 
> Kumar, Rahul R ; Dong,
> Eric 
> Subject: [PATCH] UefiCpuPkg: Fix SMM code hangs when InitPaging
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4246
> 
> In function InitPaging, NumberOfPml5Entries is calculated by below code
> NumberOfPml5Entries = (UINTN)LShiftU64 (1, SizeOfMemorySpace - 48);
> If the SizeOfMemorySpace is larger than 48, NumberOfPml5Entries will be
> larger than 1. However, this doesn't make sense if the hardware doesn't
> support 5 level page table.
> 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Signed-off-by: Eric Dong 
> Signed-off-by: Zhiguang Liu 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> index c1efda7126..c597b39b8c 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> @@ -1,7 +1,7 @@
>  /** @file
>  Enable SMM profile.
> 
> -Copyright (c) 2012 - 2019, Intel Corporation. All rights reserved.
> +Copyright (c) 2012 - 2023, Intel Corporation. All rights reserved.
>  Copyright (c) 2017 - 2020, AMD Incorporated. All rights reserved.
> 
>  SPDX-License-Identifier: BSD-2-Clause-Patent
> @@ -587,15 +587,17 @@ InitPaging (
>  }
> 
>  SizeOfMemorySpace = HighBitSet64 (gPhyMask) + 1;
> +ASSERT (SizeOfMemorySpace <= 52);
> +
>  //
> -// Calculate the table entries of PML4E and PDPTE.
> +// Calculate the table entries of PML5E, PML4E and PDPTE.
>  //
>  NumberOfPml5Entries = 1;
> -if (SizeOfMemorySpace > 48) {
> +if (Enable5LevelPaging && (SizeOfMemorySpace > 48)) {
>NumberOfPml5Entries = (UINTN)LShiftU64 (1, SizeOfMemorySpace - 48);
> -  SizeOfMemorySpace   = 48;
>  }
> 
> +SizeOfMemorySpace   = SizeOfMemorySpace > 48 ? 48 : SizeOfMemorySpace;
>  NumberOfPml4Entries = 1;
>  if (SizeOfMemorySpace > 39) {
>NumberOfPml4Entries = (UINTN)LShiftU64 (1, SizeOfMemorySpace - 39);
> --
> 2.31.1.windows.1



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

Re: [edk2-devel] [PATCH] Fix cyclic dependency error on OptionROM build

[Bob Feng]

Hi Konstantin,

EDK2 has not moved to PR for code review yet. Please still send patches to the 
mailing list. 
Package maintainers open PR for triggering CI and merging the patch.

Refer to: 
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process

Thanks,
Bob

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Konstantin 
Aladyshev
Sent: Tuesday, January 17, 2023 4:24 PM
To: Feng, Bob C 
Cc: devel@edk2.groups.io; Jake Garver ; Gao, Liming 
; Chen, Christine 
Subject: Re: [edk2-devel] [PATCH] Fix cyclic dependency error on OptionROM build

Thanks, Bob!

Sorry, somehow I've missed it.
Has EDK2 moved to the GitHub PR system instead of a mailing list for patches?
Do I need to open PR for my subsequent patches, or just send them to the 
mailing list like before?

Best regards,
Konstatin Aladyshev



On Tue, Jan 17, 2023 at 8:17 AM Feng, Bob C  wrote:
>
> Konstantin,
>
>
>
> The patch missed “Signed-off-by:”, I help you add it and open a PR 
> https://github.com/tianocore/edk2/pull/3909 for merge.
>
>
>
> Thanks,
>
> Bob
>
> From: devel@edk2.groups.io  On Behalf Of Bob 
> Feng
> Sent: Tuesday, January 17, 2023 1:05 PM
> To: Jake Garver ; Konstantin Aladyshev 
> ; devel@edk2.groups.io
> Cc: Gao, Liming ; Chen, Christine 
> 
> Subject: Re: [edk2-devel] [PATCH] Fix cyclic dependency error on 
> OptionROM build
>
>
>
> Reviewed-by: Bob Feng 
>
>
>
> From: Jake Garver 
> Sent: Wednesday, December 14, 2022 2:48 AM
> To: Konstantin Aladyshev ; devel@edk2.groups.io
> Cc: Feng, Bob C ; Gao, Liming 
> ; Chen, Christine 
> Subject: Re: [PATCH] Fix cyclic dependency error on OptionROM build
>
>
>
> Thanks, Konstantin,
>
>
>
> I approve this version.
>
>
>
> Thanks,
>
> Jake
>
> 
>
> From: Konstantin Aladyshev 
> Sent: Tuesday, December 13, 2022 11:22 AM
> To: devel@edk2.groups.io 
> Cc: bob.c.f...@intel.com ; 
> gaolim...@byosoft.com.cn ; 
> yuwei.c...@intel.com ; Jake Garver 
> ; Konstantin Aladyshev 
> Subject: [PATCH] Fix cyclic dependency error on OptionROM build
>
>
>
> External email: Use caution opening links or attachments
>
>
> EDKII build system supports OptionROM generation if particular PCI_* 
> defines are present in the module INF file:
> ```
> [Defines]
>   ...
>   PCI_VENDOR_ID  = <...>
>   PCI_DEVICE_ID  = <...>
>   PCI_CLASS_CODE = <...>
>   PCI_REVISION   = <...>
> ```
> Although after the commit d372ab585a2cdc5348af5f701c56c631235fe698
> ("BaseTools/Conf: Fix Dynamic-Library-File template") it is no longer 
> possible.
> The build system fails with the error:
> ```
> Cyclic dependency detected while generating rule for 
> "<...>/DEBUG/<...>.efi" file ``` Remove 
> "$(DEBUG_DIR)(+)$(MODULE_NAME).efi" from the 'dll' output files to fix 
> the cyclic dependency.
> ---
>  BaseTools/Conf/build_rule.template | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/BaseTools/Conf/build_rule.template 
> b/BaseTools/Conf/build_rule.template
> index af4819de92..21ccd864fa 100755
> --- a/BaseTools/Conf/build_rule.template
> +++ b/BaseTools/Conf/build_rule.template
> @@ -342,7 +342,6 @@
>
>
>  
>
>  $(OUTPUT_DIR)(+)$(MODULE_NAME).efi
>
> -$(DEBUG_DIR)(+)$(MODULE_NAME).efi
>
>  $(OUTPUT_DIR)(+)$(MODULE_NAME).map
>
>
>
>  
>
> --
> 2.34.1
>
> 







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

Re: [edk2-devel] [PATCH edk2-platforms 0/2] toolchain cleanups

[Ard Biesheuvel]

On Thu, 5 Jan 2023 at 17:01, Ard Biesheuvel  wrote:
>
> This cleans up some obsolete toolchain configuration variables:
> - the RVCT ones, which are no longer supported by EDK2
> - ARCHCC and ARCHASM, which serve no useful purpose and are better
>   removed
>
> Ard Biesheuvel (2):
>   Platform/ Silicon/: Drop remnants of RVCT toolchain support
>   Silicon/, Platform/: Get rid of redundant toolchains flags
>

Pushed as 3d072871806c..8e927b0f42e7


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98659): https://edk2.groups.io/g/devel/message/98659
Mute This Topic: https://groups.io/mt/96074597/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 0/3] Customize lazy-accepted memory size for TDVF

[Gerd Hoffmann]

On Mon, Jan 16, 2023 at 12:01:40PM +, Xu, Min M wrote:
> On January 2, 2023 6:37 PM, Gerd Hoffmann wrote:
> > On Mon, Dec 26, 2022 at 09:33:35AM +0800, Min Xu wrote:
> > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4181
> > >
> > > Current lazy-accept accepts the memory under address of 4G. To improve
> > > boot performance further more, we introduce the feature of customizing
> > > the physical end address of lazy-accept in build time.
> > 
> > Do you have numbers?  I'm wondering how much of a difference this actually
> > is, given that 2M pages is fast and tdx already uses all processors to 
> > accept
> > memory ...
> This feature is tested in Intel SPR platform (boot up a td guest configured 
> with 4vCPU + 4G memory).
> It costs about 91ms to accept memories under address of 0x2000. As a 
> comparison it costs about 240ms to accept memories under address of 
> 0x1.

Under 0x1 is 2G in practice with the default q35 memory layout.
Under 0x02000 is 512M (implemented by this patch series).

Accepting 4x the memory takes less than 4x the time, probably because
some memory is not accepted in multiprocessor mode; or maybe other
constant overhead.

Accepting additional 1.5G needs ~150 ms, so we talk about ~0.1s per GB.

> > What happens in case the firmware runs out of memory in DXE phase?
> We create an initrd which size is 881MB. The td guest is configured to accept 
> memories under address of 0x2000.
>  1) Direct boot
> [ ... ]
>   Error: Image at 0001E152000 start failed: Out of Resources
> 
> 2) Grub boot
> error: ../../grub-core/loader/i386/efi/linux.c:119:can't allocate initrd.

> After a while the boot process continued. Finally the td guest is 
> successfully brought up.

I wouldn't call not being able to load the initrd a success.

So we can't accept more memory on demand in case 512 MB is not enough.

IIRC the last time this was discussed we agreed on accepting all memory
below 4G for this reason, and also to keep things simple and give the
loaded kernel some wiggle room.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98660): https://edk2.groups.io/g/devel/message/98660
Mute This Topic: https://groups.io/mt/95882249/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 1/1] AmpereAltraPkg: Update ArmPlatformLib to work with changed ARM_CORE_INFO

[Nhi Pham via groups.io]

Hi Rebecca,

That's Ampere Altra Family specific MPIDR encoding. So, we could not 
leverage the definitions in the ArmPkg/Include/Library/ArmLib.h.


-Nhi

On 1/13/2023 9:40 PM, Rebecca Cran wrote:

On 1/12/23 21:21, Nhi Pham via groups.io wrote:


+//
+// MPIDR manipulation
+//
+#define AC01_GET_MPIDR(SocketId, ClusterId, CoreId) \
+  (((SocketId) << 32) | ((ClusterId) << 16) | ((CoreId) << 8))
+#define AC01_GET_SOCKET_ID(Mpidr)  (((Mpidr) & ARM_CORE_AFF3) >> 32)
+#define AC01_GET_CLUSTER_ID(Mpidr) (((Mpidr) & ARM_CORE_AFF2) >> 16)
+#define AC01_GET_CORE_ID(Mpidr)    (((Mpidr) & ARM_CORE_AFF1) >> 8)
+


Ideally, this should go in ArmPkg/Include/Library/ArmLib.h, but I'm 
not sure how we should handle the older format where the the core was 
in the first 8 bits.





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98661): https://edk2.groups.io/g/devel/message/98661
Mute This Topic: https://groups.io/mt/96240088/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 1/1] AmpereAltraPkg: Remove MemoryAllocationLib in ArmPlatformLib

[Nhi Pham via groups.io]

Hi Ard and Leif,

Just a friendly ping on the patches recently posted.

Below are links to the patches including the new introduction to the 
Ampere Altra Max support that we need you to review and merge them in order:


1/ https://edk2.groups.io/g/devel/message/97671

2/ https://edk2.groups.io/g/devel/message/97670

3/ https://edk2.groups.io/g/devel/message/98277

4/ https://edk2.groups.io/g/devel/message/98435

5/ https://edk2.groups.io/g/devel/message/98436

Thanks,

Nhi

On 12/23/2022 9:37 PM, Ard Biesheuvel wrote:

On Wed, 21 Dec 2022 at 06:01, Nhi Pham  wrote:

From: Tinh Nguyen 

PrePeiCore's Arm module just added a requirement to run all library
constructors that PrePeiCore uses. One of them is included in the
constructor of the ExtractGuidedSectionLib. This constructor will build
a HOB that is not supported "at this time" and causes an error.
We don't need to use this constructor because PrePeiCore doesn't
really need this library.

This is a workaround to avoid PrePeiCore module calling
ExtractGuidedSectionLib's constructor.

Signed-off-by: Nhi Pham 
---
  .../AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf | 1 -
  1 file changed, 1 deletion(-)

diff --git 
a/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf 
b/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf
index a4d29379198d..a61da278c705 100644
--- a/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf
+++ b/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf
@@ -25,7 +25,6 @@ [LibraryClasses]
ArmSmcLib
HobLib
IoLib
-  MemoryAllocationLib
PL011UartLib
PcdLib
SerialPortLib

Hi,

Thanks for these patches - I will merge them shortly.

As an aside, do you have any news on the issue I reported recently
regarding SetTime() on Altra which crashes the system if
SetVirtualAddressMap() was not called?

https://lore.kernel.org/all/Y2o1hdZK9GGDVJsS@monolith.localdoman/



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98662): https://edk2.groups.io/g/devel/message/98662
Mute This Topic: https://groups.io/mt/95801452/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] x86/efi: Safely enable unaccepted memory in UEFI

[Gerd Hoffmann]

On Tue, Jan 17, 2023 at 02:17:11AM +0300, Kirill A. Shutemov wrote:
> On Mon, Jan 16, 2023 at 11:43:15AM -0800, Dionna Amalie Glaze wrote:
> > > > I still don't understand why we need to support every imaginable
> > > > combination of firmware, bootloader and OS. Unaccepted memory only
> > > > exists on a special kind of virtual machine, which provides very
> > > > little added value unless you opt into the security and attestation
> > > > features, which are all heavily based on firmware protocols. So why
> > > > should care about a EFI-aware bootloader calling ExitBootServices()
> > > > and subsequently doing a legacy boot of Linux on such systems?
> > >
> > > Why break what works? Some users want it.
> > >
> > 
> > The users that want legacy boot features will not be broken,
> 
> Why do you call boot with a bootloader a legacy feature?

Linux efi kernels can be booted in two ways:

  (1) old/legacy: boot loader calls ExitBootServices and jumps to the
  kernel entry point.
  (2) new/efi stub: boot loader does *not* call ExitBootServices, but
  loads the linux kernel as efi binary instead.  The linux kernel
  efi stub calls ExitBootServices then.

All kernel version relevant here (new enough to support SEV-SNP / TDX)
have efi stub support, so (1) does not really matter in practice.

the efi stub was added *exactly* to handle cases like this one: the
kernel can do efi calls needed on its own without depending on the
boot loader doing it on behalf of the kernel.

> > This means that users of a distro that has not enabled unaccepted
> > memory support cannot simply start a VM with the usual command, but
> > instead have to know a baroque extra flag to get access to all the
> > memory that they configured the machine (and for a CSP customer, paid
> > for). That's not a good experience.
> 
> New features require enabling. It is not something new.

Asking user to manually configure something which can be handled
automatically just fine is a bad design.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98663): https://edk2.groups.io/g/devel/message/98663
Mute This Topic: https://groups.io/mt/96256524/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] x86/efi: Safely enable unaccepted memory in UEFI

[Gerd Hoffmann]

  Hi,

> In any case, the firmware side of things didn't seem like _that_ much
> code.  So, I'm not protesting *that* strongly.  But, I also don't
> believe for a second that this is going to be removed in 3-5 years.

If things are going roughly as I expect them to go (both tdx support and
unaccepted memory support land upstream this year; distros enable it by
default) we should be able to drop this when the 6.1-lts kernel goes
EOL.  First in edk2, later in linux too.

take care,
  Gerd



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

Re: [edk2-devel] [PATCH v11 17/17] OfmvPkg: CI: Qemu tests: set CPU to Broadwell

[Oliver Steffen]

It is this one:
https://bugzilla.tianocore.org/show_bug.cgi?id=4251
Should have put that into the commit message, sorry.


On Tue, Jan 17, 2023 at 1:16 AM Yao, Jiewen  wrote:

> Not sure the detail.
>
> Could you please add more comment, such as, what issue? Why crash? Why
> changing to Broadwell can resolve it?
> any URL?
>
>
>
> > -Original Message-
> > From: Oliver Steffen 
> > Sent: Tuesday, January 17, 2023 1:41 AM
> > To: devel@edk2.groups.io
> > Cc: Andrew Fish ; Ard Biesheuvel
> > ; Feng, Bob C ; Bi,
> > Dandan ; Gerd Hoffmann ;
> > Wang, Jian J ; Yao, Jiewen  >;
> > Justen, Jordan L ; Leif Lindholm
> > ; Gao, Liming ;
> > Kinney, Michael D ; Michael Kubacki
> > ; Ni, Ray ; Sami
> > Mujawar ; Sean Brogan
> > ; Chen, Christine ;
> > Pawel Polawski ; chris.fern...@outlook.com; Oliver
> > Steffen 
> > Subject: [PATCH v11 17/17] OfmvPkg: CI: Qemu tests: set CPU to Broadwell
> >
> > Work around a bug in Ovmf that causes Ovmf to crash on startup
> > when running in recent versions of Qemu.  Setting the cpu model
> > to something older, for example "Broadwell" works around the issue.
> >
> > Signed-off-by: Oliver Steffen 
> > ---
> >  OvmfPkg/PlatformCI/PlatformBuildLib.py | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/OvmfPkg/PlatformCI/PlatformBuildLib.py
> > b/OvmfPkg/PlatformCI/PlatformBuildLib.py
> > index bfef9849c749..93f7d7aa13d6 100644
> > --- a/OvmfPkg/PlatformCI/PlatformBuildLib.py
> > +++ b/OvmfPkg/PlatformCI/PlatformBuildLib.py
> > @@ -194,6 +194,7 @@ class PlatformBuilder( UefiBuilder,
> > BuildSettingsManager):
> >  cmd = "qemu-system-x86_64"
> >  args  = "-debugcon stdio"
>  # write messages to
> > stdio
> >  args += " -global isa-debugcon.iobase=0x402"
> # debug
> > messages out thru virtual io port
> > +args += " -cpu Broadwell"
>  # workaround Qvmf
> > bug
> >  args += " -net none"
> # turn off network
> >  args += f" -drive
> file=fat:rw:{VirtualDrive},format=raw,media=disk" #
> > Mount disk with startup.nsh
> >
> > --
> > 2.39.0
>
>
>
> 
>
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98665): https://edk2.groups.io/g/devel/message/98665
Mute This Topic: https://groups.io/mt/96311858/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 3/4] OvmfPkg/IntelTdx: Enable separate-fv in IntelTdx/IntelTdxX64.fdf

[Gerd Hoffmann]

  Hi,

> -INF  MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf

If you move the gfx console driver you can move the gfx hardware drivers
too:

  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
  OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
  OvmfPkg/VirtioGpuDxe/VirtioGpu.inf

take care,
  Gerd



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

Re: [edk2-devel] [PATCH V3 0/4] Introduce Separate-Fv in OvmfPkg/IntelTdx

[Gerd Hoffmann]

On Tue, Jan 17, 2023 at 07:31:54AM +0800, Min Xu wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4152
> 
> In current DXE FV there are 100+ drivers. Some of the drivers are not
> used in Td guest. (Such as USB support drivers, network related
> drivers, etc).
> 
> From the security perspective if a driver is not used, we should prevent
> it from being loaded/started. There are 2 benefits: 
> 1. Reduce the attack surface
> 2. Improve the boot performance
> 
> So we introduce Separate-Fv which separates DXEFV into 2 FVs: DXEFV
> and NCCFV. All the drivers which are not needed by a Confidential
> Computing guest are moved from DXEFV to NCCFV.
> 
> When booting a CC guest only the drivers in DXEFV will be loaded and
> started. For a Non-CC guest both DXEFV and NCCFV drivers will be
> loaded and started.
> 
> Patch#1 updates EmbeddedPkg/PrePiLib with FFS_CHECK_SECTION_HOOK.
> Patch#2 adds PCDs/GUID for NCCFV.
> Patch#3 moves cc-unused drivers to NCCFV.
> Patch#4 update PeilessStartupLib to find NCCFV for non-cc guest.

series:
Acked-by: Gerd Hoffmann 

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98667): https://edk2.groups.io/g/devel/message/98667
Mute This Topic: https://groups.io/mt/96319661/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 0/7] Enable Tdx measurement in OvmfPkgX64

[Gerd Hoffmann]

  Hi,

> Patch #2:
>   Introduce TdxHelperLib which provides helper functions for td-guest.

> Patch #6:
>   ProcessTdxHobList is moved to TdxHelperLib and is renamed as
>   TdxHelperProcessTdHob(). So the duplicated codes are deleted in this
>   patch.

This is a unreview-able mess.  Please create a separate patch which
moves the code to TdxHelperLib, without any code modifications.
Should code changes be needed do them incrementally on top if this.

thanks & take care,
  Gerd



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

Re: [edk2-devel] [PATCH V1 1/7] OvmfPkg: Add Tdx measurement data structure in WorkArea

[Gerd Hoffmann]

On Tue, Jan 17, 2023 at 03:40:10PM +0800, Min Xu wrote:
> From: Min M Xu 
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4243
> 
> From the perspective of security any external input should be measured
> and extended to some registers (TPM PCRs or TDX RTMR registers).
> 
> There are below 2 external input in a Td guest:
>  - TdHob
>  - Configuration FV (CFV)
> 
> TdHob contains the resource information passed from VMM, such as
> unaccepted memory region. CFV contains the configurations, such as
> secure boot variables.
> 
> TdHob and CFV should be measured and extended to RTMRs before they're
> consumed. TdHob is consumed in the very early stage of boot process.
> At that moment the memory service is not ready. Cfv is consumed in
> PlatformPei to initialize the EmuVariableNvStore. To make the
> implementation simple and clean, these 2 external input are measured
> and extended to RTMRs in SEC phase.  The measurement values are stored
> in WorkArea. Then after the Hob service is available, these 2 measurement
> values are retrieved and GuidHobs for these 2 tdx measurements are
> generated.

So the measurement is done early and the hashes are stored to create the
event log entries later, correct?

Why both TdHob and CFV are handled this way?  It should be needed for
TdHob only, right?  The work area has a fixed size, IMHO we should not
store data there unless we absolutely have to, and for CFV I don't see
the justification.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98669): https://edk2.groups.io/g/devel/message/98669
Mute This Topic: https://groups.io/mt/96325908/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 5/7] OvmfPkg: Enable Tdx measurement in OvmfPkgX64

[Gerd Hoffmann]

On Tue, Jan 17, 2023 at 03:40:14PM +0800, Min Xu wrote:
> From: Min M Xu 
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4243
> 
> This patch enables Tdx measurement in OvmfPkgX64 with below changes:
> 1) TDX_ENABLE is introduced in OvmfPkgX64.dsc. This flag indicates
>if Intel TDX is enabled in OvmfPkgX64. Its default value is FALSE.
> 2) Update SecMain.c with the functions provided by TdxHelperLib
> 3) Include TdTcg2Dxe in OvmfPkgX64 so that CC_MEASUREMENT_PROTOCOL
>is installed in a Td-guest. TdTcg2Dxe is controlled by TDX_ENABLE
>because it is only valid when Intel TDX is enabled.
> 3) OvmfTpmLibs.dsc.inc and OvmfTpmSecurityStub.dsc.inc are updated
>because DxeTpm2MeasureBootLib.inf and DxeTpmMeasurementLib.inf
>should be included to support CC_MEASUREMENT_PROTOCOL.

Acked-by: Gerd Hoffmann 



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

Re: [edk2-devel] [PATCH V3 0/2] [PATCH V1 0/2] Refactor TDX MmioExit

[Gerd Hoffmann]

On Tue, Jan 17, 2023 at 03:43:28PM +0800, Min Xu wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4169
> 
> The previous TDX MmioExit doesn't handle the Mmio instructions correctly
> in some scenarios. This patch-set refactors the implementation to fix the
> issues.
> 
> Before the refactoring, common X86 instruction codes in CcExitVcHandler.c
> are moved to separate files (CcInstruction.h / CcInstruction.c) so that
> these codes can be re-used in TDX.
> 
> Code: https://github.com/mxu9/edk2/tree/TdxMmioExit.v3
> 
> v3 changes:
>  - Handle the error if an error is returned from TdxMmioReadWrite.
>  - Add more check in ParseMmioExitInstructions.
> 
> v2 changes:
>  - Add CpuDeadLoop () after each TDVMCALL(HALT) in VE handler. Because
>TDVMCALL(HALT) is not trusted.
>  - Other minor changes such as deleting ASSERT in VE handler. Because
>any error in VE handler will trigger CpuDeadLoop (). So ASSERT is not
>needed any more.

Series:
Acked-by: Gerd Hoffmann 



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

Re: [edk2-devel] [PATCH] UefiCpuPkg: Fix SMM code hangs when InitPaging

[Gerd Hoffmann]

On Tue, Jan 17, 2023 at 09:02:01AM +, Ni, Ray wrote:
> + Gerd.
> 
> > -Original Message-
> > From: Liu, Zhiguang 
> > Sent: Wednesday, January 4, 2023 1:41 PM
> > To: devel@edk2.groups.io
> > Cc: Liu, Zhiguang ; Ni, Ray ; 
> > Kumar, Rahul R ; Dong,
> > Eric 
> > Subject: [PATCH] UefiCpuPkg: Fix SMM code hangs when InitPaging
> > 
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4246
> > 
> > In function InitPaging, NumberOfPml5Entries is calculated by below code
> > NumberOfPml5Entries = (UINTN)LShiftU64 (1, SizeOfMemorySpace - 48);
> > If the SizeOfMemorySpace is larger than 48, NumberOfPml5Entries will be
> > larger than 1. However, this doesn't make sense if the hardware doesn't
> > support 5 level page table.

> > +ASSERT (SizeOfMemorySpace <= 52);
> > +
> >  //
> > -// Calculate the table entries of PML4E and PDPTE.
> > +// Calculate the table entries of PML5E, PML4E and PDPTE.
> >  //
> >  NumberOfPml5Entries = 1;
> > -if (SizeOfMemorySpace > 48) {
> > +if (Enable5LevelPaging && (SizeOfMemorySpace > 48)) {
> >NumberOfPml5Entries = (UINTN)LShiftU64 (1, SizeOfMemorySpace - 48);
> > -  SizeOfMemorySpace   = 48;
> >  }
> > 
> > +SizeOfMemorySpace   = SizeOfMemorySpace > 48 ? 48 : SizeOfMemorySpace;

if (SizeOfMemorySpace > 48) {
if (Enable5LevelPaging) {
 NumberOfPml5Entries = ...
}
SizeOfMemorySpace = 48
}

That is a much more readable version.

The only effect I can see is that this avoids creating page tables which
would not be used anyway.

Can you explain where the hangs mentioned in the subject line are coming
from and why the patch fixes them?

take care,
  Gerd



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

[edk2-devel] [PATCH v4 0/5] OvmfPkg: check 64bit mmio window for resource conflicts

[Gerd Hoffmann]

v4:
 - made mmio window move a bit more robust.
 - dropped patches for moving MMCONFIG, they'll come as separate patch
   series later.

v3:
 - Add / fix comments, add notes to commit messages.
 - Make functions static.
 - Logging tweaks.
 - Fix windows compiler warnings.
 - Add patches (5,6,7) moving MMCONFIG to 0xe000, simplifying code
   and reducing differences between 'pc' and 'q35' along the way.
   Eventually we want split them into a separate series, but some of
   this was discussed in v2 review, so I just appended them here for
   now.
v2:
 - split up PlatformScanOrAdd64BitE820Ram() into scan function with
   callbacks, store results in PlatformInfoHob struct.

Gerd Hoffmann (5):
  OvmfPkg/PlatformInitLib: Add PlatformScanE820 and GetFirstNonAddressCB
  OvmfPkg/PlatformInitLib: Add PlatformGetLowMemoryCB
  OvmfPkg/PlatformInitLib: Add PlatformAddHobCB
  OvmfPkg/PlatformInitLib: Add PlatformReservationConflictCB
  OvmfPkg/PlatformInitLib: reorder PlatformQemuUc32BaseInitialization

 OvmfPkg/Include/Library/PlatformInitLib.h |   3 +-
 OvmfPkg/Library/PeilessStartupLib/Hob.c   |   3 +-
 .../PeilessStartupLib/PeilessStartup.c|   7 +-
 OvmfPkg/Library/PlatformInitLib/MemDetect.c   | 356 ++
 OvmfPkg/Library/PlatformInitLib/Platform.c|   7 +-
 OvmfPkg/PlatformPei/MemDetect.c   |   3 +-
 6 files changed, 214 insertions(+), 165 deletions(-)

-- 
2.39.0



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

[edk2-devel] [PATCH v4 3/5] OvmfPkg/PlatformInitLib: Add PlatformAddHobCB

[Gerd Hoffmann]

Add PlatformAddHobCB() callback function for use with
PlatformScanE820().  It adds HOBs for high memory and reservations (low
memory is handled elsewhere because there are some special cases to
consider).  This replaces calls to PlatformScanOrAdd64BitE820Ram() with
AddHighHobs = TRUE.

Write any actions done (adding HOBs, skip unknown types) to the firmware
log with INFO loglevel.

Also remove PlatformScanOrAdd64BitE820Ram() which is not used any more.

Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/Library/PlatformInitLib/MemDetect.c | 185 +---
 1 file changed, 47 insertions(+), 138 deletions(-)

diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c 
b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
index dfaa05a1c24f..c626fc49cf6c 100644
--- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
+++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
@@ -112,143 +112,6 @@ PlatformQemuUc32BaseInitialization (
   }
 }
 
-/**
-  Iterate over the RAM entries in QEMU's fw_cfg E820 RAM map that start outside
-  of the 32-bit address range.
-
-  Find the highest exclusive >=4GB RAM address, or produce memory resource
-  descriptor HOBs for RAM entries that start at or above 4GB.
-
-  @param[out] MaxAddress  If MaxAddress is NULL, then 
PlatformScanOrAdd64BitE820Ram()
-  produces memory resource descriptor HOBs for RAM
-  entries that start at or above 4GB.
-
-  Otherwise, MaxAddress holds the highest exclusive
-  >=4GB RAM address on output. If QEMU's fw_cfg E820
-  RAM map contains no RAM entry that starts outside of
-  the 32-bit address range, then MaxAddress is exactly
-  4GB on output.
-
-  @retval EFI_SUCCESS The fw_cfg E820 RAM map was found and processed.
-
-  @retval EFI_PROTOCOL_ERROR  The RAM map was found, but its size wasn't a
-  whole multiple of sizeof(EFI_E820_ENTRY64). No
-  RAM entry was processed.
-
-  @return Error codes from QemuFwCfgFindFile(). No RAM
-  entry was processed.
-**/
-STATIC
-EFI_STATUS
-PlatformScanOrAdd64BitE820Ram (
-  IN BOOLEAN  AddHighHob,
-  OUT UINT64  *LowMemory OPTIONAL,
-  OUT UINT64  *MaxAddress OPTIONAL
-  )
-{
-  EFI_STATUSStatus;
-  FIRMWARE_CONFIG_ITEM  FwCfgItem;
-  UINTN FwCfgSize;
-  EFI_E820_ENTRY64  E820Entry;
-  UINTN Processed;
-
-  Status = QemuFwCfgFindFile ("etc/e820", &FwCfgItem, &FwCfgSize);
-  if (EFI_ERROR (Status)) {
-return Status;
-  }
-
-  if (FwCfgSize % sizeof E820Entry != 0) {
-return EFI_PROTOCOL_ERROR;
-  }
-
-  if (LowMemory != NULL) {
-*LowMemory = 0;
-  }
-
-  if (MaxAddress != NULL) {
-*MaxAddress = BASE_4GB;
-  }
-
-  QemuFwCfgSelectItem (FwCfgItem);
-  for (Processed = 0; Processed < FwCfgSize; Processed += sizeof E820Entry) {
-QemuFwCfgReadBytes (sizeof E820Entry, &E820Entry);
-DEBUG ((
-  DEBUG_VERBOSE,
-  "%a: Base=0x%Lx Length=0x%Lx Type=%u\n",
-  __FUNCTION__,
-  E820Entry.BaseAddr,
-  E820Entry.Length,
-  E820Entry.Type
-  ));
-if (E820Entry.Type == EfiAcpiAddressRangeMemory) {
-  if (AddHighHob && (E820Entry.BaseAddr >= BASE_4GB)) {
-UINT64  Base;
-UINT64  End;
-
-//
-// Round up the start address, and round down the end address.
-//
-Base = ALIGN_VALUE (E820Entry.BaseAddr, (UINT64)EFI_PAGE_SIZE);
-End  = (E820Entry.BaseAddr + E820Entry.Length) &
-   ~(UINT64)EFI_PAGE_MASK;
-if (Base < End) {
-  PlatformAddMemoryRangeHob (Base, End);
-  DEBUG ((
-DEBUG_VERBOSE,
-"%a: PlatformAddMemoryRangeHob [0x%Lx, 0x%Lx)\n",
-__FUNCTION__,
-Base,
-End
-));
-}
-  }
-
-  if (MaxAddress || LowMemory) {
-UINT64  Candidate;
-
-Candidate = E820Entry.BaseAddr + E820Entry.Length;
-if (MaxAddress && (Candidate > *MaxAddress)) {
-  *MaxAddress = Candidate;
-  DEBUG ((
-DEBUG_VERBOSE,
-"%a: MaxAddress=0x%Lx\n",
-__FUNCTION__,
-*MaxAddress
-));
-}
-
-if (LowMemory && (Candidate > *LowMemory) && (Candidate < BASE_4GB)) {
-  *LowMemory = Candidate;
-  DEBUG ((
-DEBUG_VERBOSE,
-"%a: LowMemory=0x%Lx\n",
-__FUNCTION__,
-*LowMemory
-));
-}
-  }
-} else if (E820Entry.Type == EfiAcpiAddressRangeReserved) {
-  if (AddHighHob) {
-DEBUG ((
-  DEBUG_INFO,
-  "%a: Reserved: Base=0x%Lx Length=0x%Lx\n",
-  __FUNCTION__,
-  E820Entry.BaseAddr,
-  E820Entry.Length
-  ));
-BuildResourceDescriptorHob (
-  EFI_RESOURCE_MEMORY_RESERVED,
-  

[edk2-devel] [PATCH v4 2/5] OvmfPkg/PlatformInitLib: Add PlatformGetLowMemoryCB

[Gerd Hoffmann]

Add PlatformGetLowMemoryCB() callback function for use with
PlatformScanE820().  It stores the low memory size in
PlatformInfoHob->LowMemory.  This replaces calls to
PlatformScanOrAdd64BitE820Ram() with non-NULL LowMemory.

Write any actions done (setting LowMemory) to the firmware log
with INFO loglevel.

Also change PlatformGetSystemMemorySizeBelow4gb() to likewise set
PlatformInfoHob->LowMemory instead of returning the value.  Update
all Callers to the new convention.

Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/Include/Library/PlatformInitLib.h |  3 +-
 OvmfPkg/Library/PeilessStartupLib/Hob.c   |  3 +-
 .../PeilessStartupLib/PeilessStartup.c|  7 +-
 OvmfPkg/Library/PlatformInitLib/MemDetect.c   | 69 +--
 OvmfPkg/Library/PlatformInitLib/Platform.c|  7 +-
 OvmfPkg/PlatformPei/MemDetect.c   |  3 +-
 6 files changed, 59 insertions(+), 33 deletions(-)

diff --git a/OvmfPkg/Include/Library/PlatformInitLib.h 
b/OvmfPkg/Include/Library/PlatformInitLib.h
index bf6f90a5761c..051b31191194 100644
--- a/OvmfPkg/Include/Library/PlatformInitLib.h
+++ b/OvmfPkg/Include/Library/PlatformInitLib.h
@@ -26,6 +26,7 @@ typedef struct {
   BOOLEAN  Q35SmramAtDefaultSmbase;
   UINT16   Q35TsegMbytes;
 
+  UINT32   LowMemory;
   UINT64   FirstNonAddress;
   UINT8PhysMemAddressWidth;
   UINT32   Uc32Base;
@@ -144,7 +145,7 @@ PlatformQemuUc32BaseInitialization (
   IN OUT EFI_HOB_PLATFORM_INFO  *PlatformInfoHob
   );
 
-UINT32
+VOID
 EFIAPI
 PlatformGetSystemMemorySizeBelow4gb (
   IN EFI_HOB_PLATFORM_INFO  *PlatformInfoHob
diff --git a/OvmfPkg/Library/PeilessStartupLib/Hob.c 
b/OvmfPkg/Library/PeilessStartupLib/Hob.c
index 630ce445ebec..318b74c95d8e 100644
--- a/OvmfPkg/Library/PeilessStartupLib/Hob.c
+++ b/OvmfPkg/Library/PeilessStartupLib/Hob.c
@@ -42,7 +42,8 @@ ConstructSecHobList (
 
   ZeroMem (&PlatformInfoHob, sizeof (PlatformInfoHob));
   PlatformInfoHob.HostBridgeDevId = PciRead16 (OVMF_HOSTBRIDGE_DID);
-  LowMemorySize   = PlatformGetSystemMemorySizeBelow4gb 
(&PlatformInfoHob);
+  PlatformGetSystemMemorySizeBelow4gb (&PlatformInfoHob);
+  LowMemorySize = PlatformInfoHob.LowMemory;
   ASSERT (LowMemorySize != 0);
   LowMemoryStart = FixedPcdGet32 (PcdOvmfDxeMemFvBase) + FixedPcdGet32 
(PcdOvmfDxeMemFvSize);
   LowMemorySize -= LowMemoryStart;
diff --git a/OvmfPkg/Library/PeilessStartupLib/PeilessStartup.c 
b/OvmfPkg/Library/PeilessStartupLib/PeilessStartup.c
index 380e71597206..928120d183ba 100644
--- a/OvmfPkg/Library/PeilessStartupLib/PeilessStartup.c
+++ b/OvmfPkg/Library/PeilessStartupLib/PeilessStartup.c
@@ -41,8 +41,7 @@ InitializePlatform (
   EFI_HOB_PLATFORM_INFO  *PlatformInfoHob
   )
 {
-  UINT32  LowerMemorySize;
-  VOID*VariableStore;
+  VOID  *VariableStore;
 
   DEBUG ((DEBUG_INFO, "InitializePlatform in Pei-less boot\n"));
   PlatformDebugDumpCmos ();
@@ -70,14 +69,14 @@ InitializePlatform (
 PlatformInfoHob->PcdCpuBootLogicalProcessorNumber
 ));
 
-  LowerMemorySize = PlatformGetSystemMemorySizeBelow4gb (PlatformInfoHob);
+  PlatformGetSystemMemorySizeBelow4gb (PlatformInfoHob);
   PlatformQemuUc32BaseInitialization (PlatformInfoHob);
   DEBUG ((
 DEBUG_INFO,
 "Uc32Base = 0x%x, Uc32Size = 0x%x, LowerMemorySize = 0x%x\n",
 PlatformInfoHob->Uc32Base,
 PlatformInfoHob->Uc32Size,
-LowerMemorySize
+PlatformInfoHob->LowMemory
 ));
 
   VariableStore  = 
PlatformReserveEmuVariableNvStore ();
diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c 
b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
index 1ea91f78cefd..dfaa05a1c24f 100644
--- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
+++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
@@ -51,18 +51,16 @@ PlatformQemuUc32BaseInitialization (
   IN OUT EFI_HOB_PLATFORM_INFO  *PlatformInfoHob
   )
 {
-  UINT32  LowerMemorySize;
-
   if (PlatformInfoHob->HostBridgeDevId == 0x /* microvm */) {
 return;
   }
 
   if (PlatformInfoHob->HostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
-LowerMemorySize = PlatformGetSystemMemorySizeBelow4gb (PlatformInfoHob);
+PlatformGetSystemMemorySizeBelow4gb (PlatformInfoHob);
 ASSERT (PcdGet64 (PcdPciExpressBaseAddress) <= MAX_UINT32);
-ASSERT (PcdGet64 (PcdPciExpressBaseAddress) >= LowerMemorySize);
+ASSERT (PcdGet64 (PcdPciExpressBaseAddress) >= PlatformInfoHob->LowMemory);
 
-if (LowerMemorySize <= BASE_2GB) {
+if (PlatformInfoHob->LowMemory <= BASE_2GB) {
   // Newer qemu with gigabyte aligned memory,
   // 32-bit pci mmio window is 2G -> 4G then.
   PlatformInfoHob->Uc32Base = BASE_2GB;
@@ -92,8 +90,8 @@ PlatformQemuUc32BaseInitialization (
   // variable MTRR suffices by truncating the size to a whole power of two,
   // while keeping the end affixed to 4GB. This will round the base up.
   //
-  LowerMemorySize   = PlatformGetSystemMemorySizeBelow4gb 
(PlatformInfoHob);

[edk2-devel] [PATCH v4 1/5] OvmfPkg/PlatformInitLib: Add PlatformScanE820 and GetFirstNonAddressCB

[Gerd Hoffmann]

First step replacing the PlatformScanOrAdd64BitE820Ram() function.

Add a PlatformScanE820() function which loops over the e280 entries
from FwCfg and calls a callback for each of them.

Add a GetFirstNonAddressCB() function which will store the first free
address (right after the last RAM block) in
PlatformInfoHob->FirstNonAddress.  This replaces calls to
PlatformScanOrAdd64BitE820Ram() with non-NULL MaxAddress.

Write any actions done (setting FirstNonAddress) to the firmware log
with INFO loglevel.

Also drop local FirstNonAddress variables and use
PlatformInfoHob->FirstNonAddress instead everywhere.

Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/Library/PlatformInitLib/MemDetect.c | 115 
 1 file changed, 92 insertions(+), 23 deletions(-)

diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c 
b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
index 882805269b3e..1ea91f78cefd 100644
--- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
+++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
@@ -251,6 +251,83 @@ PlatformScanOrAdd64BitE820Ram (
   return EFI_SUCCESS;
 }
 
+typedef VOID (*E820_SCAN_CALLBACK) (
+  EFI_E820_ENTRY64   *E820Entry,
+  EFI_HOB_PLATFORM_INFO  *PlatformInfoHob
+  );
+
+/**
+  Store first address not used by e820 RAM entries in
+  PlatformInfoHob->FirstNonAddress
+**/
+VOID
+PlatformGetFirstNonAddressCB (
+  IN EFI_E820_ENTRY64   *E820Entry,
+  IN OUT EFI_HOB_PLATFORM_INFO  *PlatformInfoHob
+  )
+{
+  UINT64  Candidate;
+
+  if (E820Entry->Type != EfiAcpiAddressRangeMemory) {
+return;
+  }
+
+  Candidate = E820Entry->BaseAddr + E820Entry->Length;
+  if (PlatformInfoHob->FirstNonAddress < Candidate) {
+DEBUG ((DEBUG_INFO, "%a: FirstNonAddress=0x%Lx\n", __FUNCTION__, 
Candidate));
+PlatformInfoHob->FirstNonAddress = Candidate;
+  }
+}
+
+/**
+  Iterate over the entries in QEMU's fw_cfg E820 RAM map, call the
+  passed callback for each entry.
+
+  @param[in] Callback  The callback function to be called.
+
+  @param[in out]  PlatformInfoHob  PlatformInfo struct which is passed
+   through to the callback.
+
+  @retval EFI_SUCCESS  The fw_cfg E820 RAM map was found and 
processed.
+
+  @retval EFI_PROTOCOL_ERROR   The RAM map was found, but its size wasn't a
+   whole multiple of sizeof(EFI_E820_ENTRY64). 
No
+   RAM entry was processed.
+
+  @return  Error codes from QemuFwCfgFindFile(). No RAM
+   entry was processed.
+**/
+STATIC
+EFI_STATUS
+PlatformScanE820 (
+  IN  E820_SCAN_CALLBACK Callback,
+  IN OUT  EFI_HOB_PLATFORM_INFO  *PlatformInfoHob
+  )
+{
+  EFI_STATUSStatus;
+  FIRMWARE_CONFIG_ITEM  FwCfgItem;
+  UINTN FwCfgSize;
+  EFI_E820_ENTRY64  E820Entry;
+  UINTN Processed;
+
+  Status = QemuFwCfgFindFile ("etc/e820", &FwCfgItem, &FwCfgSize);
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  if (FwCfgSize % sizeof E820Entry != 0) {
+return EFI_PROTOCOL_ERROR;
+  }
+
+  QemuFwCfgSelectItem (FwCfgItem);
+  for (Processed = 0; Processed < FwCfgSize; Processed += sizeof E820Entry) {
+QemuFwCfgReadBytes (sizeof E820Entry, &E820Entry);
+Callback (&E820Entry, PlatformInfoHob);
+  }
+
+  return EFI_SUCCESS;
+}
+
 /**
   Returns PVH memmap
 
@@ -384,23 +461,17 @@ PlatformGetSystemMemorySizeAbove4gb (
   Return the highest address that DXE could possibly use, plus one.
 **/
 STATIC
-UINT64
+VOID
 PlatformGetFirstNonAddress (
   IN OUT  EFI_HOB_PLATFORM_INFO  *PlatformInfoHob
   )
 {
-  UINT64FirstNonAddress;
   UINT32FwCfgPciMmio64Mb;
   EFI_STATUSStatus;
   FIRMWARE_CONFIG_ITEM  FwCfgItem;
   UINTN FwCfgSize;
   UINT64HotPlugMemoryEnd;
 
-  //
-  // set FirstNonAddress to suppress incorrect compiler/analyzer warnings
-  //
-  FirstNonAddress = 0;
-
   //
   // If QEMU presents an E820 map, then get the highest exclusive >=4GB RAM
   // address from it. This can express an address >= 4GB+1TB.
@@ -408,9 +479,10 @@ PlatformGetFirstNonAddress (
   // Otherwise, get the flat size of the memory above 4GB from the CMOS (which
   // can only express a size smaller than 1TB), and add it to 4GB.
   //
-  Status = PlatformScanOrAdd64BitE820Ram (FALSE, NULL, &FirstNonAddress);
+  PlatformInfoHob->FirstNonAddress = BASE_4GB;
+  Status   = PlatformScanE820 
(PlatformGetFirstNonAddressCB, PlatformInfoHob);
   if (EFI_ERROR (Status)) {
-FirstNonAddress = BASE_4GB + PlatformGetSystemMemorySizeAbove4gb ();
+PlatformInfoHob->FirstNonAddress = BASE_4GB + 
PlatformGetSystemMemorySizeAbove4gb ();
   }
 
   //
@@ -420,7 +492,7 @@ PlatformGetFirstNonAddress (
   //
  #ifdef MDE_CPU_IA32
   if (!FeaturePcdGet (PcdDxeIplSwitchToLongMode)) {
-return FirstNonAddress;
+return;
   }
 
  #endif
@@ -473,7 +545,7 @@ Platfo

[edk2-devel] [PATCH v4 5/5] OvmfPkg/PlatformInitLib: reorder PlatformQemuUc32BaseInitialization

[Gerd Hoffmann]

First handle the cases which do not need know the value of
PlatformInfoHob->LowMemory (microvm and cloudhv).  Then call
PlatformGetSystemMemorySizeBelow4gb() to get LowMemory.  Finally handle
the cases (q35 and pc) which need to look at LowMemory,

Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/Library/PlatformInitLib/MemDetect.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c 
b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
index 1ce692e77ecb..d6984ee96eb4 100644
--- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
+++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
@@ -55,8 +55,15 @@ PlatformQemuUc32BaseInitialization (
 return;
   }
 
+  if (PlatformInfoHob->HostBridgeDevId == CLOUDHV_DEVICE_ID) {
+PlatformInfoHob->Uc32Size = CLOUDHV_MMIO_HOLE_SIZE;
+PlatformInfoHob->Uc32Base = CLOUDHV_MMIO_HOLE_ADDRESS;
+return;
+  }
+
+  PlatformGetSystemMemorySizeBelow4gb (PlatformInfoHob);
+
   if (PlatformInfoHob->HostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
-PlatformGetSystemMemorySizeBelow4gb (PlatformInfoHob);
 ASSERT (PcdGet64 (PcdPciExpressBaseAddress) <= MAX_UINT32);
 ASSERT (PcdGet64 (PcdPciExpressBaseAddress) >= PlatformInfoHob->LowMemory);
 
@@ -78,19 +85,12 @@ PlatformQemuUc32BaseInitialization (
 return;
   }
 
-  if (PlatformInfoHob->HostBridgeDevId == CLOUDHV_DEVICE_ID) {
-PlatformInfoHob->Uc32Size = CLOUDHV_MMIO_HOLE_SIZE;
-PlatformInfoHob->Uc32Base = CLOUDHV_MMIO_HOLE_ADDRESS;
-return;
-  }
-
   ASSERT (PlatformInfoHob->HostBridgeDevId == INTEL_82441_DEVICE_ID);
   //
   // On i440fx, start with the [LowerMemorySize, 4GB) range. Make sure one
   // variable MTRR suffices by truncating the size to a whole power of two,
   // while keeping the end affixed to 4GB. This will round the base up.
   //
-  PlatformGetSystemMemorySizeBelow4gb (PlatformInfoHob);
   PlatformInfoHob->Uc32Size = GetPowerOfTwo32 ((UINT32)(SIZE_4GB - 
PlatformInfoHob->LowMemory));
   PlatformInfoHob->Uc32Base = (UINT32)(SIZE_4GB - PlatformInfoHob->Uc32Size);
   //
-- 
2.39.0



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

[edk2-devel] [PATCH v4 4/5] OvmfPkg/PlatformInitLib: Add PlatformReservationConflictCB

[Gerd Hoffmann]

Add PlatformReservationConflictCB() callback function for use with
PlatformScanE820().  It checks whenever the 64bit PCI MMIO window
overlaps with a reservation from qemu.  If so move down the MMIO window
to resolve the conflict.

Write any actions done (moving mmio window) to the firmware log with
INFO loglevel.

This happens on (virtual) AMD machines with 1TB address space,
because the AMD IOMMU uses an address window just below 1TB.

Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=4251
Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/Library/PlatformInitLib/MemDetect.c | 45 +
 1 file changed, 45 insertions(+)

diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c 
b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
index c626fc49cf6c..1ce692e77ecb 100644
--- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
+++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
@@ -213,6 +213,50 @@ PlatformAddHobCB (
   }
 }
 
+/**
+  Check whenever the 64bit PCI MMIO window overlaps with a reservation
+  from qemu.  If so move down the MMIO window to resolve the conflict.
+
+  This happens on (virtual) AMD machines with 1TB address space,
+  because the AMD IOMMU uses an address window just below 1TB.
+**/
+STATIC VOID
+PlatformReservationConflictCB (
+  IN EFI_E820_ENTRY64   *E820Entry,
+  IN OUT EFI_HOB_PLATFORM_INFO  *PlatformInfoHob
+  )
+{
+  UINT64  IntersectionBase;
+  UINT64  IntersectionEnd;
+  UINT64  NewBase;
+
+  IntersectionBase = MAX (
+   E820Entry->BaseAddr,
+   PlatformInfoHob->PcdPciMmio64Base
+   );
+  IntersectionEnd = MIN (
+  E820Entry->BaseAddr + E820Entry->Length,
+  PlatformInfoHob->PcdPciMmio64Base +
+  PlatformInfoHob->PcdPciMmio64Size
+  );
+
+  if (IntersectionBase >= IntersectionEnd) {
+return;  // no overlap
+  }
+
+  NewBase = E820Entry->BaseAddr - PlatformInfoHob->PcdPciMmio64Size;
+  NewBase = NewBase & ~(PlatformInfoHob->PcdPciMmio64Size - 1);
+
+  DEBUG ((
+DEBUG_INFO,
+"%a: move mmio: 0x%Lx => %Lx\n",
+__FUNCTION__,
+PlatformInfoHob->PcdPciMmio64Base,
+NewBase
+));
+  PlatformInfoHob->PcdPciMmio64Base = NewBase;
+}
+
 /**
   Iterate over the entries in QEMU's fw_cfg E820 RAM map, call the
   passed callback for each entry.
@@ -650,6 +694,7 @@ PlatformDynamicMmioWindow (
 DEBUG ((DEBUG_INFO, "%a:   MMIO Space 0x%Lx (%Ld GB)\n", __func__, 
MmioSpace, RShiftU64 (MmioSpace, 30)));
 PlatformInfoHob->PcdPciMmio64Size = MmioSpace;
 PlatformInfoHob->PcdPciMmio64Base = AddrSpace - MmioSpace;
+PlatformScanE820 (PlatformReservationConflictCB, PlatformInfoHob);
   } else {
 DEBUG ((DEBUG_INFO, "%a: using classic mmio window\n", __func__));
   }
-- 
2.39.0



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

Re: [edk2-devel] [PATCH v11 17/17] OfmvPkg: CI: Qemu tests: set CPU to Broadwell

[Yao, Jiewen]

I have seen Gerd sent out V4 patch set for #4251. Is that not enough?

In general, I prefer no work-around, unless there is strong reason.

I would like to have Gerd and Ard to feedback.

Thank you
Yao, Jiewen

From: devel@edk2.groups.io  On Behalf Of Oliver Steffen
Sent: Tuesday, January 17, 2023 6:37 PM
To: devel@edk2.groups.io; Yao, Jiewen 
Cc: Andrew Fish ; Ard Biesheuvel ; 
Feng, Bob C ; Bi, Dandan ; Gerd 
Hoffmann ; Wang, Jian J ; Justen, 
Jordan L ; Leif Lindholm 
; Gao, Liming ; Kinney, 
Michael D ; Michael Kubacki 
; Ni, Ray ; Sami Mujawar 
; Sean Brogan ; Chen, 
Christine ; Pawel Polawski ; 
chris.fern...@outlook.com
Subject: Re: [edk2-devel] [PATCH v11 17/17] OfmvPkg: CI: Qemu tests: set CPU to 
Broadwell

It is this one:
https://bugzilla.tianocore.org/show_bug.cgi?id=4251
Should have put that into the commit message, sorry.


On Tue, Jan 17, 2023 at 1:16 AM Yao, Jiewen 
mailto:jiewen@intel.com>> wrote:
Not sure the detail.

Could you please add more comment, such as, what issue? Why crash? Why changing 
to Broadwell can resolve it?
any URL?



> -Original Message-
> From: Oliver Steffen mailto:ostef...@redhat.com>>
> Sent: Tuesday, January 17, 2023 1:41 AM
> To: devel@edk2.groups.io
> Cc: Andrew Fish mailto:af...@apple.com>>; Ard Biesheuvel
> mailto:ardb%2btianoc...@kernel.org>>; Feng, Bob C 
> mailto:bob.c.f...@intel.com>>; Bi,
> Dandan mailto:dandan...@intel.com>>; Gerd Hoffmann 
> mailto:kra...@redhat.com>>;
> Wang, Jian J mailto:jian.j.w...@intel.com>>; Yao, 
> Jiewen mailto:jiewen@intel.com>>;
> Justen, Jordan L 
> mailto:jordan.l.jus...@intel.com>>; Leif Lindholm
> mailto:quic_llind...@quicinc.com>>; Gao, Liming 
> mailto:gaolim...@byosoft.com.cn>>;
> Kinney, Michael D 
> mailto:michael.d.kin...@intel.com>>; Michael 
> Kubacki
> mailto:mikub...@linux.microsoft.com>>; Ni, Ray 
> mailto:ray...@intel.com>>; Sami
> Mujawar mailto:sami.muja...@arm.com>>; Sean Brogan
> mailto:sean.bro...@microsoft.com>>; Chen, 
> Christine mailto:yuwei.c...@intel.com>>;
> Pawel Polawski mailto:ppola...@redhat.com>>; 
> chris.fern...@outlook.com; Oliver
> Steffen mailto:ostef...@redhat.com>>
> Subject: [PATCH v11 17/17] OfmvPkg: CI: Qemu tests: set CPU to Broadwell
>
> Work around a bug in Ovmf that causes Ovmf to crash on startup
> when running in recent versions of Qemu.  Setting the cpu model
> to something older, for example "Broadwell" works around the issue.
>
> Signed-off-by: Oliver Steffen 
> mailto:ostef...@redhat.com>>
> ---
>  OvmfPkg/PlatformCI/PlatformBuildLib.py | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/OvmfPkg/PlatformCI/PlatformBuildLib.py
> b/OvmfPkg/PlatformCI/PlatformBuildLib.py
> index bfef9849c749..93f7d7aa13d6 100644
> --- a/OvmfPkg/PlatformCI/PlatformBuildLib.py
> +++ b/OvmfPkg/PlatformCI/PlatformBuildLib.py
> @@ -194,6 +194,7 @@ class PlatformBuilder( UefiBuilder,
> BuildSettingsManager):
>  cmd = "qemu-system-x86_64"
>  args  = "-debugcon stdio"   
> # write messages to
> stdio
>  args += " -global isa-debugcon.iobase=0x402"
> # debug
> messages out thru virtual io port
> +args += " -cpu Broadwell"   
> # workaround Qvmf
> bug
>  args += " -net none"
> # turn off network
>  args += f" -drive file=fat:rw:{VirtualDrive},format=raw,media=disk" #
> Mount disk with startup.nsh
>
> --
> 2.39.0








-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98679): https://edk2.groups.io/g/devel/message/98679
Mute This Topic: https://groups.io/mt/96311858/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] OvmfPkg/PlatformInitLib: catch QEMU's CPU hotplug reg block regression

[Gerd Hoffmann]

  Hi,

> >> In particular the firmware makes no further decisions based on
> >> whether QEMU advertized some of these features.
> >
> > I was thinking the other way around:  When cpu hotplug is disabled in
> > qemu it should be safe to skip the whole cpu hotplug checking dance.
> > See test patch below.
> >
> > That would give us a config switch (turn off cpu hotplug support)
> > which would allow edk2 run on qemu versions with broken cpu hotplug.
> >
> > Does the idea look sane or do I miss something?

> This would be wrong.
> 
> [ detailed description snipped here (but stored for later reference,
>   thanks for all the details) ]

So, the tl;dr version:  cpu hotplug is older than smi feature
negotiation, so smi hotplug feature bit being off doesn't imply
qemu wouldn't hotplug cpus.

So, no easy way out.  Luckily this affects tcg only.

For edk2 ci doing (tcg) efi shell test boots switching to Oliver's
latest containers with fixed qemu included should handle things
(latest series just posted).  So once this is in we should be able to
merge this patch without breaking CI.

take care,
  Gerd



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

Re: [edk2-devel] [PATCH v11 17/17] OfmvPkg: CI: Qemu tests: set CPU to Broadwell

[Gerd Hoffmann]

On Tue, Jan 17, 2023 at 12:20:16PM +, Yao, Jiewen wrote:
> I have seen Gerd sent out V4 patch set for #4251. Is that not enough?

If that is merged first patch 17 should not be needed.

take care,
  Gerd



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

Re: [edk2-devel] PATCH v1 1/1 MdePkg: Remove Itanium leftover data structure

[Paweł Poławski]

Hi all,

Just to let you know: I performed a test with this modified version
of EDK2 and 1500 vCPU set in Qemu config. The test ended up with 
success. I can confirm that space saved by removing Itanium data 
structure allows to allocate more than 1024 vCPU using KVM accelerator.


On thing to note - to test this KVM needs to be modified, the same with 
Qemu. Both - by default has vCPU limits so low that they will be 
bottleneck for vCPU now.


Best regards,
Pawel

W dniu 10.01.2023 o 16:32, Lendacky, Thomas via groups.io pisze:

+ Garret

On 1/10/23 03:36, Ni, Ray via groups.io wrote:
The challenge is that the non-Itanium CPU archs that may depend on 
the

current binary layout of these structures.  This could be a binary
PEI CPU module, DXE CPU module, SMM CPU module, MM CPU modules,
UEFI App/Shell App that use the PPI or HOB.


The CPU health record is stored in PPI first by SecCore, then saved to 
HOB by CpuMpPei module.

Then CpuDxe gets the record from HOB.

If SecCore, CpuMpPei, CpuDxe are built with different structure 
definition,

the compatibility issue appears.

The very well know binary separation module today for x86 is Intel's FSP.
I am not sure if today customer might use a pre-built FSP binary which 
is built from
version #1 of edk2 while the SecCore and CpuDxe in platform binary are 
built from

a different version of edk2.
I don't know how AMD distributes the binary module. + Tom

If binary distribution is not adopted yet by industry, I prefer we 
just update the

structure definition.



Even if we define a new HOB format, we have to decide when it is
used to support compatibility.  Perhaps always keep the current
logic if < 1024 CPUs.  If number of CPUs >= 1024, then produce
the new format of CPU information and update all consumers to
look for new format and use that with higher priority than the
old format.


I don't like this approach because it still breaks the case when CPU 
>=1024 and binary

distribution is used.



Another option is to keep the current format and allow multiple
HOBs to be produced if the CPU information does not fit in the
single HOB size limit of 64KB.  Then update all consumers to
look for 1 or more HOBs to collect all the information.  This
approach removes the CPU number limit as long as there is enough
temp RAM for the multiple HOBs.


CpuDxe driver is one of the consumers.
1. Old CpuMpPei (in FSP binary) + new CpuDxe (In Platform binary)
  This doesn't work because CpuMpPei still cannot produce the 
huge-size HOB.

2. New CpuMpPei (in FSP binary) + old CpuDxe (In Platform binary)
  This doesn't work because old CpuDxe doesn't look for multiple 
HOBs.





-Original Message-
From: devel@edk2.groups.io  On Behalf Of Pawel 
Polawski

Sent: Tuesday, January 10, 2023 4:19 PM
To: devel@edk2.groups.io; Ni, Ray ; Kinney, Michael 
D ; Zimmer, Vincent


Cc: Gao, Liming ; Liu, Zhiguang 

Subject: Re: [edk2-devel] PATCH v1 1/1 MdePkg: Remove Itanium 
leftover data structure


Hi everyone,

If there is a chance you have some evaluation about this problem 
already?


Best regards,
Pawel


















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

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

[Oliver Steffen]

Hi Ard, Hi everyone,

Thanks for the work!

But somehow this patch (as it was merged into master branch) does not
work for me on the ThunderX box we have.

Any idea what could be wrong?
I enabled the erratum during build ;-)

CPU Info:
# lscpu
Architecture:   aarch64
  CPU op-mode(s):   64-bit
  Byte Order:   Little Endian
CPU(s): 224
  On-line CPU(s) list:  0-223
Vendor ID:  Cavium
  BIOS Vendor ID:   Cavium Inc.
  Model name:   ThunderX2 99xx
BIOS Model name:Cavium ThunderX2(R) CPU CN9975 v2.2 @ 2.0GHz
Model:  2
Thread(s) per core: 4
Core(s) per socket: 28
Socket(s):  2
Stepping:   0x1
BogoMIPS:   400.00
Flags:  fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
cpuid asimdrdm
Caches (sum of all):
  L1d:  1.8 MiB (56 instances)
  L1i:  1.8 MiB (56 instances)
  L2:   14 MiB (56 instances)
  L3:   64 MiB (2 instances)
[...]

Thanks a lot!
- Oliver


On Tue, Jan 10, 2023 at 1:08 AM dann frazier 
wrote:

> On Thu, Jan 05, 2023 at 05:25:28PM +0100, Ard Biesheuvel wrote:
> > 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|  5
> +
> >  ArmVirtPkg/Library/ArmPlatformLibQemu/AArch64/ArmPlatformHelper.S | 15
> +++
> >  2 files changed, 20 insertions(+)
>
> FTR, this v2 series also worked for me.
>
>   -dann
>
> > diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> > index f77443229e8e..5dd8b6104cca 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,11 @@ [LibraryClasses.common.UEFI_DRIVER]
> >UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
> >
> >  [BuildOptions]
> > +!if $(CAVIUM_ERRATUM_27456) == TRUE
> > +  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 1787d52fbf51..5ac7c732f6ec 100644
> > --- a/ArmVirtPkg/Library/ArmPlatformLibQemu/AArch64/ArmPlatformHelper.S
> > +++ b/ArmVirtPkg/Library/ArmPlatformLibQemu/AArch64/ArmPlatformHelper.S
> > @@ -42,6 +42,21 @@
> >
> >
> >  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 (but not 0xAF)
> > +   */
> > +  mrsx0, midr_el1// read the MIDR into X0
> > +  ubfx   x1, x0, #24, #8 // grab implementor id
> > +  ubfx   x0, x0, #7, #9  // grab part number bits [11:3]
> > +  cmpx1, #0x43   // compare implementor id
> > +  ccmp   x0, #0xA0 >> 3, #0, eq  // compare part# bits [11:3]
> > +  b.eq   0f
> > +#endif
> >mrsx0, CurrentEL   // check current exception level
> >tbnz   x0, #3, 0f  // omit early ID map if above EL1
> >
>
>
> 
>
>
>


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

Re: [edk2-devel] [PATCH] UefiCpuPkg: Fix SMM code hangs when InitPaging

[Ni, Ray]

> > > +ASSERT (SizeOfMemorySpace <= 52);
> > > +
> > >  //
> > > -// Calculate the table entries of PML4E and PDPTE.
> > > +// Calculate the table entries of PML5E, PML4E and PDPTE.
> > >  //
> > >  NumberOfPml5Entries = 1;
> > > -if (SizeOfMemorySpace > 48) {
> > > +if (Enable5LevelPaging && (SizeOfMemorySpace > 48)) {
> > >NumberOfPml5Entries = (UINTN)LShiftU64 (1, SizeOfMemorySpace - 48);
> > > -  SizeOfMemorySpace   = 48;
> > >  }
> > >
> > > +SizeOfMemorySpace   = SizeOfMemorySpace > 48 ? 48 : 
> > > SizeOfMemorySpace;
> 
> if (SizeOfMemorySpace > 48) {
> if (Enable5LevelPaging) {
>  NumberOfPml5Entries = ...
> }
> SizeOfMemorySpace = 48
> }
> 
> That is a much more readable version.

I had the same thought. New version is consistent with the logic below.


> 
> The only effect I can see is that this avoids creating page tables which
> would not be used anyway.
> 
> Can you explain where the hangs mentioned in the subject line are coming
> from and why the patch fixes them?


> 
> take care,
>   Gerd
> 
> 
> 
> 
> 



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

[edk2-devel] [PATCH v1 0/2] Add ACPI 6.5 header

[Chao Li]

ACPI specification 6.5 has been released in August 2022, EDK2 needs to
add V6.5 header.

v1:
1. Added ACPI 6.5 header, copied from Acpi64.h.
2. Added CORE_PIC, LIO_PIC ,etc. tables to MADT.

Chao Li (2):
  MdePkg: Add ACPI 6.5 header
  MdePkg: Added serveral tables to MATD used by LoongArch64

 MdePkg/Include/IndustryStandard/Acpi.h   |3 +-
 MdePkg/Include/IndustryStandard/Acpi65.h | 3256 ++
 2 files changed, 3258 insertions(+), 1 deletion(-)
 create mode 100644 MdePkg/Include/IndustryStandard/Acpi65.h

-- 
2.27.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98685): https://edk2.groups.io/g/devel/message/98685
Mute This Topic: https://groups.io/mt/96328875/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 1/1] AmpereAltraPkg: Update ArmPlatformLib to work with changed ARM_CORE_INFO

[Rebecca Cran]

I was under the impression that this is becoming a more standard format?

For example, the Neoverse N2 has AFF0 always 0 (it's not hyperthreaded), 
it puts the core ID in AFF1, the cluster ID in AFF2, but since it only 
has a single socket AFF3 is always 0. This differs from older cores 
where the core ID was in AFF0 and the cluster ID in AFF1.


https://developer.arm.com/documentation/102099//AArch64-registers/AArch64-identification-registers/MPIDR-EL1--Multiprocessor-Affinity-Register

Am I mistaken?

--
Rebecca Cran

On 1/17/23 02:53, Nhi Pham wrote:

Hi Rebecca,

That's Ampere Altra Family specific MPIDR encoding. So, we could not 
leverage the definitions in the ArmPkg/Include/Library/ArmLib.h.


-Nhi

On 1/13/2023 9:40 PM, Rebecca Cran wrote:

On 1/12/23 21:21, Nhi Pham via groups.io wrote:


+//
+// MPIDR manipulation
+//
+#define AC01_GET_MPIDR(SocketId, ClusterId, CoreId) \
+  (((SocketId) << 32) | ((ClusterId) << 16) | ((CoreId) << 8))
+#define AC01_GET_SOCKET_ID(Mpidr)  (((Mpidr) & ARM_CORE_AFF3) >> 32)
+#define AC01_GET_CLUSTER_ID(Mpidr) (((Mpidr) & ARM_CORE_AFF2) >> 16)
+#define AC01_GET_CORE_ID(Mpidr)    (((Mpidr) & ARM_CORE_AFF1) >> 8)
+


Ideally, this should go in ArmPkg/Include/Library/ArmLib.h, but I'm 
not sure how we should handle the older format where the the core was 
in the first 8 bits.





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

[edk2-devel] [PATCH v1 2/2] MdePkg: Added serveral tables to MATD used by LoongArch64

[Chao Li]

Add CORE_PIC, LIO_PIC, HT_PIC, EIO_PIC, MSI_PIC, BIO_PIC and LPC_PIC
tables for LoongArch64 as defined in ACPI SPEC 6.5.

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

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Signed-off-by: Chao Li 
---
 MdePkg/Include/IndustryStandard/Acpi65.h | 95 +++-
 1 file changed, 94 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/IndustryStandard/Acpi65.h 
b/MdePkg/Include/IndustryStandard/Acpi65.h
index fdca5316a9..1e41ae9a27 100644
--- a/MdePkg/Include/IndustryStandard/Acpi65.h
+++ b/MdePkg/Include/IndustryStandard/Acpi65.h
@@ -303,7 +303,7 @@ typedef struct {
 
 //
 // Multiple APIC Description Table APIC structure types
-// All other values between 0x10 and 0x7F are reserved and
+// All other values between 0x18 and 0x7F are reserved and
 // will be ignored by OSPM. 0x80 ~ 0xFF are reserved for OEM.
 //
 #define EFI_ACPI_6_5_PROCESSOR_LOCAL_APIC   0x00
@@ -323,6 +323,13 @@ typedef struct {
 #define EFI_ACPI_6_5_GICR   0x0E
 #define EFI_ACPI_6_5_GIC_ITS0x0F
 #define EFI_ACPI_6_5_MULTIPROCESSOR_WAKEUP  0x10
+#define EFI_ACPI_6_5_CORE_PIC   0x11
+#define EFI_ACPI_6_5_LIO_PIC0x12
+#define EFI_ACPI_6_5_HT_PIC 0x13
+#define EFI_ACPI_6_5_EIO_PIC0x14
+#define EFI_ACPI_6_5_MSI_PIC0x15
+#define EFI_ACPI_6_5_BIO_PIC0x16
+#define EFI_ACPI_6_5_LPC_PIC0x17
 
 //
 // APIC Structure Definitions
@@ -617,6 +624,92 @@ typedef struct {
 #define EFI_ACPI_6_5_MULTIPROCESSOR_WAKEUP_MAILBOX_COMMAND_NOOP0x
 #define EFI_ACPI_6_5_MULTIPROCESSOR_WAKEUP_MAILBOX_COMMAND_WAKEUP  0x0001
 
+///
+/// Core Programmable Interrupt Controller
+///
+typedef struct {
+  UINT8 Type;
+  UINT8 Length;
+  UINT8 Version;
+  UINT32ProcessorId;
+  UINT32CoreId;
+  UINT32Flags;
+} EFI_ACPI_6_5_CORE_PIC_STRUCTURE;
+
+///
+/// Legacy I/O Programmable Interrupt Controller
+///
+typedef struct {
+  UINT8 Type;
+  UINT8 Length;
+  UINT8 Version;
+  UINT64Address;
+  UINT16Size;
+  UINT8 Cascade[2];
+  UINT32CascadeMap[2];
+} EFI_ACPI_6_5_LIO_PIC_STRUCTURE;
+
+///
+/// HyperTransport Programmable Interrupt Controller
+///
+typedef struct {
+  UINT8 Type;
+  UINT8 Length;
+  UINT8 Version;
+  UINT64Address;
+  UINT16Size;
+  UINT8 Cascade[8];
+} EFI_ACPI_6_5_HT_PIC_STRUCTURE;
+
+///
+/// Extend I/O Programmable Interrupt Controller
+///
+typedef struct {
+  UINT8 Type;
+  UINT8 Length;
+  UINT8 Version;
+  UINT8 Cascade;
+  UINT8 Node;
+  UINT64NodeMap;
+} EFI_ACPI_6_5_EIO_PIC_STRUCTURE;
+
+///
+/// MSI Programmable Interrupt Controller
+///
+typedef struct {
+  UINT8 Type;
+  UINT8 Length;
+  UINT8 Version;
+  UINT64MsgAddress;
+  UINT32Start;
+  UINT32Count;
+} EFI_ACPI_6_5_MSI_PIC_STRUCTURE;
+
+///
+/// Bridge I/O Programmable Interrupt Controller
+///
+typedef struct {
+  UINT8 Type;
+  UINT8 Length;
+  UINT8 Version;
+  UINT64Address;
+  UINT16Size;
+  UINT16Id;
+  UINT16GsiBase;
+} EFI_ACPI_6_5_BIO_PIC_STRUCTURE;
+
+///
+/// Low Pin Count Programmable Interrupt Controller
+///
+typedef struct {
+  UINT8 Type;
+  UINT8 Length;
+  UINT8 Version;
+  UINT64Address;
+  UINT16Size;
+  UINT8 Cascade;
+} EFI_ACPI_6_5_LPC_PIC_STRUCTURE;
+
 ///
 /// Smart Battery Description Table (SBST)
 ///
-- 
2.27.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98687): https://edk2.groups.io/g/devel/message/98687
Mute This Topic: https://groups.io/mt/96328877/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/2] MdePkg: Add ACPI 6.5 header

[Chao Li]

Create Acpi65.h, which is copied from Acpi64.h, and make the following
changes:

1. Replace all occurences of "6.4/6_4" with "6.5/6_5".
2. Incremented FADT minor revision.
3. Make Acpi65.h the latest ACPI definitions that Acpi.h contains.

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

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Signed-off-by: Chao Li 
---
 MdePkg/Include/IndustryStandard/Acpi.h   |3 +-
 MdePkg/Include/IndustryStandard/Acpi65.h | 3163 ++
 2 files changed, 3165 insertions(+), 1 deletion(-)
 create mode 100644 MdePkg/Include/IndustryStandard/Acpi65.h

diff --git a/MdePkg/Include/IndustryStandard/Acpi.h 
b/MdePkg/Include/IndustryStandard/Acpi.h
index 05969a36b1..a0610d4a4c 100644
--- a/MdePkg/Include/IndustryStandard/Acpi.h
+++ b/MdePkg/Include/IndustryStandard/Acpi.h
@@ -4,6 +4,7 @@
 
   Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
   Copyright (c) 2019 - 2021, ARM Ltd. All rights reserved.
+  Copyright (c) 2023, Loongson Technology Corporation Limited. All rights 
reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -11,6 +12,6 @@
 #ifndef _ACPI_H_
 #define _ACPI_H_
 
-#include 
+#include 
 
 #endif
diff --git a/MdePkg/Include/IndustryStandard/Acpi65.h 
b/MdePkg/Include/IndustryStandard/Acpi65.h
new file mode 100644
index 00..fdca5316a9
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/Acpi65.h
@@ -0,0 +1,3163 @@
+/** @file
+  ACPI 6.5 definitions from the ACPI Specification Revision 6.5 Aug, 2022.
+
+  Copyright (c) 2017 - 2022, Intel Corporation. All rights reserved.
+  Copyright (c) 2019 - 2021, ARM Ltd. All rights reserved.
+  Copyright (c) 2023, Loongson Technology Corporation Limited. All rights 
reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef ACPI_6_5_H_
+#define ACPI_6_5_H_
+
+#include 
+
+//
+// Ensure proper structure formats
+//
+#pragma pack(1)
+
+///
+/// ACPI 6.5 Generic Address Space definition
+///
+typedef struct {
+  UINT8 AddressSpaceId;
+  UINT8 RegisterBitWidth;
+  UINT8 RegisterBitOffset;
+  UINT8 AccessSize;
+  UINT64Address;
+} EFI_ACPI_6_5_GENERIC_ADDRESS_STRUCTURE;
+
+//
+// Generic Address Space Address IDs
+//
+#define EFI_ACPI_6_5_SYSTEM_MEMORY   0x00
+#define EFI_ACPI_6_5_SYSTEM_IO   0x01
+#define EFI_ACPI_6_5_PCI_CONFIGURATION_SPACE 0x02
+#define EFI_ACPI_6_5_EMBEDDED_CONTROLLER 0x03
+#define EFI_ACPI_6_5_SMBUS   0x04
+#define EFI_ACPI_6_5_SYSTEM_CMOS 0x05
+#define EFI_ACPI_6_5_PCI_BAR_TARGET  0x06
+#define EFI_ACPI_6_5_IPMI0x07
+#define EFI_ACPI_6_5_GENERAL_PURPOSE_IO  0x08
+#define EFI_ACPI_6_5_GENERIC_SERIAL_BUS  0x09
+#define EFI_ACPI_6_5_PLATFORM_COMMUNICATION_CHANNEL  0x0A
+#define EFI_ACPI_6_5_FUNCTIONAL_FIXED_HARDWARE   0x7F
+
+//
+// Generic Address Space Access Sizes
+//
+#define EFI_ACPI_6_5_UNDEFINED  0
+#define EFI_ACPI_6_5_BYTE   1
+#define EFI_ACPI_6_5_WORD   2
+#define EFI_ACPI_6_5_DWORD  3
+#define EFI_ACPI_6_5_QWORD  4
+
+//
+// ACPI 6.5 table structures
+//
+
+///
+/// Root System Description Pointer Structure
+///
+typedef struct {
+  UINT64Signature;
+  UINT8 Checksum;
+  UINT8 OemId[6];
+  UINT8 Revision;
+  UINT32RsdtAddress;
+  UINT32Length;
+  UINT64XsdtAddress;
+  UINT8 ExtendedChecksum;
+  UINT8 Reserved[3];
+} EFI_ACPI_6_5_ROOT_SYSTEM_DESCRIPTION_POINTER;
+
+///
+/// RSD_PTR Revision (as defined in ACPI 6.5 spec.)
+///
+#define EFI_ACPI_6_5_ROOT_SYSTEM_DESCRIPTION_POINTER_REVISION  0x02 ///< 
ACPISpec (Revision 6.5) says current value is 2
+
+///
+/// Common table header, this prefaces all ACPI tables, including FACS, but
+/// excluding the RSD PTR structure
+///
+typedef struct {
+  UINT32Signature;
+  UINT32Length;
+} EFI_ACPI_6_5_COMMON_HEADER;
+
+//
+// Root System Description Table
+// No definition needed as it is a common description table header, the same 
with
+// EFI_ACPI_DESCRIPTION_HEADER, followed by a variable number of UINT32 table 
pointers.
+//
+
+///
+/// RSDT Revision (as defined in ACPI 6.5 spec.)
+///
+#define EFI_ACPI_6_5_ROOT_SYSTEM_DESCRIPTION_TABLE_REVISION  0x01
+
+//
+// Extended System Description Table
+// No definition needed as it is a common description table header, the same 
with
+// EFI_ACPI_DESCRIPTION_HEADER, followed by a variable number of UINT64 table 
pointers.
+//
+
+///
+/// XSDT Revision (as defined in ACPI 6.5 spec.)
+///
+#define EFI_ACPI_6_5_EXTENDED_SYSTEM_DESCRIPTION_TABLE_REVISION  0x01
+
+///
+/// Fixed ACPI Description Table Structure (FADT)
+///
+typedef struct {
+  EFI_ACPI_DESCRIPTION_HEADER   Header;
+  UINT32FirmwareCtrl;
+  UINT32Dsdt;
+  UINT8 Reserved0;
+  UINT8 

[edk2-devel] [PATCH V2 1/1] OvmfPkg/AcpiPlatformDxe: Measure ACPI table from QEMU in TDVF

[Min Xu]

From: Min M Xu 

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

The ACPI tables are downloaded from QEMU. From the security perspective
they should be measured and extended before installation. So that they
can be audited later.

The measurement leverages the TpmMeasurementLib which is available when
TPM or Confidential Computing measurement protocol is installed. But in
some cases none of the measurement protocol is installed. In this case
the measurement will be skipped.

Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Tom Lendacky 
Cc: Michael Roth 
Signed-off-by: Min Xu 
---
 OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf |  1 +
 OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c | 26 +
 2 files changed, 27 insertions(+)

diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf 
b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
index 8939dde42549..3fd0483b50eb 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
@@ -46,6 +46,7 @@
   UefiBootServicesTableLib
   UefiDriverEntryPoint
   HobLib
+  TpmMeasurementLib
 
 [Protocols]
   gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED
diff --git a/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c 
b/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
index f0d81d6fd73d..a7f14f8e25f4 100644
--- a/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
+++ b/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
@@ -10,6 +10,7 @@
 
 #include // EFI_ACPI_DESCRIPTION_HEADER
 #include   // QEMU_LOADER_FNAME_SIZE
+#include 
 #include   // AsciiStrCmp()
 #include // CopyMem()
 #include  // DEBUG()
@@ -18,6 +19,7 @@
 #include  // QemuFwCfgFindFile()
 #include// QemuFwCfgS3Enabled()
 #include  // gBS
+#include 
 
 #include "AcpiPlatform.h"
 
@@ -1032,6 +1034,30 @@ Process2ndPassCmdAddPointer (
 goto RollbackSeenPointer;
   }
 
+  //
+  // Measure the ACPI table downloaded from QEMU before it is installed.
+  //
+  Status = TpmMeasureAndLogData (
+ 1,
+ EV_PLATFORM_CONFIG_FLAGS,
+ EV_POSTCODE_INFO_ACPI_DATA,
+ ACPI_DATA_LEN,
+ (VOID *)(UINTN)PointerValue,
+ TableSize
+ );
+  //
+  // TPM & Confidential Computing measurement protocol may not be installed.
+  // So EFI_NOT_FOUND is ignored.
+  //
+  if (EFI_ERROR (Status) && (Status != EFI_NOT_FOUND)) {
+DEBUG ((
+  DEBUG_ERROR,
+  "Measure ACPI table failed! Status = %r\n",
+  Status
+  ));
+goto RollbackSeenPointer;
+  }
+
   Status = AcpiProtocol->InstallAcpiTable (
AcpiProtocol,
(VOID *)(UINTN)PointerValue,
-- 
2.29.2.windows.2



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

[edk2-devel] [PATCH v1 0/2] Add ACPI 6.5 header

[Chao Li]

ACPI specification 6.5 has been released in August 2022, EDK2 needs to
add V6.5 header.

v1:
1. Added ACPI 6.5 header, copied from Acpi64.h.
2. Added CORE_PIC, LIO_PIC ,etc. tables to MADT.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 

Chao Li (2):
  MdePkg: Add ACPI 6.5 header
  MdePkg: Added serveral tables to MATD used by LoongArch64

 MdePkg/Include/IndustryStandard/Acpi.h   |3 +-
 MdePkg/Include/IndustryStandard/Acpi65.h | 3256 ++
 2 files changed, 3258 insertions(+), 1 deletion(-)
 create mode 100644 MdePkg/Include/IndustryStandard/Acpi65.h

-- 
2.27.0



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

[edk2-devel] [PATCH v1 2/2] MdePkg: Added serveral tables to MATD used by LoongArch64

[Chao Li]

Add CORE_PIC, LIO_PIC, HT_PIC, EIO_PIC, MSI_PIC, BIO_PIC and LPC_PIC
tables for LoongArch64 as defined in ACPI SPEC 6.5.

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

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Signed-off-by: Chao Li 
---
 MdePkg/Include/IndustryStandard/Acpi65.h | 95 +++-
 1 file changed, 94 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/IndustryStandard/Acpi65.h 
b/MdePkg/Include/IndustryStandard/Acpi65.h
index fdca5316a9..1e41ae9a27 100644
--- a/MdePkg/Include/IndustryStandard/Acpi65.h
+++ b/MdePkg/Include/IndustryStandard/Acpi65.h
@@ -303,7 +303,7 @@ typedef struct {
 
 //
 // Multiple APIC Description Table APIC structure types
-// All other values between 0x10 and 0x7F are reserved and
+// All other values between 0x18 and 0x7F are reserved and
 // will be ignored by OSPM. 0x80 ~ 0xFF are reserved for OEM.
 //
 #define EFI_ACPI_6_5_PROCESSOR_LOCAL_APIC   0x00
@@ -323,6 +323,13 @@ typedef struct {
 #define EFI_ACPI_6_5_GICR   0x0E
 #define EFI_ACPI_6_5_GIC_ITS0x0F
 #define EFI_ACPI_6_5_MULTIPROCESSOR_WAKEUP  0x10
+#define EFI_ACPI_6_5_CORE_PIC   0x11
+#define EFI_ACPI_6_5_LIO_PIC0x12
+#define EFI_ACPI_6_5_HT_PIC 0x13
+#define EFI_ACPI_6_5_EIO_PIC0x14
+#define EFI_ACPI_6_5_MSI_PIC0x15
+#define EFI_ACPI_6_5_BIO_PIC0x16
+#define EFI_ACPI_6_5_LPC_PIC0x17
 
 //
 // APIC Structure Definitions
@@ -617,6 +624,92 @@ typedef struct {
 #define EFI_ACPI_6_5_MULTIPROCESSOR_WAKEUP_MAILBOX_COMMAND_NOOP0x
 #define EFI_ACPI_6_5_MULTIPROCESSOR_WAKEUP_MAILBOX_COMMAND_WAKEUP  0x0001
 
+///
+/// Core Programmable Interrupt Controller
+///
+typedef struct {
+  UINT8 Type;
+  UINT8 Length;
+  UINT8 Version;
+  UINT32ProcessorId;
+  UINT32CoreId;
+  UINT32Flags;
+} EFI_ACPI_6_5_CORE_PIC_STRUCTURE;
+
+///
+/// Legacy I/O Programmable Interrupt Controller
+///
+typedef struct {
+  UINT8 Type;
+  UINT8 Length;
+  UINT8 Version;
+  UINT64Address;
+  UINT16Size;
+  UINT8 Cascade[2];
+  UINT32CascadeMap[2];
+} EFI_ACPI_6_5_LIO_PIC_STRUCTURE;
+
+///
+/// HyperTransport Programmable Interrupt Controller
+///
+typedef struct {
+  UINT8 Type;
+  UINT8 Length;
+  UINT8 Version;
+  UINT64Address;
+  UINT16Size;
+  UINT8 Cascade[8];
+} EFI_ACPI_6_5_HT_PIC_STRUCTURE;
+
+///
+/// Extend I/O Programmable Interrupt Controller
+///
+typedef struct {
+  UINT8 Type;
+  UINT8 Length;
+  UINT8 Version;
+  UINT8 Cascade;
+  UINT8 Node;
+  UINT64NodeMap;
+} EFI_ACPI_6_5_EIO_PIC_STRUCTURE;
+
+///
+/// MSI Programmable Interrupt Controller
+///
+typedef struct {
+  UINT8 Type;
+  UINT8 Length;
+  UINT8 Version;
+  UINT64MsgAddress;
+  UINT32Start;
+  UINT32Count;
+} EFI_ACPI_6_5_MSI_PIC_STRUCTURE;
+
+///
+/// Bridge I/O Programmable Interrupt Controller
+///
+typedef struct {
+  UINT8 Type;
+  UINT8 Length;
+  UINT8 Version;
+  UINT64Address;
+  UINT16Size;
+  UINT16Id;
+  UINT16GsiBase;
+} EFI_ACPI_6_5_BIO_PIC_STRUCTURE;
+
+///
+/// Low Pin Count Programmable Interrupt Controller
+///
+typedef struct {
+  UINT8 Type;
+  UINT8 Length;
+  UINT8 Version;
+  UINT64Address;
+  UINT16Size;
+  UINT8 Cascade;
+} EFI_ACPI_6_5_LPC_PIC_STRUCTURE;
+
 ///
 /// Smart Battery Description Table (SBST)
 ///
-- 
2.27.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98692): https://edk2.groups.io/g/devel/message/98692
Mute This Topic: https://groups.io/mt/96328924/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/2] MdePkg: Add ACPI 6.5 header

[Chao Li]

Create Acpi65.h, which is copied from Acpi64.h, and make the following
changes:

1. Replace all occurences of "6.4/6_4" with "6.5/6_5".
2. Incremented FADT minor revision.
3. Make Acpi65.h the latest ACPI definitions that Acpi.h contains.

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

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Signed-off-by: Chao Li 
---
 MdePkg/Include/IndustryStandard/Acpi.h   |3 +-
 MdePkg/Include/IndustryStandard/Acpi65.h | 3163 ++
 2 files changed, 3165 insertions(+), 1 deletion(-)
 create mode 100644 MdePkg/Include/IndustryStandard/Acpi65.h

diff --git a/MdePkg/Include/IndustryStandard/Acpi.h 
b/MdePkg/Include/IndustryStandard/Acpi.h
index 05969a36b1..a0610d4a4c 100644
--- a/MdePkg/Include/IndustryStandard/Acpi.h
+++ b/MdePkg/Include/IndustryStandard/Acpi.h
@@ -4,6 +4,7 @@
 
   Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
   Copyright (c) 2019 - 2021, ARM Ltd. All rights reserved.
+  Copyright (c) 2023, Loongson Technology Corporation Limited. All rights 
reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -11,6 +12,6 @@
 #ifndef _ACPI_H_
 #define _ACPI_H_
 
-#include 
+#include 
 
 #endif
diff --git a/MdePkg/Include/IndustryStandard/Acpi65.h 
b/MdePkg/Include/IndustryStandard/Acpi65.h
new file mode 100644
index 00..fdca5316a9
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/Acpi65.h
@@ -0,0 +1,3163 @@
+/** @file
+  ACPI 6.5 definitions from the ACPI Specification Revision 6.5 Aug, 2022.
+
+  Copyright (c) 2017 - 2022, Intel Corporation. All rights reserved.
+  Copyright (c) 2019 - 2021, ARM Ltd. All rights reserved.
+  Copyright (c) 2023, Loongson Technology Corporation Limited. All rights 
reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef ACPI_6_5_H_
+#define ACPI_6_5_H_
+
+#include 
+
+//
+// Ensure proper structure formats
+//
+#pragma pack(1)
+
+///
+/// ACPI 6.5 Generic Address Space definition
+///
+typedef struct {
+  UINT8 AddressSpaceId;
+  UINT8 RegisterBitWidth;
+  UINT8 RegisterBitOffset;
+  UINT8 AccessSize;
+  UINT64Address;
+} EFI_ACPI_6_5_GENERIC_ADDRESS_STRUCTURE;
+
+//
+// Generic Address Space Address IDs
+//
+#define EFI_ACPI_6_5_SYSTEM_MEMORY   0x00
+#define EFI_ACPI_6_5_SYSTEM_IO   0x01
+#define EFI_ACPI_6_5_PCI_CONFIGURATION_SPACE 0x02
+#define EFI_ACPI_6_5_EMBEDDED_CONTROLLER 0x03
+#define EFI_ACPI_6_5_SMBUS   0x04
+#define EFI_ACPI_6_5_SYSTEM_CMOS 0x05
+#define EFI_ACPI_6_5_PCI_BAR_TARGET  0x06
+#define EFI_ACPI_6_5_IPMI0x07
+#define EFI_ACPI_6_5_GENERAL_PURPOSE_IO  0x08
+#define EFI_ACPI_6_5_GENERIC_SERIAL_BUS  0x09
+#define EFI_ACPI_6_5_PLATFORM_COMMUNICATION_CHANNEL  0x0A
+#define EFI_ACPI_6_5_FUNCTIONAL_FIXED_HARDWARE   0x7F
+
+//
+// Generic Address Space Access Sizes
+//
+#define EFI_ACPI_6_5_UNDEFINED  0
+#define EFI_ACPI_6_5_BYTE   1
+#define EFI_ACPI_6_5_WORD   2
+#define EFI_ACPI_6_5_DWORD  3
+#define EFI_ACPI_6_5_QWORD  4
+
+//
+// ACPI 6.5 table structures
+//
+
+///
+/// Root System Description Pointer Structure
+///
+typedef struct {
+  UINT64Signature;
+  UINT8 Checksum;
+  UINT8 OemId[6];
+  UINT8 Revision;
+  UINT32RsdtAddress;
+  UINT32Length;
+  UINT64XsdtAddress;
+  UINT8 ExtendedChecksum;
+  UINT8 Reserved[3];
+} EFI_ACPI_6_5_ROOT_SYSTEM_DESCRIPTION_POINTER;
+
+///
+/// RSD_PTR Revision (as defined in ACPI 6.5 spec.)
+///
+#define EFI_ACPI_6_5_ROOT_SYSTEM_DESCRIPTION_POINTER_REVISION  0x02 ///< 
ACPISpec (Revision 6.5) says current value is 2
+
+///
+/// Common table header, this prefaces all ACPI tables, including FACS, but
+/// excluding the RSD PTR structure
+///
+typedef struct {
+  UINT32Signature;
+  UINT32Length;
+} EFI_ACPI_6_5_COMMON_HEADER;
+
+//
+// Root System Description Table
+// No definition needed as it is a common description table header, the same 
with
+// EFI_ACPI_DESCRIPTION_HEADER, followed by a variable number of UINT32 table 
pointers.
+//
+
+///
+/// RSDT Revision (as defined in ACPI 6.5 spec.)
+///
+#define EFI_ACPI_6_5_ROOT_SYSTEM_DESCRIPTION_TABLE_REVISION  0x01
+
+//
+// Extended System Description Table
+// No definition needed as it is a common description table header, the same 
with
+// EFI_ACPI_DESCRIPTION_HEADER, followed by a variable number of UINT64 table 
pointers.
+//
+
+///
+/// XSDT Revision (as defined in ACPI 6.5 spec.)
+///
+#define EFI_ACPI_6_5_EXTENDED_SYSTEM_DESCRIPTION_TABLE_REVISION  0x01
+
+///
+/// Fixed ACPI Description Table Structure (FADT)
+///
+typedef struct {
+  EFI_ACPI_DESCRIPTION_HEADER   Header;
+  UINT32FirmwareCtrl;
+  UINT32Dsdt;
+  UINT8 Reserved0;
+  UINT8 

Re: [edk2-devel] [PATCH V3 3/4] OvmfPkg/IntelTdx: Enable separate-fv in IntelTdx/IntelTdxX64.fdf

[Min Xu]

On January 17, 2023 6:57 PM, Gerd Hoffmann wrote:
> 
> > -INF
> MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDx
> e.inf
> 
> If you move the gfx console driver you can move the gfx hardware drivers
> too:
> 
>   OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
>   OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
>   OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
> 
Do you mean these 3 gfx hardware drivers should be in NCCFV as 
GraphicsConsoleDxe is? They're are all in NCCFV. 
https://github.com/mxu9/edk2/blob/Separate-Fv.v3/OvmfPkg/IntelTdx/IntelTdxX64.fdf#L298
https://github.com/mxu9/edk2/blob/Separate-Fv.v3/OvmfPkg/IntelTdx/IntelTdxX64.fdf#L330-L333

Thanks
Min




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98693): https://edk2.groups.io/g/devel/message/98693
Mute This Topic: https://groups.io/mt/96319665/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 0/7] Enable Tdx measurement in OvmfPkgX64

[Min Xu]

On January 17, 2023 7:22 PM, Gerd Hoffmann wrote:
> 
> > Patch #2:
> >   Introduce TdxHelperLib which provides helper functions for td-guest.
> 
> > Patch #6:
> >   ProcessTdxHobList is moved to TdxHelperLib and is renamed as
> >   TdxHelperProcessTdHob(). So the duplicated codes are deleted in this
> >   patch.
> 
> This is a unreview-able mess.  Please create a separate patch which moves the
> code to TdxHelperLib, without any code modifications.
> Should code changes be needed do them incrementally on top if this.
Thanks for the comments. I will re-org the patches in the next version.

Thanks
Min


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

[edk2-devel] [OVMF] What would be the best way to make PcdPciMmio64Size dynamic?

[Boeuf, Sebastien]

Hi,

Looking at the hardcoded limitation provided by PcdPciMmio64Size
(32GiB), I was wondering what would be the best approach to make this a
bit more dynamic?

I know that for QEMU, the fw_cfg mechanism can be used to override the
value of PcdPciMmio64Size, but this isn't something Cloud Hypervisor or
other VMMs can implement given they don't support fw_cfg at all.

Would it be acceptable to dynamically compute PcdPciMmio64Size from the
physical address space? Given the reason why PcdPciMmio64Size can't be
increased is to make sure it can support host with small address space
(such as 36 bits), we could introduce a very simple function that would
determine the available address space and consider PcdPciMmio64Size
being half the size.

I'm not sure if PcdPciMmio64Size should still be provided or not, as a
default value to fallback on.

Please let me know your thoughts on this and I can start preparing a
patch.

Thanks,
Sebastien
-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 5 208 026.16 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


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

Re: [edk2-devel] [PATCH v4 1/5] OvmfPkg/PlatformInitLib: Add PlatformScanE820 and GetFirstNonAddressCB

[Laszlo Ersek]

On 1/17/23 13:16, Gerd Hoffmann wrote:
> First step replacing the PlatformScanOrAdd64BitE820Ram() function.
> 
> Add a PlatformScanE820() function which loops over the e280 entries
> from FwCfg and calls a callback for each of them.
> 
> Add a GetFirstNonAddressCB() function which will store the first free
> address (right after the last RAM block) in
> PlatformInfoHob->FirstNonAddress.  This replaces calls to
> PlatformScanOrAdd64BitE820Ram() with non-NULL MaxAddress.
> 
> Write any actions done (setting FirstNonAddress) to the firmware log
> with INFO loglevel.
> 
> Also drop local FirstNonAddress variables and use
> PlatformInfoHob->FirstNonAddress instead everywhere.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/Library/PlatformInitLib/MemDetect.c | 115 
>  1 file changed, 92 insertions(+), 23 deletions(-)
> 
> diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c 
> b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> index 882805269b3e..1ea91f78cefd 100644
> --- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> +++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> @@ -251,6 +251,83 @@ PlatformScanOrAdd64BitE820Ram (
>return EFI_SUCCESS;
>  }
>  
> +typedef VOID (*E820_SCAN_CALLBACK) (
> +  EFI_E820_ENTRY64   *E820Entry,
> +  EFI_HOB_PLATFORM_INFO  *PlatformInfoHob
> +  );
> +
> +/**
> +  Store first address not used by e820 RAM entries in
> +  PlatformInfoHob->FirstNonAddress
> +**/
> +VOID
> +PlatformGetFirstNonAddressCB (
> +  IN EFI_E820_ENTRY64   *E820Entry,
> +  IN OUT EFI_HOB_PLATFORM_INFO  *PlatformInfoHob
> +  )
> +{
> +  UINT64  Candidate;
> +
> +  if (E820Entry->Type != EfiAcpiAddressRangeMemory) {
> +return;
> +  }
> +
> +  Candidate = E820Entry->BaseAddr + E820Entry->Length;
> +  if (PlatformInfoHob->FirstNonAddress < Candidate) {
> +DEBUG ((DEBUG_INFO, "%a: FirstNonAddress=0x%Lx\n", __FUNCTION__, 
> Candidate));
> +PlatformInfoHob->FirstNonAddress = Candidate;
> +  }
> +}
> +
> +/**
> +  Iterate over the entries in QEMU's fw_cfg E820 RAM map, call the
> +  passed callback for each entry.
> +
> +  @param[in] Callback  The callback function to be called.
> +
> +  @param[in out]  PlatformInfoHob  PlatformInfo struct which is passed
> +   through to the callback.
> +
> +  @retval EFI_SUCCESS  The fw_cfg E820 RAM map was found and 
> processed.
> +
> +  @retval EFI_PROTOCOL_ERROR   The RAM map was found, but its size 
> wasn't a
> +   whole multiple of 
> sizeof(EFI_E820_ENTRY64). No
> +   RAM entry was processed.
> +
> +  @return  Error codes from QemuFwCfgFindFile(). No 
> RAM
> +   entry was processed.
> +**/
> +STATIC
> +EFI_STATUS
> +PlatformScanE820 (
> +  IN  E820_SCAN_CALLBACK Callback,
> +  IN OUT  EFI_HOB_PLATFORM_INFO  *PlatformInfoHob
> +  )
> +{
> +  EFI_STATUSStatus;
> +  FIRMWARE_CONFIG_ITEM  FwCfgItem;
> +  UINTN FwCfgSize;
> +  EFI_E820_ENTRY64  E820Entry;
> +  UINTN Processed;
> +
> +  Status = QemuFwCfgFindFile ("etc/e820", &FwCfgItem, &FwCfgSize);
> +  if (EFI_ERROR (Status)) {
> +return Status;
> +  }
> +
> +  if (FwCfgSize % sizeof E820Entry != 0) {
> +return EFI_PROTOCOL_ERROR;
> +  }
> +
> +  QemuFwCfgSelectItem (FwCfgItem);
> +  for (Processed = 0; Processed < FwCfgSize; Processed += sizeof E820Entry) {
> +QemuFwCfgReadBytes (sizeof E820Entry, &E820Entry);
> +Callback (&E820Entry, PlatformInfoHob);
> +  }
> +
> +  return EFI_SUCCESS;
> +}
> +
>  /**
>Returns PVH memmap
>  
> @@ -384,23 +461,17 @@ PlatformGetSystemMemorySizeAbove4gb (
>Return the highest address that DXE could possibly use, plus one.
>  **/
>  STATIC
> -UINT64
> +VOID
>  PlatformGetFirstNonAddress (
>IN OUT  EFI_HOB_PLATFORM_INFO  *PlatformInfoHob
>)
>  {
> -  UINT64FirstNonAddress;
>UINT32FwCfgPciMmio64Mb;
>EFI_STATUSStatus;
>FIRMWARE_CONFIG_ITEM  FwCfgItem;
>UINTN FwCfgSize;
>UINT64HotPlugMemoryEnd;
>  
> -  //
> -  // set FirstNonAddress to suppress incorrect compiler/analyzer warnings
> -  //
> -  FirstNonAddress = 0;
> -
>//
>// If QEMU presents an E820 map, then get the highest exclusive >=4GB RAM
>// address from it. This can express an address >= 4GB+1TB.
> @@ -408,9 +479,10 @@ PlatformGetFirstNonAddress (
>// Otherwise, get the flat size of the memory above 4GB from the CMOS 
> (which
>// can only express a size smaller than 1TB), and add it to 4GB.
>//
> -  Status = PlatformScanOrAdd64BitE820Ram (FALSE, NULL, &FirstNonAddress);
> +  PlatformInfoHob->FirstNonAddress = BASE_4GB;
> +  Status   = PlatformScanE820 
> (PlatformGetFirstNonAddressCB, PlatformInfoHob);
>if (EFI_ERROR (Status)) {
> -FirstNonAddress = BASE_4GB + PlatformGetSyst

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

[Guo Dong]

Reviewed-by: Guo Dong 

-Original Message-
From: Liu, KasimX  
Sent: Tuesday, January 17, 2023 3:41 AM
To: devel@edk2.groups.io
Cc: Liu, KasimX ; Dong, Guo ; Ni, Ray 
; Lu, James ; Guo, Gua 
Subject: [PATCH] UefiPayloadPkg: Set RTC dynamic PCD to PeiPCDdatabase

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/PayloadLoaderPeim/PayloadLoaderPeim.inf | 5 +
 1 file changed, 5 insertions(+)

diff --git a/UefiPayloadPkg/PayloadLoaderPeim/PayloadLoaderPeim.inf 
b/UefiPayloadPkg/PayloadLoaderPeim/PayloadLoaderPeim.inf
index 73f76064a0..06e83dbadc 100644
--- a/UefiPayloadPkg/PayloadLoaderPeim/PayloadLoaderPeim.inf
+++ b/UefiPayloadPkg/PayloadLoaderPeim/PayloadLoaderPeim.inf
@@ -37,6 +37,7 @@
 [Packages]   MdePkg/MdePkg.dec   MdeModulePkg/MdeModulePkg.dec+  
PcAtChipsetPkg/PcAtChipsetPkg.dec   UefiPayloadPkg/UefiPayloadPkg.dec  
[LibraryClasses]@@ -52,6 +53,10 @@
 [Ppis]   gEfiPeiLoadFilePpiGuid ## PRODUCES +[Pcd]+  
gPcAtChipsetPkgTokenSpaceGuid.PcdRtcIndexRegister+  
gPcAtChipsetPkgTokenSpaceGuid.PcdRtcTargetRegister+ [Guids]   
gUniversalPayloadExtraDataGuid ## PRODUCES -- 
2.32.0.windows.2



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

Re: [edk2-devel] [OVMF] What would be the best way to make PcdPciMmio64Size dynamic?

[Gerd Hoffmann]

On Tue, Jan 17, 2023 at 02:10:08PM +, Boeuf, Sebastien wrote:
> Hi,
> 
> Looking at the hardcoded limitation provided by PcdPciMmio64Size
> (32GiB), I was wondering what would be the best approach to make this a
> bit more dynamic?
> 
> I know that for QEMU, the fw_cfg mechanism can be used to override the
> value of PcdPciMmio64Size, but this isn't something Cloud Hypervisor or
> other VMMs can implement given they don't support fw_cfg at all.
> 
> Would it be acceptable to dynamically compute PcdPciMmio64Size from the
> physical address space? Given the reason why PcdPciMmio64Size can't be
> increased is to make sure it can support host with small address space
> (such as 36 bits), we could introduce a very simple function that would
> determine the available address space and consider PcdPciMmio64Size
> being half the size.

Sure, check master branch, the code is already there.  Should just be a
matter of wiring up the function calls for cloundhv, and you can
probably call PlatformAddressWidthFromCpuid() with QemuQuirk = false
unconditionally.

take care,
  Gerd



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

Re: [edk2-devel] [PATCH v4 2/5] OvmfPkg/PlatformInitLib: Add PlatformGetLowMemoryCB

[Laszlo Ersek]

On 1/17/23 13:16, Gerd Hoffmann wrote:
> Add PlatformGetLowMemoryCB() callback function for use with
> PlatformScanE820().  It stores the low memory size in
> PlatformInfoHob->LowMemory.  This replaces calls to
> PlatformScanOrAdd64BitE820Ram() with non-NULL LowMemory.
> 
> Write any actions done (setting LowMemory) to the firmware log
> with INFO loglevel.
> 
> Also change PlatformGetSystemMemorySizeBelow4gb() to likewise set
> PlatformInfoHob->LowMemory instead of returning the value.  Update
> all Callers to the new convention.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/Include/Library/PlatformInitLib.h |  3 +-
>  OvmfPkg/Library/PeilessStartupLib/Hob.c   |  3 +-
>  .../PeilessStartupLib/PeilessStartup.c|  7 +-
>  OvmfPkg/Library/PlatformInitLib/MemDetect.c   | 69 +--
>  OvmfPkg/Library/PlatformInitLib/Platform.c|  7 +-
>  OvmfPkg/PlatformPei/MemDetect.c   |  3 +-
>  6 files changed, 59 insertions(+), 33 deletions(-)

Reviewed-by: Laszlo Ersek 




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

Re: [edk2-devel] [PATCH v4 1/5] OvmfPkg/PlatformInitLib: Add PlatformScanE820 and GetFirstNonAddressCB

[Laszlo Ersek]

On 1/17/23 13:16, Gerd Hoffmann wrote:

> +/**
> +  Store first address not used by e820 RAM entries in
> +  PlatformInfoHob->FirstNonAddress
> +**/
> +VOID
> +PlatformGetFirstNonAddressCB (
> +  IN EFI_E820_ENTRY64   *E820Entry,
> +  IN OUT EFI_HOB_PLATFORM_INFO  *PlatformInfoHob
> +  )
> +{
> +  UINT64  Candidate;
> +
> +  if (E820Entry->Type != EfiAcpiAddressRangeMemory) {
> +return;
> +  }
> +
> +  Candidate = E820Entry->BaseAddr + E820Entry->Length;
> +  if (PlatformInfoHob->FirstNonAddress < Candidate) {
> +DEBUG ((DEBUG_INFO, "%a: FirstNonAddress=0x%Lx\n", __FUNCTION__, 
> Candidate));
> +PlatformInfoHob->FirstNonAddress = Candidate;
> +  }
> +}

This could have been made STATIC (like the other three callbacks), but
it's not important.

Laszlo



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

Re: [edk2-devel] [PATCH v4 1/5] OvmfPkg/PlatformInitLib: Add PlatformScanE820 and GetFirstNonAddressCB

[Ard Biesheuvel]

On Tue, 17 Jan 2023 at 15:47, Laszlo Ersek  wrote:
>
> On 1/17/23 13:16, Gerd Hoffmann wrote:
>
> > +/**
> > +  Store first address not used by e820 RAM entries in
> > +  PlatformInfoHob->FirstNonAddress
> > +**/
> > +VOID
> > +PlatformGetFirstNonAddressCB (
> > +  IN EFI_E820_ENTRY64   *E820Entry,
> > +  IN OUT EFI_HOB_PLATFORM_INFO  *PlatformInfoHob
> > +  )
> > +{
> > +  UINT64  Candidate;
> > +
> > +  if (E820Entry->Type != EfiAcpiAddressRangeMemory) {
> > +return;
> > +  }
> > +
> > +  Candidate = E820Entry->BaseAddr + E820Entry->Length;
> > +  if (PlatformInfoHob->FirstNonAddress < Candidate) {
> > +DEBUG ((DEBUG_INFO, "%a: FirstNonAddress=0x%Lx\n", __FUNCTION__, 
> > Candidate));
> > +PlatformInfoHob->FirstNonAddress = Candidate;
> > +  }
> > +}
>
> This could have been made STATIC (like the other three callbacks), but
> it's not important.
>

I can fix that up at merge time

Thanks,


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

Re: [edk2-devel] [PATCH v11 17/17] OfmvPkg: CI: Qemu tests: set CPU to Broadwell

[Yao, Jiewen]

Cool!
Then I suggest to drop patch 17.

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Gerd
> Hoffmann
> Sent: Tuesday, January 17, 2023 8:39 PM
> To: Yao, Jiewen 
> Cc: devel@edk2.groups.io; ostef...@redhat.com; Andrew Fish
> ; Ard Biesheuvel ; Feng,
> Bob C ; Bi, Dandan ; Wang,
> Jian J ; Justen, Jordan L ;
> Leif Lindholm ; Gao, Liming
> ; Kinney, Michael D
> ; Michael Kubacki
> ; Ni, Ray ; Sami
> Mujawar ; Sean Brogan
> ; Chen, Christine ;
> Pawel Polawski ; chris.fern...@outlook.com
> Subject: Re: [edk2-devel] [PATCH v11 17/17] OfmvPkg: CI: Qemu tests: set
> CPU to Broadwell
> 
> On Tue, Jan 17, 2023 at 12:20:16PM +, Yao, Jiewen wrote:
> > I have seen Gerd sent out V4 patch set for #4251. Is that not enough?
> 
> If that is merged first patch 17 should not be needed.
> 
> take care,
>   Gerd
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH v4 5/5] OvmfPkg/PlatformInitLib: reorder PlatformQemuUc32BaseInitialization

[Laszlo Ersek]

On 1/17/23 13:16, Gerd Hoffmann wrote:
> First handle the cases which do not need know the value of
> PlatformInfoHob->LowMemory (microvm and cloudhv).  Then call
> PlatformGetSystemMemorySizeBelow4gb() to get LowMemory.  Finally handle
> the cases (q35 and pc) which need to look at LowMemory,
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/Library/PlatformInitLib/MemDetect.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)

Reviewed-by: Laszlo Ersek 




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

Re: [edk2-devel] [PATCH v11 17/17] OfmvPkg: CI: Qemu tests: set CPU to Broadwell

[Oliver Steffen]

On Tue, Jan 17, 2023 at 3:50 PM Yao, Jiewen  wrote:

> Cool!
> Then I suggest to drop patch 17.
>

Perfectly fine with me.


>
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Gerd
> > Hoffmann
> > Sent: Tuesday, January 17, 2023 8:39 PM
> > To: Yao, Jiewen 
> > Cc: devel@edk2.groups.io; ostef...@redhat.com; Andrew Fish
> > ; Ard Biesheuvel ; Feng,
> > Bob C ; Bi, Dandan ; Wang,
> > Jian J ; Justen, Jordan L <
> jordan.l.jus...@intel.com>;
> > Leif Lindholm ; Gao, Liming
> > ; Kinney, Michael D
> > ; Michael Kubacki
> > ; Ni, Ray ; Sami
> > Mujawar ; Sean Brogan
> > ; Chen, Christine ;
> > Pawel Polawski ; chris.fern...@outlook.com
> > Subject: Re: [edk2-devel] [PATCH v11 17/17] OfmvPkg: CI: Qemu tests: set
> > CPU to Broadwell
> >
> > On Tue, Jan 17, 2023 at 12:20:16PM +, Yao, Jiewen wrote:
> > > I have seen Gerd sent out V4 patch set for #4251. Is that not enough?
> >
> > If that is merged first patch 17 should not be needed.
> >
> > take care,
> >   Gerd
> >
>
>


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

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

[Ard Biesheuvel]

On Tue, 17 Jan 2023 at 13:48, Oliver Steffen  wrote:
>
> Hi Ard, Hi everyone,
>
> Thanks for the work!
>
> But somehow this patch (as it was merged into master branch) does not
> work for me on the ThunderX box we have.
>
> Any idea what could be wrong?

I'm not sure I understand the question. The patch targets ThunderX,
and you are using a ThunderX2.

What were you expecting to happen, and what is happening instead?


> I enabled the erratum during build ;-)
>
> CPU Info:
> # lscpu
> Architecture:   aarch64
>   CPU op-mode(s):   64-bit
>   Byte Order:   Little Endian
> CPU(s): 224
>   On-line CPU(s) list:  0-223
> Vendor ID:  Cavium
>   BIOS Vendor ID:   Cavium Inc.
>   Model name:   ThunderX2 99xx
> BIOS Model name:Cavium ThunderX2(R) CPU CN9975 v2.2 @ 2.0GHz
> Model:  2
> Thread(s) per core: 4
> Core(s) per socket: 28
> Socket(s):  2
> Stepping:   0x1
> BogoMIPS:   400.00
> Flags:  fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics 
> cpuid asimdrdm
> Caches (sum of all):
>   L1d:  1.8 MiB (56 instances)
>   L1i:  1.8 MiB (56 instances)
>   L2:   14 MiB (56 instances)
>   L3:   64 MiB (2 instances)
> [...]
>
> Thanks a lot!
> - Oliver
>
>
> On Tue, Jan 10, 2023 at 1:08 AM dann frazier  
> wrote:
>>
>> On Thu, Jan 05, 2023 at 05:25:28PM +0100, Ard Biesheuvel wrote:
>> > 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|  5 
>> > +
>> >  ArmVirtPkg/Library/ArmPlatformLibQemu/AArch64/ArmPlatformHelper.S | 15 
>> > +++
>> >  2 files changed, 20 insertions(+)
>>
>> FTR, this v2 series also worked for me.
>>
>>   -dann
>>
>> > diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
>> > index f77443229e8e..5dd8b6104cca 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,11 @@ [LibraryClasses.common.UEFI_DRIVER]
>> >UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
>> >
>> >  [BuildOptions]
>> > +!if $(CAVIUM_ERRATUM_27456) == TRUE
>> > +  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 1787d52fbf51..5ac7c732f6ec 100644
>> > --- a/ArmVirtPkg/Library/ArmPlatformLibQemu/AArch64/ArmPlatformHelper.S
>> > +++ b/ArmVirtPkg/Library/ArmPlatformLibQemu/AArch64/ArmPlatformHelper.S
>> > @@ -42,6 +42,21 @@
>> >
>> >
>> >  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 (but not 0xAF)
>> > +   */
>> > +  mrsx0, midr_el1// read the MIDR into X0
>> > +  ubfx   x1, x0, #24, #8 // grab implementor id
>> > +  ubfx   x0, x0, #7, #9  // grab part number bits [11:3]
>> > +  cmpx1, #0x43   // compare implementor id
>> > +  ccmp   x0, #0xA0 >> 3, #0, eq  // compare part# bits [11:3]
>> > +  b.eq   0f
>> > +#endif
>> >mrsx0, CurrentEL   // check current exception level
>> >tbnz   x0, #3, 0f  // omit early ID map if above EL1
>> >
>>
>>
>>
>>
>>
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98705): https://edk2.groups.io/g/devel/message/98705
Mute This Topic: https://groups.io/mt/96075174/21656
Group Owner: de

Re: [edk2-devel] [PATCH v4 3/5] OvmfPkg/PlatformInitLib: Add PlatformAddHobCB

[Laszlo Ersek]

On 1/17/23 13:16, Gerd Hoffmann wrote:
> Add PlatformAddHobCB() callback function for use with
> PlatformScanE820().  It adds HOBs for high memory and reservations (low
> memory is handled elsewhere because there are some special cases to
> consider).  This replaces calls to PlatformScanOrAdd64BitE820Ram() with
> AddHighHobs = TRUE.
> 
> Write any actions done (adding HOBs, skip unknown types) to the firmware
> log with INFO loglevel.
> 
> Also remove PlatformScanOrAdd64BitE820Ram() which is not used any more.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/Library/PlatformInitLib/MemDetect.c | 185 +---
>  1 file changed, 47 insertions(+), 138 deletions(-)
> 
> diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c 
> b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> index dfaa05a1c24f..c626fc49cf6c 100644
> --- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> +++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> @@ -112,143 +112,6 @@ PlatformQemuUc32BaseInitialization (
>}
>  }
>  
> -/**
> -  Iterate over the RAM entries in QEMU's fw_cfg E820 RAM map that start 
> outside
> -  of the 32-bit address range.
> -
> -  Find the highest exclusive >=4GB RAM address, or produce memory resource
> -  descriptor HOBs for RAM entries that start at or above 4GB.
> -
> -  @param[out] MaxAddress  If MaxAddress is NULL, then 
> PlatformScanOrAdd64BitE820Ram()
> -  produces memory resource descriptor HOBs for RAM
> -  entries that start at or above 4GB.
> -
> -  Otherwise, MaxAddress holds the highest exclusive
> -  >=4GB RAM address on output. If QEMU's fw_cfg E820
> -  RAM map contains no RAM entry that starts outside 
> of
> -  the 32-bit address range, then MaxAddress is 
> exactly
> -  4GB on output.
> -
> -  @retval EFI_SUCCESS The fw_cfg E820 RAM map was found and 
> processed.
> -
> -  @retval EFI_PROTOCOL_ERROR  The RAM map was found, but its size wasn't a
> -  whole multiple of sizeof(EFI_E820_ENTRY64). No
> -  RAM entry was processed.
> -
> -  @return Error codes from QemuFwCfgFindFile(). No RAM
> -  entry was processed.
> -**/
> -STATIC
> -EFI_STATUS
> -PlatformScanOrAdd64BitE820Ram (
> -  IN BOOLEAN  AddHighHob,
> -  OUT UINT64  *LowMemory OPTIONAL,
> -  OUT UINT64  *MaxAddress OPTIONAL
> -  )
> -{
> -  EFI_STATUSStatus;
> -  FIRMWARE_CONFIG_ITEM  FwCfgItem;
> -  UINTN FwCfgSize;
> -  EFI_E820_ENTRY64  E820Entry;
> -  UINTN Processed;
> -
> -  Status = QemuFwCfgFindFile ("etc/e820", &FwCfgItem, &FwCfgSize);
> -  if (EFI_ERROR (Status)) {
> -return Status;
> -  }
> -
> -  if (FwCfgSize % sizeof E820Entry != 0) {
> -return EFI_PROTOCOL_ERROR;
> -  }
> -
> -  if (LowMemory != NULL) {
> -*LowMemory = 0;
> -  }
> -
> -  if (MaxAddress != NULL) {
> -*MaxAddress = BASE_4GB;
> -  }
> -
> -  QemuFwCfgSelectItem (FwCfgItem);
> -  for (Processed = 0; Processed < FwCfgSize; Processed += sizeof E820Entry) {
> -QemuFwCfgReadBytes (sizeof E820Entry, &E820Entry);
> -DEBUG ((
> -  DEBUG_VERBOSE,
> -  "%a: Base=0x%Lx Length=0x%Lx Type=%u\n",
> -  __FUNCTION__,
> -  E820Entry.BaseAddr,
> -  E820Entry.Length,
> -  E820Entry.Type
> -  ));
> -if (E820Entry.Type == EfiAcpiAddressRangeMemory) {
> -  if (AddHighHob && (E820Entry.BaseAddr >= BASE_4GB)) {
> -UINT64  Base;
> -UINT64  End;
> -
> -//
> -// Round up the start address, and round down the end address.
> -//
> -Base = ALIGN_VALUE (E820Entry.BaseAddr, (UINT64)EFI_PAGE_SIZE);
> -End  = (E820Entry.BaseAddr + E820Entry.Length) &
> -   ~(UINT64)EFI_PAGE_MASK;
> -if (Base < End) {
> -  PlatformAddMemoryRangeHob (Base, End);
> -  DEBUG ((
> -DEBUG_VERBOSE,
> -"%a: PlatformAddMemoryRangeHob [0x%Lx, 0x%Lx)\n",
> -__FUNCTION__,
> -Base,
> -End
> -));
> -}
> -  }
> -
> -  if (MaxAddress || LowMemory) {
> -UINT64  Candidate;
> -
> -Candidate = E820Entry.BaseAddr + E820Entry.Length;
> -if (MaxAddress && (Candidate > *MaxAddress)) {
> -  *MaxAddress = Candidate;
> -  DEBUG ((
> -DEBUG_VERBOSE,
> -"%a: MaxAddress=0x%Lx\n",
> -__FUNCTION__,
> -*MaxAddress
> -));
> -}
> -
> -if (LowMemory && (Candidate > *LowMemory) && (Candidate < BASE_4GB)) 
> {
> -  *LowMemory = Candidate;
> -  DEBUG ((
> -DEBUG_VERBOSE,
> -"%a: LowMemory=0x%Lx\n",
> -__FUNCTION__,
> -*LowMemory
> -));
> -}
> -  }
> -} else if (E820Entry.Ty

Re: [edk2-devel] [PATCH v4 3/5] OvmfPkg/PlatformInitLib: Add PlatformAddHobCB

[Ard Biesheuvel]

On Tue, 17 Jan 2023 at 16:03, Laszlo Ersek  wrote:
>
> On 1/17/23 13:16, Gerd Hoffmann wrote:
> > Add PlatformAddHobCB() callback function for use with
> > PlatformScanE820().  It adds HOBs for high memory and reservations (low
> > memory is handled elsewhere because there are some special cases to
> > consider).  This replaces calls to PlatformScanOrAdd64BitE820Ram() with
> > AddHighHobs = TRUE.
> >
> > Write any actions done (adding HOBs, skip unknown types) to the firmware
> > log with INFO loglevel.
> >
> > Also remove PlatformScanOrAdd64BitE820Ram() which is not used any more.
> >
> > Signed-off-by: Gerd Hoffmann 
> > ---
> >  OvmfPkg/Library/PlatformInitLib/MemDetect.c | 185 +---
> >  1 file changed, 47 insertions(+), 138 deletions(-)
> >
> > diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c 
> > b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> > index dfaa05a1c24f..c626fc49cf6c 100644
> > --- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> > +++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> > @@ -112,143 +112,6 @@ PlatformQemuUc32BaseInitialization (
> >}
> >  }
> >
> > -/**
> > -  Iterate over the RAM entries in QEMU's fw_cfg E820 RAM map that start 
> > outside
> > -  of the 32-bit address range.
> > -
> > -  Find the highest exclusive >=4GB RAM address, or produce memory resource
> > -  descriptor HOBs for RAM entries that start at or above 4GB.
> > -
> > -  @param[out] MaxAddress  If MaxAddress is NULL, then 
> > PlatformScanOrAdd64BitE820Ram()
> > -  produces memory resource descriptor HOBs for RAM
> > -  entries that start at or above 4GB.
> > -
> > -  Otherwise, MaxAddress holds the highest exclusive
> > -  >=4GB RAM address on output. If QEMU's fw_cfg 
> > E820
> > -  RAM map contains no RAM entry that starts 
> > outside of
> > -  the 32-bit address range, then MaxAddress is 
> > exactly
> > -  4GB on output.
> > -
> > -  @retval EFI_SUCCESS The fw_cfg E820 RAM map was found and 
> > processed.
> > -
> > -  @retval EFI_PROTOCOL_ERROR  The RAM map was found, but its size wasn't a
> > -  whole multiple of sizeof(EFI_E820_ENTRY64). 
> > No
> > -  RAM entry was processed.
> > -
> > -  @return Error codes from QemuFwCfgFindFile(). No RAM
> > -  entry was processed.
> > -**/
> > -STATIC
> > -EFI_STATUS
> > -PlatformScanOrAdd64BitE820Ram (
> > -  IN BOOLEAN  AddHighHob,
> > -  OUT UINT64  *LowMemory OPTIONAL,
> > -  OUT UINT64  *MaxAddress OPTIONAL
> > -  )
> > -{
> > -  EFI_STATUSStatus;
> > -  FIRMWARE_CONFIG_ITEM  FwCfgItem;
> > -  UINTN FwCfgSize;
> > -  EFI_E820_ENTRY64  E820Entry;
> > -  UINTN Processed;
> > -
> > -  Status = QemuFwCfgFindFile ("etc/e820", &FwCfgItem, &FwCfgSize);
> > -  if (EFI_ERROR (Status)) {
> > -return Status;
> > -  }
> > -
> > -  if (FwCfgSize % sizeof E820Entry != 0) {
> > -return EFI_PROTOCOL_ERROR;
> > -  }
> > -
> > -  if (LowMemory != NULL) {
> > -*LowMemory = 0;
> > -  }
> > -
> > -  if (MaxAddress != NULL) {
> > -*MaxAddress = BASE_4GB;
> > -  }
> > -
> > -  QemuFwCfgSelectItem (FwCfgItem);
> > -  for (Processed = 0; Processed < FwCfgSize; Processed += sizeof 
> > E820Entry) {
> > -QemuFwCfgReadBytes (sizeof E820Entry, &E820Entry);
> > -DEBUG ((
> > -  DEBUG_VERBOSE,
> > -  "%a: Base=0x%Lx Length=0x%Lx Type=%u\n",
> > -  __FUNCTION__,
> > -  E820Entry.BaseAddr,
> > -  E820Entry.Length,
> > -  E820Entry.Type
> > -  ));
> > -if (E820Entry.Type == EfiAcpiAddressRangeMemory) {
> > -  if (AddHighHob && (E820Entry.BaseAddr >= BASE_4GB)) {
> > -UINT64  Base;
> > -UINT64  End;
> > -
> > -//
> > -// Round up the start address, and round down the end address.
> > -//
> > -Base = ALIGN_VALUE (E820Entry.BaseAddr, (UINT64)EFI_PAGE_SIZE);
> > -End  = (E820Entry.BaseAddr + E820Entry.Length) &
> > -   ~(UINT64)EFI_PAGE_MASK;
> > -if (Base < End) {
> > -  PlatformAddMemoryRangeHob (Base, End);
> > -  DEBUG ((
> > -DEBUG_VERBOSE,
> > -"%a: PlatformAddMemoryRangeHob [0x%Lx, 0x%Lx)\n",
> > -__FUNCTION__,
> > -Base,
> > -End
> > -));
> > -}
> > -  }
> > -
> > -  if (MaxAddress || LowMemory) {
> > -UINT64  Candidate;
> > -
> > -Candidate = E820Entry.BaseAddr + E820Entry.Length;
> > -if (MaxAddress && (Candidate > *MaxAddress)) {
> > -  *MaxAddress = Candidate;
> > -  DEBUG ((
> > -DEBUG_VERBOSE,
> > -"%a: MaxAddress=0x%Lx\n",
> > -__FUNCTION__,
> > -*MaxAddress
> > -));
> > -}
> > -
> > -   

Re: [edk2-devel] [PATCH v4 4/5] OvmfPkg/PlatformInitLib: Add PlatformReservationConflictCB

[Laszlo Ersek]

On 1/17/23 13:16, Gerd Hoffmann wrote:
> Add PlatformReservationConflictCB() callback function for use with
> PlatformScanE820().  It checks whenever the 64bit PCI MMIO window
> overlaps with a reservation from qemu.  If so move down the MMIO window
> to resolve the conflict.
> 
> Write any actions done (moving mmio window) to the firmware log with
> INFO loglevel.
> 
> This happens on (virtual) AMD machines with 1TB address space,
> because the AMD IOMMU uses an address window just below 1TB.
> 
> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=4251
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/Library/PlatformInitLib/MemDetect.c | 45 +
>  1 file changed, 45 insertions(+)
> 
> diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c 
> b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> index c626fc49cf6c..1ce692e77ecb 100644
> --- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> +++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> @@ -213,6 +213,50 @@ PlatformAddHobCB (
>}
>  }
>  
> +/**
> +  Check whenever the 64bit PCI MMIO window overlaps with a reservation
> +  from qemu.  If so move down the MMIO window to resolve the conflict.
> +
> +  This happens on (virtual) AMD machines with 1TB address space,
> +  because the AMD IOMMU uses an address window just below 1TB.
> +**/
> +STATIC VOID
> +PlatformReservationConflictCB (
> +  IN EFI_E820_ENTRY64   *E820Entry,
> +  IN OUT EFI_HOB_PLATFORM_INFO  *PlatformInfoHob
> +  )
> +{
> +  UINT64  IntersectionBase;
> +  UINT64  IntersectionEnd;
> +  UINT64  NewBase;
> +
> +  IntersectionBase = MAX (
> +   E820Entry->BaseAddr,
> +   PlatformInfoHob->PcdPciMmio64Base
> +   );
> +  IntersectionEnd = MIN (
> +  E820Entry->BaseAddr + E820Entry->Length,
> +  PlatformInfoHob->PcdPciMmio64Base +
> +  PlatformInfoHob->PcdPciMmio64Size
> +  );
> +
> +  if (IntersectionBase >= IntersectionEnd) {
> +return;  // no overlap
> +  }
> +
> +  NewBase = E820Entry->BaseAddr - PlatformInfoHob->PcdPciMmio64Size;
> +  NewBase = NewBase & ~(PlatformInfoHob->PcdPciMmio64Size - 1);
> +
> +  DEBUG ((
> +DEBUG_INFO,
> +"%a: move mmio: 0x%Lx => %Lx\n",
> +__FUNCTION__,
> +PlatformInfoHob->PcdPciMmio64Base,
> +NewBase
> +));
> +  PlatformInfoHob->PcdPciMmio64Base = NewBase;
> +}
> +
>  /**
>Iterate over the entries in QEMU's fw_cfg E820 RAM map, call the
>passed callback for each entry.
> @@ -650,6 +694,7 @@ PlatformDynamicMmioWindow (
>  DEBUG ((DEBUG_INFO, "%a:   MMIO Space 0x%Lx (%Ld GB)\n", __func__, 
> MmioSpace, RShiftU64 (MmioSpace, 30)));
>  PlatformInfoHob->PcdPciMmio64Size = MmioSpace;
>  PlatformInfoHob->PcdPciMmio64Base = AddrSpace - MmioSpace;
> +PlatformScanE820 (PlatformReservationConflictCB, PlatformInfoHob);
>} else {
>  DEBUG ((DEBUG_INFO, "%a: using classic mmio window\n", __func__));
>}

Reviewed-by: Laszlo Ersek 



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

[Attar, AbdulLateef (Abdul Lateef) via groups.io]

[AMD Official Use Only - General]

Hi Maintainers,
Could you please review and merge the below patch?
Thanks
AbduL

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Abdul Lateef 
Attar via groups.io
Sent: 15 November 2022 17:34
To: devel@edk2.groups.io
Cc: Eric Dong ; Liming Gao ; 
Isaac Oram 
Subject: [edk2-devel] [PATCH 0/2] BoardModulePkg: BoardBdsHookLib GCC fix

Caution: This message originated from an External Source. Use proper caution 
when opening attachments, clicking links, or responding.


 Patch 1: Fix the GCC boot time page fault exception,
  by copying PcdGetPtr to local variables.
 Patch 2: Adds PCD to hold the UEFI shell GUID value
  and description, to provide flexibility to load
  any UEFI application as UEFI shell.

PR : 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2-platforms%2Fpull%2F50&data=05%7C01%7CAbdulLateef.Attar%40amd.com%7Cbe5dc1f4cbf941fa88de08dac723cf3d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638041253865897866%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LwpBjZqUi%2BMCh60aERuXCusAPrKNYk0vbpLrg7dCYic%3D&reserved=0

Cc: Eric Dong 
Cc: Liming Gao 
CC: Isaac Oram 

Abdul Lateef Attar (2):
  BoardModulePkg: Copy device path before processing
  BoardModulePkg: Adds PCD to load UEFI Shell image

 .../Intel/MinPlatformPkg/MinPlatformPkg.dec   |  5 +
 .../BoardBdsHookLib/BoardBdsHookLib.inf   |  3 +++
 .../Library/BoardBdsHookLib/BoardBdsHookLib.c | 19 ++-  
.../Library/BoardBdsHookLib/BoardBootOption.c |  8 +---
 4 files changed, 27 insertions(+), 8 deletions(-)

--
2.25.1








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

[edk2-devel] [PATCH] UefiPayloadPkg: Set RTC dynamic PCD to PeiPCDdatabase

[kasimx . liu]

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/PayloadLoaderPeim/PayloadLoaderPeim.inf | 5 +
 1 file changed, 5 insertions(+)

diff --git a/UefiPayloadPkg/PayloadLoaderPeim/PayloadLoaderPeim.inf 
b/UefiPayloadPkg/PayloadLoaderPeim/PayloadLoaderPeim.inf
index 73f76064a0..06e83dbadc 100644
--- a/UefiPayloadPkg/PayloadLoaderPeim/PayloadLoaderPeim.inf
+++ b/UefiPayloadPkg/PayloadLoaderPeim/PayloadLoaderPeim.inf
@@ -37,6 +37,7 @@
 [Packages]
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
+  PcAtChipsetPkg/PcAtChipsetPkg.dec
   UefiPayloadPkg/UefiPayloadPkg.dec
 
 [LibraryClasses]
@@ -52,6 +53,10 @@
 [Ppis]
   gEfiPeiLoadFilePpiGuid ## PRODUCES
 
+[Pcd]
+  gPcAtChipsetPkgTokenSpaceGuid.PcdRtcIndexRegister
+  gPcAtChipsetPkgTokenSpaceGuid.PcdRtcTargetRegister
+
 [Guids]
   gUniversalPayloadExtraDataGuid ## PRODUCES
 
-- 
2.32.0.windows.2



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

Re: [edk2-devel] [PATCH v4 3/5] OvmfPkg/PlatformInitLib: Add PlatformAddHobCB

[Ard Biesheuvel]

On Tue, 17 Jan 2023 at 16:03, Laszlo Ersek  wrote:
>
> On 1/17/23 13:16, Gerd Hoffmann wrote:

> > +  PlatformAddMemoryRangeHob (Base, End);
> > +}
> > +  }
> > +
>
> (2) Still not sure if this empty line is intentional (it may be, you
> didn't answer it under the v2 review AFAICT).
>

As it turns out, yes. Uncrustify demands a newline here, or else 


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

Re: [edk2-devel] [PATCH v4 0/5] OvmfPkg: check 64bit mmio window for resource conflicts

[Ard Biesheuvel]

On Tue, 17 Jan 2023 at 13:16, Gerd Hoffmann  wrote:
>
> v4:
>  - made mmio window move a bit more robust.
>  - dropped patches for moving MMCONFIG, they'll come as separate patch
>series later.
>
> v3:
>  - Add / fix comments, add notes to commit messages.
>  - Make functions static.
>  - Logging tweaks.
>  - Fix windows compiler warnings.
>  - Add patches (5,6,7) moving MMCONFIG to 0xe000, simplifying code
>and reducing differences between 'pc' and 'q35' along the way.
>Eventually we want split them into a separate series, but some of
>this was discussed in v2 review, so I just appended them here for
>now.
> v2:
>  - split up PlatformScanOrAdd64BitE820Ram() into scan function with
>callbacks, store results in PlatformInfoHob struct.
>
> Gerd Hoffmann (5):
>   OvmfPkg/PlatformInitLib: Add PlatformScanE820 and GetFirstNonAddressCB
>   OvmfPkg/PlatformInitLib: Add PlatformGetLowMemoryCB
>   OvmfPkg/PlatformInitLib: Add PlatformAddHobCB
>   OvmfPkg/PlatformInitLib: Add PlatformReservationConflictCB
>   OvmfPkg/PlatformInitLib: reorder PlatformQemuUc32BaseInitialization
>

Merged now, thanks,


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98712): https://edk2.groups.io/g/devel/message/98712
Mute This Topic: https://groups.io/mt/96328401/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 1/1] AmpereAltraPkg: Update ArmPlatformLib to work with changed ARM_CORE_INFO

[Ard Biesheuvel]

On Tue, 17 Jan 2023 at 13:55, Rebecca Cran  wrote:
>
> I was under the impression that this is becoming a more standard format?
>

If this is not defined in an ARM spec somewhere, we shouldn't add it
to ArmPkg at this point.

> For example, the Neoverse N2 has AFF0 always 0 (it's not hyperthreaded),
> it puts the core ID in AFF1, the cluster ID in AFF2, but since it only
> has a single socket AFF3 is always 0. This differs from older cores
> where the core ID was in AFF0 and the cluster ID in AFF1.
>
> https://developer.arm.com/documentation/102099//AArch64-registers/AArch64-identification-registers/MPIDR-EL1--Multiprocessor-Affinity-Register
>
> Am I mistaken?
>
> --
> Rebecca Cran
>
> On 1/17/23 02:53, Nhi Pham wrote:
> > Hi Rebecca,
> >
> > That's Ampere Altra Family specific MPIDR encoding. So, we could not
> > leverage the definitions in the ArmPkg/Include/Library/ArmLib.h.
> >
> > -Nhi
> >
> > On 1/13/2023 9:40 PM, Rebecca Cran wrote:
> >> On 1/12/23 21:21, Nhi Pham via groups.io wrote:
> >>
> >>> +//
> >>> +// MPIDR manipulation
> >>> +//
> >>> +#define AC01_GET_MPIDR(SocketId, ClusterId, CoreId) \
> >>> +  (((SocketId) << 32) | ((ClusterId) << 16) | ((CoreId) << 8))
> >>> +#define AC01_GET_SOCKET_ID(Mpidr)  (((Mpidr) & ARM_CORE_AFF3) >> 32)
> >>> +#define AC01_GET_CLUSTER_ID(Mpidr) (((Mpidr) & ARM_CORE_AFF2) >> 16)
> >>> +#define AC01_GET_CORE_ID(Mpidr)(((Mpidr) & ARM_CORE_AFF1) >> 8)
> >>> +
> >>
> >> Ideally, this should go in ArmPkg/Include/Library/ArmLib.h, but I'm
> >> not sure how we should handle the older format where the the core was
> >> in the first 8 bits.
> >>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98713): https://edk2.groups.io/g/devel/message/98713
Mute This Topic: https://groups.io/mt/96240088/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] OvmfPkg/PlatformInitLib: catch QEMU's CPU hotplug reg block regression

[Ard Biesheuvel]

On Tue, 17 Jan 2023 at 13:37, Gerd Hoffmann  wrote:
>
>   Hi,
>
> > >> In particular the firmware makes no further decisions based on
> > >> whether QEMU advertized some of these features.
> > >
> > > I was thinking the other way around:  When cpu hotplug is disabled in
> > > qemu it should be safe to skip the whole cpu hotplug checking dance.
> > > See test patch below.
> > >
> > > That would give us a config switch (turn off cpu hotplug support)
> > > which would allow edk2 run on qemu versions with broken cpu hotplug.
> > >
> > > Does the idea look sane or do I miss something?
>
> > This would be wrong.
> >
> > [ detailed description snipped here (but stored for later reference,
> >   thanks for all the details) ]
>
> So, the tl;dr version:  cpu hotplug is older than smi feature
> negotiation, so smi hotplug feature bit being off doesn't imply
> qemu wouldn't hotplug cpus.
>
> So, no easy way out.  Luckily this affects tcg only.
>
> For edk2 ci doing (tcg) efi shell test boots switching to Oliver's
> latest containers with fixed qemu included should handle things
> (latest series just posted).  So once this is in we should be able to
> merge this patch without breaking CI.
>

My head is spinning.

What about running QEMU with only a single CPU, and without any of
these features? Is there really no way we can make that work without
turning OVMF into the timebomb that Laszlo describes?

It's just very annoying that on a non-KVM host and a given QEMU
binary, you might simply be out of luck entirely, and there is no way
you can run OVMF with the fix applied. I would like to avoid that if
possible.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98714): https://edk2.groups.io/g/devel/message/98714
Mute This Topic: https://groups.io/mt/96218818/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] x86/efi: Safely enable unaccepted memory in UEFI

[Dionna Glaze via groups.io]

>
> Why do you call boot with a bootloader a legacy feature?
>

Gerd answered this about EBS called from the bootloader.

> > they'll only get a safe view of the memory map. I don't think it's right
> > to choose unsafe behavior for a legacy setup.
>
> Present memory map with unaccepted memory to OS that doesn't about it is
> perfectly safe. This portion of the memory will be ignored. It is "feature
> not [yet] implemented" case.
>

SNP guest support is already in Linux, and it gets a full view of the
memory given to the VM. If the firmware ever introduces unaccepted
memory, then the kernel's behavior is retroactively broken without the
"accept all if AllowUnacceptedMemory() not called" behavior of the
UEFI.
The memory that existed before becomes ignored. This is not the right
approach IMO.

> > > This patch adds complexity, breaks what works and the only upside will
> > > turn into a dead weight soon.
> > >
> > > There's alternative to add option to instruct firmware to accept all
> > > memory from VMM side. It will serve legacy OS that doesn't know about
> > > unaccepted memory and it is also can be use by latency-sensitive users
> > > later on (analog of qemu -mem-prealloc).
> > >
> >
> > This means that users of a distro that has not enabled unaccepted
> > memory support cannot simply start a VM with the usual command, but
> > instead have to know a baroque extra flag to get access to all the
> > memory that they configured the machine (and for a CSP customer, paid
> > for). That's not a good experience.
>
> New features require enabling. It is not something new.
>

What I'm saying is that you're suggesting a feature _dis_abling
requirement, which is an antipattern. Any SNP user right now would
need to add a "don't use an unimplemented feature" flag to get access
to all its memory again.

> > With GCE at least, you can't (shouldn't) associate the boot feature
> > flag with a disk image because disks are mutable. If a customer
> > upgrades their kernel after initially starting their VM, they can't
> > remove the flag due to the way image annotations work.
>
> I guess a new VM has to be created, right? Doesn't sound like a big deal
> to me.
>

Usually it's not, but the retroactive need to create a new VM once the
firmware adds UEFI v2.9 support with unaccepted memory is a big deal.

> The old will not break with upgraded kernel. Just not get benefit of the
> feature.
>

A user buys access to a high memory VM: 768GiB. They then shut down
and bring it back up on a new firmware that uses unaccepted memory.

That VM goes from 785GiB free memory to 3GiB free memory at boot.

This is because all memory above 4GiB (and nothing there for the
3-4GiB MMIO hole) would be the unknown unaccepted memory type. We need
the accept-all-if-support-not-acked semantics with the protocol.

> > All of this headache goes away by adopting a small patch to the kernel
> > that calls a 0-ary protocol interface and keeping safe acceptance
> > behavior in the firmware. I think Gerd is right here that we should
> > treat it as a transition feature that we can remove later.
>
> Removing a feature is harder than adding one. How do you define that
> "later" has come?
>

Gerd's response of after 6.1-lts EOL is reasonable to me. At the same
time, both SEV-SNP and TDX's Kconfig would need to strictly require
unaccepted memory.

The semantics of the UEFI under the proposed protocol is allowed to
change the default behavior when the protocol is not exposed to the
OS. The default would then be to always introduce unaccepted memory
for TDX and SEV-SNP guests.

To Gerd's point, removing "first in edk2, later in linux too" I think
is backwards. We need all users of the protocol to agree that SEV-SNP
and TDX strictly imply unaccepted memory support. Only then can we
remove the protocol from EDK2.

> Anyway, I think we walk in a circle. I consider it a misfeature. If you
> want still go this path, please add my
>
> Nacked-by: Kirill A. Shutemov 
>

Thanks for your time discussing.


-- 
-Dionna Glaze, PhD (she/her)


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98715): https://edk2.groups.io/g/devel/message/98715
Mute This Topic: https://groups.io/mt/96256524/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 0/3] Add NULL IpmiCommandLib instance

[Igor Kulchytskyy via groups.io]

Series Reviewed-by: Igor Kulchytskyy 

-Original Message-
From: abner.ch...@amd.com 
Sent: Friday, January 13, 2023 1:03 AM
To: devel@edk2.groups.io
Cc: Jian J Wang ; Liming Gao ; 
Nickle Wang ; Igor Kulchytskyy ; Isaac Oram 
; Nate DeSimone 
Subject: [EXTERNAL] [PATCH V2 0/3] Add NULL IpmiCommandLib instance


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

From: Abner Chang 

BZ# 4231

In V2: Address the typos.

This patch adds a NULL instance of IpmiCommandLib to remove the dependence 
between edk2 and edk2-platform packages.

Signed-off-by: Abner Chang 
Cc: Jian J Wang 
Cc: Liming Gao 
Cc: Nickle Wang 
Cc: Igor Kulchytskyy 
Cc: Isaac Oram 
Cc: Nate DeSimone  Abner Chang (3):
  MdeModulePkg/Include: Add IpmiCommandLib header file
  MdeModulePkg/IpmiCommandLib: Add NULL instance library
  MdeModulePkg: Add IpmiCommandLib

 MdeModulePkg/MdeModulePkg.dec |   5 +
 MdeModulePkg/MdeModulePkg.dsc |   3 +
 .../BaseIpmiCommandLibNull.inf|  34 +
 MdeModulePkg/Include/Library/IpmiCommandLib.h | 683 ++
 .../IpmiCommandLibNetFnApp.c  | 252 +++
 .../IpmiCommandLibNetFnChassis.c  | 123 
 .../IpmiCommandLibNetFnStorage.c  | 248 +++
 .../IpmiCommandLibNetFnTransport.c| 100 +++
 8 files changed, 1448 insertions(+)
 create mode 100644 
MdeModulePkg/Library/BaseIpmiCommandLibNull/BaseIpmiCommandLibNull.inf
 create mode 100644 MdeModulePkg/Include/Library/IpmiCommandLib.h
 create mode 100644 
MdeModulePkg/Library/BaseIpmiCommandLibNull/IpmiCommandLibNetFnApp.c
 create mode 100644 
MdeModulePkg/Library/BaseIpmiCommandLibNull/IpmiCommandLibNetFnChassis.c
 create mode 100644 
MdeModulePkg/Library/BaseIpmiCommandLibNull/IpmiCommandLibNetFnStorage.c
 create mode 100644 
MdeModulePkg/Library/BaseIpmiCommandLibNull/IpmiCommandLibNetFnTransport.c

--
2.37.1.windows.1

-The information contained in this message may be confidential and proprietary 
to American Megatrends (AMI). This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited. Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98716): https://edk2.groups.io/g/devel/message/98716
Mute This Topic: https://groups.io/mt/96241124/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] OvmfPkg/PlatformInitLib: pass through reservations from qemu

[Ard Biesheuvel]

On Mon, 16 Jan 2023 at 21:10, Tom Lendacky  wrote:
>
> On 1/16/23 11:09, Ard Biesheuvel wrote:
> > On Thu, 12 Jan 2023 at 18:09, Tom Lendacky  wrote:
> >>
> >> On 12/6/22 23:32, Gerd Hoffmann via groups.io wrote:
> >>> qemu uses the etc/e820 fw_cfg file not only for memory, but
> >>> also for reservations.  Handle reservations by adding resource
> >>> descriptor hobs for them.
> >>>
> >>> A typical qemu configuration has a small reservation between
> >>> lapic and flash:
> >>>
> >>> # sudo cat /proc/iomem
> >>> [ ... ]
> >>> fee0-fee00fff : Local APIC
> >>> feffc000-feff : Reserved  <= HERE
> >>> ffc0- : Reserved
> >>> [ ... ]
> >>>
> >>> Signed-off-by: Gerd Hoffmann 
> >>
> >> On newer versions of Qemu, this patch causes a boot failure on my
> >> AMD system with the following output:
> >>
> >> ...
> >> PciHostBridgeUtilityInitRootBridge: populated root bus 0, with room for 
> >> 255 subordinate bus(es)
> >> RootBridge: PciRoot(0x0)
> >> Support/Attr: 70069 / 70069
> >>   DmaAbove4G: No
> >> NoExtConfSpace: No
> >>AllocAttr: 3 (CombineMemPMem Mem64Decode)
> >>  Bus: 0 - FF Translation=0
> >>   Io: 6000 -  Translation=0
> >>  Mem: C000 - FBFF Translation=0
> >>   MemAbove4G: E0 - FF Translation=0
> >> PMem:  - 0 Translation=0
> >>  PMemAbove4G:  - 0 Translation=0
> >> PciHostBridgeDxe: IntersectMemoryDescriptor: desc [FD, 
> >> 100) type 1 cap 80026000 conflicts with aperture 
> >> [E0, 100) cap 1
> >>
> >> ASSERT_EFI_ERROR (Status = Invalid Parameter)
> >> ASSERT [PciHostBridgeDxe] 
> >> /root/kernels/ovmf-build-X64/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c(550):
> >>  !(((INTN)(RETURN_STATUS)(Status)) < 0)
> >>
> >> Doing some bisecting, before Qemu patch
> >>
> >>  8504f129450b ("i386/pc: relocate 4g start to 1T where applicable")
> >>
> >> this issue wasn't observed. And before this OVMF patch, the newer version
> >> of Qemu doesn't have an issue.
> >>
> >> Also, if I add host-phys-bits=true to the Qemu -cpu parameter, then
> >> the issue isn't observed regardless of Qemu/OVMF level.
> >>
> >> I'm hoping someone has an understanding of what is going on and what
> >> can be done to fix it.
> >>
> >
> > Could someone look into this please? Gerd?
>
> Looks like Gerd is already on it.
>
> See https://bugzilla.tianocore.org/show_bug.cgi?id=4251
>

Right, I didn't realize these things were related.

In any case, those patches have been merged now - care to check
whether the issue has been resolved? Thanks.


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

[edk2-devel] Event: Tools, CI, Code base construction meeting series - Tuesday, January 17, 2023 #cal-reminder

[Group Notification]

*Reminder: Tools, CI, Code base construction meeting series*

*When:*
Tuesday, January 17, 2023
10:00am to 11:00am
(UTC-08:00) America/Los Angeles

*Where:*
https://github.com/tianocore/edk2/discussions/2614

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

*Description:*

TianoCore community,

Microsoft and Intel will be hosting a series of open meetings to discuss build, 
CI, tools, and other related topics. If you are interested, have ideas/opinions 
please join us. These meetings will be Monday 4:30pm Pacific Time on Microsoft 
Teams.

MS Teams Link in following discussion: * 
https://github.com/tianocore/edk2/discussions/2614

Anyone is welcome to join.

* tianocore/edk2: EDK II (github.com)
* tianocore/edk2-basetools: EDK II BaseTools Python tools as a PIP module 
(github.com) https://github.com/tianocore/edk2-basetools
* tianocore/edk2-pytool-extensions: Extensions to the edk2 build system 
allowing for a more robust and plugin based build system and tool execution 
environment (github.com) https://github.com/tianocore/edk2-pytool-extensions
* tianocore/edk2-pytool-library: Python library package that supports UEFI 
development (github.com) https://github.com/tianocore/edk2-pytool-library

MS Teams Browser Clients * 
https://docs.microsoft.com/en-us/microsoftteams/get-clients?tabs=Windows#browser-client


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98718): https://edk2.groups.io/g/devel/message/98718
Mute This Topic: https://groups.io/mt/96334298/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 v11 07/17] CI: Use Fedora 35 container (Linux only)

[Michael Kubacki]

Reviewed-by: Michael Kubacki 

On 1/16/2023 12:40 PM, Oliver Steffen wrote:

Run all Linux based jobs in a container, using a custom Fedora 35 image
(gcc 11).  The image URL specified in the defaults.yml template, so that
all CI jobs can use it. The image is hosted on ghcr.io and the
Dockerfiles are here: https://github.com/tianocore/containers The
version numbers of gcc, iasl, and nasm are pinned to avoid unintended
upgrades during image rebuild.

Do not run apt-get in CI jobs to install qemu and gcc dependencies.
Assume the container image provides these.

Use Python from the container image, do not download at runtime.

Signed-off-by: Oliver Steffen 
---
  .azurepipelines/Ubuntu-GCC5.yml | 3 ++-
  .azurepipelines/templates/basetools-build-steps.yml | 9 -
  .azurepipelines/templates/defaults.yml  | 1 +
  3 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/.azurepipelines/Ubuntu-GCC5.yml b/.azurepipelines/Ubuntu-GCC5.yml
index 4ed6cb601b8e..246e2d272e20 100644
--- a/.azurepipelines/Ubuntu-GCC5.yml
+++ b/.azurepipelines/Ubuntu-GCC5.yml
@@ -21,6 +21,7 @@ jobs:
parameters:
  tool_chain_tag: 'GCC5'
  vm_image: 'ubuntu-latest'
+container: ${{ variables.default_linux_image }}
  arch_list: "IA32,X64,ARM,AARCH64,RISCV64,LOONGARCH64"
-usePythonVersion: ${{ variables.default_python_version }}
+usePythonVersion: ''  # use Python from the container image
  
diff --git a/.azurepipelines/templates/basetools-build-steps.yml b/.azurepipelines/templates/basetools-build-steps.yml

index d8c108c6e212..a72758bc3395 100644
--- a/.azurepipelines/templates/basetools-build-steps.yml
+++ b/.azurepipelines/templates/basetools-build-steps.yml
@@ -10,15 +10,6 @@ parameters:
tool_chain_tag: ''
  
  steps:

-- ${{ if contains(parameters.tool_chain_tag, 'GCC') }}:
-  - bash: sudo apt-get update
-displayName: Update apt
-condition: and(gt(variables.pkg_count, 0), succeeded())
-
-  - bash: sudo apt-get install gcc g++ make uuid-dev
-displayName: Install required tools
-condition: and(gt(variables.pkg_count, 0), succeeded())
-
  - task: CmdLine@1
displayName: Build Base Tools from source
inputs:
diff --git a/.azurepipelines/templates/defaults.yml 
b/.azurepipelines/templates/defaults.yml
index b4909448bdea..74d6b417839d 100644
--- a/.azurepipelines/templates/defaults.yml
+++ b/.azurepipelines/templates/defaults.yml
@@ -9,3 +9,4 @@
  
  variables:

default_python_version: ">=3.10.6"
+  default_linux_image: "ghcr.io/tianocore/containers/fedora-35-test:47addc9"



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

Re: [edk2-devel] [PATCH v11 08/17] ArmVirtPkg: CI: Use Fedora 35 container (Linux only)

[Michael Kubacki]

Reviewed-by: Michael Kubacki 

On 1/16/2023 12:40 PM, Oliver Steffen wrote:

Run the Linux jobs of the ArmVirtPkg platform CI inside a container,
in the same way the general CI does now. Make use of the default image
specified in the defaults.yml template.

Do not run apt-get in CI jobs to install qemu and gcc dependencies.
Assume the container image provides these.

Use Python from the container image, do not download at runtime.

Signed-off-by: Oliver Steffen 
---
  ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml | 8 +++-
  1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml 
b/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
index 5a0e589ed4a7..c0a2e0f20d4f 100644
--- a/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
+++ b/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
@@ -78,6 +78,8 @@ jobs:
  pool:
vmImage: $(vm_image)
  
+container: ${{ variables.default_linux_image }}

+
  steps:
  - template: 
../../../.azurepipelines/templates/platform-build-run-steps.yml
parameters:
@@ -88,8 +90,4 @@ jobs:
  build_file: $(Build.File)
  build_flags: $(Build.Flags)
  run_flags: $(Run.Flags)
-usePythonVersion: ${{ variables.default_python_version }}
-extra_install_step:
-- bash: sudo apt-get install qemu
-  displayName: Install qemu
-  condition: and(gt(variables.pkg_count, 0), succeeded())
+usePythonVersion: '' # use Python from the container image



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

Re: [edk2-devel] [PATCH v11 09/17] EmulatorPkg: CI: Use Fedora 35 container (Linux only)

[Michael Kubacki]

Reviewed-by: Michael Kubacki 

On 1/16/2023 12:40 PM, Oliver Steffen wrote:

Run the Linux jobs of the EmulatorPkg platform CI inside a container,
in the same way the general CI does now. Make use of the default image
specified in the defaults.yml template.

Do not run apt-get in CI jobs to install qemu and gcc dependencies.
Assume the container image provides these.

Use Python from the container image, do not download at runtime.

Signed-off-by: Oliver Steffen 
---
  EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml 
b/EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
index a32c57d4aab4..3861457ac70a 100644
--- a/EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
+++ b/EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
@@ -79,6 +79,8 @@ jobs:
  pool:
vmImage: $(vm_image)
  
+container: ${{ variables.default_linux_image }}

+
  steps:
  - template: 
../../../.azurepipelines/templates/platform-build-run-steps.yml
parameters:
@@ -89,4 +91,4 @@ jobs:
  build_file: $(Build.File)
  build_flags: $(Build.Flags)
  run_flags: $(Run.Flags)
-usePythonVersion: ${{ variables.default_python_version }}
+usePythonVersion: '' # use Python from the container image



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

Re: [edk2-devel] [PATCH v11 10/17] OvmfPkg: CI: Use Fedora 35 container (Linux only)

[Michael Kubacki]

Reviewed-by: Michael Kubacki 

On 1/16/2023 12:40 PM, Oliver Steffen wrote:

Run the Linux jobs of the OvmfPkg platform CI inside a container,
in the same way the general CI does now. Make use of the default image
specified in the defaults.yml template.

Do not run apt-get in CI jobs to install qemu and gcc dependencies.
Assume the container image provides these.

Use Python from the container image, do not download at runtime.

Signed-off-by: Oliver Steffen 
---
  OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml | 8 +++-
  1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml 
b/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
index 6dd90711ac70..85be431ca5e7 100644
--- a/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
+++ b/OvmfPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
@@ -180,6 +180,8 @@ jobs:
  pool:
vmImage: $(vm_image)
  
+container: ${{ variables.default_linux_image }}

+
  steps:
  - template: 
../../../.azurepipelines/templates/platform-build-run-steps.yml
parameters:
@@ -190,8 +192,4 @@ jobs:
  build_file: $(Build.File)
  build_flags: $(Build.Flags)
  run_flags: $(Run.Flags)
-usePythonVersion: ${{ variables.default_python_version }}
-extra_install_step:
-- bash: sudo apt-get install qemu
-  displayName: Install qemu
-  condition: and(gt(variables.pkg_count, 0), succeeded())
+usePythonVersion: '' # use Python from the container image



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

[edk2-devel] Now: Tools, CI, Code base construction meeting series - Tuesday, January 17, 2023 #cal-notice

[Group Notification]

*Tools, CI, Code base construction meeting series*

*When:*
Tuesday, January 17, 2023
10:00am to 11:00am
(UTC-08:00) America/Los Angeles

*Where:*
https://github.com/tianocore/edk2/discussions/2614

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

*Description:*

TianoCore community,

Microsoft and Intel will be hosting a series of open meetings to discuss build, 
CI, tools, and other related topics. If you are interested, have ideas/opinions 
please join us. These meetings will be Monday 4:30pm Pacific Time on Microsoft 
Teams.

MS Teams Link in following discussion: * 
https://github.com/tianocore/edk2/discussions/2614

Anyone is welcome to join.

* tianocore/edk2: EDK II (github.com)
* tianocore/edk2-basetools: EDK II BaseTools Python tools as a PIP module 
(github.com) https://github.com/tianocore/edk2-basetools
* tianocore/edk2-pytool-extensions: Extensions to the edk2 build system 
allowing for a more robust and plugin based build system and tool execution 
environment (github.com) https://github.com/tianocore/edk2-pytool-extensions
* tianocore/edk2-pytool-library: Python library package that supports UEFI 
development (github.com) https://github.com/tianocore/edk2-pytool-library

MS Teams Browser Clients * 
https://docs.microsoft.com/en-us/microsoftteams/get-clients?tabs=Windows#browser-client


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98724): https://edk2.groups.io/g/devel/message/98724
Mute This Topic: https://groups.io/mt/96336246/21656
Mute #cal-notice:https://edk2.groups.io/g/devel/mutehashtag/cal-notice
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 1/1] AmpereAltraPkg: Update ArmPlatformLib to work with changed ARM_CORE_INFO

[Rebecca Cran]

On 1/17/23 09:40, Ard Biesheuvel wrote:


On Tue, 17 Jan 2023 at 13:55, Rebecca Cran  wrote:

I was under the impression that this is becoming a more standard format?


If this is not defined in an ARM spec somewhere, we shouldn't add it
to ArmPkg at this point.


From what I've found, the ARM specs such as the Arm Architecture 
Reference Manual for A-profile architecture don't define the meaning of 
the affinity fields? That appears to be left up to the individual Arm 
core TRMs.


For example, the Cortex-X2 TRM says:

Affinity level 0. This is the affinity level that is most significant 
for determining PE behavior. Higher affinity
levels are increasingly less significant in determining PE behavior. The 
assigned value of the MPIDR.{Aff2,
Aff1, Aff0} or AArch64-MPIDR_EL1.{Aff3, Aff2, Aff1, Aff0} set of fields 
of each PE must be unique within the

system as a whole.
0b
Only one thread.


Affinity level 1. See the description of Aff0 for more information.
Value read from the CPUID configuration pins. Identification number for 
each CPU in an cluster counting from

zero.


Affinity level 2. See the description of Aff0 for more information.
The value will be determined by the CLUSTERIDAFF2 configuration pins.


Affinity level 3. See the description of Aff0 for more information.
The value will be determined by the CLUSTERIDAFF3 configuration pins.


--
Rebecca Cran


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

Re: [edk2-devel] [PATCH v11 00/17] CI: Use Fedora 35 container for Linux jobs

[Ard Biesheuvel]

On Mon, 16 Jan 2023 at 18:41, Oliver Steffen  wrote:
>
> Update CI, run all Linux (aka Ubuntu-GCC5) based jobs in custom
> containers.  This decouples the CI environment from the virtual machine
> images that Azure DevOps provides.  The currently used ubuntu-18.04 image
> has been deprecated for a while now and will be removed soon.
>
> The container image provides the required compiler toolchains and Qemu
> for the supported architectures. These are then no longer downloaded at
> runtime, avoiding CI failures due to download errors. This approach also
> makes it easier to switch to other or newer compilers. It makes the CI
> setup independent from the default images that Azure DevOps provides.
> It can also help debugging CI problems, because the CI environment
> can be reproduced on a local machine.
>
> The container images are hosted on ghcr.io and are automatically
> generated using GitHub Actions. The Dockerfiles are maintained in the
> Tianocore "containers" repository:
> https://github.com/tianocore/containers.
>
> The current image is based on Fedora 35, with gcc 11. Fedora was chosen
> because of its fast release cycle which makes it easy to keep the
> toolchains up-to-date.
>
> Some further possible changes not included in this series:
> - The Tianocore/containers repository provides stack of layered images.
>   One image for general purpose (build+test) and build-only jobs.
>   The build+test image is based on the build-only one and adds Qemu,
>   for the testing job that involve Qemu.  The work in the image side
>   is done, we just need to change the CI setup accordingly.
>   This patch set uses the build+test images for all jobs.
> - Further reduce the number of external dependencies that need to be
>   downloaded at runtime. Candidates are iasl and nasm, which are already
>   included in the image but not used yet.
>
> PR: https://github.com/tianocore/edk2/pull/3904
>
> v11:
> - Rebase to current master branch
> - Use lasted image, includes Qemu 7.2
> - Set container image URL in a central place (the defaults.yml template)
>
> v10:
> - Split commits by package
> - Use ubuntu-22.04 as vm_image (instead of the floating ubuntu-latest)
> - Some fixups around the Python version template argument and defaults.yml
> - Fix some commit messages
> - Add license statement to defaults.yml
>
> v9:
> - Drop the "Don't install cspell" patch
> - Use explicitly use ubuntu-22.04 as vm_image
>
> v8:
> - Use updated container image that contains gcc for LoongArch64.
> - Remove ext_dep files for the LoongArch64 gcc.
> - Don't change the scopes in .pytool/CISettings.py if running Linux CI
>   it.
> - Split commits that touch multiple packages.
> - Use the smaller "build" image for jobs that allow it.
> - Add a CI template file as a central place to define the default Python 
> version
>   and use it where needed.
>
> v7:
> - Rebase to latest master branch.
> - Use latest Fedora 35 CI image.
> - Stop using the ubuntu-18.04 vm_image since this will no longer be available
>   after Dec 1st.  Use ubuntu-latest instead.
>
> v6:
> - Include suggestions by Chris Fernald.
> - Added a parameter for the container image to the job template, makes usage
>   of containers optional.
> - Added a parameter to configure the Python version to download. Allows
>   using Python from the VM/container image also.
> - Restructure the commits (no further functional changes).
>
> v5:
> - Update image
>
> v4:
> - Use the latest image from the tianocode/containers repository which
>   - does not include acpica-tools
>   - includes Pyhton 3.10
>
> v3:
> - Use the latest image from the tianocode/containers repository which
>   pins down version numbers of gcc, iasl, and nasm in the Dockerfile.
>
> v2:
> - Images are now hosted under the Tianocore Organization
>   https://github.com/tianocore/containers
>
> v1:
> - Thread: https://edk2.groups.io/g/devel/message/89058
> - Images were hosted at https://github.com/osteffenrh/edk2-build-images
>
> Signed-off-by: Oliver Steffen 
> Acked-by: Ard Biesheuvel 
> Acked-by: Gerd Hoffmann 
> Reviewed-by: Chris Fernald 
>
> Oliver Steffen (17):
>   CI: make Python version configurable
>   ArmVirtPkg: CI: use Python version from defaults template
>   EmulatorPkg: CI: use Python version from defaults template
>   OvmfPkg: CI: use Python version from defaults template
>   CI: add ~/.local/bin to PATH (Linux only)
>   CI: Allow running in a container.
>   CI: Use Fedora 35 container (Linux only)
>   ArmVirtPkg: CI: Use Fedora 35 container (Linux only)
>   EmulatorPkg: CI: Use Fedora 35 container (Linux only)
>   OvmfPkg: CI: Use Fedora 35 container (Linux only)
>   .pytool: CISettings.py: don't add scopes for GCC
>   BaseTools: remove ext_dep files for gcc
>   ArmVirtPkg: CI: use ubuntu-22.04 vm_image (Linux only)
>   EmulatorPgk: CI: use ubuntu-22.04 vm_image (Linux only)
>   OvmfPkg: CI: use ubuntu-22.04 vm_image (Linux only)
>   CI: use ubuntu-22.04 image (Linux only)

Thanks

I have created a PR here

htt

Re: [edk2-devel] [PATCH 1/2] BoardModulePkg: Copy device path before processing

[Isaac Oram]

Platform/Intel/BoardModulePkg/Library/BoardBdsHookLib/BoardBdsHookLib.c 
Line 168: Don't we need to free buffer on this path?
Lines 655, 1083:  Please put a newline between while and the block to free 
resources.

Regards,
Isaac

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Abdul Lateef 
Attar via groups.io
Sent: Tuesday, November 15, 2022 4:04 AM
To: devel@edk2.groups.io
Cc: Dong, Eric ; Gao, Liming 
Subject: [edk2-devel] [PATCH 1/2] BoardModulePkg: Copy device path before 
processing

From: Abdul Lateef Attar 

GCC compiler puts the DevicePath PCDs to the read-only section. During boot if 
try to process the device path after PtrGetPtr it throws a page fault exception.

Hence making a local copy using DuplicateDevicePath() to avoid the page fault 
exception.

Cc: Eric Dong 
Cc: Liming Gao 

Signed-off-by: Abdul Lateef Attar 
---
 .../Library/BoardBdsHookLib/BoardBdsHookLib.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git 
a/Platform/Intel/BoardModulePkg/Library/BoardBdsHookLib/BoardBdsHookLib.c 
b/Platform/Intel/BoardModulePkg/Library/BoardBdsHookLib/BoardBdsHookLib.c
index 0bcee7c9a4ba..8700118d255a 100644
--- a/Platform/Intel/BoardModulePkg/Library/BoardBdsHookLib/BoardBdsHookLib.c
+++ b/Platform/Intel/BoardModulePkg/Library/BoardBdsHookLib/BoardBdsHook
+++ Lib.c
@@ -3,6 +3,7 @@
   implementation instance of the BDS hook library

 

   Copyright (c) 2019, Intel Corporation. All rights reserved.

+  Copyright (C) 2022 Advanced Micro Devices, Inc. All rights 
+ reserved.

   SPDX-License-Identifier: BSD-2-Clause-Patent

 

 **/

@@ -131,7 +132,7 @@ IsTrustedConsole (
 

   switch (ConsoleType) {

 case ConIn:

-  TrustedConsoleDevicepath = PcdGetPtr (PcdTrustedConsoleInputDevicePath);

+  TrustedConsoleDevicepath = DuplicateDevicePath (PcdGetPtr 
+ (PcdTrustedConsoleInputDevicePath));

   break;

 case ConOut:

   //

@@ -147,7 +148,7 @@ IsTrustedConsole (
 TempDevicePath = NextDevicePathNode (TempDevicePath);

   }

 

-  TrustedConsoleDevicepath = PcdGetPtr (PcdTrustedConsoleOutputDevicePath);

+  TrustedConsoleDevicepath = DuplicateDevicePath (PcdGetPtr 
+ (PcdTrustedConsoleOutputDevicePath));

   break;

 default:

   ASSERT (FALSE);

@@ -171,7 +172,9 @@ IsTrustedConsole (
   } while (TempDevicePath != NULL);

 

   FreePool (ConsoleDevice);

-

+  if (TrustedConsoleDevicepath != NULL) {

+FreePool (TrustedConsoleDevicepath);

+  }

   return FALSE;

 }

 

@@ -624,7 +627,7 @@ ConnectTrustedStorage (
   EFI_STATUSStatus;

   EFI_HANDLEDeviceHandle;

 

-  TrustedStorageDevicepath = PcdGetPtr (PcdTrustedStorageDevicePath);

+  TrustedStorageDevicepath = DuplicateDevicePath (PcdGetPtr 
+ (PcdTrustedStorageDevicePath));

   DumpDevicePath (L"TrustedStorage", TrustedStorageDevicepath);

 

   TempDevicePath = TrustedStorageDevicepath;

@@ -649,6 +652,9 @@ ConnectTrustedStorage (
 

 FreePool (Instance);

   } while (TempDevicePath != NULL);

+  if (TrustedStorageDevicepath != NULL) {

+FreePool (TrustedStorageDevicepath);

+  }

 }

 

 

@@ -1031,7 +1037,7 @@ AddConsoleVariable (
   EFI_HANDLEGraphicsControllerHandle;

   EFI_DEVICE_PATH   *GopDevicePath;

 

-  TempDevicePath = ConsoleDevicePath;

+  TempDevicePath = DuplicateDevicePath (ConsoleDevicePath);

   do {

 Instance = GetNextDevicePathInstance (&TempDevicePath, &Size);

 if (Instance == NULL) {

@@ -1074,6 +1080,9 @@ AddConsoleVariable (
 

 FreePool (Instance);

   } while (TempDevicePath != NULL);

+  if (TempDevicePath != NULL) {

+FreePool (TempDevicePath);

+  }

 }

 

 

--
2.25.1








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

Re: [edk2-devel] [PATCH 2/2] BoardModulePkg: Adds PCD to load UEFI Shell image

[Isaac Oram]

edk2-platforms/Platform/Intel/BoardModulePkg/Library/BoardBdsHookLib/BoardBootOption.c
 338:  Can you change to mUefiShellFileGuid and initialize it to zero?  It 
seems misleading to me to have the default value here when it is not used.  I 
think we should also move the declarations to the beginning of the file.

I am curious why this kind of global variable doesn't trigger PF and PCD does.  
If you know off the top of your head.  You do not need to research if the code 
is functional with GCC.  Also, please add me to CC list so I don't filter the 
emails.

Thanks,
Isaac


-Original Message-
From: devel@edk2.groups.io  On Behalf Of Abdul Lateef 
Attar via groups.io
Sent: Tuesday, November 15, 2022 4:04 AM
To: devel@edk2.groups.io
Cc: Dong, Eric ; Gao, Liming 
Subject: [edk2-devel] [PATCH 2/2] BoardModulePkg: Adds PCD to load UEFI Shell 
image

defines two PCDs, PcdShellFile and PcdShellFileDesc, which holds the GUID and 
description of the UEFI shell file to be loaded.

A PCDs based solution gives flexibility to the user to load different images, 
by just overriding the DSC file.

The user can load a diagnostic image or test image during PCDBootToShellOnly or 
later stages.

Cc: Eric Dong 
Cc: Liming Gao 
Signed-off-by: Abdul Lateef Attar 
---
 Platform/Intel/MinPlatformPkg/MinPlatformPkg.dec  | 5 +
 .../Library/BoardBdsHookLib/BoardBdsHookLib.inf   | 3 +++
 .../Library/BoardBdsHookLib/BoardBootOption.c | 8 +---
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dec 
b/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dec
index 2953e9527224..73cbd62be030 100644
--- a/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dec
+++ b/Platform/Intel/MinPlatformPkg/MinPlatformPkg.dec
@@ -7,6 +7,7 @@
 # for the build infrastructure.

 #

 # Copyright (c) 2017 - 2021, Intel Corporation. All rights reserved.

+# Copyright (C) 2022 Advanced Micro Devices, Inc. All rights 
+reserved.

 #

 # SPDX-License-Identifier: BSD-2-Clause-Patent

 #

@@ -266,6 +267,10 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
   gMinPlatformPkgTokenSpaceGuid.PcdFlashFvFspUSize|0x|UINT32|0x202B

   
gMinPlatformPkgTokenSpaceGuid.PcdFlashFvFspUOffset|0x|UINT32|0x202C

 

+  # GUID of Shell file to be loaded, default value is 
+ gUefiShellFileGuid define in ShellPkg.dec

+  gMinPlatformPkgTokenSpaceGuid.PcdShellFile|{GUID({0x7c04a583, 0x9e3e, 
+ 0x4f1c, {0xad, 0x65, 0xe0, 0x52, 0x68, 0xd0, 0xb4, 
+ 0xd1}})}|VOID*|0x2230

+  gMinPlatformPkgTokenSpaceGuid.PcdShellFileDesc|L"Internal UEFI Shell 
+ 2.0"|VOID*|0x2231

+

 [PcdsDynamic, PcdsDynamicEx]

   gMinPlatformPkgTokenSpaceGuid.PcdPcIoApicEnable|0x0|UINT32|0x9019

   
gMinPlatformPkgTokenSpaceGuid.PcdAcpiSleepControlRegisterAddressSpaceId|0x00|UINT8|0x0001004B

diff --git 
a/Platform/Intel/BoardModulePkg/Library/BoardBdsHookLib/BoardBdsHookLib.inf 
b/Platform/Intel/BoardModulePkg/Library/BoardBdsHookLib/BoardBdsHookLib.inf
index 69f3fcb55222..e2ac73498b90 100644
--- a/Platform/Intel/BoardModulePkg/Library/BoardBdsHookLib/BoardBdsHookLib.inf
+++ b/Platform/Intel/BoardModulePkg/Library/BoardBdsHookLib/BoardBdsHook
+++ Lib.inf
@@ -2,6 +2,7 @@
 # Module Information file for the Bds Hook Library.

 #

 # Copyright (c) 2019, Intel Corporation. All rights reserved.

+# Copyright (C) 2022 Advanced Micro Devices, Inc. All rights 
+reserved.

 #

 # SPDX-License-Identifier: BSD-2-Clause-Patent

 #

@@ -59,6 +60,8 @@ [Pcd]
   gMinPlatformPkgTokenSpaceGuid.PcdTrustedConsoleInputDevicePath## CONSUMES

   gMinPlatformPkgTokenSpaceGuid.PcdTrustedConsoleOutputDevicePath   ## CONSUMES

   gMinPlatformPkgTokenSpaceGuid.PcdTrustedStorageDevicePath ## CONSUMES

+  gMinPlatformPkgTokenSpaceGuid.PcdShellFile## CONSUMES

+  gMinPlatformPkgTokenSpaceGuid.PcdShellFileDesc## CONSUMES

 

 [Sources]

   BoardBdsHook.h

diff --git 
a/Platform/Intel/BoardModulePkg/Library/BoardBdsHookLib/BoardBootOption.c 
b/Platform/Intel/BoardModulePkg/Library/BoardBdsHookLib/BoardBootOption.c
index dec3ce93ef71..de1676dad0c7 100644
--- a/Platform/Intel/BoardModulePkg/Library/BoardBdsHookLib/BoardBootOption.c
+++ b/Platform/Intel/BoardModulePkg/Library/BoardBdsHookLib/BoardBootOpt
+++ ion.c
@@ -2,6 +2,8 @@
   Driver for Platform Boot Options support.

 

 Copyright (c) 2019, Intel Corporation. All rights reserved.

+Copyright (C) 2022 Advanced Micro Devices, Inc. All rights 
+reserved.

+

 SPDX-License-Identifier: BSD-2-Clause-Patent

 

 **/

@@ -335,7 +337,6 @@ PlatformBootManagerWaitCallback (
 

 EFI_GUID gUefiShellFileGuid = { 0x7C04A583, 0x9E3E, 0x4f1c, { 0xAD, 0x65, 
0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 } };

 

-#define INTERNAL_UEFI_SHELL_NAME  L"Internal UEFI Shell 2.0"

 #define UEFI_HARD_DRIVE_NAME  L"UEFI Hard Drive"

 

 /**

@@ -352,7 +353,8 @@ RegisterDefaultBootOption (
 

 ShellData = NULL;

 ShellDataSize = 0;

-Reg

Re: [edk2-devel] [PATCH 1/1] OvmfPkg/PlatformInitLib: pass through reservations from qemu

[Lendacky, Thomas via groups.io]

On 1/17/23 10:49, Ard Biesheuvel wrote:

On Mon, 16 Jan 2023 at 21:10, Tom Lendacky  wrote:


On 1/16/23 11:09, Ard Biesheuvel wrote:

On Thu, 12 Jan 2023 at 18:09, Tom Lendacky  wrote:


On 12/6/22 23:32, Gerd Hoffmann via groups.io wrote:

qemu uses the etc/e820 fw_cfg file not only for memory, but
also for reservations.  Handle reservations by adding resource
descriptor hobs for them.

A typical qemu configuration has a small reservation between
lapic and flash:

 # sudo cat /proc/iomem
 [ ... ]
 fee0-fee00fff : Local APIC
 feffc000-feff : Reserved  <= HERE
 ffc0- : Reserved
 [ ... ]

Signed-off-by: Gerd Hoffmann 


On newer versions of Qemu, this patch causes a boot failure on my
AMD system with the following output:

...
PciHostBridgeUtilityInitRootBridge: populated root bus 0, with room for 255 
subordinate bus(es)
RootBridge: PciRoot(0x0)
 Support/Attr: 70069 / 70069
   DmaAbove4G: No
NoExtConfSpace: No
AllocAttr: 3 (CombineMemPMem Mem64Decode)
  Bus: 0 - FF Translation=0
   Io: 6000 -  Translation=0
  Mem: C000 - FBFF Translation=0
   MemAbove4G: E0 - FF Translation=0
 PMem:  - 0 Translation=0
  PMemAbove4G:  - 0 Translation=0
PciHostBridgeDxe: IntersectMemoryDescriptor: desc [FD, 100) 
type 1 cap 80026000 conflicts with aperture [E0, 100) 
cap 1

ASSERT_EFI_ERROR (Status = Invalid Parameter)
ASSERT [PciHostBridgeDxe] 
/root/kernels/ovmf-build-X64/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c(550):
 !(((INTN)(RETURN_STATUS)(Status)) < 0)

Doing some bisecting, before Qemu patch

  8504f129450b ("i386/pc: relocate 4g start to 1T where applicable")

this issue wasn't observed. And before this OVMF patch, the newer version
of Qemu doesn't have an issue.

Also, if I add host-phys-bits=true to the Qemu -cpu parameter, then
the issue isn't observed regardless of Qemu/OVMF level.

I'm hoping someone has an understanding of what is going on and what
can be done to fix it.



Could someone look into this please? Gerd?


Looks like Gerd is already on it.

See https://bugzilla.tianocore.org/show_bug.cgi?id=4251



Right, I didn't realize these things were related.

In any case, those patches have been merged now - care to check
whether the issue has been resolved? Thanks.


Yes, the issue is now resolved.

Thanks,
Tom



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

Re: [edk2-devel][edk2-non-osi][PATCH 1/1] ASpeed/ASpeedGopBinPkg: Update X64/AArch Gop UEFI Driver

[Ard Biesheuvel]

Note that the value in the INF_VERSION field cannot be chosen
arbitrarily - it should be the latest version of the INF spec, so 1.29
(you don't need to put a hex value here, just "1.29" is fine)

On Tue, 17 Jan 2023 at 23:40, Isaac Oram  wrote:
>
> Reviewed-by: Isaac Oram 
>
> Note that you do not need a cover letter for single commit reviews.  It is 
> needed for multi-commit reviews so that you can describe the whole patch 
> series.
>
> -Original Message-
> From: Tommy Huang 
> Sent: Tuesday, January 10, 2023 10:08 PM
> To: devel@edk2.groups.io
> Cc: Desimone, Nathaniel L ; Oram, Isaac W 
> ; quic_llind...@quicinc.com; Kinney, Michael D 
> ; Chen, Ryan ; 
> bmc...@aspeedtech.com
> Subject: [edk2-devel][edk2-non-osi][PATCH 1/1] ASpeed/ASpeedGopBinPkg: Update 
> X64/AArch Gop UEFI Driver
>
> 1. Add ASpeedAst2600GopDxe.inf.
> 2. Add ASpeedAst2600Gop file for AArch64.
> 3. Update the others Gop UEFI binaries into the recently version. The version 
> will be v1.13.02.
>
> Cc: Isaac Oram 
> Cc: Nate DeSimone 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Cc: Ryan Chen 
> Cc: BMC-SW 
>
> Signed-off-by: Tommy Huang 
> ---
>  .../AArch64/ASpeedAst2500Gop.efi  | Bin 42880 -> 45056 bytes
>  .../AArch64/ASpeedAst2600Gop.efi  | Bin 0 -> 45056 bytes
>  .../ASpeedGopBinPkg/ASpeedAst2500GopDxe.inf   |   4 ++--
>  .../ASpeedGopBinPkg/ASpeedAst2600GopDxe.inf   |  22 ++
>  .../ASpeedGopBinPkg/X64/ASpeedAst2500Gop.efi  | Bin 36928 -> 33600 bytes
>  .../ASpeedGopBinPkg/X64/ASpeedAst2600Gop.efi  | Bin 32544 -> 29952 bytes
>  6 files changed, 24 insertions(+), 2 deletions(-)
>  create mode 100644 
> Drivers/ASpeed/ASpeedGopBinPkg/AArch64/ASpeedAst2600Gop.efi
>  create mode 100644 Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2600GopDxe.inf
>


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

[edk2-devel] [PATCH V2 1/1] OvmfPkg/BaseMemEncryptTdxLib: Refactor error handle of SetOrClearSharedBit

[Min Xu]

From: Min M Xu 

The previous implementation of SetOrClearSharedBit doesn't handle the
error correctly. In this patch SetOrClearSharedBit is changed to return
error code so that the caller can handle it.

Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Tom Lendacky 
Cc: Michael Roth 
Reviewed-by: Jiewen Yao 
Signed-off-by: Min Xu 
---
 .../BaseMemEncryptTdxLib/MemoryEncryption.c   | 48 +++
 1 file changed, 40 insertions(+), 8 deletions(-)

diff --git a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c 
b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c
index 503f626d75c6..5b13042512ad 100644
--- a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c
+++ b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c
@@ -510,8 +510,11 @@ Split1GPageTo2M (
   @param[in]  PagetablePointPage table entry pointer (PTE).
   @param[in]  Mode  Set or Clear shared bit
 
+  @retval EFI_SUCCESS   Successfully set or clear the memory 
shared bit
+  @retval OthersOther error as indicated
 **/
-STATIC VOID
+STATIC
+EFI_STATUS
 SetOrClearSharedBit (
   IN   OUT UINT64  *PageTablePointer,
   IN   TDX_PAGETABLE_MODE  Mode,
@@ -520,7 +523,8 @@ SetOrClearSharedBit (
   )
 {
   UINT64AddressEncMask;
-  UINT64Status;
+  UINT64TdStatus;
+  EFI_STATUSStatus;
   EDKII_MEMORY_ACCEPT_PROTOCOL  *MemoryAcceptProtocol;
 
   AddressEncMask = GetMemEncryptionAddressMask ();
@@ -536,16 +540,30 @@ SetOrClearSharedBit (
 PhysicalAddress   &= ~AddressEncMask;
   }
 
-  Status = TdVmCall (TDVMCALL_MAPGPA, PhysicalAddress, Length, 0, 0, NULL);
+  TdStatus = TdVmCall (TDVMCALL_MAPGPA, PhysicalAddress, Length, 0, 0, NULL);
+  if (TdStatus != 0) {
+DEBUG ((DEBUG_ERROR, "%a: TdVmcall(MAPGPA) failed with %llx\n", 
__FUNCTION__, TdStatus));
+ASSERT (FALSE);
+return EFI_DEVICE_ERROR;
+  }
 
   //
   // If changing shared to private, must accept-page again
   //
   if (Mode == ClearSharedBit) {
 Status = gBS->LocateProtocol (&gEdkiiMemoryAcceptProtocolGuid, NULL, (VOID 
**)&MemoryAcceptProtocol);
-ASSERT (!EFI_ERROR (Status));
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "%a: Failed to locate MemoryAcceptProtocol with 
%r\n", __FUNCTION__, Status));
+  ASSERT (FALSE);
+  return Status;
+}
+
 Status = MemoryAcceptProtocol->AcceptMemory (MemoryAcceptProtocol, 
PhysicalAddress, Length);
-ASSERT (!EFI_ERROR (Status));
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "%a: Failed to AcceptMemory with %r\n", 
__FUNCTION__, Status));
+  ASSERT (FALSE);
+  return Status;
+}
   }
 
   DEBUG ((
@@ -558,6 +576,8 @@ SetOrClearSharedBit (
 Mode,
 Status
 ));
+
+  return EFI_SUCCESS;
 }
 
 /**
@@ -747,7 +767,11 @@ SetMemorySharedOrPrivate (
   // If we have at least 1GB to go, we can just update this entry
   //
   if (!(PhysicalAddress & (BIT30 - 1)) && (Length >= BIT30)) {
-SetOrClearSharedBit (&PageDirectory1GEntry->Uint64, Mode, 
PhysicalAddress, BIT30);
+Status = SetOrClearSharedBit (&PageDirectory1GEntry->Uint64, Mode, 
PhysicalAddress, BIT30);
+if (EFI_ERROR (Status)) {
+  goto Done;
+}
+
 DEBUG ((
   DEBUG_VERBOSE,
   "%a:%a: updated 1GB entry for Physical=0x%Lx\n",
@@ -809,7 +833,11 @@ SetMemorySharedOrPrivate (
 // If we have at least 2MB left to go, we can just update this entry
 //
 if (!(PhysicalAddress & (BIT21-1)) && (Length >= BIT21)) {
-  SetOrClearSharedBit (&PageDirectory2MEntry->Uint64, Mode, 
PhysicalAddress, BIT21);
+  Status = SetOrClearSharedBit (&PageDirectory2MEntry->Uint64, Mode, 
PhysicalAddress, BIT21);
+  if (EFI_ERROR (Status)) {
+goto Done;
+  }
+
   PhysicalAddress += BIT21;
   Length  -= BIT21;
 } else {
@@ -856,7 +884,11 @@ SetMemorySharedOrPrivate (
   goto Done;
 }
 
-SetOrClearSharedBit (&PageTableEntry->Uint64, Mode, PhysicalAddress, 
EFI_PAGE_SIZE);
+Status = SetOrClearSharedBit (&PageTableEntry->Uint64, Mode, 
PhysicalAddress, EFI_PAGE_SIZE);
+if (EFI_ERROR (Status)) {
+  goto Done;
+}
+
 PhysicalAddress += EFI_PAGE_SIZE;
 Length  -= EFI_PAGE_SIZE;
   }
-- 
2.29.2.windows.2



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

[edk2-devel] [PATCH V2 1/1] OvmfPkg/CcExitLib: Initialize Status in IoExit

[Min Xu]

From: Min M Xu 

Status should be initialized otherwise it may return unexpected value.

Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Tom Lendacky 
Cc: Michael Roth 
Reviewed-by: Jiewen Yao 
Signed-off-by: Min Xu 
---
 OvmfPkg/Library/CcExitLib/CcExitVeHandler.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/OvmfPkg/Library/CcExitLib/CcExitVeHandler.c 
b/OvmfPkg/Library/CcExitLib/CcExitVeHandler.c
index 30d547d5fe55..872f772a5ac8 100644
--- a/OvmfPkg/Library/CcExitLib/CcExitVeHandler.c
+++ b/OvmfPkg/Library/CcExitLib/CcExitVeHandler.c
@@ -105,10 +105,11 @@ IoExit (
   UINT64   RepCnt;
   UINT64   Status;
 
-  Val   = 0;
-  Write = Veinfo->ExitQualification.Io.Direction ? FALSE : TRUE;
-  Size  = Veinfo->ExitQualification.Io.Size + 1;
-  Port  = Veinfo->ExitQualification.Io.Port;
+  Val= 0;
+  Status = 0;
+  Write  = Veinfo->ExitQualification.Io.Direction ? FALSE : TRUE;
+  Size   = Veinfo->ExitQualification.Io.Size + 1;
+  Port   = Veinfo->ExitQualification.Io.Port;
 
   if (Veinfo->ExitQualification.Io.String) {
 //
-- 
2.29.2.windows.2



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

[edk2-devel] [PATCH V2 1/1] SecurityPkg/TdTcg2Dxe: Extend EFI boot variable to PCR[1]

[Min Xu]

From: Min M Xu 

According to TCG PC Client PFP spec 0021 Section 2.4.4.2 EFI boot variable
should be measured and extended to PCR[1], not PCR[5]. This patch is
proposed to fix this error.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Reviewed-by: Jiewen Yao 
Signed-off-by: Min Xu 
---
 SecurityPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/SecurityPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.c 
b/SecurityPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.c
index d19923b0c682..59341a8c0250 100644
--- a/SecurityPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.c
+++ b/SecurityPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.c
@@ -1873,12 +1873,8 @@ ReadAndMeasureBootVariable (
   OUT VOID  **VarData
   )
 {
-  //
-  // Boot variables are measured into (PCR[5]) RTMR[1],
-  // details in section 8.1 of TDVF design guide.
-  //
   return ReadAndMeasureVariable (
-   MapPcrToMrIndex (5),
+   MapPcrToMrIndex (1),
EV_EFI_VARIABLE_BOOT,
VarName,
VendorGuid,
-- 
2.29.2.windows.2



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

[Min Xu]

Thanks for the comments. They're will be sent for review in separate patches.

> -Original Message-
> From: Yao, Jiewen 
> Sent: Monday, January 16, 2023 8:45 AM
> To: Xu, Min M ; devel@edk2.groups.io
> Cc: Wang, Jian J ; Aktas, Erdem
> ; James Bottomley ; Gerd
> Hoffmann ; Tom Lendacky
> ; Michael Roth ; Yao,
> Jiewen 
> Subject: RE: [PATCH V1 0/3] Fix TDVF issues
> 
> From process perspective, I see no reason to combine them into one patch set,
> because each patch is individual, and they are handling different problem.
> Also, there is no reason to mix the fix in SecurityPkg with the fix in 
> OvmfPkg, if
> they are not related.
> 
> Please split them into 3 different patches.
> 
> With comment above, reviewed-by: Jiewen Yao 
> 
> Thank you
> Yao, Jiewen
> 
> > -Original Message-
> > From: Xu, Min M 
> > Sent: Monday, January 16, 2023 7:28 AM
> > To: devel@edk2.groups.io
> > Cc: Xu, Min M ; Yao, Jiewen
> > ; Wang, Jian J ; Aktas,
> > Erdem ; James Bottomley
> ;
> > Gerd Hoffmann ; Tom Lendacky
> > ; Michael Roth 
> > Subject: [PATCH V1 0/3] Fix TDVF issues
> >
> > This patch-set fix below TDVF issues:
> > Patch#1: Initialize Status in IoExit
> > Patch#2: Extend EFI boot variable to PCR[1] according to TCG PC Client
> >  PFP spec.
> > Patch#3: Refactor error handle of SetOrClearSharedBit so that the caller
> >  can handle the returned error.
> >
> > Cc: Jiewen Yao 
> > Cc: Jian J Wang 
> > Cc: Erdem Aktas 
> > Cc: James Bottomley 
> > Cc: Jiewen Yao 
> > Cc: Gerd Hoffmann 
> > Cc: Tom Lendacky 
> > Cc: Michael Roth 
> > Signed-off-by: Min Xu 
> >
> > Min M Xu (3):
> >   OvmfPkg/CcExitLib: Initialize Status in IoExit
> >   SecurityPkg/TdTcg2Dxe: Extend EFI boot variable to PCR[1]
> >   OvmfPkg/BaseMemEncryptTdxLib: Refactor error handle of
> > SetOrClearSharedBit
> >
> >  .../BaseMemEncryptTdxLib/MemoryEncryption.c   | 48 +++---
> -
> >  OvmfPkg/Library/CcExitLib/CcExitVeHandler.c   |  9 ++--
> >  SecurityPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.c |  6 +--
> >  3 files changed, 46 insertions(+), 17 deletions(-)
> >
> > --
> > 2.29.2.windows.2



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

Re: [edk2-devel] [PATCH V2 1/1] OvmfPkg/CcExitLib: Initialize Status in IoExit

[Yao, Jiewen]

Reviewed-by: Jiewen Yao 

> -Original Message-
> From: Xu, Min M 
> Sent: Wednesday, January 18, 2023 7:53 AM
> To: devel@edk2.groups.io
> Cc: Xu, Min M ; Aktas, Erdem
> ; James Bottomley ; Yao,
> Jiewen ; Gerd Hoffmann ;
> Tom Lendacky ; Michael Roth
> 
> Subject: [PATCH V2 1/1] OvmfPkg/CcExitLib: Initialize Status in IoExit
> 
> From: Min M Xu 
> 
> Status should be initialized otherwise it may return unexpected value.
> 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Gerd Hoffmann 
> Cc: Tom Lendacky 
> Cc: Michael Roth 
> Reviewed-by: Jiewen Yao 
> Signed-off-by: Min Xu 
> ---
>  OvmfPkg/Library/CcExitLib/CcExitVeHandler.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/OvmfPkg/Library/CcExitLib/CcExitVeHandler.c
> b/OvmfPkg/Library/CcExitLib/CcExitVeHandler.c
> index 30d547d5fe55..872f772a5ac8 100644
> --- a/OvmfPkg/Library/CcExitLib/CcExitVeHandler.c
> +++ b/OvmfPkg/Library/CcExitLib/CcExitVeHandler.c
> @@ -105,10 +105,11 @@ IoExit (
>UINT64   RepCnt;
>UINT64   Status;
> 
> -  Val   = 0;
> -  Write = Veinfo->ExitQualification.Io.Direction ? FALSE : TRUE;
> -  Size  = Veinfo->ExitQualification.Io.Size + 1;
> -  Port  = Veinfo->ExitQualification.Io.Port;
> +  Val= 0;
> +  Status = 0;
> +  Write  = Veinfo->ExitQualification.Io.Direction ? FALSE : TRUE;
> +  Size   = Veinfo->ExitQualification.Io.Size + 1;
> +  Port   = Veinfo->ExitQualification.Io.Port;
> 
>if (Veinfo->ExitQualification.Io.String) {
>  //
> --
> 2.29.2.windows.2



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

Re: [edk2-devel] [PATCH V2 1/1] SecurityPkg/TdTcg2Dxe: Extend EFI boot variable to PCR[1]

[Yao, Jiewen]

Reviewed-by: Jiewen Yao 

> -Original Message-
> From: Xu, Min M 
> Sent: Wednesday, January 18, 2023 7:53 AM
> To: devel@edk2.groups.io
> Cc: Xu, Min M ; Yao, Jiewen ;
> Wang, Jian J 
> Subject: [PATCH V2 1/1] SecurityPkg/TdTcg2Dxe: Extend EFI boot variable to
> PCR[1]
> 
> From: Min M Xu 
> 
> According to TCG PC Client PFP spec 0021 Section 2.4.4.2 EFI boot variable
> should be measured and extended to PCR[1], not PCR[5]. This patch is
> proposed to fix this error.
> 
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> Reviewed-by: Jiewen Yao 
> Signed-off-by: Min Xu 
> ---
>  SecurityPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/SecurityPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.c
> b/SecurityPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.c
> index d19923b0c682..59341a8c0250 100644
> --- a/SecurityPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.c
> +++ b/SecurityPkg/Tcg/TdTcg2Dxe/TdTcg2Dxe.c
> @@ -1873,12 +1873,8 @@ ReadAndMeasureBootVariable (
>OUT VOID  **VarData
>)
>  {
> -  //
> -  // Boot variables are measured into (PCR[5]) RTMR[1],
> -  // details in section 8.1 of TDVF design guide.
> -  //
>return ReadAndMeasureVariable (
> -   MapPcrToMrIndex (5),
> +   MapPcrToMrIndex (1),
> EV_EFI_VARIABLE_BOOT,
> VarName,
> VendorGuid,
> --
> 2.29.2.windows.2



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

Re: [edk2-devel] [PATCH V2 1/1] OvmfPkg/BaseMemEncryptTdxLib: Refactor error handle of SetOrClearSharedBit

[Yao, Jiewen]

Reviewed-by: Jiewen Yao 

> -Original Message-
> From: Xu, Min M 
> Sent: Wednesday, January 18, 2023 7:53 AM
> To: devel@edk2.groups.io
> Cc: Xu, Min M ; Aktas, Erdem
> ; James Bottomley ; Yao,
> Jiewen ; Gerd Hoffmann ;
> Tom Lendacky ; Michael Roth
> 
> Subject: [PATCH V2 1/1] OvmfPkg/BaseMemEncryptTdxLib: Refactor error
> handle of SetOrClearSharedBit
> 
> From: Min M Xu 
> 
> The previous implementation of SetOrClearSharedBit doesn't handle the
> error correctly. In this patch SetOrClearSharedBit is changed to return
> error code so that the caller can handle it.
> 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Gerd Hoffmann 
> Cc: Tom Lendacky 
> Cc: Michael Roth 
> Reviewed-by: Jiewen Yao 
> Signed-off-by: Min Xu 
> ---
>  .../BaseMemEncryptTdxLib/MemoryEncryption.c   | 48 +++
>  1 file changed, 40 insertions(+), 8 deletions(-)
> 
> diff --git a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c
> b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c
> index 503f626d75c6..5b13042512ad 100644
> --- a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c
> +++ b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c
> @@ -510,8 +510,11 @@ Split1GPageTo2M (
>@param[in]  PagetablePointPage table entry pointer (PTE).
>@param[in]  Mode  Set or Clear shared bit
> 
> +  @retval EFI_SUCCESS   Successfully set or clear the memory
> shared bit
> +  @retval OthersOther error as indicated
>  **/
> -STATIC VOID
> +STATIC
> +EFI_STATUS
>  SetOrClearSharedBit (
>IN   OUT UINT64  *PageTablePointer,
>IN   TDX_PAGETABLE_MODE  Mode,
> @@ -520,7 +523,8 @@ SetOrClearSharedBit (
>)
>  {
>UINT64AddressEncMask;
> -  UINT64Status;
> +  UINT64TdStatus;
> +  EFI_STATUSStatus;
>EDKII_MEMORY_ACCEPT_PROTOCOL  *MemoryAcceptProtocol;
> 
>AddressEncMask = GetMemEncryptionAddressMask ();
> @@ -536,16 +540,30 @@ SetOrClearSharedBit (
>  PhysicalAddress   &= ~AddressEncMask;
>}
> 
> -  Status = TdVmCall (TDVMCALL_MAPGPA, PhysicalAddress, Length, 0, 0,
> NULL);
> +  TdStatus = TdVmCall (TDVMCALL_MAPGPA, PhysicalAddress, Length, 0, 0,
> NULL);
> +  if (TdStatus != 0) {
> +DEBUG ((DEBUG_ERROR, "%a: TdVmcall(MAPGPA) failed with %llx\n",
> __FUNCTION__, TdStatus));
> +ASSERT (FALSE);
> +return EFI_DEVICE_ERROR;
> +  }
> 
>//
>// If changing shared to private, must accept-page again
>//
>if (Mode == ClearSharedBit) {
>  Status = gBS->LocateProtocol (&gEdkiiMemoryAcceptProtocolGuid, NULL,
> (VOID **)&MemoryAcceptProtocol);
> -ASSERT (!EFI_ERROR (Status));
> +if (EFI_ERROR (Status)) {
> +  DEBUG ((DEBUG_ERROR, "%a: Failed to locate MemoryAcceptProtocol
> with %r\n", __FUNCTION__, Status));
> +  ASSERT (FALSE);
> +  return Status;
> +}
> +
>  Status = MemoryAcceptProtocol->AcceptMemory (MemoryAcceptProtocol,
> PhysicalAddress, Length);
> -ASSERT (!EFI_ERROR (Status));
> +if (EFI_ERROR (Status)) {
> +  DEBUG ((DEBUG_ERROR, "%a: Failed to AcceptMemory with %r\n",
> __FUNCTION__, Status));
> +  ASSERT (FALSE);
> +  return Status;
> +}
>}
> 
>DEBUG ((
> @@ -558,6 +576,8 @@ SetOrClearSharedBit (
>  Mode,
>  Status
>  ));
> +
> +  return EFI_SUCCESS;
>  }
> 
>  /**
> @@ -747,7 +767,11 @@ SetMemorySharedOrPrivate (
>// If we have at least 1GB to go, we can just update this entry
>//
>if (!(PhysicalAddress & (BIT30 - 1)) && (Length >= BIT30)) {
> -SetOrClearSharedBit (&PageDirectory1GEntry->Uint64, Mode,
> PhysicalAddress, BIT30);
> +Status = SetOrClearSharedBit (&PageDirectory1GEntry->Uint64, Mode,
> PhysicalAddress, BIT30);
> +if (EFI_ERROR (Status)) {
> +  goto Done;
> +}
> +
>  DEBUG ((
>DEBUG_VERBOSE,
>"%a:%a: updated 1GB entry for Physical=0x%Lx\n",
> @@ -809,7 +833,11 @@ SetMemorySharedOrPrivate (
>  // If we have at least 2MB left to go, we can just update this entry
>  //
>  if (!(PhysicalAddress & (BIT21-1)) && (Length >= BIT21)) {
> -  SetOrClearSharedBit (&PageDirectory2MEntry->Uint64, Mode,
> PhysicalAddress, BIT21);
> +  Status = SetOrClearSharedBit (&PageDirectory2MEntry->Uint64, Mode,
> PhysicalAddress, BIT21);
> +  if (EFI_ERROR (Status)) {
> +goto Done;
> +  }
> +
>PhysicalAddress += BIT21;
>Length  -= BIT21;
>  } else {
> @@ -856,7 +884,11 @@ SetMemorySharedOrPrivate (
>goto Done;
>  }
> 
> -SetOrClearSharedBit (&PageTableEntry->Uint64, Mode, PhysicalAddress,
> EFI_PAGE_SIZE);
> +Status = SetOrClearSharedBit (&PageTableEntry->Uint64, Mode,
> PhysicalAddress, EFI_PAGE_SIZE);
> +if (EFI_ERROR (Status)) {
> +

Re: [edk2-devel][edk2-non-osi][PATCH 1/1] ASpeed/ASpeedGopBinPkg: Update X64/AArch Gop UEFI Driver

[Isaac Oram]

Thanks Ard.

Tommy, I will wait for Patch V2 with the correct INF_VERSION.

Thanks,
Isaac

-Original Message-
From: Ard Biesheuvel  
Sent: Tuesday, January 17, 2023 3:16 PM
To: devel@edk2.groups.io; Oram, Isaac W 
Cc: Tommy Huang ; Desimone, Nathaniel L 
; quic_llind...@quicinc.com; Kinney, Michael D 
; Chen, Ryan ; 
bmc...@aspeedtech.com
Subject: Re: [edk2-devel][edk2-non-osi][PATCH 1/1] ASpeed/ASpeedGopBinPkg: 
Update X64/AArch Gop UEFI Driver

Note that the value in the INF_VERSION field cannot be chosen arbitrarily - it 
should be the latest version of the INF spec, so 1.29 (you don't need to put a 
hex value here, just "1.29" is fine)

On Tue, 17 Jan 2023 at 23:40, Isaac Oram  wrote:
>
> Reviewed-by: Isaac Oram 
>
> Note that you do not need a cover letter for single commit reviews.  It is 
> needed for multi-commit reviews so that you can describe the whole patch 
> series.
>
> -Original Message-
> From: Tommy Huang 
> Sent: Tuesday, January 10, 2023 10:08 PM
> To: devel@edk2.groups.io
> Cc: Desimone, Nathaniel L ; Oram, 
> Isaac W ; quic_llind...@quicinc.com; Kinney, 
> Michael D ; Chen, Ryan 
> ; bmc...@aspeedtech.com
> Subject: [edk2-devel][edk2-non-osi][PATCH 1/1] ASpeed/ASpeedGopBinPkg: 
> Update X64/AArch Gop UEFI Driver
>
> 1. Add ASpeedAst2600GopDxe.inf.
> 2. Add ASpeedAst2600Gop file for AArch64.
> 3. Update the others Gop UEFI binaries into the recently version. The version 
> will be v1.13.02.
>
> Cc: Isaac Oram 
> Cc: Nate DeSimone 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Cc: Ryan Chen 
> Cc: BMC-SW 
>
> Signed-off-by: Tommy Huang 
> ---
>  .../AArch64/ASpeedAst2500Gop.efi  | Bin 42880 -> 45056 bytes
>  .../AArch64/ASpeedAst2600Gop.efi  | Bin 0 -> 45056 bytes
>  .../ASpeedGopBinPkg/ASpeedAst2500GopDxe.inf   |   4 ++--
>  .../ASpeedGopBinPkg/ASpeedAst2600GopDxe.inf   |  22 ++
>  .../ASpeedGopBinPkg/X64/ASpeedAst2500Gop.efi  | Bin 36928 -> 33600 
> bytes  .../ASpeedGopBinPkg/X64/ASpeedAst2600Gop.efi  | Bin 32544 -> 
> 29952 bytes
>  6 files changed, 24 insertions(+), 2 deletions(-)  create mode 100644 
> Drivers/ASpeed/ASpeedGopBinPkg/AArch64/ASpeedAst2600Gop.efi
>  create mode 100644 
> Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2600GopDxe.inf
>


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

Re: [edk2-devel][edk2-non-osi][PATCH 1/1] ASpeed/ASpeedGopBinPkg: Update X64/AArch Gop UEFI Driver

[Tommy Huang]

Hi Ard and Isaac,

Thanks for review.
I will correct it and submit V2.

BR,

by Tommy

> -Original Message-
> From: Oram, Isaac W 
> Sent: Wednesday, January 18, 2023 8:16 AM
> To: Ard Biesheuvel ; devel@edk2.groups.io
> Cc: Tommy Huang ; Desimone, Nathaniel L
> ; quic_llind...@quicinc.com; Kinney,
> Michael D ; Ryan Chen
> ; BMC-SW 
> Subject: RE: [edk2-devel][edk2-non-osi][PATCH 1/1]
> ASpeed/ASpeedGopBinPkg: Update X64/AArch Gop UEFI Driver
> 
> Thanks Ard.
> 
> Tommy, I will wait for Patch V2 with the correct INF_VERSION.
> 
> Thanks,
> Isaac
> 
> -Original Message-
> From: Ard Biesheuvel 
> Sent: Tuesday, January 17, 2023 3:16 PM
> To: devel@edk2.groups.io; Oram, Isaac W 
> Cc: Tommy Huang ; Desimone, Nathaniel L
> ; quic_llind...@quicinc.com; Kinney,
> Michael D ; Chen, Ryan
> ; bmc...@aspeedtech.com
> Subject: Re: [edk2-devel][edk2-non-osi][PATCH 1/1]
> ASpeed/ASpeedGopBinPkg: Update X64/AArch Gop UEFI Driver
> 
> Note that the value in the INF_VERSION field cannot be chosen arbitrarily - it
> should be the latest version of the INF spec, so 1.29 (you don't need to put a
> hex value here, just "1.29" is fine)
> 
> On Tue, 17 Jan 2023 at 23:40, Isaac Oram  wrote:
> >
> > Reviewed-by: Isaac Oram 
> >
> > Note that you do not need a cover letter for single commit reviews.  It is
> needed for multi-commit reviews so that you can describe the whole patch
> series.
> >
> > -Original Message-
> > From: Tommy Huang 
> > Sent: Tuesday, January 10, 2023 10:08 PM
> > To: devel@edk2.groups.io
> > Cc: Desimone, Nathaniel L ; Oram,
> > Isaac W ; quic_llind...@quicinc.com; Kinney,
> > Michael D ; Chen, Ryan
> > ; bmc...@aspeedtech.com
> > Subject: [edk2-devel][edk2-non-osi][PATCH 1/1] ASpeed/ASpeedGopBinPkg:
> > Update X64/AArch Gop UEFI Driver
> >
> > 1. Add ASpeedAst2600GopDxe.inf.
> > 2. Add ASpeedAst2600Gop file for AArch64.
> > 3. Update the others Gop UEFI binaries into the recently version. The 
> > version
> will be v1.13.02.
> >
> > Cc: Isaac Oram 
> > Cc: Nate DeSimone 
> > Cc: Leif Lindholm 
> > Cc: Michael D Kinney 
> > Cc: Ryan Chen 
> > Cc: BMC-SW 
> >
> > Signed-off-by: Tommy Huang 
> > ---
> >  .../AArch64/ASpeedAst2500Gop.efi  | Bin 42880 -> 45056
> bytes
> >  .../AArch64/ASpeedAst2600Gop.efi  | Bin 0 -> 45056 bytes
> >  .../ASpeedGopBinPkg/ASpeedAst2500GopDxe.inf   |   4 ++--
> >  .../ASpeedGopBinPkg/ASpeedAst2600GopDxe.inf   |  22
> ++
> >  .../ASpeedGopBinPkg/X64/ASpeedAst2500Gop.efi  | Bin 36928 -> 33600
> > bytes  .../ASpeedGopBinPkg/X64/ASpeedAst2600Gop.efi  | Bin 32544 ->
> > 29952 bytes
> >  6 files changed, 24 insertions(+), 2 deletions(-)  create mode 100644
> > Drivers/ASpeed/ASpeedGopBinPkg/AArch64/ASpeedAst2600Gop.efi
> >  create mode 100644
> > Drivers/ASpeed/ASpeedGopBinPkg/ASpeedAst2600GopDxe.inf
> >


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

[Nate DeSimone]

Reviewed-by: Nate DeSimone 

-Original Message-
From: Benjamin Doron  
Sent: Friday, January 13, 2023 9:56 AM
To: devel@edk2.groups.io
Cc: Chaganty, Rangasai V ; Oram, Isaac W 
; Desimone, Nathaniel L 
; Chiu, Chasel 
Subject: [edk2-devel][edk2-platforms][PATCH v2] 
KabylakeOpenBoardPkg/I2cHdmiDebugSerialPortLib: Configurable timings

Now that an implementation of the HDMI debug port is available at high speed, 
make the timing parameters configurable. As this is implementation, not board 
dependent, perhaps these could become dynamic PCDs.

Arduino sketch available at
https://github.com/benjamindoron/i2c_debug_port.

Tested on Adafruit ItsyBitsy M4, using 1 MHz clock and 60 us delay.

Cc: Sai Chaganty 
Cc: Isaac Oram 
Cc: Nate DeSimone 
Cc: Chasel Chiu 
Signed-off-by: Benjamin Doron 
---
 .../DxeI2cHdmiDebugSerialPortLib.inf  |  2 ++
 .../Library/I2cHdmiDebugSerialPortLib/Gmbus.c |  9 +++--
 .../I2cDebugPortProtocol.c| 12 +---
 .../PeiI2cHdmiDebugSerialPortLib.inf  |  2 ++
 .../SecI2cHdmiDebugSerialPortLib.inf  |  2 ++
 .../SmmI2cHdmiDebugSerialPortLib.inf  |  2 ++
 .../KabylakeOpenBoardPkg/OpenBoardPkg.dec | 19 +++
 7 files changed, 43 insertions(+), 5 deletions(-)

diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/Library/I2cHdmiDebugSerialPortLib/DxeI2cHdmiDebugSerialPortLib.inf
 
b/Platform/Intel/KabylakeOpenBoardPkg/Library/I2cHdmiDebugSerialPortLib/DxeI2cHdmiDebugSerialPortLib.inf
index 736b11a561f0..e8af25161008 100644
--- 
a/Platform/Intel/KabylakeOpenBoardPkg/Library/I2cHdmiDebugSerialPortLib/DxeI2cHdmiDebugSerialPortLib.inf
+++ b/Platform/Intel/KabylakeOpenBoardPkg/Library/I2cHdmiDebugSerialPort
+++ Lib/DxeI2cHdmiDebugSerialPortLib.inf
@@ -51,3 +51,5 @@
 [Pcd]   gKabylakeOpenBoardPkgTokenSpaceGuid.PcdI2cHdmiDebugPortDdcI2cChannel   
 ## CONSUMES   gKabylakeOpenBoardPkgTokenSpaceGuid.PcdGttMmAddress  
   ## CONSUMES+  
gKabylakeOpenBoardPkgTokenSpaceGuid.PcdI2cHdmiDebugPortGmbusClockRate   ## 
CONSUMES+  gKabylakeOpenBoardPkgTokenSpaceGuid.PcdI2cHdmiDebugPortPacketStallUs 
   ## CONSUMESdiff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/Library/I2cHdmiDebugSerialPortLib/Gmbus.c 
b/Platform/Intel/KabylakeOpenBoardPkg/Library/I2cHdmiDebugSerialPortLib/Gmbus.c
index c6453117843a..31965a1b3a54 100644
--- 
a/Platform/Intel/KabylakeOpenBoardPkg/Library/I2cHdmiDebugSerialPortLib/Gmbus.c
+++ b/Platform/Intel/KabylakeOpenBoardPkg/Library/I2cHdmiDebugSerialPort
+++ Lib/Gmbus.c
@@ -443,6 +443,7 @@ GmbusRead (
 {   EFI_STATUS  Status;   EFI_STATUS  Status2;+  UINT8 
  GmbusClockRate;   UINT32  Index;   UINT32 
 GmbusCmdSts;   UINT32  GmbusStatus;@@ -472,7 
+473,8 @@ GmbusRead (
   //   // Configure Gmbus port and clock speed   //-  Status = GmbusPrepare 
(GMBUS_CLOCK_RATE_50K, (DdcBusPinPair & B_SA_GTTMMADR_GMBUS0_PIN_PAIR_MASK));+  
GmbusClockRate = FixedPcdGet8 (PcdI2cHdmiDebugPortGmbusClockRate);+  Status = 
GmbusPrepare (GmbusClockRate, (DdcBusPinPair & 
B_SA_GTTMMADR_GMBUS0_PIN_PAIR_MASK));   if (EFI_ERROR (Status)) { goto 
Done;   }@@ -607,6 +609,7 @@ GmbusWrite (
 {   EFI_STATUS  Status;   EFI_STATUS  Status2;+  UINT8 
  GmbusClockRate;   UINT32  Index;   UINT32 
 GmbusCmdSts;   UINT32  GmbusStatus;@@ -637,7 
+640,9 @@ GmbusWrite (
//   // Configure Gmbus port and clock speed-  Status = GmbusPrepare 
(GMBUS_CLOCK_RATE_50K, (DdcBusPinPair & B_SA_GTTMMADR_GMBUS0_PIN_PAIR_MASK));+  
//+  GmbusClockRate = FixedPcdGet8 (PcdI2cHdmiDebugPortGmbusClockRate);+  
Status = GmbusPrepare (GmbusClockRate, (DdcBusPinPair & 
B_SA_GTTMMADR_GMBUS0_PIN_PAIR_MASK));   if (EFI_ERROR (Status)) { goto 
Done;   }diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/Library/I2cHdmiDebugSerialPortLib/I2cDebugPortProtocol.c
 
b/Platform/Intel/KabylakeOpenBoardPkg/Library/I2cHdmiDebugSerialPortLib/I2cDebugPortProtocol.c
index f76bcf364cd1..d64251b75b4e 100644
--- 
a/Platform/Intel/KabylakeOpenBoardPkg/Library/I2cHdmiDebugSerialPortLib/I2cDebugPortProtocol.c
+++ b/Platform/Intel/KabylakeOpenBoardPkg/Library/I2cHdmiDebugSerialPort
+++ Lib/I2cDebugPortProtocol.c
@@ -38,6 +38,7 @@ I2cDebugPortWrite (
   UINT8   WriteBuffer[I2C_DEBUG_PORT_MAX_DATA_SIZE + 1];   EFI_STATUS  
Status;   UINT32  Index;+  UINT32  ImplementationDelayUs;   UINT8   
CurrentSize;   UINT8   DdcBusPinPair; @@ -51,9 +52,10 @@ I2cDebugPortWrite (
   if (EFI_ERROR (Status)) { return Status;   }+  ImplementationDelayUs = 
FixedPcdGet32 (PcdI2cHdmiDebugPortPacketStallUs);  //BP: 3ms stall to catch up  
 RaiseTplForI2cDebugPortAccess ();   for (Index = 0; Index < Count; Index += 
I2C_DEBUG_PORT_MAX_DATA_SIZE) {-MicroSecondDelay (3000);  //3ms stall to 
let the BusPirate catch up+MicroSecondDelay (ImplementationDelayUs); if 
((Index + I2C_DEBUG_POR

Re: [edk2-devel][edk2-platforms][PATCH v2] KabylakeOpenBoardPkg/I2cHdmiDebugSerialPortLib: Configurable timings

[Isaac Oram]

Pushed as 8e927b0f42..e43a63746f

-Original Message-
From: Desimone, Nathaniel L  
Sent: Tuesday, January 17, 2023 4:45 PM
To: Benjamin Doron ; devel@edk2.groups.io
Cc: Chaganty, Rangasai V ; Oram, Isaac W 
; Chiu, Chasel 
Subject: RE: [edk2-devel][edk2-platforms][PATCH v2] 
KabylakeOpenBoardPkg/I2cHdmiDebugSerialPortLib: Configurable timings

Reviewed-by: Nate DeSimone 

-Original Message-
From: Benjamin Doron  
Sent: Friday, January 13, 2023 9:56 AM
To: devel@edk2.groups.io
Cc: Chaganty, Rangasai V ; Oram, Isaac W 
; Desimone, Nathaniel L 
; Chiu, Chasel 
Subject: [edk2-devel][edk2-platforms][PATCH v2] 
KabylakeOpenBoardPkg/I2cHdmiDebugSerialPortLib: Configurable timings

Now that an implementation of the HDMI debug port is available at high speed, 
make the timing parameters configurable. As this is implementation, not board 
dependent, perhaps these could become dynamic PCDs.

Arduino sketch available at
https://github.com/benjamindoron/i2c_debug_port.

Tested on Adafruit ItsyBitsy M4, using 1 MHz clock and 60 us delay.

Cc: Sai Chaganty 
Cc: Isaac Oram 
Cc: Nate DeSimone 
Cc: Chasel Chiu 
Signed-off-by: Benjamin Doron 
---
 .../DxeI2cHdmiDebugSerialPortLib.inf  |  2 ++
 .../Library/I2cHdmiDebugSerialPortLib/Gmbus.c |  9 +++--
 .../I2cDebugPortProtocol.c| 12 +---
 .../PeiI2cHdmiDebugSerialPortLib.inf  |  2 ++
 .../SecI2cHdmiDebugSerialPortLib.inf  |  2 ++
 .../SmmI2cHdmiDebugSerialPortLib.inf  |  2 ++
 .../KabylakeOpenBoardPkg/OpenBoardPkg.dec | 19 +++
 7 files changed, 43 insertions(+), 5 deletions(-)

diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/Library/I2cHdmiDebugSerialPortLib/DxeI2cHdmiDebugSerialPortLib.inf
 
b/Platform/Intel/KabylakeOpenBoardPkg/Library/I2cHdmiDebugSerialPortLib/DxeI2cHdmiDebugSerialPortLib.inf
index 736b11a561f0..e8af25161008 100644
--- 
a/Platform/Intel/KabylakeOpenBoardPkg/Library/I2cHdmiDebugSerialPortLib/DxeI2cHdmiDebugSerialPortLib.inf
+++ b/Platform/Intel/KabylakeOpenBoardPkg/Library/I2cHdmiDebugSerialPort
+++ Lib/DxeI2cHdmiDebugSerialPortLib.inf
@@ -51,3 +51,5 @@
 [Pcd]   gKabylakeOpenBoardPkgTokenSpaceGuid.PcdI2cHdmiDebugPortDdcI2cChannel   
 ## CONSUMES   gKabylakeOpenBoardPkgTokenSpaceGuid.PcdGttMmAddress  
   ## CONSUMES+  
gKabylakeOpenBoardPkgTokenSpaceGuid.PcdI2cHdmiDebugPortGmbusClockRate   ## 
CONSUMES+  gKabylakeOpenBoardPkgTokenSpaceGuid.PcdI2cHdmiDebugPortPacketStallUs 
   ## CONSUMESdiff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/Library/I2cHdmiDebugSerialPortLib/Gmbus.c 
b/Platform/Intel/KabylakeOpenBoardPkg/Library/I2cHdmiDebugSerialPortLib/Gmbus.c
index c6453117843a..31965a1b3a54 100644
--- 
a/Platform/Intel/KabylakeOpenBoardPkg/Library/I2cHdmiDebugSerialPortLib/Gmbus.c
+++ b/Platform/Intel/KabylakeOpenBoardPkg/Library/I2cHdmiDebugSerialPort
+++ Lib/Gmbus.c
@@ -443,6 +443,7 @@ GmbusRead (
 {   EFI_STATUS  Status;   EFI_STATUS  Status2;+  UINT8 
  GmbusClockRate;   UINT32  Index;   UINT32 
 GmbusCmdSts;   UINT32  GmbusStatus;@@ -472,7 
+473,8 @@ GmbusRead (
   //   // Configure Gmbus port and clock speed   //-  Status = GmbusPrepare 
(GMBUS_CLOCK_RATE_50K, (DdcBusPinPair & B_SA_GTTMMADR_GMBUS0_PIN_PAIR_MASK));+  
GmbusClockRate = FixedPcdGet8 (PcdI2cHdmiDebugPortGmbusClockRate);+  Status = 
GmbusPrepare (GmbusClockRate, (DdcBusPinPair & 
B_SA_GTTMMADR_GMBUS0_PIN_PAIR_MASK));   if (EFI_ERROR (Status)) { goto 
Done;   }@@ -607,6 +609,7 @@ GmbusWrite (
 {   EFI_STATUS  Status;   EFI_STATUS  Status2;+  UINT8 
  GmbusClockRate;   UINT32  Index;   UINT32 
 GmbusCmdSts;   UINT32  GmbusStatus;@@ -637,7 
+640,9 @@ GmbusWrite (
//   // Configure Gmbus port and clock speed-  Status = GmbusPrepare 
(GMBUS_CLOCK_RATE_50K, (DdcBusPinPair & B_SA_GTTMMADR_GMBUS0_PIN_PAIR_MASK));+  
//+  GmbusClockRate = FixedPcdGet8 (PcdI2cHdmiDebugPortGmbusClockRate);+  
Status = GmbusPrepare (GmbusClockRate, (DdcBusPinPair & 
B_SA_GTTMMADR_GMBUS0_PIN_PAIR_MASK));   if (EFI_ERROR (Status)) { goto 
Done;   }diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/Library/I2cHdmiDebugSerialPortLib/I2cDebugPortProtocol.c
 
b/Platform/Intel/KabylakeOpenBoardPkg/Library/I2cHdmiDebugSerialPortLib/I2cDebugPortProtocol.c
index f76bcf364cd1..d64251b75b4e 100644
--- 
a/Platform/Intel/KabylakeOpenBoardPkg/Library/I2cHdmiDebugSerialPortLib/I2cDebugPortProtocol.c
+++ b/Platform/Intel/KabylakeOpenBoardPkg/Library/I2cHdmiDebugSerialPort
+++ Lib/I2cDebugPortProtocol.c
@@ -38,6 +38,7 @@ I2cDebugPortWrite (
   UINT8   WriteBuffer[I2C_DEBUG_PORT_MAX_DATA_SIZE + 1];   EFI_STATUS  
Status;   UINT32  Index;+  UINT32  ImplementationDelayUs;   UINT8   
CurrentSize;   UINT8   DdcBusPinPair; @@ -51,9 +52,10 @@ I2cDebugPortWrite (
   if (EFI_ERROR (Status)) { return Status;   }+  Implementati

Re: [edk2-devel] [PATCH] UefiCpuPkg: Fix SMM code hangs when InitPaging

[Zhiguang Liu]

Thanks all for reviewing, and I will send a new version to address the comment.

As for Gerd's question, let me explain.
Let's see one example, that the CPU has SizeOfMemorySpace >48, but the CPU 
doesn't enable 5 level paging.
The purpose of the current function InitPaging is to modify existing page 
table. To use the same logic to handle both 5 level and 4 level paging, for 4 
level paging, the logic will create a false 5 level paging entry to treat it 
like a 5 level page table. This way, the number of 5 level paging should always 
be one. If we use SizeOfMemorySpace to calculate the 5 level paging entry 
count, we will get number more than one.  However, as I just mentioned, we only 
create one false 5 level paging entry, system may hang when we try to access 
the second 5 level paging entry. This patch fixes the issue by always letting 
the number of 5 level paging entry as one if 5 level paging is disabled.

Thanks
Zhiguang

> -Original Message-
> From: Ni, Ray 
> Sent: Tuesday, January 17, 2023 8:49 PM
> To: devel@edk2.groups.io; kra...@redhat.com
> Cc: Liu, Zhiguang ; Kumar, Rahul R
> ; Dong, Eric 
> Subject: RE: [edk2-devel] [PATCH] UefiCpuPkg: Fix SMM code hangs when
> InitPaging
> 
> > > > +ASSERT (SizeOfMemorySpace <= 52);
> > > > +
> > > >  //
> > > > -// Calculate the table entries of PML4E and PDPTE.
> > > > +// Calculate the table entries of PML5E, PML4E and PDPTE.
> > > >  //
> > > >  NumberOfPml5Entries = 1;
> > > > -if (SizeOfMemorySpace > 48) {
> > > > +if (Enable5LevelPaging && (SizeOfMemorySpace > 48)) {
> > > >NumberOfPml5Entries = (UINTN)LShiftU64 (1, SizeOfMemorySpace -
> 48);
> > > > -  SizeOfMemorySpace   = 48;
> > > >  }
> > > >
> > > > +SizeOfMemorySpace   = SizeOfMemorySpace > 48 ? 48 :
> SizeOfMemorySpace;
> >
> > if (SizeOfMemorySpace > 48) {
> > if (Enable5LevelPaging) {
> >  NumberOfPml5Entries = ...
> > }
> > SizeOfMemorySpace = 48
> > }
> >
> > That is a much more readable version.
> 
> I had the same thought. New version is consistent with the logic below.
> 
> 
> >
> > The only effect I can see is that this avoids creating page tables
> > which would not be used anyway.
> >
> > Can you explain where the hangs mentioned in the subject line are
> > coming from and why the patch fixes them?
> 
> 
> >
> > take care,
> >   Gerd
> >
> >
> >
> > 
> >



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

[edk2-devel] [PATCH v2] UefiCpuPkg: Fix SMM code hangs when InitPaging

[Zhiguang Liu]

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

In function InitPaging, NumberOfPml5Entries is calculated by below code
NumberOfPml5Entries = (UINTN)LShiftU64 (1, SizeOfMemorySpace - 48);
If the SizeOfMemorySpace is larger than 48, NumberOfPml5Entries will be
larger than 1. However, this doesn't make sense if the hardware doesn't
support 5 level page table.

Cc: Gerd Hoffmann 
Cc: Rahul Kumar 
Reviewed-by: Star Zeng 
Reviewed-by: Wu, Jiaxin 
Reviewed-by: Ray Ni 
Signed-off-by: Eric Dong 
Signed-off-by: Zhiguang Liu 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
index c1efda7126..1b0b6673e1 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
@@ -1,7 +1,7 @@
 /** @file
 Enable SMM profile.
 
-Copyright (c) 2012 - 2019, Intel Corporation. All rights reserved.
+Copyright (c) 2012 - 2023, Intel Corporation. All rights reserved.
 Copyright (c) 2017 - 2020, AMD Incorporated. All rights reserved.
 
 SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -587,13 +587,18 @@ InitPaging (
 }
 
 SizeOfMemorySpace = HighBitSet64 (gPhyMask) + 1;
+ASSERT (SizeOfMemorySpace <= 52);
+
 //
-// Calculate the table entries of PML4E and PDPTE.
+// Calculate the table entries of PML5E, PML4E and PDPTE.
 //
 NumberOfPml5Entries = 1;
 if (SizeOfMemorySpace > 48) {
-  NumberOfPml5Entries = (UINTN)LShiftU64 (1, SizeOfMemorySpace - 48);
-  SizeOfMemorySpace   = 48;
+  if (Enable5LevelPaging) {
+NumberOfPml5Entries = (UINTN)LShiftU64 (1, SizeOfMemorySpace - 48);
+  }
+
+  SizeOfMemorySpace = 48;
 }
 
 NumberOfPml4Entries = 1;
-- 
2.31.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98748): https://edk2.groups.io/g/devel/message/98748
Mute This Topic: https://groups.io/mt/96345457/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 V1 0/2] Update Si support

[Nate DeSimone]

Good work Isaac!

For the series...

Reviewed-by: Nate DeSimone 

-Original Message-
From: Oram, Isaac W  
Sent: Thursday, January 12, 2023 3:57 PM
To: devel@edk2.groups.io
Cc: Oram, Isaac W ; Desimone, Nathaniel L 
; Chiu, Chasel 
Subject: [edk2-devel][edk2-platforms][PATCH V1 0/2] Update Si support

Updates for latest validated FSP, 4.2.0.2A.
There are binary incompatible Dispatch mode interface changes necessary.
API mode interfaces are unchanged.

Cc: Nate DeSimone 
Cc: Chasel Chiu 

Isaac Oram (2):
  WhitleySiliconPkg: Update to Whitley FSP 4.2.0.2A
  WhitleyOpenBoardPkg: Update to Whitley FSP 4.2.0.2A

 .../Dxe/PlatformCpuPolicy/PlatformCpuPolicy.c |   2 +-
 .../AcpiTables/Dsdt/CommonPlatform10nm.asi|   1 +
 .../Pci/Dxe/PciHostBridge/PciRebalance.c  | 243 ++
 .../Include/Dsc/BuildOptions.dsc  |   2 +-
 .../Include/Dsc/EnableRichDebugMessages.dsc   |   9 +
 .../Include/Guid/SetupVariable.h  |   3 +
 .../SiliconPolicyUpdateLib.c  |   2 +-
 .../SiliconPolicyUpdateLibFsp.c   |   2 +-
 .../WhitleyOpenBoardPkg/PlatformPkgConfig.dsc |   6 +-
 .../WhitleyOpenBoardPkg/StructurePcd.dsc  | 173 -
 .../WhitleyOpenBoardPkg/StructurePcdCpx.dsc   |  91 ++-
 Silicon/Intel/WhitleySiliconPkg/CpRcPkg.dec   |  23 +-
 .../Intel/WhitleySiliconPkg/Cpu/CpuRcPkg.dec  |   4 +-
 .../Cpu/Include/CpuPolicyPeiDxeCommon.h   |   2 +-
 .../WhitleySiliconPkg/Include/BdatSchema.h|  16 +-
 .../Include/Guid/MemoryMapData.h  |   4 +-
 .../Include/Guid/SocketIioVariable.h  |  13 +-
 .../Include/Guid/SocketMemoryVariable.h   |   3 +
 .../Include/Guid/SocketPciResourceData.h  |   4 +-
 .../Guid/SocketPowermanagementVariable.h  |   2 +
 .../Guid/SocketProcessorCoreVariable.h|   2 +-
 .../WhitleySiliconPkg/Include/IioConfig.h |  11 +-
 .../Intel/WhitleySiliconPkg/Include/IioRegs.h |   1 -
 .../Include/Library/EnhancedWarningLogLib.h   |   2 -
 .../Include/PlatformInfoTypes.h   |  16 +-
 .../Include/Ppi/MemoryPolicyPpi.h |  10 +
 .../Include/Ppi/RasImcS3Data.h|   6 -
 .../WhitleySiliconPkg/Include/Upi/KtiHost.h   |   2 -
 .../Core/Include/DataTypes.h  |  10 +-
 .../BaseMemoryCoreLib/Core/Include/MemHost.h  |   6 +-
 .../BaseMemoryCoreLib/Platform/PlatformHost.h |   5 -
 .../Include/Private/Library/PchSpiCommonLib.h |   1 -
 .../Product/Whitley/SiliconPkg10nmPcds.dsc|   5 +
 .../SecurityIp/SecurityIpSgxTem1v0_Inputs.h   |   2 +-
 .../SecurityIp/SecurityIpSgxTem1v0_Outputs.h  |   2 +-
 .../Intel/WhitleySiliconPkg/SiliconPkg.dec|  26 +-
 36 files changed, 521 insertions(+), 191 deletions(-)

--
2.39.0.windows.1


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

Re: [edk2-devel] [PATCH V1 1/7] OvmfPkg: Add Tdx measurement data structure in WorkArea

[Min Xu]

On January 17, 2023 7:26 PM, Gerd Hoffmann wrote:
> On Tue, Jan 17, 2023 at 03:40:10PM +0800, Min Xu wrote:
> > From: Min M Xu 
> >
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4243
> >
> > From the perspective of security any external input should be measured
> > and extended to some registers (TPM PCRs or TDX RTMR registers).
> >
> > There are below 2 external input in a Td guest:
> >  - TdHob
> >  - Configuration FV (CFV)
> >
> > TdHob contains the resource information passed from VMM, such as
> > unaccepted memory region. CFV contains the configurations, such as
> > secure boot variables.
> >
> > TdHob and CFV should be measured and extended to RTMRs before they're
> > consumed. TdHob is consumed in the very early stage of boot process.
> > At that moment the memory service is not ready. Cfv is consumed in
> > PlatformPei to initialize the EmuVariableNvStore. To make the
> > implementation simple and clean, these 2 external input are measured
> > and extended to RTMRs in SEC phase.  The measurement values are stored
> > in WorkArea. Then after the Hob service is available, these 2
> > measurement values are retrieved and GuidHobs for these 2 tdx
> > measurements are generated.
> 
> So the measurement is done early and the hashes are stored to create the
> event log entries later, correct?
Yes.
> 
> Why both TdHob and CFV are handled this way?  It should be needed for
> TdHob only, right?  The work area has a fixed size, IMHO we should not store
> data there unless we absolutely have to, and for CFV I don't see the
> justification.
In our first design CFV was measured and extended in PEI phase. Because CFV is 
consumed in PlatformInitEmuVariableNvStore. 
But then we find a problem. That we must either refactor the 
HashLibBaseCryptoRouterPei or introduce a new HashLib in PEI phase.
1) If HashLibBaseCryptoRouterPei is to be refactored to support 
tdx-measurement, then it must detect the tdx-guest in run-time so that it can 
determine to call Tpm2PcrExtend or call TdxExtendRtmr. 
2) If we import a new HashLib in PEI phase, we are facing another problem, that 
we have to load either the new HashLib or HashLibBaseCryptoRouterPei in 
run-time.

Cfv is measured and extended in both OvmfPkgX64 and IntelTdxX64. Our current 
design reduces the code duplication of measurement, as well as the generation 
of GuidHob for the measurement. We have the helper function in SEC phase to do 
the measurement for TdHob, it's easy to measure Cfv as well. From the security 
perspective, the earlier the Cfv is measured/extended the better.

As to the work-area, now the size of work-area is 4096 bytes. Before this patch 
TDX uses 4+16 bytes. TDX_MEASUREMENTS_DATA uses 4+48+48=100 bytes. So totally 
120 bytes are used. I don't think the size is a problem. And if Cfv is measured 
in SEC phase, then its measurement value has to be stored in work-area.

Based on above consideration, we finally propose this solution.

Thanks
Min


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

[edk2-devel] [PATCH] MdeModulePkg ScsiDiskDxe: Remove the left git merge comments

[gaoliming via groups.io]

Signed-off-by: Christopher Zurcher 
Reviewed-by: Liming Gao 
---
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c 
b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
index 6555aeed7d..f424ebd041 100644
--- a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
+++ b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
@@ -3,10 +3,7 @@
 
 Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 Copyright (c) 1985 - 2022, American Megatrends International LLC.
-<<< HEAD
-===
 
->>> ace365b4e0 (MdeModulePkg/scsi :Coverity scan flags multiple issues in 
edk2-stable202205)
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
-- 
2.37.3.windows.1




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

[edk2-devel] [PATCH V3 0/3] Add NULL IpmiCommandLib instance

[Chang, Abner via groups.io]

From: Abner Chang 

BZ# 4231

In V3: Add Igor Kulchytskyy's Reviewed-by
In V2: Address the typos.

This patch adds a NULL instance of IpmiCommandLib to remove
the dependence between edk2 and edk2-platform packages.

Signed-off-by: Abner Chang 
Cc: Jian J Wang 
Cc: Liming Gao 
Cc: Nickle Wang 
Cc: Igor Kulchytskyy 
Cc: Isaac Oram 
Cc: Nate DeSimone 

Abner Chang (3):
  MdeModulePkg/Include: Add IpmiCommandLib header file
  MdeModulePkg/IpmiCommandLib: Add NULL instance library
  MdeModulePkg: Add IpmiCommandLib

 MdeModulePkg/MdeModulePkg.dec |   5 +
 MdeModulePkg/MdeModulePkg.dsc |   3 +
 .../BaseIpmiCommandLibNull.inf|  34 +
 MdeModulePkg/Include/Library/IpmiCommandLib.h | 683 ++
 .../IpmiCommandLibNetFnApp.c  | 252 +++
 .../IpmiCommandLibNetFnChassis.c  | 123 
 .../IpmiCommandLibNetFnStorage.c  | 248 +++
 .../IpmiCommandLibNetFnTransport.c| 100 +++
 8 files changed, 1448 insertions(+)
 create mode 100644 
MdeModulePkg/Library/BaseIpmiCommandLibNull/BaseIpmiCommandLibNull.inf
 create mode 100644 MdeModulePkg/Include/Library/IpmiCommandLib.h
 create mode 100644 
MdeModulePkg/Library/BaseIpmiCommandLibNull/IpmiCommandLibNetFnApp.c
 create mode 100644 
MdeModulePkg/Library/BaseIpmiCommandLibNull/IpmiCommandLibNetFnChassis.c
 create mode 100644 
MdeModulePkg/Library/BaseIpmiCommandLibNull/IpmiCommandLibNetFnStorage.c
 create mode 100644 
MdeModulePkg/Library/BaseIpmiCommandLibNull/IpmiCommandLibNetFnTransport.c

-- 
2.37.1.windows.1



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

[edk2-devel] [PATCH V3 2/3] MdeModulePkg/IpmiCommandLib: Add NULL instance library

[Chang, Abner via groups.io]

From: Abner Chang 

The NULL instance of IpmiCommandLib library under
MdeModulePkg as the default IpmiCommandLib instance
used by the modules under edk2.

Signed-off-by: Abner Chang 
Cc: Jian J Wang 
Cc: Liming Gao 
Cc: Nickle Wang 
Cc: Igor Kulchytskyy 
Cc: Isaac Oram 
Cc: Nate DeSimone 
Reviewed-by: Isaac Oram 
Reviewed-by: Igor Kulchytskyy 
---
 .../BaseIpmiCommandLibNull.inf|  34 +++
 .../IpmiCommandLibNetFnApp.c  | 252 ++
 .../IpmiCommandLibNetFnChassis.c  | 123 +
 .../IpmiCommandLibNetFnStorage.c  | 248 +
 .../IpmiCommandLibNetFnTransport.c| 100 +++
 5 files changed, 757 insertions(+)
 create mode 100644 
MdeModulePkg/Library/BaseIpmiCommandLibNull/BaseIpmiCommandLibNull.inf
 create mode 100644 
MdeModulePkg/Library/BaseIpmiCommandLibNull/IpmiCommandLibNetFnApp.c
 create mode 100644 
MdeModulePkg/Library/BaseIpmiCommandLibNull/IpmiCommandLibNetFnChassis.c
 create mode 100644 
MdeModulePkg/Library/BaseIpmiCommandLibNull/IpmiCommandLibNetFnStorage.c
 create mode 100644 
MdeModulePkg/Library/BaseIpmiCommandLibNull/IpmiCommandLibNetFnTransport.c

diff --git 
a/MdeModulePkg/Library/BaseIpmiCommandLibNull/BaseIpmiCommandLibNull.inf 
b/MdeModulePkg/Library/BaseIpmiCommandLibNull/BaseIpmiCommandLibNull.inf
new file mode 100644
index 000..175e1ae433c
--- /dev/null
+++ b/MdeModulePkg/Library/BaseIpmiCommandLibNull/BaseIpmiCommandLibNull.inf
@@ -0,0 +1,34 @@
+## @file
+# NULL instance of IpmiCommandLib
+#
+# Component description file for IPMI Command Library.
+#
+# Copyright (c) 2018 - 2021, Intel Corporation. All rights reserved.
+# Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = BaseIpmiCommandLibNull
+  FILE_GUID  = 63F06EF8-B78A-4E7E-823E-D11A21059669
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = IpmiCommandLib
+
+[sources]
+  IpmiCommandLibNetFnApp.c
+  IpmiCommandLibNetFnTransport.c
+  IpmiCommandLibNetFnChassis.c
+  IpmiCommandLibNetFnStorage.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+
+[LibraryClasses]
+  BaseMemoryLib
+  DebugLib
+
diff --git 
a/MdeModulePkg/Library/BaseIpmiCommandLibNull/IpmiCommandLibNetFnApp.c 
b/MdeModulePkg/Library/BaseIpmiCommandLibNull/IpmiCommandLibNetFnApp.c
new file mode 100644
index 000..2312e08258d
--- /dev/null
+++ b/MdeModulePkg/Library/BaseIpmiCommandLibNull/IpmiCommandLibNetFnApp.c
@@ -0,0 +1,252 @@
+/** @file
+  IPMI Command - NetFnApp NULL instance library.
+
+  Copyright (c) 2018 - 2021, Intel Corporation. All rights reserved.
+  Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+#include 
+#include 
+
+/**
+  This function gets the IPMI Device ID.
+
+  @param[out] DeviceId  Get device ID response.
+
+  @retval EFI_UNSUPPORTED  Unsupported in the NULL lib.
+
+**/
+EFI_STATUS
+EFIAPI
+IpmiGetDeviceId (
+  OUT IPMI_GET_DEVICE_ID_RESPONSE  *DeviceId
+  )
+{
+  return RETURN_UNSUPPORTED;
+}
+
+/**
+  This function gets the self-test result.
+
+  @param[out] SelfTestResult  Self test command response.
+
+  @retval EFI_UNSUPPORTED  Unsupported in the NULL lib.
+
+**/
+EFI_STATUS
+EFIAPI
+IpmiGetSelfTestResult (
+  OUT IPMI_SELF_TEST_RESULT_RESPONSE  *SelfTestResult
+  )
+{
+  return RETURN_UNSUPPORTED;
+}
+
+/**
+  This function resets watchdog timer.
+
+  @param[out] CompletionCode  The command completion code.
+
+  @retval EFI_UNSUPPORTED  Unsupported in the NULL lib.
+
+**/
+EFI_STATUS
+EFIAPI
+IpmiResetWatchdogTimer (
+  OUT UINT8  *CompletionCode
+  )
+{
+  return RETURN_UNSUPPORTED;
+}
+
+/**
+  This function sets watchdog timer.
+
+  @param[in] SetWatchdogTimer  Set watchdog timer request.
+  @param[out] CompletionCode   The command completion code.
+
+  @retval EFI_UNSUPPORTED  Unsupported in the NULL lib.
+
+**/
+EFI_STATUS
+EFIAPI
+IpmiSetWatchdogTimer (
+  IN  IPMI_SET_WATCHDOG_TIMER_REQUEST  *SetWatchdogTimer,
+  OUT UINT8*CompletionCode
+  )
+{
+  return RETURN_UNSUPPORTED;
+}
+
+/**
+  This function gets watchdog timer.
+
+  @param[out] GetWatchdogTimer  Get watchdog timer response.
+
+  @retval EFI_UNSUPPORTED  Unsupported in the NULL lib.
+
+**/
+EFI_STATUS
+EFIAPI
+IpmiGetWatchdogTimer (
+  OUT IPMI_GET_WATCHDOG_TIMER_RESPONSE  *GetWatchdogTimer
+  )
+{
+  return RETURN_UNSUPPORTED;
+}
+
+/**
+  This function sets BMC global enables.
+
+  @param[in]  SetBmcGlobalEnablesSet BMC global enables command request.
+  @param[out] CompletionCode The command completion code.
+
+  @retval EFI_UNSUPPORTED  Unsupported in the NULL lib.
+
+**/
+EFI_STATUS
+EFIAPI
+IpmiSetBmcGlobalEnables (
+  IN  IPMI_SET_BMC_GLOBAL_ENABLES_REQUEST  *SetBmcGl

[edk2-devel] [PATCH V3 3/3] MdeModulePkg: Add IpmiCommandLib

[Chang, Abner via groups.io]

From: Abner Chang 

Add IpmiCommandLib to MdeModulePkg DEC/DSC
files.

Signed-off-by: Abner Chang 
Cc: Jian J Wang 
Cc: Liming Gao 
Cc: Nickle Wang 
Cc: Igor Kulchytskyy 
Cc: Isaac Oram 
Cc: Nate DeSimone 
Reviewed-by: Isaac Oram 
Reviewed-by: Igor Kulchytskyy 
---
 MdeModulePkg/MdeModulePkg.dec | 5 +
 MdeModulePkg/MdeModulePkg.dsc | 3 +++
 2 files changed, 8 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index be5e829ca9c..9605c617b7a 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -9,6 +9,7 @@
 # (C) Copyright 2016 - 2019 Hewlett Packard Enterprise Development LP
 # Copyright (c) 2017, AMD Incorporated. All rights reserved.
 # Copyright (c) Microsoft Corporation.
+# Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 #
 ##
@@ -117,6 +118,10 @@
   #
   IpmiLib|Include/Library/IpmiLib.h
 
+  ## @libraryclass  Provides interfaces to send/receive IPMI command.
+  #
+  IpmiCommandLib|Include/Library/IpmiCommandLib.h
+
   ## @libraryclass  Provides interfaces for platform to return root bridge 
information to PciHostBridgeDxe driver.
   #
   PciHostBridgeLib|Include/Library/PciHostBridgeLib.h
diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index 659482ab737..1014598f31c 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -4,6 +4,7 @@
 # (C) Copyright 2014 Hewlett-Packard Development Company, L.P.
 # Copyright (c) 2007 - 2021, Intel Corporation. All rights reserved.
 # Copyright (c) Microsoft Corporation.
+# Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
 #
 #SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -104,6 +105,7 @@
   
VariablePolicyHelperLib|MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.inf
   
MmUnblockMemoryLib|MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf
   
VariableFlashInfoLib|MdeModulePkg/Library/BaseVariableFlashInfoLib/BaseVariableFlashInfoLib.inf
+  
IpmiCommandLib|MdeModulePkg/Library/BaseIpmiCommandLibNull/BaseIpmiCommandLibNull.inf
 
 [LibraryClasses.EBC.PEIM]
   IoLib|MdePkg/Library/PeiIoLibCpuIo/PeiIoLibCpuIo.inf
@@ -333,6 +335,7 @@
   MdeModulePkg/Library/DxeIpmiLibIpmiProtocol/DxeIpmiLibIpmiProtocol.inf
   MdeModulePkg/Library/PeiIpmiLibIpmiPpi/PeiIpmiLibIpmiPpi.inf
   MdeModulePkg/Library/SmmIpmiLibSmmIpmiProtocol/SmmIpmiLibSmmIpmiProtocol.inf
+  MdeModulePkg/Library/BaseIpmiCommandLibNull/BaseIpmiCommandLibNull.inf
   MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
   
MdeModulePkg/Library/NonDiscoverableDeviceRegistrationLib/NonDiscoverableDeviceRegistrationLib.inf
   MdeModulePkg/Library/BaseBmpSupportLib/BaseBmpSupportLib.inf
-- 
2.37.1.windows.1



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

[edk2-devel] [PATCH V3 1/3] MdeModulePkg/Include: Add IpmiCommandLib header file

[Chang, Abner via groups.io]

From: Abner Chang 

Add IpmiCommandLib to MdeModulePkg. This header file is
copied from edk2-platforms/Features/Intel/OutOfBandManagement/
IpmiFeaturePkg\Include\Library. Having this header file in
edk2 to avoid the dependence of edk2 module with edk2-platfrom.
The NULL instance of IpmiCommandLib under MdeModulePkg has
to be implemented for the same reason.
IpmiCommandLib.h in edk2-platforms should be removed once
this patch set is merged. Expect no impacts on edk2-platforms
because MdeModulePkg is referred in INF file by all edk2
modules under edk2-platforms that use IpmiCommandLib.

Signed-off-by: Abner Chang 
Cc: Jian J Wang 
Cc: Liming Gao 
Cc: Nickle Wang 
Cc: Igor Kulchytskyy 
Cc: Isaac Oram 
Cc: Nate DeSimone 
Reviewed-by: Isaac Oram 
Reviewed-by: Igor Kulchytskyy 
---
 MdeModulePkg/Include/Library/IpmiCommandLib.h | 683 ++
 1 file changed, 683 insertions(+)
 create mode 100644 MdeModulePkg/Include/Library/IpmiCommandLib.h

diff --git a/MdeModulePkg/Include/Library/IpmiCommandLib.h 
b/MdeModulePkg/Include/Library/IpmiCommandLib.h
new file mode 100644
index 000..7edaf36cbe5
--- /dev/null
+++ b/MdeModulePkg/Include/Library/IpmiCommandLib.h
@@ -0,0 +1,683 @@
+/** @file
+  This library abstract how to send/receive IPMI command.
+
+Copyright (c) 2018-2021, Intel Corporation. All rights reserved.
+Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
+
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef IPMI_COMMAND_LIB_H_
+#define IPMI_COMMAND_LIB_H_
+
+#include 
+#include 
+
+//
+// IPMI NetFnApp
+//
+
+/**
+  This function gets the IPMI Device ID.
+
+  @param[out] DeviceId  Get device ID response.
+
+  @retval EFI_SUCCESSCommand is sent successfully.
+  @retval EFI_NOT_AVAILABLE_YET  Transport interface is not ready yet.
+  @retval Other  Failure.
+
+**/
+EFI_STATUS
+EFIAPI
+IpmiGetDeviceId (
+  OUT IPMI_GET_DEVICE_ID_RESPONSE  *DeviceId
+  );
+
+/**
+  This function gets the self-test result.
+
+  @param[out] SelfTestResult  Self test command response.
+
+  @retval EFI_SUCCESSCommand is sent successfully.
+  @retval EFI_NOT_AVAILABLE_YET  Transport interface is not ready yet.
+  @retval Other  Failure.
+
+**/
+EFI_STATUS
+EFIAPI
+IpmiGetSelfTestResult (
+  OUT IPMI_SELF_TEST_RESULT_RESPONSE  *SelfTestResult
+  );
+
+/**
+  This function resets watchdog timer.
+
+  @param[out] CompletionCode  The command completion code.
+
+  @retval EFI_SUCCESSCommand is sent successfully.
+  @retval EFI_NOT_AVAILABLE_YET  Transport interface is not ready yet.
+  @retval Other  Failure.
+
+**/
+EFI_STATUS
+EFIAPI
+IpmiResetWatchdogTimer (
+  OUT UINT8  *CompletionCode
+  );
+
+/**
+  This function sets watchdog timer.
+
+  @param[in] SetWatchdogTimer  Set watchdog timer request.
+  @param[out] CompletionCode   The command completion code.
+
+  @retval EFI_SUCCESSCommand is sent successfully.
+  @retval EFI_NOT_AVAILABLE_YET  Transport interface is not ready yet.
+  @retval Other  Failure.
+
+
+**/
+EFI_STATUS
+EFIAPI
+IpmiSetWatchdogTimer (
+  IN  IPMI_SET_WATCHDOG_TIMER_REQUEST  *SetWatchdogTimer,
+  OUT UINT8*CompletionCode
+  );
+
+/**
+  This function gets watchdog timer.
+
+  @param[out] GetWatchdogTimer  Get watchdog timer response.
+
+  @retval EFI_SUCCESSCommand is sent successfully.
+  @retval EFI_NOT_AVAILABLE_YET  Transport interface is not ready yet.
+  @retval Other  Failure.
+
+**/
+EFI_STATUS
+EFIAPI
+IpmiGetWatchdogTimer (
+  OUT IPMI_GET_WATCHDOG_TIMER_RESPONSE  *GetWatchdogTimer
+  );
+
+/**
+  This function sets BMC global enables.
+
+  @param[in]  SetBmcGlobalEnablesSet BMC global enables command request.
+  @param[out] CompletionCode The command completion code.
+
+  @retval EFI_SUCCESSCommand is sent successfully.
+  @retval EFI_NOT_AVAILABLE_YET  Transport interface is not ready yet.
+  @retval Other  Failure.
+
+**/
+EFI_STATUS
+EFIAPI
+IpmiSetBmcGlobalEnables (
+  IN  IPMI_SET_BMC_GLOBAL_ENABLES_REQUEST  *SetBmcGlobalEnables,
+  OUT UINT8*CompletionCode
+  );
+
+/**
+  This function gets BMC global enables.
+
+  @param[out]  GetBmcGlobalEnables  Get BMC global enables command response.
+
+  @retval EFI_SUCCESSCommand is sent successfully.
+  @retval EFI_NOT_AVAILABLE_YET  Transport interface is not ready yet.
+  @retval Other  Failure.
+
+**/
+EFI_STATUS
+EFIAPI
+IpmiGetBmcGlobalEnables (
+  OUT IPMI_GET_BMC_GLOBAL_ENABLES_RESPONSE  *GetBmcGlobalEnables
+  );
+
+/**
+  This function clears message flag.
+
+  @param[in]ClearMessageFlagsRequest  Clear message flags command request.
+  @param[out]   CompletionCodeThe command completion code.
+
+  @retval EFI_SUCCESSCommand is sent successfully.
+  @retval EFI_NOT_AVAILABLE_YET  Transport interface is not r

Re: [edk2-devel] [PATCH V3 0/4] Introduce Separate-Fv in OvmfPkg/IntelTdx

[Yao, Jiewen]

Reviewed-by: Jiewen Yao 

Merged https://github.com/tianocore/edk2/pull/3916

> -Original Message-
> From: Gerd Hoffmann 
> Sent: Tuesday, January 17, 2023 6:58 PM
> To: Xu, Min M 
> Cc: devel@edk2.groups.io; Leif Lindholm ; Ard
> Biesheuvel ; Abner Chang
> ; Daniel Schaefer ; Aktas,
> Erdem ; James Bottomley ;
> Yao, Jiewen ; Tom Lendacky
> 
> Subject: Re: [PATCH V3 0/4] Introduce Separate-Fv in OvmfPkg/IntelTdx
> 
> On Tue, Jan 17, 2023 at 07:31:54AM +0800, Min Xu wrote:
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4152
> >
> > In current DXE FV there are 100+ drivers. Some of the drivers are not
> > used in Td guest. (Such as USB support drivers, network related
> > drivers, etc).
> >
> > From the security perspective if a driver is not used, we should prevent
> > it from being loaded/started. There are 2 benefits:
> > 1. Reduce the attack surface
> > 2. Improve the boot performance
> >
> > So we introduce Separate-Fv which separates DXEFV into 2 FVs: DXEFV
> > and NCCFV. All the drivers which are not needed by a Confidential
> > Computing guest are moved from DXEFV to NCCFV.
> >
> > When booting a CC guest only the drivers in DXEFV will be loaded and
> > started. For a Non-CC guest both DXEFV and NCCFV drivers will be
> > loaded and started.
> >
> > Patch#1 updates EmbeddedPkg/PrePiLib with FFS_CHECK_SECTION_HOOK.
> > Patch#2 adds PCDs/GUID for NCCFV.
> > Patch#3 moves cc-unused drivers to NCCFV.
> > Patch#4 update PeilessStartupLib to find NCCFV for non-cc guest.
> 
> series:
> Acked-by: Gerd Hoffmann 
> 
> take care,
>   Gerd



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

[edk2-devel] 回复: [PATCH V2] MdeModulePkg/Decompress: Add missing source file to Brotli library

[gaoliming via groups.io]

Abner:
  What problem will be caused without those source files?

Thanks
Liming
> -邮件原件-
> 发件人: abner.ch...@amd.com 
> 发送时间: 2023年1月12日 13:08
> 收件人: devel@edk2.groups.io
> 抄送: Dandan Bi ; Liming Gao
> ; Garrett Kirkendall
> ; Abner Chang 
> 主题: [PATCH V2] MdeModulePkg/Decompress: Add missing source file to
> Brotli library
> 
> From: Abner Chang 
> 
> Add missing source files to Brotli library INF.
> 
> Signed-off-by: Jiangang He 
> Cc: Dandan Bi 
> Cc: Liming Gao 
> Cc: Garrett Kirkendall 
> Cc: Abner Chang 
> ---
>  .../BrotliCustomDecompressLib/BrotliCustomDecompressLib.inf  | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git
> a/MdeModulePkg/Library/BrotliCustomDecompressLib/BrotliCustomDecomp
> ressLib.inf
> b/MdeModulePkg/Library/BrotliCustomDecompressLib/BrotliCustomDecomp
> ressLib.inf
> index 525e92408d6..244c2e35023 100644
> ---
> a/MdeModulePkg/Library/BrotliCustomDecompressLib/BrotliCustomDecomp
> ressLib.inf
> +++
> b/MdeModulePkg/Library/BrotliCustomDecompressLib/BrotliCustomDecomp
> ressLib.inf
> @@ -5,6 +5,7 @@
>  #  Brotli was released on the website https://github.com/google/brotli.
>  #
>  #  Copyright (c) 2017 - 2020, Intel Corporation. All rights reserved.
> +#  Copyright (C) 2023 Advanced Micro Devices, Inc. All rights
reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -41,6 +42,10 @@
># Wrapper header files end #
>brotli/c/common/dictionary.c
>brotli/c/common/transform.c
> +  brotli/c/common/context.c
> +  brotli/c/common/platform.c
> +  brotli/c/common/constants.c
> +  brotli/c/common/shared_dictionary.c
>brotli/c/dec/bit_reader.c
>brotli/c/dec/decode.c
>brotli/c/dec/huffman.c
> --
> 2.37.1.windows.1





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98757): https://edk2.groups.io/g/devel/message/98757
Mute This Topic: https://groups.io/mt/96347071/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] MdeModulePkg/Decompress: Add missing source file to Brotli library

[Chang, Abner via groups.io]

[AMD Official Use Only - General]

Forwarding this question to Jiangang and Tim.

Abner

> -Original Message-
> From: gaoliming 
> Sent: Wednesday, January 18, 2023 11:20 AM
> To: Chang, Abner ; devel@edk2.groups.io
> Cc: 'Dandan Bi' ; Kirkendall, Garrett
> 
> Subject: 回复: [PATCH V2] MdeModulePkg/Decompress: Add missing source
> file to Brotli library
> 
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
> 
> 
> Abner:
>   What problem will be caused without those source files?
> 
> Thanks
> Liming
> > -邮件原件-
> > 发件人: abner.ch...@amd.com 
> > 发送时间: 2023年1月12日 13:08
> > 收件人: devel@edk2.groups.io
> > 抄送: Dandan Bi ; Liming Gao
> > ; Garrett Kirkendall
> > ; Abner Chang 
> > 主题: [PATCH V2] MdeModulePkg/Decompress: Add missing source file to
> > Brotli library
> >
> > From: Abner Chang 
> >
> > Add missing source files to Brotli library INF.
> >
> > Signed-off-by: Jiangang He 
> > Cc: Dandan Bi 
> > Cc: Liming Gao 
> > Cc: Garrett Kirkendall 
> > Cc: Abner Chang 
> > ---
> >  .../BrotliCustomDecompressLib/BrotliCustomDecompressLib.inf  | 5
> > +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git
> >
> a/MdeModulePkg/Library/BrotliCustomDecompressLib/BrotliCustomDecom
> p
> > ressLib.inf
> >
> b/MdeModulePkg/Library/BrotliCustomDecompressLib/BrotliCustomDecom
> p
> > ressLib.inf
> > index 525e92408d6..244c2e35023 100644
> > ---
> >
> a/MdeModulePkg/Library/BrotliCustomDecompressLib/BrotliCustomDecom
> p
> > ressLib.inf
> > +++
> >
> b/MdeModulePkg/Library/BrotliCustomDecompressLib/BrotliCustomDecom
> p
> > ressLib.inf
> > @@ -5,6 +5,7 @@
> >  #  Brotli was released on the website https://github.com/google/brotli.
> >  #
> >  #  Copyright (c) 2017 - 2020, Intel Corporation. All rights
> > reserved.
> > +#  Copyright (C) 2023 Advanced Micro Devices, Inc. All rights
> reserved.
> >  #
> >  #  SPDX-License-Identifier: BSD-2-Clause-Patent  # @@ -41,6 +42,10 @@
> ># Wrapper header files end #
> >brotli/c/common/dictionary.c
> >brotli/c/common/transform.c
> > +  brotli/c/common/context.c
> > +  brotli/c/common/platform.c
> > +  brotli/c/common/constants.c
> > +  brotli/c/common/shared_dictionary.c
> >brotli/c/dec/bit_reader.c
> >brotli/c/dec/decode.c
> >brotli/c/dec/huffman.c
> > --
> > 2.37.1.windows.1
> 
> 


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

Re: [edk2-devel] [PATCH V3 0/2] [PATCH V1 0/2] Refactor TDX MmioExit

[Yao, Jiewen]

Reviewed-by: Jiewen Yao 

Merged https://github.com/tianocore/edk2/pull/3918

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Gerd
> Hoffmann
> Sent: Tuesday, January 17, 2023 7:33 PM
> To: Xu, Min M 
> Cc: devel@edk2.groups.io; Aktas, Erdem ; James
> Bottomley ; Yao, Jiewen ; Tom
> Lendacky ; Afranji, Ryan 
> Subject: Re: [edk2-devel] [PATCH V3 0/2] [PATCH V1 0/2] Refactor TDX
> MmioExit
> 
> On Tue, Jan 17, 2023 at 03:43:28PM +0800, Min Xu wrote:
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4169
> >
> > The previous TDX MmioExit doesn't handle the Mmio instructions correctly
> > in some scenarios. This patch-set refactors the implementation to fix the
> > issues.
> >
> > Before the refactoring, common X86 instruction codes in CcExitVcHandler.c
> > are moved to separate files (CcInstruction.h / CcInstruction.c) so that
> > these codes can be re-used in TDX.
> >
> > Code: https://github.com/mxu9/edk2/tree/TdxMmioExit.v3
> >
> > v3 changes:
> >  - Handle the error if an error is returned from TdxMmioReadWrite.
> >  - Add more check in ParseMmioExitInstructions.
> >
> > v2 changes:
> >  - Add CpuDeadLoop () after each TDVMCALL(HALT) in VE handler. Because
> >TDVMCALL(HALT) is not trusted.
> >  - Other minor changes such as deleting ASSERT in VE handler. Because
> >any error in VE handler will trigger CpuDeadLoop (). So ASSERT is not
> >needed any more.
> 
> Series:
> Acked-by: Gerd Hoffmann 
> 
> 
> 
> 
> 



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