Re: [edk2-devel] [PATCH] BaseTools/tools_def: Disable unneeded-internal-declaration warning in CLANGPDB

[Ard Biesheuvel]

On Tue, 12 Dec 2023 at 08:17, Mike Beaton  wrote:
>
> > > A completely different approach, which allows clang to spot that the
> > > usage has been 'optimised away' and so to not complain (and therefore
> > > allows us to re-enable the warning in CLANGDWARF as well), is the
> > > following:
> > >
> > > --- a/MdePkg/Include/Library/DebugLib.h
> > > +++ b/MdePkg/Include/Library/DebugLib.h
> > > @@ -426,7 +426,10 @@ UnitTestDebugAssert (
> > >}\
> > >  } while (FALSE)
> > >  #else
> > > -#define DEBUG(Expression)
> > > +#define DEBUG(Expression)\
> > > +if (FALSE) {   \
> > > +  _DEBUG (Expression); \
> > > +}
> > >  #endif
> > >
> > >  /**
> > >
> >
> > But will this not litter the object files with a bunch of format strings
> > etc?
>
> Yes. Which would be optimized away at link time. (Or rather, I believe
> so, would need further tests to confirm exactly what is optimized away
> when.)
>

Link time optimization does not usually optimize away assets at this
granularity. Even if --gc-sections is set, the only thing it can
optimize away is an entire input section.

However, the compiler should be smart enough not to emit any
references to format strings etc in the first place, as it knows the
condition can never become true (but NOOPT builds should retain them).

> > It feels like, for CLANGPDB (and maybe CLANGDWARF), the RELEASE target
> > should not define MDEPKG_NDEBUG, but make sure (instead) that
> > DebugPrintEnabled() evals to FALSE. If PcdDebugPropertyMask is
> > fixed-at-build, then DebugPrintEnabled() should be possible to evaluate
> > at compile time; is that right? (At least for clang?)
>
> Yes, that is my understanding of how compile-time Pcds work too - but
> wouldn't the net result be the same as what I suggested?

It depends on the kind of access. For PCDs that are fixed-at-build
only, the FixedPcdGet###() accessors will evaluate to constant
preprocessor expressions, allowing the compiler to do optimizations.
The ordinary PcdGet###() routines will not produce compile time
constant expressions in the same way, so there, all the logic is
retained (again, modulo LTO)


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

Re: [edk2-devel] [PATCH] BaseTools/tools_def: Disable unneeded-internal-declaration warning in CLANGPDB

[Mike Beaton]

> > A completely different approach, which allows clang to spot that the
> > usage has been 'optimised away' and so to not complain (and therefore
> > allows us to re-enable the warning in CLANGDWARF as well), is the
> > following:
> >
> > --- a/MdePkg/Include/Library/DebugLib.h
> > +++ b/MdePkg/Include/Library/DebugLib.h
> > @@ -426,7 +426,10 @@ UnitTestDebugAssert (
> >}\
> >  } while (FALSE)
> >  #else
> > -#define DEBUG(Expression)
> > +#define DEBUG(Expression)\
> > +if (FALSE) {   \
> > +  _DEBUG (Expression); \
> > +}
> >  #endif
> >
> >  /**
> >
>
> But will this not litter the object files with a bunch of format strings
> etc?

Yes. Which would be optimized away at link time. (Or rather, I believe
so, would need further tests to confirm exactly what is optimized away
when.)

> It feels like, for CLANGPDB (and maybe CLANGDWARF), the RELEASE target
> should not define MDEPKG_NDEBUG, but make sure (instead) that
> DebugPrintEnabled() evals to FALSE. If PcdDebugPropertyMask is
> fixed-at-build, then DebugPrintEnabled() should be possible to evaluate
> at compile time; is that right? (At least for clang?)

Yes, that is my understanding of how compile-time Pcds work too - but
wouldn't the net result be the same as what I suggested?


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112358): https://edk2.groups.io/g/devel/message/112358
Mute This Topic: https://groups.io/mt/103087794/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 06/11] CryptoPkg: Add all .inf files for BaseCryptLibMbedTls

[Alexey Kardashevskiy via groups.io]

ah never mind, sorry for the noise. Needed to build BaseTools/Source/C 
and install some packages.



On 12/12/23 14:52, Alexey Kardashevskiy via groups.io wrote:

Hi,

This broke build:

nice build -q --cmd-len=64436 -n 20 -t GCC5 -a X64 -p 
OvmfPkg/OvmfPkgX64.dsc


build.py...
/home/aik/p/o-snp/CryptoPkg/CryptoPkg.dec(32): error 000E: 
File/directory not found in workspace

     /home/aik/p/o-snp/CryptoPkg/Library/MbedTlsLib/mbedtls/include

What am I missing? Thanks,


On 29/9/23 01:34, Wenxing Hou via groups.io wrote:

Add .inf files and other support files.

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

Cc: Jiewen Yao 
Cc: Yi Li 
Cc: Xiaoyu Lu 
Cc: Guomin Jiang 
Signed-off-by: Wenxing Hou 
---
  CryptoPkg/CryptoPkg.dec   |   4 +
  CryptoPkg/CryptoPkgMbedTls.dsc    | 280 +++
  .../BaseCryptLibMbedTls/BaseCryptLib.inf  |  81 +++
  .../BaseCryptLibMbedTls/PeiCryptLib.inf   | 101 
  .../BaseCryptLibMbedTls/PeiCryptLib.uni   |  25 +
  .../BaseCryptLibMbedTls/RuntimeCryptLib.inf   |  92 
  .../BaseCryptLibMbedTls/RuntimeCryptLib.uni   |  22 +
  .../BaseCryptLibMbedTls/SecCryptLib.inf   |  84 
  .../BaseCryptLibMbedTls/SecCryptLib.uni   |  17 +
  .../BaseCryptLibMbedTls/SmmCryptLib.inf   |  92 
  .../BaseCryptLibMbedTls/SmmCryptLib.uni   |  22 +
  .../SysCall/ConstantTimeClock.c   |  75 +++
  .../BaseCryptLibMbedTls/SysCall/CrtWrapper.c  |  58 +++
  .../SysCall/RuntimeMemAllocation.c    | 462 ++
  .../SysCall/TimerWrapper.c    | 198 
  .../BaseCryptLibMbedTls/TestBaseCryptLib.inf  |  76 +++
  CryptoPkg/Library/Include/stdint.h    |  19 +
  CryptoPkg/Library/Include/stubs-32.h  |   9 +
  CryptoPkg/Library/MbedTlsLib/EcSm2Null.c  |   2 +-
  19 files changed, 1718 insertions(+), 1 deletion(-)
  create mode 100644 CryptoPkg/CryptoPkgMbedTls.dsc
  create mode 100644 
CryptoPkg/Library/BaseCryptLibMbedTls/BaseCryptLib.inf
  create mode 100644 
CryptoPkg/Library/BaseCryptLibMbedTls/PeiCryptLib.inf
  create mode 100644 
CryptoPkg/Library/BaseCryptLibMbedTls/PeiCryptLib.uni
  create mode 100644 
CryptoPkg/Library/BaseCryptLibMbedTls/RuntimeCryptLib.inf
  create mode 100644 
CryptoPkg/Library/BaseCryptLibMbedTls/RuntimeCryptLib.uni
  create mode 100644 
CryptoPkg/Library/BaseCryptLibMbedTls/SecCryptLib.inf
  create mode 100644 
CryptoPkg/Library/BaseCryptLibMbedTls/SecCryptLib.uni
  create mode 100644 
CryptoPkg/Library/BaseCryptLibMbedTls/SmmCryptLib.inf
  create mode 100644 
CryptoPkg/Library/BaseCryptLibMbedTls/SmmCryptLib.uni
  create mode 100644 
CryptoPkg/Library/BaseCryptLibMbedTls/SysCall/ConstantTimeClock.c
  create mode 100644 
CryptoPkg/Library/BaseCryptLibMbedTls/SysCall/CrtWrapper.c
  create mode 100644 
CryptoPkg/Library/BaseCryptLibMbedTls/SysCall/RuntimeMemAllocation.c
  create mode 100644 
CryptoPkg/Library/BaseCryptLibMbedTls/SysCall/TimerWrapper.c
  create mode 100644 
CryptoPkg/Library/BaseCryptLibMbedTls/TestBaseCryptLib.inf

  create mode 100644 CryptoPkg/Library/Include/stdint.h
  create mode 100644 CryptoPkg/Library/Include/stubs-32.h

diff --git a/CryptoPkg/CryptoPkg.dec b/CryptoPkg/CryptoPkg.dec
index 0c7d16109b..a5fa81a338 100644
--- a/CryptoPkg/CryptoPkg.dec
+++ b/CryptoPkg/CryptoPkg.dec
@@ -27,6 +27,10 @@
    Library/OpensslLib/openssl/providers/implementations/include
    Library/OpensslLib/OpensslGen/include
    Library/OpensslLib/OpensslGen/providers/common/include
+  Library/MbedTlsLib/Include
+  Library/MbedTlsLib/mbedtls
+  Library/MbedTlsLib/mbedtls/include
+  Library/MbedTlsLib/mbedtls/include/mbedtls
  [LibraryClasses]
    ##  @libraryclass  Provides basic library functions for 
cryptographic primitives.
diff --git a/CryptoPkg/CryptoPkgMbedTls.dsc 
b/CryptoPkg/CryptoPkgMbedTls.dsc

new file mode 100644
index 00..5d0ae6ff3f
--- /dev/null
+++ b/CryptoPkg/CryptoPkgMbedTls.dsc
@@ -0,0 +1,280 @@
+## @file
+#  Cryptographic Library Package for UEFI Security Implementation.
+#  PEIM, DXE Driver, and SMM Driver with all crypto services enabled.
+#
+#  Copyright (c) 2023, Intel Corporation. All rights reserved.
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+
+#
+# Defines Section - statements that will be processed to create a 
Makefile.

+#
+
+[Defines]
+  PLATFORM_NAME  = CryptoPkg
+  PLATFORM_GUID  = E1063286-6C8C-4c25-AEF0-67A9A5B6E6B6
+  PLATFORM_VERSION   = 0.98
+  DSC_SPECIFICATION  = 0x00010005
+  OUTPUT_DIRECTORY   = Build/CryptoPkgMbed
+  SUPPORTED_ARCHITECTURES    = IA32|X64|ARM|AARCH64|RISCV64
+  BUILD_TARGETS  = DEBUG|RELEASE|NOOPT
+  SKUID_IDENTIFIER   = DEFAULT
+
+!ifndef CRYPTO_IMG_TYPE
+  DEFINE CRYPTO_IMG_TYPE = 

Re: [edk2-devel] [PATCH v3 06/11] CryptoPkg: Add all .inf files for BaseCryptLibMbedTls

[Alexey Kardashevskiy via groups.io]

Hi,

This broke build:

nice build -q --cmd-len=64436 -n 20 -t GCC5 -a X64 -p OvmfPkg/OvmfPkgX64.dsc

build.py...
/home/aik/p/o-snp/CryptoPkg/CryptoPkg.dec(32): error 000E: 
File/directory not found in workspace

/home/aik/p/o-snp/CryptoPkg/Library/MbedTlsLib/mbedtls/include

What am I missing? Thanks,


On 29/9/23 01:34, Wenxing Hou via groups.io wrote:

Add .inf files and other support files.

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

Cc: Jiewen Yao 
Cc: Yi Li 
Cc: Xiaoyu Lu 
Cc: Guomin Jiang 
Signed-off-by: Wenxing Hou 
---
  CryptoPkg/CryptoPkg.dec   |   4 +
  CryptoPkg/CryptoPkgMbedTls.dsc| 280 +++
  .../BaseCryptLibMbedTls/BaseCryptLib.inf  |  81 +++
  .../BaseCryptLibMbedTls/PeiCryptLib.inf   | 101 
  .../BaseCryptLibMbedTls/PeiCryptLib.uni   |  25 +
  .../BaseCryptLibMbedTls/RuntimeCryptLib.inf   |  92 
  .../BaseCryptLibMbedTls/RuntimeCryptLib.uni   |  22 +
  .../BaseCryptLibMbedTls/SecCryptLib.inf   |  84 
  .../BaseCryptLibMbedTls/SecCryptLib.uni   |  17 +
  .../BaseCryptLibMbedTls/SmmCryptLib.inf   |  92 
  .../BaseCryptLibMbedTls/SmmCryptLib.uni   |  22 +
  .../SysCall/ConstantTimeClock.c   |  75 +++
  .../BaseCryptLibMbedTls/SysCall/CrtWrapper.c  |  58 +++
  .../SysCall/RuntimeMemAllocation.c| 462 ++
  .../SysCall/TimerWrapper.c| 198 
  .../BaseCryptLibMbedTls/TestBaseCryptLib.inf  |  76 +++
  CryptoPkg/Library/Include/stdint.h|  19 +
  CryptoPkg/Library/Include/stubs-32.h  |   9 +
  CryptoPkg/Library/MbedTlsLib/EcSm2Null.c  |   2 +-
  19 files changed, 1718 insertions(+), 1 deletion(-)
  create mode 100644 CryptoPkg/CryptoPkgMbedTls.dsc
  create mode 100644 CryptoPkg/Library/BaseCryptLibMbedTls/BaseCryptLib.inf
  create mode 100644 CryptoPkg/Library/BaseCryptLibMbedTls/PeiCryptLib.inf
  create mode 100644 CryptoPkg/Library/BaseCryptLibMbedTls/PeiCryptLib.uni
  create mode 100644 CryptoPkg/Library/BaseCryptLibMbedTls/RuntimeCryptLib.inf
  create mode 100644 CryptoPkg/Library/BaseCryptLibMbedTls/RuntimeCryptLib.uni
  create mode 100644 CryptoPkg/Library/BaseCryptLibMbedTls/SecCryptLib.inf
  create mode 100644 CryptoPkg/Library/BaseCryptLibMbedTls/SecCryptLib.uni
  create mode 100644 CryptoPkg/Library/BaseCryptLibMbedTls/SmmCryptLib.inf
  create mode 100644 CryptoPkg/Library/BaseCryptLibMbedTls/SmmCryptLib.uni
  create mode 100644 
CryptoPkg/Library/BaseCryptLibMbedTls/SysCall/ConstantTimeClock.c
  create mode 100644 CryptoPkg/Library/BaseCryptLibMbedTls/SysCall/CrtWrapper.c
  create mode 100644 
CryptoPkg/Library/BaseCryptLibMbedTls/SysCall/RuntimeMemAllocation.c
  create mode 100644 
CryptoPkg/Library/BaseCryptLibMbedTls/SysCall/TimerWrapper.c
  create mode 100644 CryptoPkg/Library/BaseCryptLibMbedTls/TestBaseCryptLib.inf
  create mode 100644 CryptoPkg/Library/Include/stdint.h
  create mode 100644 CryptoPkg/Library/Include/stubs-32.h

diff --git a/CryptoPkg/CryptoPkg.dec b/CryptoPkg/CryptoPkg.dec
index 0c7d16109b..a5fa81a338 100644
--- a/CryptoPkg/CryptoPkg.dec
+++ b/CryptoPkg/CryptoPkg.dec
@@ -27,6 +27,10 @@
Library/OpensslLib/openssl/providers/implementations/include
Library/OpensslLib/OpensslGen/include
Library/OpensslLib/OpensslGen/providers/common/include
+  Library/MbedTlsLib/Include
+  Library/MbedTlsLib/mbedtls
+  Library/MbedTlsLib/mbedtls/include
+  Library/MbedTlsLib/mbedtls/include/mbedtls
  
  [LibraryClasses]

##  @libraryclass  Provides basic library functions for cryptographic 
primitives.
diff --git a/CryptoPkg/CryptoPkgMbedTls.dsc b/CryptoPkg/CryptoPkgMbedTls.dsc
new file mode 100644
index 00..5d0ae6ff3f
--- /dev/null
+++ b/CryptoPkg/CryptoPkgMbedTls.dsc
@@ -0,0 +1,280 @@
+## @file
+#  Cryptographic Library Package for UEFI Security Implementation.
+#  PEIM, DXE Driver, and SMM Driver with all crypto services enabled.
+#
+#  Copyright (c) 2023, Intel Corporation. All rights reserved.
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+
+#
+# Defines Section - statements that will be processed to create a Makefile.
+#
+
+[Defines]
+  PLATFORM_NAME  = CryptoPkg
+  PLATFORM_GUID  = E1063286-6C8C-4c25-AEF0-67A9A5B6E6B6
+  PLATFORM_VERSION   = 0.98
+  DSC_SPECIFICATION  = 0x00010005
+  OUTPUT_DIRECTORY   = Build/CryptoPkgMbed
+  SUPPORTED_ARCHITECTURES= IA32|X64|ARM|AARCH64|RISCV64
+  BUILD_TARGETS  = DEBUG|RELEASE|NOOPT
+  SKUID_IDENTIFIER   = DEFAULT
+
+!ifndef CRYPTO_IMG_TYPE
+  DEFINE CRYPTO_IMG_TYPE = DXE_SMM
+!endif
+
+!if $(CRYPTO_IMG_TYPE) IN "PEI_DEFAULT PEI_PREMEM DXE_SMM"
+!else
+  !error CRYPTO_IMG_TYPE must be set to one of PEI_DEFAULT PEI_PREMEM DXE_SMM.
+!endif
+
+##

Re: [edk2-devel] [PATCH v3 11/39] UefiCpuPkg: Add LoongArch64 CPU Timer library

[Chao Li]

Hi Laszlo,

Thanks for reviewing again this patch while you are sick and please take 
care.


My opinion is as follow:


Thanks,
Chao
On 2023/12/12 01:16, Laszlo Ersek wrote:

On 11/23/23 12:43, Chao Li wrote:

On 2023/11/23 00:12, Laszlo Ersek wrote:

On 11/17/23 11:00, Chao Li wrote:

Add the LoongArch64 CPU Timer library, using CPUCFG 0x4 and 0x5 for
Stable Counter frequency.

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

Cc: Eric Dong
Cc: Ray Ni
Cc: Rahul Kumar
Cc: Gerd Hoffmann
Signed-off-by: Chao Li
---
  .../BaseLoongArch64CpuTimerLib.inf|  30 +++
  .../BaseLoongArch64CpuTimerLib.uni|  15 ++
  .../BaseLoongArch64CpuTimerLib/CpuTimerLib.c  | 226 ++
  UefiCpuPkg/UefiCpuPkg.dsc |   3 +
  4 files changed, 274 insertions(+)
  create mode 100644 
UefiCpuPkg/Library/BaseLoongArch64CpuTimerLib/BaseLoongArch64CpuTimerLib.inf
  create mode 100644 
UefiCpuPkg/Library/BaseLoongArch64CpuTimerLib/BaseLoongArch64CpuTimerLib.uni
  create mode 100644 UefiCpuPkg/Library/BaseLoongArch64CpuTimerLib/CpuTimerLib.c

(1) sorry about the annoying comment, but the library should be
called (preferably) BaseTimerLibLoongArch64Cpu.

We're frequently not consistent with the following library instance
naming scheme, but in theory anyway, library instances should be
named as follows:

   

Thus, in this case, Base + TimerLib + LoongArch64Cpu.

update UNI file name, INF file name, directory name, BASE_NAME and
MODULE_UNI_FILE accordingly (if you agree)

There has a SPEC for naming style:

https://github.com/tianocore-docs/edk2-CCodingStandardsSpecification/blob/master/4_naming_conventions/42_directory_names.md

Please check 4.2.3 EDKII Library directory, and most directory naming
follows this SPEC.

I didn't remember (or know about) this part of the coding standards
spec; thanks for the pointer.

It seems like my suggestion matches the second alternative
([]).

Your naming seems to follow the first alternative
([]). OK.

However, that's still not a perfect match. For , you have "Base".
For , you have "LoongArch64". But for , you
have "CpuTimerLib", and that's wrong. We don't have a "CpuTimerLib"
class; instead it's the "TimerLib" class.
The part of "CpuTimerLib" uses the name located at 
UefiCpuPkg/Library/CpuTimerLib, so this library is named 
BaseLoongArch64CpuTimerLib.


The LIBRARY_CLASS define in your INF file also says "TimerLib", so
"CpuTimerLib" is wrong / inconsistent in the lib instance name.
"BaseLoongArch64TimerLib" should be fine. If you want to add "Cpu", I
guess you could add it as [], as a suffix, under the first
naming scheme alternative: "BaseLoongArch64TimerLibCpu".


I think the name "CpuTimerLib" highlights the "CPU", because this 
library relies on the CPU interal timer. So should I use the 
"CpuTimerLib" as ?


Ray, what do you suggest?




(5) Relatedly: the TimerLib class is declared in "MdePkg.dec". Thus,
if you indeed don't need anything from "UefiCpuPkg.dec", I'd suggest
moving this library instance under MdePkg.

It is inappropriate to place this library in MdePkg, because the
MdePkg doesn't have any CpuTimerLib instance, and this class library
are HW implementation-related, so it more appropriate to place it in
UefiCpuPkg.

This ties in with my above comment. The reason for MdePkg not having a
"CpuTimerLib" instance is that there is no such lib class in edk2.

The library class is called "TimerLib". We have multiple instances in
edk2:

$ git grep -l 'LIBRARY_CLASS *= *TimerLib\>' -- '*inf'

   ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
   EmulatorPkg/Library/DxeCoreTimerLib/DxeCoreTimerLib.inf
   EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.inf
   EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.inf
   MdePkg/Library/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf
   MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
   OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf
   OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLibBhyve.inf
   OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
   OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
   PcAtChipsetPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf
   PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
   PcAtChipsetPkg/Library/AcpiTimerLib/PeiAcpiTimerLib.inf
   PcAtChipsetPkg/Library/AcpiTimerLib/StandaloneMmAcpiTimerLib.inf
   UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/BaseRiscV64CpuTimerLib.inf
   UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
   UefiCpuPkg/Library/SecPeiDxeTimerLibUefiCpu/SecPeiDxeTimerLibUefiCpu.inf
   UefiPayloadPkg/Library/AcpiTimerLib/AcpiTimerLib.inf

This "prior art" suggests the new library instance could go in MdePkg or
UefiCpuPkg alike.

That's where my comment about "UefiCpuPkg.dec" dependencies becomes
relevant. Compare:

- MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
- UefiCpuPkg/Library/SecPeiDxeTimerLibUefiCpu/SecPeiDxeTimerLibUefiCpu.inf

The difference between these library instances (as the INF files
explain) is

[edk2-devel] Event: TianoCore Bug Triage - APAC / NAMO - Tuesday, December 12, 2023 #cal-reminder

[Group Notification]

*Reminder: TianoCore Bug Triage - APAC / NAMO*

*When:*
Tuesday, December 12, 2023
6:30pm to 7:30pm
(UTC-08:00) America/Los Angeles

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

*Organizer:* Liming Gao gaolim...@byosoft.com.cn ( 
gaolim...@byosoft.com.cn?subject=Re:%20Event:%20TianoCore%20Bug%20Triage%20-%20APAC%20%2F%20NAMO
 )

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

*Description:*

TianoCore Bug Triage - APAC / NAMO

Hosted by Liming Gao



Microsoft Teams meeting

*Join on your computer or mobile app*

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

*Join with a video conferencing device*

te...@conf.intel.com

Video Conference ID: 116 062 094 0

Alternate VTC dialing instructions ( 
https://conf.intel.com/teams/?conf=1160620940&ivr=teams&d=conf.intel.com&test=test_call
 )

*Or call in (audio only)*

+1 916-245-6934,,77463821# ( tel:+19162456934,,77463821# ) United States, 
Sacramento

Phone Conference ID: 774 638 21#

Find a local number ( 
https://dialin.teams.microsoft.com/d195d438-2daa-420e-b9ea-da26f9d1d6d5?id=77463821
 ) | Reset PIN ( https://mysettings.lync.com/pstnconferencing )

Learn More ( https://aka.ms/JoinTeamsMeeting ) | Meeting options ( 
https://teams.microsoft.com/meetingOptions/?organizerId=b286b53a-1218-4db3-bfc9-3d4c5aa7669e&tenantId=46c98d88-e344-4ed4-8496-4ed7712e255d&threadId=19_meeting_OTUyZTg2NjgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh@thread.v2&messageId=0&language=en-US
 )


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112354): https://edk2.groups.io/g/devel/message/112354
Mute This Topic: https://groups.io/mt/103123254/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 V3 0/6] Create and consume a new gMpInformationHobGuid2 in UefiCpuPkg.

[duntan]

Hi Laszlo,

Thanks for your reply. Sorry that I didn't add you in the reviewer list from 
the beginning of this patch series review. About the patch review, please take 
your time. Also take care your body!

The patch set was reviewed-by Ray last week. So I think we can merge the patch 
set first. You can ping me if you have any comments about this patch set later.

Thanks,
Dun

-Original Message-
From: Laszlo Ersek  
Sent: Monday, December 11, 2023 9:50 PM
To: Tan, Dun ; devel@edk2.groups.io
Cc: Ni, Ray ; Ard Biesheuvel ; Kinney, 
Michael D ; Gerd Hoffmann 
Subject: Re: [edk2-devel] [Patch V3 0/6] Create and consume a new 
gMpInformationHobGuid2 in UefiCpuPkg.

Hi Dun,

On 12/11/23 04:16, Tan, Dun wrote:
> Hi Laszlo,
> 
> Previously I sent a patch set " Move gMpInformationHobGuid from 
> StandaloneMmPkg to UefiCpuPkg. " and thanks for your review. To solve the 
> issue that the maximum length of one HOB might not be enough when CPU count 
> is 1-2000 or bigger and extend the HOB, we decide to create a new MpInfo2Hob 
> in UefiCpuPkg in this patch set. Do you have any comments about the patch set?
> 
> Thanks,
> Dun

A few days ago I made an effort to at least identify the newest patch sets I 
should "sometime" review on edk2, including those that apparently superseded 
older versions. Thus, although not with 100% certainty, I did deduce the above 
"change of plan", i.e., that the movement of the existent info HOB between 
packages would be superseded by a brand new HOB. However, all I could do at the 
time was simply tagging the new version for review -- and that's where I stand 
now.

For reference, I have approx. 14+ patch sets tagged for review on edk2-devel -- 
these have accumulated due to my 2 weeks long sick leave.
I'm back to work for 4 days this week, but then I'll disappear again until the 
end of the year. So, I think I had best declare "email bankruptcy".

Apologies for blocking you -- I had made some efforts to inform my 
co-maintainers of my status meanwhile. So, please don't wait for my feedback at 
this time; I might catch up, if I'm lucky, but I probably won't be able to. So 
if Ray is pleased with your patches, please go ahead and merge them.

I might make comments on smaller patches this week; rest assured that that kind 
of "preference" is just practicality, not laziness. It feels hopeless for me to 
make a serious "dent" in reviewing any larger patch set this week, so I'll try 
to spend review effort where it has a fleeting chance at enabling actual 
progress.

Best regards,
Laszlo


> 
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of duntan
> Sent: Friday, December 8, 2023 5:55 PM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] [Patch V3 0/6] Create and consume a new 
> gMpInformationHobGuid2 in UefiCpuPkg.
> 
> In the V3 patch set,
> In patch "UefiCpuPkg: Build MpInfo2HOB in CpuMpPei", the DEBUG message format 
> is modified In patch "UefiCpuPkg: Consume MpInfo2Hob in PiSmmCpuDxe", remove 
> unneccesary assert check.
> In patch "UefiCpuPkg: Avoid assuming only one smmbasehob", free allocated 
> buffer when error returning case happen.
> 
> Dun Tan (6):
>   UefiCpuPkg: Create gMpInformationHobGuid2 in UefiCpuPkg
>   UefiCpuPkg: Build MpInfo2HOB in CpuMpPei
>   UefiCpuPkg: Consume MpInfo2Hob in PiSmmCpuDxe
>   UefiCpuPkg: Add a new field in MpInfo2 HOB
>   UefiCpuPkg: Cache core type in MpInfo2 HOB
>   UefiCpuPkg: Avoid assuming only one smmbasehob
> 
>  UefiCpuPkg/CpuMpPei/CpuMpPei.c   | 146 
> ++
>  UefiCpuPkg/CpuMpPei/CpuMpPei.h   |   6 +-
>  UefiCpuPkg/CpuMpPei/CpuMpPei.inf |   3 ++-
>  UefiCpuPkg/Include/Guid/MpInformation2.h |  58 
> ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c   | 354 
> ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h   |   2 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf |   8 
>  UefiCpuPkg/UefiCpuPkg.dec|   3 +++
>  8 files changed, 513 insertions(+), 67 deletions(-)  create mode 
> 100644 UefiCpuPkg/Include/Guid/MpInformation2.h
> 
> --
> 2.31.1.windows.1
> 
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH 0/4] Add DEBUG_MANAGEABILITY to debug level comments

[Rebecca Cran]

On 12/11/2023 6:17 PM, Laszlo Ersek wrote:

On 12/9/23 01:33, Rebecca Cran via groups.io wrote:

On 12/8/2023 5:19 PM, Rebecca Cran wrote:

Add the new DEBUG_MANAGEABILITY debug level to MdePkg.dec and MdePkg.uni.

Improve the wording of the description of the DEBUG_MANAGEABILITY
level in
DebugLib.h.

Update the comment block in ArmVirtPkg.dsc.inc with the new list and
updated
formatting.


PR: https://github.com/tianocore/edk2/pull/5127


... commenting only because I was CC'd:

Please confirm on the list whenever a series is merged; it saves time
for reviewers.

(This problem should disappear once we move reviews to github.com, but
until then, a short confirmation on-list can prevent wasted time.)

For the record: commit range
5b5481526fc9b89e5f3843d9bb3d6c4f5ce41060..aa2f32cefa567133d94d574672a4479e004211ee.


Oh, thanks! I was meaning to do that but forgot between setting the 
'push' label and waiting for CI to complete.



--
Rebecca Cran


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

Re: [edk2-devel] [PATCH 0/4] Add DEBUG_MANAGEABILITY to debug level comments

[Laszlo Ersek]

On 12/9/23 01:33, Rebecca Cran via groups.io wrote:
> On 12/8/2023 5:19 PM, Rebecca Cran wrote:
>> Add the new DEBUG_MANAGEABILITY debug level to MdePkg.dec and MdePkg.uni.
>>
>> Improve the wording of the description of the DEBUG_MANAGEABILITY
>> level in
>> DebugLib.h.
>>
>> Update the comment block in ArmVirtPkg.dsc.inc with the new list and
>> updated
>> formatting.
> 
> PR: https://github.com/tianocore/edk2/pull/5127

... commenting only because I was CC'd:

Please confirm on the list whenever a series is merged; it saves time
for reviewers.

(This problem should disappear once we move reviews to github.com, but
until then, a short confirmation on-list can prevent wasted time.)

For the record: commit range
5b5481526fc9b89e5f3843d9bb3d6c4f5ce41060..aa2f32cefa567133d94d574672a4479e004211ee.

Thanks!
Laszlo



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

回复: [edk2-devel] [PATCH v4 1/1] MdeModulePkg: Support customized FV Migration Information

[gaoliming via groups.io]

Fan:
  Please separate the patch for the different packages. 

Thanks
Liming
> -邮件原件-
> 发件人: devel@edk2.groups.io  代表 Wang Fan
> 发送时间: 2023年12月11日 17:06
> 收件人: devel@edk2.groups.io
> 抄送: Fan Wang ; Michael D Kinney
> ; Liming Gao ;
> Ray Ni ; Guomin Jiang ; Jian J
> Wang 
> 主题: [edk2-devel] [PATCH v4 1/1] MdeModulePkg: Support customized FV
> Migration Information
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4533
> 
> There are use cases which not all FVs need be migrated from TempRam to
> permanent memory before TempRam tears down. This new guid is introduced
> to avoid unnecessary FV migration to improve boot performance. Platform
> can publish MigrationInfo hob with this guid to customize FV migration
> info, and PeiCore will only migrate FVs indicated by this Hob info.
> 
> This is a backwards compatible change, PeiCore will check MigrationInfo
> hob before migration. If MigrationInfo hobs exists, only migrate FVs
> recorded by hobs. If MigrationInfo hobs not exists, migrate all FVs to
> permanent memory.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Ray Ni 
> Cc: Guomin Jiang 
> Cc: Jian J Wang 
> Signed-off-by: Fan Wang 
> ---
>  MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c | 79
> +--
>  MdeModulePkg/Core/Pei/PeiMain.inf |  1 +
>  MdeModulePkg/Include/Guid/MigratedFvInfo.h| 42 +-
>  MdeModulePkg/MdeModulePkg.dec |  3 +-
>  SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c |  7 +-
>  SecurityPkg/Tcg/TcgPei/TcgPei.c   |  7 +-
>  6 files changed, 111 insertions(+), 28 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
> b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
> index 5f32ebb560..0086087e82 100644
> --- a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
> +++ b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
> @@ -1184,7 +1184,12 @@ EvacuateTempRam (
> 
> 
>PEI_CORE_FV_HANDLEPeiCoreFvHandle;
> 
>EFI_PEI_CORE_FV_LOCATION_PPI  *PeiCoreFvLocationPpi;
> 
> +  EFI_PEI_HOB_POINTERS  Hob;
> 
> +  EDKII_MIGRATION_INFO  *MigrationInfo;
> 
> +  TO_MIGRATE_FV_INFO*ToMigrateFvInfo;
> 
> +  UINT32FvMigrationFlags;
> 
>EDKII_MIGRATED_FV_INFOMigratedFvInfo;
> 
> +  UINTN Index;
> 
> 
> 
>ASSERT (Private->PeiMemoryInstalled);
> 
> 
> 
> @@ -1211,6 +1216,13 @@ EvacuateTempRam (
> 
> 
>ConvertPeiCorePpiPointers (Private, &PeiCoreFvHandle);
> 
> 
> 
> +  Hob.Raw = GetFirstGuidHob (&gEdkiiMigrationInfoGuid);
> 
> +  if (Hob.Raw != NULL) {
> 
> +MigrationInfo = GET_GUID_HOB_DATA (Hob);
> 
> +  } else {
> 
> +MigrationInfo = NULL;
> 
> +  }
> 
> +
> 
>for (FvIndex = 0; FvIndex < Private->FvCount; FvIndex++) {
> 
>  FvHeader = Private->Fv[FvIndex].FvHeader;
> 
>  ASSERT (FvHeader != NULL);
> 
> @@ -1224,20 +1236,27 @@ EvacuateTempRam (
>)
> 
>  )
> 
>  {
> 
> -  //
> 
> -  // Allocate page to save the rebased PEIMs, the PEIMs will get
> dispatched later.
> 
> -  //
> 
> -  Status =  PeiServicesAllocatePages (
> 
> -  EfiBootServicesCode,
> 
> -  EFI_SIZE_TO_PAGES ((UINTN)FvHeader->FvLength),
> 
> -  &FvHeaderAddress
> 
> -  );
> 
> -  ASSERT_EFI_ERROR (Status);
> 
> -  MigratedFvHeader = (EFI_FIRMWARE_VOLUME_HEADER
> *)(UINTN)FvHeaderAddress;
> 
> +  if ((MigrationInfo == NULL) || (MigrationInfo->MigrateAll == TRUE))
{
> 
> +// Migrate all FVs and copy raw data
> 
> +FvMigrationFlags = FLAGS_FV_RAW_DATA_COPY;
> 
> +  } else {
> 
> +for (Index = 0; Index < MigrationInfo->ToMigrateFvCount; Index++)
> {
> 
> +  ToMigrateFvInfo = ((TO_MIGRATE_FV_INFO *)(MigrationInfo +
> 1)) + Index;
> 
> +  if (ToMigrateFvInfo->FvOrgBaseOnTempRam ==
> (UINT32)(UINTN)FvHeader) {
> 
> +// This FV is to migrate
> 
> +FvMigrationFlags = ToMigrateFvInfo->FvMigrationFlags;
> 
> +break;
> 
> +  }
> 
> +}
> 
> +
> 
> +if (Index == MigrationInfo->ToMigrateFvCount) {
> 
> +  // This FV is not expected to migrate
> 
> +  continue;
> 
> +}
> 
> +  }
> 
> 
> 
>//
> 
> -  // Allocate pool to save the raw PEIMs, which is used to keep
> consistent context across
> 
> -  // multiple boot and PCR0 will keep the same no matter if the
> address of allocated page is changed.
> 
> +  // Allocate pages to save the rebased PEIMs, the PEIMs will get
> dispatched later.
> 
>//
> 
>Status =  PeiServicesAllocatePages (
> 
>EfiBootServicesCode,
> 
> @@ -1245,7 +1264,8 @@ EvacuateTempRam (
>&FvHeaderAddress
> 
>);
> 
>ASSERT_EFI_ERROR (Status);
> 
> -  RawDataFvHeader = (EFI_FIRMWARE_VOLUME_HEADER
> *)(UINTN)FvHeaderAddress;
> 
> +  MigratedFvHeader = (EFI_FIRMWARE_VOLUME_

Re: [edk2-devel] [PATCH] BaseTools/tools_def: Disable unneeded-internal-declaration warning in CLANGPDB

[Laszlo Ersek]

On 12/11/23 18:26, Mike Beaton wrote:
>>> I believe this would be logically wrong, as the other versions still
>>> wouldn't compile if you changed the relevant debug Pcds. (Which are
>>> logically independent of the compile and link options - e.g. what if for
>>> some reason you wanted to single step with the Debug Pcds set to
>>> disabled, in a NOOPT build?)
>>
>> I don't think that use case exists in practice.
>>
>> Anyway, my suggestion is based on prior art: I *think* we ask gcc to
>> whine about unused local variables in RELEASE builds only, too. See
>> commits 20d00edf21d2 ("BaseTools/GCC: set -Wno-unused-but-set-variables
>> only on RELEASE builds", 2016-03-25) and 8b6366f87584 ("BaseTools/GCC:
>> set -Wno-unused-const-variable on RELEASE builds", 2017-09-08).
>>
>> ... TBH I don't understand the current state of
>> "-Wno-unused-but-set-variables" and "-Wno-unused-const-variable" between
>> X64 and AARCH64, considering the DEBUG target. Today,
>> DEBUG_GCC5_AARCH64_CC_FLAGS disables these warnings, but
>> DEBUG_GCC5_X64_CC_FLAGS doesn't, even though *both* macros specify
>> -flto. Compare commit 06c8a34cc4bc ("BaseTool/tools_def GCC5: enable
>> optimization for ARM/AARCH64 DEBUG builds", 2017-12-08) -- I don't
>> understand why "-flto" had to be accompanied by
>> "-Wno-unused-but-set-variable -Wno-unused-const-variable" in that commit.
>>
>> In brief, IA32 and X64 prior art supports my suggestion to shut up the
>> warning only for RELEASE (for CLANGPDB too), but ARM/AARCH64 prior art
>> contradicts that proposal. IOW, prior art is inconsistent per se... I
>> don't understand.
>>
>> Laszlo
> 
> Hunting around further, it is not the Pcds which are causing this to
> be optimised away, but the definition of MDEPKG_NDEBUG.
> 
> A completely different approach, which allows clang to spot that the
> usage has been 'optimised away' and so to not complain (and therefore
> allows us to re-enable the warning in CLANGDWARF as well), is the
> following:
> 
> --- a/MdePkg/Include/Library/DebugLib.h
> +++ b/MdePkg/Include/Library/DebugLib.h
> @@ -426,7 +426,10 @@ UnitTestDebugAssert (
>}\
>  } while (FALSE)
>  #else
> -#define DEBUG(Expression)
> +#define DEBUG(Expression)\
> +if (FALSE) {   \
> +  _DEBUG (Expression); \
> +}
>  #endif
> 
>  /**
> 

But will this not litter the object files with a bunch of format strings
etc?

It feels like, for CLANGPDB (and maybe CLANGDWARF), the RELEASE target
should not define MDEPKG_NDEBUG, but make sure (instead) that
DebugPrintEnabled() evals to FALSE. If PcdDebugPropertyMask is
fixed-at-build, then DebugPrintEnabled() should be possible to evaluate
at compile time; is that right? (At least for clang?)

Laszlo



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

回复: [edk2-devel] [PATCH 1/1] MdePkg/IndustryStandard: Add _PSD/_CPC/Coord types definitions

[gaoliming via groups.io]

The change is good to me. Reviewed-by: Liming Gao 

Thanks
Liming
> -邮件原件-
> 发件人: devel@edk2.groups.io  代表
> PierreGondois
> 发送时间: 2023年12月6日 17:43
> 收件人: Ni, Ray ; devel@edk2.groups.io
> 抄送: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang ; Sami
> Mujawar ; Leif Lindholm
> 
> 主题: Re: [edk2-devel] [PATCH 1/1] MdePkg/IndustryStandard: Add
> _PSD/_CPC/Coord types definitions
> 
> Hello Ray and the MdePkg maintainers,
> 
> Does this patch looks fine ? When/if this patch is accepted,
> I will send the other patches relying  on this present patch,
> cf. https://edk2.groups.io/g/devel/message/111900
> 
> Regards,
> Pierre
> 
> On 12/1/23 13:26, Pierre Gondois wrote:
> > Hi Ray,
> > I followed the way revisions are defined for ACPI tables revisions,
> > like for the MADT:
> > EFI_ACPI_x_x_MULTIPLE_APIC_DESCRIPTION_TABLE_REVISION definition
> >
> > For each ACPI spec. revision, there is a matching MADT revision number.
> > Sometimes the table has changed and the revision is upgraded, sometimes
> > not and the revision stays the same.
> > This also means having a macro definition for each ACPI spec. header
> > file. I think it should be ok do to the same thing for _PSD/_CPC
> > revisions,
> >
> > Regards,
> > Pierre
> >
> > On 12/1/23 11:22, Ni, Ray wrote:
> >>> --- a/MdePkg/Include/IndustryStandard/Acpi50.h
> >>> +++ b/MdePkg/Include/IndustryStandard/Acpi50.h
> >>
> >>> +#define EFI_ACPI_5_0_AML_PSD_REVISION  0
> >>> +#define EFI_ACPI_5_0_AML_CPC_REVISION  1
> >>
> >>
> >> Do you think it's better to define EFI_ACPI_AML_PSD_REVISION and
> >> EFI_ACPI_AML_CPC_REVISION in Acpi50.h?
> >>
> >> So that Acpi51.h doesn't have to redefine a different macro to
> >> the same value?
> >>
> >>>
> >>> diff --git a/MdePkg/Include/IndustryStandard/Acpi51.h
> >>> b/MdePkg/Include/IndustryStandard/Acpi51.h
> >>> index 01ef544c3a29..19dd7b4f864c 100644
> >>> --- a/MdePkg/Include/IndustryStandard/Acpi51.h
> >>> +++ b/MdePkg/Include/IndustryStandard/Acpi51.h
> >>
> >>> +#define EFI_ACPI_5_1_AML_PSD_REVISION  0
> >>> +#define EFI_ACPI_5_1_AML_CPC_REVISION  1
> 
> 
> 
> 





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

Re: [edk2-devel] [PATCH v2 3/3] UefiCpuPkg/CpuMpPei: Use CpuPageTableLib to set memory attribute.

[Laszlo Ersek]

On 12/1/23 09:42, Ni, Ray wrote:
> Reviewed-by: Ray Ni 

This series seems to have been merged meanwhile -- that's good, because
I could have usefully reviewed only patch#1, and only ACK patches #2 and
#3, due to time constraints.

However... please do report on the list whenever a series is merged! I
started reviewing patch#1, only to find that it was already upstream. I
could have saved that time if I had seen, on the list, a statement of
merging.

So, for the record: commit range
ef3fde64aa78598a4c21556629936fb228390e8c..7e18c9a788e543ab71cdc0485989cf5d00cdccc2.

Thanks
Laszlo



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

[edk2-devel] 回复: [PATCH v1 1/1] BaseTools: Resolve regex syntax warnings

[gaoliming via groups.io]

Joey:
  Does this change still work on old python version, such as Python 3.9? 

Thanks
Liming
> -邮件原件-
> 发件人: Joey Vagedes 
> 发送时间: 2023年12月7日 4:27
> 收件人: devel@edk2.groups.io
> 抄送: Rebecca Cran ; Liming Gao
> ; Bob Feng ; Yuwei Chen
> 
> 主题: [PATCH v1 1/1] BaseTools: Resolve regex syntax warnings
> 
> Switches regex patterns to raw text to resolve python 3.12 syntax
> warnings in regards to invalid escape sequences, as is suggested by the
> re (regex) module in python.
> 
> Cc: Rebecca Cran 
> Cc: Liming Gao 
> Cc: Bob Feng 
> Cc: Yuwei Chen 
> Signed-off-by: Joey Vagedes 
> ---
>  BaseTools/Source/Python/AmlToC/AmlToC.py |  2
> +-
>  BaseTools/Source/Python/AutoGen/BuildEngine.py   |  2
> +-
>  BaseTools/Source/Python/AutoGen/GenDepex.py  |
> 2 +-
>  BaseTools/Source/Python/AutoGen/GenMake.py   |
> 2 +-
>  BaseTools/Source/Python/AutoGen/IdfClassObject.py|  2 +-
>  BaseTools/Source/Python/AutoGen/ModuleAutoGen.py |  4
> ++--
>  BaseTools/Source/Python/AutoGen/StrGather.py |  2
> +-
>  BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py  |  2
> +-
>  BaseTools/Source/Python/Common/Expression.py | 16
> ++---
>  BaseTools/Source/Python/Common/GlobalData.py |
> 4 ++--
>  BaseTools/Source/Python/Common/Misc.py   |
> 24 ++--
>  BaseTools/Source/Python/Common/ToolDefClassObject.py |  6
> ++---
>  BaseTools/Source/Python/GenFds/FdfParser.py  | 10
> 
>  BaseTools/Source/Python/GenFds/GenFds.py |  2
> +-
>  BaseTools/Source/Python/GenPatchPcdTable/GenPatchPcdTable.py | 12
> +-
>  BaseTools/Source/Python/Trim/Trim.py | 18
> +++
>  BaseTools/Source/Python/Workspace/DscBuildData.py|  8
> +++
>  BaseTools/Source/Python/Workspace/MetaFileParser.py  |  2 +-
>  18 files changed, 60 insertions(+), 60 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/AmlToC/AmlToC.py
> b/BaseTools/Source/Python/AmlToC/AmlToC.py
> index 346de7159de7..63931c9720c9 100644
> --- a/BaseTools/Source/Python/AmlToC/AmlToC.py
> +++ b/BaseTools/Source/Python/AmlToC/AmlToC.py
> @@ -17,7 +17,7 @@ from Common.BuildToolError import *
>  import sys
> 
>  import os
> 
> 
> 
> -__description__ = """
> 
> +__description__ = r"""
> 
>  Convert an AML file to a .c file containing the AML bytecode stored in a
C
> 
>  array. By default, Tables\Dsdt.aml will generate Tables\Dsdt.c.
> 
>  Tables\Dsdt.c will contain a C array named "dsdt_aml_code" that contains
> 
> diff --git a/BaseTools/Source/Python/AutoGen/BuildEngine.py
> b/BaseTools/Source/Python/AutoGen/BuildEngine.py
> index 752a1a1f6a86..45b39d7878d5 100644
> --- a/BaseTools/Source/Python/AutoGen/BuildEngine.py
> +++ b/BaseTools/Source/Python/AutoGen/BuildEngine.py
> @@ -306,7 +306,7 @@ class BuildRule:
>  _SubSectionList = [_InputFile, _OutputFile, _Command]
> 
> 
> 
>  _PATH_SEP = "(+)"
> 
> -_FileTypePattern = re.compile("^[_a-zA-Z][_\-0-9a-zA-Z]*$")
> 
> +_FileTypePattern = re.compile(r"^[_a-zA-Z][_\-0-9a-zA-Z]*$")
> 
>  _BinaryFileRule = FileBuildRule(TAB_DEFAULT_BINARY_FILE, [],
> [os.path.join("$(OUTPUT_DIR)", "${s_name}")],
> 
>  ["$(CP) ${src} ${dst}"], [])
> 
> 
> 
> diff --git a/BaseTools/Source/Python/AutoGen/GenDepex.py
> b/BaseTools/Source/Python/AutoGen/GenDepex.py
> index f2f2e9d65b5f..b6db6645a4fb 100644
> --- a/BaseTools/Source/Python/AutoGen/GenDepex.py
> +++ b/BaseTools/Source/Python/AutoGen/GenDepex.py
> @@ -126,7 +126,7 @@ class DependencyExpression:
>  #
> 
>  # open and close brace must be taken as individual tokens
> 
>  #
> 
> -TokenPattern = re.compile("(\(|\)|\{[^{}]+\{?[^{}]+\}?[ ]*\}|\w+)")
> 
> +TokenPattern = re.compile(r"(\(|\)|\{[^{}]+\{?[^{}]+\}?[ ]*\}|\w+)")
> 
> 
> 
>  ## Constructor
> 
>  #
> 
> diff --git a/BaseTools/Source/Python/AutoGen/GenMake.py
> b/BaseTools/Source/Python/AutoGen/GenMake.py
> index daec9c6d54b2..c416fe172fe5 100755
> --- a/BaseTools/Source/Python/AutoGen/GenMake.py
> +++ b/BaseTools/Source/Python/AutoGen/GenMake.py
> @@ -28,7 +28,7 @@ from Common.DataType import TAB_COMPILER_MSFT
>  gIncludePattern =
> re.compile(r"^[ \t]*[#%]?[ \t]*include(?:[ \t]*(?:\\(?:\r\n|\r|\n))*[
\t]*)*(?:\(
> ?[\"<]?[ \t]*)([-\w.\\/() \t]+)(?:[ \t]*[\">]?\)?)", re.MULTILINE |
re.UNICODE |
> re.IGNORECASE)
> 
> 
> 
>  ## Regular expression for matching macro used in header file inclusion
> 
> -gMacroPattern = re.compile("([_A-Z][_A-Z0-9]*)[ \t]*\((.+)\)",
re.UNICODE)
> 
> +gMacroPattern = re.compile(r"([_A-Z][_A-Z0-9]*)[ \t]*\((.+)\)",
re.UNICODE)
> 
> 
> 
>  gIsFileMap = {}
> 
> 
> 
> diff --git a/BaseTools/Source/Python/AutoGen/IdfClassObject.py
> b/BaseTools/Source/Python/AutoGen/IdfClassObject.py
> index a6b8123c2539..bb413c6a26e3 100644
> --- a/BaseTools/Source/Python

Re: [edk2-devel] [Patch V2] UefiCpuPkg/PiSmmCpuDxeSmm: SmmCpuRendezvous ensure all Aps in Present.

[Laszlo Ersek]

On 12/6/23 04:35, Wu, Jiaxin wrote:
>> (1) Here's why I don't like this:
>>
>> we already have a function that is supposed to do this, and it is
>> SmmWaitForApArrival().
>>
>> SmmWaitForApArrival() is called in two contexts. One, in BSPHandler().
>> Two, here.
>>
>> Consider the following condition:
>>
>>   (SyncMode == SmmCpuSyncModeTradition) ||
>>   SmmCpuFeaturesNeedConfigureMtrrs ()
>>
>> If this condition evaluates to true, then BSPHandler() calls
>> SmmWaitForApArrival(), and SmmCpuRendezvous() doesn't.
>>
>> (This is what the "else" branch in SmmCpuRendezvous() states, in a
>> comment, too.)
>>
>> And if the condition evaluates to false, then SmmCpuRendezvous() calls
>> SmmWaitForApArrival(), and BSPHandler() doesn't.
>>
>> This patch adds extra waiting logic to *one* of both call sites. And I
>> don't understand why the *other* call site (in BSPHandler()) does not
>> need the exact same logic.
>>
>> In my opinion, this is a sign that SmmWaitForApArrival() isn't "strong
>> enough". It is not doing all of the work.
>>
>> In my opinion, *both* call sites should receive this logic (i.e., ensure
>> that all AP's are "present"), but then in turn, the additional waiting /
>> checking should be pushed down into SmmWaitForApArrival().
>>
>> What's your opinion on that?
> 
> 
> Existing SmmWaitForApArrival() only make sure all Aps enter SMI except SMI 
> blocked & disabled Aps, not consider the "Present" state. I think this is the 
> original implementation purpose. It won't require all Aps must set the 
> Present flag.
> 
> As you also commented there is a later loop for the Present flag:
>   WaitForAllAPs (ApCount)
> 
> Here, i still prefer to keep existing way instead of making 
> SmmWaitForApArrival return until all aps set the Present flag, because that 
> will be duplicate work within SmmWaitForApArrival() & existing  WaitForAllAPs 
> (). We can't delete the WaitForAllAPs for the later sync to make sure all APs 
> to get ready for programming MTRRs. MTRRs programming need all CPUs in the 
> same start line. 
> 
>   WaitForAllAPs() has two purpose:
>1. Make sure all Aps have set the Present.
>2. Get ready for programming MTRRs to make sure cpus in the same start 
> line.
> 
> if so, that will be better as existing logic, it can also save some time for 
> the Present flag check in SmmWaitForApArrival

OK, this argument makes sense to me.

I didn't realize that WaitForAllAPs() -- called by BSPHandler() after
calling SmmWaitForApArrival() -- already *effectively* ensured that the
APs had their Present flag set!

That happens because:

(a) WaitForAllAPs() pends the "Run" semaphore of each AP.

(b) The APHandler() function sets the Present flag *first*.

(c) If

  (SyncMode == SmmCpuSyncModeTradition) ||
  SmmCpuFeaturesNeedConfigureMtrrs ()

is true, then APHandler() posts the "Run" semaphore, *second*.

Therefore, once WaitForAllAPs() has acquired all AP "Run" semaphores,
all AP Present flags must be set.

This is not obvious at all, but it looks correct.

Therefore I agree that your patch does not introduce asymmetry between
SmmCpuRendezvous() and BSPHandler(). Instead, your patch eliminates
asymmetry, because now SmmCpuRendezvous() will wait for the Present
flags of the APs (if the above-quoted condition is false), similarly to
how BSPHandler already does (if the condition is true).


Now, I have not had the time yet to re-review your patch set

  [PATCH v3 0/6] Refine SMM CPU Sync flow and abstract SmmCpuSyncLib

As far as I remember (from v1), that patch set reorganizes exactly these
"Run" semaphore release/acquire patterns.

(3) Can you confirm that your v3 patch set will not invalidate this
discussion? I.e., can you confirm that WaitForAllAPs() will *still*
ensure, via the Run semaphores, that the Present flags will have been set?

(4) Please add the following to the commit message:

---
BSPHandler -> { SmmWaitForApArrival, WaitForAllAPs } already awaits that
the Present flag is set for all APs, namely via the AP Run semaphores.
Therefore this patch ensures symmetry between BSPHandler (when [1] is
true) and SmmCpuRendezvous() (when [1] is false).

[1] (SyncMode == SmmCpuSyncModeTradition) ||
SmmCpuFeaturesNeedConfigureMtrrs ()
---

More comments below:

> 
>>
>> (2) I notice that a similar "busy loop", waiting for Present flags, is
>> in BSPHandler().
>>
>> Do you think we could call CpuPause() in all such "busy loops" (just
>> before the end of the "while" body)? I think that's supposed to improve
>> the system's throughput, considered as a whole. The function's comment
>> says,
>>
>>   Requests CPU to pause for a short period of time. Typically used in MP
>>   systems to prevent memory starvation while waiting for a spin lock.
>>
> 
> Do you mean the below WaitForAllAPs()? There is already has the CpuPause 
> check within WaitForSemaphore().
> 
> //
> // Wait for all APs to get ready for programming MTRRs
> //
> WaitForAllAPs (ApCount);

Yes, that's the

[edk2-devel] 回复: [PATCH v3] MdePkg: Add a new memory type definition

[gaoliming via groups.io]

Reviewed-by: Liming Gao 

> -邮件原件-
> 发件人: ManickamX Srinivasan 
> 发送时间: 2023年12月8日 13:37
> 收件人: devel@edk2.groups.io
> 抄送: ManickamX Srinivasan ; Michael D
> Kinney ; Liming Gao
> ; Zhiguang Liu ; T V
> Krishnamoorthy 
> 主题: [PATCH v3] MdePkg: Add a new memory type definition
> 
> New memory type as defined in UEFI standard v2.10
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: T V Krishnamoorthy 
> Signed-off-by: ManickamX Srinivasan 
> ---
>  MdePkg/Include/Uefi/UefiSpec.h | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/MdePkg/Include/Uefi/UefiSpec.h
> b/MdePkg/Include/Uefi/UefiSpec.h
> index 7dfe35b499..d583ee17d0 100644
> --- a/MdePkg/Include/Uefi/UefiSpec.h
> +++ b/MdePkg/Include/Uefi/UefiSpec.h
> @@ -110,6 +110,21 @@ typedef enum {
>  //
>  #define EFI_MEMORY_RUNTIME  0x8000ULL
> 
> +//
> +// If this flag is set, the memory region is
> +// described with additional ISA-specific memory attributes
> +// as specified in EFI_MEMORY_ISA_MASK.
> +//
> +#define EFI_MEMORY_ISA_VALID 0x4000ULL
> +
> +//
> +// Defines the bits reserved for describing optional ISA-specific
cacheability
> +// attributes that are not covered by the standard UEFI Memory Attributes
> cacheability
> +// bits (EFI_MEMORY_UC, EFI_MEMORY_WC, EFI_MEMORY_WT,
> EFI_MEMORY_WB and EFI_MEMORY_UCE).
> +// See Calling Conventions for further ISA-specific enumeration of these
bits.
> +//
> +#define EFI_MEMORY_ISA_MASK 0x0000ULL
> +
>  //
>  // Attributes bitmasks, grouped by type
>  //
> --
> 2.30.2.windows.1





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

回复: [edk2-devel] [PATCH] MdePkg: Define the DevicePath argument from LoadImage as optional

[gaoliming via groups.io]

Reviewed-by: Liming Gao 

> -邮件原件-
> 发件人: devel@edk2.groups.io  代表 ManickamX
> Srinivasan
> 发送时间: 2023年12月8日 15:29
> 收件人: devel@edk2.groups.io
> 抄送: ManickamX Srinivasan ; Zhiguang
> Liu ; Michael D Kinney
> ; Liming Gao ; T
> V Krishnamoorthy 
> 主题: [edk2-devel] [PATCH] MdePkg: Define the DevicePath argument from
> LoadImage as optional
> 
> Define the DevicePath argument from LoadImage as optional as per
> the UEFI 2.9A specification.
> 
> Reviewed-by: Zhiguang Liu 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: T V Krishnamoorthy 
> Signed-off-by: ManickamX Srinivasan 
> ---
>  MdePkg/Include/Uefi/UefiSpec.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdePkg/Include/Uefi/UefiSpec.h
> b/MdePkg/Include/Uefi/UefiSpec.h
> index 7dfe35b499..e83e14d347 100644
> --- a/MdePkg/Include/Uefi/UefiSpec.h
> +++ b/MdePkg/Include/Uefi/UefiSpec.h
> @@ -898,7 +898,7 @@ EFI_STATUS
>  (EFIAPI *EFI_IMAGE_LOAD)(
>IN  BOOLEAN  BootPolicy,
>IN  EFI_HANDLE   ParentImageHandle,
> -  IN  EFI_DEVICE_PATH_PROTOCOL *DevicePath,
> +  IN  EFI_DEVICE_PATH_PROTOCOL *DevicePath   OPTIONAL,
>IN  VOID *SourceBuffer OPTIONAL,
>IN  UINTNSourceSize,
>OUT EFI_HANDLE   *ImageHandle
> --
> 2.30.2.windows.1
> 
> 
> 
> 
> 





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112343): https://edk2.groups.io/g/devel/message/112343
Mute This Topic: https://groups.io/mt/103121251/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] RedfishPkg/RedfishDicovery: Remedy Redfish service discovery flow

[Chang, Abner via groups.io]

[AMD Official Use Only - General]

Here is the PR https://github.com/tianocore/edk2/pull/5139 with Igor's RB for 
the V1.

Hi Igor, please check it again as I had moved the code around.

Thanks
Abner

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Chang,
> Abner via groups.io
> Sent: Monday, December 11, 2023 10:59 PM
> To: devel@edk2.groups.io
> Cc: Nickle Wang ; Igor Kulchytskyy ;
> Mike Maslenkin 
> Subject: [edk2-devel] [PATCH V2] RedfishPkg/RedfishDicovery: Remedy
> Redfish service discovery flow
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> From: Abner Chang 
>
> Remedy Redfish service discovery flow changes made
> in commit 8736b8fd.
>
> The above fix creates the dependency with SMBIOS 42h record,
> which has a problem as SMBIOS 42h may not be created when
> RedfishDiscovery.Supported() is invoked even all of the
> required protocols are ready on the ControllerHandle. We can’t
> guarantee SMBIOS 42 structure will be always created before
> ConnectController(). USB NIC maybe detected late and it means
> PlatformHostInterfaceBmcUsbNicLib can populate SMBIOS 42h
> information late as well. Calling to
> RedfishServiceGetNetworkInterface with the previous fix may
> result in no network interface for BMC-exposed NIC as SMBIOS
> 42h is not ready yet.This is the first issue.
>
> Second, to skip the network interface when
> NetworkInterfaceGetSubnetInfo() returns a failure also has
> problem, as the NIC may be configured via RestEx->Configure().
> This happens after the Host interface is discovered, as at this
> moment we have the sufficient network information to configure
> BMC-exposed NIC.
>
> Base on Redfish spec in 31.1.5.2, “EFI Redfish Client may provide
> selection UI of network interfaces for Redfish service discovery.",
> This means edk2 Redfish client gets all network interfaces
> through RedfishServiceGetNetworkInterface and choose the desired
> network interface at its discretion for Redfish service.
>
> So the fix here is:
> 1. In BuildNetworkInterface(), we don’t skip any network
>interface. In RedfishServiceGetNetworkInterface, we don’t
>skip any network interface even the subnet information is not
>retrieved. We will still return all of network interfaces to
>client.
> 2. In RedfishServiceAcquireService for
>EFI_REDFISH_RISCOVER_HOST_INTERFACE case, we don’t skip any
>network interface even the subnet information is not
>retrieved.
>
> 3. Added some more debug information.
>
> Note: The subnet information is used for the scenario the system
> is managed by a centralized Redfish service (not on BMC), says
> the multiple Redfish computer system instances. As it mentions
> in 31.1.5.2, Redfish client they may have to know the subnet
> information so they can know the network domain the NIC is
> connected. There may have multiple subnets in the corporation
> network environment. So the subnet information provides client
> an idea when they choose the network interface, so does VLAN ID.
>
> Change-Id: Ibb38ddcd17459ad4b23fcb4fcd8a771a0f63987a
> Signed-off-by: Abner Chang 
> Cc: Nickle Wang 
> Cc: Igor Kulchytskyy 
> Cc: Mike Maslenkin 
> ---
>  .../RedfishDiscoverDxe/RedfishDiscoverDxe.c   | 109 +++---
>  1 file changed, 39 insertions(+), 70 deletions(-)
>
> diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
> b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
> index 833ae2b969f..06d8d00da7f 100644
> --- a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
> +++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
> @@ -487,43 +487,6 @@ CheckIsIpVersion6 (
>return FALSE;
>  }
>
> -/**
> -  This function returns the  IP type supported by the Host Interface.
> -
> -  @retval 00h is Unknown
> -  01h is Ipv4
> -  02h is Ipv6
> -
> -**/
> -STATIC
> -UINT8
> -GetHiIpProtocolType (
> -  VOID
> -  )
> -{
> -  EFI_STATUS Status;
> -  REDFISH_OVER_IP_PROTOCOL_DATA  *Data;
> -  REDFISH_INTERFACE_DATA *DeviceDescriptor;
> -
> -  Data = NULL;
> -  DeviceDescriptor = NULL;
> -  if (mSmbios == NULL) {
> -Status = gBS->LocateProtocol (&gEfiSmbiosProtocolGuid, NULL, (VOID
> **)&mSmbios);
> -if (EFI_ERROR (Status)) {
> -  return
> REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_UNKNOWN;
> -}
> -  }
> -
> -  Status = RedfishGetHostInterfaceProtocolData (mSmbios,
> &DeviceDescriptor, &Data); // Search for SMBIOS type 42h
> -  if (!EFI_ERROR (Status) && (Data != NULL) &&
> -  (Data->HostIpAssignmentType == RedfishHostIpAssignmentStatic))
> -  {
> -return Data->HostIpAddressFormat;
> -  }
> -
> -  return
> REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_UNKNOWN;
> -}
> -
>  /**
>Check if Network Protocol Type matches with SMBIOS Type 42 IP Address
> Type.
>
> @@ -583,7 +546,10 @@ DiscoverRedfishHostInterface (
>}
>
>Status = RedfishGetHostInterfacePr

Re: [edk2-devel] [PATCH v2 1/1] OvmfPkg/VirtNorFlashDxe: sanity-check variables

[Laszlo Ersek]

On 12/7/23 10:44, Gerd Hoffmann wrote:
> Extend the ValidateFvHeader function, additionally to the header checks
> walk over the list of variables and sanity check them.
> 
> In case we find inconsistencies indicating variable store corruption
> return EFI_NOT_FOUND so the variable store will be re-initialized.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c | 82 +--
>  1 file changed, 77 insertions(+), 5 deletions(-)
> 
> diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c 
> b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
> index 5ee98e9b595a..1bfb14495abd 100644
> --- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
> +++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
> @@ -185,11 +185,16 @@ ValidateFvHeader (
>IN  NOR_FLASH_INSTANCE  *Instance
>)
>  {
> -  UINT16  Checksum;
> -  EFI_FIRMWARE_VOLUME_HEADER  *FwVolHeader;
> -  VARIABLE_STORE_HEADER   *VariableStoreHeader;
> -  UINTN   VariableStoreLength;
> -  UINTN   FvLength;
> +  UINT16 Checksum;
> +  EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader;
> +  VARIABLE_STORE_HEADER  *VariableStoreHeader;
> +  UINTN  VarOffset;
> +  AUTHENTICATED_VARIABLE_HEADER  *VarHeader;
> +  UINTN  VarSize;
> +  CHAR16 *VarName;
> +  CHAR8  *VarState;
> +  UINTN  VariableStoreLength;
> +  UINTN  FvLength;
>  
>FwVolHeader = (EFI_FIRMWARE_VOLUME_HEADER *)Instance->RegionBaseAddress;
>  
> @@ -260,6 +265,73 @@ ValidateFvHeader (
>  return EFI_NOT_FOUND;
>}
>  
> +  // check variables

(1) Comment style -- should be preceded and succeeded by otherwise empty // 
lines

> +  DEBUG ((DEBUG_INFO, "%a: checking variables\n", __func__));
> +  VarOffset = sizeof (*VariableStoreHeader);
> +  while (VarOffset + sizeof (*VarHeader) < VariableStoreHeader->Size) {

(2) The addition is not checked for overflow. When it is evaluated for the 
first time, it cannot overflow, but I can't easily find a proof that it cannot 
overflow in further iterations on 32-bit platforms.

(The strict "<" relop in itself seems justified; we always expect *some* data 
after the variable header.)

I suggest rewriting as follows:

  for (;;) {
RETURN_STATUS  Status;
UINTN  VarHeaderEnd;

Status = SafeUintnAdd (VarOffset, sizeof (*VarHeader), &VarHeaderEnd);
if (RETURN_ERROR (Status)) {
  return EFI_NOT_FOUND;
}
if (VarHeaderEnd >= VariableStoreHeader->Size) {
  break;
}

Perhaps even the second check should return EFI_NOT_FOUND, assuming we require 
(StartId != 0x55aa) as the only successful termination condition.

> +VarHeader = (VOID *)((UINTN)VariableStoreHeader + VarOffset);
> +if (VarHeader->StartId != 0x55aa) {
> +  DEBUG ((DEBUG_INFO, "%a: end of var list\n", __func__));
> +  break;
> +}
> +
> +VarSize = sizeof (*VarHeader) + VarHeader->NameSize + 
> VarHeader->DataSize;

(3) Given that we expect that the varstore may be corrupt, this addition can 
definitely overflow on 32-bit platforms (where the additions are performed in 
UINT32). I suggest using SafeUintnAdd() from SafeIntLib again.

> +if (VarOffset + VarSize > VariableStoreHeader->Size) {

(4) This addition should be checked for overflow too.

Alternatively -- given that, from previous checks, here we know for sure that 
VarOffset is strictly smaller than VariableStoreHeader->Size --, the expression 
can be rearranged as follows (by subtracting VarOffset from both sides):

if (VarSize > VariableStoreHeader->Size - VarOffset) {

Mathematically this means the same thing, but the subtraction on the right hand 
side cannot underflow.

> +  DEBUG ((
> +DEBUG_ERROR,
> +"%a: invalid variable size: 0x%x + 0x%x + 0x%x + 0x%x > 0x%x\n",
> +__func__,
> +VarOffset,

(5) VarOffset is of type UINTN, which may be UINT32 or UINT64. %x is not a 
proper format specifier for printing UINT64.

PrintLib offers no format specifier for UINTN, only for UINT32 (%x, %u) and 
UINT64 (%lx / %Lx, %lu / %Lu).

Therefore, the best way to format a UINTN value is:

- convert it to UINT64 explicitly,
- print it with one of the format specifiers matching UINT64.

For example,

  DEBUG ((DEBUG_ERROR, "%Lx\n", (UINT64)VarOffset));

> +sizeof (*VarHeader),

(6) same issue, sizeof evals to a UINTN.

> +VarHeader->NameSize,
> +VarHeader->DataSize,
> +VariableStoreHeader->Size

these are good (all three are UINT32)

> +));
> +  return EFI_NOT_FOUND;
> +}
> +
> +VarName = (VOID *)((UINTN)VariableStoreHeader + VarOffset
> +   + sizeof (*VarHeader));

(7) This seems premature. We should first check that NameSize is (a) nonzero 
and (b) divisible by 2.

> +switch (VarHeader->State) {
> +  case VAR_HE

[edk2-devel] [PATCH v2 4/4] [WIP] UefiPayloadPkg: Support SMRAMC register

[Benjamin Doron]

From: Benjamin Doron 

Former Intel platforms controlled SMRAM protection using a dedicated
register.

SlimBootloader-supported platforms have converged on the SMRR, but for
coreboot to support prior platforms too, lock-down is advised.

Requires testing.

TODO: It is more correct to install a handler in SMM to set SPI to
write-protected again, though it's at least assumed secure at present:
as the SMI will not be acknowledged, platform will re-enter SMM.

Cc: Guo Dong 
Cc: Ray Ni 
Cc: Sean Rhodes 
Cc: James Lu 
Cc: Gua Guo 
Signed-off-by: Benjamin Doron 
---
 UefiPayloadPkg/BlSupportSmm/BlSupportSmm.c|  29 ++
 UefiPayloadPkg/BlSupportSmm/BlSupportSmm.inf  |   1 +
 UefiPayloadPkg/Include/Guid/SmmRegisterInfoGuid.h |   1 +
 UefiPayloadPkg/SmmAccessDxe/SmmAccessDxe.c| 103 +++-
 UefiPayloadPkg/SmmAccessDxe/SmmAccessDxe.h|   1 +
 UefiPayloadPkg/SmmAccessDxe/SmmAccessDxe.inf  |   2 +
 6 files changed, 136 insertions(+), 1 deletion(-)

diff --git a/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.c 
b/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.c
index 0d16aec8ef70..48e7ff9ad044 100644
--- a/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.c
+++ b/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.c
@@ -6,6 +6,8 @@
   writting 0xB2 port with given value from SMM communication area.
   The paylaod SMM handler got chance to restore regs in S3 path.
 
+  Global TODO: Install SMI handler to handle SPI write-protect.
+
   Copyright (c) 2021, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -13,9 +15,14 @@
 
 #include 
 
+#define B_SA_SMRAMC_D_LCK_MASK (0x10)
+#define B_SA_SMRAMC_D_CLS_MASK (0x20)
+#define B_SA_SMRAMC_D_OPEN_MASK(0x40)
+
 PLD_S3_COMMUNICATIONmPldS3Hob;
 EFI_SMRAM_HOB_DESCRIPTOR_BLOCK  *mSmramHob = NULL;
 PLD_SMM_REGISTERS   *mSmmRegisterHob   = NULL;
+UINT32  mSmramcAddress = 0x;
 UINT64  mSmmFeatureControl = 0;
 
 /**
@@ -185,6 +192,20 @@ SmmFeatureLockOnS3 (
   mSmmFeatureControl = AsmReadMsr64 (MSR_SMM_FEATURE_CONTROL);
 }
 
+/**
+  Set SMRAMC, if supported, on S3 path.
+
+**/
+VOID
+SetSmramcOnS3 (
+  VOID
+  )
+{
+  if (mSmramcAddress != 0x) {
+PciOr8 (mSmramcAddress, B_SA_SMRAMC_D_LCK_MASK);
+  }
+}
+
 /**
   Function to program SMRR base and mask.
 
@@ -299,6 +320,7 @@ BlSwSmiHandler (
   )
 {
   SetSmrrOnS3 ();
+  SetSmramcOnS3 ();
   SmmFeatureLockOnS3 ();
   LockSmiGlobalEn ();
 
@@ -353,6 +375,7 @@ BlSupportSmm (
   EFI_HANDLE SwHandle;
   EFI_HOB_GUID_TYPE  *GuidHob;
   VOID   *SmmHob;
+  PLD_GENERIC_REGISTER   *SmramcReg;
   VOID   *Registration;
 
   //
@@ -399,6 +422,12 @@ BlSupportSmm (
 }
 
 CopyMem (mSmmRegisterHob, SmmHob, GET_GUID_HOB_DATA_SIZE (GuidHob));
+
+SmramcReg = GetRegisterById (REGISTER_ID_SMRAMC);
+if (SmramcReg != NULL) {
+  DEBUG ((DEBUG_INFO, "SMRAMC reg found.\n"));
+  mSmramcAddress = SmramcReg->Address.Address;
+}
   } else {
 return EFI_NOT_FOUND;
   }
diff --git a/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.inf 
b/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.inf
index 75d4777971fc..a92a971f7c49 100644
--- a/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.inf
+++ b/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.inf
@@ -33,6 +33,7 @@
   MemoryAllocationLib
   BaseLib
   IoLib
+  PciLib
   HobLib
 
 [Guids]
diff --git a/UefiPayloadPkg/Include/Guid/SmmRegisterInfoGuid.h 
b/UefiPayloadPkg/Include/Guid/SmmRegisterInfoGuid.h
index 665eaa7e7729..feeb984b9f9b 100644
--- a/UefiPayloadPkg/Include/Guid/SmmRegisterInfoGuid.h
+++ b/UefiPayloadPkg/Include/Guid/SmmRegisterInfoGuid.h
@@ -27,6 +27,7 @@ typedef EFI_ACPI_3_0_GENERIC_ADDRESS_STRUCTURE 
PLD_GENERIC_ADDRESS;
 #define REGISTER_ID_SMI_EOS  3
 #define REGISTER_ID_SMI_APM_EN   4
 #define REGISTER_ID_SMI_APM_STS  5
+#define REGISTER_ID_SMRAMC   6
 
 #pragma pack(1)
 typedef struct {
diff --git a/UefiPayloadPkg/SmmAccessDxe/SmmAccessDxe.c 
b/UefiPayloadPkg/SmmAccessDxe/SmmAccessDxe.c
index acb07192f714..919a47bdde7e 100644
--- a/UefiPayloadPkg/SmmAccessDxe/SmmAccessDxe.c
+++ b/UefiPayloadPkg/SmmAccessDxe/SmmAccessDxe.c
@@ -7,8 +7,14 @@
 **/
 
 #include "SmmAccessDxe.h"
+#include 
+
+#define B_SA_SMRAMC_D_LCK_MASK (0x10)
+#define B_SA_SMRAMC_D_CLS_MASK (0x20)
+#define B_SA_SMRAMC_D_OPEN_MASK(0x40)
 
 SMM_ACCESS_PRIVATE_DATA  mSmmAccess;
+UINT32  mSmramcAddress = 0x;
 
 /**
Update region state from SMRAM description
@@ -53,6 +59,8 @@ Open (
   IN EFI_SMM_ACCESS2_PROTOCOL  *This
   )
 {
+  UINT8  SmramControl;
+
   if ((mSmmAccess.SmmRegionState & EFI_SMRAM_LOCKED) != 0) {
 //
 // Cannot open a "locked" region
@@ -61,13 +69,33 @@ Open (
 return EFI_DEVICE_ERROR;
   }
 
+  //
+  // Chipset code
+  //
+  if (mSmramcAddress != 0x) {
+SmramControl = PciRead8 (mSmramcAddress);
+
+// C

[edk2-devel] [PATCH v2 3/4] [WIP] UefiPayloadPkg/CbParseLib: Initial coreboot support for SMM payload

[Benjamin Doron]

From: Benjamin Doron 

To be used with the https://review.coreboot.org/c/coreboot/+/70378
patch-series. Now feature complete, awaiting final upstream feedback
whether generating some data inside coreboot is okay.

Cc: Guo Dong 
Cc: Ray Ni 
Cc: Sean Rhodes 
Cc: James Lu 
Cc: Gua Guo 
Signed-off-by: Benjamin Doron 
---
 UefiPayloadPkg/Include/Coreboot.h|  50 
 UefiPayloadPkg/Library/CbParseLib/CbParseLib.c   | 121 +++-
 UefiPayloadPkg/Library/CbParseLib/CbParseLib.inf |   9 ++
 3 files changed, 179 insertions(+), 1 deletion(-)

diff --git a/UefiPayloadPkg/Include/Coreboot.h 
b/UefiPayloadPkg/Include/Coreboot.h
index 6c33dda9ef85..add64d9623d9 100644
--- a/UefiPayloadPkg/Include/Coreboot.h
+++ b/UefiPayloadPkg/Include/Coreboot.h
@@ -270,6 +270,56 @@ struct fmap {
   struct fmap_area areas[];
 } __attribute__ ((packed));
 
+#define CB_TAG_PLD_SMM_REGISTER_INFO  0x0050
+struct lb_pld_generic_register {
+  UINT8  register_id;
+  UINT8  address_space_id;
+  UINT8  register_bit_width;
+  UINT8  register_bit_offset;
+  UINT32 value;
+  struct cbuint64 address;
+};
+
+struct lb_pld_smm_registers {
+  UINT32 tag;
+  UINT32 size;
+  UINT32 revision;
+  UINT32 count;
+  struct lb_pld_generic_register registers[];
+};
+
+#define CB_TAG_PLD_SMM_SMRAM  0x0051
+struct lb_pld_smram_descriptor {
+  struct cbuint64 physical_start;
+  struct cbuint64 physical_size;
+  struct cbuint64 region_state;
+};
+
+struct lb_pld_smram_descriptor_block {
+  UINT32 tag;
+  UINT32 size;
+  UINT32 number_of_smm_regions;
+  struct lb_pld_smram_descriptor descriptor[1];
+};
+
+#define CB_TAG_PLD_SPI_FLASH_INFO 0x0052
+struct lb_pld_spi_flash_info {
+  UINT32 tag;
+  UINT32 size;
+  UINT16 revision;
+  UINT16 flags;
+  struct lb_pld_generic_register spi_address;
+};
+
+#define CB_TAG_PLD_S3_COMMUNICATION   0x0054
+struct lb_pld_s3_communication {
+  UINT32 tag;
+  UINT32 size;
+  struct lb_pld_smram_descriptor comm_buffer;
+  UINT8  pld_acpi_s3_enable;
+  UINT8  pad[3];
+};
+
 /* Helpful macros */
 
 #define MEM_RANGE_COUNT(_rec) \
diff --git a/UefiPayloadPkg/Library/CbParseLib/CbParseLib.c 
b/UefiPayloadPkg/Library/CbParseLib/CbParseLib.c
index 8a353f77f635..46b164231fe5 100644
--- a/UefiPayloadPkg/Library/CbParseLib/CbParseLib.c
+++ b/UefiPayloadPkg/Library/CbParseLib/CbParseLib.c
@@ -7,15 +7,22 @@
 
 **/
 
-#include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 /**
   Convert a packed value from cbuint64 to a UINT64 value.
@@ -602,5 +609,117 @@ ParseMiscInfo (
   VOID
   )
 {
+  struct lb_pld_smm_registers   *BlSmmRegisters;
+  PLD_SMM_REGISTERS *PldSmmRegisters;
+  UINTN Index;
+  struct lb_pld_smram_descriptor_block  *BlSmramInfo;
+  EFI_SMRAM_HOB_DESCRIPTOR_BLOCK*PldSmramHob;
+  struct lb_pld_spi_flash_info  *BlSpiFlashInfo;
+  SPI_FLASH_INFO*PldSpiFlashInfo;
+  EFI_PHYSICAL_ADDRESS  SmmStoreFmapRegionAddress;
+  UINT32SmmStoreFmapRegionSize;
+  EFI_STATUSStatus;
+  NV_VARIABLE_INFO  *PldNvVariableInfo;
+  struct lb_pld_s3_communication*BlS3Communication;
+  PLD_S3_COMMUNICATION  *PldS3Communication;
+
+  BlSmmRegisters = FindCbTag (CB_TAG_PLD_SMM_REGISTER_INFO);
+  if (BlSmmRegisters != NULL) {
+PldSmmRegisters = BuildGuidHob (
+&gSmmRegisterInfoGuid,
+sizeof (PLD_SMM_REGISTERS) + (BlSmmRegisters->count * 
sizeof (PLD_GENERIC_REGISTER))
+);
+if (PldSmmRegisters != NULL) {
+  PldSmmRegisters->Revision = BlSmmRegisters->revision;
+
+  PldSmmRegisters->Count = BlSmmRegisters->count;
+  for (Index = 0; Index < BlSmmRegisters->count; Index++) {
+PldSmmRegisters->Registers[Index].Id = 
BlSmmRegisters->registers[Index].register_id;
+PldSmmRegisters->Registers[Index].Address.AddressSpaceId = 
BlSmmRegisters->registers[Index].address_space_id;
+PldSmmRegisters->Registers[Index].Address.RegisterBitWidth = 
BlSmmRegisters->registers[Index].register_bit_width;
+PldSmmRegisters->Registers[Index].Address.RegisterBitOffset = 
BlSmmRegisters->registers[Index].register_bit_offset;
+PldSmmRegisters->Registers[Index].Value = 
BlSmmRegisters->registers[Index].value;
+PldSmmRegisters->Registers[Index].Address.Address = cb_unpack64 
(BlSmmRegisters->registers[Index].address);
+
+// Required for UefiPayload implementation compatibility
+PldSmmRegisters->Registers[Index].Address.AccessSize = 
EFI_ACPI_3_0_DWORD;
+  }
+
+  DEBUG ((DEBUG_INFO, "Create SMM register info guid hob\n"));
+}
+  }
+
+  BlSmramInfo = FindCbTag (CB_TAG_PLD_SMM_SMRAM);
+  if (BlSmramInfo != NULL) {
+PldSmramHob = BuildGui

[edk2-devel] [PATCH v2 2/4] UefiPayloadPkg: Introduce coreboot FMAP parser library

[Benjamin Doron]

From: Benjamin Doron 

Parse coreboot FMAP structures to find the memory region in SPI flash
by the FMAP area name.

Cc: Guo Dong 
Cc: Ray Ni 
Cc: Sean Rhodes 
Cc: James Lu 
Cc: Gua Guo 
Signed-off-by: Benjamin Doron 
---
 UefiPayloadPkg/Include/Coreboot.h  |  21 
 UefiPayloadPkg/Include/Library/FmapParserLib.h |  35 +++
 UefiPayloadPkg/Library/CbFmapParserLib/CbFmapParserLib.c   | 104 

 UefiPayloadPkg/Library/CbFmapParserLib/CbFmapParserLib.inf |  28 ++
 UefiPayloadPkg/UefiPayloadPkg.dsc  |   1 +
 5 files changed, 189 insertions(+)

diff --git a/UefiPayloadPkg/Include/Coreboot.h 
b/UefiPayloadPkg/Include/Coreboot.h
index 2d454f7c893c..6c33dda9ef85 100644
--- a/UefiPayloadPkg/Include/Coreboot.h
+++ b/UefiPayloadPkg/Include/Coreboot.h
@@ -249,6 +249,27 @@ struct cb_cbmem_tab {
   UINT64cbmem_tab;
 };
 
+#define CB_TAG_FMAP  0x0037
+#define FMAP_STRLEN  32  /* includes null-terminator */
+struct fmap_area {
+  UINT32 offset;/* offset relative to base */
+  UINT32 size;  /* size in bytes */
+  UINT8  name[FMAP_STRLEN]; /* descriptive name */
+  UINT16 flags; /* flags for this area */
+} __attribute__ ((packed));
+
+struct fmap {
+  UINT8  signature[8];   /* "__FMAP__" (0x5F5F464D41505F5F) */
+  UINT8  ver_major;  /* major version */
+  UINT8  ver_minor;  /* minor version */
+  UINT64 base;   /* address of the firmware binary */
+  UINT32 size;   /* size of firmware binary in bytes */
+  UINT8  name[FMAP_STRLEN];  /* name of this firmware binary */
+  UINT16 nareas; /* number of areas described by
+fmap_areas[] below */
+  struct fmap_area areas[];
+} __attribute__ ((packed));
+
 /* Helpful macros */
 
 #define MEM_RANGE_COUNT(_rec) \
diff --git a/UefiPayloadPkg/Include/Library/FmapParserLib.h 
b/UefiPayloadPkg/Include/Library/FmapParserLib.h
new file mode 100644
index ..f03b9b22a85b
--- /dev/null
+++ b/UefiPayloadPkg/Include/Library/FmapParserLib.h
@@ -0,0 +1,35 @@
+/** @file
+  Contains helper functions for parsing FMAP.
+
+  Copyright (c) 2023, 9elements GmbH.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+#include 
+
+#define FMAP_SIGNATURE  "__FMAP__"
+#define FMAP_VER_MAJOR  1
+#define FMAP_VER_MINOR  1
+
+/**
+  Find a requested FMAP area's address and size.
+
+  @param[in]   FmapAreaName Name string of FMAP area to find
+  @param[out]  FmapAreaAddress  Pointer to return of FMAP area memory address
+  @param[out]  FmapAreaSize Pointer to return of FMAP area size
+
+  @retval EFI_SUCCESSSuccessfully found the FMAP area information.
+  @retval EFI_INVALID_PARAMETER  Input arguments are invalid.
+  @retval EFI_NOT_FOUND  Failed to find the FMAP area information.
+
+**/
+EFI_STATUS
+EFIAPI
+FmapLocateArea (
+  IN CHAR8 *FmapAreaName,
+  IN OUT EFI_PHYSICAL_ADDRESS  *FmapAreaAddress,
+  IN OUT UINT32*FmapAreaSize
+  );
diff --git a/UefiPayloadPkg/Library/CbFmapParserLib/CbFmapParserLib.c 
b/UefiPayloadPkg/Library/CbFmapParserLib/CbFmapParserLib.c
new file mode 100644
index ..1a181b7266f0
--- /dev/null
+++ b/UefiPayloadPkg/Library/CbFmapParserLib/CbFmapParserLib.c
@@ -0,0 +1,104 @@
+/** @file
+  Contains helper functions for parsing FMAP.
+
+  Copyright (c) 2023, 9elements GmbH.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+  Find coreboot record with given Tag.
+  NOTE: This coreboot-specific function definition is absent
+from the common BlParseLib header.
+
+  @param  TagThe tag id to be found
+
+  @retval NULL  The Tag is not found.
+  @retval OthersThe pointer to the record found.
+
+**/
+VOID *
+FindCbTag (
+  IN  UINT32  Tag
+  );
+
+/**
+  Find a requested FMAP area's address and size.
+
+  @param[in]   FmapAreaName Name string of FMAP area to find
+  @param[out]  FmapAreaAddress  Pointer to return of FMAP area memory address
+  @param[out]  FmapAreaSize Pointer to return of FMAP area size
+
+  @retval EFI_SUCCESSSuccessfully found the FMAP area information.
+  @retval EFI_INVALID_PARAMETER  Input arguments are invalid.
+  @retval EFI_NOT_FOUND  Failed to find the FMAP area information.
+
+**/
+EFI_STATUS
+EFIAPI
+FmapLocateArea (
+  IN CHAR8 *FmapAreaName,
+  IN OUT EFI_PHYSICAL_ADDRESS  *FmapAreaAddress,
+  IN OUT UINT32*FmapAreaSize
+  )
+{
+  struct cb_cbmem_ref  *CbMemRef;
+  struct fmap  *Fmap;
+  UINTNIndex;
+
+  //
+  // Perform basic validation
+  //
+  if ((FmapAreaName == NULL) || (FmapAreaAddress == NULL) || (FmapAreaSize == 
NULL)) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  // FMAP_STRLEN includes sizeof NULL

[edk2-devel] [PATCH v2 1/4] UefiPayloadPkg/SblParseLib: Build SMM feature GUID HOBs from bootloader

[Benjamin Doron]

From: Benjamin Doron 

UefiPayload does not install all SBL HOBs, EDK2-relevant ones must be
installed individually. This was omitted from the SMM feature pushes.

Cc: Guo Dong 
Cc: Ray Ni 
Cc: Sean Rhodes 
Cc: James Lu 
Cc: Gua Guo 
Signed-off-by: Benjamin Doron 
---
 UefiPayloadPkg/Library/SblParseLib/SblParseLib.c   | 77 
 UefiPayloadPkg/Library/SblParseLib/SblParseLib.inf |  5 ++
 2 files changed, 82 insertions(+)

diff --git a/UefiPayloadPkg/Library/SblParseLib/SblParseLib.c 
b/UefiPayloadPkg/Library/SblParseLib/SblParseLib.c
index d88238bfdccb..9775ad4ac2a6 100644
--- a/UefiPayloadPkg/Library/SblParseLib/SblParseLib.c
+++ b/UefiPayloadPkg/Library/SblParseLib/SblParseLib.c
@@ -15,6 +15,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
 
 /**
@@ -264,6 +269,17 @@ ParseMiscInfo (
   RETURN_STATUS   Status;
   UNIVERSAL_PAYLOAD_PCI_ROOT_BRIDGES  *BlRootBridgesHob;
   UNIVERSAL_PAYLOAD_PCI_ROOT_BRIDGES  *PldRootBridgesHob;
+  // TODO: Drop half by ignoring return?
+  PLD_SMM_REGISTERS   *BlSmmRegisters;
+  PLD_SMM_REGISTERS   *PldSmmRegisters;
+  EFI_SMRAM_HOB_DESCRIPTOR_BLOCK  *BlSmramHob;
+  EFI_SMRAM_HOB_DESCRIPTOR_BLOCK  *PldSmramHob;
+  SPI_FLASH_INFO  *BlSpiFlashInfo;
+  SPI_FLASH_INFO  *PldSpiFlashInfo;
+  NV_VARIABLE_INFO*BlNvVariableInfo;
+  NV_VARIABLE_INFO*PldNvVariableInfo;
+  PLD_S3_COMMUNICATION*BlS3Communication;
+  PLD_S3_COMMUNICATION*PldS3Communication;
 
   Status   = RETURN_NOT_FOUND;
   BlRootBridgesHob = (UNIVERSAL_PAYLOAD_PCI_ROOT_BRIDGES 
*)GetGuidHobDataFromSbl (
@@ -287,5 +303,66 @@ ParseMiscInfo (
 }
   }
 
+  // Perhaps payload does not perform SMM, do not override Status
+  BlSmmRegisters = GetGuidHobDataFromSbl (&gSmmRegisterInfoGuid);
+  if (BlSmmRegisters != NULL) {
+PldSmmRegisters = BuildGuidDataHob (
+&gSmmRegisterInfoGuid,
+BlSmmRegisters,
+sizeof (PLD_SMM_REGISTERS) + (BlSmmRegisters->Count * 
sizeof (PLD_GENERIC_REGISTER))
+);
+if (PldSmmRegisters != NULL) {
+  DEBUG ((DEBUG_INFO, "Create SMM register info guid hob\n"));
+}
+  }
+
+  BlSmramHob = GetGuidHobDataFromSbl (&gEfiSmmSmramMemoryGuid);
+  if (BlSmramHob != NULL) {
+PldSmramHob = BuildGuidDataHob (
+&gEfiSmmSmramMemoryGuid,
+BlSmramHob,
+sizeof (EFI_SMRAM_HOB_DESCRIPTOR_BLOCK) + 
((BlSmramHob->number_of_smm_regions - 1) * sizeof (EFI_SMRAM_DESCRIPTOR))
+);
+if (PldSmramHob != NULL) {
+  DEBUG ((DEBUG_INFO, "Create SMM SMRAM memory info guid hob\n"));
+}
+  }
+
+  BlSpiFlashInfo = GetGuidHobDataFromSbl (&gSpiFlashInfoGuid);
+  if (BlSpiFlashInfo != NULL) {
+PldSpiFlashInfo = BuildGuidDataHob (
+&gSpiFlashInfoGuid,
+BlSpiFlashInfo,
+sizeof (SPI_FLASH_INFO)
+);
+if (PldSpiFlashInfo != NULL) {
+  DEBUG ((DEBUG_INFO, "Create SPI flash info guid hob\n"));
+}
+  }
+
+  BlNvVariableInfo = GetGuidHobDataFromSbl (&gNvVariableInfoGuid);
+  if (BlNvVariableInfo != NULL) {
+PldNvVariableInfo = BuildGuidDataHob (
+  &gNvVariableInfoGuid,
+  BlNvVariableInfo,
+  sizeof (NV_VARIABLE_INFO)
+  );
+if (PldNvVariableInfo != NULL) {
+  DEBUG ((DEBUG_INFO, "Create NV variable info guid hob\n"));
+}
+  }
+
+  BlS3Communication = GetGuidHobDataFromSbl (&gS3CommunicationGuid);
+  if (BlS3Communication != NULL) {
+PldS3Communication = BuildGuidDataHob (
+   &gS3CommunicationGuid,
+   BlS3Communication,
+   sizeof (PLD_S3_COMMUNICATION)
+   );
+if (PldS3Communication != NULL) {
+  DEBUG ((DEBUG_INFO, "Create S3 communication guid hob\n"));
+}
+  }
+
   return Status;
 }
diff --git a/UefiPayloadPkg/Library/SblParseLib/SblParseLib.inf 
b/UefiPayloadPkg/Library/SblParseLib/SblParseLib.inf
index f83a10ccd826..1c77d86a8643 100644
--- a/UefiPayloadPkg/Library/SblParseLib/SblParseLib.inf
+++ b/UefiPayloadPkg/Library/SblParseLib/SblParseLib.inf
@@ -41,6 +41,11 @@
   gEfiGraphicsInfoHobGuid
   gEfiGraphicsDeviceInfoHobGuid
   gUniversalPayloadPciRootBridgeInfoGuid
+  gSmmRegisterInfoGuid
+  gEfiSmmSmramMemoryGuid
+  gSpiFlashInfoGuid
+  gNvVariableInfoGuid
+  gS3CommunicationGuid
 
 [Pcd]
   gUefiPayloadPkgTokenSpaceGuid.PcdBootloaderParameter
-- 
2.43.0



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

[edk2-devel] [PATCH v1 4/4] [WIP] UefiPayloadPkg: Support SMRAMC register

[Benjamin Doron]

From: Benjamin Doron 

Former Intel platforms controlled SMRAM protection using a dedicated
register.

SlimBootloader-supported platforms have converged on the SMRR, but for
coreboot to support prior platforms too, lock-down is advised.

Requires testing.

TODO: It is more correct to install a handler in SMM to set SPI to
write-protected again, though it's at least assumed secure at present:
as the SMI will not be acknowledged, platform will re-enter SMM.

Cc: Guo Dong 
Cc: Ray Ni 
Cc: Sean Rhodes 
Cc: James Lu 
Cc: Gua Guo 
Signed-off-by: Benjamin Doron 
---
 UefiPayloadPkg/BlSupportSmm/BlSupportSmm.c|  29 ++
 UefiPayloadPkg/BlSupportSmm/BlSupportSmm.inf  |   1 +
 UefiPayloadPkg/Include/Guid/SmmRegisterInfoGuid.h |   1 +
 UefiPayloadPkg/SmmAccessDxe/SmmAccessDxe.c| 103 +++-
 UefiPayloadPkg/SmmAccessDxe/SmmAccessDxe.h|   1 +
 UefiPayloadPkg/SmmAccessDxe/SmmAccessDxe.inf  |   2 +
 6 files changed, 136 insertions(+), 1 deletion(-)

diff --git a/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.c 
b/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.c
index 0d16aec8ef70..48e7ff9ad044 100644
--- a/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.c
+++ b/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.c
@@ -6,6 +6,8 @@
   writting 0xB2 port with given value from SMM communication area.
   The paylaod SMM handler got chance to restore regs in S3 path.
 
+  Global TODO: Install SMI handler to handle SPI write-protect.
+
   Copyright (c) 2021, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -13,9 +15,14 @@
 
 #include 
 
+#define B_SA_SMRAMC_D_LCK_MASK (0x10)
+#define B_SA_SMRAMC_D_CLS_MASK (0x20)
+#define B_SA_SMRAMC_D_OPEN_MASK(0x40)
+
 PLD_S3_COMMUNICATIONmPldS3Hob;
 EFI_SMRAM_HOB_DESCRIPTOR_BLOCK  *mSmramHob = NULL;
 PLD_SMM_REGISTERS   *mSmmRegisterHob   = NULL;
+UINT32  mSmramcAddress = 0x;
 UINT64  mSmmFeatureControl = 0;
 
 /**
@@ -185,6 +192,20 @@ SmmFeatureLockOnS3 (
   mSmmFeatureControl = AsmReadMsr64 (MSR_SMM_FEATURE_CONTROL);
 }
 
+/**
+  Set SMRAMC, if supported, on S3 path.
+
+**/
+VOID
+SetSmramcOnS3 (
+  VOID
+  )
+{
+  if (mSmramcAddress != 0x) {
+PciOr8 (mSmramcAddress, B_SA_SMRAMC_D_LCK_MASK);
+  }
+}
+
 /**
   Function to program SMRR base and mask.
 
@@ -299,6 +320,7 @@ BlSwSmiHandler (
   )
 {
   SetSmrrOnS3 ();
+  SetSmramcOnS3 ();
   SmmFeatureLockOnS3 ();
   LockSmiGlobalEn ();
 
@@ -353,6 +375,7 @@ BlSupportSmm (
   EFI_HANDLE SwHandle;
   EFI_HOB_GUID_TYPE  *GuidHob;
   VOID   *SmmHob;
+  PLD_GENERIC_REGISTER   *SmramcReg;
   VOID   *Registration;
 
   //
@@ -399,6 +422,12 @@ BlSupportSmm (
 }
 
 CopyMem (mSmmRegisterHob, SmmHob, GET_GUID_HOB_DATA_SIZE (GuidHob));
+
+SmramcReg = GetRegisterById (REGISTER_ID_SMRAMC);
+if (SmramcReg != NULL) {
+  DEBUG ((DEBUG_INFO, "SMRAMC reg found.\n"));
+  mSmramcAddress = SmramcReg->Address.Address;
+}
   } else {
 return EFI_NOT_FOUND;
   }
diff --git a/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.inf 
b/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.inf
index 75d4777971fc..a92a971f7c49 100644
--- a/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.inf
+++ b/UefiPayloadPkg/BlSupportSmm/BlSupportSmm.inf
@@ -33,6 +33,7 @@
   MemoryAllocationLib
   BaseLib
   IoLib
+  PciLib
   HobLib
 
 [Guids]
diff --git a/UefiPayloadPkg/Include/Guid/SmmRegisterInfoGuid.h 
b/UefiPayloadPkg/Include/Guid/SmmRegisterInfoGuid.h
index 665eaa7e7729..feeb984b9f9b 100644
--- a/UefiPayloadPkg/Include/Guid/SmmRegisterInfoGuid.h
+++ b/UefiPayloadPkg/Include/Guid/SmmRegisterInfoGuid.h
@@ -27,6 +27,7 @@ typedef EFI_ACPI_3_0_GENERIC_ADDRESS_STRUCTURE 
PLD_GENERIC_ADDRESS;
 #define REGISTER_ID_SMI_EOS  3
 #define REGISTER_ID_SMI_APM_EN   4
 #define REGISTER_ID_SMI_APM_STS  5
+#define REGISTER_ID_SMRAMC   6
 
 #pragma pack(1)
 typedef struct {
diff --git a/UefiPayloadPkg/SmmAccessDxe/SmmAccessDxe.c 
b/UefiPayloadPkg/SmmAccessDxe/SmmAccessDxe.c
index acb07192f714..919a47bdde7e 100644
--- a/UefiPayloadPkg/SmmAccessDxe/SmmAccessDxe.c
+++ b/UefiPayloadPkg/SmmAccessDxe/SmmAccessDxe.c
@@ -7,8 +7,14 @@
 **/
 
 #include "SmmAccessDxe.h"
+#include 
+
+#define B_SA_SMRAMC_D_LCK_MASK (0x10)
+#define B_SA_SMRAMC_D_CLS_MASK (0x20)
+#define B_SA_SMRAMC_D_OPEN_MASK(0x40)
 
 SMM_ACCESS_PRIVATE_DATA  mSmmAccess;
+UINT32  mSmramcAddress = 0x;
 
 /**
Update region state from SMRAM description
@@ -53,6 +59,8 @@ Open (
   IN EFI_SMM_ACCESS2_PROTOCOL  *This
   )
 {
+  UINT8  SmramControl;
+
   if ((mSmmAccess.SmmRegionState & EFI_SMRAM_LOCKED) != 0) {
 //
 // Cannot open a "locked" region
@@ -61,13 +69,33 @@ Open (
 return EFI_DEVICE_ERROR;
   }
 
+  //
+  // Chipset code
+  //
+  if (mSmramcAddress != 0x) {
+SmramControl = PciRead8 (mSmramcAddress);
+
+// C

[edk2-devel] [PATCH v1 3/4] [WIP] UefiPayloadPkg/CbParseLib: Initial coreboot support for SMM payload

[Benjamin Doron]

From: Benjamin Doron 

To be used with the https://review.coreboot.org/c/coreboot/+/70378
patch-series. Now feature complete, awaiting final upstream feedback
whether generating some data inside coreboot is okay.

Cc: Guo Dong 
Cc: Ray Ni 
Cc: Sean Rhodes 
Cc: James Lu 
Cc: Gua Guo 
Signed-off-by: Benjamin Doron 
---
 UefiPayloadPkg/Include/Coreboot.h|  50 
 UefiPayloadPkg/Library/CbParseLib/CbParseLib.c   | 121 +++-
 UefiPayloadPkg/Library/CbParseLib/CbParseLib.inf |   9 ++
 3 files changed, 179 insertions(+), 1 deletion(-)

diff --git a/UefiPayloadPkg/Include/Coreboot.h 
b/UefiPayloadPkg/Include/Coreboot.h
index 6c33dda9ef85..add64d9623d9 100644
--- a/UefiPayloadPkg/Include/Coreboot.h
+++ b/UefiPayloadPkg/Include/Coreboot.h
@@ -270,6 +270,56 @@ struct fmap {
   struct fmap_area areas[];
 } __attribute__ ((packed));
 
+#define CB_TAG_PLD_SMM_REGISTER_INFO  0x0050
+struct lb_pld_generic_register {
+  UINT8  register_id;
+  UINT8  address_space_id;
+  UINT8  register_bit_width;
+  UINT8  register_bit_offset;
+  UINT32 value;
+  struct cbuint64 address;
+};
+
+struct lb_pld_smm_registers {
+  UINT32 tag;
+  UINT32 size;
+  UINT32 revision;
+  UINT32 count;
+  struct lb_pld_generic_register registers[];
+};
+
+#define CB_TAG_PLD_SMM_SMRAM  0x0051
+struct lb_pld_smram_descriptor {
+  struct cbuint64 physical_start;
+  struct cbuint64 physical_size;
+  struct cbuint64 region_state;
+};
+
+struct lb_pld_smram_descriptor_block {
+  UINT32 tag;
+  UINT32 size;
+  UINT32 number_of_smm_regions;
+  struct lb_pld_smram_descriptor descriptor[1];
+};
+
+#define CB_TAG_PLD_SPI_FLASH_INFO 0x0052
+struct lb_pld_spi_flash_info {
+  UINT32 tag;
+  UINT32 size;
+  UINT16 revision;
+  UINT16 flags;
+  struct lb_pld_generic_register spi_address;
+};
+
+#define CB_TAG_PLD_S3_COMMUNICATION   0x0054
+struct lb_pld_s3_communication {
+  UINT32 tag;
+  UINT32 size;
+  struct lb_pld_smram_descriptor comm_buffer;
+  UINT8  pld_acpi_s3_enable;
+  UINT8  pad[3];
+};
+
 /* Helpful macros */
 
 #define MEM_RANGE_COUNT(_rec) \
diff --git a/UefiPayloadPkg/Library/CbParseLib/CbParseLib.c 
b/UefiPayloadPkg/Library/CbParseLib/CbParseLib.c
index 8a353f77f635..46b164231fe5 100644
--- a/UefiPayloadPkg/Library/CbParseLib/CbParseLib.c
+++ b/UefiPayloadPkg/Library/CbParseLib/CbParseLib.c
@@ -7,15 +7,22 @@
 
 **/
 
-#include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 /**
   Convert a packed value from cbuint64 to a UINT64 value.
@@ -602,5 +609,117 @@ ParseMiscInfo (
   VOID
   )
 {
+  struct lb_pld_smm_registers   *BlSmmRegisters;
+  PLD_SMM_REGISTERS *PldSmmRegisters;
+  UINTN Index;
+  struct lb_pld_smram_descriptor_block  *BlSmramInfo;
+  EFI_SMRAM_HOB_DESCRIPTOR_BLOCK*PldSmramHob;
+  struct lb_pld_spi_flash_info  *BlSpiFlashInfo;
+  SPI_FLASH_INFO*PldSpiFlashInfo;
+  EFI_PHYSICAL_ADDRESS  SmmStoreFmapRegionAddress;
+  UINT32SmmStoreFmapRegionSize;
+  EFI_STATUSStatus;
+  NV_VARIABLE_INFO  *PldNvVariableInfo;
+  struct lb_pld_s3_communication*BlS3Communication;
+  PLD_S3_COMMUNICATION  *PldS3Communication;
+
+  BlSmmRegisters = FindCbTag (CB_TAG_PLD_SMM_REGISTER_INFO);
+  if (BlSmmRegisters != NULL) {
+PldSmmRegisters = BuildGuidHob (
+&gSmmRegisterInfoGuid,
+sizeof (PLD_SMM_REGISTERS) + (BlSmmRegisters->count * 
sizeof (PLD_GENERIC_REGISTER))
+);
+if (PldSmmRegisters != NULL) {
+  PldSmmRegisters->Revision = BlSmmRegisters->revision;
+
+  PldSmmRegisters->Count = BlSmmRegisters->count;
+  for (Index = 0; Index < BlSmmRegisters->count; Index++) {
+PldSmmRegisters->Registers[Index].Id = 
BlSmmRegisters->registers[Index].register_id;
+PldSmmRegisters->Registers[Index].Address.AddressSpaceId = 
BlSmmRegisters->registers[Index].address_space_id;
+PldSmmRegisters->Registers[Index].Address.RegisterBitWidth = 
BlSmmRegisters->registers[Index].register_bit_width;
+PldSmmRegisters->Registers[Index].Address.RegisterBitOffset = 
BlSmmRegisters->registers[Index].register_bit_offset;
+PldSmmRegisters->Registers[Index].Value = 
BlSmmRegisters->registers[Index].value;
+PldSmmRegisters->Registers[Index].Address.Address = cb_unpack64 
(BlSmmRegisters->registers[Index].address);
+
+// Required for UefiPayload implementation compatibility
+PldSmmRegisters->Registers[Index].Address.AccessSize = 
EFI_ACPI_3_0_DWORD;
+  }
+
+  DEBUG ((DEBUG_INFO, "Create SMM register info guid hob\n"));
+}
+  }
+
+  BlSmramInfo = FindCbTag (CB_TAG_PLD_SMM_SMRAM);
+  if (BlSmramInfo != NULL) {
+PldSmramHob = BuildGui

[edk2-devel] [PATCH v1 2/4] UefiPayloadPkg: Introduce coreboot FMAP parser library

[Benjamin Doron]

From: Benjamin Doron 

Parse coreboot FMAP structures to find the memory region in SPI flash
by the FMAP area name.

Cc: Guo Dong 
Cc: Ray Ni 
Cc: Sean Rhodes 
Cc: James Lu 
Cc: Gua Guo 
Signed-off-by: Benjamin Doron 
---
 UefiPayloadPkg/Include/Coreboot.h  |  21 
 UefiPayloadPkg/Include/Library/FmapParserLib.h |  35 +++
 UefiPayloadPkg/Library/CbFmapParserLib/CbFmapParserLib.c   | 104 

 UefiPayloadPkg/Library/CbFmapParserLib/CbFmapParserLib.inf |  28 ++
 UefiPayloadPkg/UefiPayloadPkg.dsc  |   1 +
 5 files changed, 189 insertions(+)

diff --git a/UefiPayloadPkg/Include/Coreboot.h 
b/UefiPayloadPkg/Include/Coreboot.h
index 2d454f7c893c..6c33dda9ef85 100644
--- a/UefiPayloadPkg/Include/Coreboot.h
+++ b/UefiPayloadPkg/Include/Coreboot.h
@@ -249,6 +249,27 @@ struct cb_cbmem_tab {
   UINT64cbmem_tab;
 };
 
+#define CB_TAG_FMAP  0x0037
+#define FMAP_STRLEN  32  /* includes null-terminator */
+struct fmap_area {
+  UINT32 offset;/* offset relative to base */
+  UINT32 size;  /* size in bytes */
+  UINT8  name[FMAP_STRLEN]; /* descriptive name */
+  UINT16 flags; /* flags for this area */
+} __attribute__ ((packed));
+
+struct fmap {
+  UINT8  signature[8];   /* "__FMAP__" (0x5F5F464D41505F5F) */
+  UINT8  ver_major;  /* major version */
+  UINT8  ver_minor;  /* minor version */
+  UINT64 base;   /* address of the firmware binary */
+  UINT32 size;   /* size of firmware binary in bytes */
+  UINT8  name[FMAP_STRLEN];  /* name of this firmware binary */
+  UINT16 nareas; /* number of areas described by
+fmap_areas[] below */
+  struct fmap_area areas[];
+} __attribute__ ((packed));
+
 /* Helpful macros */
 
 #define MEM_RANGE_COUNT(_rec) \
diff --git a/UefiPayloadPkg/Include/Library/FmapParserLib.h 
b/UefiPayloadPkg/Include/Library/FmapParserLib.h
new file mode 100644
index ..f03b9b22a85b
--- /dev/null
+++ b/UefiPayloadPkg/Include/Library/FmapParserLib.h
@@ -0,0 +1,35 @@
+/** @file
+  Contains helper functions for parsing FMAP.
+
+  Copyright (c) 2023, 9elements GmbH.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+#include 
+
+#define FMAP_SIGNATURE  "__FMAP__"
+#define FMAP_VER_MAJOR  1
+#define FMAP_VER_MINOR  1
+
+/**
+  Find a requested FMAP area's address and size.
+
+  @param[in]   FmapAreaName Name string of FMAP area to find
+  @param[out]  FmapAreaAddress  Pointer to return of FMAP area memory address
+  @param[out]  FmapAreaSize Pointer to return of FMAP area size
+
+  @retval EFI_SUCCESSSuccessfully found the FMAP area information.
+  @retval EFI_INVALID_PARAMETER  Input arguments are invalid.
+  @retval EFI_NOT_FOUND  Failed to find the FMAP area information.
+
+**/
+EFI_STATUS
+EFIAPI
+FmapLocateArea (
+  IN CHAR8 *FmapAreaName,
+  IN OUT EFI_PHYSICAL_ADDRESS  *FmapAreaAddress,
+  IN OUT UINT32*FmapAreaSize
+  );
diff --git a/UefiPayloadPkg/Library/CbFmapParserLib/CbFmapParserLib.c 
b/UefiPayloadPkg/Library/CbFmapParserLib/CbFmapParserLib.c
new file mode 100644
index ..1a181b7266f0
--- /dev/null
+++ b/UefiPayloadPkg/Library/CbFmapParserLib/CbFmapParserLib.c
@@ -0,0 +1,104 @@
+/** @file
+  Contains helper functions for parsing FMAP.
+
+  Copyright (c) 2023, 9elements GmbH.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+  Find coreboot record with given Tag.
+  NOTE: This coreboot-specific function definition is absent
+from the common BlParseLib header.
+
+  @param  TagThe tag id to be found
+
+  @retval NULL  The Tag is not found.
+  @retval OthersThe pointer to the record found.
+
+**/
+VOID *
+FindCbTag (
+  IN  UINT32  Tag
+  );
+
+/**
+  Find a requested FMAP area's address and size.
+
+  @param[in]   FmapAreaName Name string of FMAP area to find
+  @param[out]  FmapAreaAddress  Pointer to return of FMAP area memory address
+  @param[out]  FmapAreaSize Pointer to return of FMAP area size
+
+  @retval EFI_SUCCESSSuccessfully found the FMAP area information.
+  @retval EFI_INVALID_PARAMETER  Input arguments are invalid.
+  @retval EFI_NOT_FOUND  Failed to find the FMAP area information.
+
+**/
+EFI_STATUS
+EFIAPI
+FmapLocateArea (
+  IN CHAR8 *FmapAreaName,
+  IN OUT EFI_PHYSICAL_ADDRESS  *FmapAreaAddress,
+  IN OUT UINT32*FmapAreaSize
+  )
+{
+  struct cb_cbmem_ref  *CbMemRef;
+  struct fmap  *Fmap;
+  UINTNIndex;
+
+  //
+  // Perform basic validation
+  //
+  if ((FmapAreaName == NULL) || (FmapAreaAddress == NULL) || (FmapAreaSize == 
NULL)) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  // FMAP_STRLEN includes sizeof NULL

[edk2-devel] [PATCH v1 1/4] UefiPayloadPkg/SblParseLib: Build SMM feature GUID HOBs from bootloader

[Benjamin Doron]

From: Benjamin Doron 

UefiPayload does not install all SBL HOBs, EDK2-relevant ones must be
installed individually. This was omitted from the SMM feature pushes.

Cc: Guo Dong 
Cc: Ray Ni 
Cc: Sean Rhodes 
Cc: James Lu 
Cc: Gua Guo 
Signed-off-by: Benjamin Doron 
---
 UefiPayloadPkg/Library/SblParseLib/SblParseLib.c   | 77 
 UefiPayloadPkg/Library/SblParseLib/SblParseLib.inf |  5 ++
 2 files changed, 82 insertions(+)

diff --git a/UefiPayloadPkg/Library/SblParseLib/SblParseLib.c 
b/UefiPayloadPkg/Library/SblParseLib/SblParseLib.c
index d88238bfdccb..9775ad4ac2a6 100644
--- a/UefiPayloadPkg/Library/SblParseLib/SblParseLib.c
+++ b/UefiPayloadPkg/Library/SblParseLib/SblParseLib.c
@@ -15,6 +15,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
 
 /**
@@ -264,6 +269,17 @@ ParseMiscInfo (
   RETURN_STATUS   Status;
   UNIVERSAL_PAYLOAD_PCI_ROOT_BRIDGES  *BlRootBridgesHob;
   UNIVERSAL_PAYLOAD_PCI_ROOT_BRIDGES  *PldRootBridgesHob;
+  // TODO: Drop half by ignoring return?
+  PLD_SMM_REGISTERS   *BlSmmRegisters;
+  PLD_SMM_REGISTERS   *PldSmmRegisters;
+  EFI_SMRAM_HOB_DESCRIPTOR_BLOCK  *BlSmramHob;
+  EFI_SMRAM_HOB_DESCRIPTOR_BLOCK  *PldSmramHob;
+  SPI_FLASH_INFO  *BlSpiFlashInfo;
+  SPI_FLASH_INFO  *PldSpiFlashInfo;
+  NV_VARIABLE_INFO*BlNvVariableInfo;
+  NV_VARIABLE_INFO*PldNvVariableInfo;
+  PLD_S3_COMMUNICATION*BlS3Communication;
+  PLD_S3_COMMUNICATION*PldS3Communication;
 
   Status   = RETURN_NOT_FOUND;
   BlRootBridgesHob = (UNIVERSAL_PAYLOAD_PCI_ROOT_BRIDGES 
*)GetGuidHobDataFromSbl (
@@ -287,5 +303,66 @@ ParseMiscInfo (
 }
   }
 
+  // Perhaps payload does not perform SMM, do not override Status
+  BlSmmRegisters = GetGuidHobDataFromSbl (&gSmmRegisterInfoGuid);
+  if (BlSmmRegisters != NULL) {
+PldSmmRegisters = BuildGuidDataHob (
+&gSmmRegisterInfoGuid,
+BlSmmRegisters,
+sizeof (PLD_SMM_REGISTERS) + (BlSmmRegisters->Count * 
sizeof (PLD_GENERIC_REGISTER))
+);
+if (PldSmmRegisters != NULL) {
+  DEBUG ((DEBUG_INFO, "Create SMM register info guid hob\n"));
+}
+  }
+
+  BlSmramHob = GetGuidHobDataFromSbl (&gEfiSmmSmramMemoryGuid);
+  if (BlSmramHob != NULL) {
+PldSmramHob = BuildGuidDataHob (
+&gEfiSmmSmramMemoryGuid,
+BlSmramHob,
+sizeof (EFI_SMRAM_HOB_DESCRIPTOR_BLOCK) + 
((BlSmramHob->number_of_smm_regions - 1) * sizeof (EFI_SMRAM_DESCRIPTOR))
+);
+if (PldSmramHob != NULL) {
+  DEBUG ((DEBUG_INFO, "Create SMM SMRAM memory info guid hob\n"));
+}
+  }
+
+  BlSpiFlashInfo = GetGuidHobDataFromSbl (&gSpiFlashInfoGuid);
+  if (BlSpiFlashInfo != NULL) {
+PldSpiFlashInfo = BuildGuidDataHob (
+&gSpiFlashInfoGuid,
+BlSpiFlashInfo,
+sizeof (SPI_FLASH_INFO)
+);
+if (PldSpiFlashInfo != NULL) {
+  DEBUG ((DEBUG_INFO, "Create SPI flash info guid hob\n"));
+}
+  }
+
+  BlNvVariableInfo = GetGuidHobDataFromSbl (&gNvVariableInfoGuid);
+  if (BlNvVariableInfo != NULL) {
+PldNvVariableInfo = BuildGuidDataHob (
+  &gNvVariableInfoGuid,
+  BlNvVariableInfo,
+  sizeof (NV_VARIABLE_INFO)
+  );
+if (PldNvVariableInfo != NULL) {
+  DEBUG ((DEBUG_INFO, "Create NV variable info guid hob\n"));
+}
+  }
+
+  BlS3Communication = GetGuidHobDataFromSbl (&gS3CommunicationGuid);
+  if (BlS3Communication != NULL) {
+PldS3Communication = BuildGuidDataHob (
+   &gS3CommunicationGuid,
+   BlS3Communication,
+   sizeof (PLD_S3_COMMUNICATION)
+   );
+if (PldS3Communication != NULL) {
+  DEBUG ((DEBUG_INFO, "Create S3 communication guid hob\n"));
+}
+  }
+
   return Status;
 }
diff --git a/UefiPayloadPkg/Library/SblParseLib/SblParseLib.inf 
b/UefiPayloadPkg/Library/SblParseLib/SblParseLib.inf
index f83a10ccd826..1c77d86a8643 100644
--- a/UefiPayloadPkg/Library/SblParseLib/SblParseLib.inf
+++ b/UefiPayloadPkg/Library/SblParseLib/SblParseLib.inf
@@ -41,6 +41,11 @@
   gEfiGraphicsInfoHobGuid
   gEfiGraphicsDeviceInfoHobGuid
   gUniversalPayloadPciRootBridgeInfoGuid
+  gSmmRegisterInfoGuid
+  gEfiSmmSmramMemoryGuid
+  gSpiFlashInfoGuid
+  gNvVariableInfoGuid
+  gS3CommunicationGuid
 
 [Pcd]
   gUefiPayloadPkgTokenSpaceGuid.PcdBootloaderParameter
-- 
2.43.0

Re: [edk2-devel] [PATCH 1/1] OutOfBandManagement/SpcrFeaturePkg: PCD based IRQ/GSI

[Nate DeSimone]

Pushed as 3c0adfe.

-Original Message-
From: Abdul Lateef Attar  
Sent: Wednesday, August 2, 2023 11:35 PM
To: devel@edk2.groups.io
Cc: Abdul Lateef Attar ; Chaganty, Rangasai V 
; Oram, Isaac W ; 
Desimone, Nathaniel L ; Gao, Liming 
; Abner Chang 
Subject: [PATCH 1/1] OutOfBandManagement/SpcrFeaturePkg: PCD based IRQ/GSI

From: Abdul Lateef Attar 

Create a new PCD to hold the IRQ or GSI number for SPCR, with default values of 
4.
Update the ACPI SPCR table's IRQ value based on PCD.

Cc: Sai Chaganty 
Cc: Isaac Oram 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Abner Chang 
Signed-off-by: Abdul Lateef Attar 

Change-Id: I7218903fa5572f8139ad45db598ab085f079713b
---
 .../OutOfBandManagement/SpcrFeaturePkg/SpcrFeaturePkg.dec  | 5 +
 .../SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpiDxe.inf | 4 
 .../SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpi.h  | 3 +++
 .../SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpi.c  | 7 ---
 4 files changed, 16 insertions(+), 3 deletions(-)

diff --git 
a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrFeaturePkg.dec 
b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrFeaturePkg.dec
index b084fad89220..d69d650f3f20 100644
--- a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrFeaturePkg.dec
+++ b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrFeaturePkg.d
+++ ec
@@ -7,6 +7,7 @@
 # for the build infrastructure.
 #
 # Copyright (c) 2020, Intel Corporation. All rights reserved.
+# Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved
 #
 # SPDX-License-Identifier: BSD-2-Clause-Patent  # @@ -24,6 +25,10 @@ 
[Includes]  [Guids]
   gSpcrFeaturePkgTokenSpaceGuid = { 0xe978c988, 0xeeba, 0x4671, { 0xb8, 0x0d, 
0xcc, 0x8b, 0x89, 0xb5, 0xd1, 0xef }}
 
+[PcdsFixedAtBuild]
+  # SPCR default IRQ set to 4
+  gSpcrFeaturePkgTokenSpaceGuid.PcdSpcrInterrupt|4|UINT8|0x0010
+
 [PcdsFeatureFlag]
   gSpcrFeaturePkgTokenSpaceGuid.PcdSpcrFeatureEnable|FALSE|BOOLEAN|0x0001
 
diff --git 
a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpiDxe.inf 
b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpiDxe.inf
index 9a4f95e86bbf..cd43afea5242 100644
--- 
a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpiDxe.inf
+++ b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/Spcr
+++ AcpiDxe.inf
@@ -24,6 +24,7 @@ [LibraryClasses]
   UefiDriverEntryPoint
   UefiLib
   SpcrDeviceLib
+  PcdLib
 
 [Packages]
   MdePkg/MdePkg.dec
@@ -51,5 +52,8 @@ [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterStride
   gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseMmio
 
+[FixedPcd]
+  gSpcrFeaturePkgTokenSpaceGuid.PcdSpcrInterrupt
+
 [Depex]
   TRUE
diff --git 
a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpi.h 
b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpi.h
index c11da439fcb8..245a847762c5 100644
--- a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpi.h
+++ b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/Spcr
+++ Acpi.h
@@ -3,6 +3,8 @@
   SPCR is abbreviation of Serial Port Console Redirection Table (SPCR).
 
   Copyright (c) 2004 - 2020, Intel Corporation. All rights reserved.
+  Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
+
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -23,6 +25,7 @@
 #include 
 #include   #include 
+#include 
 
 #include 
 #include 
diff --git 
a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpi.c 
b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpi.c
index 51449d0fad9e..e92db96caaa9 100644
--- a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpi.c
+++ b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/Spcr
+++ Acpi.c
@@ -3,7 +3,7 @@
   SPCR is abbreviation of Serial Port Console Redirection Table (SPCR).
 
   Copyright (c) 2004 - 2020, Intel Corporation. All rights reserved.
-  Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
+  Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -83,8 +83,8 @@ EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE gSpcrInfo = {
   },
 
   0x03,   //INTERRUPT_TYPE,
-  0x04,   //IRQ,
-  0x04,   //GLOBAL_SYSTEM_INTERRUPT,
+  FixedPcdGet8 (PcdSpcrInterrupt), // IRQ,
+  FixedPcdGet8 (PcdSpcrInterrupt), // GLOBAL_SYSTEM_INTERRUPT,
   0x07,   //BAUD_RATE,
   0x00,   //PARITY,
   0x01,   //STOP_BITS,
@@ -441,6 +441,7 @@ OutOfBandACPITableConstruction (
 gSpcrInfo.FlowControl = UART_FLOW_CONTROL_HARDWARE;
   }
 
+
   if (HasIsaSerialNode(SavedDevicePath)) {
 GetIsaTypeInfo (SavedDevicePath);
   } else {
--
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112331): https://edk2.groups.io/g/devel/message/112331
Mute T

Re: [edk2-devel] [PATCH 1/1] OutOfBandManagement/SpcrFeaturePkg: PCD based IRQ/GSI

[Nate DeSimone]

Reviewed-by: Nate DeSimone 

-Original Message-
From: Abdul Lateef Attar  
Sent: Wednesday, August 2, 2023 11:35 PM
To: devel@edk2.groups.io
Cc: Abdul Lateef Attar ; Chaganty, Rangasai V 
; Oram, Isaac W ; 
Desimone, Nathaniel L ; Gao, Liming 
; Abner Chang 
Subject: [PATCH 1/1] OutOfBandManagement/SpcrFeaturePkg: PCD based IRQ/GSI

From: Abdul Lateef Attar 

Create a new PCD to hold the IRQ or GSI number for SPCR, with default values of 
4.
Update the ACPI SPCR table's IRQ value based on PCD.

Cc: Sai Chaganty 
Cc: Isaac Oram 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Abner Chang 
Signed-off-by: Abdul Lateef Attar 

Change-Id: I7218903fa5572f8139ad45db598ab085f079713b
---
 .../OutOfBandManagement/SpcrFeaturePkg/SpcrFeaturePkg.dec  | 5 +
 .../SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpiDxe.inf | 4 
 .../SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpi.h  | 3 +++
 .../SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpi.c  | 7 ---
 4 files changed, 16 insertions(+), 3 deletions(-)

diff --git 
a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrFeaturePkg.dec 
b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrFeaturePkg.dec
index b084fad89220..d69d650f3f20 100644
--- a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrFeaturePkg.dec
+++ b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrFeaturePkg.d
+++ ec
@@ -7,6 +7,7 @@
 # for the build infrastructure.
 #
 # Copyright (c) 2020, Intel Corporation. All rights reserved.
+# Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved
 #
 # SPDX-License-Identifier: BSD-2-Clause-Patent  # @@ -24,6 +25,10 @@ 
[Includes]  [Guids]
   gSpcrFeaturePkgTokenSpaceGuid = { 0xe978c988, 0xeeba, 0x4671, { 0xb8, 0x0d, 
0xcc, 0x8b, 0x89, 0xb5, 0xd1, 0xef }}
 
+[PcdsFixedAtBuild]
+  # SPCR default IRQ set to 4
+  gSpcrFeaturePkgTokenSpaceGuid.PcdSpcrInterrupt|4|UINT8|0x0010
+
 [PcdsFeatureFlag]
   gSpcrFeaturePkgTokenSpaceGuid.PcdSpcrFeatureEnable|FALSE|BOOLEAN|0x0001
 
diff --git 
a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpiDxe.inf 
b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpiDxe.inf
index 9a4f95e86bbf..cd43afea5242 100644
--- 
a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpiDxe.inf
+++ b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/Spcr
+++ AcpiDxe.inf
@@ -24,6 +24,7 @@ [LibraryClasses]
   UefiDriverEntryPoint
   UefiLib
   SpcrDeviceLib
+  PcdLib
 
 [Packages]
   MdePkg/MdePkg.dec
@@ -51,5 +52,8 @@ [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterStride
   gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseMmio
 
+[FixedPcd]
+  gSpcrFeaturePkgTokenSpaceGuid.PcdSpcrInterrupt
+
 [Depex]
   TRUE
diff --git 
a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpi.h 
b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpi.h
index c11da439fcb8..245a847762c5 100644
--- a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpi.h
+++ b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/Spcr
+++ Acpi.h
@@ -3,6 +3,8 @@
   SPCR is abbreviation of Serial Port Console Redirection Table (SPCR).
 
   Copyright (c) 2004 - 2020, Intel Corporation. All rights reserved.
+  Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
+
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -23,6 +25,7 @@
 #include 
 #include   #include 
+#include 
 
 #include 
 #include 
diff --git 
a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpi.c 
b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpi.c
index 51449d0fad9e..e92db96caaa9 100644
--- a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpi.c
+++ b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/Spcr
+++ Acpi.c
@@ -3,7 +3,7 @@
   SPCR is abbreviation of Serial Port Console Redirection Table (SPCR).
 
   Copyright (c) 2004 - 2020, Intel Corporation. All rights reserved.
-  Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
+  Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -83,8 +83,8 @@ EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE gSpcrInfo = {
   },
 
   0x03,   //INTERRUPT_TYPE,
-  0x04,   //IRQ,
-  0x04,   //GLOBAL_SYSTEM_INTERRUPT,
+  FixedPcdGet8 (PcdSpcrInterrupt), // IRQ,
+  FixedPcdGet8 (PcdSpcrInterrupt), // GLOBAL_SYSTEM_INTERRUPT,
   0x07,   //BAUD_RATE,
   0x00,   //PARITY,
   0x01,   //STOP_BITS,
@@ -441,6 +441,7 @@ OutOfBandACPITableConstruction (
 gSpcrInfo.FlowControl = UART_FLOW_CONTROL_HARDWARE;
   }
 
+
   if (HasIsaSerialNode(SavedDevicePath)) {
 GetIsaTypeInfo (SavedDevicePath);
   } else {
--
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112330): https://edk2.groups.io/g/devel/message/1123

Re: [edk2-devel] [PATCH v1 1/1] IpmiFeaturePkg/GenericIpmi: Sync change from SMM

[Nate DeSimone]

Pushed as 7afba0.

-Original Message-
From: Huang, Li-Xia  
Sent: Tuesday, December 5, 2023 11:00 PM
To: devel@edk2.groups.io
Cc: Abner Chang ; Desimone, Nathaniel L 

Subject: [PATCH v1 1/1] IpmiFeaturePkg/GenericIpmi: Sync change from SMM

Sync change from SMM to StandaloneMm GenericIpmi driver.
Update SmmIpmbInterface and SmmSsifInterface Lib to support MM_STANDALONE. And 
Format code with uncrustify.

Cc: Abner Chang 
Cc: Nate DeSimone 

Signed-off-by: Lixia Huang 
---
 
Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/StandaloneMm/StandaloneMmGenericIpmi.c
| 315 +---
 
Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Library/BmcInterfaceCommonAccess/IpmbInterfaceLib/SmmIpmbInterfaceLib.c
   |   4 +-
 
Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Library/BmcInterfaceCommonAccess/SsifInterfaceLib/SmmSsifInterfaceLib.c
   |  64 ++--
 
Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/StandaloneMm/StandaloneMmGenericIpmi.inf
  |  10 +
 Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Include/IpmiFeature.dsc  
 |   2 +-
 
Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Library/BmcInterfaceCommonAccess/IpmbInterfaceLib/SmmIpmbInterfaceLib.inf
 |   4 +-
 
Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Library/BmcInterfaceCommonAccess/SsifInterfaceLib/SmmSsifInterfaceLib.inf
 |   4 +-
 7 files changed, 326 insertions(+), 77 deletions(-)

diff --git 
a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/StandaloneMm/StandaloneMmGenericIpmi.c
 
b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/StandaloneMm/StandaloneMmGenericIpmi.c
index d808e2517c99..1b9841e4b745 100644
--- 
a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/StandaloneMm/StandaloneMmGenericIpmi.c
+++ b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Stan
+++ daloneMm/StandaloneMmGenericIpmi.c
@@ -19,17 +19,157 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "IpmiHooks.h"
 #include "IpmiBmcCommon.h"
 #include "IpmiBmc.h"
 
-IPMI_BMC_INSTANCE_DATA *mIpmiInstance;
-EFI_HANDLE mHandle;
+IPMI_BMC_INSTANCE_DATA  *mIpmiInstance;
+EFI_HANDLE  mIpmiTransportHandle;
+EFI_HANDLE  mIpmiTransport2Handle;
 
 /**
+
+Routine Description:
+  Initialize the API and parameters for IPMI Transport2 Instance
+
+Arguments:
+  IpmiInstance- Pointer to IPMI Instance.
+
+Returns:
+  VOID- Nothing.
+
+**/
+VOID
+InitIpmiTransport2 (
+  IN  IPMI_BMC_INSTANCE_DATA  *IpmiInstance
+  )
+{
+  IpmiInstance->IpmiTransport2.InterfaceType   = FixedPcdGet8 
(PcdDefaultSystemInterface);
+  IpmiInstance->IpmiTransport2.IpmiTransport2BmcStatus = BmcStatusOk;
+  IpmiInstance->IpmiTransport2.IpmiSubmitCommand2  = IpmiSendCommand2;
+  IpmiInstance->IpmiTransport2.IpmiSubmitCommand2Ex= IpmiSendCommand2Ex;
+
+  if (FixedPcdGet8 (PcdBtInterfaceSupport) == 1) {
+InitBtInterfaceData (&IpmiInstance->IpmiTransport2);  }
+
+  if (FixedPcdGet8 (PcdSsifInterfaceSupport) == 1) {
+InitSsifInterfaceData (&IpmiInstance->IpmiTransport2);  }
+
+  if (FixedPcdGet8 (PcdIpmbInterfaceSupport) == 1) {
+InitIpmbInterfaceData (&IpmiInstance->IpmiTransport2);
+  }
+}
+
+/**
+
+Routine Description:
+  Notify call back to initialize the interfaces and install SMM IPMI
+  protocol.
+
+Arguments:
+  Protocol- Pointer to the protocol guid.
+  Interface   - Pointer to the protocol instance.
+  Handle  - Handle on which the protocol is installed.
+
+Returns:
+  Status of Notify call back.
+
+**/
+EFI_STATUS
+EFIAPI
+SmmNotifyCallback (
+  IN CONST  EFI_GUID*Protocol,
+  INVOID*Interface,
+  INEFI_HANDLE  Handle
+  )
+{
+  EFI_STATUSStatus;
+  IPMI_INTERFACE_STATE  InterfaceState;
+
+  InterfaceState = IpmiInterfaceNotReady;
+
+  if (FixedPcdGet8 (PcdSsifInterfaceSupport) == 1) {
+InitSsifInterfaceData (&mIpmiInstance->IpmiTransport2);
+
+if (mIpmiInstance->IpmiTransport2.Interface.Ssif.InterfaceState == 
IpmiInterfaceInitialized) {
+  InterfaceState = IpmiInterfaceInitialized;
+}
+  }
+
+  if (FixedPcdGet8 (PcdIpmbInterfaceSupport) == 1) {
+InitIpmbInterfaceData (&mIpmiInstance->IpmiTransport2);  }
+
+  if (mIpmiInstance->IpmiTransport2.Interface.Ipmb.InterfaceState == 
IpmiInterfaceInitialized) {
+InterfaceState = IpmiInterfaceInitialized;  }
+
+  if (InterfaceState != IpmiInterfaceInitialized) {
+return EFI_SUCCESS;
+  }
+
+  // Default Interface data should be initialized to install Ipmi Transport2 
Protocol.
+  if (InterfaceState == IpmiInterfaceInitialized) {
+mIpmiTransport2Handle = NULL;
+Status= gMmst->MmInstallProtocolInterface (
+ &mIpmiTransport2Handle,
+ &gSmmIpmiTransport2ProtocolGuid,
+  

Re: [edk2-devel] [PATCH v1 1/1] IpmiFeaturePkg/GenericIpmi: Sync change from SMM

[Nate DeSimone]

Reviewed-by: Nate DeSimone 

-Original Message-
From: Huang, Li-Xia  
Sent: Tuesday, December 5, 2023 11:00 PM
To: devel@edk2.groups.io
Cc: Abner Chang ; Desimone, Nathaniel L 

Subject: [PATCH v1 1/1] IpmiFeaturePkg/GenericIpmi: Sync change from SMM

Sync change from SMM to StandaloneMm GenericIpmi driver.
Update SmmIpmbInterface and SmmSsifInterface Lib to support MM_STANDALONE. And 
Format code with uncrustify.

Cc: Abner Chang 
Cc: Nate DeSimone 

Signed-off-by: Lixia Huang 
---
 
Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/StandaloneMm/StandaloneMmGenericIpmi.c
| 315 +---
 
Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Library/BmcInterfaceCommonAccess/IpmbInterfaceLib/SmmIpmbInterfaceLib.c
   |   4 +-
 
Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Library/BmcInterfaceCommonAccess/SsifInterfaceLib/SmmSsifInterfaceLib.c
   |  64 ++--
 
Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/StandaloneMm/StandaloneMmGenericIpmi.inf
  |  10 +
 Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Include/IpmiFeature.dsc  
 |   2 +-
 
Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Library/BmcInterfaceCommonAccess/IpmbInterfaceLib/SmmIpmbInterfaceLib.inf
 |   4 +-
 
Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Library/BmcInterfaceCommonAccess/SsifInterfaceLib/SmmSsifInterfaceLib.inf
 |   4 +-
 7 files changed, 326 insertions(+), 77 deletions(-)

diff --git 
a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/StandaloneMm/StandaloneMmGenericIpmi.c
 
b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/StandaloneMm/StandaloneMmGenericIpmi.c
index d808e2517c99..1b9841e4b745 100644
--- 
a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/StandaloneMm/StandaloneMmGenericIpmi.c
+++ b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Stan
+++ daloneMm/StandaloneMmGenericIpmi.c
@@ -19,17 +19,157 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "IpmiHooks.h"
 #include "IpmiBmcCommon.h"
 #include "IpmiBmc.h"
 
-IPMI_BMC_INSTANCE_DATA *mIpmiInstance;
-EFI_HANDLE mHandle;
+IPMI_BMC_INSTANCE_DATA  *mIpmiInstance;
+EFI_HANDLE  mIpmiTransportHandle;
+EFI_HANDLE  mIpmiTransport2Handle;
 
 /**
+
+Routine Description:
+  Initialize the API and parameters for IPMI Transport2 Instance
+
+Arguments:
+  IpmiInstance- Pointer to IPMI Instance.
+
+Returns:
+  VOID- Nothing.
+
+**/
+VOID
+InitIpmiTransport2 (
+  IN  IPMI_BMC_INSTANCE_DATA  *IpmiInstance
+  )
+{
+  IpmiInstance->IpmiTransport2.InterfaceType   = FixedPcdGet8 
(PcdDefaultSystemInterface);
+  IpmiInstance->IpmiTransport2.IpmiTransport2BmcStatus = BmcStatusOk;
+  IpmiInstance->IpmiTransport2.IpmiSubmitCommand2  = IpmiSendCommand2;
+  IpmiInstance->IpmiTransport2.IpmiSubmitCommand2Ex= IpmiSendCommand2Ex;
+
+  if (FixedPcdGet8 (PcdBtInterfaceSupport) == 1) {
+InitBtInterfaceData (&IpmiInstance->IpmiTransport2);  }
+
+  if (FixedPcdGet8 (PcdSsifInterfaceSupport) == 1) {
+InitSsifInterfaceData (&IpmiInstance->IpmiTransport2);  }
+
+  if (FixedPcdGet8 (PcdIpmbInterfaceSupport) == 1) {
+InitIpmbInterfaceData (&IpmiInstance->IpmiTransport2);
+  }
+}
+
+/**
+
+Routine Description:
+  Notify call back to initialize the interfaces and install SMM IPMI
+  protocol.
+
+Arguments:
+  Protocol- Pointer to the protocol guid.
+  Interface   - Pointer to the protocol instance.
+  Handle  - Handle on which the protocol is installed.
+
+Returns:
+  Status of Notify call back.
+
+**/
+EFI_STATUS
+EFIAPI
+SmmNotifyCallback (
+  IN CONST  EFI_GUID*Protocol,
+  INVOID*Interface,
+  INEFI_HANDLE  Handle
+  )
+{
+  EFI_STATUSStatus;
+  IPMI_INTERFACE_STATE  InterfaceState;
+
+  InterfaceState = IpmiInterfaceNotReady;
+
+  if (FixedPcdGet8 (PcdSsifInterfaceSupport) == 1) {
+InitSsifInterfaceData (&mIpmiInstance->IpmiTransport2);
+
+if (mIpmiInstance->IpmiTransport2.Interface.Ssif.InterfaceState == 
IpmiInterfaceInitialized) {
+  InterfaceState = IpmiInterfaceInitialized;
+}
+  }
+
+  if (FixedPcdGet8 (PcdIpmbInterfaceSupport) == 1) {
+InitIpmbInterfaceData (&mIpmiInstance->IpmiTransport2);  }
+
+  if (mIpmiInstance->IpmiTransport2.Interface.Ipmb.InterfaceState == 
IpmiInterfaceInitialized) {
+InterfaceState = IpmiInterfaceInitialized;  }
+
+  if (InterfaceState != IpmiInterfaceInitialized) {
+return EFI_SUCCESS;
+  }
+
+  // Default Interface data should be initialized to install Ipmi Transport2 
Protocol.
+  if (InterfaceState == IpmiInterfaceInitialized) {
+mIpmiTransport2Handle = NULL;
+Status= gMmst->MmInstallProtocolInterface (
+ &mIpmiTransport2Handle,
+ &gSmmIpmiTransport2ProtocolGuid,
+

Re: [edk2-devel] [PATCH 2/2] MdePkg:simplify Fifo API in BaseIoLibIntrinsic

[Michael D Kinney]

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

> -Original Message-
> From: Kinney, Michael D 
> Sent: Monday, December 11, 2023 9:34 AM
> To: Tan, Dun ; devel@edk2.groups.io
> Cc: Gao, Liming ; Liu, Zhiguang
> ; Ni, Ray ; Kinney, Michael D
> 
> Subject: RE: [edk2-devel] [PATCH 2/2] MdePkg:simplify Fifo API in
> BaseIoLibIntrinsic
> 
> Acked-by: Michael D Kinney 
> 
> Mike
> 
> > -Original Message-
> > From: Tan, Dun 
> > Sent: Wednesday, December 6, 2023 1:26 AM
> > To: devel@edk2.groups.io; Tan, Dun 
> > Cc: Kinney, Michael D ; Gao, Liming
> > ; Liu, Zhiguang ;
> Ni,
> > Ray 
> > Subject: RE: [edk2-devel] [PATCH 2/2] MdePkg:simplify Fifo API in
> > BaseIoLibIntrinsic
> >
> > Hi Mike and Liming,
> >
> > Could you please help to review this patch?
> >
> > Thanks,
> > Dun
> >
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of duntan
> > Sent: Thursday, November 9, 2023 10:50 AM
> > To: devel@edk2.groups.io
> > Cc: Kinney, Michael D ; Gao, Liming
> > ; Liu, Zhiguang ;
> Ni,
> > Ray 
> > Subject: [edk2-devel] [PATCH 2/2] MdePkg:simplify Fifo API in
> > BaseIoLibIntrinsic
> >
> > Simplify IoRead/WriteFifo implement by repeatedly calling IoRead/Write
> > in the C code.
> > This can avoid calling assembly code to use string I/O instructions.
> > With this change Ia32/IoFifo.nasm and X64/IoFifo.nasm can be removed.
> > Then the source files for IA32 and X64 are the same.
> >
> > Signed-off-by: Dun Tan 
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> > Cc: Zhiguang Liu 
> > Cc: Ray Ni 
> > ---
> >  MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf |  10 ++
> --
> > --
> >  MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm   | 131 --
> --
> > --
> --
> > ---
> >  MdePkg/Library/BaseIoLibIntrinsic/IoLibFifo.c| 220
> >
> 
> >
> 
> >
> 
> > 
> >  MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifo.nasm| 120 --
> --
> > --
> --
> > 
> >  4 files changed, 222 insertions(+), 259 deletions(-)
> >
> > diff --git a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> > b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> > index aeb072ee95..b587e2cded 100644
> > --- a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> > +++ b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> > @@ -38,17 +38,11 @@
> >IoLibInternalTdxNull.c
> >IoLibTdx.h
> >
> > -[Sources.IA32]
> > +[Sources.IA32, Sources.X64]
> >IoLibGcc.c| GCC
> >IoLibMsc.c| MSFT
> >IoLib.c
> > -  Ia32/IoFifo.nasm
> > -
> > -[Sources.X64]
> > -  IoLibGcc.c| GCC
> > -  IoLibMsc.c| MSFT
> > -  IoLib.c
> > -  X64/IoFifo.nasm
> > +  IoLibFifo.c
> >
> >  [Sources.EBC]
> >IoLibEbc.c
> > diff --git a/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm
> > b/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm
> > deleted file mode 100644
> > index a4ae1a0053..00
> > --- a/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm
> > +++ /dev/null
> > @@ -1,131 +0,0 @@
> > -;
> --
> > 
> > -;
> > -; Copyright (c) 2006 - 2012, Intel Corporation. All rights
> > reserved. -; Copyright (c) 2017, AMD Incorporated. All rights
> > reserved. -; -; SPDX-License-Identifier: BSD-2-Clause-Patent -;
> > -;
> --
> > 
> > -
> > -SECTION .text
> > -
> > -;
> --
> > 
> > -;  VOID
> > -;  EFIAPI
> > -;  IoReadFifo8 (
> > -;IN  UINTN Port,
> > -;IN  UINTN Size,
> > -;OUT VOID  *Buffer
> > -;);
> > -;
> --
> > 
> > -global ASM_PFX(IoReadFifo8)
> > -ASM_PFX(IoReadFifo8):
> > -pushedi
> > -cld
> > -mov dx, [esp + 8]
> > -mov ecx, [esp + 12]
> > -mov edi, [esp + 16]
> > -rep insb
> > -pop edi
> > -ret
> > -
> > -;
> --
> > 
> > -;  VOID
> > -;  EFIAPI
> > -;  IoReadFifo16 (
> > -;IN  UINTN Port,
> > -;IN  UINTN Size,
> > -;OUT VOID  *Buffer
> > -;);
> > -;
> --
> > 
> > -global ASM_PFX(IoReadFifo16)
> > -ASM_PFX(IoReadFifo16):
> > -pushedi
> > -cld
> > -mov dx, [esp + 8]
> > 

Re: [edk2-devel] [PATCH v7 1/5] UefiCpuPkg: Add macro definitions for CET feature for NASM files.

[Laszlo Ersek]

On 12/7/23 10:01, Sheng Wei wrote:
> Hi Ray,
> I update the copyright year and add your review-by for the 5 patches.
> And here is the PR https://github.com/tianocore/edk2/pull/5109

Why was my Reviewed-by removed from v6 patches #2 through #5?

Those patches didn't change between v6 and v7, except for the copyright
year updates.

It's demotivating that evidence of my review efforts was explicitly
excluded from git commit history, for no good reason (as far as I can tell).

Laszlo



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

Re: [edk2-devel] [Patch V4 0/3] UefiCpuPkg/MpInitLib: Eliminate redundant microcode loading in DXE.

[Laszlo Ersek]

On 11/24/23 04:45, Ni, Ray wrote:
> Reviewed-by: Ray Ni 

Please go ahead with merging this. The patch set has changed so much
since v2 (which I last reviewed) that I can't perform an incremental
review, and I can't review this from zero at the moment.

Thanks
Laszlo

> 
> Thanks,
> Ray
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Yuanhao
>> Xie
>> Sent: Friday, November 24, 2023 10:57 AM
>> To: devel@edk2.groups.io
>> Cc: Xie, Yuanhao 
>> Subject: [edk2-devel] [Patch V4 0/3] UefiCpuPkg/MpInitLib: Eliminate
>> redundant microcode loading in DXE.
>>
>> The DXE stage's Microcode loading process has been eliminated.
>> Store BSP's MTRR setting only when CpuCount>1.
>> Extract Dump Microcode Revision as a function
>>
>> Compare with V3, this version updates the comments,
>> Move GetMicrocodePatchInfoFromHob removal from patch 3 to patch 1
>>
>> on
>> xieyuanh (3):
>>   UefiCpuPkg/MpInitLib: Eliminate redundant microcode loading in DXE.
>>   UefiCpuPkg/MpInitLib: Store MTRRs settings only when  CpuCount>1
>>   UefiCpuPkg/MpInitLib: Extract Dump Microcode Revision as function.
>>
>>  UefiCpuPkg/Library/MpInitLib/Microcode.c | 85
>> +++--
>> 
>>  UefiCpuPkg/Library/MpInitLib/MpLib.c | 81
>> -
>>  UefiCpuPkg/Library/MpInitLib/MpLib.h | 31
>> ++-
>>  3 files changed, 81 insertions(+), 116 deletions(-)
>>
>> --
>> 2.39.1.windows.1
>>
>>
>>
>>
>>
> 
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH 2/2] MdePkg:simplify Fifo API in BaseIoLibIntrinsic

[Michael D Kinney]

Acked-by: Michael D Kinney 

Mike

> -Original Message-
> From: Tan, Dun 
> Sent: Wednesday, December 6, 2023 1:26 AM
> To: devel@edk2.groups.io; Tan, Dun 
> Cc: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang ; Ni,
> Ray 
> Subject: RE: [edk2-devel] [PATCH 2/2] MdePkg:simplify Fifo API in
> BaseIoLibIntrinsic
> 
> Hi Mike and Liming,
> 
> Could you please help to review this patch?
> 
> Thanks,
> Dun
> 
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of duntan
> Sent: Thursday, November 9, 2023 10:50 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang ; Ni,
> Ray 
> Subject: [edk2-devel] [PATCH 2/2] MdePkg:simplify Fifo API in
> BaseIoLibIntrinsic
> 
> Simplify IoRead/WriteFifo implement by repeatedly calling IoRead/Write
> in the C code.
> This can avoid calling assembly code to use string I/O instructions.
> With this change Ia32/IoFifo.nasm and X64/IoFifo.nasm can be removed.
> Then the source files for IA32 and X64 are the same.
> 
> Signed-off-by: Dun Tan 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Ray Ni 
> ---
>  MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf |  10 ++--
> --
>  MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm   | 131 
> 
> ---
>  MdePkg/Library/BaseIoLibIntrinsic/IoLibFifo.c| 220
> 
> 
> 
> 
>  MdePkg/Library/BaseIoLibIntrinsic/X64/IoFifo.nasm| 120 
> 
> 
>  4 files changed, 222 insertions(+), 259 deletions(-)
> 
> diff --git a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> index aeb072ee95..b587e2cded 100644
> --- a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> +++ b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> @@ -38,17 +38,11 @@
>IoLibInternalTdxNull.c
>IoLibTdx.h
> 
> -[Sources.IA32]
> +[Sources.IA32, Sources.X64]
>IoLibGcc.c| GCC
>IoLibMsc.c| MSFT
>IoLib.c
> -  Ia32/IoFifo.nasm
> -
> -[Sources.X64]
> -  IoLibGcc.c| GCC
> -  IoLibMsc.c| MSFT
> -  IoLib.c
> -  X64/IoFifo.nasm
> +  IoLibFifo.c
> 
>  [Sources.EBC]
>IoLibEbc.c
> diff --git a/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm
> b/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm
> deleted file mode 100644
> index a4ae1a0053..00
> --- a/MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm
> +++ /dev/null
> @@ -1,131 +0,0 @@
> -;--
> 
> -;
> -; Copyright (c) 2006 - 2012, Intel Corporation. All rights
> reserved. -; Copyright (c) 2017, AMD Incorporated. All rights
> reserved. -; -; SPDX-License-Identifier: BSD-2-Clause-Patent -;
> -;--
> 
> -
> -SECTION .text
> -
> -;--
> 
> -;  VOID
> -;  EFIAPI
> -;  IoReadFifo8 (
> -;IN  UINTN Port,
> -;IN  UINTN Size,
> -;OUT VOID  *Buffer
> -;);
> -;--
> 
> -global ASM_PFX(IoReadFifo8)
> -ASM_PFX(IoReadFifo8):
> -pushedi
> -cld
> -mov dx, [esp + 8]
> -mov ecx, [esp + 12]
> -mov edi, [esp + 16]
> -rep insb
> -pop edi
> -ret
> -
> -;--
> 
> -;  VOID
> -;  EFIAPI
> -;  IoReadFifo16 (
> -;IN  UINTN Port,
> -;IN  UINTN Size,
> -;OUT VOID  *Buffer
> -;);
> -;--
> 
> -global ASM_PFX(IoReadFifo16)
> -ASM_PFX(IoReadFifo16):
> -pushedi
> -cld
> -mov dx, [esp + 8]
> -mov ecx, [esp + 12]
> -mov edi, [esp + 16]
> -rep insw
> -pop edi
> -ret
> -
> -;--
> 
> -;  VOID
> -;  EFIAPI
> -;  IoReadFifo32 (
> -;IN  UINTN Port,
> -;IN  UINTN Size,
> -;OUT VOID  *Buffer
> -;);
> -;--
> 
> -global ASM_PFX(IoReadFifo32)
> -ASM_PFX(IoReadFifo32):
> -pushedi
> -cld
> -mov dx, [esp + 8]
> -mov ecx, [esp + 12]
> -mov edi, [esp + 16]
> -rep insd
> -pop ed

Re: [edk2-devel] [PATCH] BaseTools/tools_def: Disable unneeded-internal-declaration warning in CLANGPDB

[Mike Beaton]

> > I believe this would be logically wrong, as the other versions still
> > wouldn't compile if you changed the relevant debug Pcds. (Which are
> > logically independent of the compile and link options - e.g. what if for
> > some reason you wanted to single step with the Debug Pcds set to
> > disabled, in a NOOPT build?)
>
> I don't think that use case exists in practice.
>
> Anyway, my suggestion is based on prior art: I *think* we ask gcc to
> whine about unused local variables in RELEASE builds only, too. See
> commits 20d00edf21d2 ("BaseTools/GCC: set -Wno-unused-but-set-variables
> only on RELEASE builds", 2016-03-25) and 8b6366f87584 ("BaseTools/GCC:
> set -Wno-unused-const-variable on RELEASE builds", 2017-09-08).
>
> ... TBH I don't understand the current state of
> "-Wno-unused-but-set-variables" and "-Wno-unused-const-variable" between
> X64 and AARCH64, considering the DEBUG target. Today,
> DEBUG_GCC5_AARCH64_CC_FLAGS disables these warnings, but
> DEBUG_GCC5_X64_CC_FLAGS doesn't, even though *both* macros specify
> -flto. Compare commit 06c8a34cc4bc ("BaseTool/tools_def GCC5: enable
> optimization for ARM/AARCH64 DEBUG builds", 2017-12-08) -- I don't
> understand why "-flto" had to be accompanied by
> "-Wno-unused-but-set-variable -Wno-unused-const-variable" in that commit.
>
> In brief, IA32 and X64 prior art supports my suggestion to shut up the
> warning only for RELEASE (for CLANGPDB too), but ARM/AARCH64 prior art
> contradicts that proposal. IOW, prior art is inconsistent per se... I
> don't understand.
>
> Laszlo

Hunting around further, it is not the Pcds which are causing this to
be optimised away, but the definition of MDEPKG_NDEBUG.

A completely different approach, which allows clang to spot that the
usage has been 'optimised away' and so to not complain (and therefore
allows us to re-enable the warning in CLANGDWARF as well), is the
following:

--- a/MdePkg/Include/Library/DebugLib.h
+++ b/MdePkg/Include/Library/DebugLib.h
@@ -426,7 +426,10 @@ UnitTestDebugAssert (
   }\
 } while (FALSE)
 #else
-#define DEBUG(Expression)
+#define DEBUG(Expression)\
+if (FALSE) {   \
+  _DEBUG (Expression); \
+}
 #endif

 /**


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112323): https://edk2.groups.io/g/devel/message/112323
Mute This Topic: https://groups.io/mt/103087794/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-test v2 0/4] Various improvements to the repo

[Rebecca Cran]

I don't appear to have permission to push to the edk2-test repo.
Could somebody merge my change please?

Thanks.
Rebecca

On 11/10/2023 12:08 PM, Rebecca Cran wrote:

Some improvements to the edk2-test repository.

Since buildzip.sh creates output that appears more useful for running on
the target machine, I wonder if we might want to mention it in the
documentation someplace?

Also, I suspect the HowToBuildSctInUdk2017.txt file is now pretty
outdated. Should we delete it?

Finally, is the TianoCore Contribution Agreement still relevant? I know
it is for the edk2 docs repositories, but not sure if edk2-test should
be updated to match the other code repos like edk2 and edk2-platforms?

CHANGES FROM v1 to v2:

Converted tabs to spaces in the echo line added to buildzip.sh

Rebecca Cran (4):
   Unbreak buildzip.sh
   Rename files in HowToBuild to avoid spaces in filenames
   Point users to the URL for edk2-test-parser if it doesn't exist
   Fix the URL for the edk2-test repo

  Maintainers.txt   
   | 2 +-
  uefi-sct/HowToBuild/{How to accelerate SCT execution.txt => 
HowToAccelerateSctExecution.txt} | 0
  uefi-sct/HowToBuild/{How to build SCT.txt => HowToBuildSct.txt}   
   | 0
  uefi-sct/HowToBuild/{How to build SCT in UDK2017.txt => 
HowToBuildSctInUdk2017.txt}  | 0
  uefi-sct/SctPkg/buildzip.sh   
   | 4 +---
  5 files changed, 2 insertions(+), 4 deletions(-)
  rename uefi-sct/HowToBuild/{How to accelerate SCT execution.txt => 
HowToAccelerateSctExecution.txt} (100%)
  rename uefi-sct/HowToBuild/{How to build SCT.txt => HowToBuildSct.txt} (100%)
  rename uefi-sct/HowToBuild/{How to build SCT in UDK2017.txt => 
HowToBuildSctInUdk2017.txt} (100%)





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112322): https://edk2.groups.io/g/devel/message/112322
Mute This Topic: https://groups.io/mt/102513312/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] CloudHv: Add CI for CloudHv on AArch64

[Laszlo Ersek]

Hi Jianyong,

On 12/11/23 17:31, Laszlo Ersek wrote:
> On 11/23/23 04:22, Jianyong Wu wrote:
>> Add the long lost CI for CloudHv on AArch64.
>> As CloudHv CI works nearly the same way with other VMMs like KvmTool,
>> thus we can easily create its CI configuration based on KvmTool.
>>
>> Reviewed-by: Laszlo Ersek 
>> Signed-off-by: Jianyong Wu 
>> ---
>>  .../PlatformCI/.azurepipelines/Ubuntu-GCC5.yml  | 13 +
>>  .../PlatformCI/{KvmToolBuild.py => CloudHvBuild.py} |  4 ++--
>>  2 files changed, 15 insertions(+), 2 deletions(-)
>>  copy ArmVirtPkg/PlatformCI/{KvmToolBuild.py => CloudHvBuild.py} (89%)
>>
>> diff --git a/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml 
>> b/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
>> index d1772a65fc..ab8a2db530 100644
>> --- a/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
>> +++ b/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
>> @@ -140,6 +140,19 @@ jobs:
>>  Build.Target: "RELEASE"
>>  Run: false
>>  
>> +  CLOUDHV_AARCH64_DEBUG:
>> +Build.File: "$(package)/PlatformCI/CloudHvBuild.py"
>> +Build.Arch: "AARCH64"
>> +Build.Flags: ""
>> +Build.Target: "DEBUG"
>> +Run: false
>> +  CLOUDHV_AARCH64_RELEASE:
>> +Build.File: "$(package)/PlatformCI/CloudHvBuild.py"
>> +Build.Arch: "AARCH64"
>> +Build.Flags: ""
>> +Build.Target: "RELEASE"
>> +Run: false
>> +
>>  workspace:
>>clean: all
>>  
>> diff --git a/ArmVirtPkg/PlatformCI/KvmToolBuild.py 
>> b/ArmVirtPkg/PlatformCI/CloudHvBuild.py
>> similarity index 89%
>> copy from ArmVirtPkg/PlatformCI/KvmToolBuild.py
>> copy to ArmVirtPkg/PlatformCI/CloudHvBuild.py
>> index 4d02dba124..06ada39886 100644
>> --- a/ArmVirtPkg/PlatformCI/KvmToolBuild.py
>> +++ b/ArmVirtPkg/PlatformCI/CloudHvBuild.py
>> @@ -19,13 +19,13 @@ class CommonPlatform():
>>  for the different parts of stuart
>>  '''
>>  PackagesSupported = ("ArmVirtPkg",)
>> -ArchSupported = ("AARCH64", "ARM")
>> +ArchSupported = ("AARCH64")
> 
> Right, and this one change is new in version 2 of the patch.
> 
> My R-b stands.
> 
> I'm picking this up now.
> 

The CI run failed for this patch when I tried to merge it; can you
please review ?

Thanks,
Laszlo



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

Re: [edk2-devel] [PATCH v3 11/39] UefiCpuPkg: Add LoongArch64 CPU Timer library

[Laszlo Ersek]

On 11/23/23 12:43, Chao Li wrote:
> On 2023/11/23 00:12, Laszlo Ersek wrote:
>> On 11/17/23 11:00, Chao Li wrote:
>>> Add the LoongArch64 CPU Timer library, using CPUCFG 0x4 and 0x5 for
>>> Stable Counter frequency.
>>>
>>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
>>>
>>> Cc: Eric Dong 
>>> Cc: Ray Ni 
>>> Cc: Rahul Kumar 
>>> Cc: Gerd Hoffmann 
>>> Signed-off-by: Chao Li 
>>> ---
>>>  .../BaseLoongArch64CpuTimerLib.inf|  30 +++
>>>  .../BaseLoongArch64CpuTimerLib.uni|  15 ++
>>>  .../BaseLoongArch64CpuTimerLib/CpuTimerLib.c  | 226 ++
>>>  UefiCpuPkg/UefiCpuPkg.dsc |   3 +
>>>  4 files changed, 274 insertions(+)
>>>  create mode 100644 
>>> UefiCpuPkg/Library/BaseLoongArch64CpuTimerLib/BaseLoongArch64CpuTimerLib.inf
>>>  create mode 100644 
>>> UefiCpuPkg/Library/BaseLoongArch64CpuTimerLib/BaseLoongArch64CpuTimerLib.uni
>>>  create mode 100644 
>>> UefiCpuPkg/Library/BaseLoongArch64CpuTimerLib/CpuTimerLib.c
>> (1) sorry about the annoying comment, but the library should be
>> called (preferably) BaseTimerLibLoongArch64Cpu.
>>
>> We're frequently not consistent with the following library instance
>> naming scheme, but in theory anyway, library instances should be
>> named as follows:
>>
>>   
>>
>> Thus, in this case, Base + TimerLib + LoongArch64Cpu.
>>
>> update UNI file name, INF file name, directory name, BASE_NAME and
>> MODULE_UNI_FILE accordingly (if you agree)
>
> There has a SPEC for naming style:
>
> https://github.com/tianocore-docs/edk2-CCodingStandardsSpecification/blob/master/4_naming_conventions/42_directory_names.md
>
> Please check 4.2.3 EDKII Library directory, and most directory naming
> follows this SPEC.

I didn't remember (or know about) this part of the coding standards
spec; thanks for the pointer.

It seems like my suggestion matches the second alternative
([]).

Your naming seems to follow the first alternative
([]). OK.

However, that's still not a perfect match. For , you have "Base".
For , you have "LoongArch64". But for , you
have "CpuTimerLib", and that's wrong. We don't have a "CpuTimerLib"
class; instead it's the "TimerLib" class.

The LIBRARY_CLASS define in your INF file also says "TimerLib", so
"CpuTimerLib" is wrong / inconsistent in the lib instance name.
"BaseLoongArch64TimerLib" should be fine. If you want to add "Cpu", I
guess you could add it as [], as a suffix, under the first
naming scheme alternative: "BaseLoongArch64TimerLibCpu".

>> (5) Relatedly: the TimerLib class is declared in "MdePkg.dec". Thus,
>> if you indeed don't need anything from "UefiCpuPkg.dec", I'd suggest
>> moving this library instance under MdePkg.

> It is inappropriate to place this library in MdePkg, because the
> MdePkg doesn't have any CpuTimerLib instance, and this class library
> are HW implementation-related, so it more appropriate to place it in
> UefiCpuPkg.

This ties in with my above comment. The reason for MdePkg not having a
"CpuTimerLib" instance is that there is no such lib class in edk2.

The library class is called "TimerLib". We have multiple instances in
edk2:

$ git grep -l 'LIBRARY_CLASS *= *TimerLib\>' -- '*inf'

  ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
  EmulatorPkg/Library/DxeCoreTimerLib/DxeCoreTimerLib.inf
  EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.inf
  EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.inf
  MdePkg/Library/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf
  MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
  OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf
  OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLibBhyve.inf
  OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
  OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
  PcAtChipsetPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf
  PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
  PcAtChipsetPkg/Library/AcpiTimerLib/PeiAcpiTimerLib.inf
  PcAtChipsetPkg/Library/AcpiTimerLib/StandaloneMmAcpiTimerLib.inf
  UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/BaseRiscV64CpuTimerLib.inf
  UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
  UefiCpuPkg/Library/SecPeiDxeTimerLibUefiCpu/SecPeiDxeTimerLibUefiCpu.inf
  UefiPayloadPkg/Library/AcpiTimerLib/AcpiTimerLib.inf

This "prior art" suggests the new library instance could go in MdePkg or
UefiCpuPkg alike.

That's where my comment about "UefiCpuPkg.dec" dependencies becomes
relevant. Compare:

- MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf
- UefiCpuPkg/Library/SecPeiDxeTimerLibUefiCpu/SecPeiDxeTimerLibUefiCpu.inf

The difference between these library instances (as the INF files
explain) is xAPIC vs. x2APIC support. The latter instance supports
x2APIC. And, for x2APIC support, the latter instance depends on the
LocalApicLib class. The LocalApicLib class is declared in
"UefiCpuPkg.dec". And that is the dependency that forces the second
library instance to exist under UefiCpuPkg.

Thus, my original point stands -- if you need nothing from "UefiCpuPkg",

Re: [edk2-devel] [PATCH] MdePkg/BaseFdtLib: Rename standard functions

[Jeff Brasen via groups.io]

Hit send before adding the cc on this one. (Would probably be good to get that 
added to here 
(https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process)
 so copy paste doesn't get folks 😊.

I sent them as different patch series as I thought this one might cause some 
discussion and wanted to separate it from that. 

This issue I was seeing is if you both include FdtLib and BaseCryptLib they 
both contain implementations of these standard functions with other functions 
in the same c files. This results in a link error as the linker won't discard 
part of a compilation unit if it is used so if you have

Foo.c has functions func1 and func2
Bar.c has functions func3 and func2

If func3 and func1 are both used externally that will cause both objects to be 
included and the linker to complain that func2 is defined twice.

We could move these to c files with just 1 function each in both libraries but 
that seemed like a bigger change than this.

-Jeff


> -Original Message-
> From: Pedro Falcato 
> Sent: Monday, December 11, 2023 9:00 AM
> To: devel@edk2.groups.io; Jeff Brasen 
> Subject: Re: [edk2-devel] [PATCH] MdePkg/BaseFdtLib: Rename standard
> functions
> 
> External email: Use caution opening links or attachments
> 
> 
> On Mon, Dec 11, 2023 at 3:40 PM Jeff Brasen via groups.io
>  wrote:
> >
> 
> Jeff,
> 
> You're missing CC's on this patch. Also, you should probably send the
> 3 patches in a single series, since they're all related.
> 
> > Rename the standard functions in the LibFdtSupport to remove conflicts
> > with other libraries that define them.
> 
> This is a funny problem. What error were you seeing? As far as I can tell, you
> can totally define your local C library functions, it shouldn't result in any 
> linker
> errors (even if, IIRC, deemed UB by the C spec).
> 
> --
> Pedro


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112319): https://edk2.groups.io/g/devel/message/112319
Mute This Topic: https://groups.io/mt/103110792/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-test v2 2/4] Rename files in HowToBuild to avoid spaces in filenames

[G Edhaya Chandran]

Thank you, Rebecca.
However the other reviewers too felt that your naming convention was more apt.
So we will take it as it is. No need of any changes.

With Warm Regards,
Edhay


> -Original Message-
> From: Rebecca Cran 
> Sent: Monday, December 11, 2023 9:38 PM
> To: G Edhaya Chandran ; devel@edk2.groups.io
> Subject: Re: [edk2-devel] [PATCH edk2-test v2 2/4] Rename files in HowToBuild
> to avoid spaces in filenames
>
> On 11/29/2023 1:06 AM, G Edhaya Chandran wrote:
> > Hi Rebecca,
> > Thank you for these updates.
> > Just a matter of style, but can we do HowToBuild*SCT*.txt instead of
> > HowToBuild*Sct*.txt?
>
> Sure! I can make that change just before I push the series.
>
>
> --
>
> Rebecca Cran

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112318): https://edk2.groups.io/g/devel/message/112318
Mute This Topic: https://groups.io/mt/102513314/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] CloudHv: Add CI for CloudHv on AArch64

[Laszlo Ersek]

On 11/23/23 04:22, Jianyong Wu wrote:
> Add the long lost CI for CloudHv on AArch64.
> As CloudHv CI works nearly the same way with other VMMs like KvmTool,
> thus we can easily create its CI configuration based on KvmTool.
> 
> Reviewed-by: Laszlo Ersek 
> Signed-off-by: Jianyong Wu 
> ---
>  .../PlatformCI/.azurepipelines/Ubuntu-GCC5.yml  | 13 +
>  .../PlatformCI/{KvmToolBuild.py => CloudHvBuild.py} |  4 ++--
>  2 files changed, 15 insertions(+), 2 deletions(-)
>  copy ArmVirtPkg/PlatformCI/{KvmToolBuild.py => CloudHvBuild.py} (89%)
> 
> diff --git a/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml 
> b/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
> index d1772a65fc..ab8a2db530 100644
> --- a/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
> +++ b/ArmVirtPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
> @@ -140,6 +140,19 @@ jobs:
>  Build.Target: "RELEASE"
>  Run: false
>  
> +  CLOUDHV_AARCH64_DEBUG:
> +Build.File: "$(package)/PlatformCI/CloudHvBuild.py"
> +Build.Arch: "AARCH64"
> +Build.Flags: ""
> +Build.Target: "DEBUG"
> +Run: false
> +  CLOUDHV_AARCH64_RELEASE:
> +Build.File: "$(package)/PlatformCI/CloudHvBuild.py"
> +Build.Arch: "AARCH64"
> +Build.Flags: ""
> +Build.Target: "RELEASE"
> +Run: false
> +
>  workspace:
>clean: all
>  
> diff --git a/ArmVirtPkg/PlatformCI/KvmToolBuild.py 
> b/ArmVirtPkg/PlatformCI/CloudHvBuild.py
> similarity index 89%
> copy from ArmVirtPkg/PlatformCI/KvmToolBuild.py
> copy to ArmVirtPkg/PlatformCI/CloudHvBuild.py
> index 4d02dba124..06ada39886 100644
> --- a/ArmVirtPkg/PlatformCI/KvmToolBuild.py
> +++ b/ArmVirtPkg/PlatformCI/CloudHvBuild.py
> @@ -19,13 +19,13 @@ class CommonPlatform():
>  for the different parts of stuart
>  '''
>  PackagesSupported = ("ArmVirtPkg",)
> -ArchSupported = ("AARCH64", "ARM")
> +ArchSupported = ("AARCH64")

Right, and this one change is new in version 2 of the patch.

My R-b stands.

I'm picking this up now.

Laszlo

>  TargetsSupported = ("DEBUG", "RELEASE")
>  Scopes = ('armvirt', 'edk2-build')
>  WorkspaceRoot = os.path.realpath(os.path.join(
>  os.path.dirname(os.path.abspath(__file__)), "..", ".."))
>  
> -DscName = os.path.join("ArmVirtPkg", "ArmVirtKvmTool.dsc")
> +DscName = os.path.join("ArmVirtPkg", "ArmVirtCloudHv.dsc")
>  FvQemuArg = "" # ignored
>  
>  import PlatformBuildLib



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

Re: [edk2-devel] [PATCH] BaseTools/tools_def: Disable unneeded-internal-declaration warning in CLANGPDB

[Laszlo Ersek]

On 12/11/23 16:18, Mike Beaton wrote:
> I believe this would be logically wrong, as the other versions still
> wouldn't compile if you changed the relevant debug Pcds. (Which are
> logically independent of the compile and link options - e.g. what if for
> some reason you wanted to single step with the Debug Pcds set to
> disabled, in a NOOPT build?)

I don't think that use case exists in practice.

Anyway, my suggestion is based on prior art: I *think* we ask gcc to
whine about unused local variables in RELEASE builds only, too. See
commits 20d00edf21d2 ("BaseTools/GCC: set -Wno-unused-but-set-variables
only on RELEASE builds", 2016-03-25) and 8b6366f87584 ("BaseTools/GCC:
set -Wno-unused-const-variable on RELEASE builds", 2017-09-08).

... TBH I don't understand the current state of
"-Wno-unused-but-set-variables" and "-Wno-unused-const-variable" between
X64 and AARCH64, considering the DEBUG target. Today,
DEBUG_GCC5_AARCH64_CC_FLAGS disables these warnings, but
DEBUG_GCC5_X64_CC_FLAGS doesn't, even though *both* macros specify
-flto. Compare commit 06c8a34cc4bc ("BaseTool/tools_def GCC5: enable
optimization for ARM/AARCH64 DEBUG builds", 2017-12-08) -- I don't
understand why "-flto" had to be accompanied by
"-Wno-unused-but-set-variable -Wno-unused-const-variable" in that commit.

In brief, IA32 and X64 prior art supports my suggestion to shut up the
warning only for RELEASE (for CLANGPDB too), but ARM/AARCH64 prior art
contradicts that proposal. IOW, prior art is inconsistent per se... I
don't understand.

Laszlo

> On Mon, 11 Dec 2023, 15:00 Laszlo Ersek,  > wrote:
> 
> On 12/10/23 11:18, Mike Beaton wrote:
> > From: Mike Beaton mailto:mjsbea...@gmail.com>>
> >
> > This warning was already disabled in CLANGDWARF by commit
> > d3225577123767fd09c91201d27e9c91663ae132.
> >
> > gcc can distinguish between optimised-away variable usage (as  can
> occur in
> > valid debug code) and genuinely unused variables, and only
> complains about
> > the latter. clang cannot, and therefore this warning ends up
> complaining
> > about valid debug code under clang.
> >
> > Since EDK-II code is in general going to be compiled by gcc as
> well as clang
> > then disabling this warning in clang does not amount to entirely
> removing
> > potentially valid warnings about genuinely unused variables.
> >
> > Signed-off-by: Mike Beaton  >
> > ---
> >  BaseTools/Conf/tools_def.template | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/BaseTools/Conf/tools_def.template
> b/BaseTools/Conf/tools_def.template
> > index c34ecfd557..48cf45245f 100755
> > --- a/BaseTools/Conf/tools_def.template
> > +++ b/BaseTools/Conf/tools_def.template
> > @@ -1754,7 +1754,7 @@ DEFINE CLANGPDB_X64_PREFIX           =
> ENV(CLANG_BIN)
> >  DEFINE CLANGPDB_IA32_TARGET          = -target
> i686-unknown-windows-gnu
> >  DEFINE CLANGPDB_X64_TARGET           = -target
> x86_64-unknown-windows-gnu
> > 
> > -DEFINE CLANGPDB_WARNING_OVERRIDES    = -Wno-parentheses-equality
> -Wno-tautological-compare
> -Wno-tautological-constant-out-of-range-compare -Wno-empty-body
> -Wno-unused-const-variable -Wno-varargs -Wno-unknown-warning-option
> -Wno-unused-but-set-variable -Wno-unused-const-variable
> -Wno-unaligned-access -Wno-microsoft-enum-forward-reference
> > +DEFINE CLANGPDB_WARNING_OVERRIDES    = -Wno-parentheses-equality
> -Wno-tautological-compare
> -Wno-tautological-constant-out-of-range-compare -Wno-empty-body
> -Wno-unused-const-variable -Wno-varargs -Wno-unknown-warning-option
> -Wno-unused-but-set-variable -Wno-unused-const-variable
> -Wno-unaligned-access -Wno-unneeded-internal-declaration
> -Wno-microsoft-enum-forward-reference
> >  DEFINE CLANGPDB_ALL_CC_FLAGS         = DEF(GCC48_ALL_CC_FLAGS)
> DEF(CLANGPDB_WARNING_OVERRIDES) -fno-stack-protector -funsigned-char
> -ftrap-function=undefined_behavior_has_been_optimized_away_by_clang
> -Wno-address -Wno-shift-negative-value -Wno-unknown-pragmas
> -Wno-incompatible-library-redeclaration -Wno-null-dereference
> -mno-implicit-float -mms-bitfields -mno-stack-arg-probe -nostdlib
> -nostdlibinc -fseh-exceptions
> > 
> >  ###
> 
> AFAICT, CLANGPDB_WARNING_OVERRIDES gets included in
> CLANGPDB_ALL_CC_FLAGS, which in turn gets included in all three of
> DEBUG, RELEASE and NOOPT build target flags.
> 
> The original report was "RELEASE CLANGPDB OVMF currently does not
> compile".
> 
> Can we use "-Wno-unneeded-internal-declaration" with RELEASE builds
> only?
> 
> Thanks,
> Laszlo
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112316): https://edk2.groups.io/g/devel/message/

Re: [edk2-devel] [PATCH edk2-test v2 2/4] Rename files in HowToBuild to avoid spaces in filenames

[Rebecca Cran]

On 11/29/2023 1:06 AM, G Edhaya Chandran wrote:

Hi Rebecca,
Thank you for these updates.
Just a matter of style, but can we do HowToBuild*SCT*.txt instead of 
HowToBuild*Sct*.txt? 


Sure! I can make that change just before I push the series.


--

Rebecca Cran



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

Re: [edk2-devel] [PATCH] MdePkg/BaseFdtLib: Rename standard functions

[Pedro Falcato]

On Mon, Dec 11, 2023 at 3:40 PM Jeff Brasen via groups.io
 wrote:
>

Jeff,

You're missing CC's on this patch. Also, you should probably send the
3 patches in a single series, since they're all related.

> Rename the standard functions in the LibFdtSupport to remove conflicts
> with other libraries that define them.

This is a funny problem. What error were you seeing? As far as I can
tell, you can totally define your local C library functions, it
shouldn't result in any linker errors (even if, IIRC, deemed UB by the
C spec).

--
Pedro


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

Re: [edk2-devel] [PATCH v9 4/5] MdePkg: Utilize Cache Management Operations Implementation For RISC-V

[Pedro Falcato]

On Mon, Dec 4, 2023 at 8:30 AM Dhaval Sharma  wrote:
>
> Use newly defined cache management operations for RISC-V where possible
> It builds up on the support added for RISC-V cache management
> instructions in BaseLib.
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Laszlo Ersek 
>
> Signed-off-by: Dhaval Sharma 
> Acked-by: Laszlo Ersek 
> ---
>
> Notes:
> V9:
> - Fixed an issue with Instruction cache invalidation. Use fence.i
>   instruction as CMO does not support i-cache operations.
> V8:
> - Added note to convert PCD into RISC-V feature bitmap pointer
> - Modified function names to be more explicit about cache ops
> - Added RB tag
> V7:
> - Added PcdLib
> - Restructure DEBUG message based on feedback on V6
> - Make naming consistent to CMO, remove all CBO references
> - Add ASSERT for not supported functions instead of plain debug message
> - Added RB tag
> V6:
> - Utilize cache management instructions if HW supports it
>   This patch is part of restructuring on top of v5
>
>  MdePkg/MdePkg.dec  |   8 +
>  MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf |   5 +
>  MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c| 173 
> 
>  MdePkg/MdePkg.uni  |   4 +
>  4 files changed, 160 insertions(+), 30 deletions(-)
>
> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> index ac54338089e8..fa92673ff633 100644
> --- a/MdePkg/MdePkg.dec
> +++ b/MdePkg/MdePkg.dec
> @@ -2399,6 +2399,14 @@ [PcdsFixedAtBuild.AARCH64, 
> PcdsPatchableInModule.AARCH64]
># @Prompt CPU Rng algorithm's GUID.
>
> gEfiMdePkgTokenSpaceGuid.PcdCpuRngSupportedAlgorithm|{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}|VOID*|0x0037
>
> +[PcdsFixedAtBuild.RISCV64, PcdsPatchableInModule.RISCV64]
> +  #
> +  # Configurability to override RISC-V CPU Features
> +  # BIT 0 = Cache Management Operations. This bit is relevant only if
> +  # previous stage has feature enabled and user wants to disable it.
> +  #
> +  
> gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0x|UINT64|0x69
> +
>  [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
>## This value is used to set the base address of PCI express hierarchy.
># @Prompt PCI Express Base Address.
> diff --git 
> a/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf 
> b/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
> index 6fd9cbe5f6c9..601a38d6c109 100644
> --- a/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
> +++ b/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
> @@ -56,3 +56,8 @@ [LibraryClasses]
>BaseLib
>DebugLib
>
> +[LibraryClasses.RISCV64]
> +  PcdLib
> +
> +[Pcd.RISCV64]
> +  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride  ## CONSUMES
> diff --git a/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c 
> b/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
> index ac2a3c23a249..cacc38eff4f4 100644
> --- a/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
> +++ b/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
> @@ -2,6 +2,7 @@
>RISC-V specific functionality for cache.
>
>Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights 
> reserved.
> +  Copyright (c) 2023, Rivos Inc. All rights reserved.
>
>SPDX-License-Identifier: BSD-2-Clause-Patent
>  **/
> @@ -9,10 +10,117 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +//
> +// TODO: Grab cache block size and make Cache Management Operation
> +// enabling decision based on RISC-V CPU HOB in
> +// future when it is available and convert PcdRiscVFeatureOverride
> +// PCD to a pointer that contains pointer to bitmap structure
> +// which can be operated more elegantly.
> +//
> +#define RISCV_CACHE_BLOCK_SIZE 64
> +#define RISCV_CPU_FEATURE_CMO_BITMASK  0x1
> +
> +typedef enum {
> +  CacheOpClean,
> +  CacheOpFlush,
> +  CacheOpInvld,
> +} CACHE_OP;
> +
> +/**
> +Verify CBOs are supported by this HW
> +TODO: Use RISC-V CPU HOB once available.
> +
> +**/
> +STATIC
> +BOOLEAN
> +RiscVIsCMOEnabled (
> +  VOID
> +  )
> +{
> +  // If CMO is disabled in HW, skip Override check
> +  // Otherwise this PCD can override settings
> +  return ((PcdGet64 (PcdRiscVFeatureOverride) & 
> RISCV_CPU_FEATURE_CMO_BITMASK) != 0);
> +}
> +
> +/**
> +  Performs required opeartion on cache lines in the cache coherency domain
> +  of the calling CPU. If Address is not aligned on a cache line boundary,
> +  then entire cache line containing Address is operated. If Address + Length
> +  is not aligned on a cache line boundary, then the entire cache line
> +  containing Address + Length -1 is operated.
> +  If Length is greater than (MAX_ADDRESS - Address + 1), then ASSERT().
> +  @param  Address The base address of t

[edk2-devel] [PATCH] EmbeddedPkg/PrePiMemoryAllocationLib: Add ReallocatePool

[Jeff Brasen via groups.io]

Add implementation of ReallocatePool which is defined in the
MemoryAllocationLib header file to allow components to not
need special handling for PrePi module types.

Signed-off-by: Jeff Brasen 
---
 .../MemoryAllocationLib.c | 57 +++
 1 file changed, 57 insertions(+)

diff --git a/EmbeddedPkg/Library/PrePiMemoryAllocationLib/MemoryAllocationLib.c 
b/EmbeddedPkg/Library/PrePiMemoryAllocationLib/MemoryAllocationLib.c
index 08a0add340..39fbe243dd 100644
--- a/EmbeddedPkg/Library/PrePiMemoryAllocationLib/MemoryAllocationLib.c
+++ b/EmbeddedPkg/Library/PrePiMemoryAllocationLib/MemoryAllocationLib.c
@@ -269,3 +269,60 @@ FreePool (
 {
   // Not implemented yet
 }
+
+/**
+  Reallocates a buffer of type EfiBootServicesData.
+
+  Allocates and zeros the number bytes specified by NewSize from memory of type
+  EfiBootServicesData.  If OldBuffer is not NULL, then the smaller of OldSize 
and
+  NewSize bytes are copied from OldBuffer to the newly allocated buffer, and
+  OldBuffer is freed.  A pointer to the newly allocated buffer is returned.
+  If NewSize is 0, then a valid buffer of 0 size is  returned.  If there is not
+  enough memory remaining to satisfy the request, then NULL is returned.
+
+  If the allocation of the new buffer is successful and the smaller of NewSize 
and OldSize
+  is greater than (MAX_ADDRESS - OldBuffer + 1), then ASSERT().
+
+  @param  OldSizeThe size, in bytes, of OldBuffer.
+  @param  NewSizeThe size, in bytes, of the buffer to reallocate.
+  @param  OldBuffer  The buffer to copy to the allocated buffer.  This is 
an optional
+ parameter that may be NULL.
+
+  @return A pointer to the allocated buffer or NULL if allocation fails.
+
+**/
+VOID *
+EFIAPI
+ReallocatePool (
+  IN UINTN  OldSize,
+  IN UINTN  NewSize,
+  IN VOID   *OldBuffer  OPTIONAL
+  )
+{
+  VOID  *NewBuffer;
+
+  // Validate the OldBuffer is HobAllocated.
+  DEBUG_CODE_BEGIN ();
+  EFI_HOB_HANDOFF_INFO_TABLE  *HandOffHob;
+
+  if (OldBuffer != NULL) {
+HandOffHob = GetHobList ();
+ASSERT (((EFI_PHYSICAL_ADDRESS)OldBuffer >= HandOffHob->EfiMemoryBottom));
+ASSERT (((EFI_PHYSICAL_ADDRESS)(OldBuffer + OldSize) <= 
HandOffHob->EfiFreeMemoryBottom));
+  }
+
+  DEBUG_CODE_END ();
+
+  // If new buffer would be smaller just return old buffer as FreePool isn't 
supported.
+  if ((OldBuffer != NULL) && (OldSize >= NewSize)) {
+return OldBuffer;
+  }
+
+  NewBuffer = AllocateZeroPool (NewSize);
+  if ((NewBuffer != NULL) && (OldBuffer != NULL)) {
+CopyMem (NewBuffer, OldBuffer, MIN (OldSize, NewSize));
+FreePool (OldBuffer);
+  }
+
+  return NewBuffer;
+}
-- 
2.34.1



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

[edk2-devel] [PATCH] EmbeddedPkg: Add DtPlatformLoaderLib gmock support

[Jeff Brasen via groups.io]

Add Google Mock Library for DtPlatformLoaderDtbLib

Signed-off-by: Jeff Brasen 
---
 EmbeddedPkg/EmbeddedPkg.dec   |  1 +
 .../Library/MockDtPlatformDtbLoaderLib.h  | 31 +++
 .../MockDtPlatformDtbLoaderLib.cpp| 13 
 .../MockDtPlatformDtbLoaderLib.inf| 29 +
 4 files changed, 74 insertions(+)
 create mode 100644 
EmbeddedPkg/Test/Mock/Include/GoogleTest/Library/MockDtPlatformDtbLoaderLib.h
 create mode 100644 
EmbeddedPkg/Test/Mock/Library/GoogleTest/MockDtPlatformDtbLoaderLib/MockDtPlatformDtbLoaderLib.cpp
 create mode 100644 
EmbeddedPkg/Test/Mock/Library/GoogleTest/MockDtPlatformDtbLoaderLib/MockDtPlatformDtbLoaderLib.inf

diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec
index 94dc3c9b76..b4834e8b4f 100644
--- a/EmbeddedPkg/EmbeddedPkg.dec
+++ b/EmbeddedPkg/EmbeddedPkg.dec
@@ -28,6 +28,7 @@
 

 [Includes.common]
   Include# Root include for the package
+  Test/Mock/Include
 
 [LibraryClasses.common]
   PrePiLib|Include/Library/PrePiLib.h
diff --git 
a/EmbeddedPkg/Test/Mock/Include/GoogleTest/Library/MockDtPlatformDtbLoaderLib.h 
b/EmbeddedPkg/Test/Mock/Include/GoogleTest/Library/MockDtPlatformDtbLoaderLib.h
new file mode 100644
index 00..23dab21668
--- /dev/null
+++ 
b/EmbeddedPkg/Test/Mock/Include/GoogleTest/Library/MockDtPlatformDtbLoaderLib.h
@@ -0,0 +1,31 @@
+/** @file
+  Google Test mocks for DtPlatformDtbLoaderLib
+
+  Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+  Copyright (c) 2023, Intel Corporation. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef MOCK_DT_PLATFORM_DTB_LOADER_LIB_H_
+#define MOCK_DT_PLATFORM_DTB_LOADER_LIB_H_
+
+#include 
+#include 
+extern "C" {
+#include 
+#include 
+#include 
+}
+
+struct MockDtPlatformDtbLoaderLib {
+  MOCK_INTERFACE_DECLARATION (MockDtPlatformDtbLoaderLib);
+
+  MOCK_FUNCTION_DECLARATION (
+EFI_STATUS,
+DtPlatformLoadDtb,
+(OUT   VOID   **Dtb,
+ OUT   UINTN  *DtbSize)
+);
+};
+
+#endif
diff --git 
a/EmbeddedPkg/Test/Mock/Library/GoogleTest/MockDtPlatformDtbLoaderLib/MockDtPlatformDtbLoaderLib.cpp
 
b/EmbeddedPkg/Test/Mock/Library/GoogleTest/MockDtPlatformDtbLoaderLib/MockDtPlatformDtbLoaderLib.cpp
new file mode 100644
index 00..a5db68e59a
--- /dev/null
+++ 
b/EmbeddedPkg/Test/Mock/Library/GoogleTest/MockDtPlatformDtbLoaderLib/MockDtPlatformDtbLoaderLib.cpp
@@ -0,0 +1,13 @@
+/** @file
+  Google Test mocks for MockDtPlatformDtbLoaderLib
+
+  Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+  Copyright (c) 2023, Intel Corporation. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include 
+
+MOCK_INTERFACE_DEFINITION (MockDtPlatformDtbLoaderLib);
+
+MOCK_FUNCTION_DEFINITION (MockDtPlatformDtbLoaderLib, DtPlatformLoadDtb, 2, 
EFIAPI);
diff --git 
a/EmbeddedPkg/Test/Mock/Library/GoogleTest/MockDtPlatformDtbLoaderLib/MockDtPlatformDtbLoaderLib.inf
 
b/EmbeddedPkg/Test/Mock/Library/GoogleTest/MockDtPlatformDtbLoaderLib/MockDtPlatformDtbLoaderLib.inf
new file mode 100644
index 00..9618efd864
--- /dev/null
+++ 
b/EmbeddedPkg/Test/Mock/Library/GoogleTest/MockDtPlatformDtbLoaderLib/MockDtPlatformDtbLoaderLib.inf
@@ -0,0 +1,29 @@
+## @file
+# Google Test mocks for MockDtPlatformDtbLoaderLib
+#
+# Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+# Copyright (c) 2023, Intel Corporation. All rights reserved.
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = MockDtPlatformDtbLoaderLib
+  FILE_GUID  = 34c05e81-3c56-4c78-b4b7-a39be19163a4
+  MODULE_TYPE= HOST_APPLICATION
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = DtPlatformDtbLoaderLib
+
+[Sources]
+MockDtPlatformDtbLoaderLib.cpp
+
+[Packages]
+  EmbeddedPkg/EmbeddedPkg.dec
+  MdePkg/MdePkg.dec
+  UnitTestFrameworkPkg/UnitTestFrameworkPkg.dec
+
+[LibraryClasses]
+  GoogleTestLib
+
+[BuildOptions]
+  MSFT:*_*_*_CC_FLAGS = /EHsc
-- 
2.34.1



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

[edk2-devel] [PATCH] MdePkg: Add FdtLib gmock support

[Jeff Brasen via groups.io]

Add Google Mock Library for FdtLib

Signed-off-by: Jeff Brasen 
---
 .../Include/GoogleTest/Library/MockFdtLib.h   | 165 ++
 .../GoogleTest/MockFdtLib/MockFdtLib.cpp  |  34 
 .../GoogleTest/MockFdtLib/MockFdtLib.inf  |  28 +++
 3 files changed, 227 insertions(+)
 create mode 100644 MdePkg/Test/Mock/Include/GoogleTest/Library/MockFdtLib.h
 create mode 100644 
MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.cpp
 create mode 100644 
MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.inf

diff --git a/MdePkg/Test/Mock/Include/GoogleTest/Library/MockFdtLib.h 
b/MdePkg/Test/Mock/Include/GoogleTest/Library/MockFdtLib.h
new file mode 100644
index 00..c0aeaa25c0
--- /dev/null
+++ b/MdePkg/Test/Mock/Include/GoogleTest/Library/MockFdtLib.h
@@ -0,0 +1,165 @@
+/** @file
+  Google Test mocks for FdtLib
+
+  Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+  Copyright (c) 2023, Intel Corporation. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef MOCK_FDT_LIB_H_
+#define MOCK_FDT_LIB_H_
+
+#include 
+#include 
+extern "C" {
+#include 
+#include 
+#include 
+}
+
+struct MockFdtLib {
+  MOCK_INTERFACE_DECLARATION (MockFdtLib);
+
+  MOCK_FUNCTION_DECLARATION (
+UINT16,
+Fdt16ToCpu,
+(IN UINT16 Value)
+);
+  MOCK_FUNCTION_DECLARATION (
+UINT16,
+CpuToFdt16,
+(IN UINT16 Value)
+);
+  MOCK_FUNCTION_DECLARATION (
+UINT32,
+Fdt32ToCpu,
+(IN UINT32 Value)
+);
+  MOCK_FUNCTION_DECLARATION (
+UINT32,
+CpuToFdt32,
+(IN UINT32 Value)
+);
+  MOCK_FUNCTION_DECLARATION (
+UINT64,
+Fdt64ToCpu,
+(IN UINT64 Value)
+);
+  MOCK_FUNCTION_DECLARATION (
+UINT64,
+CpuToFdt64,
+(IN UINT64 Value)
+);
+  MOCK_FUNCTION_DECLARATION (
+INT32,
+FdtCheckHeader,
+(IN CONST VOID  *Fdt)
+);
+  MOCK_FUNCTION_DECLARATION (
+INT32,
+FdtCreateEmptyTree,
+(IN VOID*Buffer,
+ IN UINT32  BufferSize)
+);
+  MOCK_FUNCTION_DECLARATION (
+INT32,
+FdtNextNode,
+(IN CONST VOID  *Fdt,
+ IN INT32   Offset,
+ IN INT32   *Depth)
+);
+  MOCK_FUNCTION_DECLARATION (
+INT32,
+FdtFirstSubnode,
+(IN CONST VOID  *Fdt,
+ IN INT32   Offset)
+);
+  MOCK_FUNCTION_DECLARATION (
+INT32,
+FdtNextSubnode,
+(IN CONST VOID  *Fdt,
+ IN INT32   Offset)
+);
+  MOCK_FUNCTION_DECLARATION (
+INT32,
+FdtSubnodeOffsetNameLen,
+(IN CONST VOID   *Fdt,
+ IN INT32ParentOffset,
+ IN CONST CHAR8  *Name,
+ IN INT32NameLength)
+);
+  MOCK_FUNCTION_DECLARATION (
+INT32,
+FdtNodeOffsetByPropValue,
+(IN CONST VOID   *Fdt,
+ IN INT32StartOffset,
+ IN CONST CHAR8  *PropertyName,
+ IN CONST VOID   *PropertyValue,
+ IN INT32PropertyLength)
+);
+  MOCK_FUNCTION_DECLARATION (
+CONST FDT_PROPERTY *,
+FdtGetProperty,
+(IN CONST VOID   *Fdt,
+ IN INT32NodeOffset,
+ IN CONST CHAR8  *Name,
+ IN INT32*Length)
+);
+  MOCK_FUNCTION_DECLARATION (
+INT32,
+FdtFirstPropertyOffset,
+(IN CONST VOID  *Fdt,
+ IN INT32   NodeOffset)
+);
+  MOCK_FUNCTION_DECLARATION (
+INT32,
+FdtNextPropertyOffset,
+(IN CONST VOID  *Fdt,
+ IN INT32   NodeOffset)
+);
+  MOCK_FUNCTION_DECLARATION (
+CONST FDT_PROPERTY *,
+FdtGetPropertyByOffset,
+(IN CONST VOID  *Fdt,
+ IN INT32   Offset,
+ IN INT32   *Length)
+);
+  MOCK_FUNCTION_DECLARATION (
+CONST CHAR8 *,
+FdtGetString,
+(IN CONST VOID  *Fdt,
+ IN INT32   StrOffset,
+ IN INT32   *LengthOPTIONAL)
+);
+  MOCK_FUNCTION_DECLARATION (
+INT32,
+FdtAddSubnode,
+(IN VOID *Fdt,
+ IN INT32ParentOffset,
+ IN CONST CHAR8  *Name)
+);
+  MOCK_FUNCTION_DECLARATION (
+INT32,
+FdtSetProp,
+(IN VOID *Fdt,
+ IN INT32NodeOffset,
+ IN CONST CHAR8  *Name,
+ IN CONST VOID   *Value,
+ IN UINT32   Length)
+);
+  MOCK_FUNCTION_DECLARATION (
+CONST CHAR8 *,
+FdtGetName,
+(IN VOID*Fdt,
+ IN INT32   NodeOffset,
+ IN UINT32  *Length)
+);
+  MOCK_FUNCTION_DECLARATION (
+INT32,
+FdtNodeDepth,
+(IN CONST VOID  *Fdt,
+ IN INT32   NodeOffset)
+);
+};
+
+#endif
diff --git a/MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.cpp 
b/MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.cpp
new file mode 100644
index 00..a955780d23
--- /dev/null
+++ b/MdePkg/Test/Mock/Library/GoogleTest/MockFdtLib/MockFdtLib.cpp
@@ -0,0 +1,34 @@
+/** @file
+  Google Test mocks for FdtLib
+
+  Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+  Copyright (c) 2023, Intel Corporation. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include 
+
+MOCK_INTERFACE_DEFINITI

Re: [edk2-devel] [PATCH v9 4/5] MdePkg: Utilize Cache Management Operations Implementation For RISC-V

[Pedro Falcato]

On Mon, Dec 11, 2023 at 3:20 PM Sunil V L  wrote:
>
> On Mon, Dec 11, 2023 at 03:09:19PM +, Pedro Falcato wrote:
> > On Mon, Dec 11, 2023 at 1:12 PM Sunil V L  wrote:
> > >
> > > On Sun, Dec 10, 2023 at 07:51:12PM +0530, Dhaval Sharma wrote:
> > [...]
> > > > nit: Can we pick a log style here? Like : 
> > > > In this case, "CacheOpCacheRange: Performing ...". It's just prettier
> > > > and more greppable.
> > > > My interpretation of this was removing __func__ and instead having some
> > > > relevant text would make it more searchable.
> > > > And it kind of did make sense to me. I know many places __func__ is used
> > > > but this is just a perspective.
> > > >
> > > I think the comment meant to follow a standard logging format since
> > > there was no ":" and a space in original change. I prefer __func__ over
> > > this so that we don't need to update multiple lines in case function
> > > name gets changed.
> >
> > I definitely meant that __func__ should not be used for this as well.
> > You can't really search for an error message if you're doing
> > gratuitous printf formatting for no reason.
> > Linux even has a policy where user-facing strings (i.e logs) cannot
> > get broken up, even if you run out of line width.
> >
> Thanks Pedro. Do you mean __func__ should not be used at all in any
> of logging? Or is there a case where it is allowed vs not allowed?

My point is that we should aid people trying to do
git grep 

FWIW, Linux itself uses __func__ a bunch for logs. But I personally
dislike it, for the reasons stated above.

-- 
Pedro


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

[edk2-devel] [PATCH] MdePkg/BaseFdtLib: Rename standard functions

[Jeff Brasen via groups.io]

Rename the standard functions in the LibFdtSupport to remove conflicts
with other libraries that define them.

Signed-off-by: Jeff Brasen 
---
 MdePkg/Library/BaseFdtLib/LibFdtSupport.h | 16 +++
 MdePkg/Library/BaseFdtLib/LibFdtWrapper.c | 25 ++-
 2 files changed, 18 insertions(+), 23 deletions(-)

diff --git a/MdePkg/Library/BaseFdtLib/LibFdtSupport.h 
b/MdePkg/Library/BaseFdtLib/LibFdtSupport.h
index 393019324b..47beac9fac 100644
--- a/MdePkg/Library/BaseFdtLib/LibFdtSupport.h
+++ b/MdePkg/Library/BaseFdtLib/LibFdtSupport.h
@@ -68,6 +68,12 @@ strrchr(
   int
   );
 
+char *
+fdt_strrchr(
+  const char *,
+  int
+  );
+
 unsigned long
 strtoul (
   const char *,
@@ -75,6 +81,13 @@ strtoul (
   int
   );
 
+unsigned long
+fdt_strtoul (
+  const char *,
+  char **,
+  int
+  );
+
 char *
 strcpy (
   char*strDest,
@@ -93,7 +106,10 @@ strcpy (
 #define strnlen(str, count) (size_t)(AsciiStrnLenS(str, count))
 #define strncpy(strDest, strSource, count)  AsciiStrnCpyS(strDest, 
MAX_STRING_SIZE, strSource, (UINTN)count)
 #define strcat(strDest, strSource)  AsciiStrCatS(strDest, 
MAX_STRING_SIZE, strSource)
+#define strchr(str, ch) ScanMem8(str, AsciiStrSize (str), 
(UINT8)ch)
 #define strcmp(string1, string2, count) (int)(AsciiStrCmp(string1, 
string2))
 #define strncmp(string1, string2, count)(int)(AsciiStrnCmp(string1, 
string2, (UINTN)(count)))
+#define strrchr(str, ch)fdt_strrchr(str, ch)
+#define strtoul(ptr, end_ptr, base) fdt_strtoul(ptr, end_ptr, base)
 
 #endif /* FDT_LIB_SUPPORT_H_ */
diff --git a/MdePkg/Library/BaseFdtLib/LibFdtWrapper.c 
b/MdePkg/Library/BaseFdtLib/LibFdtWrapper.c
index ef6452914f..1a4cd573fd 100644
--- a/MdePkg/Library/BaseFdtLib/LibFdtWrapper.c
+++ b/MdePkg/Library/BaseFdtLib/LibFdtWrapper.c
@@ -18,28 +18,7 @@
 // so the code gets a bit clunky to handle that case specifically.
 
 char *
-strchr (
-  const char  *Str,
-  int Char
-  )
-{
-  char  *S;
-
-  S = (char *)Str;
-
-  for ( ; ; S++) {
-if (*S == Char) {
-  return S;
-}
-
-if (*S == '\0') {
-  return NULL;
-}
-  }
-}
-
-char *
-strrchr (
+fdt_strrchr (
   const char  *Str,
   int Char
   )
@@ -71,7 +50,7 @@ __isspace (
 }
 
 unsigned long
-strtoul (
+fdt_strtoul (
   const char  *Nptr,
   char**EndPtr,
   int Base
-- 
2.34.1



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

Re: [edk2-devel] [PATCH v9 4/5] MdePkg: Utilize Cache Management Operations Implementation For RISC-V

[Sunil V L]

On Mon, Dec 11, 2023 at 03:09:19PM +, Pedro Falcato wrote:
> On Mon, Dec 11, 2023 at 1:12 PM Sunil V L  wrote:
> >
> > On Sun, Dec 10, 2023 at 07:51:12PM +0530, Dhaval Sharma wrote:
> [...]
> > > nit: Can we pick a log style here? Like : 
> > > In this case, "CacheOpCacheRange: Performing ...". It's just prettier
> > > and more greppable.
> > > My interpretation of this was removing __func__ and instead having some
> > > relevant text would make it more searchable.
> > > And it kind of did make sense to me. I know many places __func__ is used
> > > but this is just a perspective.
> > >
> > I think the comment meant to follow a standard logging format since
> > there was no ":" and a space in original change. I prefer __func__ over
> > this so that we don't need to update multiple lines in case function
> > name gets changed.
> 
> I definitely meant that __func__ should not be used for this as well.
> You can't really search for an error message if you're doing
> gratuitous printf formatting for no reason.
> Linux even has a policy where user-facing strings (i.e logs) cannot
> get broken up, even if you run out of line width.
> 
Thanks Pedro. Do you mean __func__ should not be used at all in any
of logging? Or is there a case where it is allowed vs not allowed? 

Thanks,
Sunil


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

Re: [edk2-devel] [PATCH] BaseTools/tools_def: Disable unneeded-internal-declaration warning in CLANGPDB

[Mike Beaton]

I believe this would be logically wrong, as the other versions still
wouldn't compile if you changed the relevant debug Pcds. (Which are
logically independent of the compile and link options - e.g. what if for
some reason you wanted to single step with the Debug Pcds set to disabled,
in a NOOPT build?)




On Mon, 11 Dec 2023, 15:00 Laszlo Ersek,  wrote:

> On 12/10/23 11:18, Mike Beaton wrote:
> > From: Mike Beaton 
> >
> > This warning was already disabled in CLANGDWARF by commit
> > d3225577123767fd09c91201d27e9c91663ae132.
> >
> > gcc can distinguish between optimised-away variable usage (as  can occur
> in
> > valid debug code) and genuinely unused variables, and only complains
> about
> > the latter. clang cannot, and therefore this warning ends up complaining
> > about valid debug code under clang.
> >
> > Since EDK-II code is in general going to be compiled by gcc as well as
> clang
> > then disabling this warning in clang does not amount to entirely removing
> > potentially valid warnings about genuinely unused variables.
> >
> > Signed-off-by: Mike Beaton 
> > ---
> >  BaseTools/Conf/tools_def.template | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/BaseTools/Conf/tools_def.template
> b/BaseTools/Conf/tools_def.template
> > index c34ecfd557..48cf45245f 100755
> > --- a/BaseTools/Conf/tools_def.template
> > +++ b/BaseTools/Conf/tools_def.template
> > @@ -1754,7 +1754,7 @@ DEFINE CLANGPDB_X64_PREFIX   =
> ENV(CLANG_BIN)
> >  DEFINE CLANGPDB_IA32_TARGET  = -target i686-unknown-windows-gnu
> >  DEFINE CLANGPDB_X64_TARGET   = -target
> x86_64-unknown-windows-gnu
> >
> > -DEFINE CLANGPDB_WARNING_OVERRIDES= -Wno-parentheses-equality
> -Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare
> -Wno-empty-body -Wno-unused-const-variable -Wno-varargs
> -Wno-unknown-warning-option -Wno-unused-but-set-variable
> -Wno-unused-const-variable -Wno-unaligned-access
> -Wno-microsoft-enum-forward-reference
> > +DEFINE CLANGPDB_WARNING_OVERRIDES= -Wno-parentheses-equality
> -Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare
> -Wno-empty-body -Wno-unused-const-variable -Wno-varargs
> -Wno-unknown-warning-option -Wno-unused-but-set-variable
> -Wno-unused-const-variable -Wno-unaligned-access
> -Wno-unneeded-internal-declaration -Wno-microsoft-enum-forward-reference
> >  DEFINE CLANGPDB_ALL_CC_FLAGS = DEF(GCC48_ALL_CC_FLAGS)
> DEF(CLANGPDB_WARNING_OVERRIDES) -fno-stack-protector -funsigned-char
> -ftrap-function=undefined_behavior_has_been_optimized_away_by_clang
> -Wno-address -Wno-shift-negative-value -Wno-unknown-pragmas
> -Wno-incompatible-library-redeclaration -Wno-null-dereference
> -mno-implicit-float -mms-bitfields -mno-stack-arg-probe -nostdlib
> -nostdlibinc -fseh-exceptions
> >
> >  ###
>
> AFAICT, CLANGPDB_WARNING_OVERRIDES gets included in
> CLANGPDB_ALL_CC_FLAGS, which in turn gets included in all three of
> DEBUG, RELEASE and NOOPT build target flags.
>
> The original report was "RELEASE CLANGPDB OVMF currently does not compile".
>
> Can we use "-Wno-unneeded-internal-declaration" with RELEASE builds only?
>
> Thanks,
> Laszlo
>
>


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

Re: [edk2-devel] [PATCH v9 4/5] MdePkg: Utilize Cache Management Operations Implementation For RISC-V

[Pedro Falcato]

On Mon, Dec 11, 2023 at 1:12 PM Sunil V L  wrote:
>
> On Sun, Dec 10, 2023 at 07:51:12PM +0530, Dhaval Sharma wrote:
[...]
> > nit: Can we pick a log style here? Like : 
> > In this case, "CacheOpCacheRange: Performing ...". It's just prettier
> > and more greppable.
> > My interpretation of this was removing __func__ and instead having some
> > relevant text would make it more searchable.
> > And it kind of did make sense to me. I know many places __func__ is used
> > but this is just a perspective.
> >
> I think the comment meant to follow a standard logging format since
> there was no ":" and a space in original change. I prefer __func__ over
> this so that we don't need to update multiple lines in case function
> name gets changed.

I definitely meant that __func__ should not be used for this as well.
You can't really search for an error message if you're doing
gratuitous printf formatting for no reason.
Linux even has a policy where user-facing strings (i.e logs) cannot
get broken up, even if you run out of line width.

PS: Dhaval, I gave you a bunch of feedback and you dropped me from
CCs. Please don't do that, I completely lost track of this patch set
:/

-- 
Pedro


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

Re: [edk2-devel] [PATCH] BaseTools/tools_def: Disable unneeded-internal-declaration warning in CLANGPDB

[Laszlo Ersek]

On 12/10/23 11:18, Mike Beaton wrote:
> From: Mike Beaton 
> 
> This warning was already disabled in CLANGDWARF by commit
> d3225577123767fd09c91201d27e9c91663ae132.
> 
> gcc can distinguish between optimised-away variable usage (as  can occur in
> valid debug code) and genuinely unused variables, and only complains about
> the latter. clang cannot, and therefore this warning ends up complaining
> about valid debug code under clang.
> 
> Since EDK-II code is in general going to be compiled by gcc as well as clang
> then disabling this warning in clang does not amount to entirely removing
> potentially valid warnings about genuinely unused variables.
> 
> Signed-off-by: Mike Beaton 
> ---
>  BaseTools/Conf/tools_def.template | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/BaseTools/Conf/tools_def.template 
> b/BaseTools/Conf/tools_def.template
> index c34ecfd557..48cf45245f 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -1754,7 +1754,7 @@ DEFINE CLANGPDB_X64_PREFIX   = ENV(CLANG_BIN)
>  DEFINE CLANGPDB_IA32_TARGET  = -target i686-unknown-windows-gnu
>  DEFINE CLANGPDB_X64_TARGET   = -target x86_64-unknown-windows-gnu
>  
> -DEFINE CLANGPDB_WARNING_OVERRIDES= -Wno-parentheses-equality 
> -Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare 
> -Wno-empty-body -Wno-unused-const-variable -Wno-varargs 
> -Wno-unknown-warning-option -Wno-unused-but-set-variable 
> -Wno-unused-const-variable -Wno-unaligned-access 
> -Wno-microsoft-enum-forward-reference
> +DEFINE CLANGPDB_WARNING_OVERRIDES= -Wno-parentheses-equality 
> -Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare 
> -Wno-empty-body -Wno-unused-const-variable -Wno-varargs 
> -Wno-unknown-warning-option -Wno-unused-but-set-variable 
> -Wno-unused-const-variable -Wno-unaligned-access 
> -Wno-unneeded-internal-declaration -Wno-microsoft-enum-forward-reference
>  DEFINE CLANGPDB_ALL_CC_FLAGS = DEF(GCC48_ALL_CC_FLAGS) 
> DEF(CLANGPDB_WARNING_OVERRIDES) -fno-stack-protector -funsigned-char 
> -ftrap-function=undefined_behavior_has_been_optimized_away_by_clang 
> -Wno-address -Wno-shift-negative-value -Wno-unknown-pragmas 
> -Wno-incompatible-library-redeclaration -Wno-null-dereference 
> -mno-implicit-float -mms-bitfields -mno-stack-arg-probe -nostdlib 
> -nostdlibinc -fseh-exceptions
>  
>  ###

AFAICT, CLANGPDB_WARNING_OVERRIDES gets included in
CLANGPDB_ALL_CC_FLAGS, which in turn gets included in all three of
DEBUG, RELEASE and NOOPT build target flags.

The original report was "RELEASE CLANGPDB OVMF currently does not compile".

Can we use "-Wno-unneeded-internal-declaration" with RELEASE builds only?

Thanks,
Laszlo



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

[edk2-devel] [PATCH V2] RedfishPkg/RedfishDicovery: Remedy Redfish service discovery flow

[Chang, Abner via groups.io]

From: Abner Chang 

Remedy Redfish service discovery flow changes made
in commit 8736b8fd.

The above fix creates the dependency with SMBIOS 42h record,
which has a problem as SMBIOS 42h may not be created when
RedfishDiscovery.Supported() is invoked even all of the
required protocols are ready on the ControllerHandle. We can’t
guarantee SMBIOS 42 structure will be always created before
ConnectController(). USB NIC maybe detected late and it means
PlatformHostInterfaceBmcUsbNicLib can populate SMBIOS 42h
information late as well. Calling to
RedfishServiceGetNetworkInterface with the previous fix may
result in no network interface for BMC-exposed NIC as SMBIOS
42h is not ready yet.This is the first issue.

Second, to skip the network interface when
NetworkInterfaceGetSubnetInfo() returns a failure also has
problem, as the NIC may be configured via RestEx->Configure().
This happens after the Host interface is discovered, as at this
moment we have the sufficient network information to configure
BMC-exposed NIC.

Base on Redfish spec in 31.1.5.2, “EFI Redfish Client may provide
selection UI of network interfaces for Redfish service discovery.",
This means edk2 Redfish client gets all network interfaces
through RedfishServiceGetNetworkInterface and choose the desired
network interface at its discretion for Redfish service.

So the fix here is:
1. In BuildNetworkInterface(), we don’t skip any network
   interface. In RedfishServiceGetNetworkInterface, we don’t
   skip any network interface even the subnet information is not
   retrieved. We will still return all of network interfaces to
   client.
2. In RedfishServiceAcquireService for
   EFI_REDFISH_RISCOVER_HOST_INTERFACE case, we don’t skip any
   network interface even the subnet information is not
   retrieved.

3. Added some more debug information.

Note: The subnet information is used for the scenario the system
is managed by a centralized Redfish service (not on BMC), says
the multiple Redfish computer system instances. As it mentions
in 31.1.5.2, Redfish client they may have to know the subnet
information so they can know the network domain the NIC is
connected. There may have multiple subnets in the corporation
network environment. So the subnet information provides client
an idea when they choose the network interface, so does VLAN ID.

Change-Id: Ibb38ddcd17459ad4b23fcb4fcd8a771a0f63987a
Signed-off-by: Abner Chang 
Cc: Nickle Wang 
Cc: Igor Kulchytskyy 
Cc: Mike Maslenkin 
---
 .../RedfishDiscoverDxe/RedfishDiscoverDxe.c   | 109 +++---
 1 file changed, 39 insertions(+), 70 deletions(-)

diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c 
b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
index 833ae2b969f..06d8d00da7f 100644
--- a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
+++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
@@ -487,43 +487,6 @@ CheckIsIpVersion6 (
   return FALSE;
 }
 
-/**
-  This function returns the  IP type supported by the Host Interface.
-
-  @retval 00h is Unknown
-  01h is Ipv4
-  02h is Ipv6
-
-**/
-STATIC
-UINT8
-GetHiIpProtocolType (
-  VOID
-  )
-{
-  EFI_STATUS Status;
-  REDFISH_OVER_IP_PROTOCOL_DATA  *Data;
-  REDFISH_INTERFACE_DATA *DeviceDescriptor;
-
-  Data = NULL;
-  DeviceDescriptor = NULL;
-  if (mSmbios == NULL) {
-Status = gBS->LocateProtocol (&gEfiSmbiosProtocolGuid, NULL, (VOID 
**)&mSmbios);
-if (EFI_ERROR (Status)) {
-  return REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_UNKNOWN;
-}
-  }
-
-  Status = RedfishGetHostInterfaceProtocolData (mSmbios, &DeviceDescriptor, 
&Data); // Search for SMBIOS type 42h
-  if (!EFI_ERROR (Status) && (Data != NULL) &&
-  (Data->HostIpAssignmentType == RedfishHostIpAssignmentStatic))
-  {
-return Data->HostIpAddressFormat;
-  }
-
-  return REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_UNKNOWN;
-}
-
 /**
   Check if Network Protocol Type matches with SMBIOS Type 42 IP Address Type.
 
@@ -583,7 +546,10 @@ DiscoverRedfishHostInterface (
   }
 
   Status = RedfishGetHostInterfaceProtocolData (mSmbios, &DeviceDescriptor, 
&Data); // Search for SMBIOS type 42h
-  if (!EFI_ERROR (Status) && (Data != NULL) && (DeviceDescriptor != NULL)) {
+  if (EFI_ERROR (Status) || (Data == NULL) || (DeviceDescriptor == NULL)) {
+DEBUG ((DEBUG_ERROR, "%a: RedfishGetHostInterfaceProtocolData is 
failed.\n", __func__));
+return Status;
+  } else {
 // Check IP Type and skip an unnecessary network protocol if does not match
 if (FilterProtocol (Instance->NetworkInterface->NetworkProtocolType, 
Data->HostIpAddressFormat)) {
   return EFI_UNSUPPORTED;
@@ -675,6 +641,9 @@ DiscoverRedfishHostInterface (
   IsHttps = FALSE;
   if (Data->RedfishServiceIpPort == 443) {
 IsHttps = TRUE;
+DEBUG ((DEBUG_MANAGEABILITY, "Redfish service port: 443\n"));
+  } else {
+DEBUG ((DEBUG_MANAGEABILITY, "Redfish service port: 80\n"));
   }
 
  

Re: [edk2-devel] [PATCH v3] ArmVirt: Allow memory attributes protocol to be disabled

[Ard Biesheuvel]

On Mon, 11 Dec 2023 at 15:33, Laszlo Ersek  wrote:
>
> On 12/11/23 11:55, Gerd Hoffmann wrote:
> >> +  //
> >> +  // Work around shim's terminally broken use of the EFI memory attributes
> >> +  // protocol, by uninstalling it if requested on the QEMU command line.
> >> +  //
> >> +  // E.g.,
> >> +  //   -fw_cfg opt/org.tianocore/UninstallMemAttrProtocol,string=y
> >> +  //
> >> +  // This is only needed on the first boot, when fbaa64.efi is being 
> >> invoked to
> >> +  // set the boot order variables. Subsequent boots involving GRUB are not
> >> +  // affected.
> >> +  //
>
> (1) I think this last paragraph of the comment no longer applies; is
> that right? We don't restrict the proto masking to first boot any longer
> (i.e., in v3).
>

Indeed.

> >> +  Uninstall = FixedPcdGetBool (PcdUninstallMemAttrProtocol);
> >> +  QemuFwCfgParseBool ("opt/org.tianocore/UninstallMemAttrProtocol", 
> >> &Uninstall);
> >> +  if (Uninstall) {
> >> +UninstallEfiMemoryAttributesProtocol ();
> >> +  }
> >
> > Can we please have a log message here, for both uninstall and
> > keep-installed cases?
>
> Good idea!
>
> >
> > Otherwise the patch looks good to me.
>
> With those two updates (assuming I'm right about (1)):
>
> Reviewed-by: Laszlo Ersek 
>

Thanks.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112302): https://edk2.groups.io/g/devel/message/112302
Mute This Topic: https://groups.io/mt/103106391/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] ArmVirt: Allow memory attributes protocol to be disabled

[Laszlo Ersek]

On 12/11/23 11:55, Gerd Hoffmann wrote:
>> +  //
>> +  // Work around shim's terminally broken use of the EFI memory attributes
>> +  // protocol, by uninstalling it if requested on the QEMU command line.
>> +  //
>> +  // E.g.,
>> +  //   -fw_cfg opt/org.tianocore/UninstallMemAttrProtocol,string=y
>> +  //
>> +  // This is only needed on the first boot, when fbaa64.efi is being 
>> invoked to
>> +  // set the boot order variables. Subsequent boots involving GRUB are not
>> +  // affected.
>> +  //

(1) I think this last paragraph of the comment no longer applies; is
that right? We don't restrict the proto masking to first boot any longer
(i.e., in v3).

>> +  Uninstall = FixedPcdGetBool (PcdUninstallMemAttrProtocol);
>> +  QemuFwCfgParseBool ("opt/org.tianocore/UninstallMemAttrProtocol", 
>> &Uninstall);
>> +  if (Uninstall) {
>> +UninstallEfiMemoryAttributesProtocol ();
>> +  }
> 
> Can we please have a log message here, for both uninstall and
> keep-installed cases?

Good idea!

> 
> Otherwise the patch looks good to me.

With those two updates (assuming I'm right about (1)):

Reviewed-by: Laszlo Ersek 

Thanks!
Laszlo



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

Re: [edk2-devel] [PATCH v2] ArmVirt: Allow memory attributes protocol to be disabled on first boot

[Laszlo Ersek]

On 12/8/23 16:34, Ard Biesheuvel wrote:
> On Fri, 8 Dec 2023 at 15:34, Laszlo Ersek  wrote:

>>> diff --git a/ArmVirtPkg/ArmVirtPkg.dec b/ArmVirtPkg/ArmVirtPkg.dec
>>> index 0f2d7873279f..c55978f75c19 100644
>>> --- a/ArmVirtPkg/ArmVirtPkg.dec
>>> +++ b/ArmVirtPkg/ArmVirtPkg.dec
>>> @@ -68,3 +68,9 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
>>># Cloud Hypervisor has no other way to pass Rsdp address to the guest 
>>> except use a PCD.
>>>
>>>#
>>>
>>>
>>> gArmVirtTokenSpaceGuid.PcdCloudHvAcpiRsdpBaseAddress|0x0|UINT64|0x0005
>>>
>>> +
>>>
>>> +  ##
>>>
>>> +  # Whether the EFI memory attribus protocol should be uninstalled before
>>>
>>> +  # invoking the OS loader on the first boot. This may be needed to work 
>>> around
>>>
>>> +  # problematic builds of shim that use the protocol incorrectly.
>>>
>>> +  
>>> gArmVirtTokenSpaceGuid.PcdUninstallMemAttrProtocolOnFirstBoot|FALSE|BOOLEAN|0x0006
>>>
>>
>> (1) could be a feature PCD (although it couldn't be patchable-in-module
>> then, and perhaps we don't consider this a "feature")
>>
> 
> Is this a general remark on the similarity between feature PCDs and
> boolean PCDs?

Yes, just a general remark; I generally don't have a surefire handle on
when to use a feature PCD versus a fixed-at-build (and/or
patchable-in-module) BOOLEAN PCD.

>> (4) Why the change from an explicit call from AfterConsole to a
>> constructor? Was AfterConsole too late somehow?
>>
> 
> Yes. Checking for the existence of "BootOrder" needs to occur earlier,
> or it will have been created by the BDS.
> 
>> I think constructors should be the last resort.
>>
> 
> Not disagreeing with that.
> 
>> (5) Is the depex really necessary? BDS is supposed to start when all
>> drivers have been dispatched, and so by that time, all of the UEFI
>> architectural protocols should be available. (BDS will launch UEFI
>> drivers, and all the UEFI drivers have an implicit depex on all the
>> architectural protocols.)
>>
> 
> The BDS arch protocol will be invoked at that point. but the BdsDxe
> itself could be dispatched much earlier, at which point the
> constructor of this library will be invoked.
> 
> And I'll need to include the CPU arch protocol as well here, as this
> is installed at the same time as the EFI memory attributes protocol by
> the CPU dxe driver.

Ah, so the idea is to inject code between the memory attributes
protocol's installation and BdsDxe launching.


>> (7) Tying back to my point (4) -- I understand this is a hack anyway,
>> but I'm still uncomfortable with platform BDS uninstalling a protocol
>> that is owned by / provided by the CPU driver. Feels like a significant
>> layering violation.
>>
> 
> It is.
> 
>> Can we modify the CPU driver instead, to listen to a new event group,
>> upon which being signaled, the CPU driver would uninstall the protocol
>> (and close the listening event)?
>>
>> This PlatformBootManagerLib instance would act more or less the same
>> (I'd suggest signaling the event group from within AfterConsole, in case
>> the PCD default and/or the fw_cfg knob dictated that), but the protocol
>> uninstallation would occur in "ArmPkg/Drivers/CpuDxe".
>>
>> In more technical terms, the layering violation IMO is that we mess with
>> CpuDxe's "mCpuHandle" and "mMemoryAttribute" static variables from
>> within BDS. Adding the new event group requires more boiler-plate code
>> for sure, but there's a small code-size benefit as well: we'd not have
>> to look up either the handle (with LocateHandle) or the protocol
>> interface (with HandleProtocol), as CpuDxe inherently knows those
>> (mCpuHandle, mMemoryAttribute).
>>
> 
> I agree with your analysis here. But I am reluctant to introduce
> elaborate infrastructure across drivers to implement a feature that
> should not exist in the first place.
> 
> As I mentioned a couple of times, I am rather unhappy with the
> complete lack of involvement of the people who created this mess in
> the first place, and what I am after is really a minimal, local hack
> that unblocks the actual end users (people running LIMA on ARM based
> Macs) without creating building blocks that will be used by the distro
> forks to erode the original functionality even further,

Understood. I agree to keep this contained, location-wise.

(I notice Gerd reports downthread though that limiting the protocol's
masking time-wise as well (i.e. to first boot) is not helpful, because
even rhel-9.3 grubaa64 has problems when the protocol is exposed. So a
simpler but broader approach could be better.)

Thanks!
Laszlo



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

Re: [edk2-devel] [PATCH v3 4/5] DynamicTablesPkg: Adds API to generate a method with ArgN

[PierreGondois]

Hello Abdul,
Thanks for the new patches. I reviewed this one, but I think it would
be better to have one single generic function to handle the 2 cases
(and the many more that might spawn) that you have.

Would it be possible to make a function based on this kind of interface instead 
?

/* Type of the function parameter. There are some missing types,
   like the Local arguments, packages, etc. but this should be sufficient
   for your use case.
*/
typedef enum {
  AmlMethodParamTypeArg = 0,
  AmlMethodParamTypeInteger,
  AmlMethodParamTypeString,
} AML_METHOD_PARAM_TYPE;

/* Structure to describe each method parameter. */
struct {
  AML_METHOD_TYPE Type;

  union {
UINTN ArgN;
UINT64 Integer;
VOID *Data;
  } Data;

  UINTN Length;

  /* In case packages are added one day and we need to count the elements. */
  UINTN Count;
}

/* The function */
EFI_STATUS
EFIAPI
AmlCodeGenMethodInvokeMethodArgn (
  IN  CONST CHAR8   *MethodNameString,
  IN  CONST CHAR8   *InvokeMethodNameString,
  INUINT8   NumArgs,
  INBOOLEAN IsSerialized,
  INUINT8   SyncLevel,
  INAML_METHOD_PARAM_TYPE   *MethodParamArray,
  INUINTN   MethodParamCount,
  INAML_NODE_HANDLE ParentNode   OPTIONAL,
  OUT   AML_OBJECT_NODE_HANDLE  *NewObjectNodeOPTIONAL
  );
{
 /* Based on the type of each element of MethodParamArray,
some Data node might be necessary to allocate.
  */
}


/* And to use this function: */
AML_METHOD_PARAM_TYPE MethodParamArray[4] = {
  { // [0]
.Type = AmlMethodParamTypeArg,
.Data = 2,
// Length and Count are unused.
  },
  { // [1]
.Type = AmlMethodParamTypeInteger,
.Data = 1000,
// Length and Count are unused.
  },
  { // [2]
.Type = AmlMethodParamTypeString,
.Data = "Hello",
.Length = strlen("Hello");
// Count is unused.
  },
  { // [3]
.Type = AmlMethodParamTypeArg,
.Data = 0,
// Length and Count are unused.
  },
}

AmlCodeGenMethodInvokeMethodArgn (
  "MET0", "MET1", 4, TRUE, 3, MethodParamArray, 4, ParentNode, NewObjectNode
  );

is equivalent of the following ASL code:
  Method(MET0, 4, Serialized, 3) {
MET1 (Arg2, 1000, "Hello", Arg0)
  }

Regards,
Pierre

On 12/11/23 11:37, Abdul Lateef Attar wrote:

From: Abdul Lateef Attar 

Adds an API to generate a method which invokes another
method with arguments.
This help to generate dynamic code to invoke another
method(might be in static ASL file) with build-in
argument parameters.

e.g:
Method (MET0, 6, Serialized)
{
   \_SB.MET1 (Arg0, Arg1, Arg2, Arg3, Arg4, Arg5)
}

Cc: Pierre Gondois 
Cc: Sami Mujawar 
Signed-off-by: Abdul Lateef Attar 
---
  .../Include/Library/AmlLib/AmlLib.h   |  46 ++
  .../Common/AmlLib/CodeGen/AmlCodeGen.c| 152 ++
  2 files changed, 198 insertions(+)

diff --git a/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h 
b/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
index eb8740692f..5ab205b5f0 100644
--- a/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
+++ b/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
@@ -1693,4 +1693,50 @@ AmlAddNameStringToNamedPackage (
IN AML_OBJECT_NODE_HANDLE  NamedNode
);
  
+/** AML code generation for a method invoking another method

+with ArgN arguments.
+
+  AmlCodeGenMethodInvokeMethodArgn (
+"MET0", "MET1", 4, TRUE, 3, ParentNode, NewObjectNode
+);
+  is equivalent of the following ASL code:
+Method(MET0, 4, Serialized, 3) {
+  MET1 (Arg0, Arg1, Arg2, Arg3)
+}
+
+  @param [in]  MethodNameString   The new Method's name.
+  Must be a NULL-terminated ASL NameString
+  e.g.: "MET0", "_SB.MET0", etc.
+  The input string is copied.
+  @param [in]  InvokeMethodNameString The called/invoked method's name.
+  Must be a NULL-terminated ASL NameString
+  e.g.: "MET1", "_SB.MET1", etc.
+  The input string is copied.
+  @param [in]  NumArgsNumber of arguments.
+  Must be 0 <= NumArgs <= 6.
+  @param [in]  IsSerialized   TRUE is equivalent to Serialized.
+  FALSE is equivalent to NotSerialized.
+  Default is NotSerialized in ASL spec.
+  @param [in]  SyncLevel  Synchronization level for the method.
+  Must be 0 <= SyncLevel <= 15.
+  Default is 0 in ASL.
+  @param [in]  ParentNode If provided, set ParentNode as the parent
+  of the node created.
+  @param [out] NewObjectNode  If success, contains the created node.
+
+  @retval EFI_SUC

Re: [edk2-devel] [Patch V3 0/6] Create and consume a new gMpInformationHobGuid2 in UefiCpuPkg.

[Laszlo Ersek]

Hi Dun,

On 12/11/23 04:16, Tan, Dun wrote:
> Hi Laszlo,
> 
> Previously I sent a patch set " Move gMpInformationHobGuid from 
> StandaloneMmPkg to UefiCpuPkg. " and thanks for your review. To solve the 
> issue that the maximum length of one HOB might not be enough when CPU count 
> is 1-2000 or bigger and extend the HOB, we decide to create a new MpInfo2Hob 
> in UefiCpuPkg in this patch set. Do you have any comments about the patch set?
> 
> Thanks, 
> Dun

A few days ago I made an effort to at least identify the newest patch
sets I should "sometime" review on edk2, including those that apparently
superseded older versions. Thus, although not with 100% certainty, I did
deduce the above "change of plan", i.e., that the movement of the
existent info HOB between packages would be superseded by a brand new
HOB. However, all I could do at the time was simply tagging the new
version for review -- and that's where I stand now.

For reference, I have approx. 14+ patch sets tagged for review on
edk2-devel -- these have accumulated due to my 2 weeks long sick leave.
I'm back to work for 4 days this week, but then I'll disappear again
until the end of the year. So, I think I had best declare "email
bankruptcy".

Apologies for blocking you -- I had made some efforts to inform my
co-maintainers of my status meanwhile. So, please don't wait for my
feedback at this time; I might catch up, if I'm lucky, but I probably
won't be able to. So if Ray is pleased with your patches, please go
ahead and merge them.

I might make comments on smaller patches this week; rest assured that
that kind of "preference" is just practicality, not laziness. It feels
hopeless for me to make a serious "dent" in reviewing any larger patch
set this week, so I'll try to spend review effort where it has a
fleeting chance at enabling actual progress.

Best regards,
Laszlo


> 
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of duntan
> Sent: Friday, December 8, 2023 5:55 PM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] [Patch V3 0/6] Create and consume a new 
> gMpInformationHobGuid2 in UefiCpuPkg.
> 
> In the V3 patch set,
> In patch "UefiCpuPkg: Build MpInfo2HOB in CpuMpPei", the DEBUG message format 
> is modified In patch "UefiCpuPkg: Consume MpInfo2Hob in PiSmmCpuDxe", remove 
> unneccesary assert check.
> In patch "UefiCpuPkg: Avoid assuming only one smmbasehob", free allocated 
> buffer when error returning case happen.
> 
> Dun Tan (6):
>   UefiCpuPkg: Create gMpInformationHobGuid2 in UefiCpuPkg
>   UefiCpuPkg: Build MpInfo2HOB in CpuMpPei
>   UefiCpuPkg: Consume MpInfo2Hob in PiSmmCpuDxe
>   UefiCpuPkg: Add a new field in MpInfo2 HOB
>   UefiCpuPkg: Cache core type in MpInfo2 HOB
>   UefiCpuPkg: Avoid assuming only one smmbasehob
> 
>  UefiCpuPkg/CpuMpPei/CpuMpPei.c   | 146 
> ++
>  UefiCpuPkg/CpuMpPei/CpuMpPei.h   |   6 +-
>  UefiCpuPkg/CpuMpPei/CpuMpPei.inf |   3 ++-
>  UefiCpuPkg/Include/Guid/MpInformation2.h |  58 
> ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c   | 354 
> ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h   |   2 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf |   8 
>  UefiCpuPkg/UefiCpuPkg.dec|   3 +++
>  8 files changed, 513 insertions(+), 67 deletions(-)  create mode 100644 
> UefiCpuPkg/Include/Guid/MpInformation2.h
> 
> --
> 2.31.1.windows.1
> 
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH v9 4/5] MdePkg: Utilize Cache Management Operations Implementation For RISC-V

[Sunil V L]

On Sun, Dec 10, 2023 at 07:51:12PM +0530, Dhaval Sharma wrote:
> Thanks for the review. My comments inline:
> 
> On Fri, Dec 8, 2023 at 9:58 AM Sunil V L  wrote:
> 
> > On Thu, Dec 07, 2023 at 10:31:48AM +0530, Dhaval Sharma wrote:
> > > Comments inline:
> > >
> > >
> > > On Wed, Dec 6, 2023 at 7:50 PM Sunil V L 
> > wrote:
> > >
> > > > Hi Dhaval,
> > > >
> > > > Thank you very much for fixing the issue with instruction cache
> > > > invalidation and confirming with the spec owner. Few minor comments
> > > > below.
> > > >
> > > > On Mon, Dec 04, 2023 at 01:59:49PM +0530, Dhaval Sharma wrote:
> > > > > Use newly defined cache management operations for RISC-V where
> > possible
> > > > > It builds up on the support added for RISC-V cache management
> > > > > instructions in BaseLib.
> > > > > Cc: Michael D Kinney 
> > > > > Cc: Liming Gao 
> > > > > Cc: Zhiguang Liu 
> > > > > Cc: Laszlo Ersek 
> > > > >
> > > > > Signed-off-by: Dhaval Sharma 
> > > > > Acked-by: Laszlo Ersek 
> > > > > ---
> > > > >
> > > > > Notes:
> > > > > V9:
> > > > > - Fixed an issue with Instruction cache invalidation. Use fence.i
> > > > >   instruction as CMO does not support i-cache operations.
> > > > > V8:
> > > > > - Added note to convert PCD into RISC-V feature bitmap pointer
> > > > > - Modified function names to be more explicit about cache ops
> > > > > - Added RB tag
> > > > > V7:
> > > > > - Added PcdLib
> > > > > - Restructure DEBUG message based on feedback on V6
> > > > > - Make naming consistent to CMO, remove all CBO references
> > > > > - Add ASSERT for not supported functions instead of plain debug
> > > > message
> > > > > - Added RB tag
> > > > > V6:
> > > > > - Utilize cache management instructions if HW supports it
> > > > >   This patch is part of restructuring on top of v5
> > > > >
> > > > IMO, it is better to keep the change log in the cover letter. Since not
> > > > all patches may be CC'd to every one apart from the cover letter, it is
> > > > difficult to understand from the cover letter what has changed in the
> > new
> > > > series.
> > > >
> > > [Dhaval] AFAIU notes are tied to specific commits. But it makes sense, I
> > > can add an update to the cover letter.
> > >
> > > >
> > > > >  MdePkg/MdePkg.dec  |
> > > >  8 +
> > > > >  MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf |
> > > >  5 +
> > > > >  MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c|
> > > > 173 
> > > > >  MdePkg/MdePkg.uni  |
> > > >  4 +
> > > > >  4 files changed, 160 insertions(+), 30 deletions(-)
> > > > >
> > > > > diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> > > > > index ac54338089e8..fa92673ff633 100644
> > > > > --- a/MdePkg/MdePkg.dec
> > > > > +++ b/MdePkg/MdePkg.dec
> > > > > @@ -2399,6 +2399,14 @@ [PcdsFixedAtBuild.AARCH64,
> > > > PcdsPatchableInModule.AARCH64]
> > > > ># @Prompt CPU Rng algorithm's GUID.
> > > > >
> > > >
> > gEfiMdePkgTokenSpaceGuid.PcdCpuRngSupportedAlgorithm|{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}|VOID*|0x0037
> > > > >
> > > > > +[PcdsFixedAtBuild.RISCV64, PcdsPatchableInModule.RISCV64]
> > > > > +  #
> > > > > +  # Configurability to override RISC-V CPU Features
> > > > > +  # BIT 0 = Cache Management Operations. This bit is relevant only
> > if
> > > > > +  # previous stage has feature enabled and user wants to disable it.
> > > > > +  #
> > > > > +
> > > >
> > gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0x|UINT64|0x69
> > > > > +
> > > > >  [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic,
> > PcdsDynamicEx]
> > > > >## This value is used to set the base address of PCI express
> > > > hierarchy.
> > > > ># @Prompt PCI Express Base Address.
> > > > > diff --git
> > > > a/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
> > > > b/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
> > > > > index 6fd9cbe5f6c9..601a38d6c109 100644
> > > > > ---
> > a/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
> > > > > +++
> > b/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
> > > > > @@ -56,3 +56,8 @@ [LibraryClasses]
> > > > >BaseLib
> > > > >DebugLib
> > > > >
> > > > > +[LibraryClasses.RISCV64]
> > > > > +  PcdLib
> > > > > +
> > > > > +[Pcd.RISCV64]
> > > > > +  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride  ## CONSUMES
> > > > > diff --git a/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
> > > > b/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
> > > > > index ac2a3c23a249..cacc38eff4f4 100644
> > > > > --- a/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
> > > > > +++ b/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
> > > > > @@ -2,6 +2,7 @@
> > > > >RISC-V specific functionality for cache.

Re: [edk2-devel] [PATCH v2 1/2] SctPkg: Fix X64 build errors for GCC toolchain

[Sunny Wang]

Good fix and cleanup, Abdul. EFIAPI is needed for 
https://uefi.org/specs/UEFI/2.9_A/02_Overview.html#calling-conventions.
Looks good to me as long as we can also successfully build AARCH64 and other 
architectures with this change.
Reviewed-by: Sunny Wang 

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Abdul Lateef 
Attar via groups.io
Sent: Thursday, June 9, 2022 11:54 AM
To: devel@edk2.groups.io
Cc: G Edhaya Chandran ; Barton Gao 
; Carolyn Gjertsen ; Samer 
El-Haj-Mahmoud ; Eric Jin ; 
Arvin Chen ; Supreeth Venkatesh 

Subject: [edk2-devel] [PATCH v2 1/2] SctPkg: Fix X64 build errors for GCC 
toolchain

Corrects the function declaration/definition
by adding EFIAPI.
Removes duplicate functions.

Cc: G Edhaya Chandran 
Cc: Barton Gao 
Cc: Carolyn Gjertsen 
Cc: Samer El-Haj-Mahmoud 
Cc: Eric Jin 
Cc: Arvin Chen 
Cc: Supreeth Venkatesh 
Signed-off-by: Abdul Lateef Attar 
---
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/DebugSupport/BlackBoxTest/DebugSupportBBTestMain.h
  |  1 +
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/DevicePathFromText/BlackBoxTest/DevicePathFromTextBBTestMain.h
  |  1 +
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/DevicePathToText/BlackBoxTest/DevicePathToTextBBTestMain.h
  |  1 +
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/HIIConfigAccess/BlackBoxTest/HIIConfigAccessBBTestMain.h
|  1 +
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/HIIConfigRouting/BlackBoxTest/HIIConfigRoutingBBTestMain.h
  |  1 +
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/HIIFontEx/BlackBoxTest/HIIFontExBBTestMain.h
|  1 +
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/HIIImage/BlackBoxTest/HIIImageBBTestMain.h
  |  1 +
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/HIIImageEx/BlackBoxTest/HIIImageExBBTestMain.h
  |  1 +
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/HIIString/BlackBoxTest/HIIStringBBTestMain.h
|  3 ++
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/LoadedImage/BlackBoxTest/LoadedImageBBTest.h
|  1 +
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/PartitionInfo/BlackBoxTest/PartitionInfoBBTestMain.h
|  1 +
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/ResetNotification/BlackBoxTest/ResetNotificationBBTestMain.h
|  1 +
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleFileSystem/BlackBoxTest/SimpleFileSystemBBTest.h
  |  1 +
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextIn/BlackBoxTest/SimpleTextInBBTestMain.h
  |  1 +
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextOut/BlackBoxTest/SimpleTextOutBBTestMain_efi.h
|  1 +
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleTextOut/BlackBoxTest/SimpleTextOutBBTestMain_uefi.h
   |  1 +
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/UFSDeviceConfig/BlackBoxTest/UFSDeviceConfigBBTestMain.h
|  1 +
 
uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/DevicePath/BlackBoxTest/DevicePathBBTestMain.h
  |  1 +
 
uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/HIIConfigAccess/BlackBoxTest/HIIConfigAccessBBTestMain.h
|  1 +
 
uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleFileSystem/BlackBoxTest/SimpleFileSystemBBTest.h
  |  1 +
 
uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextIn/BlackBoxTest/SimpleTextInBBTestMain.h
  |  1 +
 
uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestMain.h
|  1 +
 
uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextOut/BlackBoxTest/SimpleTextOutBBTestMain_uefi.h
   |  1 +
 uefi-sct/SctPkg/SCRT/SCRTDriver/ia32/Debug.c   
|  9 --
 uefi-sct/SctPkg/SCRT/SCRTDriver/x64/Debug.c
|  9 --
 
uefi-sct/SctPkg/TestCase/RIVL/Protocol/AddressResolutionProtocol/Arp/ArpENTSTest.c
 |  1 +
 
uefi-sct/SctPkg/TestCase/RIVL/Protocol/AddressResolutionProtocol/ArpServiceBinding/ArpServiceBindingENTSTest.c
 |  3 ++
 uefi-sct/SctPkg/TestCase/RIVL/Protocol/Dhcp4/Dhcp4/Dhcp4ENTSTest.c 
|  1 +
 uefi-sct/SctPkg/TestCase/RIVL/Protocol/Dhcp4/Dhcp4SB/Dhcp4SBENTSTest.c 
|  3 ++
 uefi-sct/SctPkg/TestCase/RIVL/Protocol/Dhcp6/Dhcp6/Dhcp6ENTSTest.c 
|  1 +
 uefi-sct/SctPkg/TestCase/RIVL/Protocol/Dhcp6/Dhcp6SB/Dhcp6SBENTSTest.c 
|  1 +
 uefi-sct/SctPkg/TestCase/RIVL/Protocol/Http/Http/HttpENTSTest.c
|  1 +
 
uefi-sct/SctPkg/TestCase/RIVL/Protocol/Http/HttpServiceBinding/HttpServiceBindingENTSTest.c
|  3 ++
 uefi-sct/SctPkg/TestCase/RIVL/Protocol/InternetProtocol4/Ip4/Ip4ENTSTest.c 

Re: [edk2-devel] [PATCH edk2-test v2 4/4] Fix the URL for the edk2-test repo

[Sunny Wang]

Good catch. Looks good to me. Thanks, Rebecca!
Reviewed-by: Sunny Wang 

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Rebecca Cran via 
groups.io
Sent: Friday, November 10, 2023 7:08 PM
To: devel@edk2.groups.io; G Edhaya Chandran ; Barton 
Gao ; Carolyn Gjertsen ; Samer 
El-Haj-Mahmoud ; Supreeth Venkatesh 

Cc: Rebecca Cran 
Subject: [edk2-devel] [PATCH edk2-test v2 4/4] Fix the URL for the edk2-test 
repo

Fix the URL for the edk2-test repo: the uefi-sct is a directory inside
the repo.

Signed-off-by: Rebecca Cran 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 Maintainers.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index a94255f015ad..ae6dd7008bcd 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -28,7 +28,7 @@ Descriptions of section entries:

 UEFI-SCT
 --
-T: git - https://github.com/tianocore/edk2-test/uefi-sct
+T: git - https://github.com/tianocore/edk2-test


 Responsible Disclosure, Reporting Security Issues
--
2.34.1






IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112294): https://edk2.groups.io/g/devel/message/112294
Mute This Topic: https://groups.io/mt/102513318/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-test 3/4] Point users to the URL for edk2-test-parser if it doesn't exist

[Sunny Wang]

This is good. Thanks, Rebecca!
Reviewed-by: Sunny Wang 

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Rebecca Cran via 
groups.io
Sent: Friday, November 10, 2023 7:02 PM
To: devel@edk2.groups.io; G Edhaya Chandran ; Barton 
Gao ; Carolyn Gjertsen ; Samer 
El-Haj-Mahmoud ; Eric Jin ; 
Arvin Chen ; Supreeth Venkatesh 

Cc: Rebecca Cran 
Subject: [edk2-devel] [PATCH edk2-test 3/4] Point users to the URL for 
edk2-test-parser if it doesn't exist

If edk2-test-parser doesn't exist, tell the user where they can clone it
from.

Signed-off-by: Rebecca Cran 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 uefi-sct/SctPkg/buildzip.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/uefi-sct/SctPkg/buildzip.sh b/uefi-sct/SctPkg/buildzip.sh
index c7f4673f62b2..cc02ad3056b6 100755
--- a/uefi-sct/SctPkg/buildzip.sh
+++ b/uefi-sct/SctPkg/buildzip.sh
@@ -54,6 +54,7 @@ cp Build/MdeModule/RELEASE_GCC5/${TARGET_ARCH}/CapsuleApp.efi 
${TARGET_ARCH}_SCT
 if [ ! -d "${pwd}edk2-test-parser" ]
 then
 echo "edk2-test-parser repo is missing from current directory, please 
clone and try again"
+   echo "The URL for edk2-test-parser is 
https://git.gitlab.arm.com/systemready/edk2-test-parser.git";
 exit
 fi

--
2.34.1






IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112293): https://edk2.groups.io/g/devel/message/112293
Mute This Topic: https://groups.io/mt/102513215/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-test v2 2/4] Rename files in HowToBuild to avoid spaces in filenames

[Sunny Wang]

Looks good to me.
Better to add 
https://github.com/tianocore/tianocore.github.io/wiki/Code-Style-C#user-content-CamelCase
 in commit message for reference.
Reviewed-by: Sunny Wang 

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Rebecca Cran via 
groups.io
Sent: Friday, November 10, 2023 7:08 PM
To: devel@edk2.groups.io; G Edhaya Chandran ; Barton 
Gao ; Carolyn Gjertsen ; Samer 
El-Haj-Mahmoud ; Supreeth Venkatesh 

Cc: Rebecca Cran 
Subject: [edk2-devel] [PATCH edk2-test v2 2/4] Rename files in HowToBuild to 
avoid spaces in filenames

Rename the text files in the HowToBuild directory to remove the spaces
and use CamelCase instead.

Signed-off-by: Rebecca Cran 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 uefi-sct/HowToBuild/{How to accelerate SCT execution.txt => 
HowToAccelerateSctExecution.txt} | 0
 uefi-sct/HowToBuild/{How to build SCT.txt => HowToBuildSct.txt}
  | 0
 uefi-sct/HowToBuild/{How to build SCT in UDK2017.txt => 
HowToBuildSctInUdk2017.txt}  | 0
 3 files changed, 0 insertions(+), 0 deletions(-)

diff --git a/uefi-sct/HowToBuild/How to accelerate SCT execution.txt 
b/uefi-sct/HowToBuild/HowToAccelerateSctExecution.txt
similarity index 100%
rename from uefi-sct/HowToBuild/How to accelerate SCT execution.txt
rename to uefi-sct/HowToBuild/HowToAccelerateSctExecution.txt
diff --git a/uefi-sct/HowToBuild/How to build SCT.txt 
b/uefi-sct/HowToBuild/HowToBuildSct.txt
similarity index 100%
rename from uefi-sct/HowToBuild/How to build SCT.txt
rename to uefi-sct/HowToBuild/HowToBuildSct.txt
diff --git a/uefi-sct/HowToBuild/How to build SCT in UDK2017.txt 
b/uefi-sct/HowToBuild/HowToBuildSctInUdk2017.txt
similarity index 100%
rename from uefi-sct/HowToBuild/How to build SCT in UDK2017.txt
rename to uefi-sct/HowToBuild/HowToBuildSctInUdk2017.txt
--
2.34.1






IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112292): https://edk2.groups.io/g/devel/message/112292
Mute This Topic: https://groups.io/mt/102513314/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-test v2 1/4] Unbreak buildzip.sh

[Sunny Wang]

Looks good to me.

The commit message looks a little confusing to me in the beginning because one 
of purposes to run the edksetup.sh is to correctly configure both WORKSPACE and 
PACKAGES_PATH.
However, since buildzip.sh can be independently run, it seems better to remove 
the line of sourcing edksetup.

Reviewed-by: Sunny Wang 

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Rebecca Cran via 
groups.io
Sent: Friday, November 10, 2023 7:08 PM
To: devel@edk2.groups.io; G Edhaya Chandran ; Barton 
Gao ; Carolyn Gjertsen ; Samer 
El-Haj-Mahmoud ; Supreeth Venkatesh 

Cc: Rebecca Cran 
Subject: [edk2-devel] [PATCH edk2-test v2 1/4] Unbreak buildzip.sh

Unbreak buildzip.sh by removing the line sourcing edksetup.sh: unless
WORKSPACE and PACKAGES_PATH are already configured, edksetup.sh will
error out.

Signed-off-by: Rebecca Cran 
Contributed-under: TianoCore Contribution Agreement 1.1
---
 uefi-sct/SctPkg/buildzip.sh | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/uefi-sct/SctPkg/buildzip.sh b/uefi-sct/SctPkg/buildzip.sh
index 625475701f12..c7f4673f62b2 100755
--- a/uefi-sct/SctPkg/buildzip.sh
+++ b/uefi-sct/SctPkg/buildzip.sh
@@ -32,9 +32,6 @@ esac
 # clear all positional parameters
 set --

-source ./edk2/edksetup.sh
-
-
 NUM_CPUS=$((`getconf _NPROCESSORS_ONLN` + 2))

 make -j"$NUM_CPUS" -C edk2/BaseTools/
--
2.34.1






IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112291): https://edk2.groups.io/g/devel/message/112291
Mute This Topic: https://groups.io/mt/102513313/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] ArmVirt: Allow memory attributes protocol to be disabled

[Gerd Hoffmann]

> +  //
> +  // Work around shim's terminally broken use of the EFI memory attributes
> +  // protocol, by uninstalling it if requested on the QEMU command line.
> +  //
> +  // E.g.,
> +  //   -fw_cfg opt/org.tianocore/UninstallMemAttrProtocol,string=y
> +  //
> +  // This is only needed on the first boot, when fbaa64.efi is being invoked 
> to
> +  // set the boot order variables. Subsequent boots involving GRUB are not
> +  // affected.
> +  //
> +  Uninstall = FixedPcdGetBool (PcdUninstallMemAttrProtocol);
> +  QemuFwCfgParseBool ("opt/org.tianocore/UninstallMemAttrProtocol", 
> &Uninstall);
> +  if (Uninstall) {
> +UninstallEfiMemoryAttributesProtocol ();
> +  }

Can we please have a log message here, for both uninstall and
keep-installed cases?

Otherwise the patch looks good to me.

thanks,
  Gerd



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

[edk2-devel] [PATCH v3] ArmVirt: Allow memory attributes protocol to be disabled

[Ard Biesheuvel]

From: Ard Biesheuvel 

Shim's PE loader uses the EFI memory attributes protocol in a way that
results in an immediate crash when invoking the loaded image, unless the
base and size of its executable segment are both aligned to 4k.

If this is not the case, it will strip the memory allocation of its
executable permissions, but fail to add them back for the executable
region, resulting in non-executable code. Unfortunately, the PE loader
does not even bother invoking the protocol in this case (as it notices
the misalignment), making it very hard for system firmware to work
around this by attempting to infer the intent of the caller.

So let's introduce a QEMU command line option to indicate that the
protocol should not be exposed at all, and a PCD to set the default for
this option when it is omitted.

  -fw_cfg opt/org.tianocore/UninstallMemAttrProtocol,string=y

Cc: Laszlo Ersek 
Cc: Gerd Hoffmann 
Cc: Oliver Steffen 
Cc: Alexander Graf 
Cc: Oliver Smith-Denny 
Cc: Taylor Beebe 
Cc: Peter Jones 
Cc: Leif Lindholm 
Link: https://gitlab.com/qemu-project/qemu/-/issues/1990
Signed-off-by: Ard Biesheuvel 
---
 ArmVirtPkg/ArmVirtPkg.dec|  6 ++
 ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |  3 +
 ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c   | 62 

 3 files changed, 71 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtPkg.dec b/ArmVirtPkg/ArmVirtPkg.dec
index 0f2d7873279f..313aebda902a 100644
--- a/ArmVirtPkg/ArmVirtPkg.dec
+++ b/ArmVirtPkg/ArmVirtPkg.dec
@@ -68,3 +68,9 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
   # Cloud Hypervisor has no other way to pass Rsdp address to the guest except 
use a PCD.
   #
   gArmVirtTokenSpaceGuid.PcdCloudHvAcpiRsdpBaseAddress|0x0|UINT64|0x0005
+
+  ##
+  # Whether the EFI memory attributes protocol should be uninstalled before
+  # invoking the OS loader. This may be needed to work around problematic
+  # builds of shim that use the protocol incorrectly.
+  gArmVirtTokenSpaceGuid.PcdUninstallMemAttrProtocol|FALSE|BOOLEAN|0x0006
diff --git 
a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index 997eb1a4429f..70e4ebf94ad9 100644
--- a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -46,6 +46,7 @@ [LibraryClasses]
   PcdLib
   PlatformBmPrintScLib
   QemuBootOrderLib
+  QemuFwCfgSimpleParserLib
   QemuLoadImageLib
   ReportStatusCodeLib
   TpmPlatformHierarchyLib
@@ -55,6 +56,7 @@ [LibraryClasses]
   UefiRuntimeServicesTableLib

 [FixedPcd]
+  gArmVirtTokenSpaceGuid.PcdUninstallMemAttrProtocol
   gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate
   gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits
   gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity
@@ -73,5 +75,6 @@ [Guids]
 [Protocols]
   gEfiFirmwareVolume2ProtocolGuid
   gEfiGraphicsOutputProtocolGuid
+  gEfiMemoryAttributeProtocolGuid
   gEfiPciRootBridgeIoProtocolGuid
   gVirtioDeviceProtocolGuid
diff --git a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c 
b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
index 85c01351b09d..a1a2bca2af3d 100644
--- a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
+++ b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -,6 +1112,49 @@ PlatformBootManagerBeforeConsole (
   FilterAndProcess (&gEfiPciIoProtocolGuid, IsVirtioPciSerial, 
SetupVirtioSerial);
 }

+/**
+  Uninstall the EFI memory attribute protocol if it exists.
+**/
+STATIC
+VOID
+UninstallEfiMemoryAttributesProtocol (
+  VOID
+  )
+{
+  EFI_STATUS  Status;
+  EFI_HANDLE  Handle;
+  UINTN   Size;
+  VOID*MemoryAttributeProtocol;
+
+  Size   = sizeof (Handle);
+  Status = gBS->LocateHandle (
+  ByProtocol,
+  &gEfiMemoryAttributeProtocolGuid,
+  NULL,
+  &Size,
+  &Handle
+  );
+
+  if (EFI_ERROR (Status)) {
+ASSERT (Status == EFI_NOT_FOUND);
+return;
+  }
+
+  Status = gBS->HandleProtocol (
+  Handle,
+  &gEfiMemoryAttributeProtocolGuid,
+  &MemoryAttributeProtocol
+  );
+  ASSERT_EFI_ERROR (Status);
+
+  Status = gBS->UninstallProtocolInterface (
+  Handle,
+  &gEfiMemoryAttributeProtocolGuid,
+  MemoryAttributeProtocol
+  );
+  ASSERT_EFI_ERROR (Status);
+}
+
 /**
   Do the platform specific action after the console is ready
   Possible things that can be done in PlatformBootManagerAfterConsole:
@@ -1129,12 +1173,30 @@ PlatformBootManagerAfterConsole (
   )
 {
   RETURN_STATUS  Status;
+  BOOLEANUninstall;

   //
   // Show the splash screen.
   //
   BootLo

[edk2-devel] [PATCH v3 5/5] DynamicTablesPkg: Adds wrapper API AmlCodeGenMethodInvokeMethodArgn

[Abdul Lateef Attar via groups.io]

From: Abdul Lateef Attar 

Adds a wrapper API AmlCodeGenMethodInvokeMethodArgnWithInteger() to
the AmlCodeGenMethodInvokeMethodArgn().

Wrapper API provides ability to add integer arguments along
with ArgN argument.
This help to generate dynamic code to invoke another
method(might be in static ASL file) with build-in
argument parameters plus integer arguments.

e.g:
Method (MET0, 3, Serialized)
{
  \_SB.MET1 (Arg0, Arg1, Arg2, 0x10, 0x20))
}

Cc: Pierre Gondois 
Cc: Sami Mujawar 
Signed-off-by: Abdul Lateef Attar 
---
 .../Include/Library/AmlLib/AmlLib.h   |  68 +++
 .../Common/AmlLib/CodeGen/AmlCodeGen.c| 187 ++
 2 files changed, 255 insertions(+)

diff --git a/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h 
b/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
index 5ab205b5f0..132846a38a 100644
--- a/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
+++ b/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
@@ -1739,4 +1739,72 @@ AmlCodeGenMethodInvokeMethodArgn (
   OUT   AML_OBJECT_NODE_HANDLE  *NewObjectNode   OPTIONAL
   );
 
+/** AML code generation for a method invoking another method
+with ArgN arguments and optionally integer arguments.
+
+  Arg0Int = 0x10;
+  Arg1Int = 0x20;
+  AmlCodeGenMethodInvokeMethodArgnWithInteger (
+"MET0", "MET1", 4, TRUE, 3,
+Arg0Int, Arg1Int, NULL, NULL, NULL, NULL,
+ParentNode, NewObjectNode
+);
+  is equivalent of the following ASL code:
+Method(MET0, 4, Serialized, 3) {
+  MET1 (Arg0, Arg1, Arg2, Arg3, 0x10, 0x20)
+}
+
+  @param [in]  MethodNameString The new Method's name.
+Must be a NULL-terminated ASL NameString
+e.g.: "MET0", "_SB.MET0", etc.
+The input string is copied.
+  @param [in]  InvokeMethodNameString The called/invoked method's name.
+Must be a NULL-terminated ASL NameString
+e.g.: "MET1", "_SB.MET1", etc.
+The input string is copied.
+  @param [in]  NumArgs  Number of arguments.
+Must be 0 <= NumArgs <= 6.
+  @param [in]  IsSerialized TRUE is equivalent to Serialized.
+FALSE is equivalent to NotSerialized.
+Default is NotSerialized in ASL spec.
+  @param [in]  SyncLevelSynchronization level for the method.
+Must be 0 <= SyncLevel <= 15.
+Default is 0 in ASL.
+  @param [in]  IntegerArg0  If provided and meets the validation 
criteria,
+then set as integer argument to invoked 
method.
+  @param [in]  IntegerArg1  If provided and meets the validation 
criteria,
+then set as integer argument to invoked 
method.
+  @param [in]  IntegerArg2  If provided and meets the validation 
criteria,
+then set as integer argument to invoked 
method.
+  @param [in]  IntegerArg3  If provided and meets the validation 
criteria,
+then set as integer argument to invoked 
method.
+  @param [in]  IntegerArg4  If provided and meets the validation 
criteria,
+then set as integer argument to invoked 
method.
+  @param [in]  IntegerArg5  If provided and meets the validation 
criteria,
+then set as integer argument to invoked 
method.
+  @param [in]  ParentNode   If provided, set ParentNode as the parent
+of the node created.
+  @param [out] NewObjectNodeIf success, contains the created node.
+
+  @retval EFI_SUCCESS Success.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+**/
+EFI_STATUS
+EFIAPI
+AmlCodeGenMethodInvokeMethodArgnWithInteger (
+  IN  CONST CHAR8   *MethodNameString,
+  IN  CONST CHAR8   *InvokeMethodNameString,
+  INUINT8   NumArgs,
+  INBOOLEAN IsSerialized,
+  INUINT8   SyncLevel,
+  INUINT64  *IntegerArg0OPTIONAL,
+  INUINT64  *IntegerArg1OPTIONAL,
+  INUINT64  *IntegerArg2OPTIONAL,
+  INUINT64  *IntegerArg3OPTIONAL,
+  INUINT64  *IntegerArg4OPTIONAL,
+  INUINT64  *IntegerArg5OPTIONAL,
+  INAML_NODE_HANDLE ParentNode  OPTIONAL,
+  OUT   AML_OBJECT_NODE_HANDLE  *NewObjectNode  OPTIONAL
+  );
+
 #endif // AML_LIB_H_
diff --git a/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c 
b/DynamicTablesPkg/Library/Commo

[edk2-devel] [PATCH v3 4/5] DynamicTablesPkg: Adds API to generate a method with ArgN

[Abdul Lateef Attar via groups.io]

From: Abdul Lateef Attar 

Adds an API to generate a method which invokes another
method with arguments.
This help to generate dynamic code to invoke another
method(might be in static ASL file) with build-in
argument parameters.

e.g:
Method (MET0, 6, Serialized)
{
  \_SB.MET1 (Arg0, Arg1, Arg2, Arg3, Arg4, Arg5)
}

Cc: Pierre Gondois 
Cc: Sami Mujawar 
Signed-off-by: Abdul Lateef Attar 
---
 .../Include/Library/AmlLib/AmlLib.h   |  46 ++
 .../Common/AmlLib/CodeGen/AmlCodeGen.c| 152 ++
 2 files changed, 198 insertions(+)

diff --git a/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h 
b/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
index eb8740692f..5ab205b5f0 100644
--- a/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
+++ b/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
@@ -1693,4 +1693,50 @@ AmlAddNameStringToNamedPackage (
   IN AML_OBJECT_NODE_HANDLE  NamedNode
   );
 
+/** AML code generation for a method invoking another method
+with ArgN arguments.
+
+  AmlCodeGenMethodInvokeMethodArgn (
+"MET0", "MET1", 4, TRUE, 3, ParentNode, NewObjectNode
+);
+  is equivalent of the following ASL code:
+Method(MET0, 4, Serialized, 3) {
+  MET1 (Arg0, Arg1, Arg2, Arg3)
+}
+
+  @param [in]  MethodNameString   The new Method's name.
+  Must be a NULL-terminated ASL NameString
+  e.g.: "MET0", "_SB.MET0", etc.
+  The input string is copied.
+  @param [in]  InvokeMethodNameString The called/invoked method's name.
+  Must be a NULL-terminated ASL NameString
+  e.g.: "MET1", "_SB.MET1", etc.
+  The input string is copied.
+  @param [in]  NumArgsNumber of arguments.
+  Must be 0 <= NumArgs <= 6.
+  @param [in]  IsSerialized   TRUE is equivalent to Serialized.
+  FALSE is equivalent to NotSerialized.
+  Default is NotSerialized in ASL spec.
+  @param [in]  SyncLevel  Synchronization level for the method.
+  Must be 0 <= SyncLevel <= 15.
+  Default is 0 in ASL.
+  @param [in]  ParentNode If provided, set ParentNode as the parent
+  of the node created.
+  @param [out] NewObjectNode  If success, contains the created node.
+
+  @retval EFI_SUCCESS Success.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+**/
+EFI_STATUS
+EFIAPI
+AmlCodeGenMethodInvokeMethodArgn (
+  IN  CONST CHAR8   *MethodNameString,
+  IN  CONST CHAR8   *InvokeMethodNameString,
+  INUINT8   NumArgs,
+  INBOOLEAN IsSerialized,
+  INUINT8   SyncLevel,
+  INAML_NODE_HANDLE ParentNode   OPTIONAL,
+  OUT   AML_OBJECT_NODE_HANDLE  *NewObjectNode   OPTIONAL
+  );
+
 #endif // AML_LIB_H_
diff --git a/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c 
b/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
index a6db34fb97..b05fa6d109 100644
--- a/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
+++ b/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
@@ -3849,3 +3849,155 @@ exit_handler:
 
   return Status;
 }
+
+/** AML code generation for a method invoking another method
+with ArgN arguments.
+
+  AmlCodeGenMethodInvokeMethodArgn (
+"MET0", "MET1", 4, TRUE, 3, ParentNode, NewObjectNode
+);
+  is equivalent of the following ASL code:
+Method(MET0, 4, Serialized, 3) {
+  MET1 (Arg0, Arg1, Arg2, Arg3)
+}
+
+  @param [in]  MethodNameString   The new Method's name.
+  Must be a NULL-terminated ASL NameString
+  e.g.: "MET0", "_SB.MET0", etc.
+  The input string is copied.
+  @param [in]  InvokeMethodNameString The called/invoked method's name.
+  Must be a NULL-terminated ASL NameString
+  e.g.: "MET1", "_SB.MET1", etc.
+  The input string is copied.
+  @param [in]  NumArgsNumber of arguments.
+  Must be 0 <= NumArgs <= 6.
+  @param [in]  IsSerialized   TRUE is equivalent to Serialized.
+  FALSE is equivalent to NotSerialized.
+  Default is NotSerialized in ASL spec.
+  @param [in]  SyncLevel  Synchronization level for the method.
+  Must be 0 <= SyncLevel <= 15.
+  Default is 0 in

[edk2-devel] [PATCH v3 0/5] DynamicTablesPkg: Updated word I/O

[Abdul Lateef Attar via groups.io]

From: Abdul Lateef Attar 

PR: https://github.com/tianocore/edk2/pull/5131/

Cc: Pierre Gondois 
Cc: Sami Mujawar 
Cc: Abdul Lateef Attar 

Abdul Lateef Attar (5):
  DynamicTablesPkg: AML Code generation for word I/O ranges
  DynamicTablesPkg: Corrects AmlCodeGenRdWordBusNumber parameters
  DynamicTablesPkg: Corrects function pointer typedef of
AML_PARSE_FUNCTION
  DynamicTablesPkg: Adds API to generate a method with ArgN
  DynamicTablesPkg: Adds wrapper API AmlCodeGenMethodInvokeMethodArgn

 .../Include/Library/AmlLib/AmlLib.h   | 189 +-
 .../Common/AmlLib/CodeGen/AmlCodeGen.c| 339 ++
 .../AmlLib/CodeGen/AmlResourceDataCodeGen.c   |  98 -
 .../Library/Common/AmlLib/Parser/AmlParser.c  |   3 +-
 4 files changed, 617 insertions(+), 12 deletions(-)

-- 
2.34.1



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

[edk2-devel] [PATCH v3 3/5] DynamicTablesPkg: Corrects function pointer typedef of AML_PARSE_FUNCTION

[Abdul Lateef Attar via groups.io]

From: Abdul Lateef Attar 

Corrects the function pointer typedef AML_PARSE_FUNCTION,
otherwise some compiler like VS2019 gives error.

Cc: Pierre Gondois 
Cc: Sami Mujawar 
Signed-off-by: Abdul Lateef Attar 
Reviewed-by: Pierre Gondois 
---
 DynamicTablesPkg/Library/Common/AmlLib/Parser/AmlParser.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/DynamicTablesPkg/Library/Common/AmlLib/Parser/AmlParser.c 
b/DynamicTablesPkg/Library/Common/AmlLib/Parser/AmlParser.c
index 8e584d4930..d3a51a94c7 100644
--- a/DynamicTablesPkg/Library/Common/AmlLib/Parser/AmlParser.c
+++ b/DynamicTablesPkg/Library/Common/AmlLib/Parser/AmlParser.c
@@ -100,8 +100,7 @@ AmlParseStream (
 **/
 typedef
 EFI_STATUS
-EFIAPI
-(*AML_PARSE_FUNCTION) (
+(EFIAPI *AML_PARSE_FUNCTION)(
   IN  CONST AML_NODE_HEADER   *Node,
   INAML_PARSE_FORMAT  ExpectedFormat,
   IN  OUT   AML_STREAM*FStream,
-- 
2.34.1



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

[Abdul Lateef Attar via groups.io]

From: Abdul Lateef Attar 

Corrects the parameters of AmlCodeGenRdWordBusNumber() to
UINT16 to generate word bus number.

Cc: Pierre Gondois 
Cc: Sami Mujawar 
Signed-off-by: Abdul Lateef Attar 
Reviewed-by: Pierre Gondois 
---
 DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h   | 10 +-
 .../Common/AmlLib/CodeGen/AmlResourceDataCodeGen.c | 10 +-
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h 
b/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
index 5e340b94ce..eb8740692f 100644
--- a/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
+++ b/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
@@ -714,11 +714,11 @@ AmlCodeGenRdWordBusNumber (
   INBOOLEAN IsMinFixed,
   INBOOLEAN IsMaxFixed,
   INBOOLEAN IsPosDecode,
-  INUINT32 AddressGranularity,
-  INUINT32 AddressMinimum,
-  INUINT32 AddressMaximum,
-  INUINT32 AddressTranslation,
-  INUINT32 RangeLength,
+  INUINT16 AddressGranularity,
+  INUINT16 AddressMinimum,
+  INUINT16 AddressMaximum,
+  INUINT16 AddressTranslation,
+  INUINT16 RangeLength,
   INUINT8 ResourceSourceIndex,
   IN  CONST CHAR8 *ResourceSource,
   INAML_OBJECT_NODE_HANDLE NameOpNode, OPTIONAL
diff --git 
a/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlResourceDataCodeGen.c 
b/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlResourceDataCodeGen.c
index 60fe69ba6d..46243f981c 100644
--- a/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlResourceDataCodeGen.c
+++ b/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlResourceDataCodeGen.c
@@ -848,11 +848,11 @@ AmlCodeGenRdWordBusNumber (
   INBOOLEAN IsMinFixed,
   INBOOLEAN IsMaxFixed,
   INBOOLEAN IsPosDecode,
-  INUINT32 AddressGranularity,
-  INUINT32 AddressMinimum,
-  INUINT32 AddressMaximum,
-  INUINT32 AddressTranslation,
-  INUINT32 RangeLength,
+  INUINT16 AddressGranularity,
+  INUINT16 AddressMinimum,
+  INUINT16 AddressMaximum,
+  INUINT16 AddressTranslation,
+  INUINT16 RangeLength,
   INUINT8 ResourceSourceIndex,
   IN  CONST CHAR8 *ResourceSource,
   INAML_OBJECT_NODE_HANDLE NameOpNode, OPTIONAL
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112284): https://edk2.groups.io/g/devel/message/112284
Mute This Topic: https://groups.io/mt/103106348/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/5] DynamicTablesPkg: AML Code generation for word I/O ranges

[Abdul Lateef Attar via groups.io]

From: Abdul Lateef Attar 

Add helper functions to generate AML resource data
for word I/O.

Cc: Pierre Gondois 
Cc: Sami Mujawar 
Signed-off-by: Abdul Lateef Attar 
Reviewed-by: Pierre Gondois 
---
 .../Include/Library/AmlLib/AmlLib.h   | 65 ++
 .../AmlLib/CodeGen/AmlResourceDataCodeGen.c   | 88 +++
 2 files changed, 153 insertions(+)

diff --git a/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h 
b/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
index 71e8539b30..5e340b94ce 100644
--- a/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
+++ b/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
@@ -2,6 +2,7 @@
   AML Lib.
 
   Copyright (c) 2019 - 2021, Arm Limited. All rights reserved.
+  Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 **/
@@ -724,6 +725,70 @@ AmlCodeGenRdWordBusNumber (
   OUT   AML_DATA_NODE_HANDLE*NewRdNode  OPTIONAL
   );
 
+/** Code generation for the "WordIO ()" ASL function.
+
+  The Resource Data effectively created is a Word Address Space Resource
+  Data. Cf ACPI 6.5:
+   - s6.4.3.5.3 "Word Address Space Descriptor".
+
+  The created resource data node can be:
+   - appended to the list of resource data elements of the NameOpNode.
+ In such case NameOpNode must be defined by a the "Name ()" ASL statement
+ and initially contain a "ResourceTemplate ()".
+   - returned through the NewRdNode parameter.
+
+  @param [in]  IsResourceConsumer   ResourceUsage parameter.
+  @param [in]  IsMinFixed   Minimum address is fixed.
+  @param [in]  IsMaxFixed   Maximum address is fixed.
+  @param [in]  IsPosDecode  Decode parameter
+  @param [in]  IsaRangesPossible values are:
+ 0-Reserved
+ 1-NonISAOnly
+ 2-ISAOnly
+ 3-EntireRange
+  @param [in]  AddressGranularity   Address granularity.
+  @param [in]  AddressMinimum   Minimum address.
+  @param [in]  AddressMaximum   Maximum address.
+  @param [in]  AddressTranslation   Address translation.
+  @param [in]  RangeLength  Range length.
+  @param [in]  ResourceSourceIndex  Resource Source index.
+Not supported. Must be 0.
+  @param [in]  ResourceSource   Resource Source.
+Not supported. Must be NULL.
+  @param [in]  IsDenseTranslation   TranslationDensity parameter.
+  @param [in]  IsTypeStatic TranslationType parameter.
+  @param [in]  NameOpNode   NameOp object node defining a named object.
+If provided, append the new resource data
+node to the list of resource data elements
+of this node.
+  @param [out] NewRdNodeIf provided and success,
+contain the created node.
+
+  @retval EFI_SUCCESS The function completed successfully.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+  @retval EFI_OUT_OF_RESOURCESCould not allocate memory.
+**/
+EFI_STATUS
+EFIAPI
+AmlCodeGenRdWordIo (
+  INBOOLEAN IsResourceConsumer,
+  INBOOLEAN IsMinFixed,
+  INBOOLEAN IsMaxFixed,
+  INBOOLEAN IsPosDecode,
+  INUINT8 IsaRanges,
+  INUINT16 AddressGranularity,
+  INUINT16 AddressMinimum,
+  INUINT16 AddressMaximum,
+  INUINT16 AddressTranslation,
+  INUINT16 RangeLength,
+  INUINT8 ResourceSourceIndex,
+  IN  CONST CHAR8 *ResourceSource,
+  INBOOLEAN IsDenseTranslation,
+  INBOOLEAN IsTypeStatic,
+  INAML_OBJECT_NODE_HANDLE NameOpNode, OPTIONAL
+  OUT   AML_DATA_NODE_HANDLE*NewRdNode  OPTIONAL
+  );
+
 /** Code generation for the "QWordIO ()" ASL function.
 
   The Resource Data effectively created is a QWord Address Space Resource
diff --git 
a/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlResourceDataCodeGen.c 
b/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlResourceDataCodeGen.c
index 0bc1c1d119..60fe69ba6d 100644
--- a/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlResourceDataCodeGen.c
+++ b/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlResourceDataCodeGen.c
@@ -2,6 +2,7 @@
   AML Resource Data Code Generation.
 
   Copyright (c) 2020 - 2021, Arm Limited. All rights reserved.
+  Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -878,6 +879,93 @@ AmlCodeGenRdWordBusNumber (
);
 }
 
+/** Code generation for the "WordIO ()" ASL function.
+
+  The Resource Data effectively created is a Word Address Space Resource
+  Data. Cf ACPI 6.5:
+   - s6.4.3.5.3 "Word Address Space Descriptor".
+
+  The created resource data node can be:
+   - appended to the list of resource data elem

Re: [edk2-devel] [PATCH v3 13/39] UefiCpuPkg: Add CpuMmuLib.h to UefiCpuPkg

[Chao Li]

Ok, I will submit the V4 today.


Thanks,
Chao
On 2023/12/11 16:13, Ni, Ray wrote:


Thanks. I think we are aligned. Looking forward to your v4 patch.

Thanks,

Ray

*From:*devel@edk2.groups.io  *On Behalf Of *Chao Li
*Sent:* Friday, December 8, 2023 10:10 AM
*To:* Ni, Ray ; devel@edk2.groups.io
*Cc:* Dong, Eric ; Kumar, Rahul R 
; Gerd Hoffmann ; Leif 
Lindholm ; Ard Biesheuvel 
; Sami Mujawar ; 
Sunil V L ; Warkentin, Andrei 

*Subject:* Re: [edk2-devel] [PATCH v3 13/39] UefiCpuPkg: Add 
CpuMmuLib.h to UefiCpuPkg


Hi Ray,

Do you think this plan is OK? If possible, I will submit the V4 today.

Thanks,
Chao

On 2023/12/5 20:27, Chao Li wrote:

Hi Ray,

On 2023/12/5 16:27, Ni, Ray wrote:

Thanks,

Ray

*From:*devel@edk2.groups.io 
 *On Behalf Of *Chao Li
*Sent:* Monday, December 4, 2023 3:32 PM
*To:* devel@edk2.groups.io; Ni, Ray 

*Cc:* Dong, Eric 
; Kumar, Rahul R
 ;
Gerd Hoffmann  ;
Leif Lindholm 
; Ard Biesheuvel

; Sami Mujawar
 ; Sunil V
L 
; Warkentin, Andrei
 
*Subject:* Re: [edk2-devel] [PATCH v3 13/39] UefiCpuPkg: Add
CpuMmuLib.h to UefiCpuPkg

Hi Ray,

For this patch, I checked again and here are my opinions:

 1. (Set|Get)MemoryRegionAttribute is difficult to merge
together, because the parameters between the tow APIs are
not similar. So I suggest they be independent.

[Ray] What I mean is to merge SetMemoryRegion(NonExec|ReadOly)
to SetMemoryRegionAttribute(). Similarly, GetXXX can be merged
as well. What’s your opinion?

Ok, I already said it in point 2, other APIs will be removed.

 2. The EfiAttributeConverse, GetMemoryRegionAttribute,
SetMemoryRegionAttributes and
ConfigureMemoryManagementUnit will be retained and other
APIs will be removed. Because the functions expressed by
other APIs can be completed though the retained API.

[Ray] I didn’t notice EfiAttributeConverse(). I guess callers
may not need to know the architectural specific attributes. So
EfiAttributeConverse() might be not needed as a public API.

I agree, the EfiAttributeCoverse() complete by caller or as a
private API.

 3. You pointed out MEMORY_REGION_DESCRIPTOR have no one to
construct it, do I need add a new API to construct it?
Could it be named GetMemoryMapPolicy and accept a
parameter with MEMORY_REGION_DESCRIPTOR** ?

[Ray] So the GetMemoryRegionAttribute() and
SetMemoryRegionAttributes() are performed on the active
translation table. ConfigureMemoryManagementUint() is to
create a translation table with a list of memory attributes.
How about the following idea?

[Ray] (Set|Get)MemoryRegionAttribute() are performed on a
translation table buffer. And caller calls
SetMemoryRegionAttribute() to modify the translation table
buffer supplied as the parameter. With this,
ConfigureMemoryManagementUnit() is not needed.

Ah, I think you may have some misunderstanding, the
ConfigureMemoryManagementUint is a function that to initialize the
MMU. The MEMORY_REGION_DESCRIPTOR will created by the private API,
and then the caller will call the ConfigureMemoryManagementUnit to
initialize the MMU first(may be fill the static page tables and so
on).

But I thought about it again and it seems you are right, the
ConfigureMemoryManagementUnit and discrptor creater as the public
APIs are not appropriate. They are more suitable as some private APIs.

So, (Get|Set)MemoryRegionAttribute() will be the public APIs and
the parameters will be the same with this change?

Hope to hear from you! :)

Thanks,
Chao

On 2023/11/30 10:25, Chao Li wrote:

Hi Ray,

Thanks for review, here are some of my thoughts:

On 2023/11/30 08:59, Ni, Ray wrote:

Chao,

Since the lib class is so general, I'd like to
understand more details to make sure it can properly
fit into any CPU arch.

In X86, cache setting is through MSRs and Page tables,
and memory access control (read-only, not-present,
non-executable) is through page tables.

Let me understand, 'cache setting' means does it access a
certain address(probably a memory address) via cache? If
so, I'd sa

Re: [edk2-devel] [PATCH v2] ArmVirt: Allow memory attributes protocol to be disabled on first boot

[Gerd Hoffmann]

  Hi,

> OK, so not worth the trouble of trying to detect the first boot, I guess.
> 
> For my info, is rhel-9.3 an old GRUB?

2.06 with a huge stack of downstream patches.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112281): https://edk2.groups.io/g/devel/message/112281
Mute This Topic: https://groups.io/mt/103031504/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/1] MdeModulePkg: Support customized FV Migration Information

[Wang Fan]

Hi Ray, Liming, Mike and Jian

I have updated the patch v4: https://edk2.groups.io/g/devel/message/112276

Pull Request: https://github.com/tianocore/edk2/pull/5124


v2:
- Update commit message for better describe this feature

v3:
- Add more descriptions for "gEdkiiToMigrateFvInfoGuid" PPI usages and 
background, but still keep the name.
- Update "FvOrgBase" to "FvTemporaryRamBase" in EDKII_TO_MIGRATE_FV_INFO.
- Remove flag "FLAGS_SKIP_FV_MIGRATION", since it's not needed.
- Add more descriptions to flag "FLAGS_SKIP_FV_RAW_DATA_COPY".
- Remove the variable MigrateAllFvs to simplify logic.
- Correct "allocate pool" to "allocate pages" to align with descriptions.

v4:
- Re-design EDKII_MIGRATION_INFO to include all FV migration info in one Hob
- Update "FvTemporaryRamBase" to "FvOrgBaseOnTempRam" to avoid misunderstanding
- Update flag name "FLAGS_SKIP_FV_RAW_DATA_COPY" to "FLAGS_FV_RAW_DATA_COPY "
- Refine the logic to NOT impact building MigratedFvInfo hob with raw data copy 
flag

Best Regards
Fan

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Wang Fan
Sent: Monday, December 11, 2023 5:06 PM
To: devel@edk2.groups.io
Cc: Wang, Fan ; Kinney, Michael D 
; Gao, Liming ; Ni, Ray 
; Jiang, Guomin ; Wang, Jian J 

Subject: [edk2-devel] [PATCH v4 1/1] MdeModulePkg: Support customized FV 
Migration Information

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

There are use cases which not all FVs need be migrated from TempRam to 
permanent memory before TempRam tears down. This new guid is introduced to 
avoid unnecessary FV migration to improve boot performance. Platform can 
publish MigrationInfo hob with this guid to customize FV migration info, and 
PeiCore will only migrate FVs indicated by this Hob info.

This is a backwards compatible change, PeiCore will check MigrationInfo hob 
before migration. If MigrationInfo hobs exists, only migrate FVs recorded by 
hobs. If MigrationInfo hobs not exists, migrate all FVs to permanent memory.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Ray Ni 
Cc: Guomin Jiang 
Cc: Jian J Wang 
Signed-off-by: Fan Wang 
---
 MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c | 79 +--
 MdeModulePkg/Core/Pei/PeiMain.inf |  1 +
 MdeModulePkg/Include/Guid/MigratedFvInfo.h| 42 +-
 MdeModulePkg/MdeModulePkg.dec |  3 +-
 SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c |  7 +-
 SecurityPkg/Tcg/TcgPei/TcgPei.c   |  7 +-
 6 files changed, 111 insertions(+), 28 deletions(-)

diff --git a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c 
b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
index 5f32ebb560..0086087e82 100644
--- a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
+++ b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
@@ -1184,7 +1184,12 @@ EvacuateTempRam (
PEI_CORE_FV_HANDLEPeiCoreFvHandle;   
EFI_PEI_CORE_FV_LOCATION_PPI  *PeiCoreFvLocationPpi;+  EFI_PEI_HOB_POINTERS 
 Hob;+  EDKII_MIGRATION_INFO  *MigrationInfo;+  TO_MIGRATE_FV_INFO  
  *ToMigrateFvInfo;+  UINT32FvMigrationFlags;   
EDKII_MIGRATED_FV_INFOMigratedFvInfo;+  UINTN 
Index;ASSERT (Private->PeiMemoryInstalled); @@ -1211,6 +1216,13 @@ 
EvacuateTempRam (
ConvertPeiCorePpiPointers (Private, &PeiCoreFvHandle); +  Hob.Raw = 
GetFirstGuidHob (&gEdkiiMigrationInfoGuid);+  if (Hob.Raw != NULL) {+
MigrationInfo = GET_GUID_HOB_DATA (Hob);+  } else {+MigrationInfo = NULL;+  
}+   for (FvIndex = 0; FvIndex < Private->FvCount; FvIndex++) { FvHeader = 
Private->Fv[FvIndex].FvHeader; ASSERT (FvHeader != NULL);@@ -1224,20 
+1236,27 @@ EvacuateTempRam (
   ) ) {-  //-  // Allocate page to save the 
rebased PEIMs, the PEIMs will get dispatched later.-  //-  Status =  
PeiServicesAllocatePages (-  EfiBootServicesCode,-  
EFI_SIZE_TO_PAGES ((UINTN)FvHeader->FvLength),-  
&FvHeaderAddress-  );-  ASSERT_EFI_ERROR (Status);-  
MigratedFvHeader = (EFI_FIRMWARE_VOLUME_HEADER *)(UINTN)FvHeaderAddress;+  
if ((MigrationInfo == NULL) || (MigrationInfo->MigrateAll == TRUE)) {+
// Migrate all FVs and copy raw data+FvMigrationFlags = 
FLAGS_FV_RAW_DATA_COPY;+  } else {+for (Index = 0; Index < 
MigrationInfo->ToMigrateFvCount; Index++) {+  ToMigrateFvInfo = 
((TO_MIGRATE_FV_INFO *)(MigrationInfo + 1)) + Index;+  if 
(ToMigrateFvInfo->FvOrgBaseOnTempRam == (UINT32)(UINTN)FvHeader) {+
// This FV is to migrate+FvMigrationFlags = 
ToMigrateFvInfo->FvMigrationFlags;+break;+  }+}++   
 if (Index == MigrationInfo->ToMigrateFvCount) {+  // This FV is 
not expected to migrate+  continue;+}+  }//-  
// Allocate pool to save the raw PEIMs, which is used to keep consistent 
context across-  // multiple boot and PCR

Re: [edk2-devel] [Patch V2 1/4] BaseTools: fixing FMMT ShrinkFv issue

[Yuwei Chen]

Thanks a lot~

> -Original Message-
> From: gaoliming 
> Sent: Monday, December 11, 2023 5:04 PM
> To: Chen, Christine ; devel@edk2.groups.io; Feng,
> Bob C 
> Cc: 'Rebecca Cran' ; Guo, Gua 
> Subject: 回复: [edk2-devel] [Patch V2 1/4] BaseTools: fixing FMMT ShrinkFv
> issue
> 
> Christine:
>   I add PUSH label for this PR.
> 
> Thanks
> Liming
> > -邮件原件-
> > 发件人: Chen, Christine 
> > 发送时间: 2023年12月4日 10:59
> > 收件人: Gao, Liming ; devel@edk2.groups.io;
> > Feng, Bob C 
> > 抄送: 'Rebecca Cran' ; Guo, Gua
> 
> > 主题: RE: [edk2-devel] [Patch V2 1/4] BaseTools: fixing FMMT ShrinkFv
> > issue
> >
> > Hi Liming,
> > To avoid wrong operation. I create a new PR for this patch series with
> > Reviewed-by.
> > Please help adding push label. Thanks.
> > https://github.com/tianocore/edk2/pull/5102
> >
> > Thanks,
> > Christine
> >
> > > -Original Message-
> > > From: gaoliming 
> > > Sent: Wednesday, November 29, 2023 11:53 PM
> > > To: devel@edk2.groups.io; Chen, Christine ;
> > > Feng, Bob C 
> > > Cc: 'Rebecca Cran' ; Guo, Gua
> 
> > > Subject: 回复: [edk2-devel] [Patch V2 1/4] BaseTools: fixing FMMT
> > ShrinkFv
> > > issue
> > >
> > > Yuwei:
> > >   Please update commit message with reviewed-by info, then I will
> > > add
> > push
> > > label for this patch set.
> > >
> > > Thanks
> > > Liming
> > > > -邮件原件-
> > > > 发件人: devel@edk2.groups.io  代表 Yuwei
> > Chen
> > > > 发送时间: 2023年11月29日 16:26
> > > > 收件人: Gao, Liming ; Feng, Bob C
> > > > 
> > > > 抄送: 'Rebecca Cran' ; devel@edk2.groups.io;
> > Chen,
> > > > Christine ; Guo, Gua 
> > > > 主题: Re: [edk2-devel] [Patch V2 1/4] BaseTools: fixing FMMT
> > > > ShrinkFv issue
> > > >
> > > > Hi Liming and Cran,
> > > >
> > > > I have created the Edk2 PR for this one:
> > > > https://github.com/tianocore/edk2/pull/5009
> > > > As it has been reviewed, please help merge that. Thanks~
> > > >
> > > > Thanks,
> > > > Yuwei (Christine)
> > > >
> > > > > -Original Message-
> > > > > From: devel@edk2.groups.io  On Behalf Of
> > Yuwei
> > > > > Chen
> > > > > Sent: Monday, September 11, 2023 9:23 AM
> > > > > To: Gao, Liming ;
> > > > > devel@edk2.groups.io; Feng, Bob C 
> > > > > Cc: 'Rebecca Cran' 
> > > > > Subject: Re: [edk2-devel] [Patch V2 1/4] BaseTools: fixing FMMT
> > > > > ShrinkFv issue
> > > > >
> > > > > Thanks liming~ Hope it will be merged soon~ 😊
> > > > >
> > > > > Many thanks,
> > > > > Christine
> > > > >
> > > > > > -Original Message-
> > > > > > From: gaoliming 
> > > > > > Sent: Wednesday, August 30, 2023 4:43 PM
> > > > > > To: devel@edk2.groups.io; Feng, Bob C ;
> > > > > > Chen, Christine 
> > > > > > Cc: 'Rebecca Cran' 
> > > > > > Subject: 回复: [edk2-devel] [Patch V2 1/4] BaseTools: fixing
> > > > > > FMMT ShrinkFv issue
> > > > > >
> > > > > > Christine:
> > > > > >   I have no comments for this patch set. Reviewed-by: Liming
> > > > > > Gao 
> > > > > >
> > > > > > Thanks
> > > > > > Liming
> > > > > > > -邮件原件-
> > > > > > > 发件人: devel@edk2.groups.io  代表 Bob
> > > > Feng
> > > > > > > 发送时间: 2023年6月29日 14:54
> > > > > > > 收件人: Chen, Christine ;
> > > > devel@edk2.groups.io
> > > > > > > 抄送: Rebecca Cran ; Gao, Liming
> > > > > > > 
> > > > > > > 主题: Re: [edk2-devel] [Patch V2 1/4] BaseTools: fixing FMMT
> > > > > > > ShrinkFv
> > > > > > issue
> > > > > > >
> > > > > > > Reviewed-by: Bob Feng 
> > > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Chen, Christine 
> > > > > > > Sent: Thursday, June 29, 2023 11:34 AM
> > > > > > > To: devel@edk2.groups.io
> > > > > > > Cc: Rebecca Cran ; Gao, Liming
> > > > > > > ; Feng, Bob C
> > > > > > > 
> > > > > > > Subject: [Patch V2 1/4] BaseTools: fixing FMMT ShrinkFv
> > > > > > > issue
> > > > > > >
> > > > > > > 1. FvLength not change issue; 2. FileSystemGuid align with
> > > > > > > File Size;
> > > > > > >
> > > > > > > Cc: Rebecca Cran 
> > > > > > > Cc: Liming Gao 
> > > > > > > Cc: Bob Feng 
> > > > > > > Signed-off-by: Yuwei Chen 
> > > > > > > ---
> > > > > > >  BaseTools/Source/Python/FMMT/core/FMMTOperation.py |  2 +-
> > > > > > >  BaseTools/Source/Python/FMMT/core/FvHandler.py | 10
> > > > +++---
> > > > > > >  2 files changed, 8 insertions(+), 4 deletions(-)
> > > > > > >
> > > > > > > diff --git
> > a/BaseTools/Source/Python/FMMT/core/FMMTOperation.py
> > > > > > > b/BaseTools/Source/Python/FMMT/core/FMMTOperation.py
> > > > > > > index a86f8dda9a1a..d4aa3397036d 100644
> > > > > > > --- a/BaseTools/Source/Python/FMMT/core/FMMTOperation.py
> > > > > > > +++ b/BaseTools/Source/Python/FMMT/core/FMMTOperation.py
> > > > > > > @@ -188,7 +188,7 @@ def ExtractFfs(inputfile: str, Ffs_name:
> > > > > > > str,
> > > > > > outputfile:
> > > > > > > str, Fv_name: str=None
> > > > > > >
> > > > > > >
> > > > FmmtParser.WholeFvTree.Findlist.remove(FmmtParser.WholeFvTree.Find
> > > > li
> > > > > > > st
> > > > > > > [i
> > > > > > > ndex])
> > > > > > >  if FmmtParser.WholeFvTree.Findlist != []:
> > > > > > >  TargetNode =

回复: [edk2-devel] [edk2-stable202311][PATCH] BaseTools: Python VfrCompiler implementation

[gaoliming via groups.io]

Christine:

 Is there the change in Edk2 to apply new VfrCompiler? Can you share your code 
branch with new VfrCompiler to pass build on Emulator or Ovmf? I would like to 
try this tool first. 

 

Thanks

Liming

发件人: Chen, Christine  
发送时间: 2023年12月7日 17:08
收件人: devel@edk2.groups.io; Chen, Christine ; Gao, Liming 
; 'Rebecca Cran' ; Zimmer, Vincent 
; Kinney, Michael D ; 
'Leif Lindholm' ; 'Andrew Fish' 
抄送: Feng, Bob C ; Yang, Yuting2 ; 
Hartung, Stephen 
主题: RE: [edk2-devel] [edk2-stable202311][PATCH] BaseTools: Python VfrCompiler 
implementation

 

Hi Liming,

 

Is this feature been tested and reviewed these two weeks? 😊

 

Thanks,

Christine

From: devel@edk2.groups.io   mailto:devel@edk2.groups.io> > On Behalf Of Yuwei Chen
Sent: Monday, November 13, 2023 8:32 AM
To: Gao, Liming mailto:gaolim...@byosoft.com.cn> >; 
'Rebecca Cran' mailto:rebe...@bsdio.com> >; Gao, Liming 
mailto:gaolim...@byosoft.com.cn> >; Zimmer, Vincent 
mailto:vincent.zim...@intel.com> >; Kinney, Michael 
D mailto:michael.d.kin...@intel.com> >; 'Leif 
Lindholm' mailto:quic_llind...@quicinc.com> >; 
'Andrew Fish' mailto:af...@apple.com> >
Cc: Feng, Bob C mailto:bob.c.f...@intel.com> >; Yang, 
Yuting2 mailto:yuting2.y...@intel.com> >; 
devel@edk2.groups.io  ; Hartung, Stephen 
mailto:stephen.hart...@intel.com> >
Subject: Re: [edk2-devel] [edk2-stable202311][PATCH] BaseTools: Python 
VfrCompiler implementation

 

Hi Liming,

 

I know your point. Would you like to start reviewing it and give us more 
feedbacks? We really hope it can be merged as soon as possible.

We can do the merging after the stable tag, but just like you said, maybe we 
need to review it firstly.

 

Looking forward to your feedbacks, and I think this one is a very big step for 
BaseTools. Thanks a lot for your help and contribution on this.

I have created a BZ for this feature: 
https://bugzilla.tianocore.org/show_bug.cgi?id=4596

Will update the patch with Bugzilla link. (This step should not influence the 
reviewing)

 

Thanks,

Christine

 

From: gaoliming mailto:gaolim...@byosoft.com.cn> > 
Sent: Thursday, November 9, 2023 10:19 PM
To: 'Rebecca Cran' mailto:rebe...@bsdio.com> >; Gao, Liming 
mailto:gaolim...@byosoft.com.cn> >; Zimmer, Vincent 
mailto:vincent.zim...@intel.com> >; Chen, Christine 
mailto:yuwei.c...@intel.com> >; Kinney, Michael D 
mailto:michael.d.kin...@intel.com> >; 'Leif 
Lindholm' mailto:quic_llind...@quicinc.com> >; 
'Andrew Fish' mailto:af...@apple.com> >
Cc: Feng, Bob C mailto:bob.c.f...@intel.com> >; Yang, 
Yuting2 mailto:yuting2.y...@intel.com> >; 
devel@edk2.groups.io  ; Hartung, Stephen 
mailto:stephen.hart...@intel.com> >
Subject: RE: [edk2-stable202311][PATCH] BaseTools: Python VfrCompiler 
implementation

 

Christine:

 I can’t directly reply to the original mail because it is too large. This is a 
new feature to add python version VfrCompiler. I don’t think we have enough 
time to review the design and implementation. Although it has no real impact, 
its code may have many change in future. So, I suggest to merge it after this 
stable tag. 

 

Thanks

Liming

 

Below is your request. 

 

Hi Liming and Cran, 

 

Could you help on quick reviewing this new VfrCompiler python tool, it has the 
same functions with origin C version VfrCompiler, meanwhile it supports more 
new features such as generated Vfr files config info into Yaml format. 

 

This feature is urgent for us to use, and we really hope it can be merged into 
this stable tag. This patch is linked to the edk2-basetools PR: 
https://github.com/tianocore/edk2-basetools/pull/109. We list all the known 
issues which will be enhanced in the ReadMe file. And will enhance them one by 
one after the patch merged.

 

For the code quality, in this patch, the new tool is not enabled in build 
process, it just saves in the basetools python folder, which will not influence 
the current edk2 behaviors. We will enable it with a new patch when everything 
is ready.

 

Many thanks~

 

Hi Vincent, please help add more information if necessary~ Thanks a lot~

 

Thanks,

Christine

 





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112278): https://edk2.groups.io/g/devel/message/112278
Mute This Topic: https://groups.io/mt/103105777/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] ArmVirt: Allow memory attributes protocol to be disabled on first boot

[Ard Biesheuvel]

On Mon, Dec 11, 2023 at 10:06 AM Gerd Hoffmann  wrote:
>
> On Thu, Dec 07, 2023 at 11:06:03AM +0100, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel 
> >
> > Shim's PE loader uses the EFI memory attributes protocol in a way that
> > results in an immediate crash when invoking the loaded image, unless the
> > base and size of its executable segment are both aligned to 4k.
> >
> > If this is not the case, it will strip the memory allocation of its
> > executable permissions, but fail to add them back for the executable
> > region, resulting in non-executable code. Unfortunately, the PE loader
> > does not even bother invoking the protocol in this case (as it notices
> > the misalignment), making it very hard for system firmware to work
> > around this by attempting to infer the intent of the caller.
> >
> > So let's introduce a QEMU command line option to indicate that the
> > protocol should not be exposed at all on the first boot, which is when
> > the issue is triggered. (fbaa64.efi is broken but grubaa64.efi boots
> > fine)
> >
> >   -fw_cfg opt/org.tianocore/UninstallMemAttrProtocolOnFirstBoot,string=y
> >
> > Also introduce a fixed boolean PCD that sets the default.
>
> Did some more testing meanwhile with latest shim.  Noticed things can
> explode in other ways as well in case the memory attribute protocol is
> present.
>
> Specifically rhel-9.3 grub on aa64 crashes with latest shim.  Which I
> suspect is that grub version not being NX-clean, and shim setting page
> permissions via memory attribute protocol triggers that bug.  Didn't
> analyze it yet though.
>
> So, while I'd love to see some automatic way here I suspect trying to be
> too clever does more harm than good.
>

OK, so not worth the trouble of trying to detect the first boot, I guess.

For my info, is rhel-9.3 an old GRUB?


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

[edk2-devel] [PATCH v4 1/1] MdeModulePkg: Support customized FV Migration Information

[Wang Fan]

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

There are use cases which not all FVs need be migrated from TempRam to
permanent memory before TempRam tears down. This new guid is introduced
to avoid unnecessary FV migration to improve boot performance. Platform
can publish MigrationInfo hob with this guid to customize FV migration
info, and PeiCore will only migrate FVs indicated by this Hob info.

This is a backwards compatible change, PeiCore will check MigrationInfo
hob before migration. If MigrationInfo hobs exists, only migrate FVs
recorded by hobs. If MigrationInfo hobs not exists, migrate all FVs to
permanent memory.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Ray Ni 
Cc: Guomin Jiang 
Cc: Jian J Wang 
Signed-off-by: Fan Wang 
---
 MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c | 79 +--
 MdeModulePkg/Core/Pei/PeiMain.inf |  1 +
 MdeModulePkg/Include/Guid/MigratedFvInfo.h| 42 +-
 MdeModulePkg/MdeModulePkg.dec |  3 +-
 SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c |  7 +-
 SecurityPkg/Tcg/TcgPei/TcgPei.c   |  7 +-
 6 files changed, 111 insertions(+), 28 deletions(-)

diff --git a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c 
b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
index 5f32ebb560..0086087e82 100644
--- a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
+++ b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
@@ -1184,7 +1184,12 @@ EvacuateTempRam (
 
   PEI_CORE_FV_HANDLEPeiCoreFvHandle;
   EFI_PEI_CORE_FV_LOCATION_PPI  *PeiCoreFvLocationPpi;
+  EFI_PEI_HOB_POINTERS  Hob;
+  EDKII_MIGRATION_INFO  *MigrationInfo;
+  TO_MIGRATE_FV_INFO*ToMigrateFvInfo;
+  UINT32FvMigrationFlags;
   EDKII_MIGRATED_FV_INFOMigratedFvInfo;
+  UINTN Index;
 
   ASSERT (Private->PeiMemoryInstalled);
 
@@ -1211,6 +1216,13 @@ EvacuateTempRam (
 
   ConvertPeiCorePpiPointers (Private, &PeiCoreFvHandle);
 
+  Hob.Raw = GetFirstGuidHob (&gEdkiiMigrationInfoGuid);
+  if (Hob.Raw != NULL) {
+MigrationInfo = GET_GUID_HOB_DATA (Hob);
+  } else {
+MigrationInfo = NULL;
+  }
+
   for (FvIndex = 0; FvIndex < Private->FvCount; FvIndex++) {
 FvHeader = Private->Fv[FvIndex].FvHeader;
 ASSERT (FvHeader != NULL);
@@ -1224,20 +1236,27 @@ EvacuateTempRam (
   )
 )
 {
-  //
-  // Allocate page to save the rebased PEIMs, the PEIMs will get 
dispatched later.
-  //
-  Status =  PeiServicesAllocatePages (
-  EfiBootServicesCode,
-  EFI_SIZE_TO_PAGES ((UINTN)FvHeader->FvLength),
-  &FvHeaderAddress
-  );
-  ASSERT_EFI_ERROR (Status);
-  MigratedFvHeader = (EFI_FIRMWARE_VOLUME_HEADER *)(UINTN)FvHeaderAddress;
+  if ((MigrationInfo == NULL) || (MigrationInfo->MigrateAll == TRUE)) {
+// Migrate all FVs and copy raw data
+FvMigrationFlags = FLAGS_FV_RAW_DATA_COPY;
+  } else {
+for (Index = 0; Index < MigrationInfo->ToMigrateFvCount; Index++) {
+  ToMigrateFvInfo = ((TO_MIGRATE_FV_INFO *)(MigrationInfo + 1)) + 
Index;
+  if (ToMigrateFvInfo->FvOrgBaseOnTempRam == (UINT32)(UINTN)FvHeader) {
+// This FV is to migrate
+FvMigrationFlags = ToMigrateFvInfo->FvMigrationFlags;
+break;
+  }
+}
+
+if (Index == MigrationInfo->ToMigrateFvCount) {
+  // This FV is not expected to migrate
+  continue;
+}
+  }
 
   //
-  // Allocate pool to save the raw PEIMs, which is used to keep consistent 
context across
-  // multiple boot and PCR0 will keep the same no matter if the address of 
allocated page is changed.
+  // Allocate pages to save the rebased PEIMs, the PEIMs will get 
dispatched later.
   //
   Status =  PeiServicesAllocatePages (
   EfiBootServicesCode,
@@ -1245,7 +1264,8 @@ EvacuateTempRam (
   &FvHeaderAddress
   );
   ASSERT_EFI_ERROR (Status);
-  RawDataFvHeader = (EFI_FIRMWARE_VOLUME_HEADER *)(UINTN)FvHeaderAddress;
+  MigratedFvHeader = (EFI_FIRMWARE_VOLUME_HEADER *)(UINTN)FvHeaderAddress;
+  CopyMem (MigratedFvHeader, FvHeader, (UINTN)FvHeader->FvLength);
 
   DEBUG ((
 DEBUG_VERBOSE,
@@ -1256,17 +1276,34 @@ EvacuateTempRam (
 ));
 
   //
-  // Copy the context to the rebased pages and raw pages, and create hob 
to save the
-  // information. The MigratedFvInfo HOB will never be produced when
-  // PcdMigrateTemporaryRamFirmwareVolumes is FALSE, because the PCD 
control the
-  // feature.
+  // Create hob to save MigratedFvInfo, this hob will only be produced when
+  // Migration feature PCD PcdMigrateTemporaryRamFirmwareVolumes is set to 
TRUE.
   //
-  CopyMem (MigratedFvHeader, FvHeader, (UINTN)FvHeader->FvLength);
-  CopyMem (RawDataFvHeader, MigratedFvHeader, (UINTN)FvHeader-

Re: [edk2-devel] [PATCH v2] ArmVirt: Allow memory attributes protocol to be disabled on first boot

[Gerd Hoffmann]

On Thu, Dec 07, 2023 at 11:06:03AM +0100, Ard Biesheuvel wrote:
> From: Ard Biesheuvel 
> 
> Shim's PE loader uses the EFI memory attributes protocol in a way that
> results in an immediate crash when invoking the loaded image, unless the
> base and size of its executable segment are both aligned to 4k.
> 
> If this is not the case, it will strip the memory allocation of its
> executable permissions, but fail to add them back for the executable
> region, resulting in non-executable code. Unfortunately, the PE loader
> does not even bother invoking the protocol in this case (as it notices
> the misalignment), making it very hard for system firmware to work
> around this by attempting to infer the intent of the caller.
> 
> So let's introduce a QEMU command line option to indicate that the
> protocol should not be exposed at all on the first boot, which is when
> the issue is triggered. (fbaa64.efi is broken but grubaa64.efi boots
> fine)
> 
>   -fw_cfg opt/org.tianocore/UninstallMemAttrProtocolOnFirstBoot,string=y
> 
> Also introduce a fixed boolean PCD that sets the default.

Did some more testing meanwhile with latest shim.  Noticed things can
explode in other ways as well in case the memory attribute protocol is
present.

Specifically rhel-9.3 grub on aa64 crashes with latest shim.  Which I
suspect is that grub version not being NX-clean, and shim setting page
permissions via memory attribute protocol triggers that bug.  Didn't
analyze it yet though.

So, while I'd love to see some automatic way here I suspect trying to be
too clever does more harm than good.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112275): https://edk2.groups.io/g/devel/message/112275
Mute This Topic: https://groups.io/mt/103031504/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/4] BaseTools: fixing FMMT ShrinkFv issue

[gaoliming via groups.io]

Christine:
  I add PUSH label for this PR.

Thanks
Liming
> -邮件原件-
> 发件人: Chen, Christine 
> 发送时间: 2023年12月4日 10:59
> 收件人: Gao, Liming ; devel@edk2.groups.io;
> Feng, Bob C 
> 抄送: 'Rebecca Cran' ; Guo, Gua 
> 主题: RE: [edk2-devel] [Patch V2 1/4] BaseTools: fixing FMMT ShrinkFv issue
> 
> Hi Liming,
> To avoid wrong operation. I create a new PR for this patch series with
> Reviewed-by.
> Please help adding push label. Thanks.
> https://github.com/tianocore/edk2/pull/5102
> 
> Thanks,
> Christine
> 
> > -Original Message-
> > From: gaoliming 
> > Sent: Wednesday, November 29, 2023 11:53 PM
> > To: devel@edk2.groups.io; Chen, Christine ; Feng,
> > Bob C 
> > Cc: 'Rebecca Cran' ; Guo, Gua 
> > Subject: 回复: [edk2-devel] [Patch V2 1/4] BaseTools: fixing FMMT
> ShrinkFv
> > issue
> >
> > Yuwei:
> >   Please update commit message with reviewed-by info, then I will add
> push
> > label for this patch set.
> >
> > Thanks
> > Liming
> > > -邮件原件-
> > > 发件人: devel@edk2.groups.io  代表 Yuwei
> Chen
> > > 发送时间: 2023年11月29日 16:26
> > > 收件人: Gao, Liming ; Feng, Bob C
> > > 
> > > 抄送: 'Rebecca Cran' ; devel@edk2.groups.io;
> Chen,
> > > Christine ; Guo, Gua 
> > > 主题: Re: [edk2-devel] [Patch V2 1/4] BaseTools: fixing FMMT ShrinkFv
> > > issue
> > >
> > > Hi Liming and Cran,
> > >
> > > I have created the Edk2 PR for this one:
> > > https://github.com/tianocore/edk2/pull/5009
> > > As it has been reviewed, please help merge that. Thanks~
> > >
> > > Thanks,
> > > Yuwei (Christine)
> > >
> > > > -Original Message-
> > > > From: devel@edk2.groups.io  On Behalf Of
> Yuwei
> > > > Chen
> > > > Sent: Monday, September 11, 2023 9:23 AM
> > > > To: Gao, Liming ; devel@edk2.groups.io;
> > > > Feng, Bob C 
> > > > Cc: 'Rebecca Cran' 
> > > > Subject: Re: [edk2-devel] [Patch V2 1/4] BaseTools: fixing FMMT
> > > > ShrinkFv issue
> > > >
> > > > Thanks liming~ Hope it will be merged soon~ 😊
> > > >
> > > > Many thanks,
> > > > Christine
> > > >
> > > > > -Original Message-
> > > > > From: gaoliming 
> > > > > Sent: Wednesday, August 30, 2023 4:43 PM
> > > > > To: devel@edk2.groups.io; Feng, Bob C ;
> > > > > Chen, Christine 
> > > > > Cc: 'Rebecca Cran' 
> > > > > Subject: 回复: [edk2-devel] [Patch V2 1/4] BaseTools: fixing FMMT
> > > > > ShrinkFv issue
> > > > >
> > > > > Christine:
> > > > >   I have no comments for this patch set. Reviewed-by: Liming Gao
> > > > > 
> > > > >
> > > > > Thanks
> > > > > Liming
> > > > > > -邮件原件-
> > > > > > 发件人: devel@edk2.groups.io  代表 Bob
> > > Feng
> > > > > > 发送时间: 2023年6月29日 14:54
> > > > > > 收件人: Chen, Christine ;
> > > devel@edk2.groups.io
> > > > > > 抄送: Rebecca Cran ; Gao, Liming
> > > > > > 
> > > > > > 主题: Re: [edk2-devel] [Patch V2 1/4] BaseTools: fixing FMMT
> > > > > > ShrinkFv
> > > > > issue
> > > > > >
> > > > > > Reviewed-by: Bob Feng 
> > > > > >
> > > > > > -Original Message-
> > > > > > From: Chen, Christine 
> > > > > > Sent: Thursday, June 29, 2023 11:34 AM
> > > > > > To: devel@edk2.groups.io
> > > > > > Cc: Rebecca Cran ; Gao, Liming
> > > > > > ; Feng, Bob C 
> > > > > > Subject: [Patch V2 1/4] BaseTools: fixing FMMT ShrinkFv issue
> > > > > >
> > > > > > 1. FvLength not change issue;
> > > > > > 2. FileSystemGuid align with File Size;
> > > > > >
> > > > > > Cc: Rebecca Cran 
> > > > > > Cc: Liming Gao 
> > > > > > Cc: Bob Feng 
> > > > > > Signed-off-by: Yuwei Chen 
> > > > > > ---
> > > > > >  BaseTools/Source/Python/FMMT/core/FMMTOperation.py |  2 +-
> > > > > >  BaseTools/Source/Python/FMMT/core/FvHandler.py | 10
> > > +++---
> > > > > >  2 files changed, 8 insertions(+), 4 deletions(-)
> > > > > >
> > > > > > diff --git
> a/BaseTools/Source/Python/FMMT/core/FMMTOperation.py
> > > > > > b/BaseTools/Source/Python/FMMT/core/FMMTOperation.py
> > > > > > index a86f8dda9a1a..d4aa3397036d 100644
> > > > > > --- a/BaseTools/Source/Python/FMMT/core/FMMTOperation.py
> > > > > > +++ b/BaseTools/Source/Python/FMMT/core/FMMTOperation.py
> > > > > > @@ -188,7 +188,7 @@ def ExtractFfs(inputfile: str, Ffs_name:
> > > > > > str,
> > > > > outputfile:
> > > > > > str, Fv_name: str=None
> > > > > >
> > > > > >
> > > FmmtParser.WholeFvTree.Findlist.remove(FmmtParser.WholeFvTree.Findli
> > > > > > st
> > > > > > [i
> > > > > > ndex])
> > > > > >  if FmmtParser.WholeFvTree.Findlist != []:
> > > > > >  TargetNode = FmmtParser.WholeFvTree.Findlist[0]
> > > > > > -if TargetNode.type == FV_TREE or SEC_FV_TREE or
> > > > > > DATA_FV_TREE:
> > > > > > +if TargetNode.type == FV_TREE or TargetNode.type ==
> > > > > > SEC_FV_TREE or TargetNode.type == DATA_FV_TREE:
> > > > > >  FinalData = struct2stream(TargetNode.Data.Header)
> +
> > > > > > TargetNode.Data.Data
> > > > > >  with open(outputfile, "wb") as f:
> > > > > >  f.write(FinalData) diff --git
> > > > > > a/BaseTools/Source/Python/FMMT/core/FvHandler.py
> > > > > > b/BaseTools/Source/Python/FMMT/core/FvHandler.py
> > >

Re: [edk2-devel] [PATCH v3 13/39] UefiCpuPkg: Add CpuMmuLib.h to UefiCpuPkg

[Ni, Ray]

Thanks. I think we are aligned. Looking forward to your v4 patch.

Thanks,
Ray
From: devel@edk2.groups.io  On Behalf Of Chao Li
Sent: Friday, December 8, 2023 10:10 AM
To: Ni, Ray ; devel@edk2.groups.io
Cc: Dong, Eric ; Kumar, Rahul R ; 
Gerd Hoffmann ; Leif Lindholm ; 
Ard Biesheuvel ; Sami Mujawar 
; Sunil V L ; Warkentin, Andrei 

Subject: Re: [edk2-devel] [PATCH v3 13/39] UefiCpuPkg: Add CpuMmuLib.h to 
UefiCpuPkg


Hi Ray,

Do you think this plan is OK? If possible, I will submit the V4 today.

Thanks,
Chao
On 2023/12/5 20:27, Chao Li wrote:

Hi Ray,
On 2023/12/5 16:27, Ni, Ray wrote:


Thanks,
Ray
From: devel@edk2.groups.io 
 On Behalf Of Chao Li
Sent: Monday, December 4, 2023 3:32 PM
To: devel@edk2.groups.io; Ni, Ray 

Cc: Dong, Eric ; Kumar, Rahul 
R ; Gerd Hoffmann 
; Leif Lindholm 
; Ard Biesheuvel 
; Sami Mujawar 
; Sunil V L 
; Warkentin, Andrei 

Subject: Re: [edk2-devel] [PATCH v3 13/39] UefiCpuPkg: Add CpuMmuLib.h to 
UefiCpuPkg


Hi Ray,

For this patch, I checked again and here are my opinions:

  1.  (Set|Get)MemoryRegionAttribute is difficult to merge together, because 
the parameters between the tow APIs are not similar. So I suggest they be 
independent.

[Ray] What I mean is to merge SetMemoryRegion(NonExec|ReadOly) to 
SetMemoryRegionAttribute(). Similarly, GetXXX can be merged as well. What’s 
your opinion?
Ok, I already said it in point 2, other APIs will be removed.


  1.  The EfiAttributeConverse, GetMemoryRegionAttribute, 
SetMemoryRegionAttributes and ConfigureMemoryManagementUnit will be retained 
and other APIs will be removed. Because the functions expressed by other APIs 
can be completed though the retained API.

[Ray] I didn’t notice EfiAttributeConverse(). I guess callers may not need to 
know the architectural specific attributes. So EfiAttributeConverse() might be 
not needed as a public API.
I agree, the EfiAttributeCoverse() complete by caller or as a private API.


  1.  You pointed out MEMORY_REGION_DESCRIPTOR have no one to construct it, do 
I need add a new API to construct it? Could it be named GetMemoryMapPolicy and 
accept a parameter with MEMORY_REGION_DESCRIPTOR** ?

[Ray] So the GetMemoryRegionAttribute() and SetMemoryRegionAttributes() are 
performed on the active translation table. ConfigureMemoryManagementUint() is 
to create a translation table with a list of memory attributes. How about the 
following idea?

[Ray] (Set|Get)MemoryRegionAttribute() are performed on a translation table 
buffer. And caller calls SetMemoryRegionAttribute() to modify the translation 
table buffer supplied as the parameter. With this, 
ConfigureMemoryManagementUnit() is not needed.

Ah, I think you may have some misunderstanding, the 
ConfigureMemoryManagementUint is a function that to initialize the MMU. The 
MEMORY_REGION_DESCRIPTOR will created by the private API, and then the caller 
will call the ConfigureMemoryManagementUnit to initialize the MMU first(may be 
fill the static page tables and so on).

But I thought about it again and it seems you are right, the 
ConfigureMemoryManagementUnit and discrptor creater as the public APIs are not 
appropriate. They are more suitable as some private APIs.

So, (Get|Set)MemoryRegionAttribute() will be the public APIs and the parameters 
will be the same with this change?

Hope to hear from you! :)

Thanks,
Chao
On 2023/11/30 10:25, Chao Li wrote:

Hi Ray,

Thanks for review, here are some of my thoughts:
On 2023/11/30 08:59, Ni, Ray wrote:

Chao,

Since the lib class is so general, I'd like to understand more details to make 
sure it can properly fit into any CPU arch.



In X86, cache setting is through MSRs and Page tables, and memory access 
control (read-only, not-present, non-executable) is through page tables.
Let me understand, 'cache setting' means does it access a certain 
address(probably a memory address) via cache? If so, I'd say the 'cache 
setting' should be a part of attributes.



This CpuMmuLib is to provide both services. How does LoongArch64 manage the 
cache settings and memory access control?

Is it proper to combine both services into one lib?
In LoongArch64, cache settings and memory access control are performed via page 
tables. Please check the patch 14 of this series.



If the backend silicon IP is the same one that supports the "one" lib design, 
can we refine the lib API a bit?
Yes, I think Attribute's instance family can be bear the memory access and 
cache setting. So what are you suggestions if we improve the lib API?



We have (Set|Get)MemoryRegionAttribute() and 
(Set|Clear)MemoryRegion(NoExec|ReadOnly). Can we merge them together?
Do you

Re: [edk2-devel] [PATCH v2] NetworkPkg: Triger regularly scan only if not connect to AP

[Heng Luo]

Hi Zack,
Could you please review the change?
Thanks,
Heng

> -Original Message-
> From: Kasbekar, Saloni 
> Sent: Saturday, December 2, 2023 5:25 AM
> To: Luo, Heng ; devel@edk2.groups.io
> Cc: Clark-williams, Zachary 
> Subject: RE: [PATCH v2] NetworkPkg: Triger regularly scan only if not connect
> to AP
> 
> Reviewed-by: Kasbekar, Saloni 
> 
> Thanks,
> Saloni
> 
> -Original Message-
> From: Luo, Heng 
> Sent: Monday, November 27, 2023 7:07 PM
> To: devel@edk2.groups.io
> Cc: Kasbekar, Saloni ; Clark-williams, Zachary
> 
> Subject: [PATCH v2] NetworkPkg: Triger regularly scan only if not connect to
> AP
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4605
> 
> When UEFI Wi-Fi is in BSS connected state, the platform is considered as a
> static and Wi-Fi roaming support is not needed.
> Wifi connection manager should not initiate Scan requests in this state affect
> BSS client connectivity and must be avoided.
> Triger regularly scan only if not connect to AP.
> 
> Signed-off-by: Heng Luo 
> Cc: Saloni Kasbekar 
> Cc: Zachary Clark-williams 
> ---
>  NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrImpl.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git
> a/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrImpl.c
> b/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrImpl.c
> index d1182e52bd..4c5460b65c 100644
> --- a/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrImpl.c
> +++ b/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrImpl.c
> @@ -1506,8 +1506,8 @@ WifiMgrOnTimerTick (
>}Nic->ScanTickTime++;-  if (((Nic->ScanTickTime >
> WIFI_SCAN_FREQUENCY) || Nic->OneTimeScanRequest) &&-  (Nic-
> >ScanState == WifiMgrScanFinished))+  if Nic->ScanTickTime >
> WIFI_SCAN_FREQUENCY) && (Nic->ConnectState != WifiMgrConnectedToAp))
> ||+   Nic->OneTimeScanRequest) && (Nic->ScanState ==
> WifiMgrScanFinished))   { Nic->OneTimeScanRequest = FALSE; Nic-
> >ScanTickTime   = 0;--
> 2.31.1.windows.1



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