date:20190815

Reviewed-by: Liming Gao 

>-Original Message-
>From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>Michael D Kinney
>Sent: Friday, August 16, 2019 10:15 AM
>To: devel@edk2.groups.io
>Cc: Justen, Jordan L ; Ni, Ray ;
>Andrew Fish 
>Subject: [edk2-devel] [Patch V4 10/10] BaseTools/tools_def.template: Add -
>gdwarf to XCODE5 X64
>
>Add -gdwarf to XCODE5 X64 builds to generate symbols for
>source level debug using lldb.
>
>Cc: Jordan Justen 
>Cc: Ray Ni 
>Cc: Michael D Kinney 
>Signed-off-by: Andrew Fish 
>---
> BaseTools/Conf/tools_def.template | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/BaseTools/Conf/tools_def.template
>b/BaseTools/Conf/tools_def.template
>index 26a2cf604f..8f0e6cb6c2 100755
>--- a/BaseTools/Conf/tools_def.template
>+++ b/BaseTools/Conf/tools_def.template
>@@ -2593,8 +2593,8 @@ RELEASE_XCODE5_X64_ASM_FLAGS  = -arch x86_64
> *_XCODE5_*_PP_FLAGS = -E -x assembler-with-cpp -include
>$(DEST_DIR_DEBUG)/AutoGen.h
> *_XCODE5_*_VFRPP_FLAGS  = -x c -E -P -DVFRCOMPILE -include
>$(DEST_DIR_DEBUG)/$(MODULE_NAME)StrDefs.h
>
>-  DEBUG_XCODE5_X64_CC_FLAGS   = -target x86_64-pc-win32-macho -c -g -
>Os   -Wall -Werror -Wextra -include AutoGen.h -funsigned-char -fno-ms-
>extensions -fno-stack-protector -fno-builtin -fshort-wchar -mno-implicit-float
>-mms-bitfields -Wno-unused-parameter -Wno-missing-braces -Wno-missing-
>field-initializers -Wno-tautological-compare -Wno-sign-compare -Wno-varargs
>-ftrap-function=undefined_behavior_has_been_optimized_away_by_clang -
>D NO_MSABI_VA_FUNCS $(PLATFORM_FLAGS)
>-  NOOPT_XCODE5_X64_CC_FLAGS   = -target x86_64-pc-win32-macho -c -g -
>O0   -Wall -Werror -Wextra -include AutoGen.h -funsigned-char -fno-ms-
>extensions -fno-stack-protector -fno-builtin -fshort-wchar -mno-implicit-float
>-mms-bitfields -Wno-unused-parameter -Wno-missing-braces -Wno-missing-
>field-initializers -Wno-tautological-compare -Wno-sign-compare -Wno-varargs
>-ftrap-function=undefined_behavior_has_been_optimized_away_by_clang -
>D NO_MSABI_VA_FUNCS $(PLATFORM_FLAGS)
>+  DEBUG_XCODE5_X64_CC_FLAGS   = -target x86_64-pc-win32-macho -c -g -
>gdwarf -Os   -Wall -Werror -Wextra -include AutoGen.h -funsigned-char -
>fno-ms-extensions -fno-stack-protector -fno-builtin -fshort-wchar -mno-
>implicit-float -mms-bitfields -Wno-unused-parameter -Wno-missing-braces -
>Wno-missing-field-initializers -Wno-tautological-compare -Wno-sign-compare
>-Wno-varargs -ftrap-
>function=undefined_behavior_has_been_optimized_away_by_clang -D
>NO_MSABI_VA_FUNCS $(PLATFORM_FLAGS)
>+  NOOPT_XCODE5_X64_CC_FLAGS   = -target x86_64-pc-win32-macho -c -g -
>gdwarf -O0   -Wall -Werror -Wextra -include AutoGen.h -funsigned-char -
>fno-ms-extensions -fno-stack-protector -fno-builtin -fshort-wchar -mno-
>implicit-float -mms-bitfields -Wno-unused-parameter -Wno-missing-braces -
>Wno-missing-field-initializers -Wno-tautological-compare -Wno-sign-compare
>-Wno-varargs -ftrap-
>function=undefined_behavior_has_been_optimized_away_by_clang -D
>NO_MSABI_VA_FUNCS $(PLATFORM_FLAGS)
> RELEASE_XCODE5_X64_CC_FLAGS   = -target x86_64-pc-win32-macho -c-Os
>-Wall -Werror -Wextra -include AutoGen.h -funsigned-char -fno-ms-
>extensions -fno-stack-protector -fno-builtin -fshort-wchar -mno-implicit-float
>-mms-bitfields -Wno-unused-parameter -Wno-missing-braces -Wno-missing-
>field-initializers -Wno-tautological-compare -Wno-sign-compare -Wno-varargs
>-Wno-unused-const-variable -ftrap-
>function=undefined_behavior_has_been_optimized_away_by_clang -D
>NO_MSABI_VA_FUNCS $(PLATFORM_FLAGS)
>
>
>###
>#
>--
>2.21.0.windows.1
>
>
>


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

View/Reply Online (#45788): https://edk2.groups.io/g/devel/message/45788
Mute This Topic: https://groups.io/mt/32894355/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by using CPUID(0x15) TSC leaf

Reviewed-by: Eric Dong 

> -Original Message-
> From: Kuo, Donald
> Sent: Thursday, August 15, 2019 5:11 PM
> To: devel@edk2.groups.io
> Cc: Ni, Ray ; Zeng, Star ; Dong, Eric
> ; Chan, Amy ; Chaganty,
> Rangasai V 
> Subject: [PATCH] UefiCpuPkg: Adding a new TSC library by using CPUID(0x15)
> TSC leaf
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1909
> 
> Cc: Ray Ni 
> Cc: Star Zeng 
> Cc: Eric Dong 
> Cc: Amy Chan 
> Cc: Rangasai V Chaganty 
> Signed-off-by: Donald Kuo 
> ---
>  UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c   |  41 +++
>  UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf |  35 +++
> UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni |  17 ++
>  UefiCpuPkg/Library/CpuTimerLib/CpuTimerLib.c   | 279
> +
>  UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.c|  85 +++
>  UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.inf  |  37 +++
> UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.uni  |  17 ++
>  UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.c|  58 +
>  UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.inf  |  36 +++
> UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.uni  |  17 ++
>  UefiCpuPkg/UefiCpuPkg.dec  |   8 +
>  UefiCpuPkg/UefiCpuPkg.dsc  |   3 +
>  UefiCpuPkg/UefiCpuPkg.uni  |  10 +
>  13 files changed, 643 insertions(+)
>  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
>  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
>  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni
>  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/CpuTimerLib.c
>  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.c
>  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.inf
>  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.uni
>  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.c
>  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.inf
>  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.uni
> 
> diff --git a/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
> b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
> new file mode 100644
> index 00..6ddf917bad
> --- /dev/null
> +++ b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
> @@ -0,0 +1,41 @@
> +/** @file
> +  CPUID Leaf 0x15 for Core Crystal Clock frequency instance as Base Timer
> Library.
> +
> +  Copyright (c) 2019 Intel Corporation. All rights reserved.
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#include 
> +#include 
> +#include 
> +
> +/**
> +  CPUID Leaf 0x15 for Core Crystal Clock Frequency.
> +
> +  The TSC counting frequency is determined by using CPUID leaf 0x15.
> Frequency in MHz = Core XTAL frequency * EBX/EAX.
> +  In newer flavors of the CPU, core xtal frequency is returned in ECX or 0 
> if not
> supported.
> +  @return The number of TSC counts per second.
> +
> +**/
> +UINT64
> +CpuidCoreClockCalculateTscFrequency (
> +  VOID
> +  );
> +
> +/**
> +  Internal function to retrieves the 64-bit frequency in Hz.
> +
> +  Internal function to retrieves the 64-bit frequency in Hz.
> +
> +  @return The frequency in Hz.
> +
> +**/
> +UINT64
> +InternalGetPerformanceCounterFrequency (
> +  VOID
> +  )
> +{
> +  return CpuidCoreClockCalculateTscFrequency (); }
> +
> diff --git a/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
> b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
> new file mode 100644
> index 00..fd93adc5f1
> --- /dev/null
> +++ b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
> @@ -0,0 +1,35 @@
> +## @file
> +#  Base CPU Timer Library
> +#
> +#  Provides basic timer support using CPUID Leaf 0x15 XTAL frequency.
> +The performance #  counter features are provided by the processors time
> stamp counter.
> +#
> +#  Copyright (c) 2019, Intel Corporation. All rights reserved. #
> +SPDX-License-Identifier: BSD-2-Clause-Patent # ##
> +
> +[Defines]
> +  INF_VERSION= 0x00010005
> +  BASE_NAME  = BaseCpuTimerLib
> +  FILE_GUID  = F10B5B91-D15A-496C-B044-B5235721AA08
> +  MODULE_TYPE= BASE
> +  VERSION_STRING = 1.0
> +  LIBRARY_CLASS  = TimerLib|SEC PEI_CORE PEIM
> +  MODULE_UNI_FILE= BaseCpuTimerLib.uni
> +
> +[Sources]
> +  CpuTimerLib.c
> +  BaseCpuTimerLib.c
> +
> +[Packages]
> +  MdePkg/MdePkg.dec
> +  UefiCpuPkg/UefiCpuPkg.dec
> +
> +[LibraryClasses]
> +  BaseLib
> +  PcdLib
> +  DebugLib
> +
> +[Pcd]
> +  gUefiCpuPkgTokenSpaceGuid.PcdCpuCoreCrystalClockFrequency  ##
> +CONSUMES
> diff --git a/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni
> b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni
> new file mode 100644
> index 00..fcf2b0fbcb
> --- /dev/null
> +++ b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni
> @@ -0,0 +1,17 @@
> +// /** @file
> +// Base CPU Timer Library

Re: [edk2-devel] [PATCH 1/1] UefiCpuPkg/Cpuid: Add description for parameter LeafFunction

Reviewed-by: Eric Dong 

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Zhang, Shenglei
> Sent: Thursday, August 15, 2019 4:15 PM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Ni, Ray ; Laszlo
> Ersek 
> Subject: [edk2-devel] [PATCH 1/1] UefiCpuPkg/Cpuid: Add description for
> parameter LeafFunction
> 
> LeafFunction needs to be described in comments.
> https://bugzilla.tianocore.org/show_bug.cgi?id=2052
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Signed-off-by: Shenglei Zhang 
> ---
>  UefiCpuPkg/Application/Cpuid/Cpuid.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/UefiCpuPkg/Application/Cpuid/Cpuid.c
> b/UefiCpuPkg/Application/Cpuid/Cpuid.c
> index 7a994eba9ac8..f39a7fb33ae5 100644
> --- a/UefiCpuPkg/Application/Cpuid/Cpuid.c
> +++ b/UefiCpuPkg/Application/Cpuid/Cpuid.c
> @@ -708,6 +708,8 @@ CpuidArchitecturalPerformanceMonitoring (
>  /**
>Display CPUID_EXTENDED_TOPOLOGY leafs for all supported levels.
> 
> +  @param[in] LeafFunction  Leaf function index for
> CPUID_EXTENDED_TOPOLOGY.
> +
>  **/
>  VOID
>  CpuidExtendedTopology (
> --
> 2.18.0.windows.1
> 
> 
> 


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

View/Reply Online (#45786): https://edk2.groups.io/g/devel/message/45786
Mute This Topic: https://groups.io/mt/32884640/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] ShellPkg/UefiShellAcpiViewCommandLib: Initialize local variables

2019-08-15 Thread Gao, Zhichao

Reviewed-by: Zhichao Gao 

Thanks,
Zhichao

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Zhang, Shenglei
> Sent: Thursday, August 15, 2019 1:42 PM
> To: devel@edk2.groups.io
> Cc: Carsey, Jaben ; Ni, Ray ;
> Gao, Zhichao 
> Subject: [edk2-devel] [PATCH 1/1] ShellPkg/UefiShellAcpiViewCommandLib:
> Initialize local variables
> 
> At latest edk2 version, there is build failure when building ShellPkg with
> VS2012x86, which results from uninitialized local variables.
> 
> Cc: Jaben Carsey 
> Cc: Ray Ni 
> Cc: Zhichao Gao 
> Signed-off-by: Shenglei Zhang 
> ---
>  .../Library/UefiShellAcpiViewCommandLib/AcpiParser.c   |  8 
>  .../Library/UefiShellAcpiViewCommandLib/AcpiView.c | 10 ++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
> index 2d6ff80e299e..94bafa22ef4c 100644
> --- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
> +++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
> @@ -121,6 +121,10 @@ VerifyChecksum (
>UINT8 Checksum;
>UINTN OriginalAttribute;
> 
> +  //
> +  // set local variables to suppress incorrect compiler/analyzer
> + warnings  //  OriginalAttribute = 0;
>ByteCount = 0;
>Checksum = 0;
> 
> @@ -472,6 +476,10 @@ ParseAcpi (
>BOOLEAN HighLight;
>UINTN   OriginalAttribute;
> 
> +  //
> +  // set local variables to suppress incorrect compiler/analyzer
> + warnings  //  OriginalAttribute = 0;
>Offset = 0;
> 
>// Increment the Indent
> diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiView.c
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiView.c
> index 9feb2df2078f..de0851dd5fba 100644
> --- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiView.c
> +++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiView.c
> @@ -211,6 +211,10 @@ ProcessTableReportOptions (
>BOOLEAN Log;
>BOOLEAN HighLight;
> 
> +  //
> +  // set local variables to suppress incorrect compiler/analyzer
> + warnings  //  OriginalAttribute = 0;
>SignaturePtr = (UINT8*)(UINTN)
>Log = FALSE;
>HighLight = GetColourHighlighting (); @@ -347,6 +351,12 @@ AcpiView (
>PARSE_ACPI_TABLE_PROCRsdpParserProc;
>BOOLEAN  Trace;
> 
> +  //
> +  // set local variables to suppress incorrect compiler/analyzer
> + warnings  //  EfiConfigurationTable = NULL;  OriginalAttribute = 0;
> +
>// Search the table for an entry that matches the ACPI Table Guid
>FoundAcpiTable = FALSE;
>for (Index = 0; Index < SystemTable->NumberOfTableEntries; Index++) {
> --
> 2.18.0.windows.1
> 
> 
> 


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

View/Reply Online (#45785): https://edk2.groups.io/g/devel/message/45785
Mute This Topic: https://groups.io/mt/32883914/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] ShellPkg/UefiShellAcpiViewCommandLib: Replace shift logical left

2019-08-15 Thread Gao, Zhichao

Reviewed-by: Zhichao Gao 

Thanks,
Zhichao

> -Original Message-
> From: Zhang, Shenglei
> Sent: Thursday, August 15, 2019 3:38 PM
> To: devel@edk2.groups.io
> Cc: Carsey, Jaben ; Ni, Ray ;
> Gao, Zhichao 
> Subject: [PATCH 1/1] ShellPkg/UefiShellAcpiViewCommandLib: Replace shift
> logical left
> 
> Replace the operation to shift logical left with the function LShiftU64, which
> has the same functionality.
> The original code causes ShellPkg build failure with build target"-b NOOPT".
> 
> Cc: Jaben Carsey 
> Cc: Ray Ni 
> Cc: Zhichao Gao 
> Signed-off-by: Shenglei Zhang 
> ---
>  ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
> index 2d6ff80e299e..2e6d99145beb 100644
> --- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
> +++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
> @@ -290,7 +290,7 @@ DumpUint64 (
> 
>Val = *(UINT32*)(Ptr + sizeof (UINT32));
> 
> -  Val <<= 32;
> +  LShiftU64(Val,32);
>Val |= (UINT64)*(UINT32*)Ptr;
> 
>Print (Format, Val);
> --
> 2.18.0.windows.1


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

View/Reply Online (#45784): https://edk2.groups.io/g/devel/message/45784
Mute This Topic: https://groups.io/mt/32884463/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v6 0/5] Build cache enhancement

2019-08-15 Thread Bob Feng

For this patch set,

Reviewed-by: Bob Feng 

-Original Message-
From: Shi, Steven 
Sent: Thursday, August 15, 2019 10:26 PM
To: devel@edk2.groups.io
Cc: Gao, Liming ; Feng, Bob C ; 
Rodriguez, Christian ; Johnson, Michael 
; ler...@redhat.com; leif.lindh...@linaro.org; 
af...@apple.com; Cetola, Stephano ; Kinney, Michael 
D ; Shi, Steven 
Subject: [PATCH v6 0/5] Build cache enhancement

From: "Shi, Steven" 

This patch set is for the 201908 stable tag

Enhance the edk2 build cache with below patches:
Patch 01/05: Improve the cache hit rate through new cache checkpoint and hash 
algorithm Patch 02/05: Print more info to explain why a module build cache miss 
Patch 03/05: Fix the unsafe [self.Arch][self.Name] key usage in build cache 
Patch 04/05  Add the GenFds multi-thread support in build cache Patch 05/05  
Improve the file saving and copying functions reliability in build cache


You can directly try this patch set in the branch:
https://github.com/shijunjing/edk2/tree/build_cache_improve_v6_3

V6:
In the patch 5, add error handling to skip hash calculation if find module 
cache already crashed

V5:
Fix the method name typo in Misc.py from EdkLogger.quite() to EdkLogger.quiet()

V4:
Change single global lock into two locks, which are cache_lock and file_lock, 
for better cache performance and IO reliability in windows

V3:
Add patch 5. To improve the autogen CopyFileOnChange() and SaveFileOnChange() 
functions reliability for build cache

V2:
Enhance the SaveHashChainFileToCache() function in ModuleAutoGen.py and not 
need to call f.close() in the "with open(xxx) as f:" block. The with block will 
close the file automatically

V1:
Initial patch set

Shi, Steven (5):
  BaseTools: Improve the cache hit in the edk2 build cache
  BaseTools: Print first cache missing file for build cachle
  BaseTools: Change the [Arch][Name] module key in Build cache
  BaseTools: Add GenFds multi-thread support in build cache
  BaseTools: Improve the file saving and copying reliability

 .../Source/Python/AutoGen/AutoGenWorker.py|  27 +-
 BaseTools/Source/Python/AutoGen/CacheIR.py|  29 +
 BaseTools/Source/Python/AutoGen/DataPipe.py   |   6 +
 BaseTools/Source/Python/AutoGen/GenC.py   |   0
 BaseTools/Source/Python/AutoGen/GenMake.py| 233 +++---
 .../Source/Python/AutoGen/ModuleAutoGen.py| 791 --
 BaseTools/Source/Python/Common/GlobalData.py  |  11 +
 BaseTools/Source/Python/Common/Misc.py|  44 +-
 BaseTools/Source/Python/build/build.py| 182 ++--
 9 files changed, 1073 insertions(+), 250 deletions(-)  mode change 100644 => 
100755 BaseTools/Source/Python/AutoGen/AutoGenWorker.py
 create mode 100755 BaseTools/Source/Python/AutoGen/CacheIR.py
 mode change 100644 => 100755 BaseTools/Source/Python/AutoGen/DataPipe.py
 mode change 100644 => 100755 BaseTools/Source/Python/AutoGen/GenC.py
 mode change 100644 => 100755 BaseTools/Source/Python/AutoGen/GenMake.py
 mode change 100644 => 100755 BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
 mode change 100644 => 100755 BaseTools/Source/Python/Common/GlobalData.py
 mode change 100644 => 100755 BaseTools/Source/Python/Common/Misc.py
 mode change 100644 => 100755 BaseTools/Source/Python/build/build.py

--
2.17.1


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

View/Reply Online (#45783): https://edk2.groups.io/g/devel/message/45783
Mute This Topic: https://groups.io/mt/32887324/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 00/11] Test against invalid pointers in acpiview

Krzysztof:
   Can you submit BZ in https://bugzilla.tianocore.org/ for this change? 

Thanks
Liming
>-Original Message-
>From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>Krzysztof Koch
>Sent: Thursday, August 15, 2019 9:11 PM
>To: devel@edk2.groups.io
>Cc: Carsey, Jaben ; Ni, Ray ; Gao,
>Zhichao ; sami.muja...@arm.com;
>matteo.carl...@arm.com; n...@arm.com
>Subject: [edk2-devel] [PATCH v1 00/11] Test against invalid pointers in
>acpiview
>
>Prevent the use of invalid pointers when parsing ACPI tables in the UEFI
>shell acpiview tool.
>
>The parsing of ACPI tables is often controlled with the values read
>earlier from the same table. For example, the 'Offset' or 'Count' fields
>found in a structure are later used to parse the substructures. If such
>fields lie outside the structure's buffer length provided, then there
>is a possibility for a wild or dangling pointer.
>
>Currently, if the ParseAcpi() function terminates early because the end
>of the input table data buffer has been reached, then the pointers
>which were supposed to be updated by this function are left untouched.
>This is a security issue as the values pointed to by these pointers are
>later used for flow control.
>
>This patch series aims to solve this security issue by explicitly
>initializing any pointers lying outside the input ACPI data buffer to
>NULL and testing for NULL whenever these pointers are dereferenced.
>
>Changes can be seet at:
>https://github.com/KrzysztofKoch1/edk2/tree/612_add_pointer_validation_
>v1
>
>Krzysztof Koch (11):
>  ShellPkg: acpiview: Set ItemPtr to NULL for unprocessed table fields
>  ShellPkg: acpiview: RSDP: Validate global pointer before use
>  ShellPkg: acpiview: FADT: Validate global pointer before use
>  ShellPkg: acpiview: SLIT: Validate global pointer before use
>  ShellPkg: acpiview: SLIT: Validate System Locality count
>  ShellPkg: acpiview: SRAT: Validate global pointers before use
>  ShellPkg: acpiview: MADT: Validate global pointers before use
>  ShellPkg: acpiview: PPTT: Validate global pointers before use
>  ShellPkg: acpiview: IORT: Validate global pointers before use
>  ShellPkg: acpiview: GTDT: Validate global pointers before use
>  ShellPkg: acpiview: DBG2: Validate global pointers before use
>
> ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c  |  9 
> ++-
> ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Dbg2/Dbg2Parser.c
>| 43 ++
> ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.c |
>14 +
> ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Gtdt/GtdtParser.c
>| 37 
> ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Iort/IortParser.c |
>52 +
>
>ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtParser.c
>| 13 +
> ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pptt/PpttParser.c |
>25 
> ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Rsdp/RsdpParser.c
>| 12 
> ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser.c | 61
>++--
> ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c |
>13 +
> 10 files changed, 272 insertions(+), 7 deletions(-)
>
>--
>'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
>
>
>
>


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

View/Reply Online (#45782): https://edk2.groups.io/g/devel/message/45782
Mute This Topic: https://groups.io/mt/32886564/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] CryptoPkg/OpensslLib: Add missing header files in INF file

Pushed at 8906f076de35b222a7d62bcf6ed1a4a2498a5791

Regards,
Jian


> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Wang, Jian J
> Sent: Thursday, August 15, 2019 4:59 PM
> To: Zhang, Shenglei ; devel@edk2.groups.io
> Cc: Ye, Ting 
> Subject: Re: [edk2-devel] [PATCH 1/1] CryptoPkg/OpensslLib: Add missing
> header files in INF file
> 
> 
> Reviewed-by: Jian J Wang 
> 
> > -Original Message-
> > From: Zhang, Shenglei
> > Sent: Tuesday, August 13, 2019 4:50 PM
> > To: devel@edk2.groups.io
> > Cc: Wang, Jian J ; Ye, Ting 
> > Subject: [PATCH 1/1] CryptoPkg/OpensslLib: Add missing header files in
> INF
> > file
> >
> > The header files are used but missing in INF,which causes
> > warning message when building them.
> > https://bugzilla.tianocore.org/show_bug.cgi?id=2036
> >
> > Cc: Jian Wang 
> > Cc: Ting Ye 
> > Signed-off-by: Shenglei Zhang 
> > ---
> >  CryptoPkg/Library/OpensslLib/OpensslLib.inf   | 59
> > +++
> >  .../Library/OpensslLib/OpensslLibCrypto.inf   | 53 -
> >  2 files changed, 111 insertions(+), 1 deletion(-)
> >
> > diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> > b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> > index 5f36edeeef3c..7432321fd431 100644
> > --- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> > +++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> > @@ -22,6 +22,8 @@ [Defines]
> >  #
> >
> >  [Sources]
> > +  buildinf.h
> > +  rand_pool_noise.h
> >$(OPENSSL_PATH)/e_os.h
> >  # Autogenerated files list starts here
> >$(OPENSSL_PATH)/crypto/aes/aes_cbc.c
> > @@ -32,7 +34,9 @@ [Sources]
> >$(OPENSSL_PATH)/crypto/aes/aes_misc.c
> >$(OPENSSL_PATH)/crypto/aes/aes_ofb.c
> >$(OPENSSL_PATH)/crypto/aes/aes_wrap.c
> > +  $(OPENSSL_PATH)/crypto/aes/aes_locl.h
> >$(OPENSSL_PATH)/crypto/aria/aria.c
> > +  $(OPENSSL_PATH)/crypto/arm_arch.h
> >$(OPENSSL_PATH)/crypto/asn1/a_bitstr.c
> >$(OPENSSL_PATH)/crypto/asn1/a_d2i_fp.c
> >$(OPENSSL_PATH)/crypto/asn1/a_digest.c
> > @@ -97,12 +101,21 @@ [Sources]
> >$(OPENSSL_PATH)/crypto/asn1/x_sig.c
> >$(OPENSSL_PATH)/crypto/asn1/x_spki.c
> >$(OPENSSL_PATH)/crypto/asn1/x_val.c
> > +  $(OPENSSL_PATH)/crypto/asn1/standard_methods.h
> > +  $(OPENSSL_PATH)/crypto/asn1/charmap.h
> > +  $(OPENSSL_PATH)/crypto/asn1/tbl_standard.h
> > +  $(OPENSSL_PATH)/crypto/asn1/asn1_item_list.h
> > +  $(OPENSSL_PATH)/crypto/asn1/asn1_locl.h
> >$(OPENSSL_PATH)/crypto/async/arch/async_null.c
> >$(OPENSSL_PATH)/crypto/async/arch/async_posix.c
> >$(OPENSSL_PATH)/crypto/async/arch/async_win.c
> >$(OPENSSL_PATH)/crypto/async/async.c
> >$(OPENSSL_PATH)/crypto/async/async_err.c
> >$(OPENSSL_PATH)/crypto/async/async_wait.c
> > +  $(OPENSSL_PATH)/crypto/async/arch/async_win.h
> > +  $(OPENSSL_PATH)/crypto/async/async_locl.h
> > +  $(OPENSSL_PATH)/crypto/async/arch/async_posix.h
> > +  $(OPENSSL_PATH)/crypto/async/arch/async_null.h
> >$(OPENSSL_PATH)/crypto/bio/b_addr.c
> >$(OPENSSL_PATH)/crypto/bio/b_dump.c
> >$(OPENSSL_PATH)/crypto/bio/b_sock.c
> > @@ -125,6 +138,7 @@ [Sources]
> >$(OPENSSL_PATH)/crypto/bio/bss_mem.c
> >$(OPENSSL_PATH)/crypto/bio/bss_null.c
> >$(OPENSSL_PATH)/crypto/bio/bss_sock.c
> > +  $(OPENSSL_PATH)/crypto/bio/bio_lcl.h
> >$(OPENSSL_PATH)/crypto/bn/bn_add.c
> >$(OPENSSL_PATH)/crypto/bn/bn_asm.c
> >$(OPENSSL_PATH)/crypto/bn/bn_blind.c
> > @@ -156,6 +170,9 @@ [Sources]
> >$(OPENSSL_PATH)/crypto/bn/bn_srp.c
> >$(OPENSSL_PATH)/crypto/bn/bn_word.c
> >$(OPENSSL_PATH)/crypto/bn/bn_x931p.c
> > +  $(OPENSSL_PATH)/crypto/bn/rsaz_exp.h
> > +  $(OPENSSL_PATH)/crypto/bn/bn_prime.h
> > +  $(OPENSSL_PATH)/crypto/bn/bn_lcl.h
> >$(OPENSSL_PATH)/crypto/buffer/buf_err.c
> >$(OPENSSL_PATH)/crypto/buffer/buffer.c
> >$(OPENSSL_PATH)/crypto/cmac/cm_ameth.c
> > @@ -164,6 +181,7 @@ [Sources]
> >$(OPENSSL_PATH)/crypto/comp/c_zlib.c
> >$(OPENSSL_PATH)/crypto/comp/comp_err.c
> >$(OPENSSL_PATH)/crypto/comp/comp_lib.c
> > +  $(OPENSSL_PATH)/crypto/comp/comp_lcl.h
> >$(OPENSSL_PATH)/crypto/conf/conf_api.c
> >$(OPENSSL_PATH)/crypto/conf/conf_def.c
> >$(OPENSSL_PATH)/crypto/conf/conf_err.c
> > @@ -172,6 +190,8 @@ [Sources]
> >$(OPENSSL_PATH)/crypto/conf/conf_mod.c
> >$(OPENSSL_PATH)/crypto/conf/conf_sap.c
> >$(OPENSSL_PATH)/crypto/conf/conf_ssl.c
> > +  $(OPENSSL_PATH)/crypto/conf/conf_lcl.h
> > +  $(OPENSSL_PATH)/crypto/conf/conf_def.h
> >$(OPENSSL_PATH)/crypto/cpt_err.c
> >$(OPENSSL_PATH)/crypto/cryptlib.c
> >$(OPENSSL_PATH)/crypto/ctype.c
> > @@ -195,6 +215,8 @@ [Sources]
> >$(OPENSSL_PATH)/crypto/des/set_key.c
> >$(OPENSSL_PATH)/crypto/des/str2key.c
> >$(OPENSSL_PATH)/crypto/des/xcbc_enc.c
> > +  $(OPENSSL_PATH)/crypto/des/spr.h
> > +  $(OPENSSL_PATH)/crypto/des/des_locl.h
> >$(OPENSSL_PATH)/crypto/dh/dh_ameth.c
> >$(OPENSSL_PATH)/crypto/dh/dh_asn1.c
> >$(OPENSSL_PATH)/crypto/dh/dh_check.c
>

[edk2-devel] [Patch v4 5/6] UefiCpuPkg/RegisterCpuFeaturesLib: Supports test then write new value logic.

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

Supports new logic which test current value before write new value.
Only write new value when current value not same as new value.

Signed-off-by: Eric Dong 
Cc: Ray Ni 
Acked-by: Laszlo Ersek 
---
 .../CpuFeaturesInitialize.c   | 31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c 
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
index 63bc50a55f..0a4fcff033 100644
--- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
+++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
@@ -826,6 +826,7 @@ ProgramProcessorRegister (
   UINTN ValidThreadCount;
   UINT32*ValidCoreCountPerPackage;
   EFI_STATUSStatus;
+  UINT64CurrentValue;
 
   //
   // Traverse Register Table of this logical processor
@@ -848,7 +849,16 @@ ProgramProcessorRegister (
   if (EFI_ERROR (Status)) {
 break;
   }
-
+  if (RegisterTableEntry->TestThenWrite) {
+CurrentValue = BitFieldRead64 (
+ Value,
+ RegisterTableEntry->ValidBitStart,
+ RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1
+ );
+if (CurrentValue == RegisterTableEntry->Value) {
+  break;
+}
+  }
   Value = (UINTN) BitFieldWrite64 (
 Value,
 RegisterTableEntry->ValidBitStart,
@@ -857,10 +867,29 @@ ProgramProcessorRegister (
 );
   ReadWriteCr (RegisterTableEntry->Index, FALSE, );
   break;
+
 //
 // The specified register is Model Specific Register
 //
 case Msr:
+  if (RegisterTableEntry->TestThenWrite) {
+Value = (UINTN)AsmReadMsr64 (RegisterTableEntry->Index);
+if (RegisterTableEntry->ValidBitLength >= 64) {
+  if (Value == RegisterTableEntry->Value) {
+break;
+  }
+} else {
+  CurrentValue = BitFieldRead64 (
+   Value,
+   RegisterTableEntry->ValidBitStart,
+   RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1
+   );
+  if (CurrentValue == RegisterTableEntry->Value) {
+break;
+  }
+}
+  }
+
   if (RegisterTableEntry->ValidBitLength >= 64) {
 //
 // If length is not less than 64 bits, then directly write without 
reading
-- 
2.21.0.windows.1


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

View/Reply Online (#45778): https://edk2.groups.io/g/devel/message/45778
Mute This Topic: https://groups.io/mt/32894962/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [Patch v4 3/6] UefiCpuPkg/PiSmmCpuDxeSmm: Supports test then write new value logic.

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

Supports new logic which test current value before write new value.
Only write new value when current value not same as new value.

Signed-off-by: Eric Dong 
Cc: Ray Ni 
Reviewed-by: Laszlo Ersek 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
index 627a3b87ac..ba5cc0194c 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
@@ -241,6 +241,7 @@ ProgramProcessorRegister (
   UINTN ValidThreadCount;
   UINT32*ValidCoreCountPerPackage;
   EFI_STATUSStatus;
+  UINT64CurrentValue;
 
   //
   // Traverse Register Table of this logical processor
@@ -263,6 +264,16 @@ ProgramProcessorRegister (
   if (EFI_ERROR (Status)) {
 break;
   }
+  if (RegisterTableEntry->TestThenWrite) {
+CurrentValue = BitFieldRead64 (
+ Value,
+ RegisterTableEntry->ValidBitStart,
+ RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1
+ );
+if (CurrentValue == RegisterTableEntry->Value) {
+  break;
+}
+  }
   Value = (UINTN) BitFieldWrite64 (
 Value,
 RegisterTableEntry->ValidBitStart,
@@ -275,6 +286,24 @@ ProgramProcessorRegister (
 // The specified register is Model Specific Register
 //
 case Msr:
+  if (RegisterTableEntry->TestThenWrite) {
+Value = (UINTN)AsmReadMsr64 (RegisterTableEntry->Index);
+if (RegisterTableEntry->ValidBitLength >= 64) {
+  if (Value == RegisterTableEntry->Value) {
+break;
+  }
+} else {
+  CurrentValue = BitFieldRead64 (
+   Value,
+   RegisterTableEntry->ValidBitStart,
+   RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1
+   );
+  if (CurrentValue == RegisterTableEntry->Value) {
+break;
+  }
+}
+  }
+
   //
   // If this function is called to restore register setting after INIT 
signal,
   // there is no need to restore MSRs in register table.
-- 
2.21.0.windows.1


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

View/Reply Online (#45776): https://edk2.groups.io/g/devel/message/45776
Mute This Topic: https://groups.io/mt/32894960/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/6] UefiCpuPkg/RegisterCpuFeaturesLib: Add "Test Then Write" Macros.

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

Add below new micros which test the current value before write the new
value. Only write new value when current value not same as new value.
  CPU_REGISTER_TABLE_TEST_THEN_WRITE32
  CPU_REGISTER_TABLE_TEST_THEN_WRITE64
  CPU_REGISTER_TABLE_TEST_THEN_WRITE_FIELD

Also add below API:
  CpuRegisterTableTestThenWrite

Signed-off-by: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Cc: Star Zeng 
---
 UefiCpuPkg/Include/AcpiCpuData.h  |  3 +-
 .../Include/Library/RegisterCpuFeaturesLib.h  | 91 +++
 .../RegisterCpuFeaturesLib.c  | 44 -
 3 files changed, 134 insertions(+), 4 deletions(-)

diff --git a/UefiCpuPkg/Include/AcpiCpuData.h b/UefiCpuPkg/Include/AcpiCpuData.h
index b963a2f592..77da5d4455 100644
--- a/UefiCpuPkg/Include/AcpiCpuData.h
+++ b/UefiCpuPkg/Include/AcpiCpuData.h
@@ -78,7 +78,8 @@ typedef struct {
   UINT32 Index; // offset 4 - 7
   UINT8  ValidBitStart; // offset 8
   UINT8  ValidBitLength;// offset 9
-  UINT16 Reserved;  // offset 10 - 11
+  BOOLEANTestThenWrite; // offset 10
+  UINT8  Reserved1; // offset 11
   UINT32 HighIndex; // offset 12-15, only valid for 
MemoryMapped
   UINT64 Value; // offset 16-23
 } CPU_REGISTER_TABLE_ENTRY;
diff --git a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h 
b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
index e420e7f075..5bd464b32e 100644
--- a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
+++ b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
@@ -348,6 +348,32 @@ CpuRegisterTableWrite (
   IN UINT64  Value
   );
 
+/**
+  Adds an entry in specified register table.
+
+  This function adds an entry in specified register table, with given register 
type,
+  register index, bit section and value.
+
+  Driver will  test the current value before setting new value.
+
+  @param[in]  ProcessorNumber  The index of the CPU to add a register table 
entry
+  @param[in]  RegisterType Type of the register to program
+  @param[in]  IndexIndex of the register to program
+  @param[in]  ValueMaskMask of bits in register to write
+  @param[in]  ValueValue to write
+
+  @note This service could be called by BSP only.
+**/
+VOID
+EFIAPI
+CpuRegisterTableTestThenWrite (
+  IN UINTN   ProcessorNumber,
+  IN REGISTER_TYPE   RegisterType,
+  IN UINT64  Index,
+  IN UINT64  ValueMask,
+  IN UINT64  Value
+  );
+
 /**
   Adds an entry in specified Pre-SMM register table.
 
@@ -390,6 +416,26 @@ PreSmmCpuRegisterTableWrite (
 CpuRegisterTableWrite (ProcessorNumber, RegisterType, Index, MAX_UINT32, 
Value);  \
   } while(FALSE);
 
+/**
+  Adds a 32-bit register write entry in specified register table.
+
+  This macro adds an entry in specified register table, with given register 
type,
+  register index, and value.
+
+  Driver will  test the current value before setting new value.
+
+  @param[in]  ProcessorNumber  The index of the CPU to add a register table 
entry.
+  @param[in]  RegisterType Type of the register to program
+  @param[in]  IndexIndex of the register to program
+  @param[in]  ValueValue to write
+
+  @note This service could be called by BSP only.
+**/
+#define CPU_REGISTER_TABLE_TEST_THEN_WRITE32(ProcessorNumber, RegisterType, 
Index, Value) \
+  do { 
   \
+CpuRegisterTableTestThenWrite (ProcessorNumber, RegisterType, Index, 
MAX_UINT32, Value);  \
+  } while(FALSE);
+
 /**
   Adds a 64-bit register write entry in specified register table.
 
@@ -408,6 +454,26 @@ PreSmmCpuRegisterTableWrite (
 CpuRegisterTableWrite (ProcessorNumber, RegisterType, Index, MAX_UINT64, 
Value);  \
   } while(FALSE);
 
+/**
+  Adds a 64-bit register write entry in specified register table.
+
+  This macro adds an entry in specified register table, with given register 
type,
+  register index, and value.
+
+  Driver will  test the current value before setting new value.
+
+  @param[in]  ProcessorNumber  The index of the CPU to add a register table 
entry.
+  @param[in]  RegisterType Type of the register to program
+  @param[in]  IndexIndex of the register to program
+  @param[in]  ValueValue to write
+
+  @note This service could be called by BSP only.
+**/
+#define CPU_REGISTER_TABLE_TEST_THEN_WRITE64(ProcessorNumber, RegisterType, 
Index, Value) \
+  do { 
   \
+CpuRegisterTableTestThenWrite (ProcessorNumber, RegisterType, Index, 
MAX_UINT64, Value);  \
+  } while(FALSE);
+
 /**
   Adds a bit field write entry in specified register table.
 
@@ -431,6 +497,31 @@

[edk2-devel] [Patch v4 6/6] UefiCpuPkg/CpuCommonFeaturesLib: Use new macros.

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

Below code is current implementation:
  if (MsrRegister[ProcessorNumber].Bits.Lock == 0) {
CPU_REGISTER_TABLE_WRITE_FIELD (
  ProcessorNumber,
  Msr,
  MSR_IA32_FEATURE_CONTROL,
  MSR_IA32_FEATURE_CONTROL_REGISTER,
  Bits.Lock,
  1
);
  }

1. In first normal boot, the Bits.Lock is 0, 1 will be added
   into the register table and then will set to the MSR.
2. Trig warm reboot, MSR value preserves. After normal boot phase,
   the Bits.Lock is 1, so it will not be added into the register
   table during the warm reboot phase.
3. Trig S3 then resume, the Bits.Lock change to 0 and Bits.Lock is
   not added in register table, so it's still 0 after resume. This
   is not an expect behavior. The expect value is the value should
   always 1 after booting or resuming from S3.

The root cause for this issue is
1. driver bases on current value to insert the "set value action" to
   the register table.
2. Some MSRs may reserve their value during warm reboot.

The solution for this issue is using new added macros for the MSRs which
preserve value during warm reboot.

Signed-off-by: Eric Dong 
Cc: Ray Ni 
Acked-by: Laszlo Ersek 
---
 .../CpuCommonFeaturesLib/CpuCommonFeatures.h  |  15 --
 .../CpuCommonFeaturesLib.c|   8 +-
 .../CpuCommonFeaturesLib/FeatureControl.c | 141 ++
 .../CpuCommonFeaturesLib/MachineCheck.c   |  23 ++-
 4 files changed, 58 insertions(+), 129 deletions(-)

diff --git a/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeatures.h 
b/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeatures.h
index 25d0174727..b2390e6c39 100644
--- a/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeatures.h
+++ b/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeatures.h
@@ -848,21 +848,6 @@ X2ApicInitialize (
   IN BOOLEAN   State
   );
 
-/**
-  Prepares for the data used by CPU feature detection and initialization.
-
-  @param[in]  NumberOfProcessors  The number of CPUs in the platform.
-
-  @return  Pointer to a buffer of CPU related configuration data.
-
-  @note This service could be called by BSP only.
-**/
-VOID *
-EFIAPI
-FeatureControlGetConfigData (
-  IN UINTN   NumberOfProcessors
-  );
-
 /**
   Prepares for the data used by CPU feature detection and initialization.
 
diff --git a/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeaturesLib.c 
b/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeaturesLib.c
index fd43b8d662..f0dd3a3b43 100644
--- a/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeaturesLib.c
+++ b/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeaturesLib.c
@@ -91,7 +91,7 @@ CpuCommonFeaturesLibConstructor (
   if (IsCpuFeatureSupported (CPU_FEATURE_LOCK_FEATURE_CONTROL_REGISTER)) {
 Status = RegisterCpuFeature (
"Lock Feature Control Register",
-   FeatureControlGetConfigData,
+   NULL,
LockFeatureControlRegisterSupport,
LockFeatureControlRegisterInitialize,
CPU_FEATURE_LOCK_FEATURE_CONTROL_REGISTER,
@@ -102,7 +102,7 @@ CpuCommonFeaturesLibConstructor (
   if (IsCpuFeatureSupported (CPU_FEATURE_SMX)) {
 Status = RegisterCpuFeature (
"SMX",
-   FeatureControlGetConfigData,
+   NULL,
SmxSupport,
SmxInitialize,
CPU_FEATURE_SMX,
@@ -114,7 +114,7 @@ CpuCommonFeaturesLibConstructor (
   if (IsCpuFeatureSupported (CPU_FEATURE_VMX)) {
 Status = RegisterCpuFeature (
"VMX",
-   FeatureControlGetConfigData,
+   NULL,
VmxSupport,
VmxInitialize,
CPU_FEATURE_VMX,
@@ -214,7 +214,7 @@ CpuCommonFeaturesLibConstructor (
   if (IsCpuFeatureSupported (CPU_FEATURE_LMCE)) {
 Status = RegisterCpuFeature (
"LMCE",
-   FeatureControlGetConfigData,
+   NULL,
LmceSupport,
LmceInitialize,
CPU_FEATURE_LMCE,
diff --git a/UefiCpuPkg/Library/CpuCommonFeaturesLib/FeatureControl.c 
b/UefiCpuPkg/Library/CpuCommonFeaturesLib/FeatureControl.c
index 3712ef1e5c..6679df8ba4 100644
--- a/UefiCpuPkg/Library/CpuCommonFeaturesLib/FeatureControl.c
+++ b/UefiCpuPkg/Library/CpuCommonFeaturesLib/FeatureControl.c
@@ -8,28 +8,6 @@
 
 #include "CpuCommonFeatures.h"
 
-/**
-  Prepares for the data used by CPU feature detection and initialization.
-
-  @param[in]  NumberOfProcessors  The number of CPUs in the platform.
-
-  @return  Pointer to a buffer of CPU related configuration data.
-
-  @note This service could be called by BSP only.
-**/
-VOID *
-EFIAPI
-FeatureControlGetConfigData (
-  IN UINTN   NumberOfProcessors
-  )
-{
-  VOID  *ConfigData;
-
-  ConfigData = AllocateZeroPool (sizeof (MSR_IA32_FEATURE_CONTROL_REGISTER) * 
NumberOfProcessors);
-  ASSERT (ConfigData != NULL);

[edk2-devel] [Patch v4 2/6] UefiCpuPkg/PiSmmCpuDxeSmm: Combine CR read/write action.

Signed-off-by: Eric Dong 
Cc: Ray Ni 
Reviewed-by: Laszlo Ersek 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c | 104 ++
 1 file changed, 62 insertions(+), 42 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
index d8c6b19ead..627a3b87ac 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
@@ -159,6 +159,58 @@ S3WaitForSemaphore (
  ) != Value);
 }
 
+/**
+  Read / write CR value.
+
+  @param[in]  CrIndex The CR index which need to read/write.
+  @param[in]  ReadRead or write. TRUE is read.
+  @param[in,out]  CrValue CR value.
+
+  @retvalEFI_SUCCESS means read/write success, else return EFI_UNSUPPORTED.
+**/
+UINTN
+ReadWriteCr (
+  IN UINT32   CrIndex,
+  IN BOOLEAN  Read,
+  IN OUT UINTN*CrValue
+  )
+{
+  switch (CrIndex) {
+  case 0:
+if (Read) {
+  *CrValue = AsmReadCr0 ();
+} else {
+  AsmWriteCr0 (*CrValue);
+}
+break;
+  case 2:
+if (Read) {
+  *CrValue = AsmReadCr2 ();
+} else {
+  AsmWriteCr2 (*CrValue);
+}
+break;
+  case 3:
+if (Read) {
+  *CrValue = AsmReadCr3 ();
+} else {
+  AsmWriteCr3 (*CrValue);
+}
+break;
+  case 4:
+if (Read) {
+  *CrValue = AsmReadCr4 ();
+} else {
+  AsmWriteCr4 (*CrValue);
+}
+break;
+  default:
+return EFI_UNSUPPORTED;;
+  }
+
+  return EFI_SUCCESS;
+}
+
 /**
   Initialize the CPU registers from a register table.
 
@@ -188,6 +240,7 @@ ProgramProcessorRegister (
   UINTN ProcessorIndex;
   UINTN ValidThreadCount;
   UINT32*ValidCoreCountPerPackage;
+  EFI_STATUSStatus;
 
   //
   // Traverse Register Table of this logical processor
@@ -206,50 +259,17 @@ ProgramProcessorRegister (
 // The specified register is Control Register
 //
 case ControlRegister:
-  switch (RegisterTableEntry->Index) {
-  case 0:
-Value = AsmReadCr0 ();
-Value = (UINTN) BitFieldWrite64 (
-  Value,
-  RegisterTableEntry->ValidBitStart,
-  RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1,
-  (UINTN) RegisterTableEntry->Value
-  );
-AsmWriteCr0 (Value);
-break;
-  case 2:
-Value = AsmReadCr2 ();
-Value = (UINTN) BitFieldWrite64 (
-  Value,
-  RegisterTableEntry->ValidBitStart,
-  RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1,
-  (UINTN) RegisterTableEntry->Value
-  );
-AsmWriteCr2 (Value);
-break;
-  case 3:
-Value = AsmReadCr3 ();
-Value = (UINTN) BitFieldWrite64 (
-  Value,
-  RegisterTableEntry->ValidBitStart,
-  RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1,
-  (UINTN) RegisterTableEntry->Value
-  );
-AsmWriteCr3 (Value);
-break;
-  case 4:
-Value = AsmReadCr4 ();
-Value = (UINTN) BitFieldWrite64 (
-  Value,
-  RegisterTableEntry->ValidBitStart,
-  RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1,
-  (UINTN) RegisterTableEntry->Value
-  );
-AsmWriteCr4 (Value);
-break;
-  default:
+  Status = ReadWriteCr (RegisterTableEntry->Index, TRUE, );
+  if (EFI_ERROR (Status)) {
 break;
   }
+  Value = (UINTN) BitFieldWrite64 (
+Value,
+RegisterTableEntry->ValidBitStart,
+RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1,
+RegisterTableEntry->Value
+);
+  ReadWriteCr (RegisterTableEntry->Index, FALSE, );
   break;
 //
 // The specified register is Model Specific Register
-- 
2.21.0.windows.1


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

View/Reply Online (#45775): https://edk2.groups.io/g/devel/message/45775
Mute This Topic: https://groups.io/mt/32894959/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [Patch v4 0/6] Add "test then write" mechanism

v4 changes:
1. Split Reserved field and use one byte as TestThenWrite field.

v3 changes:
1. Avoid changing exist API CpuRegisterTableWrite, add new API 
CpuRegisterTableTestThenWrite which align new adds macros.
Only 1/6 patch been changed in v3.

V2 changes:
1. Split CR read/write action in to one discrete patch 2. Keep the old logic 
which continue the process if error found.

Below code is current implementation:
  if (MsrRegister[ProcessorNumber].Bits.Lock == 0) {
CPU_REGISTER_TABLE_WRITE_FIELD (
  ProcessorNumber,
  Msr,
  MSR_IA32_FEATURE_CONTROL,
  MSR_IA32_FEATURE_CONTROL_REGISTER,
  Bits.Lock,
  1
);
  }

With below steps, the Bits.Lock bit will lose its value:
1. Trig normal boot, the Bits.Lock is 0. 1 will be added
   into the register table and then will set to the MSR.
2. Trig warm reboot, MSR value preserves. After normal boot phase,
   the Bits.Lock is 1, so it will not be added into the register
   table during the warm reboot phase.
3. Trig S3 then resume, the Bits.Lock change to 0 and Bits.Lock is
   not added in register table during normal boot phase. so it's
   still 0 after resume. 
This is not an expect behavior. The expect result is the value should always 1 
after booting or resuming from S3.

The root cause for this issue is
1. driver bases on current value to insert the "set value action" to
   the register table.
2. Some MSRs may reserve their value during warm reboot. So the insert
   action may be skip after warm reboot.

The solution for this issue is:
1. Always add "Test then Set" action for above referred MSRs.
2. Detect current value before set new value. Only set new value when
   current value not same as new value.

Cc: Ray Ni 
Cc: Laszlo Ersek 


Eric Dong (6):
  UefiCpuPkg/RegisterCpuFeaturesLib: Add "Test Then Write" Macros.
  UefiCpuPkg/PiSmmCpuDxeSmm: Combine CR read/write action.
  UefiCpuPkg/PiSmmCpuDxeSmm: Supports test then write new value logic.
  UefiCpuPkg/RegisterCpuFeaturesLib: Combine CR read/write action.
  UefiCpuPkg/RegisterCpuFeaturesLib: Supports test then write new value
logic.
  UefiCpuPkg/CpuCommonFeaturesLib: Use new macros.

 UefiCpuPkg/Include/AcpiCpuData.h  |   1 +
 .../Include/Library/RegisterCpuFeaturesLib.h  |  91 +++
 .../CpuCommonFeaturesLib/CpuCommonFeatures.h  |  15 --
 .../CpuCommonFeaturesLib.c|   8 +-
 .../CpuCommonFeaturesLib/FeatureControl.c | 141 ++
 .../CpuCommonFeaturesLib/MachineCheck.c   |  23 ++-
 .../CpuFeaturesInitialize.c   | 139 +++--
 .../RegisterCpuFeaturesLib.c  |  45 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c | 133 +++--
 9 files changed, 375 insertions(+), 221 deletions(-)

-- 
2.21.0.windows.1


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

View/Reply Online (#45773): https://edk2.groups.io/g/devel/message/45773
Mute This Topic: https://groups.io/mt/32894957/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [Patch v4 4/6] UefiCpuPkg/RegisterCpuFeaturesLib: Combine CR read/write action.

Signed-off-by: Eric Dong 
Cc: Ray Ni 
Acked-by: Laszlo Ersek 
---
 .../CpuFeaturesInitialize.c   | 110 ++
 1 file changed, 63 insertions(+), 47 deletions(-)

diff --git a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c 
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
index fb0535edd6..63bc50a55f 100644
--- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
+++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
@@ -744,6 +744,58 @@ LibWaitForSemaphore (
  ) != Value);
 }
 
+/**
+  Read / write CR value.
+
+  @param[in]  CrIndex The CR index which need to read/write.
+  @param[in]  ReadRead or write. TRUE is read.
+  @param[in,out]  CrValue CR value.
+
+  @retvalEFI_SUCCESS means read/write success, else return EFI_UNSUPPORTED.
+**/
+UINTN
+ReadWriteCr (
+  IN UINT32   CrIndex,
+  IN BOOLEAN  Read,
+  IN OUT UINTN*CrValue
+  )
+{
+  switch (CrIndex) {
+  case 0:
+if (Read) {
+  *CrValue = AsmReadCr0 ();
+} else {
+  AsmWriteCr0 (*CrValue);
+}
+break;
+  case 2:
+if (Read) {
+  *CrValue = AsmReadCr2 ();
+} else {
+  AsmWriteCr2 (*CrValue);
+}
+break;
+  case 3:
+if (Read) {
+  *CrValue = AsmReadCr3 ();
+} else {
+  AsmWriteCr3 (*CrValue);
+}
+break;
+  case 4:
+if (Read) {
+  *CrValue = AsmReadCr4 ();
+} else {
+  AsmWriteCr4 (*CrValue);
+}
+break;
+  default:
+return EFI_UNSUPPORTED;;
+  }
+
+  return EFI_SUCCESS;
+}
+
 /**
   Initialize the CPU registers from a register table.
 
@@ -773,6 +825,7 @@ ProgramProcessorRegister (
   UINTN ProcessorIndex;
   UINTN ValidThreadCount;
   UINT32*ValidCoreCountPerPackage;
+  EFI_STATUSStatus;
 
   //
   // Traverse Register Table of this logical processor
@@ -791,55 +844,18 @@ ProgramProcessorRegister (
 // The specified register is Control Register
 //
 case ControlRegister:
-  switch (RegisterTableEntry->Index) {
-  case 0:
-Value = AsmReadCr0 ();
-Value = (UINTN) BitFieldWrite64 (
-  Value,
-  RegisterTableEntry->ValidBitStart,
-  RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1,
-  RegisterTableEntry->Value
-  );
-AsmWriteCr0 (Value);
-break;
-  case 2:
-Value = AsmReadCr2 ();
-Value = (UINTN) BitFieldWrite64 (
-  Value,
-  RegisterTableEntry->ValidBitStart,
-  RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1,
-  RegisterTableEntry->Value
-  );
-AsmWriteCr2 (Value);
-break;
-  case 3:
-Value = AsmReadCr3 ();
-Value = (UINTN) BitFieldWrite64 (
-  Value,
-  RegisterTableEntry->ValidBitStart,
-  RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1,
-  RegisterTableEntry->Value
-  );
-AsmWriteCr3 (Value);
-break;
-  case 4:
-Value = AsmReadCr4 ();
-Value = (UINTN) BitFieldWrite64 (
-  Value,
-  RegisterTableEntry->ValidBitStart,
-  RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1,
-  RegisterTableEntry->Value
-  );
-AsmWriteCr4 (Value);
-break;
-  case 8:
-//
-//  Do we need to support CR8?
-//
-break;
-  default:
+  Status = ReadWriteCr (RegisterTableEntry->Index, TRUE, );
+  if (EFI_ERROR (Status)) {
 break;
   }
+
+  Value = (UINTN) BitFieldWrite64 (
+Value,
+RegisterTableEntry->ValidBitStart,
+RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1,
+RegisterTableEntry->Value
+);
+  ReadWriteCr (RegisterTableEntry->Index, FALSE, );
   break;
 //
 // The specified register is Model Specific Register
-- 
2.21.0.windows.1


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

View/Reply Online (#45777): https://edk2.groups.io/g/devel/message/45777
Mute This Topic: https://groups.io/mt/32894961/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch v3 1/6] UefiCpuPkg/RegisterCpuFeaturesLib: Add "Test Then Write" Macros.

Eric:

>-Original Message-
>From: Dong, Eric
>Sent: Friday, August 16, 2019 10:20 AM
>To: Zeng, Star ; devel@edk2.groups.io
>Cc: Ni, Ray ; Laszlo Ersek ; Yao,
>Jiewen ; Gao, Liming ;
>Kinney, Michael D 
>Subject: RE: [Patch v3 1/6] UefiCpuPkg/RegisterCpuFeaturesLib: Add "Test
>Then Write" Macros.
>
>
>
>> -Original Message-
>> From: Zeng, Star
>> Sent: Friday, August 16, 2019 10:08 AM
>> To: Dong, Eric ; devel@edk2.groups.io
>> Cc: Ni, Ray ; Laszlo Ersek ; Yao,
>> Jiewen ; Gao, Liming ;
>Kinney,
>> Michael D ; Zeng, Star 
>> Subject: RE: [Patch v3 1/6] UefiCpuPkg/RegisterCpuFeaturesLib: Add "Test
>> Then Write" Macros.
>>
>>
>>
>> > -Original Message-
>> > From: Dong, Eric
>> > Sent: Friday, August 16, 2019 9:27 AM
>> > To: Zeng, Star ; devel@edk2.groups.io
>> > Cc: Ni, Ray ; Laszlo Ersek 
>> > Subject: RE: [Patch v3 1/6] UefiCpuPkg/RegisterCpuFeaturesLib: Add
>> > "Test Then Write" Macros.
>> >
>> > > -Original Message-
>> > > From: Zeng, Star
>> > > Sent: Friday, August 16, 2019 9:15 AM
>> > > To: Dong, Eric ; devel@edk2.groups.io
>> > > Cc: Ni, Ray ; Laszlo Ersek ;
>> > > Zeng, Star 
>> > > Subject: RE: [Patch v3 1/6] UefiCpuPkg/RegisterCpuFeaturesLib: Add
>> > > "Test Then Write" Macros.
>> > >
>> > >
>> > >
>> > > > -Original Message-
>> > > > From: Dong, Eric
>> > > > Sent: Thursday, August 15, 2019 10:51 AM
>> > > > To: devel@edk2.groups.io
>> > > > Cc: Ni, Ray ; Laszlo Ersek ;
>> > > > Zeng, Star 
>> > > > Subject: [Patch v3 1/6] UefiCpuPkg/RegisterCpuFeaturesLib: Add
>> > > > "Test Then Write" Macros.
>> > > >
>> > > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2040
>> > > >
>> > > > Add below new micros which test the current value before write the
>> > > > new value. Only write new value when current value not same as new
>> > value.
>> > > >   CPU_REGISTER_TABLE_TEST_THEN_WRITE32
>> > > >   CPU_REGISTER_TABLE_TEST_THEN_WRITE64
>> > > >   CPU_REGISTER_TABLE_TEST_THEN_WRITE_FIELD
>> > > >
>> > > > Also add below API:
>> > > >   CpuRegisterTableTestThenWrite
>> > > >
>> > > > Signed-off-by: Eric Dong 
>> > > > Cc: Ray Ni 
>> > > > Cc: Laszlo Ersek 
>> > > > Cc: Star Zeng 
>> > > > ---
>> > > >  UefiCpuPkg/Include/AcpiCpuData.h  |  1 +
>> > > >  .../Include/Library/RegisterCpuFeaturesLib.h  | 91
>> > +++
>> > > >  .../RegisterCpuFeaturesLib.c  | 45 -
>> > > >  3 files changed, 134 insertions(+), 3 deletions(-)
>> > > >
>> > > > diff --git a/UefiCpuPkg/Include/AcpiCpuData.h
>> > > > b/UefiCpuPkg/Include/AcpiCpuData.h
>> > > > index b963a2f592..472a1a8070 100644
>> > > > --- a/UefiCpuPkg/Include/AcpiCpuData.h
>> > > > +++ b/UefiCpuPkg/Include/AcpiCpuData.h
>> > > > @@ -81,6 +81,7 @@ typedef struct {
>> > > >UINT16 Reserved;  // offset 10 - 11
>> > > >UINT32 HighIndex; // offset 12-15, only valid 
>> > > > for
>> > MemoryMapped
>> > > >UINT64 Value; // offset 16-23
>> > > > +  UINT8  TestThenWrite;   // 0ffset 24
>> > >
>> > > Could we use one byte of the Reserved field, but not add new field?
>> > > And use BOOLEAN type for it?
>> >
>> > I'm not sure whether use the Reserved field is an correct approach, do
>> > you have samples which use the reserved fields?
>> > But I think add new field is a more safe one.
>>
>> What "more safe" means here? Adding new field extends the structure,
>from
>> the structure layout view of point, it is an incompatible change, the 
>> structure
>> size is not just from 24 to 25 bytes, but to be nature aligned, the structure
>size
>> will be (24 + 8) 32. Since there is Reserved field can be reused, that size
>impact
>> can be removed.
>
>Yes, agree the size impact. I'm just not clear whether the Reserved field can
>be used. Whether it has compatible impact.
>
>>
>> FspGlobalData.h:
>> SHA-1: a2e61f341d26a78751b2f19b5004c6bbfc8b4fa9
>> * IntelFsp2Pkg: Support FSP Dispatch mode
>>
>> MemoryProfile.h
>> SHA-1: 072a3ca1d36a42aec97f871c808776ee7038ca06 (related to
>> 94092aa60341a3e4b1e1ea7c362781b8404ac538)
>> * MdeModulePkg MemoryProfile.h:two bytes of Reserved[4] as
>> ActionStringOffset
>>
>
>If so many examples already did it. I think we can also do it.
>
>>
>> If needed, more comments from Ray, Laszlo, Jiewen, Liming and Mike will
>be
>> better.
>
>Yes, I think we need get more comments from them.

I think to reuse the reserved field is a good solution.

Thanks
Liming
>
>Thanks,
>Eric
>>
>>
>> Thanks,
>> Star
>>
>> >
>> > Thanks,
>> > Eric
>> > >
>> > > Thanks,
>> > > Star
>> > >
>> > > >  } CPU_REGISTER_TABLE_ENTRY;
>> > > >
>> > > >  //
>> > > > diff --git a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
>> > > > b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
>> > > > index e420e7f075..5bd464b32e 100644
>> > > > --- a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
>> > > > +++ b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
>> > > > @@ -348,6 +348,32 @@

Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

2019-08-15 Thread Yao, Jiewen

Comment below:


> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Friday, August 16, 2019 12:21 AM
> To: Laszlo Ersek ; devel@edk2.groups.io; Yao, Jiewen
> 
> Cc: edk2-rfc-groups-io ; qemu devel list
> ; Igor Mammedov ;
> Chen, Yingwen ; Nakajima, Jun
> ; Boris Ostrovsky ;
> Joao Marcal Lemos Martins ; Phillip Goerl
> 
> Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
> 
> On 15/08/19 17:00, Laszlo Ersek wrote:
> > On 08/14/19 16:04, Paolo Bonzini wrote:
> >> On 14/08/19 15:20, Yao, Jiewen wrote:
>  - Does this part require a new branch somewhere in the OVMF SEC
> code?
>    How do we determine whether the CPU executing SEC is BSP or
>    hot-plugged AP?
> >>> [Jiewen] I think this is blocked from hardware perspective, since the 
> >>> first
> instruction.
> >>> There are some hardware specific registers can be used to determine if
> the CPU is new added.
> >>> I don’t think this must be same as the real hardware.
> >>> You are free to invent some registers in device model to be used in
> OVMF hot plug driver.
> >>
> >> Yes, this would be a new operation mode for QEMU, that only applies to
> >> hot-plugged CPUs.  In this mode the AP doesn't reply to INIT or SMI, in
> >> fact it doesn't reply to anything at all.
> >>
>  - How do we tell the hot-plugged AP where to start execution? (I.e.
> that
>    it should execute code at a particular pflash location.)
> >>> [Jiewen] Same real mode reset vector at :FFF0.
> >>
> >> You do not need a reset vector or INIT/SIPI/SIPI sequence at all in
> >> QEMU.  The AP does not start execution at all when it is unplugged, so
> >> no cache-as-RAM etc.
> >>
> >> We only need to modify QEMU so that hot-plugged APIs do not reply to
> >> INIT/SIPI/SMI.
> >>
> >>> I don’t think there is problem for real hardware, who always has CAR.
> >>> Can QEMU provide some CPU specific space, such as MMIO region?
> >>
> >> Why is a CPU-specific region needed if every other processor is in SMM
> >> and thus trusted.
> >
> > I was going through the steps Jiewen and Yingwen recommended.
> >
> > In step (02), the new CPU is expected to set up RAM access. In step
> > (03), the new CPU, executing code from flash, is expected to "send board
> > message to tell host CPU (GPIO->SCI) -- I am waiting for hot-add
> > message." For that action, the new CPU may need a stack (minimally if we
> > want to use C function calls).
> >
> > Until step (03), there had been no word about any other (= pre-plugged)
> > CPUs (more precisely, Jiewen even confirmed "No impact to other
> > processors"), so I didn't assume that other CPUs had entered SMM.
> >
> > Paolo, I've attempted to read Jiewen's response, and yours, as carefully
> > as I can. I'm still very confused. If you have a better understanding,
> > could you please write up the 15-step process from the thread starter
> > again, with all QEMU customizations applied? Such as, unnecessary steps
> > removed, and platform specifics filled in.
> 
> Sure.
> 
> (01a) QEMU: create new CPU.  The CPU already exists, but it does not
>  start running code until unparked by the CPU hotplug controller.
> 
> (01b) QEMU: trigger SCI
> 
> (02-03) no equivalent
> 
> (04) Host CPU: (OS) execute GPE handler from DSDT
> 
> (05) Host CPU: (OS) Port 0xB2 write, all CPUs enter SMM (NOTE: New CPU
>  will not enter CPU because SMI is disabled)
> 
> (06) Host CPU: (SMM) Save 38000, Update 38000 -- fill simple SMM
>  rebase code.
> 
> (07a) Host CPU: (SMM) Write to CPU hotplug controller to enable
>  new CPU
> 
> (07b) Host CPU: (SMM) Send INIT/SIPI/SIPI to new CPU.
[Jiewen] NOTE: INIT/SIPI/SIPI can be sent by a malicious CPU. There is no
restriction that INIT/SIPI/SIPI can only be sent in SMM.



> (08a) New CPU: (Low RAM) Enter protected mode.
[Jiewen] NOTE: The new CPU still cannot use any physical memory, because
the INIT/SIPI/SIPI may be sent by malicious CPU in non-SMM environment.



> (08b) New CPU: (Flash) Signals host CPU to proceed and enter cli;hlt loop.
> 
> (09) Host CPU: (SMM) Send SMI to the new CPU only.
> 
> (10) New CPU: (SMM) Run SMM code at 38000, and rebase SMBASE to
>  TSEG.
> 
> (11) Host CPU: (SMM) Restore 38000.
> 
> (12) Host CPU: (SMM) Update located data structure to add the new CPU
>  information. (This step will involve CPU_SERVICE protocol)
> 
> (13) New CPU: (Flash) do whatever other initialization is needed
> 
> (14) New CPU: (Flash) Deadloop, and wait for INIT-SIPI-SIPI.
> 
> (15) Host CPU: (OS) Send INIT-SIPI-SIPI to pull new CPU in..
> 
> 
> In other words, the cache-as-RAM phase of 02-03 is replaced by the
> INIT-SIPI-SIPI sequence of 07b-08a-08b.
[Jiewen] I am OK with this proposal.
I think the rule is same - the new CPU CANNOT touch any system memory,
no matter it is from reset-vector or from INIT/SIPI/SIPI.
Or I would say: if the new CPU want to touch some memory before first SMI, the 
memory should be
CPU specific or on the flash.



> >> The

Re: [edk2-devel] [Patch v3 1/6] UefiCpuPkg/RegisterCpuFeaturesLib: Add "Test Then Write" Macros.




> -Original Message-
> From: Zeng, Star
> Sent: Friday, August 16, 2019 10:08 AM
> To: Dong, Eric ; devel@edk2.groups.io
> Cc: Ni, Ray ; Laszlo Ersek ; Yao,
> Jiewen ; Gao, Liming ; Kinney,
> Michael D ; Zeng, Star 
> Subject: RE: [Patch v3 1/6] UefiCpuPkg/RegisterCpuFeaturesLib: Add "Test
> Then Write" Macros.
> 
> 
> 
> > -Original Message-
> > From: Dong, Eric
> > Sent: Friday, August 16, 2019 9:27 AM
> > To: Zeng, Star ; devel@edk2.groups.io
> > Cc: Ni, Ray ; Laszlo Ersek 
> > Subject: RE: [Patch v3 1/6] UefiCpuPkg/RegisterCpuFeaturesLib: Add
> > "Test Then Write" Macros.
> >
> > > -Original Message-
> > > From: Zeng, Star
> > > Sent: Friday, August 16, 2019 9:15 AM
> > > To: Dong, Eric ; devel@edk2.groups.io
> > > Cc: Ni, Ray ; Laszlo Ersek ;
> > > Zeng, Star 
> > > Subject: RE: [Patch v3 1/6] UefiCpuPkg/RegisterCpuFeaturesLib: Add
> > > "Test Then Write" Macros.
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Dong, Eric
> > > > Sent: Thursday, August 15, 2019 10:51 AM
> > > > To: devel@edk2.groups.io
> > > > Cc: Ni, Ray ; Laszlo Ersek ;
> > > > Zeng, Star 
> > > > Subject: [Patch v3 1/6] UefiCpuPkg/RegisterCpuFeaturesLib: Add
> > > > "Test Then Write" Macros.
> > > >
> > > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2040
> > > >
> > > > Add below new micros which test the current value before write the
> > > > new value. Only write new value when current value not same as new
> > value.
> > > >   CPU_REGISTER_TABLE_TEST_THEN_WRITE32
> > > >   CPU_REGISTER_TABLE_TEST_THEN_WRITE64
> > > >   CPU_REGISTER_TABLE_TEST_THEN_WRITE_FIELD
> > > >
> > > > Also add below API:
> > > >   CpuRegisterTableTestThenWrite
> > > >
> > > > Signed-off-by: Eric Dong 
> > > > Cc: Ray Ni 
> > > > Cc: Laszlo Ersek 
> > > > Cc: Star Zeng 
> > > > ---
> > > >  UefiCpuPkg/Include/AcpiCpuData.h  |  1 +
> > > >  .../Include/Library/RegisterCpuFeaturesLib.h  | 91
> > +++
> > > >  .../RegisterCpuFeaturesLib.c  | 45 -
> > > >  3 files changed, 134 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/UefiCpuPkg/Include/AcpiCpuData.h
> > > > b/UefiCpuPkg/Include/AcpiCpuData.h
> > > > index b963a2f592..472a1a8070 100644
> > > > --- a/UefiCpuPkg/Include/AcpiCpuData.h
> > > > +++ b/UefiCpuPkg/Include/AcpiCpuData.h
> > > > @@ -81,6 +81,7 @@ typedef struct {
> > > >UINT16 Reserved;  // offset 10 - 11
> > > >UINT32 HighIndex; // offset 12-15, only valid for
> > MemoryMapped
> > > >UINT64 Value; // offset 16-23
> > > > +  UINT8  TestThenWrite;   // 0ffset 24
> > >
> > > Could we use one byte of the Reserved field, but not add new field?
> > > And use BOOLEAN type for it?
> >
> > I'm not sure whether use the Reserved field is an correct approach, do
> > you have samples which use the reserved fields?
> > But I think add new field is a more safe one.
> 
> What "more safe" means here? Adding new field extends the structure, from
> the structure layout view of point, it is an incompatible change, the 
> structure
> size is not just from 24 to 25 bytes, but to be nature aligned, the structure 
> size
> will be (24 + 8) 32. Since there is Reserved field can be reused, that size 
> impact
> can be removed.

Yes, agree the size impact. I'm just not clear whether the Reserved field can 
be used. Whether it has compatible impact.

> 
> FspGlobalData.h:
> SHA-1: a2e61f341d26a78751b2f19b5004c6bbfc8b4fa9
> * IntelFsp2Pkg: Support FSP Dispatch mode
> 
> MemoryProfile.h
> SHA-1: 072a3ca1d36a42aec97f871c808776ee7038ca06 (related to
> 94092aa60341a3e4b1e1ea7c362781b8404ac538)
> * MdeModulePkg MemoryProfile.h:two bytes of Reserved[4] as
> ActionStringOffset
> 

If so many examples already did it. I think we can also do it.

> 
> If needed, more comments from Ray, Laszlo, Jiewen, Liming and Mike will be
> better.

Yes, I think we need get more comments from them.

Thanks,
Eric
> 
> 
> Thanks,
> Star
> 
> >
> > Thanks,
> > Eric
> > >
> > > Thanks,
> > > Star
> > >
> > > >  } CPU_REGISTER_TABLE_ENTRY;
> > > >
> > > >  //
> > > > diff --git a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> > > > b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> > > > index e420e7f075..5bd464b32e 100644
> > > > --- a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> > > > +++ b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> > > > @@ -348,6 +348,32 @@ CpuRegisterTableWrite (
> > > >IN UINT64  Value
> > > >);
> > > >
> > > > +/**
> > > > +  Adds an entry in specified register table.
> > > > +
> > > > +  This function adds an entry in specified register table, with
> > > > + given register type,  register index, bit section and value.
> > > > +
> > > > +  Driver will  test the current value before setting new value.
> > > > +
> > > > +  @param[in]  ProcessorNumber  The index of the CPU to add a
> > > > + register
> > > > table entry
> > >

[edk2-devel] [Patch V4 05/10] EmulatorPkg/Unix/Host: Disable inline/optimizations

* Disable XCODE5 compiler optimizations fort Unix/Host.
* Disable inline of SecGdbScriptBreak() to improve
  compatibility with XCODE5
* For X64 XCODE5 builds place output Host application
  in $(BIN_DIR) to match all other EmulatorPkg Host
  application builds.

Cc: Jordan Justen 
Cc: Andrew Fish 
Cc: Ray Ni 
Signed-off-by: Michael D Kinney 
---
 EmulatorPkg/Unix/Host/Host.c   | 3 +++
 EmulatorPkg/Unix/Host/Host.inf | 4 ++--
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/EmulatorPkg/Unix/Host/Host.c b/EmulatorPkg/Unix/Host/Host.c
index febfb1f44c..b431a4c2ed 100644
--- a/EmulatorPkg/Unix/Host/Host.c
+++ b/EmulatorPkg/Unix/Host/Host.c
@@ -1113,6 +1113,9 @@ DlLoadImage (
 }
 
 
+#ifdef __APPLE__
+__attribute__((noinline))
+#endif
 VOID
 SecGdbScriptBreak (
   char*FileName,
diff --git a/EmulatorPkg/Unix/Host/Host.inf b/EmulatorPkg/Unix/Host/Host.inf
index ca4294249b..c479d2b7d0 100644
--- a/EmulatorPkg/Unix/Host/Host.inf
+++ b/EmulatorPkg/Unix/Host/Host.inf
@@ -137,6 +137,6 @@ [BuildOptions]
XCODE:*_*_IA32_ASM_FLAGS == -arch i386 -g
 
XCODE:*_*_X64_DLINK_PATH == gcc
-   XCODE:*_*_X64_DLINK_FLAGS == -L/usr/X11R6/lib -lXext -lX11 -framework 
Carbon -Wl,-no_pie
+   XCODE:*_*_X64_DLINK_FLAGS == -o $(BIN_DIR)/Host -L/usr/X11R6/lib -lXext 
-lX11 -framework Carbon -Wl,-no_pie
XCODE:*_*_X64_ASM_FLAGS == -g
-   XCODE:*_*_X64_CC_FLAGS = -target x86_64-apple-darwin 
-I$(WORKSPACE)/EmulatorPkg/Unix/Host/X11IncludeHack 
"-DEFIAPI=__attribute__((ms_abi))"
+   XCODE:*_*_X64_CC_FLAGS = -O0 -target x86_64-apple-darwin 
-I$(WORKSPACE)/EmulatorPkg/Unix/Host/X11IncludeHack 
"-DEFIAPI=__attribute__((ms_abi))"
-- 
2.21.0.windows.1


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

View/Reply Online (#45763): https://edk2.groups.io/g/devel/message/45763
Mute This Topic: https://groups.io/mt/32894350/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [Patch V4 03/10] EmulatorPkg: Add -D DISABLE_NEW_DEPRECATED_INTERFACES

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

Update EmulatorPkg specific modules and libraries to use
safe string functions in BaseLib and safe PcdSetxx()
functions in PcdLib.  With these updates, the define
DISABLE_NEW_DEPRECATED_INTERFACES is enabled in the DSC
file.

Cc: Jordan Justen 
Cc: Andrew Fish 
Cc: Ray Ni 
Signed-off-by: Michael D Kinney 
Reviewed-by: Hao A Wu 
Acked-by: Jordan Justen 
---
 EmulatorPkg/EmuBusDriverDxe/EmuBusDriverDxe.c |   9 +-
 EmulatorPkg/EmulatorPkg.dsc   |   6 +-
 EmulatorPkg/FlashMapPei/FlashMapPei.c |   8 +-
 EmulatorPkg/Library/SmbiosLib/SmbiosLib.c |   4 +-
 .../ThunkProtocolList/ThunkProtocolList.c |  11 +-
 EmulatorPkg/Unix/Host/BerkeleyPacketFilter.c  |  10 +-
 EmulatorPkg/Unix/Host/PosixFileSystem.c   |  80 
 EmulatorPkg/Unix/Host/X11GraphicsWindow.c |   4 +-
 EmulatorPkg/Win/Host/WinFileSystem.c  | 116 --
 9 files changed, 172 insertions(+), 76 deletions(-)

diff --git a/EmulatorPkg/EmuBusDriverDxe/EmuBusDriverDxe.c 
b/EmulatorPkg/EmuBusDriverDxe/EmuBusDriverDxe.c
index 0bf6e723a1..d8380f2be9 100644
--- a/EmulatorPkg/EmuBusDriverDxe/EmuBusDriverDxe.c
+++ b/EmulatorPkg/EmuBusDriverDxe/EmuBusDriverDxe.c
@@ -1,7 +1,7 @@
 /** @file
  Emu Bus driver
 
-Copyright (c) 2006 - 2011, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 Portions copyright (c) 2011, Apple Inc. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -256,7 +256,12 @@ EmuBusDriverBindingStart (
 
   EmuDevice->ControllerNameTable = NULL;
 
-  StrnCpy (ComponentName, EmuIoThunk->ConfigString, sizeof 
(ComponentName)/sizeof (CHAR16));
+  StrnCpyS (
+ComponentName,
+sizeof (ComponentName) / sizeof (CHAR16),
+EmuIoThunk->ConfigString,
+sizeof (ComponentName) / sizeof (CHAR16)
+);
 
   EmuDevice->DevicePath = EmuBusCreateDevicePath (
   ParentDevicePath,
diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
index 153da464f1..529adfe1fa 100644
--- a/EmulatorPkg/EmulatorPkg.dsc
+++ b/EmulatorPkg/EmulatorPkg.dsc
@@ -408,10 +408,14 @@ [Components]
 !include NetworkPkg/Network.dsc.inc
 
 [BuildOptions]
+  #
+  # Disable deprecated APIs.
+  #
+  *_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
+
   MSFT:DEBUG_*_*_CC_FLAGS = /Od /Oy-
   MSFT:NOOPT_*_*_CC_FLAGS = /Od /Oy-
 
   MSFT:*_*_*_DLINK_FLAGS = /ALIGN:4096 /FILEALIGN:4096 /SUBSYSTEM:CONSOLE
   MSFT:DEBUG_*_*_DLINK_FLAGS = /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) 
/BASE:0x1
   MSFT:NOOPT_*_*_DLINK_FLAGS = /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) 
/BASE:0x1
-
diff --git a/EmulatorPkg/FlashMapPei/FlashMapPei.c 
b/EmulatorPkg/FlashMapPei/FlashMapPei.c
index 2a468e43ac..7744065dd6 100644
--- a/EmulatorPkg/FlashMapPei/FlashMapPei.c
+++ b/EmulatorPkg/FlashMapPei/FlashMapPei.c
@@ -1,7 +1,7 @@
 /*++ @file
   PEIM to build GUIDed HOBs for platform specific flash map
 
-Copyright (c) 2006 - 2010, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 Portions copyright (c) 2011, Apple Inc. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -69,9 +69,9 @@ Returns:
 return Status;
   }
 
-  PcdSet64 (PcdFlashNvStorageVariableBase64, PcdGet64 
(PcdEmuFlashNvStorageVariableBase) + FdFixUp);
-  PcdSet64 (PcdFlashNvStorageFtwWorkingBase64, PcdGet64 
(PcdEmuFlashNvStorageFtwWorkingBase) + FdFixUp);
-  PcdSet64 (PcdFlashNvStorageFtwSpareBase64, PcdGet64 
(PcdEmuFlashNvStorageFtwSpareBase) + FdFixUp);
+  PcdSet64S (PcdFlashNvStorageVariableBase64, PcdGet64 
(PcdEmuFlashNvStorageVariableBase) + FdFixUp);
+  PcdSet64S (PcdFlashNvStorageFtwWorkingBase64, PcdGet64 
(PcdEmuFlashNvStorageFtwWorkingBase) + FdFixUp);
+  PcdSet64S (PcdFlashNvStorageFtwSpareBase64, PcdGet64 
(PcdEmuFlashNvStorageFtwSpareBase) + FdFixUp);
 
   return EFI_SUCCESS;
 }
diff --git a/EmulatorPkg/Library/SmbiosLib/SmbiosLib.c 
b/EmulatorPkg/Library/SmbiosLib/SmbiosLib.c
index 331122e200..3acbb23644 100644
--- a/EmulatorPkg/Library/SmbiosLib/SmbiosLib.c
+++ b/EmulatorPkg/Library/SmbiosLib/SmbiosLib.c
@@ -4,7 +4,7 @@
 
 
 Copyright (c) 2012, Apple Inc. All rights reserved.
-Portitions Copyright (c) 2006 - 2012, Intel Corporation. All rights 
reserved.
+Portitions Copyright (c) 2006 - 2019, Intel Corporation. All rights 
reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -223,7 +223,7 @@ SmbiosLibUpdateUnicodeString (
   if (Ascii == NULL) {
 return EFI_OUT_OF_RESOURCES;
   }
-  UnicodeStrToAsciiStr (String, Ascii);
+  UnicodeStrToAsciiStrS (String, Ascii, StrSize (String));
 
   StringIndex = StringNumber;
   Status = gSmbios->UpdateString (gSmbios, , , Ascii);
diff --git a/EmulatorPkg/Library/ThunkProtocolList/ThunkProtocolList.c 
b/EmulatorPkg/Library/ThunkProtocolList/ThunkProtocolList.c
index b7aacc851c..3a7b6d1ceb 100644

[edk2-devel] [Patch V4 07/10] EmulatorPkg/Unix/Host: Fix BerkeleyPacketFilter.c issues

* Fix uninitialized Private->ReadBuffer.
* Remove old debug code that generates an exception.

Cc: Jordan Justen 
Cc: Ray Ni 
Cc: Michael D Kinney 
Signed-off-by: Andrew Fish 
---
 EmulatorPkg/Unix/Host/BerkeleyPacketFilter.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/EmulatorPkg/Unix/Host/BerkeleyPacketFilter.c 
b/EmulatorPkg/Unix/Host/BerkeleyPacketFilter.c
index 8d0eb0d197..3013bbc86b 100644
--- a/EmulatorPkg/Unix/Host/BerkeleyPacketFilter.c
+++ b/EmulatorPkg/Unix/Host/BerkeleyPacketFilter.c
@@ -216,6 +216,7 @@ EmuSnpStart (
   }
 
   Status = EFI_SUCCESS;
+  Private->ReadBuffer = NULL;
   if (Private->BpfFd == 0) {
 Status = OpenBpfFileDescriptor (Private, >BpfFd);
 if (EFI_ERROR (Status)) {
@@ -766,10 +767,6 @@ EmuSnpGetStatus (
 
   Private = EMU_SNP_PRIVATE_DATA_FROM_THIS (This);
 
-  if (TxBuf != NULL) {
-*((UINT8 **)TxBuf) =  (UINT8 *)1;
-  }
-
   if ( InterruptStatus != NULL ) {
 *InterruptStatus = EFI_SIMPLE_NETWORK_TRANSMIT_INTERRUPT;
   }
-- 
2.21.0.windows.1


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

View/Reply Online (#45765): https://edk2.groups.io/g/devel/message/45765
Mute This Topic: https://groups.io/mt/32894352/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] CryptoPkg/OpensslLib: Add missing header files in INF file

Shenglei,

Sorry that I forgot to mention that these two inf files are generated by 
process_files.pl
in the same folder. Please file another BZ to update this perl script to add 
those header
files into inf file.

Regards,
Jian


> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Wang, Jian J
> Sent: Thursday, August 15, 2019 4:59 PM
> To: Zhang, Shenglei ; devel@edk2.groups.io
> Cc: Ye, Ting 
> Subject: Re: [edk2-devel] [PATCH 1/1] CryptoPkg/OpensslLib: Add missing
> header files in INF file
> 
> 
> Reviewed-by: Jian J Wang 
> 
> > -Original Message-
> > From: Zhang, Shenglei
> > Sent: Tuesday, August 13, 2019 4:50 PM
> > To: devel@edk2.groups.io
> > Cc: Wang, Jian J ; Ye, Ting 
> > Subject: [PATCH 1/1] CryptoPkg/OpensslLib: Add missing header files in
> INF
> > file
> >
> > The header files are used but missing in INF,which causes
> > warning message when building them.
> > https://bugzilla.tianocore.org/show_bug.cgi?id=2036
> >
> > Cc: Jian Wang 
> > Cc: Ting Ye 
> > Signed-off-by: Shenglei Zhang 
> > ---
> >  CryptoPkg/Library/OpensslLib/OpensslLib.inf   | 59
> > +++
> >  .../Library/OpensslLib/OpensslLibCrypto.inf   | 53 -
> >  2 files changed, 111 insertions(+), 1 deletion(-)
> >
> > diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> > b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> > index 5f36edeeef3c..7432321fd431 100644
> > --- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> > +++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> > @@ -22,6 +22,8 @@ [Defines]
> >  #
> >
> >  [Sources]
> > +  buildinf.h
> > +  rand_pool_noise.h
> >$(OPENSSL_PATH)/e_os.h
> >  # Autogenerated files list starts here
> >$(OPENSSL_PATH)/crypto/aes/aes_cbc.c
> > @@ -32,7 +34,9 @@ [Sources]
> >$(OPENSSL_PATH)/crypto/aes/aes_misc.c
> >$(OPENSSL_PATH)/crypto/aes/aes_ofb.c
> >$(OPENSSL_PATH)/crypto/aes/aes_wrap.c
> > +  $(OPENSSL_PATH)/crypto/aes/aes_locl.h
> >$(OPENSSL_PATH)/crypto/aria/aria.c
> > +  $(OPENSSL_PATH)/crypto/arm_arch.h
> >$(OPENSSL_PATH)/crypto/asn1/a_bitstr.c
> >$(OPENSSL_PATH)/crypto/asn1/a_d2i_fp.c
> >$(OPENSSL_PATH)/crypto/asn1/a_digest.c
> > @@ -97,12 +101,21 @@ [Sources]
> >$(OPENSSL_PATH)/crypto/asn1/x_sig.c
> >$(OPENSSL_PATH)/crypto/asn1/x_spki.c
> >$(OPENSSL_PATH)/crypto/asn1/x_val.c
> > +  $(OPENSSL_PATH)/crypto/asn1/standard_methods.h
> > +  $(OPENSSL_PATH)/crypto/asn1/charmap.h
> > +  $(OPENSSL_PATH)/crypto/asn1/tbl_standard.h
> > +  $(OPENSSL_PATH)/crypto/asn1/asn1_item_list.h
> > +  $(OPENSSL_PATH)/crypto/asn1/asn1_locl.h
> >$(OPENSSL_PATH)/crypto/async/arch/async_null.c
> >$(OPENSSL_PATH)/crypto/async/arch/async_posix.c
> >$(OPENSSL_PATH)/crypto/async/arch/async_win.c
> >$(OPENSSL_PATH)/crypto/async/async.c
> >$(OPENSSL_PATH)/crypto/async/async_err.c
> >$(OPENSSL_PATH)/crypto/async/async_wait.c
> > +  $(OPENSSL_PATH)/crypto/async/arch/async_win.h
> > +  $(OPENSSL_PATH)/crypto/async/async_locl.h
> > +  $(OPENSSL_PATH)/crypto/async/arch/async_posix.h
> > +  $(OPENSSL_PATH)/crypto/async/arch/async_null.h
> >$(OPENSSL_PATH)/crypto/bio/b_addr.c
> >$(OPENSSL_PATH)/crypto/bio/b_dump.c
> >$(OPENSSL_PATH)/crypto/bio/b_sock.c
> > @@ -125,6 +138,7 @@ [Sources]
> >$(OPENSSL_PATH)/crypto/bio/bss_mem.c
> >$(OPENSSL_PATH)/crypto/bio/bss_null.c
> >$(OPENSSL_PATH)/crypto/bio/bss_sock.c
> > +  $(OPENSSL_PATH)/crypto/bio/bio_lcl.h
> >$(OPENSSL_PATH)/crypto/bn/bn_add.c
> >$(OPENSSL_PATH)/crypto/bn/bn_asm.c
> >$(OPENSSL_PATH)/crypto/bn/bn_blind.c
> > @@ -156,6 +170,9 @@ [Sources]
> >$(OPENSSL_PATH)/crypto/bn/bn_srp.c
> >$(OPENSSL_PATH)/crypto/bn/bn_word.c
> >$(OPENSSL_PATH)/crypto/bn/bn_x931p.c
> > +  $(OPENSSL_PATH)/crypto/bn/rsaz_exp.h
> > +  $(OPENSSL_PATH)/crypto/bn/bn_prime.h
> > +  $(OPENSSL_PATH)/crypto/bn/bn_lcl.h
> >$(OPENSSL_PATH)/crypto/buffer/buf_err.c
> >$(OPENSSL_PATH)/crypto/buffer/buffer.c
> >$(OPENSSL_PATH)/crypto/cmac/cm_ameth.c
> > @@ -164,6 +181,7 @@ [Sources]
> >$(OPENSSL_PATH)/crypto/comp/c_zlib.c
> >$(OPENSSL_PATH)/crypto/comp/comp_err.c
> >$(OPENSSL_PATH)/crypto/comp/comp_lib.c
> > +  $(OPENSSL_PATH)/crypto/comp/comp_lcl.h
> >$(OPENSSL_PATH)/crypto/conf/conf_api.c
> >$(OPENSSL_PATH)/crypto/conf/conf_def.c
> >$(OPENSSL_PATH)/crypto/conf/conf_err.c
> > @@ -172,6 +190,8 @@ [Sources]
> >$(OPENSSL_PATH)/crypto/conf/conf_mod.c
> >$(OPENSSL_PATH)/crypto/conf/conf_sap.c
> >$(OPENSSL_PATH)/crypto/conf/conf_ssl.c
> > +  $(OPENSSL_PATH)/crypto/conf/conf_lcl.h
> > +  $(OPENSSL_PATH)/crypto/conf/conf_def.h
> >$(OPENSSL_PATH)/crypto/cpt_err.c
> >$(OPENSSL_PATH)/crypto/cryptlib.c
> >$(OPENSSL_PATH)/crypto/ctype.c
> > @@ -195,6 +215,8 @@ [Sources]
> >$(OPENSSL_PATH)/crypto/des/set_key.c
> >$(OPENSSL_PATH)/crypto/des/str2key.c
> >$(OPENSSL_PATH)/crypto/des/xcbc_enc.c
> > +  $(OPENSSL_PATH)/crypto/des/spr.h
> > +

[edk2-devel] [Patch V4 01/10] EmulatorPkg: Fix VS20xx IA32 boot failure

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

The IA32 build of the EmulatorPkg for VS20xx does not boot
because the default value of PCD PcdPeiServicesTablePage
rarely succeeds to be mapped on IA32 Windows Host Environments.
Change the DEC default value for this PCD to a value that
is compatible with Windows and POSIX host environments for
IA32 and X64.  For IA32 builds, this 64-bit PCD is truncated
to a 32-bit value.

PcdPeiServicesTablePage is changed from 0x100300 to
0x101300.  With this new value, no boot failures are
observed.  However, the use of this hard coded value can
potentially cause a boot failure if this address specified
by the PCD is already allocated in the user process.

Cc: Jordan Justen 
Cc: Andrew Fish 
Cc: Ray Ni 
Signed-off-by: Michael D Kinney 
Reviewed-by: Hao A Wu 
Reviewed-by: Jordan Justen 
---
 EmulatorPkg/EmulatorPkg.dec | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/EmulatorPkg/EmulatorPkg.dec b/EmulatorPkg/EmulatorPkg.dec
index c36f2c4186..99250d9fe5 100644
--- a/EmulatorPkg/EmulatorPkg.dec
+++ b/EmulatorPkg/EmulatorPkg.dec
@@ -2,7 +2,7 @@
 #
 # This is the Emu Emulation Environment Platform
 #
-# Copyright (c) 2008 - 2011, Intel Corporation. All rights reserved.
+# Copyright (c) 2008 - 2019, Intel Corporation. All rights reserved.
 # Portions copyright (c) 2011, Apple Inc. All rights reserved.
 #
 #SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -66,7 +66,7 @@ [PcdsFixedAtBuild]
   gEmulatorPkgTokenSpaceGuid.PcdEmuApCount|L"0"|VOID*|0x1019
 
   ## Magic page to implement PEI Services Table Pointer Lib
-  
gEmulatorPkgTokenSpaceGuid.PcdPeiServicesTablePage|0x100300|UINT64|0x101b
+  
gEmulatorPkgTokenSpaceGuid.PcdPeiServicesTablePage|0x101300|UINT64|0x101b
 
   ## Size of the packet filter
   
gEmulatorPkgTokenSpaceGuid.PcdNetworkPacketFilterSize|524288|UINT32|0x101c
-- 
2.21.0.windows.1


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

View/Reply Online (#45759): https://edk2.groups.io/g/devel/message/45759
Mute This Topic: https://groups.io/mt/32894346/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [Patch V4 09/10] EmulatorPkg/Sec: Change local variable scope for XCODE5

The local variable PpiArray[10] is declared in middle
of the SEC module _ModuleEntryPoint().  When building
for XCODE5 with optimizations enabled, this results in
corruption and an exception.  The fix is to move the
declaration of PpiArray[10] to the standard location
at the beginning of the function so the storage for
this local variable is allocated for the entire
lifetime of the function.

Cc: Jordan Justen 
Cc: Ray Ni 
Cc: Michael D Kinney 
Signed-off-by: Andrew Fish 
---
 EmulatorPkg/Sec/Sec.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/EmulatorPkg/Sec/Sec.c b/EmulatorPkg/Sec/Sec.c
index 701032233b..b734d2bb87 100644
--- a/EmulatorPkg/Sec/Sec.c
+++ b/EmulatorPkg/Sec/Sec.c
@@ -75,6 +75,7 @@ _ModuleEntryPoint (
   EFI_PEI_PPI_DESCRIPTOR*SecPpiList;
   UINTN SecReseveredMemorySize;
   UINTN Index;
+  EFI_PEI_PPI_DESCRIPTORPpiArray[10];
 
   EMU_MAGIC_PAGE()->PpiList = PpiList;
   ProcessLibraryConstructorList ();
@@ -104,16 +105,13 @@ _ModuleEntryPoint (
   SecCoreData->PeiTemporaryRamBase = (VOID 
*)((UINTN)SecCoreData->PeiTemporaryRamBase + SecReseveredMemorySize);
   SecCoreData->PeiTemporaryRamSize -= SecReseveredMemorySize;
 #else
-  {
-//
-// When I subtrack from SecCoreData->PeiTemporaryRamBase PEI Core crashes? 
Either there is a bug
-// or I don't understand temp RAM correctly?
-//
-EFI_PEI_PPI_DESCRIPTORPpiArray[10];
+  //
+  // When I subtrack from SecCoreData->PeiTemporaryRamBase PEI Core crashes? 
Either there is a bug
+  // or I don't understand temp RAM correctly?
+  //
 
-SecPpiList = [0];
-ASSERT (sizeof (PpiArray) >= SecReseveredMemorySize);
-  }
+  SecPpiList = [0];
+  ASSERT (sizeof (PpiArray) >= SecReseveredMemorySize);
 #endif
   // Copy existing list, and append our entries.
   CopyMem (SecPpiList, PpiList, sizeof (EFI_PEI_PPI_DESCRIPTOR) * Index);
-- 
2.21.0.windows.1


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

View/Reply Online (#45767): https://edk2.groups.io/g/devel/message/45767
Mute This Topic: https://groups.io/mt/32894354/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [Patch V4 06/10] EmulatorPkg: Fix XCODE5 lldb issues

Fix scripts to support lldb symbolic debugging when
using XCODE5 tool chain.

Cc: Jordan Justen 
Cc: Ray Ni 
Cc: Michael D Kinney 
Signed-off-by: Andrew Fish 
---
 EmulatorPkg/Unix/lldbefi.py |  8 +---
 EmulatorPkg/build.sh| 17 ++---
 2 files changed, 7 insertions(+), 18 deletions(-)

diff --git a/EmulatorPkg/Unix/lldbefi.py b/EmulatorPkg/Unix/lldbefi.py
index 218326b8cb..099192d8b5 100755
--- a/EmulatorPkg/Unix/lldbefi.py
+++ b/EmulatorPkg/Unix/lldbefi.py
@@ -346,6 +346,7 @@ def TypePrintFormating(debugger):
 debugger.HandleCommand("type summary add CHAR8 --python-function 
lldbefi.CHAR8_TypeSummary")
 debugger.HandleCommand('type summary add --regex "CHAR8 \[[0-9]+\]" 
--python-function lldbefi.CHAR8_TypeSummary')
 
+debugger.HandleCommand('setting set frame-format "frame #${frame.index}: 
${frame.pc}{ 
${module.file.basename}{:${function.name}()${function.pc-offset}}}{ at 
${line.file.fullpath}:${line.number}}\n"')
 
 gEmulatorBreakWorkaroundNeeded = True
 
@@ -381,15 +382,16 @@ def LoadEmulatorEfiSymbols(frame, bp_loc , internal_dict):
 Error = lldb.SBError()
 FileNamePtr = frame.FindVariable ("FileName").GetValueAsUnsigned()
 FileNameLen = frame.FindVariable ("FileNameLength").GetValueAsUnsigned()
+
 FileName = frame.thread.process.ReadCStringFromMemory (FileNamePtr, 
FileNameLen, Error)
 if not Error.Success():
 print "!ReadCStringFromMemory() did not find a %d byte C string at %x" 
% (FileNameLen, FileNamePtr)
 # make breakpoint command contiue
-frame.GetThread().GetProcess().Continue()
+return False
 
 debugger = frame.thread.process.target.debugger
 if frame.FindVariable ("AddSymbolFlag").GetValueAsUnsigned() == 1:
-LoadAddress = frame.FindVariable ("LoadAddress").GetValueAsUnsigned()
+LoadAddress = frame.FindVariable ("LoadAddress").GetValueAsUnsigned() 
- 0x240
 
 debugger.HandleCommand ("target modules add  %s" % FileName)
 print "target modules load --slid 0x%x %s" % (LoadAddress, FileName)
@@ -405,7 +407,7 @@ def LoadEmulatorEfiSymbols(frame, bp_loc , internal_dict):
 print "!lldb.target.RemoveModule (%s) FAILED" % SBModule
 
 # make breakpoint command contiue
-frame.thread.process.Continue()
+return False
 
 def GuidToCStructStr (guid, Name=False):
   #
diff --git a/EmulatorPkg/build.sh b/EmulatorPkg/build.sh
index 60056e1b6c..35912a7775 100755
--- a/EmulatorPkg/build.sh
+++ b/EmulatorPkg/build.sh
@@ -209,21 +209,8 @@ fi
 if [[ "$RUN_EMULATOR" == "yes" ]]; then
   case `uname` in
 Darwin*)
-  #
-  # On Darwin we can't use dlopen, so we have to load the real PE/COFF 
images.
-  # This .gdbinit script sets a breakpoint that loads symbols for the 
PE/COFFEE
-  # images that get loaded in Host
-  #
-  if [[ "$CLANG_VER" == *-ccc-host-triple* ]]
-  then
-  # only older versions of Xcode support -ccc-host-tripe, for newer 
versions
-  # it is -target
-cp $WORKSPACE/EmulatorPkg/Unix/lldbefi.py 
"$BUILD_OUTPUT_DIR/${BUILDTARGET}_$TARGET_TOOLS/$PROCESSOR"
-cd $BUILD_ROOT_ARCH; /usr/bin/lldb --source 
$WORKSPACE/EmulatorPkg/Unix/lldbinit Host
-exit $? 
-  else
-cp $WORKSPACE/EmulatorPkg/Unix/.gdbinit 
"$BUILD_OUTPUT_DIR/${BUILDTARGET}_$TARGET_TOOLS/$PROCESSOR"
-  fi
+  cd $BUILD_ROOT_ARCH; /usr/bin/lldb -o "command script import 
$WORKSPACE/EmulatorPkg/Unix/lldbefi.py" -o 'script 
lldb.debugger.SetAsync(True)' -o "run" ./Host
+  exit $?
   ;;
   esac
 
-- 
2.21.0.windows.1


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

View/Reply Online (#45764): https://edk2.groups.io/g/devel/message/45764
Mute This Topic: https://groups.io/mt/32894351/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [Patch V4 02/10] EmulatorPkg: Remove UNIX_SEC_BUILD/WIN_SEC_BUILD

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

Remove the use of the defines UNIX_SEC_BUILD and
WIN_SEC_BUILD.  This simplifies the build command
for the EmulatorPkg.  Instead, use !if statements
in the DSC file using $(ARCH) and $(FAMILY) to
determine if the build is for a Windows or POSIX
environment.

The Readme.md, BAT, and sh files are also updated
to remove the use of these defines.

Cc: Jordan Justen 
Cc: Andrew Fish 
Cc: Ray Ni 
Signed-off-by: Michael D Kinney 
Reviewed-by: Hao A Wu 
Reviewed-by: Jordan Justen 
---
 EmulatorPkg/EmulatorPkg.dsc| 26 +-
 EmulatorPkg/Readme.md  |  8 
 EmulatorPkg/Win/VS2017/BuildVS.bat |  2 +-
 EmulatorPkg/build.sh   |  8 
 4 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
index ea8b6ce76e..153da464f1 100644
--- a/EmulatorPkg/EmulatorPkg.dsc
+++ b/EmulatorPkg/EmulatorPkg.dsc
@@ -4,7 +4,7 @@
 # The Emulation Platform can be used to debug individual modules, prior to 
creating
 # a real platform. This also provides an example for how an DSC is created.
 #
-# Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+# Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 # Portions copyright (c) 2010 - 2011, Apple Inc. All rights reserved.
 #
 # SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -236,18 +236,18 @@ [PcdsDynamicHii.common.DEFAULT]
   
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|10
 
 [Components]
-!ifdef $(UNIX_SEC_BUILD)
-  ##
-  #  Emulator, OS POSIX application
-  ##
-  EmulatorPkg/Unix/Host/Host.inf
-!endif
-
-!ifdef $(WIN_SEC_BUILD)
-  ##
-  #  Emulator, OS WIN application
-  ##
-  EmulatorPkg/Win/Host/WinHost.inf
+!if "IA32" in $(ARCH) || "X64" in $(ARCH)
+  !if "MSFT" in $(FAMILY)
+##
+#  Emulator, OS WIN application
+##
+EmulatorPkg/Win/Host/WinHost.inf
+  !else
+##
+#  Emulator, OS POSIX application
+##
+EmulatorPkg/Unix/Host/Host.inf
+  !endif
 !endif
 
 !ifndef $(SKIP_MAIN_BUILD)
diff --git a/EmulatorPkg/Readme.md b/EmulatorPkg/Readme.md
index 461975e859..5ea61ca7ab 100644
--- a/EmulatorPkg/Readme.md
+++ b/EmulatorPkg/Readme.md
@@ -21,19 +21,19 @@ 
https://github.com/tianocore/tianocore.github.io/wiki/EmulatorPkg
 **You can use the following command to build.**
   * 32bit emulator in Windows:
 
-`build -p EmulatorPkg\EmulatorPkg.dsc -t VS2017 -D WIN_SEC_BUILD -a IA32`
+`build -p EmulatorPkg\EmulatorPkg.dsc -t VS2017 -a IA32`
 
   * 64bit emulator in Windows:
 
-`build -p EmulatorPkg\EmulatorPkg.dsc -t VS2017 -D WIN_SEC_BUILD -a X64`
+`build -p EmulatorPkg\EmulatorPkg.dsc -t VS2017 -a X64`
 
   * 32bit emulator in Linux:
 
-`build -p EmulatorPkg\EmulatorPkg.dsc -t GCC5 -D UNIX_SEC_BUILD -a IA32`
+`build -p EmulatorPkg\EmulatorPkg.dsc -t GCC5 -a IA32`
 
   * 64bit emulator in Linux:
 
-`build -p EmulatorPkg\EmulatorPkg.dsc -t GCC5 -D UNIX_SEC_BUILD -a X64`
+`build -p EmulatorPkg\EmulatorPkg.dsc -t GCC5 -a X64`
 
 **You can start/run the emulator using the following command:**
   * 32bit emulator in Windows:
diff --git a/EmulatorPkg/Win/VS2017/BuildVS.bat 
b/EmulatorPkg/Win/VS2017/BuildVS.bat
index 83aebc77dc..6fcf40cc0a 100644
--- a/EmulatorPkg/Win/VS2017/BuildVS.bat
+++ b/EmulatorPkg/Win/VS2017/BuildVS.bat
@@ -1,3 +1,3 @@
 cd ../../../
 @call edksetup.bat
-build -p EmulatorPkg\EmulatorPkg.dsc -t VS2017 -D WIN_SEC_BUILD %*
+build -p EmulatorPkg\EmulatorPkg.dsc -t VS2017 %*
diff --git a/EmulatorPkg/build.sh b/EmulatorPkg/build.sh
index 2dab035ed5..60056e1b6c 100755
--- a/EmulatorPkg/build.sh
+++ b/EmulatorPkg/build.sh
@@ -233,13 +233,13 @@ fi
 
 case $CLEAN_TYPE in
   clean)
-build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc -a $PROCESSOR -b 
$BUILDTARGET -t $HOST_TOOLS -D UNIX_SEC_BUILD -n 3 clean
+build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc -a $PROCESSOR -b 
$BUILDTARGET -t $HOST_TOOLS -n 3 clean
 build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc -a $PROCESSOR -b 
$BUILDTARGET -t $TARGET_TOOLS -n 3 clean
 exit $?
 ;;
   cleanall)
 make -C $WORKSPACE/BaseTools clean
-build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc -a $PROCESSOR -b 
$BUILDTARGET -t $HOST_TOOLS -D UNIX_SEC_BUILD -n 3 clean
+build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc -a $PROCESSOR -b 
$BUILDTARGET -t $HOST_TOOLS -n 3 clean
 build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc -a $PROCESSOR -b 
$BUILDTARGET -t $TARGET_TOOLS -n 3 clean
 build -p $WORKSPACE/ShellPkg/ShellPkg.dsc -a IA32 -b $BUILDTARGET -t 
$TARGET_TOOLS -n 3 clean
 exit $?
@@ -251,9 +251,9 @@ esac
 # Build the edk2 EmulatorPkg
 #
 if [[ $HOST_TOOLS == $TARGET_TOOLS ]]; then
-  build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc $BUILD_OPTIONS -a $PROCESSOR 
-b $BUILDTARGET -t $TARGET_TOOLS -D BUILD_$ARCH_SIZE -D UNIX_SEC_BUILD 
$NETWORK_SUPPORT $BUILD_NEW_SHELL $BUILD_FAT -n 3
+  build -p

[edk2-devel] [Patch V4 08/10] EmulatorPkg: Disable TftpDynamicCommand and LogoDxe for XCODE5

Disable TftpDynamicCommand for XCODE5 because this command
places HII content in an PE/COFF resource section that is not
supported by the XCODE5 tool chain, and the missing HII
content causes the load of this command to ASSERT().

Disable the LogoDxe module that places the logo bitmap in
a PE/COFF resource section that is not supported by the
XCODE5 tool chain, and the missing HII content causes
the load of this module to ASSERT().

Cc: Jordan Justen 
Cc: Ray Ni 
Cc: Michael D Kinney 
Signed-off-by: Andrew Fish 
---
 EmulatorPkg/EmulatorPkg.dsc | 4 
 EmulatorPkg/EmulatorPkg.fdf | 4 
 2 files changed, 8 insertions(+)

diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
index 0af2d1ff95..20f1187713 100644
--- a/EmulatorPkg/EmulatorPkg.dsc
+++ b/EmulatorPkg/EmulatorPkg.dsc
@@ -332,7 +332,9 @@ [Components]
 
   MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
   MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
+!if "XCODE5" not in $(TOOL_CHAIN_TAG)
   MdeModulePkg/Logo/LogoDxe.inf
+!endif
   MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.inf
   MdeModulePkg/Application/UiApp/UiApp.inf {

@@ -375,10 +377,12 @@ [Components]
 
   FatPkg/EnhancedFatDxe/Fat.inf
 
+!if "XCODE5" not in $(TOOL_CHAIN_TAG)
   ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
 
   gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
   }
+!endif
   ShellPkg/Application/Shell/Shell.inf {
 
   
ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
diff --git a/EmulatorPkg/EmulatorPkg.fdf b/EmulatorPkg/EmulatorPkg.fdf
index ec411e82b4..295f6f1db8 100644
--- a/EmulatorPkg/EmulatorPkg.fdf
+++ b/EmulatorPkg/EmulatorPkg.fdf
@@ -178,7 +178,9 @@ [FV.FvRecovery]
 INF  MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
 INF  MdeModulePkg/Universal/PrintDxe/PrintDxe.inf
 INF  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
+!if "XCODE5" not in $(TOOL_CHAIN_TAG)
 INF  MdeModulePkg/Logo/LogoDxe.inf
+!endif
 INF  MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.inf
 INF  RuleOverride = UI MdeModulePkg/Application/UiApp/UiApp.inf
 INF  MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenuApp.inf
@@ -194,7 +196,9 @@ [FV.FvRecovery]
 
 INF FatPkg/EnhancedFatDxe/Fat.inf
 
+!if "XCODE5" not in $(TOOL_CHAIN_TAG)
 INF  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
+!endif
 INF  ShellPkg/Application/Shell/Shell.inf
 
 [Rule.Common.SEC]
-- 
2.21.0.windows.1


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

View/Reply Online (#45766): https://edk2.groups.io/g/devel/message/45766
Mute This Topic: https://groups.io/mt/32894353/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [Patch V4 00/10] EmulatorPkg: Fix VS20xx IA32 boot and simplify build config

New in V4 (Resolve XCODE5 issues)
==
* Disable inline if SecGdbScriptBreak() for XCODE5 issues
* Disable XCODE5 compiler optimizations of Unix/Host
* Fix Host output location for XCODE5 X64 builds
* Update lldb scripts for XCODE5 symbiolic debugging
* Clean up BrekelyPlacketFilter.c for uninitialized variable and old debug code.
* Remove TftpDynamicCommand and LogoDxe modules from XCODE5 builds.  These 
  modules use HII section in a PE/COFF resource sections that is not currently
  supported by XCODE5 builds.
* EmulatorPkg/Sec - Move declaration of PpiArray[10] to beginning of function
  so storage is for entire lifetime of the function.  Delaractrion in the 
  middle of the function in {} cause corruption and exceptions in XCODE5 builds.
* Add -gdwarf flag to tols_def.template for XCODE5 X64 for symbolic debug.

New in V3
==
* Fix size value used in call to AsciiStrCpyS() in PosixFileSystem.c
* Fix XCODE5 safe string function build failure in BerkleyPacketFilter.c
* Add NOOPT build target to DSC file.

New in V2
=
* Fix size values in safe string function calls.
* Update POSIX sources to use AsciiStrCpyS() and AsciiStrCatS().
* Verify that no exceptions occur if EMU_MAGIC_PAGE() can not be mapped.  An
  error message is generated and the host app exits normally.
* Update EmulatorPkg DEC file with a new PcdPeiServicesTablePage default value
  that works for Windows/POSIX hosts for both IA32 and X64.

https://bugzilla.tianocore.org/show_bug.cgi?id=162
https://bugzilla.tianocore.org/show_bug.cgi?id=2055
https://bugzilla.tianocore.org/show_bug.cgi?id=2056

* Fix VS20xx IA32 boot failure
* Remove UNIX_SEC_BUILD/WIN_SEC_BUILD
* Add -D DISABLE_NEW_DEPRECATED_INTERFACES

Cc: Jordan Justen 
Cc: Andrew Fish 
Cc: Ray Ni 
Signed-off-by: Michael D Kinney 

Michael D Kinney (10):
  EmulatorPkg: Fix VS20xx IA32 boot failure
  EmulatorPkg: Remove UNIX_SEC_BUILD/WIN_SEC_BUILD
  EmulatorPkg: Add -D DISABLE_NEW_DEPRECATED_INTERFACES
  EmulatorPkg: Add support for NOOPT target
  EmulatorPkg/Unix/Host: Disable inline/optimizations
  EmulatorPkg: Fix XCODE5 lldb issues
  EmulatorPkg/Unix/Host: Fix BerkeleyPacketFilter.c issues
  EmulatorPkg: Disable TftpDynamicCommand and LogoDxe for XCODE5
  EmulatorPkg/Sec: Change local variable scope for XCODE5
  BaseTools/tools_def.template: Add -gdwarf to XCODE5 X64

 BaseTools/Conf/tools_def.template |   4 +-
 EmulatorPkg/EmuBusDriverDxe/EmuBusDriverDxe.c |   9 +-
 EmulatorPkg/EmulatorPkg.dec   |   4 +-
 EmulatorPkg/EmulatorPkg.dsc   |  38 +++---
 EmulatorPkg/EmulatorPkg.fdf   |   4 +
 EmulatorPkg/FlashMapPei/FlashMapPei.c |   8 +-
 EmulatorPkg/Library/SmbiosLib/SmbiosLib.c |   4 +-
 .../ThunkProtocolList/ThunkProtocolList.c |  11 +-
 EmulatorPkg/Readme.md |   8 +-
 EmulatorPkg/Sec/Sec.c |  16 ++-
 EmulatorPkg/Unix/Host/BerkeleyPacketFilter.c  |  15 +--
 EmulatorPkg/Unix/Host/Host.c  |   3 +
 EmulatorPkg/Unix/Host/Host.inf|   4 +-
 EmulatorPkg/Unix/Host/PosixFileSystem.c   |  80 
 EmulatorPkg/Unix/Host/X11GraphicsWindow.c |   4 +-
 EmulatorPkg/Unix/lldbefi.py   |   8 +-
 EmulatorPkg/Win/Host/WinFileSystem.c  | 116 --
 EmulatorPkg/Win/VS2017/BuildVS.bat|   2 +-
 EmulatorPkg/build.sh  |  25 +---
 19 files changed, 227 insertions(+), 136 deletions(-)

-- 
2.21.0.windows.1


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

View/Reply Online (#45758): https://edk2.groups.io/g/devel/message/45758
Mute This Topic: https://groups.io/mt/32894345/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [Patch V4 10/10] BaseTools/tools_def.template: Add -gdwarf to XCODE5 X64

Add -gdwarf to XCODE5 X64 builds to generate symbols for
source level debug using lldb.

Cc: Jordan Justen 
Cc: Ray Ni 
Cc: Michael D Kinney 
Signed-off-by: Andrew Fish 
---
 BaseTools/Conf/tools_def.template | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 26a2cf604f..8f0e6cb6c2 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -2593,8 +2593,8 @@ RELEASE_XCODE5_X64_ASM_FLAGS  = -arch x86_64
 *_XCODE5_*_PP_FLAGS = -E -x assembler-with-cpp -include 
$(DEST_DIR_DEBUG)/AutoGen.h
 *_XCODE5_*_VFRPP_FLAGS  = -x c -E -P -DVFRCOMPILE -include 
$(DEST_DIR_DEBUG)/$(MODULE_NAME)StrDefs.h
 
-  DEBUG_XCODE5_X64_CC_FLAGS   = -target x86_64-pc-win32-macho -c -g -Os   
-Wall -Werror -Wextra -include AutoGen.h -funsigned-char -fno-ms-extensions 
-fno-stack-protector -fno-builtin -fshort-wchar -mno-implicit-float 
-mms-bitfields -Wno-unused-parameter -Wno-missing-braces 
-Wno-missing-field-initializers -Wno-tautological-compare -Wno-sign-compare 
-Wno-varargs 
-ftrap-function=undefined_behavior_has_been_optimized_away_by_clang -D 
NO_MSABI_VA_FUNCS $(PLATFORM_FLAGS)
-  NOOPT_XCODE5_X64_CC_FLAGS   = -target x86_64-pc-win32-macho -c -g -O0   
-Wall -Werror -Wextra -include AutoGen.h -funsigned-char -fno-ms-extensions 
-fno-stack-protector -fno-builtin -fshort-wchar -mno-implicit-float 
-mms-bitfields -Wno-unused-parameter -Wno-missing-braces 
-Wno-missing-field-initializers -Wno-tautological-compare -Wno-sign-compare 
-Wno-varargs 
-ftrap-function=undefined_behavior_has_been_optimized_away_by_clang -D 
NO_MSABI_VA_FUNCS $(PLATFORM_FLAGS)
+  DEBUG_XCODE5_X64_CC_FLAGS   = -target x86_64-pc-win32-macho -c -g -gdwarf 
-Os   -Wall -Werror -Wextra -include AutoGen.h -funsigned-char 
-fno-ms-extensions -fno-stack-protector -fno-builtin -fshort-wchar 
-mno-implicit-float -mms-bitfields -Wno-unused-parameter -Wno-missing-braces 
-Wno-missing-field-initializers -Wno-tautological-compare -Wno-sign-compare 
-Wno-varargs 
-ftrap-function=undefined_behavior_has_been_optimized_away_by_clang -D 
NO_MSABI_VA_FUNCS $(PLATFORM_FLAGS)
+  NOOPT_XCODE5_X64_CC_FLAGS   = -target x86_64-pc-win32-macho -c -g -gdwarf 
-O0   -Wall -Werror -Wextra -include AutoGen.h -funsigned-char 
-fno-ms-extensions -fno-stack-protector -fno-builtin -fshort-wchar 
-mno-implicit-float -mms-bitfields -Wno-unused-parameter -Wno-missing-braces 
-Wno-missing-field-initializers -Wno-tautological-compare -Wno-sign-compare 
-Wno-varargs 
-ftrap-function=undefined_behavior_has_been_optimized_away_by_clang -D 
NO_MSABI_VA_FUNCS $(PLATFORM_FLAGS)
 RELEASE_XCODE5_X64_CC_FLAGS   = -target x86_64-pc-win32-macho -c-Os   
-Wall -Werror -Wextra -include AutoGen.h -funsigned-char -fno-ms-extensions 
-fno-stack-protector -fno-builtin -fshort-wchar -mno-implicit-float 
-mms-bitfields -Wno-unused-parameter -Wno-missing-braces 
-Wno-missing-field-initializers -Wno-tautological-compare -Wno-sign-compare 
-Wno-varargs -Wno-unused-const-variable 
-ftrap-function=undefined_behavior_has_been_optimized_away_by_clang -D 
NO_MSABI_VA_FUNCS $(PLATFORM_FLAGS)
 
 

-- 
2.21.0.windows.1


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

View/Reply Online (#45768): https://edk2.groups.io/g/devel/message/45768
Mute This Topic: https://groups.io/mt/32894355/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [Patch V4 04/10] EmulatorPkg: Add support for NOOPT target

Add NOOPT to BUILD_TARGETS in DSC file.

Cc: Jordan Justen 
Cc: Andrew Fish 
Cc: Ray Ni 
Signed-off-by: Michael D Kinney 
Reviewed-by: Hao A Wu 
Reviewed-by: Jordan Justen 
---
 EmulatorPkg/EmulatorPkg.dsc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
index 529adfe1fa..0af2d1ff95 100644
--- a/EmulatorPkg/EmulatorPkg.dsc
+++ b/EmulatorPkg/EmulatorPkg.dsc
@@ -19,7 +19,7 @@ [Defines]
   OUTPUT_DIRECTORY   = Build/Emulator$(ARCH)
 
   SUPPORTED_ARCHITECTURES= X64|IA32
-  BUILD_TARGETS  = DEBUG|RELEASE
+  BUILD_TARGETS  = DEBUG|RELEASE|NOOPT
   SKUID_IDENTIFIER   = DEFAULT
   FLASH_DEFINITION   = EmulatorPkg/EmulatorPkg.fdf
 
-- 
2.21.0.windows.1


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

View/Reply Online (#45762): https://edk2.groups.io/g/devel/message/45762
Mute This Topic: https://groups.io/mt/32894349/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch v3 1/6] UefiCpuPkg/RegisterCpuFeaturesLib: Add "Test Then Write" Macros.

2019-08-15 Thread Zeng, Star




> -Original Message-
> From: Dong, Eric
> Sent: Friday, August 16, 2019 9:27 AM
> To: Zeng, Star ; devel@edk2.groups.io
> Cc: Ni, Ray ; Laszlo Ersek 
> Subject: RE: [Patch v3 1/6] UefiCpuPkg/RegisterCpuFeaturesLib: Add "Test
> Then Write" Macros.
> 
> > -Original Message-
> > From: Zeng, Star
> > Sent: Friday, August 16, 2019 9:15 AM
> > To: Dong, Eric ; devel@edk2.groups.io
> > Cc: Ni, Ray ; Laszlo Ersek ;
> > Zeng, Star 
> > Subject: RE: [Patch v3 1/6] UefiCpuPkg/RegisterCpuFeaturesLib: Add
> > "Test Then Write" Macros.
> >
> >
> >
> > > -Original Message-
> > > From: Dong, Eric
> > > Sent: Thursday, August 15, 2019 10:51 AM
> > > To: devel@edk2.groups.io
> > > Cc: Ni, Ray ; Laszlo Ersek ;
> > > Zeng, Star 
> > > Subject: [Patch v3 1/6] UefiCpuPkg/RegisterCpuFeaturesLib: Add "Test
> > > Then Write" Macros.
> > >
> > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2040
> > >
> > > Add below new micros which test the current value before write the
> > > new value. Only write new value when current value not same as new
> value.
> > >   CPU_REGISTER_TABLE_TEST_THEN_WRITE32
> > >   CPU_REGISTER_TABLE_TEST_THEN_WRITE64
> > >   CPU_REGISTER_TABLE_TEST_THEN_WRITE_FIELD
> > >
> > > Also add below API:
> > >   CpuRegisterTableTestThenWrite
> > >
> > > Signed-off-by: Eric Dong 
> > > Cc: Ray Ni 
> > > Cc: Laszlo Ersek 
> > > Cc: Star Zeng 
> > > ---
> > >  UefiCpuPkg/Include/AcpiCpuData.h  |  1 +
> > >  .../Include/Library/RegisterCpuFeaturesLib.h  | 91
> +++
> > >  .../RegisterCpuFeaturesLib.c  | 45 -
> > >  3 files changed, 134 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/UefiCpuPkg/Include/AcpiCpuData.h
> > > b/UefiCpuPkg/Include/AcpiCpuData.h
> > > index b963a2f592..472a1a8070 100644
> > > --- a/UefiCpuPkg/Include/AcpiCpuData.h
> > > +++ b/UefiCpuPkg/Include/AcpiCpuData.h
> > > @@ -81,6 +81,7 @@ typedef struct {
> > >UINT16 Reserved;  // offset 10 - 11
> > >UINT32 HighIndex; // offset 12-15, only valid for
> MemoryMapped
> > >UINT64 Value; // offset 16-23
> > > +  UINT8  TestThenWrite;   // 0ffset 24
> >
> > Could we use one byte of the Reserved field, but not add new field?
> > And use BOOLEAN type for it?
> 
> I'm not sure whether use the Reserved field is an correct approach, do you
> have samples which use the reserved fields?
> But I think add new field is a more safe one.

What "more safe" means here? Adding new field extends the structure, from the 
structure layout view of point, it is an incompatible change, the structure 
size is not just from 24 to 25 bytes, but to be nature aligned, the structure 
size will be (24 + 8) 32. Since there is Reserved field can be reused, that 
size impact can be removed.

FspGlobalData.h:
SHA-1: a2e61f341d26a78751b2f19b5004c6bbfc8b4fa9
* IntelFsp2Pkg: Support FSP Dispatch mode

MemoryProfile.h
SHA-1: 072a3ca1d36a42aec97f871c808776ee7038ca06 (related to 
94092aa60341a3e4b1e1ea7c362781b8404ac538)
* MdeModulePkg MemoryProfile.h:two bytes of Reserved[4] as ActionStringOffset


If needed, more comments from Ray, Laszlo, Jiewen, Liming and Mike will be 
better.


Thanks,
Star

> 
> Thanks,
> Eric
> >
> > Thanks,
> > Star
> >
> > >  } CPU_REGISTER_TABLE_ENTRY;
> > >
> > >  //
> > > diff --git a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> > > b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> > > index e420e7f075..5bd464b32e 100644
> > > --- a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> > > +++ b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> > > @@ -348,6 +348,32 @@ CpuRegisterTableWrite (
> > >IN UINT64  Value
> > >);
> > >
> > > +/**
> > > +  Adds an entry in specified register table.
> > > +
> > > +  This function adds an entry in specified register table, with
> > > + given register type,  register index, bit section and value.
> > > +
> > > +  Driver will  test the current value before setting new value.
> > > +
> > > +  @param[in]  ProcessorNumber  The index of the CPU to add a
> > > + register
> > > table entry
> > > +  @param[in]  RegisterType Type of the register to program
> > > +  @param[in]  IndexIndex of the register to program
> > > +  @param[in]  ValueMaskMask of bits in register to write
> > > +  @param[in]  ValueValue to write
> > > +
> > > +  @note This service could be called by BSP only.
> > > +**/
> > > +VOID
> > > +EFIAPI
> > > +CpuRegisterTableTestThenWrite (
> > > +  IN UINTN   ProcessorNumber,
> > > +  IN REGISTER_TYPE   RegisterType,
> > > +  IN UINT64  Index,
> > > +  IN UINT64  ValueMask,
> > > +  IN UINT64  Value
> > > +  );
> > > +
> > >  /**
> > >Adds an entry in specified Pre-SMM register table.
> > >
> > > @@ -390,6 +416,26 @@ PreSmmCpuRegisterTableWrite (
> > >  CpuRegisterTableWrite (ProcessorNumber,

Re: [edk2-devel] ovmf build fail with gcc 4.8.5

2019-08-15 Thread Chen, Farrah

Thanks, we use the latest commit and it works well now.


Thanks,
Fan



-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, August 13, 2019 8:23 PM
To: devel@edk2.groups.io; Chen, Farrah 
Cc: Hao, Xudong 
Subject: Re: [edk2-devel] ovmf build fail with gcc 4.8.5

On 08/13/19 03:13, Chen, Farrah wrote:
> Hi,
> 
> When build ovmf with the latest two commits of master branch, we meet error 
> on Red Hat 7.6 with gcc version 4.8.5, but succeed on Red Hat 8.0 with gcc 
> version 8.2.1.
> 
> Steps:
> git clone https://github.com/tianocore/edk2.git
> cd edk2
> git submodule init
> git submodule update -recursive
> OvmfPkg/build.sh -a X64 -n 64
> 
> Error log:
> ...
> /home/build/kvm_build/nightly/kvm_qemu/kvm-next-20190813010558-a738b5e7-5e7bcdcf/edk2/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c:641:50:
>  error: 'PageMapLevel5Entry' may be used uninitialized in this function 
> [-Werror=maybe-uninitialized]
>PAGE_MAP_AND_DIRECTORY_POINTER*PageMapLevel5Entry;
>   ^
> cc1: all warnings being treated as errors "objcopy"
> /home/build/kvm_build/nightly/kvm_qemu/kvm-next-20190813010558-a738b5e
> 7-5e7bcdcf/edk2/Build/OvmfX64/DEBUG_GCC48/X64/MdeModulePkg/Bus/Pci/Pci
> HostBridgeDxe/PciHostBridgeDxe/DEBUG/PciHostBridgeDxe.dll
> "GenFw" -e UEFI_DRIVER -o 
> /home/build/kvm_build/nightly/kvm_qemu/kvm-next-20190813010558-a738b5e
> 7-5e7bcdcf/edk2/Build/OvmfX64/DEBUG_GCC48/X64/OvmfPkg/XenBusDxe/XenBus
> Dxe/OUTPUT/XenBusDxe.efi 
> /home/build/kvm_build/nightly/kvm_qemu/kvm-next-20190813010558-a738b5e
> 7-5e7bcdcf/edk2/Build/OvmfX64/DEBUG_GCC48/X64/OvmfPkg/XenBusDxe/XenBus
> Dxe/DEBUG/XenBusDxe.dll
> make: *** 
> [/home/build/kvm_build/nightly/kvm_qemu/kvm-next-20190813010558-a738b5
> e7-5e7bcdcf/edk2/Build/OvmfX64/DEBUG_GCC48/X64/MdeModulePkg/Core/DxeIp
> lPeim/DxeIpl/OUTPUT/X64/VirtualMemory.obj] Error 1 cp -f 
> /home/build/kvm_build/nightly/kvm_qemu/kvm-next-20190813010558-a738b5e
> 7-5e7bcdcf/edk2/Build/OvmfX64/DEBUG_GCC48/X64/OvmfPkg/XenBusDxe/XenBus
> Dxe/OUTPUT/XenBusDxe.efi 
> /home/build/kvm_build/nightly/kvm_qemu/kvm-next-20190813010558-a738b5e
> 7-5e7bcdcf/edk2/Build/OvmfX64/DEBUG_GCC48/X64/OvmfPkg/XenBusDxe/XenBus
> Dxe/DEBUG
> 
> 
> build.py...
> : error 7000: Failed to execute command
> make tbuild 
> [/home/build/kvm_build/nightly/kvm_qemu/kvm-next-20190813010558-a738b5
> e7-5e7bcdcf/edk2/Build/OvmfX64/DEBUG_GCC48/X64/MdeModulePkg/Core/DxeIp
> lPeim/DxeIpl]
> 
> 
> 
> 
> build.py...
> : error F002: Failed to build module
> 
> /home/build/kvm_build/nightly/kvm_qemu/kvm-next-20190813010558-a738b5e
> 7-5e7bcdcf/edk2/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf [X64, GCC48, 
> DEBUG]
> 
> - Failed -
> Build end time: 08:46:33, Aug.13 2019
> Build total time: 00:01:15
> 
> GCC:
> gcc --version
> gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36) Copyright (C) 2015 Free 
> Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There 
> is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
> PURPOSE.

This bug was introduced in commit b3527dedc395 ("MdeModulePkg/DxeIpl:
Create 5-level page table for long mode", 2019-08-09).

It's being addressed in the following (pending) patch:

[edk2-devel] [PATCH 1/1] MdeModulePkg/DxeIplPeim: Relocate the operation of 
PageMapLevel5Entry++

(I'm calling the issue a bug and not an invalid compiler warning because the 
patch looks like an actual fix.)

Thanks
Laszlo

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

View/Reply Online (#45756): https://edk2.groups.io/g/devel/message/45756
Mute This Topic: https://groups.io/mt/32848232/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch v3 1/6] UefiCpuPkg/RegisterCpuFeaturesLib: Add "Test Then Write" Macros.

> -Original Message-
> From: Zeng, Star
> Sent: Friday, August 16, 2019 9:15 AM
> To: Dong, Eric ; devel@edk2.groups.io
> Cc: Ni, Ray ; Laszlo Ersek ; Zeng,
> Star 
> Subject: RE: [Patch v3 1/6] UefiCpuPkg/RegisterCpuFeaturesLib: Add "Test
> Then Write" Macros.
> 
> 
> 
> > -Original Message-
> > From: Dong, Eric
> > Sent: Thursday, August 15, 2019 10:51 AM
> > To: devel@edk2.groups.io
> > Cc: Ni, Ray ; Laszlo Ersek ;
> > Zeng, Star 
> > Subject: [Patch v3 1/6] UefiCpuPkg/RegisterCpuFeaturesLib: Add "Test
> > Then Write" Macros.
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2040
> >
> > Add below new micros which test the current value before write the new
> > value. Only write new value when current value not same as new value.
> >   CPU_REGISTER_TABLE_TEST_THEN_WRITE32
> >   CPU_REGISTER_TABLE_TEST_THEN_WRITE64
> >   CPU_REGISTER_TABLE_TEST_THEN_WRITE_FIELD
> >
> > Also add below API:
> >   CpuRegisterTableTestThenWrite
> >
> > Signed-off-by: Eric Dong 
> > Cc: Ray Ni 
> > Cc: Laszlo Ersek 
> > Cc: Star Zeng 
> > ---
> >  UefiCpuPkg/Include/AcpiCpuData.h  |  1 +
> >  .../Include/Library/RegisterCpuFeaturesLib.h  | 91 +++
> >  .../RegisterCpuFeaturesLib.c  | 45 -
> >  3 files changed, 134 insertions(+), 3 deletions(-)
> >
> > diff --git a/UefiCpuPkg/Include/AcpiCpuData.h
> > b/UefiCpuPkg/Include/AcpiCpuData.h
> > index b963a2f592..472a1a8070 100644
> > --- a/UefiCpuPkg/Include/AcpiCpuData.h
> > +++ b/UefiCpuPkg/Include/AcpiCpuData.h
> > @@ -81,6 +81,7 @@ typedef struct {
> >UINT16 Reserved;  // offset 10 - 11
> >UINT32 HighIndex; // offset 12-15, only valid for 
> > MemoryMapped
> >UINT64 Value; // offset 16-23
> > +  UINT8  TestThenWrite;   // 0ffset 24
> 
> Could we use one byte of the Reserved field, but not add new field? And use
> BOOLEAN type for it?

I'm not sure whether use the Reserved field is an correct approach, do you have 
samples which use the reserved fields?
But I think add new field is a more safe one.

Thanks,
Eric
> 
> Thanks,
> Star
> 
> >  } CPU_REGISTER_TABLE_ENTRY;
> >
> >  //
> > diff --git a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> > b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> > index e420e7f075..5bd464b32e 100644
> > --- a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> > +++ b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> > @@ -348,6 +348,32 @@ CpuRegisterTableWrite (
> >IN UINT64  Value
> >);
> >
> > +/**
> > +  Adds an entry in specified register table.
> > +
> > +  This function adds an entry in specified register table, with given
> > + register type,  register index, bit section and value.
> > +
> > +  Driver will  test the current value before setting new value.
> > +
> > +  @param[in]  ProcessorNumber  The index of the CPU to add a register
> > table entry
> > +  @param[in]  RegisterType Type of the register to program
> > +  @param[in]  IndexIndex of the register to program
> > +  @param[in]  ValueMaskMask of bits in register to write
> > +  @param[in]  ValueValue to write
> > +
> > +  @note This service could be called by BSP only.
> > +**/
> > +VOID
> > +EFIAPI
> > +CpuRegisterTableTestThenWrite (
> > +  IN UINTN   ProcessorNumber,
> > +  IN REGISTER_TYPE   RegisterType,
> > +  IN UINT64  Index,
> > +  IN UINT64  ValueMask,
> > +  IN UINT64  Value
> > +  );
> > +
> >  /**
> >Adds an entry in specified Pre-SMM register table.
> >
> > @@ -390,6 +416,26 @@ PreSmmCpuRegisterTableWrite (
> >  CpuRegisterTableWrite (ProcessorNumber, RegisterType, Index,
> > MAX_UINT32, Value);  \
> >} while(FALSE);
> >
> > +/**
> > +  Adds a 32-bit register write entry in specified register table.
> > +
> > +  This macro adds an entry in specified register table, with given
> > + register type,  register index, and value.
> > +
> > +  Driver will  test the current value before setting new value.
> > +
> > +  @param[in]  ProcessorNumber  The index of the CPU to add a register
> > table entry.
> > +  @param[in]  RegisterType Type of the register to program
> > +  @param[in]  IndexIndex of the register to program
> > +  @param[in]  ValueValue to write
> > +
> > +  @note This service could be called by BSP only.
> > +**/
> > +#define CPU_REGISTER_TABLE_TEST_THEN_WRITE32(ProcessorNumber,
> > RegisterType, Index, Value) \
> > +  do { 
> >\
> > +CpuRegisterTableTestThenWrite (ProcessorNumber, RegisterType,
> > +Index, MAX_UINT32, Value);  \
> > +  } while(FALSE);
> > +
> >  /**
> >Adds a 64-bit register write entry in specified register table.
> >
> > @@ -408,6 +454,26 @@ PreSmmCpuRegisterTableWrite (
> >  CpuRegisterTableWrite

Re: [edk2-devel] [Patch v3 1/6] UefiCpuPkg/RegisterCpuFeaturesLib: Add "Test Then Write" Macros.

2019-08-15 Thread Zeng, Star




> -Original Message-
> From: Dong, Eric
> Sent: Thursday, August 15, 2019 10:51 AM
> To: devel@edk2.groups.io
> Cc: Ni, Ray ; Laszlo Ersek ; Zeng,
> Star 
> Subject: [Patch v3 1/6] UefiCpuPkg/RegisterCpuFeaturesLib: Add "Test Then
> Write" Macros.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2040
> 
> Add below new micros which test the current value before write the new
> value. Only write new value when current value not same as new value.
>   CPU_REGISTER_TABLE_TEST_THEN_WRITE32
>   CPU_REGISTER_TABLE_TEST_THEN_WRITE64
>   CPU_REGISTER_TABLE_TEST_THEN_WRITE_FIELD
> 
> Also add below API:
>   CpuRegisterTableTestThenWrite
> 
> Signed-off-by: Eric Dong 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Cc: Star Zeng 
> ---
>  UefiCpuPkg/Include/AcpiCpuData.h  |  1 +
>  .../Include/Library/RegisterCpuFeaturesLib.h  | 91 +++
>  .../RegisterCpuFeaturesLib.c  | 45 -
>  3 files changed, 134 insertions(+), 3 deletions(-)
> 
> diff --git a/UefiCpuPkg/Include/AcpiCpuData.h
> b/UefiCpuPkg/Include/AcpiCpuData.h
> index b963a2f592..472a1a8070 100644
> --- a/UefiCpuPkg/Include/AcpiCpuData.h
> +++ b/UefiCpuPkg/Include/AcpiCpuData.h
> @@ -81,6 +81,7 @@ typedef struct {
>UINT16 Reserved;  // offset 10 - 11
>UINT32 HighIndex; // offset 12-15, only valid for 
> MemoryMapped
>UINT64 Value; // offset 16-23
> +  UINT8  TestThenWrite;   // 0ffset 24

Could we use one byte of the Reserved field, but not add new field? And use 
BOOLEAN type for it?

Thanks,
Star

>  } CPU_REGISTER_TABLE_ENTRY;
> 
>  //
> diff --git a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> index e420e7f075..5bd464b32e 100644
> --- a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> +++ b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> @@ -348,6 +348,32 @@ CpuRegisterTableWrite (
>IN UINT64  Value
>);
> 
> +/**
> +  Adds an entry in specified register table.
> +
> +  This function adds an entry in specified register table, with given
> + register type,  register index, bit section and value.
> +
> +  Driver will  test the current value before setting new value.
> +
> +  @param[in]  ProcessorNumber  The index of the CPU to add a register
> table entry
> +  @param[in]  RegisterType Type of the register to program
> +  @param[in]  IndexIndex of the register to program
> +  @param[in]  ValueMaskMask of bits in register to write
> +  @param[in]  ValueValue to write
> +
> +  @note This service could be called by BSP only.
> +**/
> +VOID
> +EFIAPI
> +CpuRegisterTableTestThenWrite (
> +  IN UINTN   ProcessorNumber,
> +  IN REGISTER_TYPE   RegisterType,
> +  IN UINT64  Index,
> +  IN UINT64  ValueMask,
> +  IN UINT64  Value
> +  );
> +
>  /**
>Adds an entry in specified Pre-SMM register table.
> 
> @@ -390,6 +416,26 @@ PreSmmCpuRegisterTableWrite (
>  CpuRegisterTableWrite (ProcessorNumber, RegisterType, Index,
> MAX_UINT32, Value);  \
>} while(FALSE);
> 
> +/**
> +  Adds a 32-bit register write entry in specified register table.
> +
> +  This macro adds an entry in specified register table, with given
> + register type,  register index, and value.
> +
> +  Driver will  test the current value before setting new value.
> +
> +  @param[in]  ProcessorNumber  The index of the CPU to add a register
> table entry.
> +  @param[in]  RegisterType Type of the register to program
> +  @param[in]  IndexIndex of the register to program
> +  @param[in]  ValueValue to write
> +
> +  @note This service could be called by BSP only.
> +**/
> +#define CPU_REGISTER_TABLE_TEST_THEN_WRITE32(ProcessorNumber,
> RegisterType, Index, Value) \
> +  do {   
>  \
> +CpuRegisterTableTestThenWrite (ProcessorNumber, RegisterType,
> +Index, MAX_UINT32, Value);  \
> +  } while(FALSE);
> +
>  /**
>Adds a 64-bit register write entry in specified register table.
> 
> @@ -408,6 +454,26 @@ PreSmmCpuRegisterTableWrite (
>  CpuRegisterTableWrite (ProcessorNumber, RegisterType, Index,
> MAX_UINT64, Value);  \
>} while(FALSE);
> 
> +/**
> +  Adds a 64-bit register write entry in specified register table.
> +
> +  This macro adds an entry in specified register table, with given
> + register type,  register index, and value.
> +
> +  Driver will  test the current value before setting new value.
> +
> +  @param[in]  ProcessorNumber  The index of the CPU to add a register
> table entry.
> +  @param[in]  RegisterType Type of the register to program
> +  @param[in]  IndexIndex of the register to program
> +  @param[in]  ValueValue to write
> +
> +  @note This service could be called by BSP only.
> +**/
> +#define

Re: [edk2-devel] [PATCH v2 1/1] MdeModulePkg/DxeIplPeim: Initialize pointer PageMapLevel5Entry

2019-08-15 Thread Wu, Hao A

> -Original Message-
> From: Gao, Liming
> Sent: Thursday, August 15, 2019 4:31 PM
> To: Wu, Hao A; Zhang, Shenglei; devel@edk2.groups.io
> Cc: Bi, Dandan
> Subject: RE: [PATCH v2 1/1] MdeModulePkg/DxeIplPeim: Initialize pointer
> PageMapLevel5Entry
> 
> That's fine. Thanks!
> 
> >-Original Message-
> >From: Wu, Hao A
> >Sent: Thursday, August 15, 2019 3:23 PM
> >To: Gao, Liming ; Zhang, Shenglei
> >; devel@edk2.groups.io
> >Cc: Bi, Dandan 
> >Subject: RE: [PATCH v2 1/1] MdeModulePkg/DxeIplPeim: Initialize pointer
> >PageMapLevel5Entry
> >
> >> -Original Message-
> >> From: Gao, Liming
> >> Sent: Thursday, August 15, 2019 10:27 AM
> >> To: Zhang, Shenglei; devel@edk2.groups.io
> >> Cc: Bi, Dandan; Wu, Hao A
> >> Subject: RE: [PATCH v2 1/1] MdeModulePkg/DxeIplPeim: Initialize pointer
> >> PageMapLevel5Entry
> >>
> >> Shenglei:
> >>
> >> > -Original Message-
> >> > From: Zhang, Shenglei
> >> > Sent: Thursday, August 15, 2019 10:23 AM
> >> > To: devel@edk2.groups.io
> >> > Cc: Bi, Dandan ; Gao, Liming
> >> ; Wu, Hao A 
> >> > Subject: [PATCH v2 1/1] MdeModulePkg/DxeIplPeim: Initialize pointer
> >> PageMapLevel5Entry
> >> >
> >> > Initialize PageMapLevel5Entry at the beginning of the function.
> >> >
> >> > This commit will fix a GCC 4.8.5 build failure introduced by commit
> >> > b3527dedc3951f061c5a73cb4fb2b0f95f47e08b.
> >> >
> >> > OvmfPkg build failure wtih gcc 4.8.5 still exists at latest edk2 version.
> >> > The commit 46f8a6891606746ca8b1e684ac379ce271306dc0 seems not to
> fix
> >> > the build failure completely.
> >> >
> >> > Cc: Dandan Bi 
> >> > Cc: Liming Gao 
> >> > Cc: Hao A Wu 
> >> > Signed-off-by: Shenglei Zhang 
> >> > ---
> >> > v2: Add comments to state why set initialize to NULL.
> >> >
> >> >  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 5 +
> >> >  1 file changed, 5 insertions(+)
> >> >
> >> > diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> >> b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> >> > index 2389f3eb485b..2f1038b1e67e 100644
> >> > --- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> >> > +++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> >> > @@ -652,6 +652,11 @@ CreateIdentityMappingPageTables (
> >> >UINT64AddressEncMask;
> >> >IA32_CR4  Cr4;
> >> >
> >> > +  //
> >> > +  // set PageMapLevel5Entry to suppress incorrect compiler/analyzer
> >> warnigns
> >>
> >> Please fix the typo warnigns ==> warnings
> >
> >
> >Hello Liming,
> >
> >I will fix the above typo when I push the patch.
> >Also, I will keep your RB tag from V1 patch since there is only comment
> >change between the two versions.


Reviewed-by: Hao A Wu 
With the above typo fixed, pushed via commit 0680d08683.

Best Regards,
Hao Wu


> >
> >Best Regards,
> >Hao Wu
> >
> >
> >>
> >> Thanks
> >> Liming
> >> > +  //
> >> > +  PageMapLevel5Entry = NULL;
> >> > +
> >> >//
> >> >// Make sure AddressEncMask is contained to smallest supported
> >address
> >> field
> >> >//
> >> > --
> >> > 2.18.0.windows.1


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

View/Reply Online (#45753): https://edk2.groups.io/g/devel/message/45753
Mute This Topic: https://groups.io/mt/32882542/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Determining TSC frequency programmatically

2019-08-15 Thread Vitaly Cheptsov via Groups.Io

Hello,

I initially raised this question in a new TimerLib patch[1], but as the
discussion was getting more distracted, I decided to create a separate thread
in hopes new people could join.

The issue is that our UEFI bootloader needs to obtain TSC frequency to pass it
to our specialised operating system that uses TSC for scheduling on x86.

For a while we went with ACPI power management timer to measure the frequency,
but as modern Intel CPUs support CPUID 15H leaf (CPUID_TIME_STAMP_COUNTER) we
try to use where possible for better accuracy. The issue with this CPUID leaf
is that the crystal clock frequency returned in ECX register is optional and
therefore can be 0. Intel SDM suggests to use a static value in this case[2],
but it is completely opaque on how to match the running CPU with its static
value from SDM.

Initially we went with CPUID model checking, but this failed badly for Xeon
Scalable and Xeon W, as they share the CPUID (06_55H) but have different
crystal clock frequencies (25 MHz vs 24 MHz accordingly). Donald Kuo gave a
good hint in the previous thread that client CPUs usually get 24 MHz crystal
clock, server CPUs have 25, and Atoms have 19.2. This, however, does not make
the situation easier as we do not see a way to determine CPU vertical segment
without e.g. parsing the CPUID brand string.

Apparently, we are not alone, and different open-source operating systems have
different workarounds to this issue. For example, Linux kernel went with using
marketing frequency from CPUID 16H leaf (CPUID_PROCESSOR_FREQUENCY)[3], and BSD
flavours fallback to older methods when neither crystal clock frequency can be
obtained through CPUID 15H, nor unambiguous CPUID models exist to be able to
use static values.

Another issue we see with EDK II TimerLib implementations for x86 is that they
are very model specific. As Michael Kinney said, the situation is not a problem
when you use TimerLib for BSP bringup, as you already know the CPU family you
target, however, it is not great for other uses, although they may be
discouraged. In our opinion, regardless of the use, this approach has a number
of design issues.

All modern Intel x86 CPUs have virtual TSC counter that has fixed frequency. In
fact, this is true for most, if not all, modern x86 CPUs by other vendors as
well. This makes us believe that EDK II should have generic TscTimerLib for
x86, which will work anywhere when given valid TSC frequency, and
TscFrequencyLib, which would determine TSC frequency in a vendor-specific
method. Ideally there exists GenericTscFrequencyLib that can do this for a wide
majority of CPUs through different methods at runtime, including CPUID 15H,
ACPI power management, vendor-specific extensions, etc.

To summarise:
- We need to know how to match current running CPU with its crystal clock
frequency when CPUID 15H reports 0 ECX.
- We would like to suggest to split TSC-based TimerLib in two libraries:
generic with timer implementation and platform-specific with TSC frequency
discovery.
- We wonder whether a generic vendor-supported TSC frequency discovery library
working on a wide range of CPUs is feasible to have in EDK II mainline.

Best regards,
Vitaly

[1]
https://edk2.groups.io/g/devel/topic/patch_ueficpupkg_adding_a/32839184?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,32839184

[PATCH] UefiCpuPkg: Adding a new TSC library by using CPUID(0x15) TSC leaf
[2] 18.7.3 Determining the Processor Base Frequency
Table 18-75. Nominal Core Crystal Clock Frequency
[3] https://lore.kernel.org/lkml/20190509055417.13152-1-dr...@endlessm.com/

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

View/Reply Online (#45750): https://edk2.groups.io/g/devel/message/45750
Mute This Topic: https://groups.io/mt/32891598/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

signature.asc
Description: OpenPGP digital signature

Re: [edk2-devel] [edk2-platform patch 7/7] Platform/Intel: Add build option for SIMICS QSP Platform

Hi David,

Here are my comments:

1. Please remove " Contributed-under: TianoCore Contribution Agreement 1.0" 
from your commit message as it is no longer needed.
2. Please don't add this entry: WhiskeylakeURvp = 
WhiskeylakeOpenBoardPkg/WhiskeylakeURvp/build_config.cfg

WhiskeylakeOpenBoardPkg does not exist yet, and it will be coming from a 
separate patch series.

3. Please rename BoardX58ICH10 to follow Pascal casing: BoardX58Ich10
4. Please update edk2-platforms/Platform/Intel/Readme.md to add 
SimicsOpenBoardPkg to the Board Support list.

Other than that, looks good! Please send an updated patch.

Thanks,
Nate

-Original Message-
From: Wei, David Y 
Sent: Friday, August 9, 2019 3:47 PM
To: devel@edk2.groups.io
Cc: Wu, Hao A ; Gao, Liming ; Sinha, 
Ankit ; Agyeman, Prince ; 
Kubacki, Michael A ; Desimone, Nathaniel L 
; Kinney, Michael D 
Subject: [edk2-platform patch 7/7] Platform/Intel: Add build option for SIMICS 
QSP Platform

Add build option in build script for SIMICS QSP Platform

Cc: Hao Wu 
Cc: Liming Gao 
Cc: Ankit Sinha 
Cc: Agyeman Prince 
Cc: Kubacki Michael A 
Cc: Nate DeSimone 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: David Wei 
---
 Platform/Intel/build.cfg | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Platform/Intel/build.cfg b/Platform/Intel/build.cfg index 
fc6e4fe824..2ebe09a632 100644
--- a/Platform/Intel/build.cfg
+++ b/Platform/Intel/build.cfg
@@ -54,3 +54,5 @@ NUMBER_OF_PROCESSORS = 0
 KabylakeRvp3 = KabylakeOpenBoardPkg/KabylakeRvp3/build_config.cfg
 N1xxWU = ClevoOpenBoardPkg/N1xxWU/build_config.cfg
 BoardMtOlympus = PurleyOpenBoardPkg/BoardMtOlympus/build_config.cfg
+WhiskeylakeURvp = 
+WhiskeylakeOpenBoardPkg/WhiskeylakeURvp/build_config.cfg
+BoardX58ICH10 = SimicsOpenBoardPkg/BoardX58ICH10/build_config.cfg
--
2.16.2.windows.1


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

View/Reply Online (#45748): https://edk2.groups.io/g/devel/message/45748
Mute This Topic: https://groups.io/mt/32816101/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platform patch 4/7] SimicsOpenBoardPkg: Add DXE driver for Legacy Sio

Hi David,

Here are my comments:

1. What is the purpose of this driver? My guess this is just a dummy driver 
that provides the EFI_SIO_PROTOCOL and does resource management without 
actually accessing the SIO?
2. All of the copyright years need to be updated to 2019.
3. Please remove " Contributed-under: TianoCore Contribution Agreement 1.0" 
from your commit message as it is no longer needed.
4. Please remove interspersed trailing white-space from the following files:

  * Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioDriver.c
  * Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioService.c
  * Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioService.h

Other than that, looks good! Please send an updated patch.

Thanks,
Nate

-Original Message-
From: Wei, David Y 
Sent: Friday, August 9, 2019 3:47 PM
To: devel@edk2.groups.io
Cc: Wu, Hao A ; Gao, Liming ; Sinha, 
Ankit ; Agyeman, Prince ; 
Kubacki, Michael A ; Desimone, Nathaniel L 
; Kinney, Michael D 
Subject: [edk2-platform patch 4/7] SimicsOpenBoardPkg: Add DXE driver for 
Legacy Sio

Add DXE driver for Legacy Sio support

Cc: Hao Wu 
Cc: Liming Gao 
Cc: Ankit Sinha 
Cc: Agyeman Prince 
Cc: Kubacki Michael A 
Cc: Nate DeSimone 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: David Wei 
---
 .../LegacySioDxe/ComponentName.c   | 173 ++
 .../SimicsOpenBoardPkg/LegacySioDxe/SioChip.c  | 272 ++
 .../SimicsOpenBoardPkg/LegacySioDxe/SioDriver.c| 600 +
 .../SimicsOpenBoardPkg/LegacySioDxe/SioService.c   | 249 +
 .../LegacySioDxe/ComponentName.h   |  87 +++
 .../LegacySioDxe/LegacySioDxe.inf  |  54 ++
 .../SimicsOpenBoardPkg/LegacySioDxe/Register.h |  15 +
 .../SimicsOpenBoardPkg/LegacySioDxe/SioChip.h  | 195 +++
 .../SimicsOpenBoardPkg/LegacySioDxe/SioDriver.h| 134 +
 .../SimicsOpenBoardPkg/LegacySioDxe/SioService.h   | 143 +
 10 files changed, 1922 insertions(+)
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/ComponentName.c
 create mode 100644 Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioChip.c
 create mode 100644 Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioDriver.c
 create mode 100644 Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioService.c
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/ComponentName.h
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/LegacySioDxe.inf
 create mode 100644 Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/Register.h
 create mode 100644 Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioChip.h
 create mode 100644 Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioDriver.h
 create mode 100644 Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioService.h

diff --git a/Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/ComponentName.c 
b/Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/ComponentName.c
new file mode 100644
index 00..93e8cefe6c
--- /dev/null
+++ b/Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/ComponentName.c
@@ -0,0 +1,173 @@
+/** @file
+  Install Base and Size Info Ppi for Firmware Volume Recovery.
+
+  Copyright (c) 2013 - 2016 Intel Corporation. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include "SioDriver.h"
+
+///
+/// Component Name Protocol instance
+///
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME_PROTOCOL  mSioComponentName = 
{
+  SioComponentNameGetDriverName,
+  SioComponentNameGetControllerName,
+  "eng"
+};
+
+///
+/// Component Name 2 Protocol instance
+///
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME2_PROTOCOL mSioComponentName2 
= {
+  (EFI_COMPONENT_NAME2_GET_DRIVER_NAME)SioComponentNameGetDriverName,
+  (EFI_COMPONENT_NAME2_GET_CONTROLLER_NAME)SioComponentNameGetControllerName,
+  "en"
+};
+
+///
+/// Table of driver names
+///
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_UNICODE_STRING_TABLE mSioDriverNameTable[] = 
{
+  {
+"eng;en",
+L"Super I/O Driver"
+  },
+  {
+NULL,
+NULL
+  }
+};
+
+///
+/// Table of Controller names
+///
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_UNICODE_STRING_TABLE 
mSioControllerNameTable[] = {
+  {
+"eng;en",
+L"Super I/O Controller"
+  },
+  {
+NULL,
+NULL
+  }
+};
+
+/**
+  Retrieves a Unicode string that is the user-readable name of the EFI Driver.
+
+  @param  This   A pointer to the EFI_COMPONENT_NAME_PROTOCOL instance.
+  @param  Language   A pointer to a three-character ISO 639-2 language 
identifier.
+ This is the language of the driver name that that the 
caller
+ is requesting, and it must match one of the languages 
specified
+ in SupportedLanguages.  The number of languages supported 
by a
+ driver is up to the driver writer.
+  @param  DriverName A pointer to the Unicode string to return.  This Unicode 
string
+ is the name of the driver

Re: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by using CPUID(0x15) TSC leaf

Vitaly,

When implementing a UEFI Application, if you want maximum compatibility, you 
should use UEFI Services/Protocols and minimize as many HW assumptions as 
possible.

I understand, especially for accurate time and clock related services, the that 
the UEFI Specification defined Services/Protocols can be challenging to use.

When adding content that uses HW such as TSC or CPUID the UEFI App should be 
implemented with good detection logic to know it is safe to use that HW, and 
contain the fallback logic to use an alternate mechanism if the required HW is 
not present.  This is a very different approach than some early FW 
initialization code that can safely make some HW assumptions that helps keep 
the FW init code small and efficient.  This does imply that different libraries 
may be required for FW init and UEFI Applications.

Thanks,

Mike

From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Vitaly 
Cheptsov via Groups.Io
Sent: Thursday, August 15, 2019 5:10 AM
To: Kuo, Donald 
Cc: devel@edk2.groups.io
Subject: Re: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by using 
CPUID(0x15) TSC leaf

Hi Donald,

Glad to hear it helped a little, and sorry for some outdated quotes.

Your clarification regarding model range is very helpful. Xeon W being client 
and thus having client clock makes sense, though I must say it was quite not 
obvious. I was referring to the same SDM table, and it would have been great to 
have vertical range binding instead of the misleading CPUID.

With that, however, I still do not see a way to dynamically determine the 
difference between Xeon client and server.

For us it is needed as we use TimerLib differently. For you TimerLib is a part 
of BSP, so you face no issue statically setting the clock frequency as a PCD. 
For us TimerLib is used as a part of an UEFI application compatible with 
different hardware, and in fact not just Intel. We have such "generic TimerLib" 
library, and to determine CPU frequency, as a fallback to CPUID 15H, it relies 
on ACPI PM timer. This is not great for two reasons:
- we have to maintain it ourselves, while we would have liked that be part of 
EDK II with different vendors contributing to the project.
- we still cannot find an obvious way to determine crystal clock when it is not 
reported, in particular for Xeon W and Xeon Scalable case.

I guess this is now out of the scope of this patch and perhaps even this exact 
library, but it will be helpful to hear relevant technical details on the issue 
and opinions on such "generic TimerLib" library to later appear in EDK II.

Best regards,
Vitaly
15 авг. 2019 г., в 11:40, Kuo, Donald 
mailto:donald@intel.com>> написал(а):

Hi Vitaly,

Appreciated for reviewing very detail. And looks your captured some piece of 
code is older version. And should be ok, I do got your point.

Item #1
-  I do missed RegEax error handling in case for 
CpuidCoreClockCalculateTscFrequency () should return 0 and EFI_UNSUPPORTED. AR: 
Will update it.

Item #2:
-  Actually the information is from SDM Table 18-85
o   As we know CPUID signature could be hard to identify processor XTAL 
frequency is? So we only check CPUID Leaf 0x15
o   And the PCD will be defined depends on platform specific and during project 
early development. Based on SDM, Intel processor for CPUID.15h EAX and EBX is 
enumerated, but ECX could be possible not enumerated. So that is why we based 
on  SDM Table 18-85 to create PCD as below:
•  Intel Xeon Server family: 25MHz
•  Intel Core and Intel Xeon W family: 24MHz
•  Intel Atom : 19.2MHz
•  So regards the “06_55h” might cause the confused, we could review it whether 
remove it??
Item #3:
-  Again, the XTAL frequency is optional and should be define in early 
phase of new project. Default should still use AcpiTimer.
oPlatform / developer owner should well know the CPU generation XTAL 
frequency is? Server / Client / Atom ?
o   For those CPU not supported should still use AcpiTimerLib (default)

Thanks,
Donald

From: vit9696 via [] [mailto:vit9696=protonmail.com@[]]
Sent: Thursday, August 15, 2019 3:20 PM
To: Kuo, Donald mailto:donald@intel.com>>; 
devel@edk2.groups.io
Subject: Re: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by using 
CPUID(0x15) TSC leaf

Hello,

Thank you for the patch! I reviewed the code and noticed select issues 
explained below.

1. The following construction:

if (RegEbx == 0) {
DEBUG ((DEBUG_ERROR, "The CPU is not capble for Core Crystal Clock Frequency 
!!\n"));
ASSERT (RegEbx != 0);
}

Does not look good to me, and in my opinion, should be written differently:

if (RegEbx == 0 || RegEax == 0) {
DEBUG ((DEBUG_ERROR, "The CPU is not capble for Core Crystal Clock Frequency 
!!\n"));
ASSERT (RegEbx != 0);
  ASSERT (RegEax != 0);
  return 0;
}

The reason for the above code being wrong is potential division by zero below, 
which behaviour is

Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

2019-08-15 Thread Igor Mammedov

On Thu, 15 Aug 2019 17:00:16 +0200
Laszlo Ersek  wrote:

> On 08/14/19 16:04, Paolo Bonzini wrote:
> > On 14/08/19 15:20, Yao, Jiewen wrote:
> >>> - Does this part require a new branch somewhere in the OVMF SEC code?
> >>>   How do we determine whether the CPU executing SEC is BSP or
> >>>   hot-plugged AP?
> >> [Jiewen] I think this is blocked from hardware perspective, since the 
> >> first instruction.
> >> There are some hardware specific registers can be used to determine if the 
> >> CPU is new added.
> >> I don’t think this must be same as the real hardware.
> >> You are free to invent some registers in device model to be used in OVMF 
> >> hot plug driver.
> > 
> > Yes, this would be a new operation mode for QEMU, that only applies to
> > hot-plugged CPUs.  In this mode the AP doesn't reply to INIT or SMI, in
> > fact it doesn't reply to anything at all.
> >   
> >>> - How do we tell the hot-plugged AP where to start execution? (I.e. that
> >>>   it should execute code at a particular pflash location.)
> >> [Jiewen] Same real mode reset vector at :FFF0.
> > 
> > You do not need a reset vector or INIT/SIPI/SIPI sequence at all in
> > QEMU.  The AP does not start execution at all when it is unplugged, so
> > no cache-as-RAM etc.
> > 
> > We only need to modify QEMU so that hot-plugged APIs do not reply to
> > INIT/SIPI/SMI.
> >   
> >> I don’t think there is problem for real hardware, who always has CAR.
> >> Can QEMU provide some CPU specific space, such as MMIO region?
> > 
> > Why is a CPU-specific region needed if every other processor is in SMM
> > and thus trusted.
> 
> I was going through the steps Jiewen and Yingwen recommended.
> 
> In step (02), the new CPU is expected to set up RAM access. In step
> (03), the new CPU, executing code from flash, is expected to "send board
> message to tell host CPU (GPIO->SCI) -- I am waiting for hot-add
> message." For that action, the new CPU may need a stack (minimally if we
> want to use C function calls).
> 
> Until step (03), there had been no word about any other (= pre-plugged)
> CPUs (more precisely, Jiewen even confirmed "No impact to other
> processors"), so I didn't assume that other CPUs had entered SMM.
> 
> Paolo, I've attempted to read Jiewen's response, and yours, as carefully
> as I can. I'm still very confused. If you have a better understanding,
> could you please write up the 15-step process from the thread starter
> again, with all QEMU customizations applied? Such as, unnecessary steps
> removed, and platform specifics filled in.
> 
> One more comment below:
> 
> >   
> >>>   Does CPU hotplug apply only at the socket level? If the CPU is
> >>>   multi-core, what is responsible for hot-plugging all cores present in
> >>>   the socket?
> > 
> > I can answer this: the SMM handler would interact with the hotplug
> > controller in the same way that ACPI DSDT does normally.  This supports
> > multiple hotplugs already.
> > 
> > Writes to the hotplug controller from outside SMM would be ignored.
> >   
>  (03) New CPU: (Flash) send board message to tell host CPU (GPIO->SCI)
>   -- I am waiting for hot-add message.
> >>>
> >>> Maybe we can simplify this in QEMU by broadcasting an SMI to existent
> >>> processors immediately upon plugging the new CPU.
> > 
> > The QEMU DSDT could be modified (when secure boot is in effect) to OUT
> > to 0xB2 when hotplug happens.  It could write a well-known value to
> > 0xB2, to be read by an SMI handler in edk2.
> 
> (My comment below is general, and may not apply to this particular
> situation. I'm too confused to figure that out myself, sorry!)
> 
> I dislike involving QEMU's generated DSDT in anything SMM (even
> injecting the SMI), because the AML interpreter runs in the OS.
> 
> If a malicious OS kernel is a bit too enlightened about the DSDT, it
> could willfully diverge from the process that we design. If QEMU
> broadcast the SMI internally, the guest OS could not interfere with that.
> 
> If the purpose of the SMI is specifically to force all CPUs into SMM
> (and thereby force them into trusted state), then the OS would be
> explicitly counter-interested in carrying out the AML operations from
> QEMU's DSDT.
it shouldn't matter where from management SMI comes if OS won't be able
to actually trigger SMI with un-trusted content at SMBASE on hotplugged 
(parked) CPU.
The worst that could happen is that new cpu will stay parked.

> I'd be OK with an SMM / SMI involvement in QEMU's DSDT if, by diverging
> from that DSDT, the OS kernel could only mess with its own state, and
> not with the firmware's.
> 
> Thanks
> Laszlo
> 
> > 
> >   
> >>>
> (NOTE: Host CPU can only
> >>> send
>   instruction in SMM mode. -- The register is SMM only)
> >>>
> >>> Sorry, I don't follow -- what register are we talking about here, and
> >>> why is the BSP needed to send anything at all? What "instruction" do you
> >>> have in mind?
> >> [Jiewen] The new

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

Reviewed-by: Michael D Kinney 

Mike

> -Original Message-
> From: devel@edk2.groups.io
> [mailto:devel@edk2.groups.io] On Behalf Of vit9696 via
> Groups.Io
> Sent: Tuesday, August 13, 2019 1:17 AM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] [PATCH v2 1/1] MdePkg: Add
> STATIC_ASSERT macro
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2048
> 
> Provide a macro for compile time assertions.
> Equivalent to C11 static_assert macro from assert.h.
> 
> Signed-off-by: Vitaly Cheptsov 
> ---
>  MdePkg/Include/Base.h | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/MdePkg/Include/Base.h
> b/MdePkg/Include/Base.h index
> ce20b5f01dce..f85f7028a262 100644
> --- a/MdePkg/Include/Base.h
> +++ b/MdePkg/Include/Base.h
> @@ -843,6 +843,17 @@ typedef UINTN  *BASE_LIST;
> #define OFFSET_OF(TYPE, Field) ((UINTN) &(((TYPE *)0)-
> >Field))  #endif
> 
> +///
> +/// Portable definition for compile time assertions.
> +/// Equivalent to C11 static_assert macro from
> assert.h.
> +/// Takes condtion and error message as its arguments.
> +///
> +#ifdef _MSC_EXTENSIONS
> +  #define STATIC_ASSERT static_assert
> +#else
> +  #define STATIC_ASSERT _Static_assert
> +#endif
> +
>  /**
>Macro that returns a pointer to the data structure
> that contains a specified field of
>that data structure.  This is a lightweight method
> to hide information by placing a
> --
> 2.20.1 (Apple Git-117)
> 
> 
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this
> group.
> 
> View/Reply Online (#45503):
> https://edk2.groups.io/g/devel/message/45503
> Mute This Topic: https://groups.io/mt/32850582/1643496
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub
> [michael.d.kin...@intel.com]
> -=-=-=-=-=-=


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

View/Reply Online (#45743): https://edk2.groups.io/g/devel/message/45743
Mute This Topic: https://groups.io/mt/32850582/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

2019-08-15 Thread Paolo Bonzini

On 15/08/19 11:55, Yao, Jiewen wrote:
> Hi Paolo
> I am not sure what do you mean - "You do not need a reset vector ...".
> If so, where is the first instruction of the new CPU in the virtualization 
> environment?
> Please help me understand that at first. Then we can continue the discussion.

The BSP starts running from 0xFFF0.  APs do not start running at all
and just sit waiting for an INIT-SIPI-SIPI sequence.  Please see my
proposal in the reply to Laszlo.

Paolo

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

View/Reply Online (#45741): https://edk2.groups.io/g/devel/message/45741
Mute This Topic: https://groups.io/mt/32852911/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

2019-08-15 Thread Igor Mammedov

On Wed, 14 Aug 2019 16:04:50 +0200
Paolo Bonzini  wrote:

> On 14/08/19 15:20, Yao, Jiewen wrote:
> >> - Does this part require a new branch somewhere in the OVMF SEC code?
> >>   How do we determine whether the CPU executing SEC is BSP or
> >>   hot-plugged AP?
> > [Jiewen] I think this is blocked from hardware perspective, since the first 
> > instruction.
> > There are some hardware specific registers can be used to determine if the 
> > CPU is new added.
> > I don’t think this must be same as the real hardware.
> > You are free to invent some registers in device model to be used in OVMF 
> > hot plug driver.
> 
> Yes, this would be a new operation mode for QEMU, that only applies to
> hot-plugged CPUs.  In this mode the AP doesn't reply to INIT or SMI, in
> fact it doesn't reply to anything at all.
> 
> >> - How do we tell the hot-plugged AP where to start execution? (I.e. that
> >>   it should execute code at a particular pflash location.)
> > [Jiewen] Same real mode reset vector at :FFF0.
> 
> You do not need a reset vector or INIT/SIPI/SIPI sequence at all in
> QEMU.  The AP does not start execution at all when it is unplugged, so
> no cache-as-RAM etc.
> 
> We only need to modify QEMU so that hot-plugged APIs do not reply to
> INIT/SIPI/SMI.
> 
> > I don’t think there is problem for real hardware, who always has CAR.
> > Can QEMU provide some CPU specific space, such as MMIO region?
> 
> Why is a CPU-specific region needed if every other processor is in SMM
> and thus trusted.
> 
> >>   Does CPU hotplug apply only at the socket level? If the CPU is
> >>   multi-core, what is responsible for hot-plugging all cores present in
> >>   the socket?
> 
> I can answer this: the SMM handler would interact with the hotplug
> controller in the same way that ACPI DSDT does normally.  This supports
> multiple hotplugs already.
> 
> Writes to the hotplug controller from outside SMM would be ignored.
> 
> >>> (03) New CPU: (Flash) send board message to tell host CPU (GPIO->SCI)
> >>>  -- I am waiting for hot-add message.
> >>
> >> Maybe we can simplify this in QEMU by broadcasting an SMI to existent
> >> processors immediately upon plugging the new CPU.
> 
> The QEMU DSDT could be modified (when secure boot is in effect) to OUT
> to 0xB2 when hotplug happens.  It could write a well-known value to
> 0xB2, to be read by an SMI handler in edk2.
> 
> 
> >>
> >>>(NOTE: Host CPU can only
> >> send
> >>>  instruction in SMM mode. -- The register is SMM only)
> >>
> >> Sorry, I don't follow -- what register are we talking about here, and
> >> why is the BSP needed to send anything at all? What "instruction" do you
> >> have in mind?
> > [Jiewen] The new CPU does not enable SMI at reset.
> > At some point of time later, the CPU need enable SMI, right?
> > The "instruction" here means, the host CPUs need tell to CPU to enable SMI.
> 
> Right, this would be a write to the CPU hotplug controller
> 
> >>> (04) Host CPU: (OS) get message from board that a new CPU is added.
> >>>  (GPIO -> SCI)
> >>>
> >>> (05) Host CPU: (OS) All CPUs enter SMM (SCI->SWSMI) (NOTE: New CPU
> >>>  will not enter CPU because SMI is disabled)
> >>
> >> I don't understand the OS involvement here. But, again, perhaps QEMU can
> >> force all existent CPUs into SMM immediately upon adding the new CPU.
> > [Jiewen] OS here means the Host CPU running code in OS environment, not in 
> > SMM environment.
> 
> See above.
> 
> >>> (06) Host CPU: (SMM) Save 38000, Update 38000 -- fill simple SMM
> >>>  rebase code.
> >>>
> >>> (07) Host CPU: (SMM) Send message to New CPU to Enable SMI.
> >>
> >> Aha, so this is the SMM-only register you mention in step (03). Is the
> >> register specified in the Intel SDM?
> > [Jiewen] Right. That is the register to let host CPU tell new CPU to enable 
> > SMI.
> > It is platform specific register. Not defined in SDM.
> > You may invent one in device model.
> 
> See above.
> 
> >>> (10) New CPU: (SMM) Response first SMI at 38000, and rebase SMBASE to
> >>>  TSEG.
> >>
> >> What code does the new CPU execute after it completes step (10)? Does it
> >> halt?
> >
> > [Jiewen] The new CPU exits SMM and return to original place - where it is
> > interrupted to enter SMM - running code on the flash.
> 
> So in our case we'd need an INIT/SIPI/SIPI sequence between (06) and (07).

Looking at Q35 code and Seabios SMM relocation as example, if I see it
right QEMU has:
- SMRAM is aliased from DRAM at 0xa
- and TSEG steals from the top of low RAM when configured

Now problem is that default SMBASE at 0x3 isn't backed by anything
in SMRAM address space and default SMI entry falls-through to the same
location in System address space.

The later is not trusted and entry into SMM mode will corrupt area + might
jump to 'random' SMI handler (hence save/restore code in Seabios).

Here is an idea, can we map a memory region at 0x3 in SMRAM address
space with

Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

On 08/14/19 16:04, Paolo Bonzini wrote:
> On 14/08/19 15:20, Yao, Jiewen wrote:
>>> - Does this part require a new branch somewhere in the OVMF SEC code?
>>>   How do we determine whether the CPU executing SEC is BSP or
>>>   hot-plugged AP?
>> [Jiewen] I think this is blocked from hardware perspective, since the first 
>> instruction.
>> There are some hardware specific registers can be used to determine if the 
>> CPU is new added.
>> I don’t think this must be same as the real hardware.
>> You are free to invent some registers in device model to be used in OVMF hot 
>> plug driver.
> 
> Yes, this would be a new operation mode for QEMU, that only applies to
> hot-plugged CPUs.  In this mode the AP doesn't reply to INIT or SMI, in
> fact it doesn't reply to anything at all.
> 
>>> - How do we tell the hot-plugged AP where to start execution? (I.e. that
>>>   it should execute code at a particular pflash location.)
>> [Jiewen] Same real mode reset vector at :FFF0.
> 
> You do not need a reset vector or INIT/SIPI/SIPI sequence at all in
> QEMU.  The AP does not start execution at all when it is unplugged, so
> no cache-as-RAM etc.
> 
> We only need to modify QEMU so that hot-plugged APIs do not reply to
> INIT/SIPI/SMI.
> 
>> I don’t think there is problem for real hardware, who always has CAR.
>> Can QEMU provide some CPU specific space, such as MMIO region?
> 
> Why is a CPU-specific region needed if every other processor is in SMM
> and thus trusted.

I was going through the steps Jiewen and Yingwen recommended.

In step (02), the new CPU is expected to set up RAM access. In step
(03), the new CPU, executing code from flash, is expected to "send board
message to tell host CPU (GPIO->SCI) -- I am waiting for hot-add
message." For that action, the new CPU may need a stack (minimally if we
want to use C function calls).

Until step (03), there had been no word about any other (= pre-plugged)
CPUs (more precisely, Jiewen even confirmed "No impact to other
processors"), so I didn't assume that other CPUs had entered SMM.

Paolo, I've attempted to read Jiewen's response, and yours, as carefully
as I can. I'm still very confused. If you have a better understanding,
could you please write up the 15-step process from the thread starter
again, with all QEMU customizations applied? Such as, unnecessary steps
removed, and platform specifics filled in.

One more comment below:

> 
>>>   Does CPU hotplug apply only at the socket level? If the CPU is
>>>   multi-core, what is responsible for hot-plugging all cores present in
>>>   the socket?
> 
> I can answer this: the SMM handler would interact with the hotplug
> controller in the same way that ACPI DSDT does normally.  This supports
> multiple hotplugs already.
> 
> Writes to the hotplug controller from outside SMM would be ignored.
> 
 (03) New CPU: (Flash) send board message to tell host CPU (GPIO->SCI)
  -- I am waiting for hot-add message.
>>>
>>> Maybe we can simplify this in QEMU by broadcasting an SMI to existent
>>> processors immediately upon plugging the new CPU.
> 
> The QEMU DSDT could be modified (when secure boot is in effect) to OUT
> to 0xB2 when hotplug happens.  It could write a well-known value to
> 0xB2, to be read by an SMI handler in edk2.

(My comment below is general, and may not apply to this particular
situation. I'm too confused to figure that out myself, sorry!)

I dislike involving QEMU's generated DSDT in anything SMM (even
injecting the SMI), because the AML interpreter runs in the OS.

If a malicious OS kernel is a bit too enlightened about the DSDT, it
could willfully diverge from the process that we design. If QEMU
broadcast the SMI internally, the guest OS could not interfere with that.

If the purpose of the SMI is specifically to force all CPUs into SMM
(and thereby force them into trusted state), then the OS would be
explicitly counter-interested in carrying out the AML operations from
QEMU's DSDT.

I'd be OK with an SMM / SMI involvement in QEMU's DSDT if, by diverging
from that DSDT, the OS kernel could only mess with its own state, and
not with the firmware's.

Thanks
Laszlo

> 
> 
>>>
(NOTE: Host CPU can only
>>> send
  instruction in SMM mode. -- The register is SMM only)
>>>
>>> Sorry, I don't follow -- what register are we talking about here, and
>>> why is the BSP needed to send anything at all? What "instruction" do you
>>> have in mind?
>> [Jiewen] The new CPU does not enable SMI at reset.
>> At some point of time later, the CPU need enable SMI, right?
>> The "instruction" here means, the host CPUs need tell to CPU to enable SMI.
> 
> Right, this would be a write to the CPU hotplug controller
> 
 (04) Host CPU: (OS) get message from board that a new CPU is added.
  (GPIO -> SCI)

 (05) Host CPU: (OS) All CPUs enter SMM (SCI->SWSMI) (NOTE: New CPU
  will not enter CPU because SMI is disabled)
>>>
>>> I don't understand the

[edk2-devel] [PATCH v6 4/5] BaseTools: Add GenFds multi-thread support in build cache

From: "Shi, Steven" 

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

Fix the issue that the GenFds multi-thread will build fail
if enable the build cache together.

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Steven Shi 
---
 BaseTools/Source/Python/AutoGen/ModuleAutoGen.py | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py 
b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
index 6db3b47a91..c489c3b9c4 100755
--- a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
@@ -1262,11 +1262,13 @@ class ModuleAutoGen(AutoGen):
 fStringIO.close ()
 fInputfile.close ()
 return OutputName
+
 @cached_property
 def OutputFile(self):
 retVal = set()
 OutputDir = self.OutputDir.replace('\\', '/').strip('/')
 DebugDir = self.DebugDir.replace('\\', '/').strip('/')
+FfsOutputDir = self.FfsOutputDir.replace('\\', '/').rstrip('/')
 for Item in self.CodaTargetList:
 File = Item.Target.Path.replace('\\', 
'/').strip('/').replace(DebugDir, '').replace(OutputDir, '').strip('/')
 retVal.add(File)
@@ -1282,6 +1284,12 @@ class ModuleAutoGen(AutoGen):
 if File.lower().endswith('.pdb'):
 retVal.add(File)
 
+for Root, Dirs, Files in os.walk(FfsOutputDir):
+for File in Files:
+if File.lower().endswith('.ffs') or 
File.lower().endswith('.offset') or File.lower().endswith('.raw') \
+or File.lower().endswith('.raw.txt'):
+retVal.add(File)
+
 return retVal
 
 ## Create AsBuilt INF file the module
@@ -1652,13 +1660,16 @@ class ModuleAutoGen(AutoGen):
 for File in self.OutputFile:
 File = str(File)
 if not os.path.isabs(File):
-File = os.path.join(self.OutputDir, File)
+NewFile = os.path.join(self.OutputDir, File)
+if not os.path.exists(NewFile):
+NewFile = os.path.join(self.FfsOutputDir, File)
+File = NewFile
 if os.path.exists(File):
-sub_dir = os.path.relpath(File, self.OutputDir)
-destination_file = os.path.join(FileDir, sub_dir)
-destination_dir = os.path.dirname(destination_file)
-CreateDirectory(destination_dir)
-CopyFileOnChange(File, destination_dir)
+if File.lower().endswith('.ffs') or 
File.lower().endswith('.offset') or File.lower().endswith('.raw') \
+or File.lower().endswith('.raw.txt'):
+self.CacheCopyFile(FfsDir, self.FfsOutputDir, File)
+else:
+self.CacheCopyFile(FileDir, self.OutputDir, File)
 
 def SaveHashChainFileToCache(self, gDict):
 if not GlobalData.gBinCacheDest:
-- 
2.17.1


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

View/Reply Online (#45738): https://edk2.groups.io/g/devel/message/45738
Mute This Topic: https://groups.io/mt/32887329/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v6 3/5] BaseTools: Change the [Arch][Name] module key in Build cache

From: "Shi, Steven" 

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

Current build cache use the module's [self.Arch][self.Name]
info as the ModuleAutoGen object key in hash list and dictionary.
The [self.Arch][self.Name] is not safe as the module key because
there could be two modules with same module name and arch name in
one platform. E.g. A platform can override a module or library
instance in another different path, the overriding module can has
the same module name and arch name as the original one.
Directly use the ModuleAutoGen obj self as the key, because
the obj __hash__ and __repr__ attributes already contain the
full path and arch name.

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Steven Shi 
---
 BaseTools/Source/Python/AutoGen/GenMake.py |  6 +-
 BaseTools/Source/Python/build/build.py | 48 

 2 files changed, 21 insertions(+), 33 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/GenMake.py 
b/BaseTools/Source/Python/AutoGen/GenMake.py
index c11b423ae1..039c913280 100755
--- a/BaseTools/Source/Python/AutoGen/GenMake.py
+++ b/BaseTools/Source/Python/AutoGen/GenMake.py
@@ -959,16 +959,12 @@ cleanlib:
 # Keep the file to be checked
 headerFileDependencySet.add(aFileName)
 
-# Ensure that gModuleBuildTracking has been initialized per 
architecture
-if self._AutoGenObject.Arch not in GlobalData.gModuleBuildTracking:
-GlobalData.gModuleBuildTracking[self._AutoGenObject.Arch] = dict()
-
 # Check if a module dependency header file is missing from the 
module's MetaFile
 for aFile in headerFileDependencySet:
 if aFile in headerFilesInMetaFileSet:
 continue
 if GlobalData.gUseHashCache:
-
GlobalData.gModuleBuildTracking[self._AutoGenObject.Arch][self._AutoGenObject] 
= 'FAIL_METAFILE'
+GlobalData.gModuleBuildTracking[self._AutoGenObject] = 
'FAIL_METAFILE'
 EdkLogger.warn("build","Module MetaFile [Sources] is missing local 
header!",
 ExtraData = "Local Header: " + aFile + " not found in 
" + self._AutoGenObject.MetaFile.Path
 )
diff --git a/BaseTools/Source/Python/build/build.py 
b/BaseTools/Source/Python/build/build.py
index d7c817b95c..299fa64311 100755
--- a/BaseTools/Source/Python/build/build.py
+++ b/BaseTools/Source/Python/build/build.py
@@ -630,12 +630,11 @@ class BuildTask:
 
 # Set the value used by hash invalidation flow in 
GlobalData.gModuleBuildTracking to 'SUCCESS'
 # If Module or Lib is being tracked, it did not fail header check 
test, and built successfully
-if (self.BuildItem.BuildObject.Arch in GlobalData.gModuleBuildTracking 
and
-   self.BuildItem.BuildObject in 
GlobalData.gModuleBuildTracking[self.BuildItem.BuildObject.Arch] and
-   
GlobalData.gModuleBuildTracking[self.BuildItem.BuildObject.Arch][self.BuildItem.BuildObject]
 != 'FAIL_METAFILE' and
+if (self.BuildItem.BuildObject in GlobalData.gModuleBuildTracking and
+   GlobalData.gModuleBuildTracking[self.BuildItem.BuildObject] != 
'FAIL_METAFILE' and
not BuildTask._ErrorFlag.isSet()
):
-
GlobalData.gModuleBuildTracking[self.BuildItem.BuildObject.Arch][self.BuildItem.BuildObject]
 = 'SUCCESS'
+GlobalData.gModuleBuildTracking[self.BuildItem.BuildObject] = 
'SUCCESS'
 
 # indicate there's a thread is available for another build task
 BuildTask._RunningQueueLock.acquire()
@@ -1171,25 +1170,24 @@ class Build():
 return
 
 # GlobalData.gModuleBuildTracking contains only modules or libs that 
cannot be skipped by hash
-for moduleAutoGenObjArch in GlobalData.gModuleBuildTracking.keys():
-for moduleAutoGenObj in 
GlobalData.gModuleBuildTracking[moduleAutoGenObjArch].keys():
-# Skip invalidating for Successful Module/Lib builds
-if 
GlobalData.gModuleBuildTracking[moduleAutoGenObjArch][moduleAutoGenObj] == 
'SUCCESS':
-continue
+for Ma in GlobalData.gModuleBuildTracking:
+# Skip invalidating for Successful Module/Lib builds
+if GlobalData.gModuleBuildTracking[Ma] == 'SUCCESS':
+continue
 
-# The module failed to build, failed to start building, or 
failed the header check test from this point on
+# The module failed to build, failed to start building, or failed 
the header check test from this point on
 
-# Remove .hash from build
-ModuleHashFile = os.path.join(moduleAutoGenObj.BuildDir, 
moduleAutoGenObj.Name + ".hash")
-if os.path.exists(ModuleHashFile):
-os.remove(ModuleHashFile)
+# Remove .hash from build
+ModuleHashFile = os.path.join(Ma.BuildDir, Ma.Name + ".hash")
+

[edk2-devel] [PATCH v6 5/5] BaseTools: Improve the file saving and copying reliability

From: "Shi, Steven" 

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

The Basetool CopyFileOnChange() and SaveFileOnChange()
functions might raise the IOError occasionally when build
in Windows with multi-process and build cache enabled.
The CopyFileOnChange() and SaveFileOnChange() might be invoked
in multiple sub-processes simultaneously, and this patch adds
global locks to sync these functions invoking which can
harden their reliability.

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Steven Shi 
---
 BaseTools/Source/Python/AutoGen/AutoGenWorker.py |   6 --
 BaseTools/Source/Python/AutoGen/CacheIR.py   |   1 +
 BaseTools/Source/Python/AutoGen/DataPipe.py  |   2 --
 BaseTools/Source/Python/AutoGen/GenC.py  |   0
 BaseTools/Source/Python/AutoGen/ModuleAutoGen.py | 101 
+++--
 BaseTools/Source/Python/Common/GlobalData.py |   2 ++
 BaseTools/Source/Python/Common/Misc.py   |  44 
+---
 BaseTools/Source/Python/build/build.py   |   5 -
 8 files changed, 119 insertions(+), 42 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py 
b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
index 30d2f96fc7..2e68538b1c 100755
--- a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
@@ -133,7 +133,7 @@ class AutoGenManager(threading.Thread):
 def kill(self):
 self.feedback_q.put(None)
 class AutoGenWorkerInProcess(mp.Process):
-def __init__(self,module_queue,data_pipe_file_path,feedback_q,file_lock, 
share_data,log_q,error_event):
+def 
__init__(self,module_queue,data_pipe_file_path,feedback_q,file_lock,cache_lock,share_data,log_q,error_event):
 mp.Process.__init__(self)
 self.module_queue = module_queue
 self.data_pipe_file_path =data_pipe_file_path
@@ -141,6 +141,7 @@ class AutoGenWorkerInProcess(mp.Process):
 self.feedback_q = feedback_q
 self.PlatformMetaFileSet = {}
 self.file_lock = file_lock
+self.cache_lock = cache_lock
 self.share_data = share_data
 self.log_q = log_q
 self.error_event = error_event
@@ -184,9 +185,10 @@ class AutoGenWorkerInProcess(mp.Process):
 GlobalData.gDatabasePath = self.data_pipe.Get("DatabasePath")
 GlobalData.gBinCacheSource = self.data_pipe.Get("BinCacheSource")
 GlobalData.gBinCacheDest = self.data_pipe.Get("BinCacheDest")
-GlobalData.gCacheIR = self.data_pipe.Get("CacheIR")
+GlobalData.gCacheIR = self.share_data
 GlobalData.gEnableGenfdsMultiThread = 
self.data_pipe.Get("EnableGenfdsMultiThread")
 GlobalData.file_lock = self.file_lock
+GlobalData.cache_lock = self.cache_lock
 CommandTarget = self.data_pipe.Get("CommandTarget")
 pcd_from_build_option = []
 for pcd_tuple in self.data_pipe.Get("BuildOptPcd"):
diff --git a/BaseTools/Source/Python/AutoGen/CacheIR.py 
b/BaseTools/Source/Python/AutoGen/CacheIR.py
index 2d9ffe3f0b..715be5273c 100755
--- a/BaseTools/Source/Python/AutoGen/CacheIR.py
+++ b/BaseTools/Source/Python/AutoGen/CacheIR.py
@@ -24,5 +24,6 @@ class ModuleBuildCacheIR():
 self.MakeHashDigest = None
 self.MakeHashHexDigest = None
 self.MakeHashChain = []
+self.CacheCrash = False
 self.PreMakeCacheHit = False
 self.MakeCacheHit = False
diff --git a/BaseTools/Source/Python/AutoGen/DataPipe.py 
b/BaseTools/Source/Python/AutoGen/DataPipe.py
index 84e77c301a..99c27dd50d 100755
--- a/BaseTools/Source/Python/AutoGen/DataPipe.py
+++ b/BaseTools/Source/Python/AutoGen/DataPipe.py
@@ -163,6 +163,4 @@ class MemoryDataPipe(DataPipe):
 
 self.DataContainer = {"BinCacheDest":GlobalData.gBinCacheDest}
 
-self.DataContainer = {"CacheIR":GlobalData.gCacheIR}
-
 self.DataContainer = 
{"EnableGenfdsMultiThread":GlobalData.gEnableGenfdsMultiThread}
\ No newline at end of file
diff --git a/BaseTools/Source/Python/AutoGen/GenC.py 
b/BaseTools/Source/Python/AutoGen/GenC.py
old mode 100644
new mode 100755
diff --git a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py 
b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
index c489c3b9c4..af67244ff8 100755
--- a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
@@ -28,6 +28,7 @@ from Common.caching import cached_class_function
 from AutoGen.ModuleAutoGenHelper import PlatformInfo,WorkSpaceInfo
 from AutoGen.CacheIR import ModuleBuildCacheIR
 import json
+import tempfile
 
 ## Mapping Makefile type
 gMakeTypeMap = {TAB_COMPILER_MSFT:"nmake", "GCC":"gmake"}
@@ -1702,9 +1703,8 @@ class ModuleAutoGen(AutoGen):
 try:
 ModuleHashPairList = [] # tuple list: [tuple(PreMakefileHash, 
MakeHash)]
 if

[edk2-devel] [PATCH v6 1/5] BaseTools: Improve the cache hit in the edk2 build cache

From: "Shi, Steven" 

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

Current cache hash algorithm does not parse and generate
the makefile to get the accurate dependency files for a
module. It instead use the platform and package meta files
to get the module depenedency in a quick but over approximate
way. These meta files are monolithic and involve many redundant
dependency for the module, which cause the module build
cache miss easily.
This patch introduces one more cache checkpoint and a new
hash algorithm besides the current quick one. The new hash
algorithm leverages the module makefile to achieve more
accurate and precise dependency info for a module. When
the build cache miss with the first quick hash, the
Basetool will caculate new one after makefile is generated
and then check again.

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Steven Shi 
---
 BaseTools/Source/Python/AutoGen/AutoGenWorker.py |  21 +
 BaseTools/Source/Python/AutoGen/CacheIR.py   |  28 

 BaseTools/Source/Python/AutoGen/DataPipe.py  |   8 
 BaseTools/Source/Python/AutoGen/GenMake.py   | 227 
---
 BaseTools/Source/Python/AutoGen/ModuleAutoGen.py | 639 
++-
 BaseTools/Source/Python/Common/GlobalData.py |   9 +
 BaseTools/Source/Python/build/build.py   | 129 
+
 7 files changed, 865 insertions(+), 196 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py 
b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
old mode 100644
new mode 100755
index e583828741..a84ed46f2e
--- a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
@@ -182,6 +182,12 @@ class AutoGenWorkerInProcess(mp.Process):
 GlobalData.gDisableIncludePathCheck = False
 GlobalData.gFdfParser = self.data_pipe.Get("FdfParser")
 GlobalData.gDatabasePath = self.data_pipe.Get("DatabasePath")
+GlobalData.gBinCacheSource = self.data_pipe.Get("BinCacheSource")
+GlobalData.gBinCacheDest = self.data_pipe.Get("BinCacheDest")
+GlobalData.gCacheIR = self.data_pipe.Get("CacheIR")
+GlobalData.gEnableGenfdsMultiThread = 
self.data_pipe.Get("EnableGenfdsMultiThread")
+GlobalData.file_lock = self.file_lock
+CommandTarget = self.data_pipe.Get("CommandTarget")
 pcd_from_build_option = []
 for pcd_tuple in self.data_pipe.Get("BuildOptPcd"):
 pcd_id = ".".join((pcd_tuple[0],pcd_tuple[1]))
@@ -193,10 +199,13 @@ class AutoGenWorkerInProcess(mp.Process):
 FfsCmd = self.data_pipe.Get("FfsCommand")
 if FfsCmd is None:
 FfsCmd = {}
+GlobalData.FfsCmd = FfsCmd
 PlatformMetaFile = 
self.GetPlatformMetaFile(self.data_pipe.Get("P_Info").get("ActivePlatform"),
  
self.data_pipe.Get("P_Info").get("WorkspaceDir"))
 libConstPcd = self.data_pipe.Get("LibConstPcd")
 Refes = self.data_pipe.Get("REFS")
+GlobalData.libConstPcd = libConstPcd
+GlobalData.Refes = Refes
 while True:
 if self.module_queue.empty():
 break
@@ -223,8 +232,20 @@ class AutoGenWorkerInProcess(mp.Process):
 Ma.ConstPcd = 
libConstPcd[(Ma.MetaFile.File,Ma.MetaFile.Root,Ma.Arch,Ma.MetaFile.Path)]
 if 
(Ma.MetaFile.File,Ma.MetaFile.Root,Ma.Arch,Ma.MetaFile.Path) in Refes:
 Ma.ReferenceModules = 
Refes[(Ma.MetaFile.File,Ma.MetaFile.Root,Ma.Arch,Ma.MetaFile.Path)]
+if GlobalData.gBinCacheSource and CommandTarget in [None, "", 
"all"]:
+Ma.GenModuleFilesHash(GlobalData.gCacheIR)
+Ma.GenPreMakefileHash(GlobalData.gCacheIR)
+if Ma.CanSkipbyPreMakefileCache(GlobalData.gCacheIR):
+   continue
+

[edk2-devel] [PATCH v6 2/5] BaseTools: Print first cache missing file for build cachle

From: "Shi, Steven" 

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

When a module build cache miss, add support to print the first
cache missing file path and name.

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Steven Shi 
---
 BaseTools/Source/Python/AutoGen/AutoGenWorker.py |  2 ++
 BaseTools/Source/Python/AutoGen/ModuleAutoGen.py | 76 

 2 files changed, 78 insertions(+)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py 
b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
index a84ed46f2e..30d2f96fc7 100755
--- a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
@@ -246,6 +246,8 @@ class AutoGenWorkerInProcess(mp.Process):
 Ma.GenMakeHash(GlobalData.gCacheIR)
 if Ma.CanSkipbyMakeCache(GlobalData.gCacheIR):
 continue
+else:
+Ma.PrintFirstMakeCacheMissFile(GlobalData.gCacheIR)
 except Empty:
 pass
 except:
diff --git a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py 
b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
index 613b0d2fb8..6db3b47a91 100755
--- a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
@@ -2379,6 +2379,82 @@ class ModuleAutoGen(AutoGen):
 print("[cache hit]: checkpoint_Makefile:", self.MetaFile.Path, 
self.Arch)
 return True
 
+## Show the first file name which causes cache miss
+def PrintFirstMakeCacheMissFile(self, gDict):
+if not GlobalData.gBinCacheSource:
+return
+
+# skip binary module
+if self.IsBinaryModule:
+return
+
+if not (self.MetaFile.Path, self.Arch) in gDict:
+return
+
+# Only print cache miss file for the MakeCache not hit module
+if gDict[(self.MetaFile.Path, self.Arch)].MakeCacheHit:
+return
+
+if not gDict[(self.MetaFile.Path, self.Arch)].MakeHashChain:
+EdkLogger.quiet("[cache insight]: MakeHashChain is missing for: 
%s[%s]" % (self.MetaFile.Path, self.Arch))
+return
+
+# Find the cache dir name through the .ModuleHashPair file info
+FileDir = path.join(GlobalData.gBinCacheSource, 
self.PlatformInfo.OutputDir, self.BuildTarget + "_" + self.ToolChain, 
self.Arch, self.SourceDir, self.MetaFile.BaseName)
+
+ModuleHashPairList = [] # tuple list: [tuple(PreMakefileHash, 
MakeHash)]
+ModuleHashPair = path.join(FileDir, self.Name + ".ModuleHashPair")
+if not os.path.exists(ModuleHashPair):
+EdkLogger.quiet("[cache insight]: Cannot find ModuleHashPair file 
for module: %s[%s]" % (self.MetaFile.Path, self.Arch))
+return
+
+try:
+f = open(ModuleHashPair, 'r')
+ModuleHashPairList = json.load(f)
+f.close()
+except:
+EdkLogger.quiet("[cache insight]: Cannot load ModuleHashPair file 
for module: %s[%s]" % (self.MetaFile.Path, self.Arch))
+return
+
+MakeHashSet = set()
+for idx, (PreMakefileHash, MakeHash) in enumerate (ModuleHashPairList):
+TargetHashDir = path.join(FileDir, str(MakeHash))
+if os.path.exists(TargetHashDir):
+MakeHashSet.add(MakeHash)
+if not MakeHashSet:
+EdkLogger.quiet("[cache insight]: Cannot find valid cache dir for 
module: %s[%s]" % (self.MetaFile.Path, self.Arch))
+return
+
+TargetHash = list(MakeHashSet)[0]
+TargetHashDir = path.join(FileDir, str(TargetHash))
+if len(MakeHashSet) > 1 :
+EdkLogger.quiet("[cache insight]: found multiple cache dirs for 
this module, random select dir '%s' to search the first cache miss file: 
%s[%s]" % (TargetHash, self.MetaFile.Path, self.Arch))
+
+ListFile = path.join(TargetHashDir, self.Name + '.MakeHashChain')
+if os.path.exists(ListFile):
+try:
+f = open(ListFile, 'r')
+CachedList = json.load(f)
+f.close()
+except:
+EdkLogger.quiet("[cache insight]: Cannot load MakeHashChain 
file: %s" % ListFile)
+return
+else:
+EdkLogger.quiet("[cache insight]: Cannot find MakeHashChain file: 
%s" % ListFile)
+return
+
+CurrentList = gDict[(self.MetaFile.Path, self.Arch)].MakeHashChain
+for idx, (file, hash) in enumerate (CurrentList):
+(filecached, hashcached) = CachedList[idx]
+if file != filecached:
+EdkLogger.quiet("[cache insight]: first different file in 
%s[%s] is %s, the cached one is %s" % (self.MetaFile.Path, self.Arch, file, 
filecached))
+break
+if hash != hashcached:
+EdkLogger.quiet("[cache insight]: first cache miss file in

[edk2-devel] [PATCH v6 0/5] Build cache enhancement

From: "Shi, Steven" 

This patch set is for the 201908 stable tag

Enhance the edk2 build cache with below patches:
Patch 01/05: Improve the cache hit rate through new cache checkpoint and hash 
algorithm
Patch 02/05: Print more info to explain why a module build cache miss
Patch 03/05: Fix the unsafe [self.Arch][self.Name] key usage in build cache
Patch 04/05  Add the GenFds multi-thread support in build cache
Patch 05/05  Improve the file saving and copying functions reliability in build 
cache


You can directly try this patch set in the branch:
https://github.com/shijunjing/edk2/tree/build_cache_improve_v6_3

V6:
In the patch 5, add error handling to skip hash calculation if find module cache
already crashed

V5:
Fix the method name typo in Misc.py from EdkLogger.quite() to EdkLogger.quiet()

V4:
Change single global lock into two locks, which are cache_lock and file_lock,
for better cache performance and IO reliability in windows

V3:
Add patch 5. To improve the autogen CopyFileOnChange() and SaveFileOnChange()
functions reliability for build cache

V2:
Enhance the SaveHashChainFileToCache() function in ModuleAutoGen.py and
not need to call f.close() in the "with open(xxx) as f:" block. The
with block will close the file automatically

V1:
Initial patch set

Shi, Steven (5):
  BaseTools: Improve the cache hit in the edk2 build cache
  BaseTools: Print first cache missing file for build cachle
  BaseTools: Change the [Arch][Name] module key in Build cache
  BaseTools: Add GenFds multi-thread support in build cache
  BaseTools: Improve the file saving and copying reliability

 .../Source/Python/AutoGen/AutoGenWorker.py|  27 +-
 BaseTools/Source/Python/AutoGen/CacheIR.py|  29 +
 BaseTools/Source/Python/AutoGen/DataPipe.py   |   6 +
 BaseTools/Source/Python/AutoGen/GenC.py   |   0
 BaseTools/Source/Python/AutoGen/GenMake.py| 233 +++---
 .../Source/Python/AutoGen/ModuleAutoGen.py| 791 --
 BaseTools/Source/Python/Common/GlobalData.py  |  11 +
 BaseTools/Source/Python/Common/Misc.py|  44 +-
 BaseTools/Source/Python/build/build.py| 182 ++--
 9 files changed, 1073 insertions(+), 250 deletions(-)
 mode change 100644 => 100755 BaseTools/Source/Python/AutoGen/AutoGenWorker.py
 create mode 100755 BaseTools/Source/Python/AutoGen/CacheIR.py
 mode change 100644 => 100755 BaseTools/Source/Python/AutoGen/DataPipe.py
 mode change 100644 => 100755 BaseTools/Source/Python/AutoGen/GenC.py
 mode change 100644 => 100755 BaseTools/Source/Python/AutoGen/GenMake.py
 mode change 100644 => 100755 BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
 mode change 100644 => 100755 BaseTools/Source/Python/Common/GlobalData.py
 mode change 100644 => 100755 BaseTools/Source/Python/Common/Misc.py
 mode change 100644 => 100755 BaseTools/Source/Python/build/build.py

-- 
2.17.1


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

View/Reply Online (#45734): https://edk2.groups.io/g/devel/message/45734
Mute This Topic: https://groups.io/mt/32887324/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1 11/11] ShellPkg: acpiview: DBG2: Validate global pointers before use

Check if global (in the scope of the DBG2 parser) pointers have been
successfully updated before they are used for further table parsing.

Signed-off-by: Krzysztof Koch 
---

Notes:
v1:
- Test against NULL pointers [Krzysztof]

 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Dbg2/Dbg2Parser.c | 43 

 1 file changed, 43 insertions(+)

diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Dbg2/Dbg2Parser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Dbg2/Dbg2Parser.c
index 
869e700b9beda4886bf7bc5ae4ced3ab9a59efa3..0f730a306a94329a23fbaf54b59f1833b44616ba
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Dbg2/Dbg2Parser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Dbg2/Dbg2Parser.c
@@ -123,6 +123,24 @@ DumpDbgDeviceInfo (
 PARSER_PARAMS (DbgDevInfoParser)
 );
 
+  // Check if the values used to control the parsing logic have been
+  // successfully read.
+  if ((GasCount == NULL)  ||
+  (NameSpaceStringLength == NULL) ||
+  (NameSpaceStringOffset == NULL) ||
+  (OEMDataLength == NULL) ||
+  (OEMDataOffset == NULL) ||
+  (BaseAddrRegOffset == NULL) ||
+  (AddrSizeOffset == NULL)) {
+IncrementErrorCount ();
+Print (
+  L"ERROR: Insufficient Debug Device Information Structure length. " \
+L"Length = %d.\n",
+  Length
+  );
+return;
+  }
+
   // GAS
   Index = 0;
   Offset = *BaseAddrRegOffset;
@@ -224,6 +242,18 @@ ParseAcpiDbg2 (
  PARSER_PARAMS (Dbg2Parser)
  );
 
+  // Check if the values used to control the parsing logic have been
+  // successfully read.
+  if ((OffsetDbgDeviceInfo == NULL) ||
+  (NumberDbgDeviceInfo == NULL)) {
+IncrementErrorCount ();
+Print (
+  L"ERROR: Insufficient table length. AcpiTableLength = %d\n",
+  AcpiTableLength
+  );
+return;
+  }
+
   Offset = *OffsetDbgDeviceInfo;
   Index = 0;
 
@@ -239,6 +269,19 @@ ParseAcpiDbg2 (
   PARSER_PARAMS (DbgDevInfoHeaderParser)
   );
 
+// Check if the values used to control the parsing logic have been
+// successfully read.
+if (DbgDevInfoLen == NULL) {
+  IncrementErrorCount ();
+  Print (
+L"ERROR: Insufficient remaining table buffer length to read the " \
+  L"Debug Device Information structure's 'Length' field. " \
+  L"RemainingTableBufferLength = %d.\n",
+AcpiTableLength - Offset
+);
+  return;
+}
+
 // Make sure the Debug Device Information structure lies inside the table.
 if ((Offset + *DbgDevInfoLen) > AcpiTableLength) {
   IncrementErrorCount ();
--
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'



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

View/Reply Online (#45733): https://edk2.groups.io/g/devel/message/45733
Mute This Topic: https://groups.io/mt/32886586/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1 10/11] ShellPkg: acpiview: GTDT: Validate global pointers before use

Check if global (in the scope of the GTDT parser) pointers have been
successfully updated before they are used for further table parsing.

Signed-off-by: Krzysztof Koch 
---

Notes:
v1:
- Test against NULL pointers [Krzysztof]

 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Gtdt/GtdtParser.c | 37 

 1 file changed, 37 insertions(+)

diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Gtdt/GtdtParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Gtdt/GtdtParser.c
index 
57174e14c80072f12b90e1996ebe8f0002d0c404..699a55b549ec3fa61bbd156898821055dc019199
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Gtdt/GtdtParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Gtdt/GtdtParser.c
@@ -189,6 +189,18 @@ DumpGTBlock (
 PARSER_PARAMS (GtBlockParser)
 );
 
+  // Check if the values used to control the parsing logic have been
+  // successfully read.
+  if ((GtBlockTimerCount == NULL) ||
+  (GtBlockTimerOffset == NULL)) {
+IncrementErrorCount ();
+Print (
+  L"ERROR: Insufficient GT Block Structure length. Length = %d.\n",
+  Length
+  );
+return;
+  }
+
   Offset = *GtBlockTimerOffset;
   Index = 0;
 
@@ -272,6 +284,18 @@ ParseAcpiGtdt (
 PARSER_PARAMS (GtdtParser)
 );
 
+  // Check if the values used to control the parsing logic have been
+  // successfully read.
+  if ((GtdtPlatformTimerCount == NULL) ||
+  (GtdtPlatformTimerOffset == NULL)) {
+IncrementErrorCount ();
+Print (
+  L"ERROR: Insufficient table length. AcpiTableLength = %d.\n",
+  AcpiTableLength
+  );
+return;
+  }
+
   TimerPtr = Ptr + *GtdtPlatformTimerOffset;
   Offset = *GtdtPlatformTimerOffset;
   Index = 0;
@@ -290,6 +314,19 @@ ParseAcpiGtdt (
   PARSER_PARAMS (GtPlatformTimerHeaderParser)
   );
 
+// Check if the values used to control the parsing logic have been
+// successfully read.
+if ((PlatformTimerType == NULL) ||
+(PlatformTimerLength == NULL)) {
+  IncrementErrorCount ();
+  Print (
+L"ERROR: Insufficient remaining table buffer length to read the " \
+  L"Platform Timer Structure header. Length = %d.\n",
+AcpiTableLength - Offset
+);
+  return;
+}
+
 // Make sure the Platform Timer is inside the table.
 if ((Offset + *PlatformTimerLength) > AcpiTableLength) {
   IncrementErrorCount ();
--
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'



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

View/Reply Online (#45731): https://edk2.groups.io/g/devel/message/45731
Mute This Topic: https://groups.io/mt/32886582/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1 07/11] ShellPkg: acpiview: MADT: Validate global pointers before use

Check if the MadtInterruptControllerType and
MadtInterruptControllerLength pointers have been successfully updated
before they are used for further table parsing.

Signed-off-by: Krzysztof Koch 
---

Notes:
v1:
- Test against NULL pointers [Krzysztof]

 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtParser.c | 13 
+
 1 file changed, 13 insertions(+)

diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtParser.c
index 
90bdafea1970db522e8ed96de7c6e986cdaca5ba..438905cb24f58b8b82e8fe61280e72f765d578d8
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtParser.c
@@ -260,6 +260,19 @@ ParseAcpiMadt (
   PARSER_PARAMS (MadtInterruptControllerHeaderParser)
   );
 
+// Check if the values used to control the parsing logic have been
+// successfully read.
+if ((MadtInterruptControllerType == NULL) ||
+(MadtInterruptControllerLength == NULL)) {
+  IncrementErrorCount ();
+  Print (
+L"ERROR: Insufficient remaining table buffer length to read the " \
+  L"Interrupt Controller Structure header. Length = %d.\n",
+AcpiTableLength - Offset
+);
+  return;
+}
+
 // Make sure forward progress is made.
 if (*MadtInterruptControllerLength < 2) {
   IncrementErrorCount ();
--
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'



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

View/Reply Online (#45732): https://edk2.groups.io/g/devel/message/45732
Mute This Topic: https://groups.io/mt/32886584/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1 09/11] ShellPkg: acpiview: IORT: Validate global pointers before use

Check if global (in the scope of the IORT parser) pointers have been
successfully updated before they are used for further table parsing.

Signed-off-by: Krzysztof Koch 
---

Notes:
v1:
- Test against NULL pointers [Krzysztof]

 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Iort/IortParser.c | 52 

 1 file changed, 52 insertions(+)

diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Iort/IortParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Iort/IortParser.c
index 
f1cdb9ac01d848f22ab588d8f824886387c5983d..c43ed4ee5fdd8de409052d57c13a27811c75c7d0
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Iort/IortParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Iort/IortParser.c
@@ -317,6 +317,20 @@ DumpIortNodeSmmuV1V2 (
 PARSER_PARAMS (IortNodeSmmuV1V2Parser)
 );
 
+  // Check if the values used to control the parsing logic have been
+  // successfully read.
+  if ((InterruptContextCount == NULL)   ||
+  (InterruptContextOffset == NULL)  ||
+  (PmuInterruptCount == NULL)   ||
+  (PmuInterruptOffset == NULL)) {
+IncrementErrorCount ();
+Print (
+  L"ERROR: Insufficient SMMUv1/2 node length. Length = %d\n",
+  Length
+  );
+return;
+  }
+
   Offset = *InterruptContextOffset;
   Index = 0;
 
@@ -428,6 +442,17 @@ DumpIortNodeIts (
 PARSER_PARAMS (IortNodeItsParser)
 );
 
+  // Check if the values used to control the parsing logic have been
+  // successfully read.
+  if (ItsCount == NULL) {
+IncrementErrorCount ();
+Print (
+  L"ERROR: Insufficient ITS group length. Length = %d.\n",
+  Length
+  );
+return;
+  }
+
   Index = 0;
 
   while ((Index < *ItsCount) &&
@@ -612,6 +637,18 @@ ParseAcpiIort (
 PARSER_PARAMS (IortParser)
 );
 
+  // Check if the values used to control the parsing logic have been
+  // successfully read.
+  if ((IortNodeCount == NULL) ||
+  (IortNodeOffset == NULL)) {
+IncrementErrorCount ();
+Print (
+  L"ERROR: Insufficient table length. AcpiTableLength = %d.\n",
+  AcpiTableLength
+  );
+return;
+  }
+
   Offset = *IortNodeOffset;
   NodePtr = Ptr + Offset;
   Index = 0;
@@ -630,6 +667,21 @@ ParseAcpiIort (
   PARSER_PARAMS (IortNodeHeaderParser)
   );
 
+// Check if the values used to control the parsing logic have been
+// successfully read.
+if ((IortNodeType == NULL)||
+(IortNodeLength == NULL)  ||
+(IortIdMappingCount == NULL)  ||
+(IortIdMappingOffset == NULL)) {
+  IncrementErrorCount ();
+  Print (
+L"ERROR: Insufficient remaining table buffer length to read the " \
+  L"IORT node header. Length = %d.\n",
+AcpiTableLength - Offset
+);
+  return;
+}
+
 // Make sure the IORT Node is inside the table
 if ((Offset + (*IortNodeLength)) > AcpiTableLength) {
   IncrementErrorCount ();
--
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'



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

View/Reply Online (#45730): https://edk2.groups.io/g/devel/message/45730
Mute This Topic: https://groups.io/mt/32886581/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1 08/11] ShellPkg: acpiview: PPTT: Validate global pointers before use

Check if the NumberOfPrivateResources, ProcessorTopologyStructureType
and ProcessorTopologyStructureLength pointers have been successfully
updated before they are used for further table parsing.

Signed-off-by: Krzysztof Koch 
---

Notes:
v1:
- Test against NULL pointers [Krzysztof]

 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pptt/PpttParser.c | 25 

 1 file changed, 25 insertions(+)

diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pptt/PpttParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pptt/PpttParser.c
index 
6254b9913fffb429fc54bb1301bf3e4b2e5bf161..675ba75f02b367cd5ad9f2ac23c30ed0ab58f286
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pptt/PpttParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pptt/PpttParser.c
@@ -264,6 +264,17 @@ DumpProcessorHierarchyNodeStructure (
  PARSER_PARAMS (ProcessorHierarchyNodeStructureParser)
  );
 
+  // Check if the values used to control the parsing logic have been
+  // successfully read.
+  if (NumberOfPrivateResources == NULL) {
+IncrementErrorCount ();
+Print (
+  L"ERROR: Insufficient Processor Hierarchy Node length. Length = %d.\n",
+  Length
+  );
+return;
+  }
+
   // Make sure the Private Resource array lies inside this structure
   if (Offset + (*NumberOfPrivateResources * sizeof (UINT32)) > Length) {
 IncrementErrorCount ();
@@ -387,6 +398,7 @@ ParseAcpiPptt (
  AcpiTableLength,
  PARSER_PARAMS (PpttParser)
  );
+
   ProcessorTopologyStructurePtr = Ptr + Offset;
 
   while (Offset < AcpiTableLength) {
@@ -400,6 +412,19 @@ ParseAcpiPptt (
   PARSER_PARAMS (ProcessorTopologyStructureHeaderParser)
   );
 
+// Check if the values used to control the parsing logic have been
+// successfully read.
+if ((ProcessorTopologyStructureType == NULL) ||
+(ProcessorTopologyStructureLength == NULL)) {
+  IncrementErrorCount ();
+  Print (
+L"ERROR: Insufficient remaining table buffer length to read the " \
+  L"processor topology structure header. Length = %d.\n",
+AcpiTableLength - Offset
+);
+  return;
+}
+
 // Make sure the PPTT structure lies inside the table
 if ((Offset + *ProcessorTopologyStructureLength) > AcpiTableLength) {
   IncrementErrorCount ();
--
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'



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

View/Reply Online (#45729): https://edk2.groups.io/g/devel/message/45729
Mute This Topic: https://groups.io/mt/32886580/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1 05/11] ShellPkg: acpiview: SLIT: Validate System Locality count

1. Check if the 'Number of System Localities' provided can be
represented in the SLIT table. The table 'Length' field is a 32-bit
value while the 'Number of System Localities' field is 64-bit long.

2. Check if the SLIT matrix fits in the table buffer. If N is the SLIT
locality count, then the matrix used to represent the localities is
N*N bytes long. The ACPI table length must be big enough to fit the
matrix.

3. Remove (now) redundant 64x64 bit multiplication.

Signed-off-by: Krzysztof Koch 
---

Notes:
v1:
- Validate the 'Number of System Localities' Field [Krzysztof]
- Remove redundant 64x64 bit multiplication [Krzysztof]

 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser.c | 47 
+---
 1 file changed, 42 insertions(+), 5 deletions(-)

diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser.c
index 
17e2166a09d8615b714e0c51d4d93d293fcdf601..e4625ee8b13907893a9b6990ecb956baf91cc3b9
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser.c
@@ -30,7 +30,7 @@ STATIC CONST ACPI_PARSER SlitParser[] = {
 /**
   Macro to get the value of a System Locality
 **/
-#define SLIT_ELEMENT(Ptr, i, j) *(Ptr + (MultU64x64 (i, LocalityCount)) + j)
+#define SLIT_ELEMENT(Ptr, i, j) *(Ptr + (i * LocalityCount) + j)
 
 /**
   This function parses the ACPI SLIT table.
@@ -57,9 +57,9 @@ ParseAcpiSlit (
   )
 {
   UINT32 Offset;
-  UINT64 Count;
-  UINT64 Index;
-  UINT64 LocalityCount;
+  UINT32 Count;
+  UINT32 Index;
+  UINT32 LocalityCount;
   UINT8* LocalityPtr;
   CHAR16 Buffer[80];  // Used for AsciiName param of ParseAcpi
 
@@ -87,8 +87,45 @@ ParseAcpiSlit (
 return;
   }
 
+  /*
+Despite the 'Number of System Localities' being a 64-bit field in SLIT,
+the maximum number of localities that can be represented in SLIT is limited
+by the 'Length' field of the ACPI table.
+
+Since the ACPI table length field is 32-bit wide. The maximum number of
+localities that can be represented in SLIT can be calculated as:
+
+MaxLocality = sqrt (MAX_UINT32 - sizeof 
(EFI_ACPI_6_3_SYSTEM_LOCALITY_DISTANCE_INFORMATION_TABLE_HEADER))
+= 65535
+= MAX_UINT16
+  */
+  if (*SlitSystemLocalityCount > MAX_UINT16) {
+IncrementErrorCount ();
+Print (
+  L"ERROR: The Number of System Localities provided can't be represented " 
\
+L"in the SLIT table. SlitSystemLocalityCount = %ld. " \
+L"MaxLocalityCountAllowed = %d.\n",
+  *SlitSystemLocalityCount,
+  MAX_UINT16
+  );
+return;
+  }
+
+  LocalityCount = (UINT32)*SlitSystemLocalityCount;
+
+  // Make sure system localities fit in the table buffer provided
+  if (Offset + (LocalityCount * LocalityCount) > AcpiTableLength) {
+IncrementErrorCount ();
+Print (
+  L"ERROR: Invalid Number of System Localities. " \
+L"SlitSystemLocalityCount = %ld. AcpiTableLength = %d.\n",
+  *SlitSystemLocalityCount,
+  AcpiTableLength
+  );
+return;
+  }
+
   LocalityPtr = Ptr + Offset;
-  LocalityCount = *SlitSystemLocalityCount;
 
   // We only print the Localities if the count is less than 16
   // If the locality count is more than 16 then refer to the
--
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'



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

View/Reply Online (#45728): https://edk2.groups.io/g/devel/message/45728
Mute This Topic: https://groups.io/mt/32886579/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1 01/11] ShellPkg: acpiview: Set ItemPtr to NULL for unprocessed table fields

For fields outside the buffer length provided, reset any pointers,
which were supposed to be updated by a ParseAcpi() function call to
NULL. This way one can easily validate if a pointer was successfully
updated.

The ParseAcpi() function parses the given ACPI table buffer by a
number of bytes which is a minimum of the buffer length and the length
described by ACPI_PARSER array. If the buffer length is shorter than
the array describing how to process the ACPI structure, then it is
possible that the ItemPtr inside ACPI_PARSER may not get updated or
initialized. This can lead to an error if the value pointed to by
ItemPtr is later used to control the parsing logic.

A typical example would be a 'number of elements' field in an ACPI
structure header which defines how many substructures of a given type
are present in the structure body. If the 'number of elements' field
is not parsed, this could result in a dangling pointer which could
cause a problem later.

Signed-off-by: Krzysztof Koch 
---

Notes:
v1:
- Set ItemPtr to NULL for unprocessed table fields [Krzysztof]

 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
index 
2d6ff80e299eebe7853061d3db89332197c0dc0e..1ede12859721db75d17fd0bfc14dc9e9c0d573aa
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
@@ -502,8 +502,15 @@ ParseAcpi (
 
   for (Index = 0; Index < ParserItems; Index++) {
 if ((Offset + Parser[Index].Length) > Length) {
+
+  // For fields outside the buffer length provided, reset any pointers
+  // which were supposed to be updated by this function call
+  if (Parser[Index].ItemPtr != NULL) {
+*Parser[Index].ItemPtr = NULL;
+  }
+
   // We don't parse past the end of the max length specified
-  break;
+  continue;
 }
 
 if (GetConsistencyChecking () &&
--
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'



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

View/Reply Online (#45722): https://edk2.groups.io/g/devel/message/45722
Mute This Topic: https://groups.io/mt/32886563/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1 02/11] ShellPkg: acpiview: RSDP: Validate global pointer before use

Check if XsdtAddress pointer has been successfully updated before it
is used for further table parsing.

Signed-off-by: Krzysztof Koch 
---

Notes:
v1:
- Test against NULL pointers [Krzysztof]

 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Rsdp/RsdpParser.c | 12 

 1 file changed, 12 insertions(+)

diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Rsdp/RsdpParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Rsdp/RsdpParser.c
index 
5a5c4b50c12e6eb0aa0efb1765df7e123f614da3..f4a8732a7db7c437031f2a3d2f266b80eff17b4b
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Rsdp/RsdpParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Rsdp/RsdpParser.c
@@ -138,6 +138,18 @@ ParseAcpiRsdp (
 PARSER_PARAMS (RsdpParser)
 );
 
+  // Check if the values used to control the parsing logic have been
+  // successfully read.
+  if (XsdtAddress == NULL) {
+IncrementErrorCount ();
+Print (
+  L"ERROR: Insufficient table length. AcpiTableLength = %d." \
+L"RSDP parsing aborted.\n",
+  AcpiTableLength
+  );
+return;
+  }
+
   // This code currently supports parsing of XSDT table only
   // and does not parse the RSDT table. Platforms provide the
   // RSDT to enable compatibility with ACPI 1.0 operating systems.
--
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'



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

View/Reply Online (#45726): https://edk2.groups.io/g/devel/message/45726
Mute This Topic: https://groups.io/mt/32886568/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1 03/11] ShellPkg: acpiview: FADT: Validate global pointer before use

Check if global pointers have been successfully updated before they
are used for further table parsing.

Signed-off-by: Krzysztof Koch 
---

Notes:
v1:
- Test against NULL pointers [Krzysztof]

 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.c | 14 
++
 1 file changed, 14 insertions(+)

diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.c
index 
e40c9ef8ee4b3285faf8c6edf3cb6236ee367397..e218e45926abced1096e75441e22108db7a3a811
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.c
@@ -203,6 +203,20 @@ ParseAcpiFadt (
 PARSER_PARAMS (FadtParser)
 );
 
+  // Check if the values used to control the parsing logic have been
+  // successfully read.
+  if ((DsdtAddress == NULL)   ||
+  (FadtMinorRevision == NULL) ||
+  (X_DsdtAddress == NULL)) {
+IncrementErrorCount ();
+Print (
+  L"ERROR: Insufficient table length. AcpiTableLength = %d. " \
+L"FADT parsing aborted.\n",
+  AcpiTableLength
+  );
+return;
+  }
+
   if (Trace) {
 Print (L"\nSummary:\n");
 PrintFieldName (2, L"FADT Version");
--
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'



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

View/Reply Online (#45724): https://edk2.groups.io/g/devel/message/45724
Mute This Topic: https://groups.io/mt/32886566/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms: PATCH 1/1] Platforms/RPi3: Add multiple embedded Device Tree selection

2019-08-15 Thread Pete Batard


Hi Leif,

On 2019.08.15 13:13, Leif Lindholm wrote:

On Mon, Aug 12, 2019 at 02:06:34PM +0100, Pete Batard wrote:

The Raspberry Pi 3 platform currently has 2 different models, each with a
different Device Tree. Rather than embedding a single one, and requiring
users to manually provide the other, this patch ensures that we now embed
both and and serve the relevant one at runtime.

Signed-off-by: Pete Batard 


Changeset looks very useful. Some style issues. And one question.

First the question: is there no practical size restriction on the
firmware image? This is a 24k increase in image size.


I thought about that too, but we still have plenty of unused payload to 
go by, which is why I've been adding stuff like the EBC driver, and now 
this, without worrying too much about the extra space taken.


For one, in the current 2 MB firmware image, we're still barely 
scratching 1.2 MB of effective data (for RELEASE. For DEBUG that's ~1.5 
MB), so we have plenty of space to add additional Device Trees, logos, 
and similar non critical data. As a matter of fact, I was almost tempted 
to have this patchset also include the Raspberry Pi 4 Device Tree, so 
that we would just have all of the DT's we might ever be interested in 
available at runtime, regardless of whether they are applicable or not 
(as this would simplify FdtDxe reuse a well GUID handling).


Also, I would expect the build process to complain loudly if we go over 
capacity.


Finally, I'm pretty sure we could relatively easily switch to a 4 MB or 
8 MB firmware image, if we start to run out of space with the current 2 
MB, since, from what I am aware of, the SoC is designed to be able to 
boot large Linux kernels directly and doesn't enforce a hardcoded limit 
on our FV size.


In other words, even if we start to regularly add a tens of KB here and 
there, it's going to take some time before we have to start to worry 
about going over capacity...



---
  Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c   | 57 
  Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.inf |  3 +-
  Platform/RaspberryPi/RPi3/RPi3.dec  |  3 +-
  Platform/RaspberryPi/RPi3/RPi3.fdf  |  6 ++-
  4 files changed, 55 insertions(+), 14 deletions(-)

diff --git a/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c 
b/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c
index c84e5b2767e2..7c0ab75e7cb1 100644
--- a/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c
+++ b/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c
@@ -20,6 +20,11 @@
  
  #include 
  
+CONST  EFI_GUID *mFdtGuid[] = {

+   ,
+   ,
+};
+
  STATIC VOID *mFdtImage;
  
  STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL   *mFwProtocol;

@@ -368,7 +373,9 @@ FdtDxeInitialize (
EFI_STATUS Status;
VOID   *FdtImage;
UINTN  FdtSize;
+  UINTN  FdtIndex;
INT32  Retval;
+  UINT32 BoardRevision;
BOOLEANInternal;
  
Status = gBS->LocateProtocol (, NULL,

@@ -383,13 +390,41 @@ FdtDxeInitialize (
   * Have FDT passed via config.txt.
   */
  FdtSize = fdt_totalsize (FdtImage);


This

-DEBUG ((DEBUG_INFO, "DTB passed via config.txt of 0x%lx bytes\n", 
FdtSize));
+DEBUG ((DEBUG_INFO, "Device Tree passed via config.txt (0x%lx bytes)\n", 
FdtSize));

looks unrelated to the changeset.


  Status = EFI_SUCCESS;
} else {
+/*
+ * Use one of the embedded FDT's.
+ */
  Internal = TRUE;


This DEBUG changes bit

-DEBUG ((DEBUG_INFO, "No/bad FDT at %p (%a), trying internal DTB...\n",
-  FdtImage, fdt_strerror (Retval)));
-Status = GetSectionFromAnyFv (, EFI_SECTION_RAW, 0,
+DEBUG ((DEBUG_INFO, "No/Bad Device Tree found at address 0x%p (%a), "
+  "looking up internal one...\n", FdtImage, fdt_strerror (Retval)));

to here looks completely unrelated to the changeset.
Which garbles the diff somewhat with regards to the functional line in
the middle..


I mentioned in the cover letter that changes were also added to 
harmonize the debug output to avoid acronyms and provide human readable 
error codes. But you're right, at the very least, these changes should 
have been mentioned in the commit message for actual patch itself, and 
are probably better off on their own.


I'll break them out as a separate patch as requested.

Regards,

/Pete




+/*
+ * Query the board revision to differentiate between models.
+ */
+Status = mFwProtocol->GetModelRevision ();
+if (EFI_ERROR (Status)) {
+  FdtIndex = 0;
+  DEBUG ((DEBUG_ERROR, "Failed to get board type: %r\n", Status));
+} else {
+  // 
www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
+  switch ((BoardRevision >> 4) & 0xFF) {
+  case 0x08:  // Raspberry 3 Model B
+DEBUG ((DEBUG_INFO, "Using RPi3 Model B

[edk2-devel] [PATCH v1 00/11] Test against invalid pointers in acpiview

Prevent the use of invalid pointers when parsing ACPI tables in the UEFI
shell acpiview tool.

The parsing of ACPI tables is often controlled with the values read
earlier from the same table. For example, the 'Offset' or 'Count' fields
found in a structure are later used to parse the substructures. If such
fields lie outside the structure's buffer length provided, then there
is a possibility for a wild or dangling pointer.

Currently, if the ParseAcpi() function terminates early because the end
of the input table data buffer has been reached, then the pointers
which were supposed to be updated by this function are left untouched.
This is a security issue as the values pointed to by these pointers are
later used for flow control.

This patch series aims to solve this security issue by explicitly
initializing any pointers lying outside the input ACPI data buffer to
NULL and testing for NULL whenever these pointers are dereferenced.

Changes can be seet at: 
https://github.com/KrzysztofKoch1/edk2/tree/612_add_pointer_validation_v1

Krzysztof Koch (11):
  ShellPkg: acpiview: Set ItemPtr to NULL for unprocessed table fields
  ShellPkg: acpiview: RSDP: Validate global pointer before use
  ShellPkg: acpiview: FADT: Validate global pointer before use
  ShellPkg: acpiview: SLIT: Validate global pointer before use
  ShellPkg: acpiview: SLIT: Validate System Locality count
  ShellPkg: acpiview: SRAT: Validate global pointers before use
  ShellPkg: acpiview: MADT: Validate global pointers before use
  ShellPkg: acpiview: PPTT: Validate global pointers before use
  ShellPkg: acpiview: IORT: Validate global pointers before use
  ShellPkg: acpiview: GTDT: Validate global pointers before use
  ShellPkg: acpiview: DBG2: Validate global pointers before use

 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c  |  9 ++-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Dbg2/Dbg2Parser.c | 43 
++
 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.c | 14 
+
 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Gtdt/GtdtParser.c | 37 

 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Iort/IortParser.c | 52 
+
 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtParser.c | 13 
+
 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pptt/PpttParser.c | 25 

 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Rsdp/RsdpParser.c | 12 

 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser.c | 61 
++--
 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c | 13 
+
 10 files changed, 272 insertions(+), 7 deletions(-)

--
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'



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

View/Reply Online (#45723): https://edk2.groups.io/g/devel/message/45723
Mute This Topic: https://groups.io/mt/32886564/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1 04/11] ShellPkg: acpiview: SLIT: Validate global pointer before use

Check if SlitSystemLocalityCount pointer has been successfully updated
before it is used for further table parsing.

Signed-off-by: Krzysztof Koch 
---

Notes:
v1:
- Test against NULL pointers [Krzysztof]

 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser.c | 16 
++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser.c
index 
ca2808db526b1bbb79aeb21ccfc0ae6c79b2dfd8..17e2166a09d8615b714e0c51d4d93d293fcdf601
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser.c
@@ -1,7 +1,7 @@
 /** @file
   SLIT table parser
 
-  Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
+  Copyright (c) 2016 - 2019, ARM Limited. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
   @par Reference(s):
@@ -75,9 +75,21 @@ ParseAcpiSlit (
  AcpiTableLength,
  PARSER_PARAMS (SlitParser)
  );
+
+  // Check if the values used to control the parsing logic have been
+  // successfully read.
+  if (SlitSystemLocalityCount == NULL) {
+IncrementErrorCount ();
+Print (
+  L"ERROR: Insufficient table length. AcpiTableLength = %d.\n",
+  AcpiTableLength
+  );
+return;
+  }
+
   LocalityPtr = Ptr + Offset;
-
   LocalityCount = *SlitSystemLocalityCount;
+
   // We only print the Localities if the count is less than 16
   // If the locality count is more than 16 then refer to the
   // raw data dump.
--
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'



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

View/Reply Online (#45721): https://edk2.groups.io/g/devel/message/45721
Mute This Topic: https://groups.io/mt/32886562/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1 06/11] ShellPkg: acpiview: SRAT: Validate global pointers before use

Check if SratRAType and SratRALength pointers have been successfully
updated before they are used for further table parsing.

Signed-off-by: Krzysztof Koch 
---

Notes:
v1:
- Test against NULL pointers [Krzysztof]

 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c | 13 
+
 1 file changed, 13 insertions(+)

diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c
index 
a8aa420487bb6bf29fc38221d0b221573c64b8b3..e09a7db8f5c92b44c96b6c37a44a39693352b442
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c
@@ -219,6 +219,19 @@ ParseAcpiSrat (
   PARSER_PARAMS (SratResourceAllocationParser)
   );
 
+// Check if the values used to control the parsing logic have been
+// successfully read.
+if ((SratRAType == NULL) ||
+(SratRALength == NULL)) {
+  IncrementErrorCount ();
+  Print (
+L"ERROR: Insufficient remaining table buffer length to read the " \
+  L"Static Resource Allocation structure header. Length = %d.\n",
+AcpiTableLength - Offset
+);
+  return;
+}
+
 // Make sure the SRAT structure lies inside the table
 if ((Offset + *SratRALength) > AcpiTableLength) {
   IncrementErrorCount ();
--
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'



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

View/Reply Online (#45725): https://edk2.groups.io/g/devel/message/45725
Mute This Topic: https://groups.io/mt/32886567/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 0/1] Added GOP driver for DisplayLink-based Universal USB Docks to edk2-platforms

2019-08-15 Thread Andy Hayes

On Thu, Aug 15, 2019 at 10:15:48AM +, Andy Hayes wrote:
> Thanks very much for the very quick feedback from both of you - I
> really appreciate it. I'll fix the issues that you pointed out and
> re-submit the patch.

Thanks!

> I've been testing the build with VisualStudio 2015 and GCC 7.3. (VS
> for X64, GCC5 for IA32/X64/ARM/AARCH64) I had a bit of trouble
> getting the clang build to work but I'll try it again to make sure
> that I don't introduce any other errors.

Yeah, the compilers (especially GCC/clang) are getting pickier
My baseline today is Clang 7 and GCC 8.3. Testing with Clang 8 and
GCC9 is definitely becoming relevant, but could in most cases replace
testing with GCC 8.

> The way that the C structures are initialized - what other compilers
> need to be tested to make sure there is sufficient support for this
> syntax? (I believe the syntax is a C99 thing).

Well, in this case, the "problem" is that the compiler generates calls
to "known to be there" libc helper functions. Which aren't for us.
On the IA32/X64 side, these rules have been put in place.
On the ARM/AARCH64 side, we have ArmPkg/Library/CompilerIntrinsicsLib,
which on (32-bit) ARM was a fundamental necessity for other reasons.

So testing with a particular compiler version may or may not trigger
the issue, and seemingly unrelated future code changes may nudge the
compiler into doing something else instead. So it's not exactly
foolproof.

> I know that there is a big list in tools.def, but realistically
> which ones do you have to be sure work correctly, to cover the
> majority of users? It's easy enough to cover all of the versions of
> GCC and CLANG for, say, X86/X64/ARM/AARCH64, but how far back with
> Visual Studio versions do I need to go?

I don't expect everyone to test everything - only to test more than
one option and fix things as reported. Unless it's core code.

It *would* be perfetcly valid (though less than ideal) to have
external device drivers not supported by the full set of toolchains.
Of course, making your code build with multiple toolchains frequently
flush out latent bugs, so...
In this case, the changes were all pretty trivial, so I would prefer
to see them implemented.

We have some cleanup work to do on the cross-compilation aspect in
general for !VS. While it can be nudged into working, it works
differently on ARM and X64.

Personally, I worry mostly about compatibility with the toolchain
versions included in the latest stable version of Debian (since that's
the distribution people tend to complain about lagging behind :). From
Debian Buster, we finally have cross-compilation symmetry
AARCH64<->X64.

For something like UDK, we *should* probably worry about all versions
included in all LTS Linux distro releases, but...

> > I am curious how this driver interacts with the ConSplitter when
> > displays are hot added and hot removed. I see a reference to a
> > feature that appears to sync the GOP content between frame buffers
> > when a display is hot added. I would be better if the common code in
> > the ConSplitter handled these types of operations instead of putting
> > that code in individual GOP drivers. I have added Ray to this thread
> > who may have ideas on how to handle these hot add events.
>
> I think the code that you are looking at that syncs GOP content
> might be a debug feature, rather than a hotplug handler. We found
> that some platforms only render to the first GOP device that they
> find, so I added the ability to build a version of the driver (using
> the build flag COPY_PIXELS_FROM_PRIMARY_GOP_DEVICE) that
> "steals" the pixels from another GOP framebuffer and displays them
> on our output, to check that our driver fundamentally works on that
> platform. This code is excluded in a normal build. Most platforms
> are well-behaved and render to all GOP devices correctly.

Best Regards,

Leif

> In general we've found that hotplug of our device works fine,
> without us having to do anything special in the driver. Note that
> the system will initially see this as a USB hotplug rather than a
> display hotplug. For various reasons we decided not to support
> display hotplug (i.e. plugging and unplugging displays into out
> device once our device is plugged in to USB and initialized) in the
> driver, mainly to keep things simple.
>
> Thanks again for your help,
>
> Andy Hayes
>
> From: Kinney, Michael D 
> mailto:michael.d.kin...@intel.com>>
> Sent: 14 August 2019 16:23
> To: Andy Hayes 
> mailto:andy.ha...@displaylink.com>>; 
> devel@edk2.groups.io; Ni, Ray 
> mailto:ray...@intel.com>>; Kinney, Michael D 
> mailto:michael.d.kin...@intel.com>>
> Cc: Leif Lindholm mailto:leif.lindh...@linaro.org>>
> Subject: [External] RE: [PATCH v1 0/1] Added GOP driver for DisplayLink-based 
> Universal USB Docks to edk2-platforms
>
> Hi Andy,
>
> Thanks for the contribution. Is this patch for the edk2-platform repo? The 
> email subject can help clarify the intended repo.
>
>

Re: [edk2-devel] [edk2-platforms: PATCH 1/1] Platforms/RPi3: Add multiple embedded Device Tree selection

2019-08-15 Thread Leif Lindholm

On Mon, Aug 12, 2019 at 02:06:34PM +0100, Pete Batard wrote:
> The Raspberry Pi 3 platform currently has 2 different models, each with a
> different Device Tree. Rather than embedding a single one, and requiring
> users to manually provide the other, this patch ensures that we now embed
> both and and serve the relevant one at runtime.
> 
> Signed-off-by: Pete Batard 

Changeset looks very useful. Some style issues. And one question.

First the question: is there no practical size restriction on the
firmware image? This is a 24k increase in image size.

> ---
>  Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c   | 57 
>  Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.inf |  3 +-
>  Platform/RaspberryPi/RPi3/RPi3.dec  |  3 +-
>  Platform/RaspberryPi/RPi3/RPi3.fdf  |  6 ++-
>  4 files changed, 55 insertions(+), 14 deletions(-)
> 
> diff --git a/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c 
> b/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c
> index c84e5b2767e2..7c0ab75e7cb1 100644
> --- a/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c
> +++ b/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c
> @@ -20,6 +20,11 @@
>  
>  #include 
>  
> +CONST  EFI_GUID *mFdtGuid[] = {
> +   ,
> +   ,
> +};
> +
>  STATIC VOID *mFdtImage;
>  
>  STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL   *mFwProtocol;
> @@ -368,7 +373,9 @@ FdtDxeInitialize (
>EFI_STATUS Status;
>VOID   *FdtImage;
>UINTN  FdtSize;
> +  UINTN  FdtIndex;
>INT32  Retval;
> +  UINT32 BoardRevision;
>BOOLEANInternal;
>  
>Status = gBS->LocateProtocol (, NULL,
> @@ -383,13 +390,41 @@ FdtDxeInitialize (
>   * Have FDT passed via config.txt.
>   */
>  FdtSize = fdt_totalsize (FdtImage);

This
> -DEBUG ((DEBUG_INFO, "DTB passed via config.txt of 0x%lx bytes\n", 
> FdtSize));
> +DEBUG ((DEBUG_INFO, "Device Tree passed via config.txt (0x%lx bytes)\n", 
> FdtSize));
looks unrelated to the changeset.

>  Status = EFI_SUCCESS;
>} else {
> +/*
> + * Use one of the embedded FDT's.
> + */
>  Internal = TRUE;

This DEBUG changes bit
> -DEBUG ((DEBUG_INFO, "No/bad FDT at %p (%a), trying internal DTB...\n",
> -  FdtImage, fdt_strerror (Retval)));
> -Status = GetSectionFromAnyFv (, EFI_SECTION_RAW, 
> 0,
> +DEBUG ((DEBUG_INFO, "No/Bad Device Tree found at address 0x%p (%a), "
> +  "looking up internal one...\n", FdtImage, fdt_strerror (Retval)));
to here looks completely unrelated to the changeset.
Which garbles the diff somewhat with regards to the functional line in
the middle..

> +/*
> + * Query the board revision to differentiate between models.
> + */
> +Status = mFwProtocol->GetModelRevision ();
> +if (EFI_ERROR (Status)) {
> +  FdtIndex = 0;
> +  DEBUG ((DEBUG_ERROR, "Failed to get board type: %r\n", Status));
> +} else {
> +  // 
> www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
> +  switch ((BoardRevision >> 4) & 0xFF) {
> +  case 0x08:  // Raspberry 3 Model B
> +DEBUG ((DEBUG_INFO, "Using RPi3 Model B internal Device Tree\n"));
> +FdtIndex = 0;
> +break;
> +  case 0x0D:  // Raspberry 3 Model B+
> +DEBUG ((DEBUG_INFO, "Using RPi3 Model B+ internal Device Tree\n"));
> +FdtIndex = 1;
> +break;
> +  default:
> +DEBUG ((DEBUG_INFO, "Using default internal Device Tree\n"));
> +FdtIndex = 0;
> +break;
> +  }
> +}
> +ASSERT (FdtIndex < ARRAY_SIZE (mFdtGuid));
> +Status = GetSectionFromAnyFv (mFdtGuid[FdtIndex], EFI_SECTION_RAW, 0,
> , );
>  if (Status == EFI_SUCCESS) {
>if (fdt_check_header (FdtImage) != 0) {

Everything from here...

> @@ -419,27 +454,27 @@ FdtDxeInitialize (
>  
>Status = SanitizePSCI ();
>if (EFI_ERROR (Status)) {
> -Print (L"Failed to sanitize PSCI (error %d)\n", Status);
> +Print (L"Failed to sanitize PSCI: %r\n", Status);
>}
>  
>Status = CleanMemoryNodes ();
>if (EFI_ERROR (Status)) {
> -Print (L"Failed to clean memory nodes (error %d)\n", Status);
> +Print (L"Failed to clean memory nodes: %r\n", Status);
>}
>  
>Status = CleanSimpleFramebuffer ();
>if (EFI_ERROR (Status)) {
> -Print (L"Failed to clean frame buffer (error %d)\n", Status);
> +Print (L"Failed to clean frame buffer: %r\n", Status);
>}
>  
>Status = FixEthernetAliases ();
>if (EFI_ERROR (Status)) {
> -Print (L"Failed to fix ethernet aliases (error %d)\n", Status);
> +Print (L"Failed to fix ethernet aliases: %r\n", Status);
>}
>  
>Status = UpdateMacAddress ();
>if (EFI_ERROR (Status)) {
> -Print (L"Failed to update MAC address (error %d)\n", Status);
> +Print

Re: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by using CPUID(0x15) TSC leaf

2019-08-15 Thread Vitaly Cheptsov via Groups.Io

Hi Donald,

Glad to hear it helped a little, and sorry for some outdated quotes.

Your clarification regarding model range is very helpful. Xeon W being client 
and thus having client clock makes sense, though I must say it was quite not 
obvious. I was referring to the same SDM table, and it would have been great to 
have vertical range binding instead of the misleading CPUID.

With that, however, I still do not see a way to dynamically determine the 
difference between Xeon client and server.

For us it is needed as we use TimerLib differently. For you TimerLib is a part 
of BSP, so you face no issue statically setting the clock frequency as a PCD. 
For us TimerLib is used as a part of an UEFI application compatible with 
different hardware, and in fact not just Intel. We have such "generic TimerLib" 
library, and to determine CPU frequency, as a fallback to CPUID 15H, it relies 
on ACPI PM timer. This is not great for two reasons:
- we have to maintain it ourselves, while we would have liked that be part of 
EDK II with different vendors contributing to the project.
- we still cannot find an obvious way to determine crystal clock when it is not 
reported, in particular for Xeon W and Xeon Scalable case.

I guess this is now out of the scope of this patch and perhaps even this exact 
library, but it will be helpful to hear relevant technical details on the issue 
and opinions on such "generic TimerLib" library to later appear in EDK II.

Best regards,
Vitaly

> 15 авг. 2019 г., в 11:40, Kuo, Donald  написал(а):
> 
> Hi Vitaly,
>
> Appreciated for reviewing very detail. And looks your captured some piece of 
> code is older version. And should be ok, I do got your point.
>
> Item #1
> -  I do missed RegEax error handling in case for 
> CpuidCoreClockCalculateTscFrequency () should return 0 and EFI_UNSUPPORTED. 
> AR: Will update it.
>
> Item #2:
> -  Actually the information is from SDM Table 18-85
> o   As we know CPUID signature could be hard to identify processor XTAL 
> frequency is? So we only check CPUID Leaf 0x15
> o   And the PCD will be defined depends on platform specific and during 
> project early development. Based on SDM, Intel processor for CPUID.15h EAX 
> and EBX is enumerated, but ECX could be possible not enumerated. So that is 
> why we based on  SDM Table 18-85 to create PCD as below:
> §  Intel Xeon Server family: 25MHz
> §  Intel Core and Intel Xeon W family: 24MHz
> §  Intel Atom : 19.2MHz
> §  So regards the “06_55h” might cause the confused, we could review it 
> whether remove it??
> Item #3:
> -  Again, the XTAL frequency is optional and should be define in 
> early phase of new project. Default should still use AcpiTimer.
> oPlatform / developer owner should well know the CPU generation XTAL 
> frequency is? Server / Client / Atom ?
> o   For those CPU not supported should still use AcpiTimerLib (default)
>
> Thanks,
> Donald
>   <>
>  <>From: vit9696 via [] [mailto:vit9696=protonmail.com 
> @[]] 
> Sent: Thursday, August 15, 2019 3:20 PM
> To: Kuo, Donald mailto:donald@intel.com>>; 
> devel@edk2.groups.io 
> Subject: Re: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by 
> using CPUID(0x15) TSC leaf
>
> Hello,
> 
> Thank you for the patch! I reviewed the code and noticed select issues 
> explained below.
> 
> 1. The following construction:
> 
> if (RegEbx == 0) {
> DEBUG ((DEBUG_ERROR, "The CPU is not capble for Core Crystal Clock Frequency 
> !!\n"));
> ASSERT (RegEbx != 0);
> }
> 
> Does not look good to me, and in my opinion, should be written differently:
> 
> if (RegEbx == 0 || RegEax == 0) {
> DEBUG ((DEBUG_ERROR, "The CPU is not capble for Core Crystal Clock Frequency 
> !!\n"));
> ASSERT (RegEbx != 0);
>   ASSERT (RegEax != 0);
>   return 0;
> }
> 
> The reason for the above code being wrong is potential division by zero 
> below, which behaviour is undefined (and in fact unknown due to unspecified 
> interrupt table state). Even though the intent is to not permit the use of 
> this library on an unsupported platform, runtime checks and assertions are 
> essentially NO-OPs, should be separate and not confused. For this to work 
> properly the call to CpuidCoreClockCalculateTscFrequency should happen in 
> library constructor with EFI_UNSUPPORTED return on 
> CpuidCoreClockCalculateTscFrequency returning 0.
> 
> 2. The notes about crystal clock frequency for 06_55H CPU signature:
> "2500 - Intel Xeon Processor Scalable Family with CPUID signature 
> 06_55H(25MHz).\n"
> # Intel Xeon Processor Scalable Family with CPUID signature 06_55H = 2500 
> (25MHz)
> 
> are misleading in both this library and Intel SDM. Intel Xeon W processors 
> have the same CPUID signature (06_55H), they report 0 crystal clock 
> frequency, and their crystal clock frequency is 24 MHz. This should at least 
> be mentioned in the lower part mentioning Intel Xeon W Processor 
> Family(24MHz).
>

Re: [edk2-devel] [PATCH 1/1] CryptoPkg/BaseCryptLib: Update pHkdfCtx to PHkdfCtx

Jian,

Yes, you are right. 
According to CCS_2_1_Draft, 4.3.3.3, Pointer variables may optionally be 
prefixed with a 'p'.
So please skip this change.

Thanks,
Shenglei

> -Original Message-
> From: Wang, Jian J
> Sent: Thursday, August 15, 2019 5:01 PM
> To: Zhang, Shenglei ; devel@edk2.groups.io
> Cc: Ye, Ting 
> Subject: RE: [PATCH 1/1] CryptoPkg/BaseCryptLib: Update pHkdfCtx to
> PHkdfCtx
> 
> Shenglei,
> 
> I remember the edk2 coding style allows prefix 'p' (optional) to represent a
> pointer variable.
> 
> Regards,
> Jian
> 
> 
> > -Original Message-
> > From: Zhang, Shenglei
> > Sent: Thursday, August 15, 2019 4:49 PM
> > To: devel@edk2.groups.io
> > Cc: Wang, Jian J ; Ye, Ting 
> > Subject: [PATCH 1/1] CryptoPkg/BaseCryptLib: Update pHkdfCtx to
> > PHkdfCtx
> >
> > Update pHkdfCtx to PHkdfCtx, to follow the variable naming
> > rule.
> >
> > Cc: Jian Wang 
> > Cc: Ting Ye 
> > Signed-off-by: Shenglei Zhang 
> > ---
> >  .../Library/BaseCryptLib/Kdf/CryptHkdf.c  | 22 +--
> >  1 file changed, 11 insertions(+), 11 deletions(-)
> >
> > diff --git a/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdf.c
> > b/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdf.c
> > index f0fcef211d3f..488346a38b8c 100644
> > --- a/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdf.c
> > +++ b/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdf.c
> > @@ -39,7 +39,7 @@ HkdfSha256ExtractAndExpand (
> >IN   UINTNOutSize
> >)
> >  {
> > -  EVP_PKEY_CTX *pHkdfCtx;
> > +  EVP_PKEY_CTX *PHkdfCtx;
> >BOOLEAN Result;
> >
> >if (Key == NULL || Salt == NULL || Info == NULL || Out == NULL ||
> > @@ -47,29 +47,29 @@ HkdfSha256ExtractAndExpand (
> >  return FALSE;
> >}
> >
> > -  pHkdfCtx = EVP_PKEY_CTX_new_id(EVP_PKEY_HKDF, NULL);
> > -  if (pHkdfCtx == NULL) {
> > +  PHkdfCtx = EVP_PKEY_CTX_new_id(EVP_PKEY_HKDF, NULL);
> > +  if (PHkdfCtx == NULL) {
> >  return FALSE;
> >}
> >
> > -  Result = EVP_PKEY_derive_init(pHkdfCtx) > 0;
> > +  Result = EVP_PKEY_derive_init(PHkdfCtx) > 0;
> >if (Result) {
> > -Result = EVP_PKEY_CTX_set_hkdf_md(pHkdfCtx, EVP_sha256()) > 0;
> > +Result = EVP_PKEY_CTX_set_hkdf_md(PHkdfCtx, EVP_sha256()) > 0;
> >}
> >if (Result) {
> > -Result = EVP_PKEY_CTX_set1_hkdf_salt(pHkdfCtx, Salt,
> > (UINT32)SaltSize) > 0;
> > +Result = EVP_PKEY_CTX_set1_hkdf_salt(PHkdfCtx, Salt,
> > (UINT32)SaltSize) > 0;
> >}
> >if (Result) {
> > -Result = EVP_PKEY_CTX_set1_hkdf_key(pHkdfCtx, Key,
> > (UINT32)KeySize) > 0;
> > +Result = EVP_PKEY_CTX_set1_hkdf_key(PHkdfCtx, Key,
> > (UINT32)KeySize) > 0;
> >}
> >if (Result) {
> > -Result = EVP_PKEY_CTX_add1_hkdf_info(pHkdfCtx, Info,
> > (UINT32)InfoSize) > 0;
> > +Result = EVP_PKEY_CTX_add1_hkdf_info(PHkdfCtx, Info,
> > (UINT32)InfoSize) > 0;
> >}
> >if (Result) {
> > -Result = EVP_PKEY_derive(pHkdfCtx, Out, ) > 0;
> > +Result = EVP_PKEY_derive(PHkdfCtx, Out, ) > 0;
> >}
> >
> > -  EVP_PKEY_CTX_free(pHkdfCtx);
> > -  pHkdfCtx = NULL;
> > +  EVP_PKEY_CTX_free(PHkdfCtx);
> > +  PHkdfCtx = NULL;
> >return Result;
> >  }
> > --
> > 2.18.0.windows.1


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

View/Reply Online (#45717): https://edk2.groups.io/g/devel/message/45717
Mute This Topic: https://groups.io/mt/32884778/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v5 00/35] Specific platform to run OVMF in Xen PVH and HVM guests

On 08/13/19 13:30, Anthony PERARD wrote:
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/ovmf.git 
> br.platform-xen-pvh-v5
>
> Changes in v5:
> - patch 23 got a rework of the lapic range skipping
> - small fixups in patch 20, 22, 23, 31, 32, 33.
>   see notes for detail.

This series is now fully covered with maintainer R-b's and A-b's.

I've also done some regression-tests, after applying the set in a topic
branch on top of commit caa7d3a896f6 ("BaseTools/Scripts: Add
GetUtcDateTime script.", 2019-08-15). Including build tests and my usual
boot & S3 tests.

Building for DEBUG (with GCC48) requires the independent fix

  [edk2-devel] [PATCH 1/1]
  MdeModulePkg/DxeIplPeim: Initialize pointer PageMapLevel5Entry

which was posted at

  20190814073741.16080-1-shenglei.zhang@intel.com">http://mid.mail-archive.com/20190814073741.16080-1-shenglei.zhang@intel.com
  https://edk2.groups.io/g/devel/message/45591

(again, that issue is independent of this series). With that independent
fix, RELEASE builds fine too.

Given that this v5 feature series has now been fully reviewed before
entering the Soft Feature Freeze for edk2-stable201908 -- which will
commence on 2019-08-16 at 00:00:00 UTC-8) --, the set is eligible for
pushing during the Soft Feature Freeze:

  https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
  https://github.com/tianocore/tianocore.github.io/wiki/SoftFeatureFreeze

Therefore I'll push v5 no later than 2019-Aug-21, unless a NACK arrives
before that date, from xen-devel or elsewhere.

Thanks
Laszlo

> Hi,
>
> I've started to create a Xen specific platform, in OvmfPkg/XenOvmf.dsc
> with the goal to make it work on both Xen HVM and Xen PVH.
>
> The first few patches only create the platform and duplicate some code from
> OvmfPkg and the later patches makes OVMF boot in a Xen PVH guest and can boot
> a Linux guest.
>
> After this patch series, I'd like to wait a bit before removing Xen support
> from the OvmfPkg*.dsc, to allow time to switch to the new Xen only platform,
> maybe 1 year.
>
> To build and boot:
>
> To build, simply run OvmfPkg/build.sh -p OvmfPkg/OvmfXen.dsc
> Then use OVMF.fd as a kernel of a pvh guest config file (with xl/libxl).
>
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/ovmf.git 
> br.platform-xen-pvh-v5
>
> Anthony PERARD (35):
>   OvmfPkg/ResetSystemLib: Add missing dependency on PciLib
>   OvmfPkg: Create platform OvmfXen
>   OvmfPkg: Introduce XenResetVector
>   OvmfPkg: Introduce XenPlatformPei
>   OvmfPkg/OvmfXen: Creating an ELF header
>   OvmfPkg/XenResetVector: Add new entry point for Xen PVH
>   OvmfPkg/XenResetVector: Saving start of day pointer for PVH guests
>   OvmfPkg/XenResetVector: Allow jumpstart from either hvmloader or PVH
>   OvmfPkg/OvmfXen: use a TimerLib instance that depends only on the CPU
>   OvmfPkg/XenPlatformPei: Detect OVMF_INFO from hvmloader
>   OvmfPkg/XenPlatformPei: Use mXenHvmloaderInfo to get E820
>   OvmfPkg/XenPlatformPei: Grab RSDP from PVH guest start of day struct
>   OvmfPkg/Library/XenPlatformLib: New library
>   OvmfPkg/AcpiPlatformDxe: Use XenPlatformLib
>   OvmfPkg/AcpiPlatformDxe: Use Xen PVH RSDP if it exist
>   OvmfPkg/XenHypercallLib: Enable it in PEIM
>   OvmfPkg/XenPlatformPei: Reinit XenHypercallLib
>   OvmfPkg/XenPlatformPei: Introduce XenHvmloaderDetected
>   OvmfPkg/XenPlatformPei: Setup HyperPages earlier
>   OvmfPkg/XenPlatformPei: Introduce XenPvhDetected
>   OvmfPkg: Import XENMEM_memory_map hypercall to Xen/memory.h
>   OvmfPkg/XenPlatformPei: no hvmloader: get the E820 table via hypercall
>   OvmfPkg/XenPlatformPei: Rework memory detection
>   OvmfPkg/XenPlatformPei: Reserve VGA memory region, to boot Linux
>   OvmfPkg/XenPlatformPei: Ignore missing PCI Host Bridge on Xen PVH
>   OvmfPkg/XenPlatformLib: Cache result for XenDetected
>   OvmfPkg/PlatformBootManagerLib: Use XenDetected from XenPlatformLib
>   OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen
> PVH
>   OvmfPkg/OvmfXen: Override PcdFSBClock to Xen vLAPIC timer frequency
>   OvmfPkg/OvmfXen: Introduce XenTimerDxe
>   OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn
>   OvmfPkg: Introduce PcdXenGrantFrames
>   OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables
>   OvmfPkg: Move XenRealTimeClockLib from ArmVirtPkg
>   OvmfPkg/OvmfXen: use RealTimeClockRuntimeDxe from EmbeddedPkg
>
>  OvmfPkg/OvmfPkg.dec   |  10 +
>  ArmVirtPkg/ArmVirtXen.dsc |   2 +-
>  OvmfPkg/OvmfPkgIa32.dsc   |   1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc|   1 +
>  OvmfPkg/OvmfPkgX64.dsc|   1 +
>  OvmfPkg/{OvmfPkgX64.dsc => OvmfXen.dsc}   | 238 +---
>  OvmfPkg/OvmfXen.fdf   | 539 ++
>  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf   |   3 +-
>  .../PlatformBootManagerLib.inf

Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

2019-08-15 Thread Yao, Jiewen

Hi Paolo
I am not sure what do you mean - "You do not need a reset vector ...".
If so, where is the first instruction of the new CPU in the virtualization 
environment?
Please help me understand that at first. Then we can continue the discussion.

Thank you
Yao Jiewen

> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Wednesday, August 14, 2019 10:05 PM
> To: Yao, Jiewen ; Laszlo Ersek
> ; edk2-devel-groups-io 
> Cc: edk2-rfc-groups-io ; qemu devel list
> ; Igor Mammedov ;
> Chen, Yingwen ; Nakajima, Jun
> ; Boris Ostrovsky ;
> Joao Marcal Lemos Martins ; Phillip Goerl
> 
> Subject: Re: CPU hotplug using SMM with QEMU+OVMF
> 
> On 14/08/19 15:20, Yao, Jiewen wrote:
> >> - Does this part require a new branch somewhere in the OVMF SEC code?
> >>   How do we determine whether the CPU executing SEC is BSP or
> >>   hot-plugged AP?
> > [Jiewen] I think this is blocked from hardware perspective, since the first
> instruction.
> > There are some hardware specific registers can be used to determine if the
> CPU is new added.
> > I don’t think this must be same as the real hardware.
> > You are free to invent some registers in device model to be used in OVMF
> hot plug driver.
> 
> Yes, this would be a new operation mode for QEMU, that only applies to
> hot-plugged CPUs.  In this mode the AP doesn't reply to INIT or SMI, in
> fact it doesn't reply to anything at all.
> 
> >> - How do we tell the hot-plugged AP where to start execution? (I.e. that
> >>   it should execute code at a particular pflash location.)
> > [Jiewen] Same real mode reset vector at :FFF0.
> 
> You do not need a reset vector or INIT/SIPI/SIPI sequence at all in
> QEMU.  The AP does not start execution at all when it is unplugged, so
> no cache-as-RAM etc.

> We only need to modify QEMU so that hot-plugged APIs do not reply to
> INIT/SIPI/SMI.
> 
> > I don’t think there is problem for real hardware, who always has CAR.
> > Can QEMU provide some CPU specific space, such as MMIO region?
> 
> Why is a CPU-specific region needed if every other processor is in SMM
> and thus trusted.
> >>   Does CPU hotplug apply only at the socket level? If the CPU is
> >>   multi-core, what is responsible for hot-plugging all cores present in
> >>   the socket?
> 
> I can answer this: the SMM handler would interact with the hotplug
> controller in the same way that ACPI DSDT does normally.  This supports
> multiple hotplugs already.
> 
> Writes to the hotplug controller from outside SMM would be ignored.
> 
> >>> (03) New CPU: (Flash) send board message to tell host CPU (GPIO->SCI)
> >>>  -- I am waiting for hot-add message.
> >>
> >> Maybe we can simplify this in QEMU by broadcasting an SMI to existent
> >> processors immediately upon plugging the new CPU.
> 
> The QEMU DSDT could be modified (when secure boot is in effect) to OUT
> to 0xB2 when hotplug happens.  It could write a well-known value to
> 0xB2, to be read by an SMI handler in edk2.
> 
> 
> >>
> >>>(NOTE: Host CPU can
> only
> >> send
> >>>  instruction in SMM mode. -- The register is SMM only)
> >>
> >> Sorry, I don't follow -- what register are we talking about here, and
> >> why is the BSP needed to send anything at all? What "instruction" do you
> >> have in mind?
> > [Jiewen] The new CPU does not enable SMI at reset.
> > At some point of time later, the CPU need enable SMI, right?
> > The "instruction" here means, the host CPUs need tell to CPU to enable
> SMI.
> 
> Right, this would be a write to the CPU hotplug controller
> 
> >>> (04) Host CPU: (OS) get message from board that a new CPU is added.
> >>>  (GPIO -> SCI)
> >>>
> >>> (05) Host CPU: (OS) All CPUs enter SMM (SCI->SWSMI) (NOTE: New CPU
> >>>  will not enter CPU because SMI is disabled)
> >>
> >> I don't understand the OS involvement here. But, again, perhaps QEMU
> can
> >> force all existent CPUs into SMM immediately upon adding the new CPU.
> > [Jiewen] OS here means the Host CPU running code in OS environment, not
> in SMM environment.
> 
> See above.
> 
> >>> (06) Host CPU: (SMM) Save 38000, Update 38000 -- fill simple SMM
> >>>  rebase code.
> >>>
> >>> (07) Host CPU: (SMM) Send message to New CPU to Enable SMI.
> >>
> >> Aha, so this is the SMM-only register you mention in step (03). Is the
> >> register specified in the Intel SDM?
> > [Jiewen] Right. That is the register to let host CPU tell new CPU to enable
> SMI.
> > It is platform specific register. Not defined in SDM.
> > You may invent one in device model.
> 
> See above.
> 
> >>> (10) New CPU: (SMM) Response first SMI at 38000, and rebase SMBASE
> to
> >>>  TSEG.
> >>
> >> What code does the new CPU execute after it completes step (10)? Does
> it
> >> halt?
> >
> > [Jiewen] The new CPU exits SMM and return to original place - where it is
> > interrupted to enter SMM - running code on the flash.
> 
> So in our case we'd need an INIT/SIPI/SIPI sequence between (06) and

Re: [edk2-devel] [PATCH v5 32/35] OvmfPkg: Introduce PcdXenGrantFrames

On 08/15/19 11:40, Laszlo Ersek wrote:
> On 08/13/19 13:31, Anthony PERARD wrote:
>> Introduce PcdXenGrantFrames to replace a define in XenBusDxe and allow
>> the same value to be used in a different module.
>>
>> The reason for the number of page to be 4 doesn't exist anymore, so
>> simply remove the comment.
>>
>> Signed-off-by: Anthony PERARD 
>> Reviewed-by: Laszlo Ersek 
>> ---
>>
>> Notes:
>> v5:
>> - add missing PcdLib to [LibraryClasses]
> 
> Yes, that's for
> 
> 365f2b95-b6c9-03cf-5346-5e1192bfa437@redhat.com">http://mid.mail-archive.com/365f2b95-b6c9-03cf-5346-5e1192bfa437@redhat.com
> https://edk2.groups.io/g/devel/message/44621
> 
> Thanks for it,
> Laszlo
> 
>> v4:
>> - new patch

Also thanks for adding the v4 note retro-actively.

Thanks
Laszlo

>>  OvmfPkg/OvmfPkg.dec | 3 +++
>>  OvmfPkg/XenBusDxe/XenBusDxe.inf | 3 +++
>>  OvmfPkg/XenBusDxe/XenBusDxe.h   | 1 +
>>  OvmfPkg/XenBusDxe/GrantTable.c  | 3 +--
>>  4 files changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
>> index 04d5e29272..d5fee805ef 100644
>> --- a/OvmfPkg/OvmfPkg.dec
>> +++ b/OvmfPkg/OvmfPkg.dec
>> @@ -225,6 +225,9 @@ [PcdsFixedAtBuild]
>>gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtr|0x0|UINT32|0x17
>>
>> gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtrSize|0x0|UINT32|0x32
>>  
>> +  ## Number of page frames to use for storing grant table entries.
>> +  gUefiOvmfPkgTokenSpaceGuid.PcdXenGrantFrames|4|UINT32|0x33
>> +
>>  [PcdsDynamic, PcdsDynamicEx]
>>gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
>> diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.inf 
>> b/OvmfPkg/XenBusDxe/XenBusDxe.inf
>> index 86e0fb8224..536b49fa8c 100644
>> --- a/OvmfPkg/XenBusDxe/XenBusDxe.inf
>> +++ b/OvmfPkg/XenBusDxe/XenBusDxe.inf
>> @@ -51,6 +51,7 @@ [LibraryClasses]
>>XenHypercallLib
>>SynchronizationLib
>>PrintLib
>> +  PcdLib
>>  
>>  [Protocols]
>>gEfiDriverBindingProtocolGuid
>> @@ -59,3 +60,5 @@ [Protocols]
>>gXenBusProtocolGuid
>>gXenIoProtocolGuid
>>  
>> +[FixedPcd]
>> +  gUefiOvmfPkgTokenSpaceGuid.PcdXenGrantFrames
>> diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.h b/OvmfPkg/XenBusDxe/XenBusDxe.h
>> index 8510361bca..b1dcc3549c 100644
>> --- a/OvmfPkg/XenBusDxe/XenBusDxe.h
>> +++ b/OvmfPkg/XenBusDxe/XenBusDxe.h
>> @@ -22,6 +22,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  
>>  //
>> diff --git a/OvmfPkg/XenBusDxe/GrantTable.c b/OvmfPkg/XenBusDxe/GrantTable.c
>> index 6575e9b88c..1130404cd1 100644
>> --- a/OvmfPkg/XenBusDxe/GrantTable.c
>> +++ b/OvmfPkg/XenBusDxe/GrantTable.c
>> @@ -22,8 +22,7 @@
>>  
>>  #define NR_RESERVED_ENTRIES 8
>>  
>> -/* NR_GRANT_FRAMES must be less than or equal to that configured in Xen */
>> -#define NR_GRANT_FRAMES 4
>> +#define NR_GRANT_FRAMES (FixedPcdGet32 (PcdXenGrantFrames))
>>  #define NR_GRANT_ENTRIES (NR_GRANT_FRAMES * EFI_PAGE_SIZE / 
>> sizeof(grant_entry_v1_t))
>>  
>>  STATIC grant_entry_v1_t *GrantTable = NULL;
>>
> 


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

View/Reply Online (#45714): https://edk2.groups.io/g/devel/message/45714
Mute This Topic: https://groups.io/mt/32851690/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v5 33/35] OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables

On 08/13/19 13:31, Anthony PERARD wrote:
> XenIoPvhDxe use XenIoMmioLib to reserve some space to be use by the
> Grant Tables.
> 
> The call is only done if it is necessary, we simply detect if the
> guest is PVH, as in this case there is currently no PCI bus, and no
> PCI Xen platform device which would start the XenIoPciDxe and allocate
> the space for the Grant Tables.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
> Signed-off-by: Anthony PERARD 
> Reviewed-by: Laszlo Ersek 
> ---
> 
> Notes:
> v5:
> - add missing PcdLib as #include and in [LibraryClasses]

8a5d9e63-12f1-2ff8-7c40-773d15baf333@redhat.com">http://mid.mail-archive.com/8a5d9e63-12f1-2ff8-7c40-773d15baf333@redhat.com
https://edk2.groups.io/g/devel/message/44622

The update looks good, thanks!
Laszlo

> v4:
> - Removed XenIoPvhDxeNotifyExitBoot() which was doing action that should
>   not be done in an ExitBootServices notification.
>   (InitializeXenIoPvhDxe() has been cleaned up following this.)
> - Use new PcdXenGrantFrames.
> - Some coding style fix
> - Update Maintainers.txt
> 
> v3:
> - downgrade type to DXE_DRIVER
> - use SPDX
> - rework InitializeXenIoPvhDxe, and handle errors properly.
> - Free the reserved allocation in ExitBootServices even if the XenIo
>   protocol could successfully been uninstalled.
> 
> v2:
> - do allocation in EntryPoint like the other user of XenIoMmioLib.
> - allocate memory instead of hardcoded addr.
> - cleanup, add copyright
> - detect if we are running in PVH mode
> 
>  OvmfPkg/OvmfXen.dsc |  2 ++
>  OvmfPkg/OvmfXen.fdf |  1 +
>  OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf | 36 +++
>  OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c   | 54 +
>  Maintainers.txt |  1 +
>  5 files changed, 94 insertions(+)
>  create mode 100644 OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
>  create mode 100644 OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
> 
> diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
> index e719a168f8..5e07b37279 100644
> --- a/OvmfPkg/OvmfXen.dsc
> +++ b/OvmfPkg/OvmfXen.dsc
> @@ -195,6 +195,7 @@ [LibraryClasses]
>
> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
>XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
>XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
> +  XenIoMmioLib|OvmfPkg/Library/XenIoMmioLib/XenIoMmioLib.inf
>  
>
> Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
>
> TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
> @@ -583,6 +584,7 @@ [Components]
>NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
>  !endif
>}
> +  OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
>OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
>OvmfPkg/XenBusDxe/XenBusDxe.inf
>OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> diff --git a/OvmfPkg/OvmfXen.fdf b/OvmfPkg/OvmfXen.fdf
> index 5c1a925d6a..517a492f14 100644
> --- a/OvmfPkg/OvmfXen.fdf
> +++ b/OvmfPkg/OvmfXen.fdf
> @@ -309,6 +309,7 @@ [FV.DXEFV]
>  INF  MdeModulePkg/Universal/Metronome/Metronome.inf
>  INF  
> PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
>  
> +INF  OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
>  INF  OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
>  INF  OvmfPkg/XenBusDxe/XenBusDxe.inf
>  INF  OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> diff --git a/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf 
> b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
> new file mode 100644
> index 00..1c27f8aae0
> --- /dev/null
> +++ b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
> @@ -0,0 +1,36 @@
> +## @file
> +#  Driver for the XenIo protocol
> +#
> +#  Copyright (c) 2019, Citrix Systems, Inc.
> +#
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +##
> +
> +[Defines]
> +  INF_VERSION   = 0x00010005
> +  BASE_NAME = XenIoPvhDxe
> +  FILE_GUID = 7a567cc4-0e75-4d7a-a305-c3db109b53ad
> +  MODULE_TYPE   = DXE_DRIVER
> +  VERSION_STRING= 1.0
> +  ENTRY_POINT   = InitializeXenIoPvhDxe
> +
> +[Packages]
> +  MdePkg/MdePkg.dec
> +  OvmfPkg/OvmfPkg.dec
> +
> +[Sources]
> +  XenIoPvhDxe.c
> +
> +[LibraryClasses]
> +  MemoryAllocationLib
> +  PcdLib
> +  UefiDriverEntryPoint
> +  XenIoMmioLib
> +  XenPlatformLib
> +
> +[FixedPcd]
> +  gUefiOvmfPkgTokenSpaceGuid.PcdXenGrantFrames
> +
> +[Depex]
> +  TRUE
> diff --git a/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c 
> b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
> new file mode 100644
> index 00..9264a85df1
> --- /dev/null
> +++ b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
> @@ -0,0 +1,54 @@
> +/** @file
> +
> +  Driver for the XenIo protocol
> +
> +  This driver simply allocate space for the grant tables.
> +
> +  Copyright (c) 2019, Citrix Systems, Inc.
> +
> +  SPDX-License-Identifier:

Re: [edk2-devel] [PATCH v5 32/35] OvmfPkg: Introduce PcdXenGrantFrames

On 08/13/19 13:31, Anthony PERARD wrote:
> Introduce PcdXenGrantFrames to replace a define in XenBusDxe and allow
> the same value to be used in a different module.
> 
> The reason for the number of page to be 4 doesn't exist anymore, so
> simply remove the comment.
> 
> Signed-off-by: Anthony PERARD 
> Reviewed-by: Laszlo Ersek 
> ---
> 
> Notes:
> v5:
> - add missing PcdLib to [LibraryClasses]

Yes, that's for

365f2b95-b6c9-03cf-5346-5e1192bfa437@redhat.com">http://mid.mail-archive.com/365f2b95-b6c9-03cf-5346-5e1192bfa437@redhat.com
https://edk2.groups.io/g/devel/message/44621

Thanks for it,
Laszlo

> v4:
> - new patch
> 
>  OvmfPkg/OvmfPkg.dec | 3 +++
>  OvmfPkg/XenBusDxe/XenBusDxe.inf | 3 +++
>  OvmfPkg/XenBusDxe/XenBusDxe.h   | 1 +
>  OvmfPkg/XenBusDxe/GrantTable.c  | 3 +--
>  4 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index 04d5e29272..d5fee805ef 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -225,6 +225,9 @@ [PcdsFixedAtBuild]
>gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtr|0x0|UINT32|0x17
>gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtrSize|0x0|UINT32|0x32
>  
> +  ## Number of page frames to use for storing grant table entries.
> +  gUefiOvmfPkgTokenSpaceGuid.PcdXenGrantFrames|4|UINT32|0x33
> +
>  [PcdsDynamic, PcdsDynamicEx]
>gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
> diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.inf b/OvmfPkg/XenBusDxe/XenBusDxe.inf
> index 86e0fb8224..536b49fa8c 100644
> --- a/OvmfPkg/XenBusDxe/XenBusDxe.inf
> +++ b/OvmfPkg/XenBusDxe/XenBusDxe.inf
> @@ -51,6 +51,7 @@ [LibraryClasses]
>XenHypercallLib
>SynchronizationLib
>PrintLib
> +  PcdLib
>  
>  [Protocols]
>gEfiDriverBindingProtocolGuid
> @@ -59,3 +60,5 @@ [Protocols]
>gXenBusProtocolGuid
>gXenIoProtocolGuid
>  
> +[FixedPcd]
> +  gUefiOvmfPkgTokenSpaceGuid.PcdXenGrantFrames
> diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.h b/OvmfPkg/XenBusDxe/XenBusDxe.h
> index 8510361bca..b1dcc3549c 100644
> --- a/OvmfPkg/XenBusDxe/XenBusDxe.h
> +++ b/OvmfPkg/XenBusDxe/XenBusDxe.h
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  
>  //
> diff --git a/OvmfPkg/XenBusDxe/GrantTable.c b/OvmfPkg/XenBusDxe/GrantTable.c
> index 6575e9b88c..1130404cd1 100644
> --- a/OvmfPkg/XenBusDxe/GrantTable.c
> +++ b/OvmfPkg/XenBusDxe/GrantTable.c
> @@ -22,8 +22,7 @@
>  
>  #define NR_RESERVED_ENTRIES 8
>  
> -/* NR_GRANT_FRAMES must be less than or equal to that configured in Xen */
> -#define NR_GRANT_FRAMES 4
> +#define NR_GRANT_FRAMES (FixedPcdGet32 (PcdXenGrantFrames))
>  #define NR_GRANT_ENTRIES (NR_GRANT_FRAMES * EFI_PAGE_SIZE / 
> sizeof(grant_entry_v1_t))
>  
>  STATIC grant_entry_v1_t *GrantTable = NULL;
> 


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

View/Reply Online (#45712): https://edk2.groups.io/g/devel/message/45712
Mute This Topic: https://groups.io/mt/32851690/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v5 31/35] OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn

On 08/13/19 13:31, Anthony PERARD wrote:
> On a Xen PVH guest, none of the existing serial or console interface
> works, so we add a new one, based on XenConsoleSerialPortLib, and
> implemented via SerialDxe.
> 
> That is a simple console implementation that can work on both PVH
> guest and HVM guests, even if it is rarely going to be used on HVM.
> 
> Have PlatformBootManagerLib look for the new console, when running as a
> Xen guest.
> 
> Since we use VENDOR_UART_DEVICE_PATH, fix its description and coding
> style.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
> Signed-off-by: Anthony PERARD 
> Reviewed-by: Laszlo Ersek 
> ---
> 
> Notes:
> v5:
> - fix typos in commit message.

Thanks for those fixes, my R-b stands.

Laszlo

> v4:
> - instead of creating a new XEN_CONSOLE_DEVICE_PATH, use the existing
>   VENDOR_UART_DEVICE_PATH. And explain why VENDOR_UART_DEVICE_PATH
>   changed in the commit message.
> 
> v3:
> - removed PciSioSerialDxe and IsaSerialDxe from OvmfXen, since they
>   would not be used, maybe, to check.
> - some coding style fix
> 
> - not changed: PciSioSerialDxe: even if we add SerialDxe, we still needs
>   PciSioSerialDxe to have OVMF use the emulated serial port on HVM.
> 
> v2:
> - Use MdeModulePkg/Universal/SerialDxe instead of something new.
> - Have PlatformInitializeConsole() look for it by using the
>   known-in-advance device path for the xen console in the
>   PLATFORM_CONSOLE_CONNECT_ENTRY.
> 
>  OvmfPkg/OvmfXen.dsc   |  4 ++
>  OvmfPkg/OvmfXen.fdf   |  1 +
>  .../PlatformBootManagerLib.inf|  4 ++
>  .../PlatformBootManagerLib/BdsPlatform.h  |  1 +
>  .../PlatformBootManagerLib/BdsPlatform.c  |  3 +-
>  .../PlatformBootManagerLib/PlatformData.c | 49 +--
>  6 files changed, 58 insertions(+), 4 deletions(-)
> 
> diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
> index 54ac910d8e..e719a168f8 100644
> --- a/OvmfPkg/OvmfXen.dsc
> +++ b/OvmfPkg/OvmfXen.dsc
> @@ -586,6 +586,10 @@ [Components]
>OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
>OvmfPkg/XenBusDxe/XenBusDxe.inf
>OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> +  MdeModulePkg/Universal/SerialDxe/SerialDxe.inf {
> +
> +  
> SerialPortLib|OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf
> +  }
>MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
>
> MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
>MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
> diff --git a/OvmfPkg/OvmfXen.fdf b/OvmfPkg/OvmfXen.fdf
> index fa0830a324..5c1a925d6a 100644
> --- a/OvmfPkg/OvmfXen.fdf
> +++ b/OvmfPkg/OvmfXen.fdf
> @@ -312,6 +312,7 @@ [FV.DXEFV]
>  INF  OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
>  INF  OvmfPkg/XenBusDxe/XenBusDxe.inf
>  INF  OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> +INF  MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>  
>  INF  MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
>  INF  
> MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
> diff --git 
> a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
> b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> index 04d614cd49..f89cce1879 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> @@ -61,6 +61,10 @@ [Pcd]
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
>gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut
> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity   ## CONSUMES
> +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
>  
>  [Pcd.IA32, Pcd.X64]
>gEfiMdePkgTokenSpaceGuid.PcdFSBClock
> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h 
> b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
> index 49a072b400..153e215101 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
> @@ -165,6 +165,7 @@ typedef struct {
>  #define CONSOLE_IN  BIT1
>  #define STD_ERROR   BIT2
>  extern PLATFORM_CONSOLE_CONNECT_ENTRY  gPlatformConsole[];
> +extern PLATFORM_CONSOLE_CONNECT_ENTRY  gXenPlatformConsole[];
>  
>  //
>  // Platform BDS Functions
> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
> b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> index 1eba304f09..70df6b841a 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> @@ -398,7 +398,8 @@ PlatformBootManagerBeforeConsole (
>//
>

Re: [edk2-devel] [PATCH V2 00/10] Multiple Controllers Support solution

Eric:
  I push the change for edk2platform. 
  And, I push the remaining patches 
a6ee24fbddcd901347014e045611eb6108f4f741..a5944b6a13e227da23daa0ab59b5d6f4b06bb49b

Thanks
Liming
>-Original Message-
>From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>Liming Gao
>Sent: Wednesday, August 14, 2019 12:38 PM
>To: Jin, Eric ; devel@edk2.groups.io
>Subject: Re: [edk2-devel] [PATCH V2 00/10] Multiple Controllers Support
>solution
>
>Eric:
>  I push the first 3 patches
>82407bd129dca8ec6d96e85f541b0974c8d7e087..1f06aa24c29405f271f514f01c3
>96c2ba19c1370.
>  Then, the changes in edk2 platform can be submitted. After edk2platform
>change is ready, I will push the remaining patch set.
>
>Thanks
>Liming
>>-Original Message-
>>From: Jin, Eric
>>Sent: Monday, August 12, 2019 11:17 PM
>>To: Gao, Liming ; devel@edk2.groups.io
>>Cc: Jin, Eric 
>>Subject: RE: [edk2-devel] [PATCH V2 00/10] Multiple Controllers Support
>>solution
>>
>>Liming,
>>
>>Thank you for comment.
>>We will update GetLowestSupportedVersion() API function header to
>include
>>Private param when we push the code to repo. Thanks.
>>
>>Best Regards
>>Eric
>>
>>-Original Message-
>>From: Gao, Liming
>>Sent: Monday, August 12, 2019 5:24 PM
>>To: Jin, Eric ; devel@edk2.groups.io
>>Subject: RE: [edk2-devel] [PATCH V2 00/10] Multiple Controllers Support
>>solution
>>
>>That's good information.
>>
>>In patch 5, GetLowestSupportedVersion() API function header should be
>>updated to include Private param. I have no other comments.
>>
>>With this change, Reviewed-by: Liming Gao 
>>
>>///
>>@@ -193,7 +200,7 @@ GetImageTypeNameString (  **/
>> UINT32
>> GetLowestSupportedVersion (
>>-  VOID
>>+  FIRMWARE_MANAGEMENT_PRIVATE_DATA  *Private
>>   )
>>
>>Thanks
>>Liming
>>>-Original Message-
>>>From: Jin, Eric
>>>Sent: Monday, August 12, 2019 3:14 PM
>>>To: Gao, Liming ; devel@edk2.groups.io
>>>Subject: RE: [edk2-devel] [PATCH V2 00/10] Multiple Controllers Support
>>>solution
>>>
>>>Liming,
>>>
>>>The differences between V2 and V1 are listed below.
>>>
>>>1) The series is composed of 10 patches in V2 (14 in V1). patch 14 is
>>>merged into patch 4, and patch 11/12/13 are merged into patch 5.
>>>2) Try to fix the issue exposed by ECC.
>>>
>>>Btw, the patch of edk2-platform
>>>Platform\Intel\Vlv2TbltDevicePkg\Feature\Capsule\Library\FmpDeviceLib
>>>to support new APIs is provided in separated patch
>>>https://edk2.groups.io/g/devel/message/45328
>>>
>>>Best Regards
>>>Eric
>>>
>>>-Original Message-
>>>From: Gao, Liming
>>>Sent: Monday, August 12, 2019 1:19 PM
>>>To: devel@edk2.groups.io; Jin, Eric 
>>>Subject: RE: [edk2-devel] [PATCH V2 00/10] Multiple Controllers Support
>>>solution
>>>
>>>Eric:
>>>  Can you list the difference compared to version 1?
>>>
>>>Thanks
>>>Liming
-Original Message-
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
Eric Jin
Sent: Monday, August 12, 2019 9:46 AM
To: devel@edk2.groups.io
Subject: [edk2-devel] [PATCH V2 00/10] Multiple Controllers Support
solution

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

The patch set is to support drivers that manage multiple controllers
and also provide a firmware update capability to each managed controller.

The following modules are related to Multiple Controllers Support
solution

FmpDevicePkg\FmpDxe\FmpDxe.inf - Driver to manage multiple
>>controllers
and provide the firmware update capability to each managed controller.
FmpDevicePkg\CapsuleUpdatePolicyDxe\CapsuleUpdatePolicyDxe.inf -
>>>Driver
to produce the Capsule Update Policy Protocol using the services of
the CapsuleUpdatePolicyLib class. The protocol is a private interface
to the FmpDevicePkg
FmpDevicePkg\Library\CapsuleUpdatePolicyLibOnProtocol\CapsuleUpdat
>e
>>P
>>>o
licyLibOnProtocol.inf -
CapsuleUpdatePolicyLib instance that uses the services of the Capsule
Update Policy Protocol produced by CapsuleUpdatePolicyDxe
FmpDevicePkg\Library\CapsuleUpdatePolicyLibNull\CapsuleUpdatePolicy
>Li
>>b
>>>N
ull.inf -
Null CapsuleUpdatePolicyLib instance and the template for platform
specific implementation
FmpDevicePkg\Library\FmpDeviceLibNull\FmpDeviceLibNull.inf - Null
FmpDeviceLib instance and the template for platform specific
implementation

Eric Jin (10):
  FmpDevicePkg: Add UEFI_DRIVER support
  FmpDevicePkg: Add APIs to FmpDeviceLib
  FmpDEvicePkg/FmpDeviceLibNull: Implement new APIs
  FmpDevicePkg/FmpDxe: Use new FmpDeviceLib APIs
  FmpDevicePkg/FmpDxe: Different variable for each FMP Descriptor
  FmpDevicePkg: Add Capsule Update Policy Protocol
  FmpDevicePkg/FmpDxe: Improve all DEBUG() messages
  FmpDevicePkg/FmpDxe: Add PcdFmpDeviceImageTypeIdGuid
  FmpDevicePkg/FmpDxe: Add PcdFmpDeviceStorageAccessEnable
  FmpDevicePkg/FmpDxe: Remove use of CatSprint()

Re: [edk2-devel] [PATCH v5 23/35] OvmfPkg/XenPlatformPei: Rework memory detection

On 08/13/19 13:31, Anthony PERARD wrote:
> When running as a Xen PVH guest, there is no CMOS to read the memory
> size from.  Rework GetSystemMemorySize(Below|Above)4gb() so they can
> work without CMOS by reading the e820 table.
> 
> Rework XenPublishRamRegions to also care for the reserved and ACPI
> entry in the e820 table. The region that was added by InitializeXen()
> isn't needed as that same entry is in the e820 table provided by
> hvmloader.
> 
> MTRR settings aren't modified anymore, on HVM it's already done by
> hvmloader, on PVH it is supposed to have sane default. MTRR will need
> to be done properly but keeping what's already been done by programs
> that have run before OVMF will do for now.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
> Signed-off-by: Anthony PERARD 
> Acked-by: Laszlo Ersek 
> ---
> 
> Notes:
> v5:
> - fix coding style
> - fix typo in commit message
> - Handle all possible cases of a E820 reserved range overlapping with the
>   LAPIC range.
> 
> v4:
> - some coding style
> - Added AddReservedMemoryRangeHob, and using it.
> - this patch now replace "OvmfPkg/XenPlatformPei: Reserve hvmloader's 
> memory only when it has run"
>   from v3.  hvmloader have added an entry in the e820 table, there is no
>   need for a special case.
> - now, everything that is in the e820 table is added to OVMF's memory
>   map, no more skipping ACPI entries or hvmloader's reserved entries.
>   Instead, we look for the local APIC region and avoid it if it is
>   present in the e820.
> - rework commit message
> 
>  OvmfPkg/XenPlatformPei/Platform.h  | 13 ++
>  OvmfPkg/XenPlatformPei/MemDetect.c | 69 +++
>  OvmfPkg/XenPlatformPei/Platform.c  | 11 +
>  OvmfPkg/XenPlatformPei/Xen.c   | 75 +-
>  4 files changed, 147 insertions(+), 21 deletions(-)
> 
> diff --git a/OvmfPkg/XenPlatformPei/Platform.h 
> b/OvmfPkg/XenPlatformPei/Platform.h
> index db9a62572f..7661f4a8de 100644
> --- a/OvmfPkg/XenPlatformPei/Platform.h
> +++ b/OvmfPkg/XenPlatformPei/Platform.h
> @@ -44,6 +44,13 @@ AddReservedMemoryBaseSizeHob (
>BOOLEAN Cacheable
>);
>  
> +VOID
> +AddReservedMemoryRangeHob (
> +  EFI_PHYSICAL_ADDRESSMemoryBase,
> +  EFI_PHYSICAL_ADDRESSMemoryLimit,
> +  BOOLEAN Cacheable
> +  );
> +
>  VOID
>  AddressWidthInitialization (
>VOID
> @@ -114,6 +121,12 @@ XenPublishRamRegions (
>VOID
>);
>  
> +EFI_STATUS
> +XenGetE820Map (
> +  EFI_E820_ENTRY64 **Entries,
> +  UINT32 *Count
> +  );
> +
>  extern EFI_BOOT_MODE mBootMode;
>  
>  extern UINT8 mPhysMemAddressWidth;
> diff --git a/OvmfPkg/XenPlatformPei/MemDetect.c 
> b/OvmfPkg/XenPlatformPei/MemDetect.c
> index cf95f9c474..1f81eee407 100644
> --- a/OvmfPkg/XenPlatformPei/MemDetect.c
> +++ b/OvmfPkg/XenPlatformPei/MemDetect.c
> @@ -96,6 +96,45 @@ Q35TsegMbytesInitialization (
>mQ35TsegMbytes = ExtendedTsegMbytes;
>  }
>  
> +STATIC
> +UINT64
> +GetHighestSystemMemoryAddress (
> +  BOOLEAN   Below4gb
> +  )
> +{
> +  EFI_E820_ENTRY64*E820Map;
> +  UINT32  E820EntriesCount;
> +  EFI_E820_ENTRY64*Entry;
> +  EFI_STATUS  Status;
> +  UINT32  Loop;
> +  UINT64  HighestAddress;
> +  UINT64  EntryEnd;
> +
> +  HighestAddress = 0;
> +
> +  Status = XenGetE820Map (, );
> +  ASSERT_EFI_ERROR (Status);
> +
> +  for (Loop = 0; Loop < E820EntriesCount; Loop++) {
> +Entry = E820Map + Loop;
> +EntryEnd = Entry->BaseAddr + Entry->Length;
> +
> +if (Entry->Type == EfiAcpiAddressRangeMemory &&
> +EntryEnd > HighestAddress) {
> +
> +  if (Below4gb && (EntryEnd <= BASE_4GB)) {
> +HighestAddress = EntryEnd;
> +  } else if (!Below4gb && (EntryEnd >= BASE_4GB)) {
> +HighestAddress = EntryEnd;
> +  }
> +}
> +  }
> +
> +  //
> +  // Round down the end address.
> +  //
> +  return HighestAddress & ~(UINT64)EFI_PAGE_MASK;
> +}
>  
>  UINT32
>  GetSystemMemorySizeBelow4gb (
> @@ -105,6 +144,19 @@ GetSystemMemorySizeBelow4gb (
>UINT8 Cmos0x34;
>UINT8 Cmos0x35;
>  
> +  //
> +  // In PVH case, there is no CMOS, we have to calculate the memory size
> +  // from parsing the E820
> +  //
> +  if (XenPvhDetected ()) {
> +UINT64  HighestAddress;
> +
> +HighestAddress = GetHighestSystemMemoryAddress (TRUE);
> +ASSERT (HighestAddress > 0 && HighestAddress <= BASE_4GB);
> +
> +return HighestAddress;
> +  }
> +
>//
>// CMOS 0x34/0x35 specifies the system memory above 16 MB.
>// * CMOS(0x35) is the high byte
> @@ -129,6 +181,23 @@ GetSystemMemorySizeAbove4gb (
>UINT32 Size;
>UINTN  CmosIndex;
>  
> +  //
> +  // In PVH case, there is no CMOS, we have to calculate the memory size
> +  // from parsing the E820
> +  //
> +  if (XenPvhDetected ()) {
> +UINT64  HighestAddress;
> +
> +HighestAddress =

Re: [edk2-devel] [PATCH v2 0/3] add DwMmcHcDxe driver

2019-08-15 Thread Loh, Tien Hock

Hi Leif, Ard, Christopher,

Haojian and I have tested the driver on 2 platforms, any further comments on 
this?

Thanks
Tien Hock

> -Original Message-
> From: Haojian Zhuang 
> Sent: Tuesday, July 30, 2019 3:33 PM
> To: Loh, Tien Hock ; leif.lindh...@linaro.org;
> ard.biesheu...@linaro.org; christopher...@microsoft.com
> Cc: devel@edk2.groups.io; thlo...@gmail.com
> Subject: Re: [PATCH v2 0/3] add DwMmcHcDxe driver
> 
> On Wed, Jul 24, 2019 at 05:26:03PM +0800, tien.hock@intel.com wrote:
> > From: "Tien Hock, Loh" 
> >
> > Changelog:
> > v3:
> >   * Fix an issue in NonDiscoverableDeviceDxe driver where it did not
> invalidate
> > cache before copying the memory.
> > v2:
> >   *Split DwMmcHcDxe driver into two patches. One is for PlatformDwMmc
> protocol,
> >and the other is for DwMmcHcDxe driver.
> > v1:
> >   *Add NonDiscoverableDeviceDxe for embedded platform. Make
> DwMmcHcDxe driver
> >to support both eMMC and SD controller.
> >
> > Haojian Zhuang (3):
> >   EmbeddedPkg: add NonDiscoverableDeviceDxe driver
> >   EmbeddedPkg: add PlatformDwMmc protocol
> >   EmbeddedPkg/Drivers: add DwMmcHcDxe driver
> >
> >  .../Drivers/DwMmcHcDxe/ComponentName.c|  214 ++
> >  EmbeddedPkg/Drivers/DwMmcHcDxe/DwMmcHcDxe.c   | 1295
> +
> >  EmbeddedPkg/Drivers/DwMmcHcDxe/DwMmcHcDxe.dec |   40 +
> >  EmbeddedPkg/Drivers/DwMmcHcDxe/DwMmcHcDxe.h   |  815 ++
> >  EmbeddedPkg/Drivers/DwMmcHcDxe/DwMmcHcDxe.inf |   69 +
> >  EmbeddedPkg/Drivers/DwMmcHcDxe/DwMmcHci.c | 2366
> +
> >  EmbeddedPkg/Drivers/DwMmcHcDxe/DwMmcHci.h |  983 +++
> >  EmbeddedPkg/Drivers/DwMmcHcDxe/EmmcDevice.c   | 1042 
> >  EmbeddedPkg/Drivers/DwMmcHcDxe/SdDevice.c | 1104 
> >  EmbeddedPkg/EmbeddedPkg.dec   |1 +
> >  EmbeddedPkg/Include/Protocol/PlatformDwMmc.h  |   79 +
> >  .../NonDiscoverableDeviceDxe/ComponentName.c  |  124 +
> >  .../NonDiscoverableDeviceDxe.c|  243 ++
> >  .../NonDiscoverableDeviceDxe.inf  |   52 +
> >  .../NonDiscoverableDeviceIo.c |  976 +++
> >  .../NonDiscoverableDeviceIo.h |   92 +
> >  16 files changed, 9495 insertions(+)
> >  create mode 100644
> EmbeddedPkg/Drivers/DwMmcHcDxe/ComponentName.c
> >  create mode 100644
> EmbeddedPkg/Drivers/DwMmcHcDxe/DwMmcHcDxe.c
> >  create mode 100644
> EmbeddedPkg/Drivers/DwMmcHcDxe/DwMmcHcDxe.dec
> >  create mode 100644
> EmbeddedPkg/Drivers/DwMmcHcDxe/DwMmcHcDxe.h
> >  create mode 100644
> EmbeddedPkg/Drivers/DwMmcHcDxe/DwMmcHcDxe.inf
> >  create mode 100644 EmbeddedPkg/Drivers/DwMmcHcDxe/DwMmcHci.c
> >  create mode 100644 EmbeddedPkg/Drivers/DwMmcHcDxe/DwMmcHci.h
> >  create mode 100644 EmbeddedPkg/Drivers/DwMmcHcDxe/EmmcDevice.c
> >  create mode 100644 EmbeddedPkg/Drivers/DwMmcHcDxe/SdDevice.c
> >  create mode 100644 EmbeddedPkg/Include/Protocol/PlatformDwMmc.h
> >  create mode 100644
> > EmbeddedPkg/Universal/NonDiscoverableDeviceDxe/ComponentName.c
> >  create mode 100644
> >
> EmbeddedPkg/Universal/NonDiscoverableDeviceDxe/NonDiscoverableDevic
> eDx
> > e.c  create mode 100644
> >
> EmbeddedPkg/Universal/NonDiscoverableDeviceDxe/NonDiscoverableDevic
> eDx
> > e.inf  create mode 100644
> >
> EmbeddedPkg/Universal/NonDiscoverableDeviceDxe/NonDiscoverableDevic
> eIo
> > .c  create mode 100644
> >
> EmbeddedPkg/Universal/NonDiscoverableDeviceDxe/NonDiscoverableDevic
> eIo
> > .h
> >
> > --
> > 2.19.0
> >
> 
> Hi Leif, Ard & Chris,
> 
> Could you help to share your comments on this patch set?
> 
> Best Regards
> Haojian

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

View/Reply Online (#45708): https://edk2.groups.io/g/devel/message/45708
Mute This Topic: https://groups.io/mt/32582252/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by using CPUID(0x15) TSC leaf

2019-08-15 Thread Donald Kuo

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

Cc: Ray Ni 
Cc: Star Zeng 
Cc: Eric Dong 
Cc: Amy Chan 
Cc: Rangasai V Chaganty 
Signed-off-by: Donald Kuo 
---
 UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c   |  41 +++
 UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf |  35 +++
 UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni |  17 ++
 UefiCpuPkg/Library/CpuTimerLib/CpuTimerLib.c   | 279 +
 UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.c|  85 +++
 UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.inf  |  37 +++
 UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.uni  |  17 ++
 UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.c|  58 +
 UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.inf  |  36 +++
 UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.uni  |  17 ++
 UefiCpuPkg/UefiCpuPkg.dec  |   8 +
 UefiCpuPkg/UefiCpuPkg.dsc  |   3 +
 UefiCpuPkg/UefiCpuPkg.uni  |  10 +
 13 files changed, 643 insertions(+)
 create mode 100644 UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
 create mode 100644 UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
 create mode 100644 UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni
 create mode 100644 UefiCpuPkg/Library/CpuTimerLib/CpuTimerLib.c
 create mode 100644 UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.c
 create mode 100644 UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.inf
 create mode 100644 UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.uni
 create mode 100644 UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.c
 create mode 100644 UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.inf
 create mode 100644 UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.uni

diff --git a/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c 
b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
new file mode 100644
index 00..6ddf917bad
--- /dev/null
+++ b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
@@ -0,0 +1,41 @@
+/** @file
+  CPUID Leaf 0x15 for Core Crystal Clock frequency instance as Base Timer 
Library.
+
+  Copyright (c) 2019 Intel Corporation. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+#include 
+
+/**
+  CPUID Leaf 0x15 for Core Crystal Clock Frequency.
+
+  The TSC counting frequency is determined by using CPUID leaf 0x15. Frequency 
in MHz = Core XTAL frequency * EBX/EAX.
+  In newer flavors of the CPU, core xtal frequency is returned in ECX or 0 if 
not supported.
+  @return The number of TSC counts per second.
+
+**/
+UINT64
+CpuidCoreClockCalculateTscFrequency (
+  VOID
+  );
+
+/**
+  Internal function to retrieves the 64-bit frequency in Hz.
+
+  Internal function to retrieves the 64-bit frequency in Hz.
+
+  @return The frequency in Hz.
+
+**/
+UINT64
+InternalGetPerformanceCounterFrequency (
+  VOID
+  )
+{
+  return CpuidCoreClockCalculateTscFrequency ();
+}
+
diff --git a/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf 
b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
new file mode 100644
index 00..fd93adc5f1
--- /dev/null
+++ b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
@@ -0,0 +1,35 @@
+## @file
+#  Base CPU Timer Library
+#
+#  Provides basic timer support using CPUID Leaf 0x15 XTAL frequency. The 
performance
+#  counter features are provided by the processors time stamp counter.
+#
+#  Copyright (c) 2019, Intel Corporation. All rights reserved.
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = BaseCpuTimerLib
+  FILE_GUID  = F10B5B91-D15A-496C-B044-B5235721AA08
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = TimerLib|SEC PEI_CORE PEIM
+  MODULE_UNI_FILE= BaseCpuTimerLib.uni
+
+[Sources]
+  CpuTimerLib.c
+  BaseCpuTimerLib.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  UefiCpuPkg/UefiCpuPkg.dec
+
+[LibraryClasses]
+  BaseLib
+  PcdLib
+  DebugLib
+
+[Pcd]
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuCoreCrystalClockFrequency  ## CONSUMES
diff --git a/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni 
b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni
new file mode 100644
index 00..fcf2b0fbcb
--- /dev/null
+++ b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni
@@ -0,0 +1,17 @@
+// /** @file
+// Base CPU Timer Library
+//
+// Provides basic timer support using CPUID Leaf 0x15 XTAL frequency.  The 
performance
+// counter features are provided by the processors time stamp counter.
+//
+// Copyright (c) 2019, Intel Corporation. All rights reserved.
+//
+// SPDX-License-Identifier: BSD-2-Clause-Patent
+//
+// **/
+
+
+#string STR_MODULE_ABSTRACT #language en-US "CPU Timer Library"
+
+#string STR_MODULE_DESCRIPTION  #language en-US "Provides basic timer 
support using CPUID Leaf 0x15 XTAL frequency."
+
diff --git a/UefiCpuPkg/Library/CpuTimerLib/CpuTimerLib.c

Re: [edk2-devel] [PATCH 1/1] CryptoPkg/BaseCryptLib: Update pHkdfCtx to PHkdfCtx

Shenglei,

I remember the edk2 coding style allows prefix 'p' (optional) to represent a 
pointer variable.

Regards,
Jian


> -Original Message-
> From: Zhang, Shenglei
> Sent: Thursday, August 15, 2019 4:49 PM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J ; Ye, Ting 
> Subject: [PATCH 1/1] CryptoPkg/BaseCryptLib: Update pHkdfCtx to
> PHkdfCtx
> 
> Update pHkdfCtx to PHkdfCtx, to follow the variable naming
> rule.
> 
> Cc: Jian Wang 
> Cc: Ting Ye 
> Signed-off-by: Shenglei Zhang 
> ---
>  .../Library/BaseCryptLib/Kdf/CryptHkdf.c  | 22 +--
>  1 file changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdf.c
> b/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdf.c
> index f0fcef211d3f..488346a38b8c 100644
> --- a/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdf.c
> +++ b/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdf.c
> @@ -39,7 +39,7 @@ HkdfSha256ExtractAndExpand (
>IN   UINTNOutSize
>)
>  {
> -  EVP_PKEY_CTX *pHkdfCtx;
> +  EVP_PKEY_CTX *PHkdfCtx;
>BOOLEAN Result;
> 
>if (Key == NULL || Salt == NULL || Info == NULL || Out == NULL ||
> @@ -47,29 +47,29 @@ HkdfSha256ExtractAndExpand (
>  return FALSE;
>}
> 
> -  pHkdfCtx = EVP_PKEY_CTX_new_id(EVP_PKEY_HKDF, NULL);
> -  if (pHkdfCtx == NULL) {
> +  PHkdfCtx = EVP_PKEY_CTX_new_id(EVP_PKEY_HKDF, NULL);
> +  if (PHkdfCtx == NULL) {
>  return FALSE;
>}
> 
> -  Result = EVP_PKEY_derive_init(pHkdfCtx) > 0;
> +  Result = EVP_PKEY_derive_init(PHkdfCtx) > 0;
>if (Result) {
> -Result = EVP_PKEY_CTX_set_hkdf_md(pHkdfCtx, EVP_sha256()) > 0;
> +Result = EVP_PKEY_CTX_set_hkdf_md(PHkdfCtx, EVP_sha256()) > 0;
>}
>if (Result) {
> -Result = EVP_PKEY_CTX_set1_hkdf_salt(pHkdfCtx, Salt,
> (UINT32)SaltSize) > 0;
> +Result = EVP_PKEY_CTX_set1_hkdf_salt(PHkdfCtx, Salt,
> (UINT32)SaltSize) > 0;
>}
>if (Result) {
> -Result = EVP_PKEY_CTX_set1_hkdf_key(pHkdfCtx, Key,
> (UINT32)KeySize) > 0;
> +Result = EVP_PKEY_CTX_set1_hkdf_key(PHkdfCtx, Key,
> (UINT32)KeySize) > 0;
>}
>if (Result) {
> -Result = EVP_PKEY_CTX_add1_hkdf_info(pHkdfCtx, Info,
> (UINT32)InfoSize) > 0;
> +Result = EVP_PKEY_CTX_add1_hkdf_info(PHkdfCtx, Info,
> (UINT32)InfoSize) > 0;
>}
>if (Result) {
> -Result = EVP_PKEY_derive(pHkdfCtx, Out, ) > 0;
> +Result = EVP_PKEY_derive(PHkdfCtx, Out, ) > 0;
>}
> 
> -  EVP_PKEY_CTX_free(pHkdfCtx);
> -  pHkdfCtx = NULL;
> +  EVP_PKEY_CTX_free(PHkdfCtx);
> +  PHkdfCtx = NULL;
>return Result;
>  }
> --
> 2.18.0.windows.1


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

View/Reply Online (#45706): https://edk2.groups.io/g/devel/message/45706
Mute This Topic: https://groups.io/mt/32884778/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v5 22/35] OvmfPkg/XenPlatformPei: no hvmloader: get the E820 table via hypercall

On 08/13/19 13:31, Anthony PERARD wrote:
> When the Xen PVH entry point has been used, hvmloader hasn't run and
> hasn't prepared an E820 table. The only way left to get an E820 table
> is to ask Xen via an hypercall.  We keep the result cached to avoid
> making a second hypercall which would give the same result.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
> Signed-off-by: Anthony PERARD 
> Acked-by: Laszlo Ersek 
> ---
> 
> Notes:
> v5:
> - fix commit message, the hypercall *can* be made several time, but we
>   still cache the result.

Addresses Roger's feedback in:

http://mid.mail-archive.com/20190808104558.vm6dfic5dntjsnt4@Air-de-Roger
https://edk2.groups.io/g/devel/message/45160

My ACK stands.

Thanks
Laszlo


> v3:
> - fix commit message
> - add 'm' prefix to the global variables
>   and make them static
> 
>  OvmfPkg/XenPlatformPei/Xen.c | 46 +++-
>  1 file changed, 45 insertions(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index f26f0e56dd..72f6f37b46 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "Platform.h"
>  #include "Xen.h"
> @@ -40,6 +41,8 @@ EFI_XEN_INFO mXenInfo;
>  // Only the E820 table is used by OVMF.
>  //
>  EFI_XEN_OVMF_INFO *mXenHvmloaderInfo;
> +STATIC EFI_E820_ENTRY64 mE820Entries[128];
> +STATIC UINT32 mE820EntriesCount;
>  
>  /**
>Returns E820 map provided by Xen
> @@ -55,6 +58,12 @@ XenGetE820Map (
>UINT32 *Count
>)
>  {
> +  INTN ReturnCode;
> +  xen_memory_map_t Parameters;
> +  UINTN LoopIndex;
> +  UINTN Index;
> +  EFI_E820_ENTRY64 TmpEntry;
> +
>//
>// Get E820 produced by hvmloader
>//
> @@ -66,7 +75,42 @@ XenGetE820Map (
>  return EFI_SUCCESS;
>}
>  
> -  return EFI_NOT_FOUND;
> +  //
> +  // Otherwise, get the E820 table from the Xen hypervisor
> +  //
> +
> +  if (mE820EntriesCount > 0) {
> +*Entries = mE820Entries;
> +*Count = mE820EntriesCount;
> +return EFI_SUCCESS;
> +  }
> +
> +  Parameters.nr_entries = 128;
> +  set_xen_guest_handle (Parameters.buffer, mE820Entries);
> +
> +  // Returns a errno
> +  ReturnCode = XenHypercallMemoryOp (XENMEM_memory_map, );
> +  ASSERT (ReturnCode == 0);
> +
> +  mE820EntriesCount = Parameters.nr_entries;
> +
> +  //
> +  // Sort E820 entries
> +  //
> +  for (LoopIndex = 1; LoopIndex < mE820EntriesCount; LoopIndex++) {
> +for (Index = LoopIndex; Index < mE820EntriesCount; Index++) {
> +  if (mE820Entries[Index - 1].BaseAddr > mE820Entries[Index].BaseAddr) {
> +TmpEntry = mE820Entries[Index];
> +mE820Entries[Index] = mE820Entries[Index - 1];
> +mE820Entries[Index - 1] = TmpEntry;
> +  }
> +}
> +  }
> +
> +  *Count = mE820EntriesCount;
> +  *Entries = mE820Entries;
> +
> +  return EFI_SUCCESS;
>  }
>  
>  /**
> 


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

View/Reply Online (#45705): https://edk2.groups.io/g/devel/message/45705
Mute This Topic: https://groups.io/mt/32851694/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] CryptoPkg/OpensslLib: Add missing header files in INF file



Reviewed-by: Jian J Wang 

> -Original Message-
> From: Zhang, Shenglei
> Sent: Tuesday, August 13, 2019 4:50 PM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J ; Ye, Ting 
> Subject: [PATCH 1/1] CryptoPkg/OpensslLib: Add missing header files in INF
> file
> 
> The header files are used but missing in INF,which causes
> warning message when building them.
> https://bugzilla.tianocore.org/show_bug.cgi?id=2036
> 
> Cc: Jian Wang 
> Cc: Ting Ye 
> Signed-off-by: Shenglei Zhang 
> ---
>  CryptoPkg/Library/OpensslLib/OpensslLib.inf   | 59
> +++
>  .../Library/OpensslLib/OpensslLibCrypto.inf   | 53 -
>  2 files changed, 111 insertions(+), 1 deletion(-)
> 
> diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> index 5f36edeeef3c..7432321fd431 100644
> --- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> +++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> @@ -22,6 +22,8 @@ [Defines]
>  #
> 
>  [Sources]
> +  buildinf.h
> +  rand_pool_noise.h
>$(OPENSSL_PATH)/e_os.h
>  # Autogenerated files list starts here
>$(OPENSSL_PATH)/crypto/aes/aes_cbc.c
> @@ -32,7 +34,9 @@ [Sources]
>$(OPENSSL_PATH)/crypto/aes/aes_misc.c
>$(OPENSSL_PATH)/crypto/aes/aes_ofb.c
>$(OPENSSL_PATH)/crypto/aes/aes_wrap.c
> +  $(OPENSSL_PATH)/crypto/aes/aes_locl.h
>$(OPENSSL_PATH)/crypto/aria/aria.c
> +  $(OPENSSL_PATH)/crypto/arm_arch.h
>$(OPENSSL_PATH)/crypto/asn1/a_bitstr.c
>$(OPENSSL_PATH)/crypto/asn1/a_d2i_fp.c
>$(OPENSSL_PATH)/crypto/asn1/a_digest.c
> @@ -97,12 +101,21 @@ [Sources]
>$(OPENSSL_PATH)/crypto/asn1/x_sig.c
>$(OPENSSL_PATH)/crypto/asn1/x_spki.c
>$(OPENSSL_PATH)/crypto/asn1/x_val.c
> +  $(OPENSSL_PATH)/crypto/asn1/standard_methods.h
> +  $(OPENSSL_PATH)/crypto/asn1/charmap.h
> +  $(OPENSSL_PATH)/crypto/asn1/tbl_standard.h
> +  $(OPENSSL_PATH)/crypto/asn1/asn1_item_list.h
> +  $(OPENSSL_PATH)/crypto/asn1/asn1_locl.h
>$(OPENSSL_PATH)/crypto/async/arch/async_null.c
>$(OPENSSL_PATH)/crypto/async/arch/async_posix.c
>$(OPENSSL_PATH)/crypto/async/arch/async_win.c
>$(OPENSSL_PATH)/crypto/async/async.c
>$(OPENSSL_PATH)/crypto/async/async_err.c
>$(OPENSSL_PATH)/crypto/async/async_wait.c
> +  $(OPENSSL_PATH)/crypto/async/arch/async_win.h
> +  $(OPENSSL_PATH)/crypto/async/async_locl.h
> +  $(OPENSSL_PATH)/crypto/async/arch/async_posix.h
> +  $(OPENSSL_PATH)/crypto/async/arch/async_null.h
>$(OPENSSL_PATH)/crypto/bio/b_addr.c
>$(OPENSSL_PATH)/crypto/bio/b_dump.c
>$(OPENSSL_PATH)/crypto/bio/b_sock.c
> @@ -125,6 +138,7 @@ [Sources]
>$(OPENSSL_PATH)/crypto/bio/bss_mem.c
>$(OPENSSL_PATH)/crypto/bio/bss_null.c
>$(OPENSSL_PATH)/crypto/bio/bss_sock.c
> +  $(OPENSSL_PATH)/crypto/bio/bio_lcl.h
>$(OPENSSL_PATH)/crypto/bn/bn_add.c
>$(OPENSSL_PATH)/crypto/bn/bn_asm.c
>$(OPENSSL_PATH)/crypto/bn/bn_blind.c
> @@ -156,6 +170,9 @@ [Sources]
>$(OPENSSL_PATH)/crypto/bn/bn_srp.c
>$(OPENSSL_PATH)/crypto/bn/bn_word.c
>$(OPENSSL_PATH)/crypto/bn/bn_x931p.c
> +  $(OPENSSL_PATH)/crypto/bn/rsaz_exp.h
> +  $(OPENSSL_PATH)/crypto/bn/bn_prime.h
> +  $(OPENSSL_PATH)/crypto/bn/bn_lcl.h
>$(OPENSSL_PATH)/crypto/buffer/buf_err.c
>$(OPENSSL_PATH)/crypto/buffer/buffer.c
>$(OPENSSL_PATH)/crypto/cmac/cm_ameth.c
> @@ -164,6 +181,7 @@ [Sources]
>$(OPENSSL_PATH)/crypto/comp/c_zlib.c
>$(OPENSSL_PATH)/crypto/comp/comp_err.c
>$(OPENSSL_PATH)/crypto/comp/comp_lib.c
> +  $(OPENSSL_PATH)/crypto/comp/comp_lcl.h
>$(OPENSSL_PATH)/crypto/conf/conf_api.c
>$(OPENSSL_PATH)/crypto/conf/conf_def.c
>$(OPENSSL_PATH)/crypto/conf/conf_err.c
> @@ -172,6 +190,8 @@ [Sources]
>$(OPENSSL_PATH)/crypto/conf/conf_mod.c
>$(OPENSSL_PATH)/crypto/conf/conf_sap.c
>$(OPENSSL_PATH)/crypto/conf/conf_ssl.c
> +  $(OPENSSL_PATH)/crypto/conf/conf_lcl.h
> +  $(OPENSSL_PATH)/crypto/conf/conf_def.h
>$(OPENSSL_PATH)/crypto/cpt_err.c
>$(OPENSSL_PATH)/crypto/cryptlib.c
>$(OPENSSL_PATH)/crypto/ctype.c
> @@ -195,6 +215,8 @@ [Sources]
>$(OPENSSL_PATH)/crypto/des/set_key.c
>$(OPENSSL_PATH)/crypto/des/str2key.c
>$(OPENSSL_PATH)/crypto/des/xcbc_enc.c
> +  $(OPENSSL_PATH)/crypto/des/spr.h
> +  $(OPENSSL_PATH)/crypto/des/des_locl.h
>$(OPENSSL_PATH)/crypto/dh/dh_ameth.c
>$(OPENSSL_PATH)/crypto/dh/dh_asn1.c
>$(OPENSSL_PATH)/crypto/dh/dh_check.c
> @@ -209,6 +231,7 @@ [Sources]
>$(OPENSSL_PATH)/crypto/dh/dh_prn.c
>$(OPENSSL_PATH)/crypto/dh/dh_rfc5114.c
>$(OPENSSL_PATH)/crypto/dh/dh_rfc7919.c
> +  $(OPENSSL_PATH)/crypto/dh/dh_locl.h
>$(OPENSSL_PATH)/crypto/dso/dso_dl.c
>$(OPENSSL_PATH)/crypto/dso/dso_dlfcn.c
>$(OPENSSL_PATH)/crypto/dso/dso_err.c
> @@ -216,6 +239,7 @@ [Sources]
>$(OPENSSL_PATH)/crypto/dso/dso_openssl.c
>$(OPENSSL_PATH)/crypto/dso/dso_vms.c
>$(OPENSSL_PATH)/crypto/dso/dso_win32.c
> +  $(OPENSSL_PATH)/crypto/dso/dso_locl.h
>$(OPENSSL_PATH)/crypto/ebcdic.c
>$(OPENSSL_PATH)/crypto/err/err.c
>

Re: [edk2-devel] [PATCH v5 20/35] OvmfPkg/XenPlatformPei: Introduce XenPvhDetected

On 08/13/19 13:31, Anthony PERARD wrote:
> XenPvhDetected() can be used to figure out if OVMF has started via the
> Xen PVH entry point.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
> Signed-off-by: Anthony PERARD 
> Acked-by: Laszlo Ersek 
> ---
> 
> Notes:
> v5:
> - in XenPvhDetected, check mXenInfo.HyperPages instead of .VersionMajor

Right, and that seems to address

http://mid.mail-archive.com/20190808104354.wcl2vicpmvbl3rlz@Air-de-Roger
https://edk2.groups.io/g/devel/message/45159

So my ACK stands.

Thanks
Laszlo

>  OvmfPkg/XenPlatformPei/Platform.h |  5 +
>  OvmfPkg/XenPlatformPei/Xen.c  | 13 +
>  2 files changed, 18 insertions(+)
> 
> diff --git a/OvmfPkg/XenPlatformPei/Platform.h 
> b/OvmfPkg/XenPlatformPei/Platform.h
> index 4a80057bdc..db9a62572f 100644
> --- a/OvmfPkg/XenPlatformPei/Platform.h
> +++ b/OvmfPkg/XenPlatformPei/Platform.h
> @@ -99,6 +99,11 @@ XenHvmloaderDetected (
>VOID
>);
>  
> +BOOLEAN
> +XenPvhDetected (
> +  VOID
> +  );
> +
>  VOID
>  AmdSevInitialize (
>VOID
> diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
> index 29b42b746c..f26f0e56dd 100644
> --- a/OvmfPkg/XenPlatformPei/Xen.c
> +++ b/OvmfPkg/XenPlatformPei/Xen.c
> @@ -214,6 +214,19 @@ XenHvmloaderDetected (
>return (mXenHvmloaderInfo != NULL);
>  }
>  
> +BOOLEAN
> +XenPvhDetected (
> +  VOID
> +  )
> +{
> +  //
> +  // This function should only be used after XenConnect
> +  //
> +  ASSERT (mXenInfo.HyperPages != NULL);
> +
> +  return mXenHvmloaderInfo == NULL;
> +}
> +
>  VOID
>  XenPublishRamRegions (
>VOID
> 


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

View/Reply Online (#45703): https://edk2.groups.io/g/devel/message/45703
Mute This Topic: https://groups.io/mt/32851708/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 1/1] CryptoPkg/BaseCryptLib: Update pHkdfCtx to PHkdfCtx

Update pHkdfCtx to PHkdfCtx, to follow the variable naming
rule.

Cc: Jian Wang 
Cc: Ting Ye 
Signed-off-by: Shenglei Zhang 
---
 .../Library/BaseCryptLib/Kdf/CryptHkdf.c  | 22 +--
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdf.c 
b/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdf.c
index f0fcef211d3f..488346a38b8c 100644
--- a/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdf.c
+++ b/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdf.c
@@ -39,7 +39,7 @@ HkdfSha256ExtractAndExpand (
   IN   UINTNOutSize
   )
 {
-  EVP_PKEY_CTX *pHkdfCtx;
+  EVP_PKEY_CTX *PHkdfCtx;
   BOOLEAN Result;
 
   if (Key == NULL || Salt == NULL || Info == NULL || Out == NULL ||
@@ -47,29 +47,29 @@ HkdfSha256ExtractAndExpand (
 return FALSE;
   }
 
-  pHkdfCtx = EVP_PKEY_CTX_new_id(EVP_PKEY_HKDF, NULL);
-  if (pHkdfCtx == NULL) {
+  PHkdfCtx = EVP_PKEY_CTX_new_id(EVP_PKEY_HKDF, NULL);
+  if (PHkdfCtx == NULL) {
 return FALSE;
   }
 
-  Result = EVP_PKEY_derive_init(pHkdfCtx) > 0;
+  Result = EVP_PKEY_derive_init(PHkdfCtx) > 0;
   if (Result) {
-Result = EVP_PKEY_CTX_set_hkdf_md(pHkdfCtx, EVP_sha256()) > 0;
+Result = EVP_PKEY_CTX_set_hkdf_md(PHkdfCtx, EVP_sha256()) > 0;
   }
   if (Result) {
-Result = EVP_PKEY_CTX_set1_hkdf_salt(pHkdfCtx, Salt, (UINT32)SaltSize) > 0;
+Result = EVP_PKEY_CTX_set1_hkdf_salt(PHkdfCtx, Salt, (UINT32)SaltSize) > 0;
   }
   if (Result) {
-Result = EVP_PKEY_CTX_set1_hkdf_key(pHkdfCtx, Key, (UINT32)KeySize) > 0;
+Result = EVP_PKEY_CTX_set1_hkdf_key(PHkdfCtx, Key, (UINT32)KeySize) > 0;
   }
   if (Result) {
-Result = EVP_PKEY_CTX_add1_hkdf_info(pHkdfCtx, Info, (UINT32)InfoSize) > 0;
+Result = EVP_PKEY_CTX_add1_hkdf_info(PHkdfCtx, Info, (UINT32)InfoSize) > 0;
   }
   if (Result) {
-Result = EVP_PKEY_derive(pHkdfCtx, Out, ) > 0;
+Result = EVP_PKEY_derive(PHkdfCtx, Out, ) > 0;
   }
 
-  EVP_PKEY_CTX_free(pHkdfCtx);
-  pHkdfCtx = NULL;
+  EVP_PKEY_CTX_free(PHkdfCtx);
+  PHkdfCtx = NULL;
   return Result;
 }
-- 
2.18.0.windows.1


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

View/Reply Online (#45702): https://edk2.groups.io/g/devel/message/45702
Mute This Topic: https://groups.io/mt/32884778/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] CryptoPkg/OpensslLib: Add missing header files in INF file

Reviewed-by: Liming Gao 

>-Original Message-
>From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>Zhang, Shenglei
>Sent: Tuesday, August 13, 2019 4:50 PM
>To: devel@edk2.groups.io
>Cc: Wang, Jian J ; Ye, Ting 
>Subject: [edk2-devel] [PATCH 1/1] CryptoPkg/OpensslLib: Add missing header
>files in INF file
>
>The header files are used but missing in INF,which causes
>warning message when building them.
>https://bugzilla.tianocore.org/show_bug.cgi?id=2036
>
>Cc: Jian Wang 
>Cc: Ting Ye 
>Signed-off-by: Shenglei Zhang 
>---
> CryptoPkg/Library/OpensslLib/OpensslLib.inf   | 59 +++
> .../Library/OpensslLib/OpensslLibCrypto.inf   | 53 -
> 2 files changed, 111 insertions(+), 1 deletion(-)
>
>diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
>b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
>index 5f36edeeef3c..7432321fd431 100644
>--- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
>+++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
>@@ -22,6 +22,8 @@ [Defines]
> #
>
> [Sources]
>+  buildinf.h
>+  rand_pool_noise.h
>   $(OPENSSL_PATH)/e_os.h
> # Autogenerated files list starts here
>   $(OPENSSL_PATH)/crypto/aes/aes_cbc.c
>@@ -32,7 +34,9 @@ [Sources]
>   $(OPENSSL_PATH)/crypto/aes/aes_misc.c
>   $(OPENSSL_PATH)/crypto/aes/aes_ofb.c
>   $(OPENSSL_PATH)/crypto/aes/aes_wrap.c
>+  $(OPENSSL_PATH)/crypto/aes/aes_locl.h
>   $(OPENSSL_PATH)/crypto/aria/aria.c
>+  $(OPENSSL_PATH)/crypto/arm_arch.h
>   $(OPENSSL_PATH)/crypto/asn1/a_bitstr.c
>   $(OPENSSL_PATH)/crypto/asn1/a_d2i_fp.c
>   $(OPENSSL_PATH)/crypto/asn1/a_digest.c
>@@ -97,12 +101,21 @@ [Sources]
>   $(OPENSSL_PATH)/crypto/asn1/x_sig.c
>   $(OPENSSL_PATH)/crypto/asn1/x_spki.c
>   $(OPENSSL_PATH)/crypto/asn1/x_val.c
>+  $(OPENSSL_PATH)/crypto/asn1/standard_methods.h
>+  $(OPENSSL_PATH)/crypto/asn1/charmap.h
>+  $(OPENSSL_PATH)/crypto/asn1/tbl_standard.h
>+  $(OPENSSL_PATH)/crypto/asn1/asn1_item_list.h
>+  $(OPENSSL_PATH)/crypto/asn1/asn1_locl.h
>   $(OPENSSL_PATH)/crypto/async/arch/async_null.c
>   $(OPENSSL_PATH)/crypto/async/arch/async_posix.c
>   $(OPENSSL_PATH)/crypto/async/arch/async_win.c
>   $(OPENSSL_PATH)/crypto/async/async.c
>   $(OPENSSL_PATH)/crypto/async/async_err.c
>   $(OPENSSL_PATH)/crypto/async/async_wait.c
>+  $(OPENSSL_PATH)/crypto/async/arch/async_win.h
>+  $(OPENSSL_PATH)/crypto/async/async_locl.h
>+  $(OPENSSL_PATH)/crypto/async/arch/async_posix.h
>+  $(OPENSSL_PATH)/crypto/async/arch/async_null.h
>   $(OPENSSL_PATH)/crypto/bio/b_addr.c
>   $(OPENSSL_PATH)/crypto/bio/b_dump.c
>   $(OPENSSL_PATH)/crypto/bio/b_sock.c
>@@ -125,6 +138,7 @@ [Sources]
>   $(OPENSSL_PATH)/crypto/bio/bss_mem.c
>   $(OPENSSL_PATH)/crypto/bio/bss_null.c
>   $(OPENSSL_PATH)/crypto/bio/bss_sock.c
>+  $(OPENSSL_PATH)/crypto/bio/bio_lcl.h
>   $(OPENSSL_PATH)/crypto/bn/bn_add.c
>   $(OPENSSL_PATH)/crypto/bn/bn_asm.c
>   $(OPENSSL_PATH)/crypto/bn/bn_blind.c
>@@ -156,6 +170,9 @@ [Sources]
>   $(OPENSSL_PATH)/crypto/bn/bn_srp.c
>   $(OPENSSL_PATH)/crypto/bn/bn_word.c
>   $(OPENSSL_PATH)/crypto/bn/bn_x931p.c
>+  $(OPENSSL_PATH)/crypto/bn/rsaz_exp.h
>+  $(OPENSSL_PATH)/crypto/bn/bn_prime.h
>+  $(OPENSSL_PATH)/crypto/bn/bn_lcl.h
>   $(OPENSSL_PATH)/crypto/buffer/buf_err.c
>   $(OPENSSL_PATH)/crypto/buffer/buffer.c
>   $(OPENSSL_PATH)/crypto/cmac/cm_ameth.c
>@@ -164,6 +181,7 @@ [Sources]
>   $(OPENSSL_PATH)/crypto/comp/c_zlib.c
>   $(OPENSSL_PATH)/crypto/comp/comp_err.c
>   $(OPENSSL_PATH)/crypto/comp/comp_lib.c
>+  $(OPENSSL_PATH)/crypto/comp/comp_lcl.h
>   $(OPENSSL_PATH)/crypto/conf/conf_api.c
>   $(OPENSSL_PATH)/crypto/conf/conf_def.c
>   $(OPENSSL_PATH)/crypto/conf/conf_err.c
>@@ -172,6 +190,8 @@ [Sources]
>   $(OPENSSL_PATH)/crypto/conf/conf_mod.c
>   $(OPENSSL_PATH)/crypto/conf/conf_sap.c
>   $(OPENSSL_PATH)/crypto/conf/conf_ssl.c
>+  $(OPENSSL_PATH)/crypto/conf/conf_lcl.h
>+  $(OPENSSL_PATH)/crypto/conf/conf_def.h
>   $(OPENSSL_PATH)/crypto/cpt_err.c
>   $(OPENSSL_PATH)/crypto/cryptlib.c
>   $(OPENSSL_PATH)/crypto/ctype.c
>@@ -195,6 +215,8 @@ [Sources]
>   $(OPENSSL_PATH)/crypto/des/set_key.c
>   $(OPENSSL_PATH)/crypto/des/str2key.c
>   $(OPENSSL_PATH)/crypto/des/xcbc_enc.c
>+  $(OPENSSL_PATH)/crypto/des/spr.h
>+  $(OPENSSL_PATH)/crypto/des/des_locl.h
>   $(OPENSSL_PATH)/crypto/dh/dh_ameth.c
>   $(OPENSSL_PATH)/crypto/dh/dh_asn1.c
>   $(OPENSSL_PATH)/crypto/dh/dh_check.c
>@@ -209,6 +231,7 @@ [Sources]
>   $(OPENSSL_PATH)/crypto/dh/dh_prn.c
>   $(OPENSSL_PATH)/crypto/dh/dh_rfc5114.c
>   $(OPENSSL_PATH)/crypto/dh/dh_rfc7919.c
>+  $(OPENSSL_PATH)/crypto/dh/dh_locl.h
>   $(OPENSSL_PATH)/crypto/dso/dso_dl.c
>   $(OPENSSL_PATH)/crypto/dso/dso_dlfcn.c
>   $(OPENSSL_PATH)/crypto/dso/dso_err.c
>@@ -216,6 +239,7 @@ [Sources]
>   $(OPENSSL_PATH)/crypto/dso/dso_openssl.c
>   $(OPENSSL_PATH)/crypto/dso/dso_vms.c
>   $(OPENSSL_PATH)/crypto/dso/dso_win32.c
>+  $(OPENSSL_PATH)/crypto/dso/dso_locl.h
>   $(OPENSSL_PATH)/crypto/ebcdic.c
>   $(OPENSSL_PATH)/crypto/err/err.c
>   $(OPENSSL_PATH)/crypto/err/err_prn.c
>@@ -280,11

Re: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by using CPUID(0x15) TSC leaf

2019-08-15 Thread Donald Kuo

Hi Vitaly,

Appreciated for reviewing very detail. And looks your captured some piece of 
code is older version. And should be ok, I do got your point.

Item #1

-  I do missed RegEax error handling in case for 
CpuidCoreClockCalculateTscFrequency () should return 0 and EFI_UNSUPPORTED. AR: 
Will update it.

Item #2:

-  Actually the information is from SDM Table 18-85

o   As we know CPUID signature could be hard to identify processor XTAL 
frequency is? So we only check CPUID Leaf 0x15

o   And the PCD will be defined depends on platform specific and during project 
early development. Based on SDM, Intel processor for CPUID.15h EAX and EBX is 
enumerated, but ECX could be possible not enumerated. So that is why we based 
on  SDM Table 18-85 to create PCD as below:

§  Intel Xeon Server family: 25MHz

§  Intel Core and Intel Xeon W family: 24MHz

§  Intel Atom : 19.2MHz

§  So regards the “06_55h” might cause the confused, we could review it whether 
remove it??
Item #3:

-  Again, the XTAL frequency is optional and should be define in early 
phase of new project. Default should still use AcpiTimer.

oPlatform / developer owner should well know the CPU generation XTAL 
frequency is? Server / Client / Atom ?

o   For those CPU not supported should still use AcpiTimerLib (default)

Thanks,
Donald

From: vit9696 via [] [mailto:vit9696=protonmail.com@[]]
Sent: Thursday, August 15, 2019 3:20 PM
To: Kuo, Donald ; devel@edk2.groups.io
Subject: Re: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by using 
CPUID(0x15) TSC leaf

Hello,

Thank you for the patch! I reviewed the code and noticed select issues 
explained below.

1. The following construction:

if (RegEbx == 0) {
DEBUG ((DEBUG_ERROR, "The CPU is not capble for Core Crystal Clock Frequency 
!!\n"));
ASSERT (RegEbx != 0);
}

Does not look good to me, and in my opinion, should be written differently:

if (RegEbx == 0 || RegEax == 0) {
DEBUG ((DEBUG_ERROR, "The CPU is not capble for Core Crystal Clock Frequency 
!!\n"));
ASSERT (RegEbx != 0);
  ASSERT (RegEax != 0);
  return 0;
}

The reason for the above code being wrong is potential division by zero below, 
which behaviour is undefined (and in fact unknown due to unspecified interrupt 
table state). Even though the intent is to not permit the use of this library 
on an unsupported platform, runtime checks and assertions are essentially 
NO-OPs, should be separate and not confused. For this to work properly the call 
to CpuidCoreClockCalculateTscFrequency should happen in library constructor 
with EFI_UNSUPPORTED return on CpuidCoreClockCalculateTscFrequency returning 0.

2. The notes about crystal clock frequency for 06_55H CPU signature:
"2500 - Intel Xeon Processor Scalable Family with CPUID signature 
06_55H(25MHz).\n"
# Intel Xeon Processor Scalable Family with CPUID signature 06_55H = 2500 
(25MHz)

are misleading in both this library and Intel SDM. Intel Xeon W processors have 
the same CPUID signature (06_55H), they report 0 crystal clock frequency, and 
their crystal clock frequency is 24 MHz. This should at least be mentioned in 
the lower part mentioning Intel Xeon W Processor Family(24MHz).

Actually, given that many Intel guys are here, I wonder whether anybody knows 
if there is any better approach to distinguish Xeon Scalable CPUs and Xeon W 
CPUs besides using brand string or using marketing frequency from CPUID 16H to 
determine crystal clock frequency (this is what Linux does at the moment)?

3. Intel Atom Denverton with CPUID signature (06_5FH), also known as Goldmont 
X, reports 0 crystal clock frequency as well, and has 25 MHz frequency. This is 
missing from SDM, but once again I believe it should be included in the two 
places from the above to avoid confusion.

Besides these 3 points, honestly, the library itself appears to be very limited 
for anything but embedding it into the firmware with known hardware, which 
already works just fine by defining the PCD. Missing 0 crystal clock frequency 
handling in runtime with hardcoding the PCD value looks very bad, because the 
number of modern Intel CPU models reporting 0 crystal clock frequency and 
having non 24 MHz frequency is quite far from 0. This makes the library 
essentially impossible to use in any UEFI application or third-party product 
even when targeting Skylake+ generation. To resolute this I vote for additional 
detection functionality to be added to the library to obtain crystal clock 
frequency when the CPUID reports 0. The PCD could be the last resort when no 
other method works. My opinion is that this should be resolved prior to merging 
the patch.

Best regards,
Vitaly

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

View/Reply Online (#45699): https://edk2.groups.io/g/devel/message/45699
Mute This Topic: https://groups.io/mt/32839184/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub

Re: [edk2-devel] [edk2-platform patch 1/7] SimicsX58SktPkg: Add CPU Pkg for SimicsX58

Hi David,

Here are my comments:

1. All of the copyright years need to be updated to 2019.
2. Please remove " Contributed-under: TianoCore Contribution Agreement 1.0" 
from your commit message as it is no longer needed.
3. Silicon/Intel/SimicsX58SktPkg/Override/UefiCpuPkg/SecCore/SecMain.c - Please 
fix all the interspersed trailing white-space.
4. Silicon/Intel/SimicsX58SktPkg/SktPei.dsc - line 2 reads like this "Component 
description file for the SkyLake SiPkg PEI drivers.". This is Simics, not Sky 
Lake, please update the comment.
5. Silicon/Intel/SimicsX58SktPkg/SktUefiBootInclude.fdf - lines 10 & 11 - 
please remove the commented out code.

Other than that, looks good! Please send an updated patch.

Thanks,
Nate

-Original Message-
From: Wei, David Y 
Sent: Friday, August 9, 2019 3:47 PM
To: devel@edk2.groups.io
Cc: Wu, Hao A ; Gao, Liming ; Sinha, 
Ankit ; Agyeman, Prince ; 
Kubacki, Michael A ; Desimone, Nathaniel L 
; Kinney, Michael D 
Subject: [edk2-platform patch 1/7] SimicsX58SktPkg: Add CPU Pkg for SimicsX58

Add CPU Pkg for SimicsX58. It is added for simics QSP project support

Cc: Hao Wu 
Cc: Liming Gao 
Cc: Ankit Sinha 
Cc: Agyeman Prince 
Cc: Kubacki Michael A 
Cc: Nate DeSimone 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: David Wei 
---
 .../Override/UefiCpuPkg/SecCore/SecMain.c  | 956 +
 .../SimicsX58SktPkg/Smm/Access/SmmAccess2Dxe.c | 148 
 .../SimicsX58SktPkg/Smm/Access/SmmAccessPei.c  | 353 
 .../SimicsX58SktPkg/Smm/Access/SmramInternal.c | 199 +
 .../Override/UefiCpuPkg/SecCore/Ia32/SecEntry.nasm |  45 +
 .../Override/UefiCpuPkg/SecCore/SecMain.inf|  71 ++
 .../Override/UefiCpuPkg/SecCore/X64/SecEntry.nasm  |  45 +
 Silicon/Intel/SimicsX58SktPkg/SktPei.dsc   |  18 +
 .../Intel/SimicsX58SktPkg/SktPostMemoryInclude.fdf |   9 +
 .../Intel/SimicsX58SktPkg/SktPreMemoryInclude.fdf  |  10 +
 Silicon/Intel/SimicsX58SktPkg/SktSecInclude.fdf|  17 +
 .../Intel/SimicsX58SktPkg/SktUefiBootInclude.fdf   |  16 +
 .../SimicsX58SktPkg/Smm/Access/SmmAccess2Dxe.inf   |  52 ++
 .../SimicsX58SktPkg/Smm/Access/SmmAccessPei.inf|  64 ++
 .../SimicsX58SktPkg/Smm/Access/SmramInternal.h |  81 ++
 15 files changed, 2084 insertions(+)
 create mode 100644 
Silicon/Intel/SimicsX58SktPkg/Override/UefiCpuPkg/SecCore/SecMain.c
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccess2Dxe.c
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccessPei.c
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmramInternal.c
 create mode 100644 
Silicon/Intel/SimicsX58SktPkg/Override/UefiCpuPkg/SecCore/Ia32/SecEntry.nasm
 create mode 100644 
Silicon/Intel/SimicsX58SktPkg/Override/UefiCpuPkg/SecCore/SecMain.inf
 create mode 100644 
Silicon/Intel/SimicsX58SktPkg/Override/UefiCpuPkg/SecCore/X64/SecEntry.nasm
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/SktPei.dsc
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/SktPostMemoryInclude.fdf
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/SktPreMemoryInclude.fdf
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/SktSecInclude.fdf
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/SktUefiBootInclude.fdf
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccess2Dxe.inf
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccessPei.inf
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmramInternal.h

diff --git 
a/Silicon/Intel/SimicsX58SktPkg/Override/UefiCpuPkg/SecCore/SecMain.c 
b/Silicon/Intel/SimicsX58SktPkg/Override/UefiCpuPkg/SecCore/SecMain.c
new file mode 100644
index 00..c52d459ef2
--- /dev/null
+++ b/Silicon/Intel/SimicsX58SktPkg/Override/UefiCpuPkg/SecCore/SecMain.c
@@ -0,0 +1,956 @@
+/** @file
+  Main SEC phase code.  Transitions to PEI.
+
+  Copyright (c) 2008 - 2015, Intel Corporation. All rights reserved.
+  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define SEC_IDT_ENTRY_COUNT  34
+
+typedef struct _SEC_IDT_TABLE {
+  EFI_PEI_SERVICES  *PeiService;
+  IA32_IDT_GATE_DESCRIPTOR  IdtTable[SEC_IDT_ENTRY_COUNT];
+} SEC_IDT_TABLE;
+
+VOID
+EFIAPI
+SecStartupPhase2 (
+  IN VOID *Context
+  );
+
+EFI_STATUS
+EFIAPI
+TemporaryRamMigration (
+  IN CONST EFI_PEI_SERVICES   **PeiServices,
+  IN EFI_PHYSICAL_ADDRESS TemporaryMemoryBase,
+  IN EFI_PHYSICAL_ADDRESS PermanentMemoryBase,
+  IN UINTNCopySize
+  );
+
+EFI_PEI_TEMPORARY_RAM_SUPPORT_PPI mTemporaryRamSupportPpi = {
+  TemporaryRamMigration
+};
+
+EFI_PEI_PPI_DESCRIPTOR mPrivateDispatchTable[] = {
+  {
+(EFI_PEI_PPI_DESCRIPTOR_PPI |

Re: [edk2-devel] [edk2-non-osi][PATCH V2 2/2] edk2-non-osi: Add CoffeelakeSiliconBinPkg maintainers

2019-08-15 Thread Chaganty, Rangasai V

Reviewed-by: Sai Chaganty 

-Original Message-
From: Kubacki, Michael A 
Sent: Wednesday, August 14, 2019 9:15 PM
To: devel@edk2.groups.io
Cc: Chaganty, Rangasai V ; Chiu, Chasel 
; Desimone, Nathaniel L 
; Kinney, Michael D 
Subject: [edk2-non-osi][PATCH V2 2/2] edk2-non-osi: Add CoffeelakeSiliconBinPkg 
maintainers

Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Michael D Kinney 
Signed-off-by: Michael Kubacki 
---
 Maintainers.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Maintainers.txt b/Maintainers.txt index 9fba131..5759e4c 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -46,6 +46,11 @@ M: Michael Kubacki 
 M: Ankit Sinha 
 M: Nate DeSimone 
 
+Platform/Intel/CoffeelakeSiliconBinPkg
+M: Chasel Chiu 
+M: Michael A Kubacki 
+M: Sai Chaganty 
+
 Silicon/Intel/KabylakeSiliconBinPkg
 M: Chasel Chiu 
 M: Michael A Kubacki 
--
2.16.2.windows.1


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

View/Reply Online (#45696): https://edk2.groups.io/g/devel/message/45696
Mute This Topic: https://groups.io/mt/32883415/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/1] MdeModulePkg/DxeIplPeim: Initialize pointer PageMapLevel5Entry

That's fine. Thanks!

>-Original Message-
>From: Wu, Hao A
>Sent: Thursday, August 15, 2019 3:23 PM
>To: Gao, Liming ; Zhang, Shenglei
>; devel@edk2.groups.io
>Cc: Bi, Dandan 
>Subject: RE: [PATCH v2 1/1] MdeModulePkg/DxeIplPeim: Initialize pointer
>PageMapLevel5Entry
>
>> -Original Message-
>> From: Gao, Liming
>> Sent: Thursday, August 15, 2019 10:27 AM
>> To: Zhang, Shenglei; devel@edk2.groups.io
>> Cc: Bi, Dandan; Wu, Hao A
>> Subject: RE: [PATCH v2 1/1] MdeModulePkg/DxeIplPeim: Initialize pointer
>> PageMapLevel5Entry
>>
>> Shenglei:
>>
>> > -Original Message-
>> > From: Zhang, Shenglei
>> > Sent: Thursday, August 15, 2019 10:23 AM
>> > To: devel@edk2.groups.io
>> > Cc: Bi, Dandan ; Gao, Liming
>> ; Wu, Hao A 
>> > Subject: [PATCH v2 1/1] MdeModulePkg/DxeIplPeim: Initialize pointer
>> PageMapLevel5Entry
>> >
>> > Initialize PageMapLevel5Entry at the beginning of the function.
>> >
>> > This commit will fix a GCC 4.8.5 build failure introduced by commit
>> > b3527dedc3951f061c5a73cb4fb2b0f95f47e08b.
>> >
>> > OvmfPkg build failure wtih gcc 4.8.5 still exists at latest edk2 version.
>> > The commit 46f8a6891606746ca8b1e684ac379ce271306dc0 seems not to fix
>> > the build failure completely.
>> >
>> > Cc: Dandan Bi 
>> > Cc: Liming Gao 
>> > Cc: Hao A Wu 
>> > Signed-off-by: Shenglei Zhang 
>> > ---
>> > v2: Add comments to state why set initialize to NULL.
>> >
>> >  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 5 +
>> >  1 file changed, 5 insertions(+)
>> >
>> > diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
>> b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
>> > index 2389f3eb485b..2f1038b1e67e 100644
>> > --- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
>> > +++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
>> > @@ -652,6 +652,11 @@ CreateIdentityMappingPageTables (
>> >UINT64AddressEncMask;
>> >IA32_CR4  Cr4;
>> >
>> > +  //
>> > +  // set PageMapLevel5Entry to suppress incorrect compiler/analyzer
>> warnigns
>>
>> Please fix the typo warnigns ==> warnings
>
>
>Hello Liming,
>
>I will fix the above typo when I push the patch.
>Also, I will keep your RB tag from V1 patch since there is only comment
>change between the two versions.
>
>Best Regards,
>Hao Wu
>
>
>>
>> Thanks
>> Liming
>> > +  //
>> > +  PageMapLevel5Entry = NULL;
>> > +
>> >//
>> >// Make sure AddressEncMask is contained to smallest supported
>address
>> field
>> >//
>> > --
>> > 2.18.0.windows.1


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

View/Reply Online (#45695): https://edk2.groups.io/g/devel/message/45695
Mute This Topic: https://groups.io/mt/32882542/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-non-osi patch 1/1] SimicsICH10SiliconBinPkg: Add UNDI ROM for SIMICS QSP Platform

Hi David,

Please add an .inf file to make it convenient for the platform code to include 
this binary. Please see the following for an example:

edk2-non-osi/Platform/Hisilicon/Drivers/Sm750Dxe/UefiSmi.inf

Also, please add the Maintainers.txt entries and change the package name per my 
previous email. Other than that look's good!

Thanks,
Nate

-Original Message-
From: Wei, David Y 
Sent: Friday, August 9, 2019 3:45 PM
To: devel@edk2.groups.io
Cc: Wu, Hao A ; Gao, Liming ; Sinha, 
Ankit ; Agyeman, Prince ; 
Kubacki, Michael A ; Desimone, Nathaniel L 
; Kinney, Michael D 
Subject: [edk2-non-osi patch 1/1] SimicsICH10SiliconBinPkg: Add UNDI ROM for 
SIMICS QSP Platform

Add UNDI option ROM for SIMICS QSP Network support

Cc: Hao Wu 
Cc: Liming Gao 
Cc: Ankit Sinha 
Cc: Agyeman Prince 
Cc: Kubacki Michael A 
Cc: Nate DeSimone 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: David Wei 
---
 .../UndiBinary/GigUndiDxe.efi  | Bin 0 -> 195360 bytes
 .../UndiBinary/License.txt |  30 +
 2 files changed, 30 insertions(+)
 create mode 100644 
Silicon/Intel/SimicsICH10SiliconBinPkg/UndiBinary/GigUndiDxe.efi
 create mode 100644 
Silicon/Intel/SimicsICH10SiliconBinPkg/UndiBinary/License.txt

diff --git a/Silicon/Intel/SimicsICH10SiliconBinPkg/UndiBinary/GigUndiDxe.efi 
b/Silicon/Intel/SimicsICH10SiliconBinPkg/UndiBinary/GigUndiDxe.efi
new file mode 100644
index 
..7b8e0d7be00dccedb84ebed5c5c87a0e79078983
GIT binary patch
literal 195360
zcmc$Hdwf*Ywg1dyCK({%1SJ>|F>2IQe5A%|VtmYj37nA$hL>V}rD~_NYNap(u~41i
zBqWpLC|+!}y=|pe+hVmX)+))U7Ez9K|re&6rjXC49U@AJF=
z{AkVDkG0ocd+oi~UVH7e_tbvZ_P_qO@qbK
zzafaC51`F#C)=LgUSch=*%qI3^Y?<^Ls;uZTyfaytuOOa|2#HZUn;!#c<^lxa9Q6}
zI=>#9ZTdM465(fKk?=k$Ce!%M`sX3s((m7T`%N~{b{lw50v_<2{f}@%(~z-i*Dfu3
zZK?YzO@F^cGhWk-gXRoCYKH6LPKV7O^OkzFSkV%+Q8W6JYabMOBC%j|GMUtj7qzIi
z2zlnSBJ0}Ha!r4>NbV2~3(0kJzw^EWbcODglv*_mOP`O8%1T2z-Vd6Ue%
zJC&)UBxo+vlIsQTsK3-bAJi`a6E2jnOGqxb6D?RH2rp>nCswo*#Ip^_!w1&%Mkw892qV_V}7)STu9T{jt+~gbdR+;Y)el^
z_H1N>oL#9l6~#R$8@szS48W{%jB18V_Qx7aTSVNIkK!P`21NCGOUpRm{Kj@Np#-Ii
zC1)CDYKB!JR`4gJfqSU)E27{yin*TKWf82#<`#mgr=D@xI_$uftg8cS8(d}{f%RvX
zT!S%|HFjMFAb~50PrM#5vCAJx)_E#0M)!(7xtryTf(6KrT~%LG(P=*Qh#e`e=}6h2
z1l^iGxL?yd3wu1y613z8t4LH`p%&9zo|Y<4>#M!Clj|1M^m=j~wwyvwOT)NcPyWbr
zHczjo7`W}do+))ReDl1@CXW+?`K_lNwm?ld}Q0+)2fi2k?sLAOHeN;9ZfAEmp7ObZjm7B`{PB8*emj5B|vb(jWWIhHi(=XE+Z9sy1GGn#~rR
z4cgd}xDBi{=S;LAH~$b4G`*`nUUv-=tE@z(m@SjY0@wF|x1;b3_UZu;-da$Ogk-m}
zsjGVL(qBlrj9_V{W~{>W$8=V&@80D%{_cxj14$8iKa4`Y*or%>&?JvbK7j{-Vbr-d)M3jv$bRLTN|>pujNf|W8?^z}rU(;#zxvV-N8h@27B
z%|Y3K!Rl)8%fYq;GxMy=IDTEf%?soJ)%_nwHB{#R9CyxOnSQ0r)sSoWdxyWVQ@r
z?z$Ebft<9i7M4cXgY;FG$S`MXodwU?db0)3*;;AAm!MTo$2nW;L__*G@@F9NAtXi`
z|6$Geb?I7iAo6S)n(?d_U4((R
zq?oI~62IXq^T#~yUe87@x0*46Nw7gPK1OwAs16+XcBHRrD;3DN}Ip*ytogwD{WnYY1;z&
z0jIL&&{Clbu+(Vxkszbppfp^6i@P@HS;NWl_8TTQ*yux-WQV+)TN`^)E8f$4KsB`0bt^aExeMs)8emW=bpZz(AS=Ksm;@XdVR{n
zolD2I|M?A3d%NZ@7lRdT=aRjeas_VnOT|y;CB(wc8)NwseWlxTe@=EGzLDZ;Ae(
zOrtC))}jka3m0AmX<)o>%{pLw1Q`9Xn!$=;Oh0u?@wdtDkf|E4#O635@KQWJ4XT=E
z)DEH>kY{dx$PNl>20_eH5QCgDU!=2T8i8DO#A#enM!_vQ9cy4oT4*aRlO-;UiLbaUZ)xJG;=&=j+OCs5Z8nq6*L
z2gk=nQkwMI>gJXIK(M9Pr@Nr?c39I?Qr$?VdF@_X7G
z`90k$zi0UP1)CRTScieHLMYZ^q9Ds~wLOIePwy;GwM4Gu?~B<3fLOtFEQ1iQgAU8;3Qk*i`Ai0Z)sg^tggJ)@KA(z)exJ|
zyIeIhW!QuCZ&_iA@DDCz`T{CkMH4C|4EW-5fnq<>F@30MC9YsC8fuZqt;OI5s|I3v
z%L;Qb=(WPcwE4ef4JD}Iuc_4@?XZ(cLlE-_DoIX{=}wiu+?x4mV%a4t+7
zn?fSy`o4@6GKS%SI<7(;$+cmDOY(ND2xD%>Y7S5`UcoRR?}1XXG*caoqDLINa|
zS%O0JSZx{fI4BMa2Ql30H6zl%=?Nw1m>Q!8f}k>fA+RI|2%)sqRCas~y(pkg>j_|>
z|Dv;H^?9Ypt7QK=pj)l=T*_4u=*%%DpUwxofbVG6W8^?lU&&`bzLEZTD3f=
zO1bKpyIZt8Ws~Ogw)Xgqz5vvR!WxG?P93Z^XLlfHM`*vd%;P##a3M;u3Bc~ZfI(Lc
zQlPi`jag`y6w@O65}AGak=c;qzb*}fObBua@nz)@sJ!oQpdnV&^{Ds9;xnL22`VTrs)f98{g;G#
z3{ZY!28!<1jNKA!s2CtV{eXSBl3DbJa*!yO_0xVKn{fkBPlhgE1%!=Mx
zs`WesAyg2K3y>kTp+p6XYofRZ#c#2SSF(6Hi>C{D(uK0badlTn
zV5kHydr5Px0p$rT;~tnhFT>?VIZ{+clqIrStF56Ewb=4;cT#c;R4nA(m}B1#
zhkWyTwi`2Lp{8%$fH2j2eQUc2sR(Tpp$j$RfyIQRLgg0Ah@}P_8wJA$M5bW)P(_O2
z2?thP4xt0A+HlBHvHo~?
z4I$PLyW#+9pte;nC+RI^n5dOvqN>;4(4F3YLFZakTCz~RQoV{wm;Qd84@XWVJFaP?iG-0(_!GB`$Q
zo8i!M_9ou-oQshaPrP6IESGr5dH}4PR8L
zMK?^;s&@yK8txijF@5)QDTV@PL8*)NZp+GEm8aasx%e-1_270Sso7SsM>o;ssd*a*7J*G7WJFynKmh95>kL;oS
ziOI`~fh$MTyK|VglX=+PGY`B0XThnI_**GBdxLttkby?gzCUxc?ZI#fo!dG+udy@e
zI@H%P9U^+VQ*GVhH?{>Z?k|;_WYyvJVV|sGpZr-qZ+XzSuy;K*oPbYe8x7Pv8UG9W*iE5tDjdIq21UZ)M6)=0yf~S
zGHwJfLvvac;On7l^on@#`5sLBw+zuSYyM9UK1bp<)P##IYh+fZc7v&7h`u
zd$lA4N59tfrW57zk7v!Hb+y~(bb-NSOeAOet_qCj)=PJ2Ayqy$5^W
zoIQxX=uQ;)0K7=c=|r>}^DhY*5#3CA;E(C`V&)g+e48V_U`iC?!07LR7_^++$
zy19DZvj`Vuq#3Z~~GoClkTaC(_UJvDI(Q_+06O~%iaPV82F~1N(
zcxE|>t=>z!4MJjjv|G8qvjtR}drZ4+^yc*_avf*fWP}o3<;B{~)PN
zdz3~>H@{KPdoCH_F?&6Oh0HQ`Vw1ZU>&(n^D6L$VJx0kXwznNHpzvQ9s(A2hu>Bb4~~Pppjw1*4!A@F+bVpY)PTa|6Uqdev>X

[edk2-devel] [PATCH 1/1] UefiCpuPkg/Cpuid: Add description for parameter LeafFunction

LeafFunction needs to be described in comments.
https://bugzilla.tianocore.org/show_bug.cgi?id=2052

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Shenglei Zhang 
---
 UefiCpuPkg/Application/Cpuid/Cpuid.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/UefiCpuPkg/Application/Cpuid/Cpuid.c 
b/UefiCpuPkg/Application/Cpuid/Cpuid.c
index 7a994eba9ac8..f39a7fb33ae5 100644
--- a/UefiCpuPkg/Application/Cpuid/Cpuid.c
+++ b/UefiCpuPkg/Application/Cpuid/Cpuid.c
@@ -708,6 +708,8 @@ CpuidArchitecturalPerformanceMonitoring (
 /**
   Display CPUID_EXTENDED_TOPOLOGY leafs for all supported levels.
 
+  @param[in] LeafFunction  Leaf function index for CPUID_EXTENDED_TOPOLOGY.
+  
 **/
 VOID
 CpuidExtendedTopology (
-- 
2.18.0.windows.1


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

View/Reply Online (#45693): https://edk2.groups.io/g/devel/message/45693
Mute This Topic: https://groups.io/mt/32884640/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 1/1] ShellPkg/UefiShellAcpiViewCommandLib: Replace shift logical left

Replace the operation to shift logical left with the function
LShiftU64, which has the same functionality.
The original code causes ShellPkg build failure with build
target"-b NOOPT".

Cc: Jaben Carsey 
Cc: Ray Ni 
Cc: Zhichao Gao 
Signed-off-by: Shenglei Zhang 
---
 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
index 2d6ff80e299e..2e6d99145beb 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
@@ -290,7 +290,7 @@ DumpUint64 (
 
   Val = *(UINT32*)(Ptr + sizeof (UINT32));
 
-  Val <<= 32;
+  LShiftU64(Val,32);
   Val |= (UINT64)*(UINT32*)Ptr;
 
   Print (Format, Val);
-- 
2.18.0.windows.1


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

View/Reply Online (#45692): https://edk2.groups.io/g/devel/message/45692
Mute This Topic: https://groups.io/mt/32884463/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

2019-08-15 Thread Yao, Jiewen

Acked-by: Jiewen Yao 
Reviewed-by: Jiewen Yao 

From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Vitaly 
Cheptosv via Groups.Io
Sent: Thursday, August 15, 2019 10:22 AM
To: Gao, Liming ; devel@edk2.groups.io; Yao, Jiewen 
; Kinney, Michael D 
Cc: Laszlo Ersek ; leif.lindh...@linaro.org; 
af...@apple.com; Cetola, Stephano 
Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

Liming,

Thank you for adding everyone to the CC list. Yes, I would like this to be 
merged into the next EDK II stable release.

Best regards,
Vitaly

On чт, авг. 15, 2019 at 04:59, Gao, Liming 
mailto:liming@intel.com>> wrote:
Vitaly:
  As you know, edk2 201908 stable tag will start soft freeze tomorrow. Dose 
this patch plan to catch this stable tag?
 If yes, please ask the feedback from Tianocore Stewards. I have cc this patch 
to all Stewards.

Thanks
Liming
From: devel@edk2.groups.io 
[mailto:devel@edk2.groups.io] On Behalf Of Yao, Jiewen
Sent: Thursday, August 15, 2019 9:05 AM
To: devel@edk2.groups.io; 
vit9...@protonmail.com; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Cc: Laszlo Ersek mailto:ler...@redhat.com>>
Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

Good input.
I think we should separate the work to convert all EDKII code to use 
STATIC_ASSERT.
We can do that work once we add STATIC_ASSERT.

I recommend:

1)  Step 1: Add STATIS_ASSERT - this patch and this Bugzilla

2)  Step 2: Convert VERIFY_SIZE_OF to STATIS_ASSERT, and remove 
VERIFY_SIZE_OF – the other patch and the other Bugzilla

3)  Step 3: Scan the rest, if there is need. – Another patch and another 
Bugzilla

Thank you
Yao Jiewen

From: devel@edk2.groups.io 
[mailto:devel@edk2.groups.io] On Behalf Of Vitaly Cheptosv via Groups.Io
Sent: Thursday, August 15, 2019 12:23 AM
To: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Cc: devel@edk2.groups.io; Laszlo Ersek 
mailto:ler...@redhat.com>>
Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

Michael, Liming, Laszlo,

Static assertions via _Static_assert are standard C11 functionality, thus any 
at least C11 (ISO/IEC 9899 2011) conforming compiler is required to support the 
second argument with the diagnostic description.

The notation without the message currently is only present in C++, not in C, 
thus the two-argument notation is the only allowed notation for _Static_assert 
for at least C17 (ISO/IEC 9899 2018) and below.

In the bottom of this message I included a quote from C17 for the relevant 
section (6.7.10).

GCC and CLANG (including Xcode) appear to be conforming to the standard for 
this section, and MSVC compiler static_assert extension also supports the 
diagnostic message argument. This is pretty much all we care about.

As for examples, I see little reason to clarify STATIC_ASSERT behaviour outside 
of the standard reference in its description and actual usage in the source 
code, but can do that just fine if you think that it may help somebody.

I fully agree that VERIFY_SIZE_OF usage should be converted to STATIC_ASSERT, 
and in fact I also suggest VERIFY_SIZE_OF to be entirely removed from Base.h. 
This should be fairly costless, as apparently it is only used in Base.h and 
MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c, which I can replace in the 
same patch set.

As for select ASSERT usage switching to STATIC_ASSERT, this would also be 
great, as let us be honest, the use of ASSERT in EDK II codebase is very 
questioning. In fact, this was one of the reasons we introduced our own static 
assertions some time ago. However, fixing up all broken assertions is unlikely 
a best place to fit into this patchset, but I can surely add a few examples, in 
case somebody points them out. This will be useful for reference purposes and 
may help the maintainers to get a better idea when static assertions are to be 
used.

Looking forward to hearing your opinions.

Best regards,
Vitaly

6.7.10 Static assertions

Syntax
1 static_assert-declaration:
_Static_assert ( constant-expression , string-literal ) ;

Constraints
2 The constant expression shall compare unequal to 0.

Semantics
3 The constant expression shall be an integer constant expression. If the value 
of the constant expression compares unequal to 0, the declaration has no 
effect. Otherwise, the constraint is violated and the implementation shall 
produce a diagnostic message that includes the text of the string literal, 
except that characters not in the basic source character set are not required 
to appear in the message.

Forward references: diagnostics (7.2).

7.2 Diagnostics 

3 The macro
static_assert
expands to _Static_assert.

> 14 авг. 2019 г., в 18:47, Kinney, Michael D 
> mailto:michael.d.kin...@intel.com>> написал(а):
>
>
> Liming,
>
> I think a good candidate

Re: [edk2-devel] [PATCH v2 1/1] MdeModulePkg/DxeIplPeim: Initialize pointer PageMapLevel5Entry

2019-08-15 Thread Wu, Hao A

> -Original Message-
> From: Gao, Liming
> Sent: Thursday, August 15, 2019 10:27 AM
> To: Zhang, Shenglei; devel@edk2.groups.io
> Cc: Bi, Dandan; Wu, Hao A
> Subject: RE: [PATCH v2 1/1] MdeModulePkg/DxeIplPeim: Initialize pointer
> PageMapLevel5Entry
> 
> Shenglei:
> 
> > -Original Message-
> > From: Zhang, Shenglei
> > Sent: Thursday, August 15, 2019 10:23 AM
> > To: devel@edk2.groups.io
> > Cc: Bi, Dandan ; Gao, Liming
> ; Wu, Hao A 
> > Subject: [PATCH v2 1/1] MdeModulePkg/DxeIplPeim: Initialize pointer
> PageMapLevel5Entry
> >
> > Initialize PageMapLevel5Entry at the beginning of the function.
> >
> > This commit will fix a GCC 4.8.5 build failure introduced by commit
> > b3527dedc3951f061c5a73cb4fb2b0f95f47e08b.
> >
> > OvmfPkg build failure wtih gcc 4.8.5 still exists at latest edk2 version.
> > The commit 46f8a6891606746ca8b1e684ac379ce271306dc0 seems not to fix
> > the build failure completely.
> >
> > Cc: Dandan Bi 
> > Cc: Liming Gao 
> > Cc: Hao A Wu 
> > Signed-off-by: Shenglei Zhang 
> > ---
> > v2: Add comments to state why set initialize to NULL.
> >
> >  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> > index 2389f3eb485b..2f1038b1e67e 100644
> > --- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> > +++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> > @@ -652,6 +652,11 @@ CreateIdentityMappingPageTables (
> >UINT64AddressEncMask;
> >IA32_CR4  Cr4;
> >
> > +  //
> > +  // set PageMapLevel5Entry to suppress incorrect compiler/analyzer
> warnigns
> 
> Please fix the typo warnigns ==> warnings


Hello Liming,

I will fix the above typo when I push the patch.
Also, I will keep your RB tag from V1 patch since there is only comment
change between the two versions.

Best Regards,
Hao Wu


> 
> Thanks
> Liming
> > +  //
> > +  PageMapLevel5Entry = NULL;
> > +
> >//
> >// Make sure AddressEncMask is contained to smallest supported address
> field
> >//
> > --
> > 2.18.0.windows.1


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

View/Reply Online (#45690): https://edk2.groups.io/g/devel/message/45690
Mute This Topic: https://groups.io/mt/32882542/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by using CPUID(0x15) TSC leaf

2019-08-15 Thread Vitaly Cheptsov via Groups.Io

Hello,

Thank you for the patch! I reviewed the code and noticed select issues 
explained below.

1. The following construction:

if (RegEbx == 0) {
DEBUG ((DEBUG_ERROR, "The CPU is not capble for Core Crystal Clock Frequency 
!!\n"));
ASSERT (RegEbx != 0);
}

Does not look good to me, and in my opinion, should be written differently:

if (RegEbx == 0 || RegEax == 0 ) {
DEBUG ((DEBUG_ERROR, "The CPU is not capble for Core Crystal Clock Frequency 
!!\n"));
ASSERT (RegEbx != 0);
ASSERT (RegEax != 0);
return 0;
}

The reason for the above code being wrong is potential division by zero below, 
which behaviour is undefined (and in fact unknown due to unspecified interrupt 
table state). Even though the intent is to not permit the use of this library 
on an unsupported platform, runtime checks and assertions are essentially 
NO-OPs, should be separate and not confused. For this to work properly the call 
to CpuidCoreClockCalculateTscFrequency should happen in library constructor 
with EFI_UNSUPPORTED return on CpuidCoreClockCalculateTscFrequency returning 0.

2. The notes about crystal clock frequency for 06_55H CPU signature:
"2500 - Intel Xeon Processor Scalable Family with CPUID signature 
06_55H(25MHz).\n"
# Intel Xeon Processor Scalable Family with CPUID signature 06_55H = 2500 
(25MHz)

are misleading in both this library and Intel SDM. Intel Xeon W processors have 
the same CPUID signature ( 06_55H) , they report 0 crystal clock frequency, and 
their crystal clock frequency is 24 MHz. This should at least be mentioned in 
the lower part mentioning Intel Xeon W Processor Family(24MHz).

Actually, given that many Intel guys are here, I wonder whether anybody knows 
if there is any better approach to distinguish Xeon Scalable CPUs and Xeon W 
CPUs besides using brand string or using marketing frequency from CPUID 16H to 
determine crystal clock frequency (this is what Linux does at the moment)?

3. Intel Atom Denverton with CPUID signature (06_5FH), also known as Goldmont 
X, reports 0 crystal clock frequency as well, and has 25 MHz frequency. This is 
missing from SDM, but once again I believe it should be included in the two 
places from the above to avoid confusion.

Besides these 3 points, honestly, the library itself appears to be very limited 
for anything but embedding it into the firmware with known hardware, which 
already works just fine by defining the PCD. Missing 0 crystal clock frequency 
handling in runtime with hardcoding the PCD value looks very bad, because the 
number of modern Intel CPU models reporting 0 crystal clock frequency and 
having non 24 MHz frequency is quite far from 0. This makes the library 
essentially impossible to use in any UEFI application or third-party product 
even when targeting Skylake+ generation. To resolute this I vote for additional 
detection functionality to be added to the library to obtain crystal clock 
frequency when the CPUID reports 0. The PCD could be the last resort when no 
other method works. My opinion is that this should be resolved prior to merging 
the patch.

Best regards,
Vitaly

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

View/Reply Online (#45689): https://edk2.groups.io/g/devel/message/45689
Mute This Topic: https://groups.io/mt/32839184/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-non-osi][PATCH V2 2/2] edk2-non-osi: Add CoffeelakeSiliconBinPkg maintainers