Re: [edk2-devel] [PATCH v1 1/1] UefiCpuPkg: Remove PEI/DXE instances of CpuTimerLib.

[Laszlo Ersek]

On 09/25/20 07:25, Ni, Ray wrote:
> Reviewed-by: Ray Ni 

Acked-by: Laszlo Ersek 

Thanks
Laszlo

> 
>> -Original Message-
>> From: Lou, Yun 
>> Sent: Friday, September 25, 2020 11:58 AM
>> To: devel@edk2.groups.io
>> Cc: Lou, Yun ; Ni, Ray ; Dong, Eric 
>> ; Laszlo Ersek
>> ; Kumar, Rahul1 
>> Subject: [PATCH v1 1/1] UefiCpuPkg: Remove PEI/DXE instances of CpuTimerLib.
>>
>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2832
>>
>> 1. Remove PEI instance(PeiCpuTimerLib).
>> PeiCpuTimerLib is currently designed to save time by getting CPU TSC 
>> frequncy from Hob.
>> BaseCpuTimerLib is designed to calculate TSC frequency by using CPUID[15h] 
>> each time.
>> The time it takes to find CpuCrystalFrequencyHob (about 2000ns) is much 
>> longer than it takes to
>> calculate TSC frequency with CPUID[15h] (about 450ns), which means using 
>> BaseCpuTimerLib to
>> trigger a delay is more accurate than using PeiCpuTimerLib, recommend to use 
>> BaseCpuTimerLib
>> instead of PeiCpuTimerLib.
>>
>> 2. Remove DXE instance(DxeCpuTimerLib).
>> DxeCpuTimerLib is designed to calculate TSC frequency with CPUID[15h] in its 
>> constructor function,
>> then save it in a global variable. For this design, once the driver 
>> containing this instance is
>> running, the constructor function is called, it will take extra time to 
>> calculate TSC frequency.
>> The time it takes to get TSC frequncy from global variable is shorter than 
>> it takes to calculate
>> TSC frequency with CPUID[15h], but 450ns is a short time, the impact on the 
>> platform is very limited.
>> In addition, in order to simplify the code, recommend to use BaseCpuTimerLib 
>> instead of DxeCpuTimerLib.
>>
>> I did some experiments on one Intel server platform and collected the 
>> following data:
>> 1. Average time taken to find CpuCrystalFrequencyHob: about 2000 ns.
>> 2. Average time taken to calculate TSC frequency: about 450 ns.
>>
>> Reference code:
>> //
>> // Calculate average time taken to find Hob.
>> //
>> DEBUG((DEBUG_ERROR, "[PeiCpuTimerLib] GetPerformanceCounterFrequency - 
>> GetFirstGuidHob (1000 cycles)\n"));
>> Ticks1 = AsmReadTsc();
>> for (i = 0; i < 1000; i++) {
>>   GuidHob = GetFirstGuidHob (&mCpuCrystalFrequencyHobGuid);
>> }
>> Ticks2 = AsmReadTsc();
>>
>> if (GuidHob == NULL) {
>>   DEBUG((DEBUG_ERROR, "[PeiCpuTimerLib]  - CpuCrystalFrequencyHob can 
>> not be found!\n"));
>> } else {
>>   DEBUG((DEBUG_ERROR, "[PeiCpuTimerLib]  - Average time taken to find 
>> Hob = %d ns\n", \
>>   DivU64x32(DivU64x64Remainder(MultU64x32((Ticks2 - Ticks1), 
>> 10), *CpuCrystalCounterFrequency, NULL),
>> 1000)));
>> }
>>
>> //
>> // Calculate average time taken to calculate CPU frequency.
>> //
>> DEBUG((DEBUG_ERROR, "[PeiCpuTimerLib] GetPerformanceCounterFrequency - 
>> CpuidCoreClockCalculateTscFrequency
>> (1000 cycles)\n"));
>> Ticks1 = AsmReadTsc();
>> for (i = 0; i < 1000; i++) {
>>   Freq = CpuidCoreClockCalculateTscFrequency ();
>> }
>> Ticks2 = AsmReadTsc();
>> DEBUG((DEBUG_ERROR, "[PeiCpuTimerLib]  - Average time taken to calculate 
>> TSC frequency = %d ns\n", \
>> DivU64x32(DivU64x64Remainder(MultU64x32((Ticks2 - Ticks1), 
>> 10), *CpuCrystalCounterFrequency, NULL),
>> 1000)));
>>
>> Signed-off-by: Jason Lou 
>> Cc: Ray Ni 
>> Cc: Eric Dong 
>> Cc: Laszlo Ersek 
>> Cc: Rahul Kumar 
>> ---
>>  UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.c   | 85 
>>  UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.c   | 58 -
>>  UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.inf | 37 -
>>  UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.uni | 17 
>>  UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.inf | 36 -
>>  UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.uni | 17 
>>  UefiCpuPkg/UefiCpuPkg.dsc |  4 +-
>>  7 files changed, 1 insertion(+), 253 deletions(-)
>>
>> diff --git a/UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.c 
>> b/UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.c
>> deleted file mode 100644
>> index 269e5a3e83d7..
>> --- a/UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.c
>> +++ /dev/null
>> @@ -1,85 +0,0 @@
>> -/** @file
>>
>> -  CPUID Leaf 0x15 for Core Crystal Clock frequency instance of Timer 
>> Library.
>>
>> -
>>
>> -  Copyright (c) 2019 Intel Corporation. All rights reserved.
>>
>> -  SPDX-License-Identifier: BSD-2-Clause-Patent
>>
>> -
>>
>> -**/
>>
>> -
>>
>> -#include 
>>
>> -#include 
>>
>> -#include 
>>
>> -#include 
>>
>> -
>>
>> -extern GUID mCpuCrystalFrequencyHobGuid;
>>
>> -
>>
>> -/**
>>
>> -  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 n

[edk2-devel][PATCH] EmulatorPkg/Unix Prevents the compiler form optimizing unused variable

[Yu Liu]

gInXcode is only used by GDB script and if optimization is turned on then 
compiler
treats this variable as unused so it can't been linked in the final object.

Signed-off-by: LiuYu 
---
 EmulatorPkg/Unix/Host/Host.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/EmulatorPkg/Unix/Host/Host.c b/EmulatorPkg/Unix/Host/Host.c
index b4e5510613..b851264c8e 100644
--- a/EmulatorPkg/Unix/Host/Host.c
+++ b/EmulatorPkg/Unix/Host/Host.c
@@ -54,7 +54,7 @@ IMAGE_CONTEXT_TO_MOD_HANDLE  *mImageContextModHandleArray = 
NULL;
 EFI_PEI_PPI_DESCRIPTOR  *gPpiList;
 
 
-int gInXcode = 0;
+int gInXcode  __attribute__((used)) = 0;
 

 /*++
-- 
2.20.1



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

Re: [edk2-devel] [PATCH v1 1/1] UefiCpuPkg: Remove PEI/DXE instances of CpuTimerLib.

[Ni, Ray]

Reviewed-by: Ray Ni 

> -Original Message-
> From: Lou, Yun 
> Sent: Friday, September 25, 2020 11:58 AM
> To: devel@edk2.groups.io
> Cc: Lou, Yun ; Ni, Ray ; Dong, Eric 
> ; Laszlo Ersek
> ; Kumar, Rahul1 
> Subject: [PATCH v1 1/1] UefiCpuPkg: Remove PEI/DXE instances of CpuTimerLib.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2832
> 
> 1. Remove PEI instance(PeiCpuTimerLib).
> PeiCpuTimerLib is currently designed to save time by getting CPU TSC frequncy 
> from Hob.
> BaseCpuTimerLib is designed to calculate TSC frequency by using CPUID[15h] 
> each time.
> The time it takes to find CpuCrystalFrequencyHob (about 2000ns) is much 
> longer than it takes to
> calculate TSC frequency with CPUID[15h] (about 450ns), which means using 
> BaseCpuTimerLib to
> trigger a delay is more accurate than using PeiCpuTimerLib, recommend to use 
> BaseCpuTimerLib
> instead of PeiCpuTimerLib.
> 
> 2. Remove DXE instance(DxeCpuTimerLib).
> DxeCpuTimerLib is designed to calculate TSC frequency with CPUID[15h] in its 
> constructor function,
> then save it in a global variable. For this design, once the driver 
> containing this instance is
> running, the constructor function is called, it will take extra time to 
> calculate TSC frequency.
> The time it takes to get TSC frequncy from global variable is shorter than it 
> takes to calculate
> TSC frequency with CPUID[15h], but 450ns is a short time, the impact on the 
> platform is very limited.
> In addition, in order to simplify the code, recommend to use BaseCpuTimerLib 
> instead of DxeCpuTimerLib.
> 
> I did some experiments on one Intel server platform and collected the 
> following data:
> 1. Average time taken to find CpuCrystalFrequencyHob: about 2000 ns.
> 2. Average time taken to calculate TSC frequency: about 450 ns.
> 
> Reference code:
> //
> // Calculate average time taken to find Hob.
> //
> DEBUG((DEBUG_ERROR, "[PeiCpuTimerLib] GetPerformanceCounterFrequency - 
> GetFirstGuidHob (1000 cycles)\n"));
> Ticks1 = AsmReadTsc();
> for (i = 0; i < 1000; i++) {
>   GuidHob = GetFirstGuidHob (&mCpuCrystalFrequencyHobGuid);
> }
> Ticks2 = AsmReadTsc();
> 
> if (GuidHob == NULL) {
>   DEBUG((DEBUG_ERROR, "[PeiCpuTimerLib]  - CpuCrystalFrequencyHob can not 
> be found!\n"));
> } else {
>   DEBUG((DEBUG_ERROR, "[PeiCpuTimerLib]  - Average time taken to find Hob 
> = %d ns\n", \
>   DivU64x32(DivU64x64Remainder(MultU64x32((Ticks2 - Ticks1), 
> 10), *CpuCrystalCounterFrequency, NULL),
> 1000)));
> }
> 
> //
> // Calculate average time taken to calculate CPU frequency.
> //
> DEBUG((DEBUG_ERROR, "[PeiCpuTimerLib] GetPerformanceCounterFrequency - 
> CpuidCoreClockCalculateTscFrequency
> (1000 cycles)\n"));
> Ticks1 = AsmReadTsc();
> for (i = 0; i < 1000; i++) {
>   Freq = CpuidCoreClockCalculateTscFrequency ();
> }
> Ticks2 = AsmReadTsc();
> DEBUG((DEBUG_ERROR, "[PeiCpuTimerLib]  - Average time taken to calculate 
> TSC frequency = %d ns\n", \
> DivU64x32(DivU64x64Remainder(MultU64x32((Ticks2 - Ticks1), 
> 10), *CpuCrystalCounterFrequency, NULL),
> 1000)));
> 
> Signed-off-by: Jason Lou 
> Cc: Ray Ni 
> Cc: Eric Dong 
> Cc: Laszlo Ersek 
> Cc: Rahul Kumar 
> ---
>  UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.c   | 85 
>  UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.c   | 58 -
>  UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.inf | 37 -
>  UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.uni | 17 
>  UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.inf | 36 -
>  UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.uni | 17 
>  UefiCpuPkg/UefiCpuPkg.dsc |  4 +-
>  7 files changed, 1 insertion(+), 253 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.c 
> b/UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.c
> deleted file mode 100644
> index 269e5a3e83d7..
> --- a/UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.c
> +++ /dev/null
> @@ -1,85 +0,0 @@
> -/** @file
> 
> -  CPUID Leaf 0x15 for Core Crystal Clock frequency instance of Timer Library.
> 
> -
> 
> -  Copyright (c) 2019 Intel Corporation. All rights reserved.
> 
> -  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
> -
> 
> -**/
> 
> -
> 
> -#include 
> 
> -#include 
> 
> -#include 
> 
> -#include 
> 
> -
> 
> -extern GUID mCpuCrystalFrequencyHobGuid;
> 
> -
> 
> -/**
> 
> -  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
> 
> -  );
> 
> -
> 
> -//
> 
> -// Cached CPU Crystal counter frequency
> 
> -//
>

Re: [edk2-devel] [Patch] EmulatorPkg: Add CI build for SECURE_BOOT_ENABLE

[Sean]

I think you should add NOOPT target as well.  NOOPT catches more 
compiler issues than debug/release given the change in optimization 
flags and it is used less by developers.


Once you run a build you should also add the badge to the readme.rst 
(https://github.com/tianocore/edk2/blob/master/ReadMe.rst) so that 
status is visible.


and finally the readme should be updated to include details on this 
configuration.

https://github.com/tianocore/edk2/blob/master/EmulatorPkg/PlatformCI/ReadMe.md#supported-configuration-details

Thanks
Sean




On 9/24/2020 5:48 PM, Michael D Kinney wrote:

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

Add EmulatorPkg CI builds for SECURE_BOOT_ENABLE=TRUE
for IA32/X64 and DEBUG/RELEASE.  Label this these as
FULL builds, so if additional build options are added
in the future, they can be added to these FULL builds.

Cc: Jordan Justen 
Cc: Andrew Fish 
Cc: Ray Ni 
Cc: Divneil Rai Wadhawan 
Cc: Sean Brogan 
Signed-off-by: Michael D Kinney 
---
  .../.azurepipelines/Ubuntu-GCC5.yml   | 29 +++
  .../.azurepipelines/Windows-VS2019.yml| 29 +++
  2 files changed, 58 insertions(+)

diff --git a/EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml 
b/EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
index 12ef8226ff..b5f1d933f4 100644
--- a/EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
+++ b/EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
@@ -6,6 +6,7 @@
  # Toolchain: GCC5
  #
  # Copyright (c) Microsoft Corporation.
+# Copyright (c) 2020, Intel Corporation. All rights reserved.
  # SPDX-License-Identifier: BSD-2-Clause-Patent
  ##
  trigger:
@@ -65,6 +66,34 @@ jobs:
  Build.Target: "NOOPT"
  Run.Flags: $(run_flags)
  Run: $(should_run)
+  EmulatorPkg_X64_FULL_DEBUG:
+Build.File: "$(package)/PlatformCI/PlatformBuild.py"
+Build.Arch: "X64"
+Build.Flags: "BLD_*_SECURE_BOOT_ENABLE=TRUE"
+Build.Target: "DEBUG"
+Run.Flags: $(run_flags)
+Run: $(should_run)
+  EmulatorPkg_X64_FULL_RELEASE:
+Build.File: "$(package)/PlatformCI/PlatformBuild.py"
+Build.Arch: "X64"
+Build.Flags: "BLD_*_SECURE_BOOT_ENABLE=TRUE"
+Build.Target: "RELEASE"
+Run.Flags: $(run_flags)
+Run: $(should_run)
+  EmulatorPkg_IA32_FULL_DEBUG:
+Build.File: "$(package)/PlatformCI/PlatformBuild.py"
+Build.Arch: "IA32"
+Build.Flags: "BLD_*_SECURE_BOOT_ENABLE=TRUE"
+Build.Target: "DEBUG"
+Run.Flags: $(run_flags)
+Run: $(should_run)
+  EmulatorPkg_IA32_FULL_RELEASE:
+Build.File: "$(package)/PlatformCI/PlatformBuild.py"
+Build.Arch: "IA32"
+Build.Flags: "BLD_*_SECURE_BOOT_ENABLE=TRUE"
+Build.Target: "RELEASE"
+Run.Flags: $(run_flags)
+Run: $(should_run)
  
  workspace:

clean: all
diff --git a/EmulatorPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml 
b/EmulatorPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml
index a5baf4b606..5d52d532aa 100644
--- a/EmulatorPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml
+++ b/EmulatorPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml
@@ -6,6 +6,7 @@
  # Toolchain: VS2019
  #
  # Copyright (c) Microsoft Corporation.
+# Copyright (c) 2020, Intel Corporation. All rights reserved.
  # SPDX-License-Identifier: BSD-2-Clause-Patent
  ##
  trigger:
@@ -66,6 +67,34 @@ jobs:
  Build.Target: "NOOPT"
  Run.Flags: $(run_flags)
  Run: $(should_run)
+  EmulatorPkg_X64_FULL_DEBUG:
+Build.File: "$(package)/PlatformCI/PlatformBuild.py"
+Build.Arch: "X64"
+Build.Flags: "BLD_*_SECURE_BOOT_ENABLE=TRUE"
+Build.Target: "DEBUG"
+Run.Flags: $(run_flags)
+Run: $(should_run)
+  EmulatorPkg_X64_FULL_RELEASE:
+Build.File: "$(package)/PlatformCI/PlatformBuild.py"
+Build.Arch: "X64"
+Build.Flags: "BLD_*_SECURE_BOOT_ENABLE=TRUE"
+Build.Target: "RELEASE"
+Run.Flags: $(run_flags)
+Run: $(should_run)
+  EmulatorPkg_IA32_FULL_DEBUG:
+Build.File: "$(package)/PlatformCI/PlatformBuild.py"
+Build.Arch: "IA32"
+Build.Flags: "BLD_*_SECURE_BOOT_ENABLE=TRUE"
+Build.Target: "DEBUG"
+Run.Flags: $(run_flags)
+Run: $(should_run)
+  EmulatorPkg_IA32_FULL_RELEASE:
+Build.File: "$(package)/PlatformCI/PlatformBuild.py"
+Build.Arch: "IA32"
+Build.Flags: "BLD_*_SECURE_BOOT_ENABLE=TRUE"
+Build.Target: "RELEASE"
+Run.Flags: $(run_flags)
+Run: $(should_run)
  
  workspace:

clean: all




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages

Re: [EXTERNAL] Re: [edk2-devel] ECC: Won't somebody PLEASE think of the... test structures.

[Bret Barkelew via groups.io]

Andrew,

That’s actually what got me here. EccCheck runs as part of our CI now (but it 
didn’t when I wrote these tests a year ago). I need to either figure out how to 
get this code to pass EccCheck in a reasonable way, or just not contribute the 
tests and say “go to Mu for the tests, if you want them”.

Skipping the contribution isn’t a desirable outcome at all for a number of 
reasons, not the least of which is that we (MS and others) are trying encourage 
all contributions to come with tests, so the process of writing them needs to 
be simple and painless.

- Bret

From: Andrew Fish
Sent: Thursday, September 24, 2020 7:48 PM
To: edk2-devel-groups-io; Bret 
Barkelew
Cc: Ken Taylor
Subject: [EXTERNAL] Re: [edk2-devel] ECC: Won't somebody PLEASE think of the... 
test structures.

Bret,

I’ve had this issue with EFI code too. It will compile with for DEBUG and 
RELEASE as the optimizer removes the memcpy/memset. So you only see a build 
failure when you compiler NOOPT (and there are no intrinsic libs). I mostly see 
this in platform code when I try to compile a single driver/lib NOOPT and it 
fails to link due to the missing intrinsic.

The easy to enforce this is to compile with optimizations enabled and don’t 
enable intrinsic libs. Not sure if that is really practical from the test point 
of view.

Seems the tool caught the coding style violation so I guess we could try to 
“make running that tool easier”. Maybe hooking into patchcheck.py, making some 
kind of githook, or adding a git command?

Thanks,

Andrew Fish



On Sep 24, 2020, at 7:25 PM, Bret Barkelew via 
groups.io
 
mailto:bret.barkelew=microsoft@groups.io>>
 wrote:

So for context, this is a new host-based test that should only run within a 
platform OS, so intrinsics aren’t the big deal that they would be in FW code.

But we do need to figure out how to simultaneously adhere to the coding 
convention while enabling test authoring.
Or we chose to not enforce quite as many things for tests.

I’d prefer the first.

- Bret

From: Ken Taylor
Sent: Thursday, September 24, 2020 6:57 PM
To: devel@edk2.groups.io; Bret 
Barkelew
Subject: [EXTERNAL] RE: ECC: Won't somebody PLEASE think of the... test 
structures.

If the structure is a non-static local variable, most compilers will silently 
inject an intrinsic call to memcpy in function initialization.  This leads to 
an intermittent linker error.

If the compiler you use automatically supports an intrinsic memcpy in the given 
architecture or optimizes out the memcpy, it will build for you and you won’t 
know you need to link to an intrinsic support library in order to build cross 
platform.  This leads to code that builds for you, but not for me.

Regards,
-Ken.

From: devel@edk2.groups.io 
[mailto:devel@edk2.groups.io] On Behalf Of Bret Barkelew via 
groups.io
Sent: Thursday, September 24, 2020 6:23 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] ECC: Won't somebody PLEASE think of the... test 
structures.

ERROR - EFI coding style error
ERROR - *Error code: 5007
ERROR - *There should be no initialization of a variable as part of its 
declaration
ERROR - *file: 
//home/corthon/_uefi/edk2_qemu_ci/edk2/MdeModulePkg/Library/VariablePolicyLib/VariablePolicyUnitTest/VariablePolicyUnitTest.c
ERROR - *Line number: 333
ERROR - *Variable Name: MatchCheckPolicy

EccCheck no likey:
SIMPLE_VARIABLE_POLICY_ENTRY   ValidationPolicy = {
{
  VARIABLE_POLICY_ENTRY_REVISION,
  sizeof(VARIABLE_POLICY_ENTRY) + sizeof(TEST_VAR_1_NAME),
  sizeof(VARIABLE_POLICY_ENTRY),
  TEST_GUID_1,
  TEST_POLICY_MIN_SIZE_NULL,
  TEST_POLICY_MAX_SIZE_NULL,
  TEST_POLICY_ATTRIBUTES_NULL,
  TEST_POLICY_ATTRIBUTES_NULL,
  VARIABLE_POLICY_TYPE_NO_LOCK
},
TEST_VAR_1_NAME
  };

But you can’t init this structure separately without addressing each field.
Can a brother get an override?

- Bret



<95B370A7BEED49AAB797022E8F260C8F.png>




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

Re: [edk2-devel] ECC: Won't somebody PLEASE think of the... test structures.

[Andrew Fish via groups.io]

Bret,

I’ve had this issue with EFI code too. It will compile with for DEBUG and 
RELEASE as the optimizer removes the memcpy/memset. So you only see a build 
failure when you compiler NOOPT (and there are no intrinsic libs). I mostly see 
this in platform code when I try to compile a single driver/lib NOOPT and it 
fails to link due to the missing intrinsic. 

The easy to enforce this is to compile with optimizations enabled and don’t 
enable intrinsic libs. Not sure if that is really practical from the test point 
of view. 

Seems the tool caught the coding style violation so I guess we could try to 
“make running that tool easier”. Maybe hooking into patchcheck.py, making some 
kind of githook, or adding a git command?

Thanks,

Andrew Fish


> On Sep 24, 2020, at 7:25 PM, Bret Barkelew via groups.io 
>  wrote:
> 
> So for context, this is a new host-based test that should only run within a 
> platform OS, so intrinsics aren’t the big deal that they would be in FW code.
>
> But we do need to figure out how to simultaneously adhere to the coding 
> convention while enabling test authoring.
> Or we chose to not enforce quite as many things for tests.
>
> I’d prefer the first. 
>
> - Bret 
>
> From: Ken Taylor 
> Sent: Thursday, September 24, 2020 6:57 PM
> To: devel@edk2.groups.io ; Bret Barkelew 
> 
> Subject: [EXTERNAL] RE: ECC: Won't somebody PLEASE think of the... test 
> structures.
>
> If the structure is a non-static local variable, most compilers will silently 
> inject an intrinsic call to memcpy in function initialization.  This leads to 
> an intermittent linker error.
>
> If the compiler you use automatically supports an intrinsic memcpy in the 
> given architecture or optimizes out the memcpy, it will build for you and you 
> won’t know you need to link to an intrinsic support library in order to build 
> cross platform.  This leads to code that builds for you, but not for me.
>
> Regards,
> -Ken.
>
> From: devel@edk2.groups.io  
> [mailto:devel@edk2.groups.io ] On Behalf Of Bret 
> Barkelew via groups.io 
> Sent: Thursday, September 24, 2020 6:23 PM
> To: devel@edk2.groups.io 
> Subject: [edk2-devel] ECC: Won't somebody PLEASE think of the... test 
> structures.
>
> ERROR - EFI coding style error
> ERROR - *Error code: 5007
> ERROR - *There should be no initialization of a variable as part of its 
> declaration
> ERROR - *file: 
> //home/corthon/_uefi/edk2_qemu_ci/edk2/MdeModulePkg/Library/VariablePolicyLib/VariablePolicyUnitTest/VariablePolicyUnitTest.c
> ERROR - *Line number: 333
> ERROR - *Variable Name: MatchCheckPolicy
>
> EccCheck no likey:
> SIMPLE_VARIABLE_POLICY_ENTRY   ValidationPolicy = {
> {
>   VARIABLE_POLICY_ENTRY_REVISION,
>   sizeof(VARIABLE_POLICY_ENTRY) + sizeof(TEST_VAR_1_NAME),
>   sizeof(VARIABLE_POLICY_ENTRY),
>   TEST_GUID_1,
>   TEST_POLICY_MIN_SIZE_NULL,
>   TEST_POLICY_MAX_SIZE_NULL,
>   TEST_POLICY_ATTRIBUTES_NULL,
>   TEST_POLICY_ATTRIBUTES_NULL,
>   VARIABLE_POLICY_TYPE_NO_LOCK
> },
> TEST_VAR_1_NAME
>   };
>
> But you can’t init this structure separately without addressing each field.
> Can a brother get an override?
>
> - Bret 
>
>
> 
> <95B370A7BEED49AAB797022E8F260C8F.png>



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

Re: [edk2-devel] ECC: Won't somebody PLEASE think of the... test structures.

[Bret Barkelew via groups.io]

One of the things we’re really trying to do here is make a strong case for 
contributing good tests, so I want them to be both:

  *   Good citizens of code hygiene, and
  *   Good examples of real-world, non-trivial tests (I actually used the new 
UnitTestFrameworkPkg and test-driven design while writing VarPol way back when)

So I’m happy [for some definitions of ‘happy’] to reform and reflow these as 
needed, but I’m getting the suspicion that there are walls I’m going to hit.

I also don’t want test writing to be so onerous as to prevent contributors for 
writing them. For example: I’m not going to docstring every test case. The test 
case name and framework strings should be clear enough to explain what the case 
is doing (otherwise it’s not a good test case).

- Bret

From: Bret Barkelew via groups.io
Sent: Thursday, September 24, 2020 7:26 PM
To: Ken Taylor; 
devel@edk2.groups.io
Subject: [EXTERNAL] Re: [edk2-devel] ECC: Won't somebody PLEASE think of the... 
test structures.

So for context, this is a new host-based test that should only run within a 
platform OS, so intrinsics aren’t the big deal that they would be in FW code.

But we do need to figure out how to simultaneously adhere to the coding 
convention while enabling test authoring.
Or we chose to not enforce quite as many things for tests.

I’d prefer the first.

- Bret

From: Ken Taylor
Sent: Thursday, September 24, 2020 6:57 PM
To: devel@edk2.groups.io; Bret 
Barkelew
Subject: [EXTERNAL] RE: ECC: Won't somebody PLEASE think of the... test 
structures.

If the structure is a non-static local variable, most compilers will silently 
inject an intrinsic call to memcpy in function initialization.  This leads to 
an intermittent linker error.

If the compiler you use automatically supports an intrinsic memcpy in the given 
architecture or optimizes out the memcpy, it will build for you and you won’t 
know you need to link to an intrinsic support library in order to build cross 
platform.  This leads to code that builds for you, but not for me.

Regards,
-Ken.

From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Bret 
Barkelew via groups.io
Sent: Thursday, September 24, 2020 6:23 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] ECC: Won't somebody PLEASE think of the... test 
structures.

ERROR - EFI coding style error
ERROR - *Error code: 5007
ERROR - *There should be no initialization of a variable as part of its 
declaration
ERROR - *file: 
//home/corthon/_uefi/edk2_qemu_ci/edk2/MdeModulePkg/Library/VariablePolicyLib/VariablePolicyUnitTest/VariablePolicyUnitTest.c
ERROR - *Line number: 333
ERROR - *Variable Name: MatchCheckPolicy

EccCheck no likey:
SIMPLE_VARIABLE_POLICY_ENTRY   ValidationPolicy = {
{
  VARIABLE_POLICY_ENTRY_REVISION,
  sizeof(VARIABLE_POLICY_ENTRY) + sizeof(TEST_VAR_1_NAME),
  sizeof(VARIABLE_POLICY_ENTRY),
  TEST_GUID_1,
  TEST_POLICY_MIN_SIZE_NULL,
  TEST_POLICY_MAX_SIZE_NULL,
  TEST_POLICY_ATTRIBUTES_NULL,
  TEST_POLICY_ATTRIBUTES_NULL,
  VARIABLE_POLICY_TYPE_NO_LOCK
},
TEST_VAR_1_NAME
  };

But you can’t init this structure separately without addressing each field.
Can a brother get an override?

- Bret






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

[edk2-devel] ECC: main function entry point in host-based unit tests

[Bret Barkelew via groups.io]

ERROR - EFI coding style error
ERROR - *Error code: 7001
ERROR - *There should be no use of int, unsigned, char, void, long in any .c, 
.h or .asl files
ERROR - *file: 
//home/corthon/_uefi/edk2_qemu_ci/edk2/MdeModulePkg/Library/VariablePolicyLib/VariablePolicyUnitTest/VariablePolicyUnitTest.c
ERROR - *Line number: 763
ERROR - *[main] Return type int
ERROR -
ERROR - EFI coding style error
ERROR - *Error code: 8006
ERROR - *Function name does not follow the rules: 1. First character should be 
upper case 2. Must contain lower case characters 3. No white space characters
ERROR - *file: 
//home/corthon/_uefi/edk2_qemu_ci/edk2/MdeModulePkg/Library/VariablePolicyLib/VariablePolicyUnitTest/VariablePolicyUnitTest.c
ERROR - *Line number: 2253
ERROR - *The function name [main] does not follow the rules

Currently, the host-based unit tests are using a standard C entry point:
int
main ()

That’s going to break both of these.

Another thing to override/figure out for host-based tests

- Bret



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

Re: [edk2-devel] ECC: Won't somebody PLEASE think of the... test structures.

[Bret Barkelew via groups.io]

So for context, this is a new host-based test that should only run within a 
platform OS, so intrinsics aren’t the big deal that they would be in FW code.

But we do need to figure out how to simultaneously adhere to the coding 
convention while enabling test authoring.
Or we chose to not enforce quite as many things for tests.

I’d prefer the first.

- Bret

From: Ken Taylor
Sent: Thursday, September 24, 2020 6:57 PM
To: devel@edk2.groups.io; Bret 
Barkelew
Subject: [EXTERNAL] RE: ECC: Won't somebody PLEASE think of the... test 
structures.

If the structure is a non-static local variable, most compilers will silently 
inject an intrinsic call to memcpy in function initialization.  This leads to 
an intermittent linker error.

If the compiler you use automatically supports an intrinsic memcpy in the given 
architecture or optimizes out the memcpy, it will build for you and you won’t 
know you need to link to an intrinsic support library in order to build cross 
platform.  This leads to code that builds for you, but not for me.

Regards,
-Ken.

From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Bret 
Barkelew via groups.io
Sent: Thursday, September 24, 2020 6:23 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] ECC: Won't somebody PLEASE think of the... test 
structures.

ERROR - EFI coding style error
ERROR - *Error code: 5007
ERROR - *There should be no initialization of a variable as part of its 
declaration
ERROR - *file: 
//home/corthon/_uefi/edk2_qemu_ci/edk2/MdeModulePkg/Library/VariablePolicyLib/VariablePolicyUnitTest/VariablePolicyUnitTest.c
ERROR - *Line number: 333
ERROR - *Variable Name: MatchCheckPolicy

EccCheck no likey:
SIMPLE_VARIABLE_POLICY_ENTRY   ValidationPolicy = {
{
  VARIABLE_POLICY_ENTRY_REVISION,
  sizeof(VARIABLE_POLICY_ENTRY) + sizeof(TEST_VAR_1_NAME),
  sizeof(VARIABLE_POLICY_ENTRY),
  TEST_GUID_1,
  TEST_POLICY_MIN_SIZE_NULL,
  TEST_POLICY_MAX_SIZE_NULL,
  TEST_POLICY_ATTRIBUTES_NULL,
  TEST_POLICY_ATTRIBUTES_NULL,
  VARIABLE_POLICY_TYPE_NO_LOCK
},
TEST_VAR_1_NAME
  };

But you can’t init this structure separately without addressing each field.
Can a brother get an override?

- Bret





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

Re: [edk2-devel] [Patch] BaseTools: Clean the ffs folder before generating files in it

[Yuwei Chen]

Reviewed-by: Yuwei Chen

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Bob
> Feng
> Sent: Wednesday, September 23, 2020 7:21 PM
> To: devel@edk2.groups.io
> Cc: Liming Gao ; Chen, Christine
> 
> Subject: [edk2-devel] [Patch] BaseTools: Clean the ffs folder before
> generating files in it
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2965
> 
> The content in Guid.xref depends on the files under the corresponding ffs
> folder.(refer to the commit 5e9256cd7f54ffd6f1fd9837df92a911fcd2d7c2)
> To make Guid.xref update in the incremental build, clean the files under that
> ffs folder before generating files in it.
> 
> Signed-off-by: Bob Feng 
> Cc: Liming Gao 
> Cc: Yuwei Chen 
> ---
>  BaseTools/Source/Python/GenFds/FfsFileStatement.py | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/BaseTools/Source/Python/GenFds/FfsFileStatement.py
> b/BaseTools/Source/Python/GenFds/FfsFileStatement.py
> index 9fb62b0a91..1c6e59bac7 100644
> --- a/BaseTools/Source/Python/GenFds/FfsFileStatement.py
> +++ b/BaseTools/Source/Python/GenFds/FfsFileStatement.py
> @@ -19,10 +19,11 @@ from Common.Misc import
> GuidStructureByteArrayToGuidString, SaveFileOnChange  import
> Common.LongFilePathOs as os  from .GuidSection import GuidSection
> from .FvImageSection import FvImageSection  from .Ffs import
> FdfFvFileTypeToFileType  from .GenFdsGlobalVariable import
> GenFdsGlobalVariable
> +import shutil
> 
>  ## generate FFS from FILE
>  #
>  #
>  class FileStatement (FileStatementClassObject):
> @@ -65,10 +66,12 @@ class FileStatement (FileStatementClassObject):
> 
>  Str = self.NameGuid
>  if FvName:
>  Str += FvName
>  OutputDir = os.path.join(GenFdsGlobalVariable.FfsDir, Str)
> +if os.path.exists(OutputDir):
> +shutil.rmtree(OutputDir)
>  if not os.path.exists(OutputDir):
>  os.makedirs(OutputDir)
> 
>  if Dict is None:
>  Dict = {}
> --
> 2.20.1.windows.1
> 
> 
> 
> 
> 



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

Re: [edk2-devel] ECC: Won't somebody PLEASE think of the... test structures.

[Ken Taylor]

If the structure is a non-static local variable, most compilers will silently 
inject an intrinsic call to memcpy in function initialization.  This leads to 
an intermittent linker error.

If the compiler you use automatically supports an intrinsic memcpy in the given 
architecture or optimizes out the memcpy, it will build for you and you won't 
know you need to link to an intrinsic support library in order to build cross 
platform.  This leads to code that builds for you, but not for me.

Regards,
-Ken.

From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Bret 
Barkelew via groups.io
Sent: Thursday, September 24, 2020 6:23 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] ECC: Won't somebody PLEASE think of the... test 
structures.

ERROR - EFI coding style error
ERROR - *Error code: 5007
ERROR - *There should be no initialization of a variable as part of its 
declaration
ERROR - *file: 
//home/corthon/_uefi/edk2_qemu_ci/edk2/MdeModulePkg/Library/VariablePolicyLib/VariablePolicyUnitTest/VariablePolicyUnitTest.c
ERROR - *Line number: 333
ERROR - *Variable Name: MatchCheckPolicy

EccCheck no likey:
SIMPLE_VARIABLE_POLICY_ENTRY   ValidationPolicy = {
{
  VARIABLE_POLICY_ENTRY_REVISION,
  sizeof(VARIABLE_POLICY_ENTRY) + sizeof(TEST_VAR_1_NAME),
  sizeof(VARIABLE_POLICY_ENTRY),
  TEST_GUID_1,
  TEST_POLICY_MIN_SIZE_NULL,
  TEST_POLICY_MAX_SIZE_NULL,
  TEST_POLICY_ATTRIBUTES_NULL,
  TEST_POLICY_ATTRIBUTES_NULL,
  VARIABLE_POLICY_TYPE_NO_LOCK
},
TEST_VAR_1_NAME
  };

But you can't init this structure separately without addressing each field.
Can a brother get an override?

- Bret




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

[edk2-devel] ECC: Won't somebody PLEASE think of the... test structures.

[Bret Barkelew via groups.io]

ERROR - EFI coding style error
ERROR - *Error code: 5007
ERROR - *There should be no initialization of a variable as part of its 
declaration
ERROR - *file: 
//home/corthon/_uefi/edk2_qemu_ci/edk2/MdeModulePkg/Library/VariablePolicyLib/VariablePolicyUnitTest/VariablePolicyUnitTest.c
ERROR - *Line number: 333
ERROR - *Variable Name: MatchCheckPolicy

EccCheck no likey:
SIMPLE_VARIABLE_POLICY_ENTRY   ValidationPolicy = {
{
  VARIABLE_POLICY_ENTRY_REVISION,
  sizeof(VARIABLE_POLICY_ENTRY) + sizeof(TEST_VAR_1_NAME),
  sizeof(VARIABLE_POLICY_ENTRY),
  TEST_GUID_1,
  TEST_POLICY_MIN_SIZE_NULL,
  TEST_POLICY_MAX_SIZE_NULL,
  TEST_POLICY_ATTRIBUTES_NULL,
  TEST_POLICY_ATTRIBUTES_NULL,
  VARIABLE_POLICY_TYPE_NO_LOCK
},
TEST_VAR_1_NAME
  };

But you can’t init this structure separately without addressing each field.
Can a brother get an override?

- Bret



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

[edk2-devel] What is a special documentation block?

[Bret Barkelew via groups.io]

Expect a few of these questions as I update 2000+ lines of test code that was 
written prior to EccCheck.

“The function headers should follow Doxygen special documentation blocks in 
section 2.3.5”
Doxygen doesn’t have a section 2.3.5.
Nor does the EDKII coding standard.

- Bret



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#65595): https://edk2.groups.io/g/devel/message/65595
Mute This Topic: https://groups.io/mt/77071089/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/2] CryptoPkg/OpensslLib: Add native instruction support for X64

[Zurcher, Christopher J]

I've discovered the failure was because CryptoPkg includes its own stddef.h 
which is a wrapper for CrtLibSupport.h
I have added the required definitions to this file and have resolved the error:
typedef INTN   ptrdiff_t;
typedef UINT32 wchar_t;

Thanks,
Christopher Zurcher

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of gaoliming
> Sent: Thursday, September 24, 2020 17:49
> To: devel@edk2.groups.io; Zurcher, Christopher J
> ; Yao, Jiewen ; Jiang,
> Guomin 
> Cc: Wang, Jian J ; Lu, XiaoyuX ;
> 'Ard Biesheuvel' 
> Subject: 回复: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib: Add native
> instruction support for X64
> 
> Zurcher:
>   Can you specify the detail build step to reproduce the build error with
> CLANGPDB tool chain?
> 
> Thanks
> Liming
> > -邮件原件-
> > 发件人: bounce+27952+65588+4905953+8761...@groups.io
> >  代表 Zurcher,
> > Christopher J
> > 发送时间: 2020年9月25日 8:28
> > 收件人: Yao, Jiewen ; Jiang, Guomin
> > ; devel@edk2.groups.io
> > 抄送: Wang, Jian J ; Lu, XiaoyuX
> > ; Ard Biesheuvel 
> > 主题: Re: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib: Add native
> > instruction support for X64
> >
> > I was able to successfully build and run the non-optimized code with LLVM,
> > but the optimized version returns this error during build:
> >
> > C:\Program Files\LLVM\lib\clang\9.0.0\include\stdatomic.h:91:17: error:
> > unknown type name 'wchar_t'
> > typedef _Atomic(wchar_t)atomic_wchar_t;
> >
> > Is there a known build issue with CLANGPDB and the stdatomic.h file?
> >
> > Thanks,
> > Christopher Zurcher
> >
> > > -Original Message-
> > > From: Yao, Jiewen 
> > > Sent: Tuesday, September 22, 2020 19:35
> > > To: Zurcher, Christopher J ; Jiang,
> Guomin
> > > ; devel@edk2.groups.io
> > > Cc: Wang, Jian J ; Lu, XiaoyuX
> > ;
> > > Ard Biesheuvel 
> > > Subject: RE: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib: Add
> native
> > > instruction support for X64
> > >
> > > For GCC, please refer to
> > > https://github.com/tianocore/tianocore.github.io/wiki/Using-EDK-II-with-
> > > Native-GCC
> > >
> > > For LLVM, please refer to
> > > https://github.com/tianocore/tianocore.github.io/wiki/CLANG9-Tools-Chain
> > >
> > > Thank you
> > > Yao Jiewen
> > >
> > > > -Original Message-
> > > > From: Zurcher, Christopher J 
> > > > Sent: Tuesday, September 22, 2020 11:22 PM
> > > > To: Jiang, Guomin ; devel@edk2.groups.io; Yao,
> > > > Jiewen 
> > > > Cc: Wang, Jian J ; Lu, XiaoyuX
> > > ;
> > > > Ard Biesheuvel 
> > > > Subject: RE: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib: Add
> > native
> > > > instruction support for X64
> > > >
> > > > I have unit tested SHA1, SHA512, and AES as well.
> > > > I do not have the build environment available to test GCC and LLVM.
> > > >
> > > > --
> > > > Christopher Zurcher
> > > >
> > > > > -Original Message-
> > > > > From: Jiang, Guomin 
> > > > > Sent: Wednesday, September 16, 2020 02:17
> > > > > To: devel@edk2.groups.io; Yao, Jiewen ;
> > Zurcher,
> > > > > Christopher J 
> > > > > Cc: Wang, Jian J ; Lu, XiaoyuX
> > > > ;
> > > > > Ard Biesheuvel 
> > > > > Subject: RE: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib: Add
> > native
> > > > > instruction support for X64
> > > > >
> > > > > Hi Zurcher,
> > > > >
> > > > > > [Jiewen] Since you also add other sha (sha1, sha512) and aesni, I
> think
> > > > > those
> > > > > > need unit test for them too.
> > > > >
> > > > > Can you update the status about it?
> > > > >
> > > > > > [Jiewen] I think we need support build with GCC and LLVM, and with
> > X64.
> > > > >
> > > > > It is better to support the GCC and LLVM.
> > > > >
> > > > > Thanks
> > > > > Guomin
> > > > >
> > > > > > -Original Message-
> > > > > > From: devel@edk2.groups.io  On Behalf Of
> > Yao,
> > > > > > Jiewen
> > > > > > Sent: Tuesday, August 25, 2020 7:36 AM
> > > > > > To: Zurcher, Christopher J ;
> > > > > > devel@edk2.groups.io
> > > > > > Cc: Wang, Jian J ; Lu, XiaoyuX
> > > > > > ; Ard Biesheuvel 
> > > > > > Subject: Re: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib: Add
> > > native
> > > > > > instruction support for X64
> > > > > >
> > > > > > Below:
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Zurcher, Christopher J 
> > > > > > > Sent: Tuesday, August 25, 2020 5:26 AM
> > > > > > > To: devel@edk2.groups.io; Zurcher, Christopher J
> > > > > > > ; Yao, Jiewen
> > 
> > > > > > > Cc: Wang, Jian J ; Lu, XiaoyuX
> > > > > > ;
> > > > > > > Ard Biesheuvel 
> > > > > > > Subject: RE: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib:
> Add
> > > native
> > > > > > > instruction support for X64
> > > > > > >
> > > > > > > 1) I have confirmed that the ApiHooks.c file is still required
> even
> > > > > without
> > > > > > the AVX
> > > > > > > instructions included. The x86_64 assembly files in OpenSSL set
> a
> > > flag
> > > > > called
> > > > > > > $win64 and automatically include calls to the RtlVirtualUnwind
> > > function
> >

Re: [edk2-devel] [Patch] BaseTools: Remove CanSkip calling for incremental build

[Yuwei Chen]

Reviewed-by: Yuwei Chen

> -Original Message-
> From: Feng, Bob C 
> Sent: Wednesday, September 23, 2020 8:37 PM
> To: devel@edk2.groups.io
> Cc: Liming Gao ; Chen, Christine
> 
> Subject: [Patch] BaseTools: Remove CanSkip calling for incremental build
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2978
> 
> If a module add a new PCD, the pcd token number will be reassigned. The
> new Pcd token number should be updated to all module's autogen files.
> CanSkip can only detect a single module's change but not others. CanSkip
> block the pcd token number update in incremental build, so this patch is
> going to remove this call.
> 
> Signed-off-by: Bob Feng 
> Cc: Liming Gao 
> Cc: Yuwei Chen 
> ---
>  BaseTools/Source/Python/AutoGen/ModuleAutoGen.py | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
> b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
> index dc8b1fe3d1..eebf6e87f5 100755
> --- a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
> +++ b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
> @@ -1820,13 +1820,10 @@ class ModuleAutoGen(AutoGen):
> 
>  if not self.IsLibrary and CreateLibraryCodeFile:
>  for LibraryAutoGen in self.LibraryAutoGenList:
>  LibraryAutoGen.CreateCodeFile()
> 
> -# CanSkip uses timestamps to determine build skipping
> -if self.CanSkip():
> -return
>  self.LibraryAutoGenList
>  AutoGenList = []
>  IgoredAutoGenList = []
> 
>  for File in self.AutoGenFileList:
> --
> 2.20.1.windows.1



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

回复: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib: Add native instruction support for X64

[gaoliming]

Zurcher:
  Can you specify the detail build step to reproduce the build error with
CLANGPDB tool chain?

Thanks
Liming
> -邮件原件-
> 发件人: bounce+27952+65588+4905953+8761...@groups.io
>  代表 Zurcher,
> Christopher J
> 发送时间: 2020年9月25日 8:28
> 收件人: Yao, Jiewen ; Jiang, Guomin
> ; devel@edk2.groups.io
> 抄送: Wang, Jian J ; Lu, XiaoyuX
> ; Ard Biesheuvel 
> 主题: Re: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib: Add native
> instruction support for X64
> 
> I was able to successfully build and run the non-optimized code with LLVM,
> but the optimized version returns this error during build:
> 
> C:\Program Files\LLVM\lib\clang\9.0.0\include\stdatomic.h:91:17: error:
> unknown type name 'wchar_t'
> typedef _Atomic(wchar_t)atomic_wchar_t;
> 
> Is there a known build issue with CLANGPDB and the stdatomic.h file?
> 
> Thanks,
> Christopher Zurcher
> 
> > -Original Message-
> > From: Yao, Jiewen 
> > Sent: Tuesday, September 22, 2020 19:35
> > To: Zurcher, Christopher J ; Jiang,
Guomin
> > ; devel@edk2.groups.io
> > Cc: Wang, Jian J ; Lu, XiaoyuX
> ;
> > Ard Biesheuvel 
> > Subject: RE: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib: Add
native
> > instruction support for X64
> >
> > For GCC, please refer to
> > https://github.com/tianocore/tianocore.github.io/wiki/Using-EDK-II-with-
> > Native-GCC
> >
> > For LLVM, please refer to
> > https://github.com/tianocore/tianocore.github.io/wiki/CLANG9-Tools-Chain
> >
> > Thank you
> > Yao Jiewen
> >
> > > -Original Message-
> > > From: Zurcher, Christopher J 
> > > Sent: Tuesday, September 22, 2020 11:22 PM
> > > To: Jiang, Guomin ; devel@edk2.groups.io; Yao,
> > > Jiewen 
> > > Cc: Wang, Jian J ; Lu, XiaoyuX
> > ;
> > > Ard Biesheuvel 
> > > Subject: RE: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib: Add
> native
> > > instruction support for X64
> > >
> > > I have unit tested SHA1, SHA512, and AES as well.
> > > I do not have the build environment available to test GCC and LLVM.
> > >
> > > --
> > > Christopher Zurcher
> > >
> > > > -Original Message-
> > > > From: Jiang, Guomin 
> > > > Sent: Wednesday, September 16, 2020 02:17
> > > > To: devel@edk2.groups.io; Yao, Jiewen ;
> Zurcher,
> > > > Christopher J 
> > > > Cc: Wang, Jian J ; Lu, XiaoyuX
> > > ;
> > > > Ard Biesheuvel 
> > > > Subject: RE: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib: Add
> native
> > > > instruction support for X64
> > > >
> > > > Hi Zurcher,
> > > >
> > > > > [Jiewen] Since you also add other sha (sha1, sha512) and aesni, I
think
> > > > those
> > > > > need unit test for them too.
> > > >
> > > > Can you update the status about it?
> > > >
> > > > > [Jiewen] I think we need support build with GCC and LLVM, and with
> X64.
> > > >
> > > > It is better to support the GCC and LLVM.
> > > >
> > > > Thanks
> > > > Guomin
> > > >
> > > > > -Original Message-
> > > > > From: devel@edk2.groups.io  On Behalf Of
> Yao,
> > > > > Jiewen
> > > > > Sent: Tuesday, August 25, 2020 7:36 AM
> > > > > To: Zurcher, Christopher J ;
> > > > > devel@edk2.groups.io
> > > > > Cc: Wang, Jian J ; Lu, XiaoyuX
> > > > > ; Ard Biesheuvel 
> > > > > Subject: Re: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib: Add
> > native
> > > > > instruction support for X64
> > > > >
> > > > > Below:
> > > > >
> > > > > > -Original Message-
> > > > > > From: Zurcher, Christopher J 
> > > > > > Sent: Tuesday, August 25, 2020 5:26 AM
> > > > > > To: devel@edk2.groups.io; Zurcher, Christopher J
> > > > > > ; Yao, Jiewen
> 
> > > > > > Cc: Wang, Jian J ; Lu, XiaoyuX
> > > > > ;
> > > > > > Ard Biesheuvel 
> > > > > > Subject: RE: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib:
Add
> > native
> > > > > > instruction support for X64
> > > > > >
> > > > > > 1) I have confirmed that the ApiHooks.c file is still required
even
> > > > without
> > > > > the AVX
> > > > > > instructions included. The x86_64 assembly files in OpenSSL set
a
> > flag
> > > > called
> > > > > > $win64 and automatically include calls to the RtlVirtualUnwind
> > function
> > > > if
> > > > > NASM
> > > > > > is selected as the assembler scheme.
> > > > > >
> > > > > >
> https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-
> > > > > > rtlvirtualunwind
> > > > > >
> > > > > > I have submitted an issue against OpenSSL since I don't think
using
> > the
> > > > > NASM
> > > > > > assembler should force the inclusion of Windows-specific API
hooks,
> > but
> > > > > that
> > > > > > change cannot be made in OpenSSL 1.1.1 and we will have to wait
> for
> > > > > OpenSSL 3
> > > > > > or later to remove the stub function.
> > > > > >
> > > > > > https://github.com/openssl/openssl/issues/12712
> > > > > >
> > > > >
> > > > > [Jiewen] Thanks.
> > > > >
> > > > > > 2) So far I have only built with VS.
> > > > > >
> > > > >
> > > > > [Jiewen] I think we need support build with GCC and LLVM, and with
> X64.
> > > > >
> > > > >
> > > > > > 3) The X64 SHA256 implementation was successfully exercised

[edk2-devel] [Patch] EmulatorPkg: Add CI build for SECURE_BOOT_ENABLE

[Michael D Kinney]

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

Add EmulatorPkg CI builds for SECURE_BOOT_ENABLE=TRUE
for IA32/X64 and DEBUG/RELEASE.  Label this these as
FULL builds, so if additional build options are added
in the future, they can be added to these FULL builds.

Cc: Jordan Justen 
Cc: Andrew Fish 
Cc: Ray Ni 
Cc: Divneil Rai Wadhawan 
Cc: Sean Brogan 
Signed-off-by: Michael D Kinney 
---
 .../.azurepipelines/Ubuntu-GCC5.yml   | 29 +++
 .../.azurepipelines/Windows-VS2019.yml| 29 +++
 2 files changed, 58 insertions(+)

diff --git a/EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml 
b/EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
index 12ef8226ff..b5f1d933f4 100644
--- a/EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
+++ b/EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml
@@ -6,6 +6,7 @@
 # Toolchain: GCC5
 #
 # Copyright (c) Microsoft Corporation.
+# Copyright (c) 2020, Intel Corporation. All rights reserved.
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 ##
 trigger:
@@ -65,6 +66,34 @@ jobs:
 Build.Target: "NOOPT"
 Run.Flags: $(run_flags)
 Run: $(should_run)
+  EmulatorPkg_X64_FULL_DEBUG:
+Build.File: "$(package)/PlatformCI/PlatformBuild.py"
+Build.Arch: "X64"
+Build.Flags: "BLD_*_SECURE_BOOT_ENABLE=TRUE"
+Build.Target: "DEBUG"
+Run.Flags: $(run_flags)
+Run: $(should_run)
+  EmulatorPkg_X64_FULL_RELEASE:
+Build.File: "$(package)/PlatformCI/PlatformBuild.py"
+Build.Arch: "X64"
+Build.Flags: "BLD_*_SECURE_BOOT_ENABLE=TRUE"
+Build.Target: "RELEASE"
+Run.Flags: $(run_flags)
+Run: $(should_run)
+  EmulatorPkg_IA32_FULL_DEBUG:
+Build.File: "$(package)/PlatformCI/PlatformBuild.py"
+Build.Arch: "IA32"
+Build.Flags: "BLD_*_SECURE_BOOT_ENABLE=TRUE"
+Build.Target: "DEBUG"
+Run.Flags: $(run_flags)
+Run: $(should_run)
+  EmulatorPkg_IA32_FULL_RELEASE:
+Build.File: "$(package)/PlatformCI/PlatformBuild.py"
+Build.Arch: "IA32"
+Build.Flags: "BLD_*_SECURE_BOOT_ENABLE=TRUE"
+Build.Target: "RELEASE"
+Run.Flags: $(run_flags)
+Run: $(should_run)
 
 workspace:
   clean: all
diff --git a/EmulatorPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml 
b/EmulatorPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml
index a5baf4b606..5d52d532aa 100644
--- a/EmulatorPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml
+++ b/EmulatorPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml
@@ -6,6 +6,7 @@
 # Toolchain: VS2019
 #
 # Copyright (c) Microsoft Corporation.
+# Copyright (c) 2020, Intel Corporation. All rights reserved.
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 ##
 trigger:
@@ -66,6 +67,34 @@ jobs:
 Build.Target: "NOOPT"
 Run.Flags: $(run_flags)
 Run: $(should_run)
+  EmulatorPkg_X64_FULL_DEBUG:
+Build.File: "$(package)/PlatformCI/PlatformBuild.py"
+Build.Arch: "X64"
+Build.Flags: "BLD_*_SECURE_BOOT_ENABLE=TRUE"
+Build.Target: "DEBUG"
+Run.Flags: $(run_flags)
+Run: $(should_run)
+  EmulatorPkg_X64_FULL_RELEASE:
+Build.File: "$(package)/PlatformCI/PlatformBuild.py"
+Build.Arch: "X64"
+Build.Flags: "BLD_*_SECURE_BOOT_ENABLE=TRUE"
+Build.Target: "RELEASE"
+Run.Flags: $(run_flags)
+Run: $(should_run)
+  EmulatorPkg_IA32_FULL_DEBUG:
+Build.File: "$(package)/PlatformCI/PlatformBuild.py"
+Build.Arch: "IA32"
+Build.Flags: "BLD_*_SECURE_BOOT_ENABLE=TRUE"
+Build.Target: "DEBUG"
+Run.Flags: $(run_flags)
+Run: $(should_run)
+  EmulatorPkg_IA32_FULL_RELEASE:
+Build.File: "$(package)/PlatformCI/PlatformBuild.py"
+Build.Arch: "IA32"
+Build.Flags: "BLD_*_SECURE_BOOT_ENABLE=TRUE"
+Build.Target: "RELEASE"
+Run.Flags: $(run_flags)
+Run: $(should_run)
 
 workspace:
   clean: all
-- 
2.21.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#65589): https://edk2.groups.io/g/devel/message/65589
Mute This Topic: https://groups.io/mt/77070643/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/2] CryptoPkg/OpensslLib: Add native instruction support for X64

[Zurcher, Christopher J]

I was able to successfully build and run the non-optimized code with LLVM, but 
the optimized version returns this error during build:

C:\Program Files\LLVM\lib\clang\9.0.0\include\stdatomic.h:91:17: error: unknown 
type name 'wchar_t'
typedef _Atomic(wchar_t)atomic_wchar_t;

Is there a known build issue with CLANGPDB and the stdatomic.h file?

Thanks,
Christopher Zurcher

> -Original Message-
> From: Yao, Jiewen 
> Sent: Tuesday, September 22, 2020 19:35
> To: Zurcher, Christopher J ; Jiang, Guomin
> ; devel@edk2.groups.io
> Cc: Wang, Jian J ; Lu, XiaoyuX ;
> Ard Biesheuvel 
> Subject: RE: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib: Add native
> instruction support for X64
> 
> For GCC, please refer to
> https://github.com/tianocore/tianocore.github.io/wiki/Using-EDK-II-with-
> Native-GCC
> 
> For LLVM, please refer to
> https://github.com/tianocore/tianocore.github.io/wiki/CLANG9-Tools-Chain
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: Zurcher, Christopher J 
> > Sent: Tuesday, September 22, 2020 11:22 PM
> > To: Jiang, Guomin ; devel@edk2.groups.io; Yao,
> > Jiewen 
> > Cc: Wang, Jian J ; Lu, XiaoyuX
> ;
> > Ard Biesheuvel 
> > Subject: RE: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib: Add native
> > instruction support for X64
> >
> > I have unit tested SHA1, SHA512, and AES as well.
> > I do not have the build environment available to test GCC and LLVM.
> >
> > --
> > Christopher Zurcher
> >
> > > -Original Message-
> > > From: Jiang, Guomin 
> > > Sent: Wednesday, September 16, 2020 02:17
> > > To: devel@edk2.groups.io; Yao, Jiewen ; Zurcher,
> > > Christopher J 
> > > Cc: Wang, Jian J ; Lu, XiaoyuX
> > ;
> > > Ard Biesheuvel 
> > > Subject: RE: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib: Add native
> > > instruction support for X64
> > >
> > > Hi Zurcher,
> > >
> > > > [Jiewen] Since you also add other sha (sha1, sha512) and aesni, I think
> > > those
> > > > need unit test for them too.
> > >
> > > Can you update the status about it?
> > >
> > > > [Jiewen] I think we need support build with GCC and LLVM, and with X64.
> > >
> > > It is better to support the GCC and LLVM.
> > >
> > > Thanks
> > > Guomin
> > >
> > > > -Original Message-
> > > > From: devel@edk2.groups.io  On Behalf Of Yao,
> > > > Jiewen
> > > > Sent: Tuesday, August 25, 2020 7:36 AM
> > > > To: Zurcher, Christopher J ;
> > > > devel@edk2.groups.io
> > > > Cc: Wang, Jian J ; Lu, XiaoyuX
> > > > ; Ard Biesheuvel 
> > > > Subject: Re: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib: Add
> native
> > > > instruction support for X64
> > > >
> > > > Below:
> > > >
> > > > > -Original Message-
> > > > > From: Zurcher, Christopher J 
> > > > > Sent: Tuesday, August 25, 2020 5:26 AM
> > > > > To: devel@edk2.groups.io; Zurcher, Christopher J
> > > > > ; Yao, Jiewen 
> > > > > Cc: Wang, Jian J ; Lu, XiaoyuX
> > > > ;
> > > > > Ard Biesheuvel 
> > > > > Subject: RE: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib: Add
> native
> > > > > instruction support for X64
> > > > >
> > > > > 1) I have confirmed that the ApiHooks.c file is still required even
> > > without
> > > > the AVX
> > > > > instructions included. The x86_64 assembly files in OpenSSL set a
> flag
> > > called
> > > > > $win64 and automatically include calls to the RtlVirtualUnwind
> function
> > > if
> > > > NASM
> > > > > is selected as the assembler scheme.
> > > > >
> > > > > https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-
> > > > > rtlvirtualunwind
> > > > >
> > > > > I have submitted an issue against OpenSSL since I don't think using
> the
> > > > NASM
> > > > > assembler should force the inclusion of Windows-specific API hooks,
> but
> > > > that
> > > > > change cannot be made in OpenSSL 1.1.1 and we will have to wait for
> > > > OpenSSL 3
> > > > > or later to remove the stub function.
> > > > >
> > > > > https://github.com/openssl/openssl/issues/12712
> > > > >
> > > >
> > > > [Jiewen] Thanks.
> > > >
> > > > > 2) So far I have only built with VS.
> > > > >
> > > >
> > > > [Jiewen] I think we need support build with GCC and LLVM, and with X64.
> > > >
> > > >
> > > > > 3) The X64 SHA256 implementation was successfully exercised across a
> > > > large
> > > > > number of devices in a production environment as a verification step
> in a
> > > > multi-
> > > > > GB data transfer scenario.
> > > > >
> > > >
> > > > [Jiewen] Since you also add other sha (sha1, sha512) and aesni, I think
> > > those
> > > > need unit test for them too.
> > > >
> > > >
> > > > > Thanks,
> > > > > Christopher Zurcher
> > > > >
> > > > > > -Original Message-
> > > > > > From: devel@edk2.groups.io  On Behalf Of
> > > > Zurcher,
> > > > > > Christopher J
> > > > > > Sent: Tuesday, August 18, 2020 15:50
> > > > > > To: Yao, Jiewen ; devel@edk2.groups.io
> > > > > > Cc: Wang, Jian J ; Lu, XiaoyuX
> > > > > ;
> > > > > > Ard Biesheuvel 
> > > > > > Subject: Re: [edk2-devel] [PATCH v2 1/

Re: [edk2-devel] [PATCH] EmulatorPkg: Add RngLib to satisfy dependency of OpensslLib

[Sean]

This seems like a big enough "platform" difference that we should be testing in 
platform ci.

To do that you would need to add another item in the matrix here

https://github.com/tianocore/edk2/blob/master/EmulatorPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml#L26

and here:
https://github.com/tianocore/edk2/blob/master/EmulatorPkg/PlatformCI/.azurepipelines/Ubuntu-GCC5.yml#L25

An example in OVMF of how this is done is here
https://github.com/tianocore/edk2/blob/master/OvmfPkg/PlatformCI/.azurepipelines/Windows-VS2019.yml#L95


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

Re: [edk2-devel] [PATCH v1 1/2] MdePkg: Definitions for Extended Interrupt Flags

[Michael D Kinney]

Hi Sami,

The set of define values looks more complex than needed for single bit field 
checks.

Perhaps we can simplify to just defining the bit locations and the IS_ macros 
check
for 0 or non-zer0 results?

#define EFI_ACPI_EXTENDED_INTERRUPT_FLAG_PRODUCER_CONSUMER_MASK   BIT0
#define EFI_ACPI_EXTENDED_INTERRUPT_FLAG_MODE_MASKBIT1
#define EFI_ACPI_EXTENDED_INTERRUPT_FLAG_POLARITY_MASKBIT2
#define EFI_ACPI_EXTENDED_INTERRUPT_FLAG_SHARABLE_MASKBIT3
#define EFI_ACPI_EXTENDED_INTERRUPT_FLAG_WAKE_CAPABLITY_MASK  BIT4

#define IS_EXTENDED_INTERRUPT_CONSUMER(Flag)  \
  (((Flag) & EFI_ACPI_EXTENDED_INTERRUPT_FLAG_PRODUCER_CONSUMER_MASK) != 0)

#define IS_EXTENDED_INTERRUPT_EDGE_TRIGGERED(Flag)\
  (((Flag) & EFI_ACPI_EXTENDED_INTERRUPT_FLAG_MODE_MASK) != 0)

Are the IS_ macros really required?  I do not see those for other bit
fields in ACPI structs.

Thanks,

Mike

> -Original Message-
> From: Sami Mujawar 
> Sent: Tuesday, September 22, 2020 7:08 AM
> To: devel@edk2.groups.io
> Cc: Sami Mujawar ; Kinney, Michael D 
> ; gaolim...@byosoft.com.cn; Liu, Zhiguang
> ; alexei.fedo...@arm.com; pierre.gond...@arm.com; 
> matteo.carl...@arm.com; ben.adder...@arm.com; n...@arm.com
> Subject: [PATCH v1 1/2] MdePkg: Definitions for Extended Interrupt Flags
> 
> Add Interrupt Vector Flag definitions for Extended Interrupt
> Descriptor, and macros to test the flags.
> Ref: ACPI specification 6.4.3.6
> 
> Signed-off-by: Sami Mujawar 
> ---
>  MdePkg/Include/IndustryStandard/Acpi10.h | 85 
>  1 file changed, 85 insertions(+)
> 
> diff --git a/MdePkg/Include/IndustryStandard/Acpi10.h 
> b/MdePkg/Include/IndustryStandard/Acpi10.h
> index 
> adeb5ae8c219f31d2403fc7aa217bfb4e1e44694..fa3f0694b9cf80bf9c1a325099a970b9cf8c1426
>  100644
> --- a/MdePkg/Include/IndustryStandard/Acpi10.h
> +++ b/MdePkg/Include/IndustryStandard/Acpi10.h
> @@ -2,6 +2,7 @@
>ACPI 1.0b definitions from the ACPI Specification, revision 1.0b
> 
>  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2020, Arm Limited. All rights reserved.
>  SPDX-License-Identifier: BSD-2-Clause-Patent
>  **/
> 
> @@ -377,6 +378,90 @@ typedef struct {
>  #define   EFI_ACPI_MEMORY_NON_WRITABLE  0x00
> 
>  //
> +// Interrupt Vector Flags definitions for Extended Interrupt Descriptor
> +// Ref ACPI specification 6.4.3.6
> +//
> +#define EFI_ACPI_EXTENDED_INTERRUPT_FLAG_PRODUCER_CONSUMER_MASK   BIT0
> +#define   EFI_ACPI_EXTENDED_INTERRUPT_FLAG_PRODUCER   0
> +#define   EFI_ACPI_EXTENDED_INTERRUPT_FLAG_CONSUMER   BIT0
> +
> +#define EFI_ACPI_EXTENDED_INTERRUPT_FLAG_MODE_MASKBIT1
> +#define   EFI_ACPI_EXTENDED_INTERRUPT_FLAG_LEVEL_TRIGGERED0
> +#define   EFI_ACPI_EXTENDED_INTERRUPT_FLAG_EDGE_TRIGGERED BIT1
> +
> +#define EFI_ACPI_EXTENDED_INTERRUPT_FLAG_POLARITY_MASKBIT2
> +#define   EFI_ACPI_EXTENDED_INTERRUPT_FLAG_ACTIVE_HIGH0
> +#define   EFI_ACPI_EXTENDED_INTERRUPT_FLAG_ACTIVE_LOW BIT2
> +
> +#define EFI_ACPI_EXTENDED_INTERRUPT_FLAG_SHARABLE_MASKBIT3
> +#define   EFI_ACPI_EXTENDED_INTERRUPT_FLAG_EXCLUSIVE  0
> +#define   EFI_ACPI_EXTENDED_INTERRUPT_FLAG_SHARED BIT3
> +
> +#define EFI_ACPI_EXTENDED_INTERRUPT_FLAG_WAKE_CAPABLITY_MASK  BIT4
> +#define   EFI_ACPI_EXTENDED_INTERRUPT_FLAG_NOT_WAKE_CAPABLE   0
> +#define   EFI_ACPI_EXTENDED_INTERRUPT_FLAG_WAKE_CAPABLE   BIT4> +
> +/* Helper macros to test Extended Interrupt Resource descriptor flags.
> +*/
> +
> +/** Test the Extended Interrupt flags to determine if the Device
> +is an Interrupt Consumer or Producer.
> +
> +  @param [in]  Flag   Extended Interrupt Resource descriptor flag.
> +
> +  @retval TRUEDevice is Interrupt Consumer.
> +  @retval FALSE   Device is Interrupt Producer.
> +*/
> +#define IS_EXTENDED_INTERRUPT_CONSUMER(Flag)  \
> +  (((Flag) & EFI_ACPI_EXTENDED_INTERRUPT_FLAG_CONSUMER) ==\
> +EFI_ACPI_EXTENDED_INTERRUPT_FLAG_CONSUMER)
> +
> +/** Test if the Extended Interrupt is Edge or Level triggered.
> +
> +  @param [in]  Flag   Extended Interrupt Resource descriptor flag.
> +
> +  @retval TRUEInterrupt is Edge triggered.
> +  @retval FALSE   Interrupt is Level triggered.
> +*/
> +#define IS_EXTENDED_INTERRUPT_EDGE_TRIGGERED(Flag)\
> +  (((Flag) & EFI_ACPI_EXTENDED_INTERRUPT_FLAG_EDGE_TRIGGERED) ==  \
> +EFI_ACPI_EXTENDED_INTERRUPT_FLAG_EDGE_TRIGGERED)> +
> +/** Test if the Extended Interrupt is Active Low or Active High.
> +
> +  @param [in]  Flag   Extended Interrupt Resource descriptor flag.
> +
> +  @retval TRUEInterrupt is Active Low.
> +  @retval FALSE   Interrupt is Active High.
> +*/
> +#define IS_EXTENDED_INTERRUPT_ACTIVE_LOW(Flag)\
> +  (((Flag) & EFI_ACPI_E

Re: [edk2-devel] [PATCH 1/1] NetworkPkg: Fix possible infinite loop in HTTP msg body parser

[Vladimir Olovyannikov via groups.io]

Hi Maciej,

Can you please review this patch?
It is sitting there for a while, looks like it slipped through the cracks.

Thank you,
Vladimir
> -Original Message-
> From: Vladimir Olovyannikov 
> Sent: Friday, August 28, 2020 11:17 AM
> To: devel@edk2.groups.io
> Cc: Vladimir Olovyannikov ; Maciej
> Rabeda ; Jiaxin Wu ;
> Siyuan Fu 
> Subject: [PATCH 1/1] NetworkPkg: Fix possible infinite loop in HTTP msg
body
> parser
>
> When an HTTP server sends a non-chunked body data with no Content-
> Length header, the HttpParserMessageBody in DxeHttpLib gets confused
> and never sets the Char pointer beyond the body start.
> This causes "for" loop to never break because the condition of "Char >=
Body
> + BodyLength" is never satisfied.
> Use BodyLength as the ContentLength for the parser when ContentLength is
> absent in HTTP response headers.
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2941
>
> Signed-off-by: Vladimir Olovyannikov
> 
> Cc: Maciej Rabeda 
> Cc: Jiaxin Wu 
> Cc: Siyuan Fu 
> ---
>  NetworkPkg/Library/DxeHttpLib/DxeHttpLib.c | 19 ---
>  1 file changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/NetworkPkg/Library/DxeHttpLib/DxeHttpLib.c
> b/NetworkPkg/Library/DxeHttpLib/DxeHttpLib.c
> index 180d9321025a..e550c9962dc1 100644
> --- a/NetworkPkg/Library/DxeHttpLib/DxeHttpLib.c
> +++ b/NetworkPkg/Library/DxeHttpLib/DxeHttpLib.c
> @@ -1122,6 +1122,7 @@ HttpParseMessageBody (
>CHAR8 *Char;
>UINTN RemainderLengthInThis;
>UINTN LengthForCallback;
> +  UINTN PortionLength;
>EFI_STATUSStatus;
>HTTP_BODY_PARSER  *Parser;
>
> @@ -1173,19 +1174,31 @@ HttpParseMessageBody (
>//
>// Identity transfer-coding, just notify user to save the body
data.
>//
> +  PortionLength = MIN (
> +BodyLength,
> +Parser->ContentLength -
Parser->ParsedBodyLength
> +);
> +  if (!PortionLength) {
> +//
> +// Got BodyLength, but no ContentLength. Use BodyLength.
> +//
> +PortionLength = BodyLength;
> +Parser->ContentLength = PortionLength;
> +  }
> +
>if (Parser->Callback != NULL) {
>  Status = Parser->Callback (
> BodyParseEventOnData,
> Char,
> -   MIN (BodyLength, Parser->ContentLength -
Parser-
> >ParsedBodyLength),
> +   PortionLength,
> Parser->Context
> );
>  if (EFI_ERROR (Status)) {
>return Status;
>  }
>}
> -  Char += MIN (BodyLength, Parser->ContentLength - Parser-
> >ParsedBodyLength);
> -  Parser->ParsedBodyLength += MIN (BodyLength, Parser-
> >ContentLength - Parser->ParsedBodyLength);
> +  Char += PortionLength;
> +  Parser->ParsedBodyLength += PortionLength;
>if (Parser->ParsedBodyLength == Parser->ContentLength) {
>  Parser->State = BodyParserComplete;
>  if (Parser->Callback != NULL) {
> --
> 2.26.2.266.ge870325ee8


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




smime.p7s
Description: S/MIME Cryptographic Signature

[edk2-devel] [edk2-test] Contributions.txt still mentions the TianoCore Contribution Agreement

[Rebecca Cran]

While working on the SctPkg, I noticed the Contributions.txt file in the 
top of the repo still mentions the TianoCore Contribution Agreement. 
Does it need updated?



--
Rebecca Cran



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

[edk2-devel] [edk2-test] [PATCH 2/3] uefi-sct: Fix the mailing list address in Maintainers.txt and Readme.md

[Rebecca Cran]

The mailing list has changed from lists.01.org to groups.io.
Update Maintainers.txt and Readme.md to match.

Signed-off-by: Rebecca Cran 
---
 uefi-sct/Maintainers.txt | 2 +-
 uefi-sct/Readme.md   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/uefi-sct/Maintainers.txt b/uefi-sct/Maintainers.txt
index c5f11c7deacf..cfad3b7881d8 100644
--- a/uefi-sct/Maintainers.txt
+++ b/uefi-sct/Maintainers.txt
@@ -46,4 +46,4 @@ R: Samer El-Haj-Mahmoud 
 
 
 General questions on UEFI-SCT with the subject [edk2-test] can be sent to
-L: edk2-list 
+L: edk2-devel 
diff --git a/uefi-sct/Readme.md b/uefi-sct/Readme.md
index 8445f4d54619..1a049b60aa7b 100644
--- a/uefi-sct/Readme.md
+++ b/uefi-sct/Readme.md
@@ -24,5 +24,5 @@ are listed in [Maintainers.txt](Maintainers.txt).
 # Resources
 * [TianoCore](http://www.tianocore.org)
 * [Getting Started with 
UEFI-SCT](https://github.com/tianocore/tianocore.github.io/wiki/UEFI-SCT)
-* [Mailing List](mailto:edk2-de...@lists.01.org?subject=[edk2-test])
+* [Mailing List](mailto:devel@edk2.groups.io?subject=[edk2-test])
 * [UEFI-SCT BugTracker](https://bugzilla.tianocore.org/)
-- 
2.26.2



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

[edk2-devel] [edk2-test] [PATCH 3/3] uefi-sct/SctPkg: Fix some indentation issues in build.sh

[Rebecca Cran]

build.sh contains a mixture of tabs and spaces, with differing
numbers of spaces used for indents. Update it so any single block only
uses one style of indentation.

Signed-off-by: Rebecca Cran 
---
 uefi-sct/SctPkg/build.sh | 33 -
 1 file changed, 16 insertions(+), 17 deletions(-)

diff --git a/uefi-sct/SctPkg/build.sh b/uefi-sct/SctPkg/build.sh
index be610debcf3c..37667711f3a5 100755
--- a/uefi-sct/SctPkg/build.sh
+++ b/uefi-sct/SctPkg/build.sh
@@ -56,9 +56,9 @@ function get_gcc_version
 {
gcc_version=$($1 -dumpversion)
 
-if [ ${gcc_version%%.*} -gt 5 ]; then
-gcc_version=5
-fi
+   if [ ${gcc_version%%.*} -gt 5 ]; then
+   gcc_version=5
+   fi
 
case $gcc_version in
4.6*|4.7*|4.8*|4.9*|5*)
@@ -152,10 +152,9 @@ case `uname` in
;;

GCC* | gcc*)
-set_cross_compile
-   CROSS_COMPILE="$TEMP_CROSS_COMPILE"
-export TARGET_TOOLS=`get_gcc_version "$CROSS_COMPILE"gcc`
-
+   set_cross_compile
+   CROSS_COMPILE="$TEMP_CROSS_COMPILE"
+   export TARGET_TOOLS=`get_gcc_version 
"$CROSS_COMPILE"gcc`
;;
 
*)
@@ -224,7 +223,7 @@ then
   status=$?
   if test $status -ne 0
   then
-  echo Error while building EDK tools
+echo Error while building EDK tools
 exit -1
   fi
 else
@@ -239,7 +238,7 @@ make -C SctPkg/Tools/Source/GenBin
 status=$?
 if test $status -ne 0
 then
-echo Error while building GenBin
+  echo Error while building GenBin
   exit -1
 fi
 
@@ -258,8 +257,8 @@ build -p SctPkg/UEFI/UEFI_SCT.dsc -a $SCT_TARGET_ARCH -t 
$TARGET_TOOLS -b $SCT_B
 status=$?
 if test $status -ne 0
 then
-echo Could not build the UEFI SCT package
-exit -1
+  echo Could not build the UEFI SCT package
+  exit -1
 fi
 
 build -p SctPkg/UEFI/IHV_SCT.dsc -a $SCT_TARGET_ARCH -t $TARGET_TOOLS -b 
$SCT_BUILD $3 $4 $5 $6 $7 $8 $9
@@ -268,8 +267,8 @@ build -p SctPkg/UEFI/IHV_SCT.dsc -a $SCT_TARGET_ARCH -t 
$TARGET_TOOLS -b $SCT_BU
 status=$?
 if test $status -ne 0
 then
-echo Could not build the IHV SCT package
-exit -1
+  echo Could not build the IHV SCT package
+  exit -1
 fi
 
 
@@ -299,8 +298,8 @@ pwd
 status=$?
 if test $status -ne 0
 then
-echo Could not generate UEFI SCT binary
- exit -1
+  echo Could not generate UEFI SCT binary
+  exit -1
 else
 echo The SCT binary "SctPackage${SCT_TARGET_ARCH}" is located at 
"$EFI_SOURCE/Build/UefiSct/${SCT_BUILD}_${TARGET_TOOLS}"
 fi
@@ -315,8 +314,8 @@ pwd
 status=$?
 if test $status -ne 0
 then
-echo Could not generate IHV SCT binary
- exit -1
+  echo Could not generate IHV SCT binary
+  exit -1
 else
 echo The IHV binary "SctPackage${SCT_TARGET_ARCH}" is located at 
"$EFI_SOURCE/Build/IhvSct/${SCT_BUILD}_${TARGET_TOOLS}"
 fi
-- 
2.26.2



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

[edk2-devel] [edk2-test] [PATCH 1/3] uefi-sct/SctPkg: Fix build.sh when specifying GCC5 toolchain

[Rebecca Cran]

build.sh usage indicates that "GCC5" can be specified, but it's currently
rejected due to a case statement only matching "GCC" or "gcc".
Fix this by adding a wildcard match.

Signed-off-by: Rebecca Cran 
---
 uefi-sct/SctPkg/build.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/uefi-sct/SctPkg/build.sh b/uefi-sct/SctPkg/build.sh
index cad17ccdedc7..be610debcf3c 100755
--- a/uefi-sct/SctPkg/build.sh
+++ b/uefi-sct/SctPkg/build.sh
@@ -151,7 +151,7 @@ case `uname` in
TARGET_TOOLS=ARMGCC
;;

-   GCC | gcc)
+   GCC* | gcc*)
 set_cross_compile
CROSS_COMPILE="$TEMP_CROSS_COMPILE"
 export TARGET_TOOLS=`get_gcc_version "$CROSS_COMPILE"gcc`
-- 
2.26.2



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

[edk2-devel] [edk2-test] [PATCH 2/3] uefi-sct: Fix the mailing list address in Maintainers.txt and Readme.md

[Rebecca Cran]

The mailing list has changed from lists.01.org to groups.io.
Update Maintainers.txt and Readme.md to match.

Signed-off-by: Rebecca Cran 
---
 uefi-sct/Maintainers.txt | 2 +-
 uefi-sct/Readme.md   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/uefi-sct/Maintainers.txt b/uefi-sct/Maintainers.txt
index c5f11c7d..cfad3b78 100644
--- a/uefi-sct/Maintainers.txt
+++ b/uefi-sct/Maintainers.txt
@@ -46,4 +46,4 @@ R: Samer El-Haj-Mahmoud 
 
 
 General questions on UEFI-SCT with the subject [edk2-test] can be sent to
-L: edk2-list 
+L: edk2-devel 
diff --git a/uefi-sct/Readme.md b/uefi-sct/Readme.md
index 8445f4d5..1a049b60 100644
--- a/uefi-sct/Readme.md
+++ b/uefi-sct/Readme.md
@@ -24,5 +24,5 @@ are listed in [Maintainers.txt](Maintainers.txt).
 # Resources
 * [TianoCore](http://www.tianocore.org)
 * [Getting Started with 
UEFI-SCT](https://github.com/tianocore/tianocore.github.io/wiki/UEFI-SCT)
-* [Mailing List](mailto:edk2-de...@lists.01.org?subject=[edk2-test])
+* [Mailing List](mailto:devel@edk2.groups.io?subject=[edk2-test])
 * [UEFI-SCT BugTracker](https://bugzilla.tianocore.org/)
-- 
2.26.2



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

[edk2-devel] [edk2-test] [PATCH 3/3] uefi-sct/SctPkg: Fix some indentation issues in build.sh

[Rebecca Cran]

build.sh contains a mixture of tabs and spaces, with differing
numbers of spaces used for indents. Update it so any single block only
uses one style of indentation.

Signed-off-by: Rebecca Cran 
---
 uefi-sct/SctPkg/build.sh | 33 -
 1 file changed, 16 insertions(+), 17 deletions(-)

diff --git a/uefi-sct/SctPkg/build.sh b/uefi-sct/SctPkg/build.sh
index be610deb..37667711 100755
--- a/uefi-sct/SctPkg/build.sh
+++ b/uefi-sct/SctPkg/build.sh
@@ -56,9 +56,9 @@ function get_gcc_version
 {
gcc_version=$($1 -dumpversion)
 
-if [ ${gcc_version%%.*} -gt 5 ]; then
-gcc_version=5
-fi
+   if [ ${gcc_version%%.*} -gt 5 ]; then
+   gcc_version=5
+   fi
 
case $gcc_version in
4.6*|4.7*|4.8*|4.9*|5*)
@@ -152,10 +152,9 @@ case `uname` in
;;

GCC* | gcc*)
-set_cross_compile
-   CROSS_COMPILE="$TEMP_CROSS_COMPILE"
-export TARGET_TOOLS=`get_gcc_version "$CROSS_COMPILE"gcc`
-
+   set_cross_compile
+   CROSS_COMPILE="$TEMP_CROSS_COMPILE"
+   export TARGET_TOOLS=`get_gcc_version 
"$CROSS_COMPILE"gcc`
;;
 
*)
@@ -224,7 +223,7 @@ then
   status=$?
   if test $status -ne 0
   then
-  echo Error while building EDK tools
+echo Error while building EDK tools
 exit -1
   fi
 else
@@ -239,7 +238,7 @@ make -C SctPkg/Tools/Source/GenBin
 status=$?
 if test $status -ne 0
 then
-echo Error while building GenBin
+  echo Error while building GenBin
   exit -1
 fi
 
@@ -258,8 +257,8 @@ build -p SctPkg/UEFI/UEFI_SCT.dsc -a $SCT_TARGET_ARCH -t 
$TARGET_TOOLS -b $SCT_B
 status=$?
 if test $status -ne 0
 then
-echo Could not build the UEFI SCT package
-exit -1
+  echo Could not build the UEFI SCT package
+  exit -1
 fi
 
 build -p SctPkg/UEFI/IHV_SCT.dsc -a $SCT_TARGET_ARCH -t $TARGET_TOOLS -b 
$SCT_BUILD $3 $4 $5 $6 $7 $8 $9
@@ -268,8 +267,8 @@ build -p SctPkg/UEFI/IHV_SCT.dsc -a $SCT_TARGET_ARCH -t 
$TARGET_TOOLS -b $SCT_BU
 status=$?
 if test $status -ne 0
 then
-echo Could not build the IHV SCT package
-exit -1
+  echo Could not build the IHV SCT package
+  exit -1
 fi
 
 
@@ -299,8 +298,8 @@ pwd
 status=$?
 if test $status -ne 0
 then
-echo Could not generate UEFI SCT binary
- exit -1
+  echo Could not generate UEFI SCT binary
+  exit -1
 else
 echo The SCT binary "SctPackage${SCT_TARGET_ARCH}" is located at 
"$EFI_SOURCE/Build/UefiSct/${SCT_BUILD}_${TARGET_TOOLS}"
 fi
@@ -315,8 +314,8 @@ pwd
 status=$?
 if test $status -ne 0
 then
-echo Could not generate IHV SCT binary
- exit -1
+  echo Could not generate IHV SCT binary
+  exit -1
 else
 echo The IHV binary "SctPackage${SCT_TARGET_ARCH}" is located at 
"$EFI_SOURCE/Build/IhvSct/${SCT_BUILD}_${TARGET_TOOLS}"
 fi
-- 
2.26.2



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

Re: [edk2-devel] [EXTERNAL] [PATCH v8 00/14] Add the VariablePolicy feature

[Laszlo Ersek]

On 09/23/20 23:34, Bret Barkelew wrote:
> Agreed. It's random that the previous config worked.

Here's an idea.

Assume we have two DXE drivers (D1 and D2), each of which registers an
EndOfDxe notification function (each to be queued at TPL_CALLBACK or
TPL_NOTIFY, doesn't matter).

Assume D1 does something in its EndOfDxe handler that breaks if D2's
EndOfDxe handler runs first. Let's call the offending action in D2's
EndOfDxe handler "Nastiness". (Scientific term.)

Further assume that D1 is an optional driver (while D2 is mandatory). D1
may or may not be included in the platform firmware.

Here's what the drivers could do, for ensuring that D1's handler runs
first, *if* D1 is included in the platform firmate:

(1) D2 defines (standardizes) a new, well-known protocol GUID. There is
no need for a protocol structure; it can be a null protocol.

If the protocol is present in the protocol database, that means that
Nastiness must not be performed by D2 in its EndOfDxe handler. For
simplicity, let's call the protocol EDKII_NO_NASTINESS_PLEASE_PROTOCOL.

(2) In its entry point function, D1 produces an instance of
EDKII_NO_NASTINESS_PLEASE_PROTOCOL. The protocol can be the sole
protocol on a new handle, or exist on another long-term handle (such as
gImageHandle).

(3) In its EndOfDxe handler, D1 uninstalls
EDKII_NO_NASTINESS_PLEASE_PROTOCOL (potentially destroying the handle as
well).

(This is safe because the handler is running at TPL_NOTIFY at the
highest, and uninstalling protocols is safe at <= TPL_NOTIFY. Memory
allocation services are also explicitly safe at <= TPL_NOTIFY.)

(4) D2 factors Nastiness out of its EndOfDxe handler to a new function.
This new function -- solely consisting of Nastiness -- has the usual
notification function prototype. Let's call it NastyFun().

(5) In its entry point function, D2 creates a new (private, not GUID-ed)
event, for which NastyFun() is the notification function. The TPL is
TPL_CALLBACK. Let's call the event NastyEvent.

(6) In D2's EndOfDxe handler, the original, open-coded Nastiness is
replaced with the following logic:

- If EDKII_NO_NASTINESS_PLEASE_PROTOCOL exists in the protocol database
(according to gBS->LocateProtocol(), then D2's EndOfDxe handler signals
NastyEvent.

(This is safe because LocateProtocol() is safe to call at up to and
including TPL_NOTIFY, and gBS->SignalEvent is safe even at TPL_HIGH_LEVEL.)

- Otherwise, D2's EndOfDxe calls NastyFun() with a normal function call.


It's supposed to work like this:

- If D1 is not in the firmware, it won't install
EDKII_NO_NASTINESS_PLEASE_PROTOCOL, so D2 performs Nastiness (via a
direct call to NastyFun()) on the call stack of its original EndOfDxe
handler. That is, no change in behavior.

- If D1's EndOfDxe handler completes first, D2's EndOfDxe handler will
again not see EDKII_NO_NASTINESS_PLEASE_PROTOCOL; so goto previous point.

- Multiple drivers similar to D1 may coexist; multiple
EDKII_NO_NASTINESS_PLEASE_PROTOCOL instances may coexist (all NULL
interfaces, but on different handles). If there is at least one,
gBS->LocateProtocol() in D2's EndOfDxe handler will find the first one,
and postpone Nastiness.

- When D2's EndOfDxe handler signals NastyEvent, NastyFun() will be
enqueued at TPL_CALLBACK. Note that, given that D2's EndOfDxe handler is
running at the moment, the EndOfDxe event group has been signaled
previously. This means *all* events in the EndOfDxe event group have
been signaled, and all their notification functions have been enqueued
too (in some unspecified order, except for the specified dispatch
ordering between TPL_NOTIFY and TPL_CALLBACK).

So when NastyEvent is signaled, NastyFun() is enqueued *after* all the
other -- already enqueued -- EndOfDxe notification functions. That's
because (a) NastyEvent uses TPL_CALLBACK, so the already pending
TPL_NOTIFY notifications will be dispatched before it of course, and (b)
regarding notify functions enqueued previously at the same TPL (=
TPL_CALLBACK), functions in any given TPL queue are queued / dispatched
in FIFO order.

By the time NastyFun() runs, it could ASSERT() that
EDKII_NO_NASTINESS_PLEASE_PROTOCOL does not exist.

Thanks
Laszlo

> On Wed, Sep 23, 2020 at 2:32 PM Andrew Fish  wrote:
> 
>>
>>
>> On Sep 23, 2020, at 2:14 PM, Bret Barkelew  wrote:
>>
>> As far as I can tell, this is exposing a pre-existing race condition in
>> EndOfDxe. It just so HAPPENS that the old "Disable RequestToLock"
>> callback executed after this TcgMor callback, whereas the new
>> VariablePolicy callback executes first.
>>
>> I'm going to poke around for a solution, but this seems like an
>> architectural problem with EndOfDxe.
>>
>>
>> The architecture does not guarantee order for the events. So if the events
>> are dependent on the order of other events that is a bug in implementation.
>> These kind of bugs are hard to notice as the DXE Core implementation event
>> dispatch in a fixed order, I think in the order the event was registered.
>> So it looks correc

[edk2-devel] [edk2-test] [PATCH 0/3] Fixes to SctPkg/build.sh

[Rebecca Cran]

I noticed the GCC5 SctPkg build was broken. This patch series
fixes it and also resolves a couple of other issues I found.

Rebecca Cran (3):
  uefi-sct/SctPkg: Fix build.sh when specifying GCC5 toolchain
  uefi-sct: Fix the mailing list address in Maintainers.txt and
Readme.md
  uefi-sct/SctPkg: Fix some indentation issues in build.sh

 uefi-sct/Maintainers.txt |  2 +-
 uefi-sct/Readme.md   |  2 +-
 uefi-sct/SctPkg/build.sh | 35 +--
 3 files changed, 19 insertions(+), 20 deletions(-)

-- 
2.26.2



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

[edk2-devel] [edk2-test] [PATCH 1/3] uefi-sct/SctPkg: Fix build.sh when specifying GCC5 toolchain

[Rebecca Cran]

build.sh usage indicates that "GCC5" can be specified, but it's currently
rejected due to a case statement only matching "GCC" or "gcc".
Fix this by adding a wildcard match.

Signed-off-by: Rebecca Cran 
---
 uefi-sct/SctPkg/build.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/uefi-sct/SctPkg/build.sh b/uefi-sct/SctPkg/build.sh
index cad17ccd..be610deb 100755
--- a/uefi-sct/SctPkg/build.sh
+++ b/uefi-sct/SctPkg/build.sh
@@ -151,7 +151,7 @@ case `uname` in
TARGET_TOOLS=ARMGCC
;;

-   GCC | gcc)
+   GCC* | gcc*)
 set_cross_compile
CROSS_COMPILE="$TEMP_CROSS_COMPILE"
 export TARGET_TOOLS=`get_gcc_version "$CROSS_COMPILE"gcc`
-- 
2.26.2



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

[edk2-devel] [PATCH v13 0/1] ShellPkg/DynamicCommand: add HttpDynamicCommand

[Vladimir Olovyannikov via groups.io]

Signed-off-by: Vladimir Olovyannikov 
Cc: Zhichao Gao 
Cc: Maciej Rabeda 
Cc: Jiaxin Wu 
Cc: Siyuan Fu 
Cc: Ray Ni 
Cc: Liming Gao 
Cc: Nd 
Cc: Laszlo Ersek 
Cc: Samer El-Haj-Mahmoud 

This patchset introduces an http client utilizing EDK2 HTTP protocol, to
allow fast image downloading from http/https servers.
HTTP download speed is usually faster than tftp.
The client is based on the same approach as tftp dynamic command, and
uses the same UEFI Shell command line parameters. This makes it easy
integrating http into existing UEFI Shell scripts.
Note that to enable HTTP download, feature Pcd
gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections must be set to TRUE.

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

PATCH v13 changes:
Address comments from Zhichao:
  - Fix overlooked edk2 code style issues.

Vladimir Olovyannikov (1):
  ShellPkg/DynamicCommand: add HttpDynamicCommand

 ShellPkg/ShellPkg.dec |1 +
 ShellPkg/ShellPkg.dsc |5 +
 .../HttpDynamicCommand/HttpApp.inf|   57 +
 .../HttpDynamicCommand/HttpDynamicCommand.inf |   62 +
 .../DynamicCommand/HttpDynamicCommand/Http.h  |   92 +
 ShellPkg/Include/Guid/ShellLibHiiGuid.h   |5 +
 .../DynamicCommand/HttpDynamicCommand/Http.c  | 1904 +
 .../HttpDynamicCommand/HttpApp.c  |   61 +
 .../HttpDynamicCommand/HttpDynamicCommand.c   |  137 ++
 .../HttpDynamicCommand/Http.uni   |  117 +
 10 files changed, 2441 insertions(+)
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/HttpApp.inf
 create mode 100644 
ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/Http.h
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/Http.c
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/HttpApp.c
 create mode 100644 
ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.c
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/Http.uni

-- 
2.28.0.394.ge197136389



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




smime.p7s
Description: S/MIME Cryptographic Signature

[edk2-devel] [PATCH v13 1/1] ShellPkg/DynamicCommand: add HttpDynamicCommand

[Vladimir Olovyannikov via groups.io]

Introduce an http client utilizing EDK2 HTTP protocol, to
allow fast image downloading from http/https servers.
HTTP download speed is usually faster than tftp.
The client is based on the same approach as tftp dynamic command, and
uses the same UEFI Shell command line parameters. This makes it easy
integrating http into existing UEFI Shell scripts.
Note that to enable HTTP download, feature Pcd
gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections must
be set to TRUE.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2860

Signed-off-by: Vladimir Olovyannikov 
Cc: Samer El-Haj-Mahmoud 
Cc: Laszlo Ersek 
Cc: Zhichao Gao 
Cc: Maciej Rabeda 
Cc: Jiaxin Wu 
Cc: Siyuan Fu 
Cc: Ray Ni 
Cc: Liming Gao 
Cc: Nd 
---
 ShellPkg/ShellPkg.dec |1 +
 ShellPkg/ShellPkg.dsc |5 +
 .../HttpDynamicCommand/HttpApp.inf|   57 +
 .../HttpDynamicCommand/HttpDynamicCommand.inf |   62 +
 .../DynamicCommand/HttpDynamicCommand/Http.h  |   92 +
 ShellPkg/Include/Guid/ShellLibHiiGuid.h   |5 +
 .../DynamicCommand/HttpDynamicCommand/Http.c  | 1904 +
 .../HttpDynamicCommand/HttpApp.c  |   61 +
 .../HttpDynamicCommand/HttpDynamicCommand.c   |  137 ++
 .../HttpDynamicCommand/Http.uni   |  117 +
 10 files changed, 2441 insertions(+)
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/HttpApp.inf
 create mode 100644 
ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/Http.h
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/Http.c
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/HttpApp.c
 create mode 100644 
ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.c
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/Http.uni

diff --git a/ShellPkg/ShellPkg.dec b/ShellPkg/ShellPkg.dec
index d0843d338126..7b2d1230bd2c 100644
--- a/ShellPkg/ShellPkg.dec
+++ b/ShellPkg/ShellPkg.dec
@@ -53,6 +53,7 @@ [Guids]
   gShellNetwork1HiiGuid   = {0xf3d301bb, 0xf4a5, 0x45a8, {0xb0, 0xb7, 
0xfa, 0x99, 0x9c, 0x62, 0x37, 0xae}}
   gShellNetwork2HiiGuid   = {0x174b2b5, 0xf505, 0x4b12, {0xaa, 0x60, 
0x59, 0xdf, 0xf8, 0xd6, 0xea, 0x37}}
   gShellTftpHiiGuid   = {0x738a9314, 0x82c1, 0x4592, {0x8f, 0xf7, 
0xc1, 0xbd, 0xf1, 0xb2, 0x0e, 0xd4}}
+  gShellHttpHiiGuid   = {0x390f84b3, 0x221c, 0x4d9e, {0xb5, 0x06, 
0x6d, 0xb9, 0x42, 0x3e, 0x0a, 0x7e}}
   gShellBcfgHiiGuid   = {0x5f5f605d, 0x1583, 0x4a2d, {0xa6, 0xb2, 
0xeb, 0x12, 0xda, 0xb4, 0xa2, 0xb6}}
   gShellAcpiViewHiiGuid   = {0xda8ccdf4, 0xed8f, 0x4ffc, {0xb5, 0xef, 
0x2e, 0xf5, 0x5e, 0x24, 0x93, 0x2a}}
   # FILE_GUID as defined in ShellPkg/Application/Shell/Shell.inf
diff --git a/ShellPkg/ShellPkg.dsc b/ShellPkg/ShellPkg.dsc
index 86e9f1e0040d..c42bc9464a0f 100644
--- a/ShellPkg/ShellPkg.dsc
+++ b/ShellPkg/ShellPkg.dsc
@@ -139,6 +139,11 @@ [Components]
   gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
   }
   ShellPkg/DynamicCommand/TftpDynamicCommand/TftpApp.inf
+  ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf {
+
+  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
+  }
+  ShellPkg/DynamicCommand/HttpDynamicCommand/HttpApp.inf
   ShellPkg/DynamicCommand/DpDynamicCommand/DpDynamicCommand.inf {
 
   gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
diff --git a/ShellPkg/DynamicCommand/HttpDynamicCommand/HttpApp.inf 
b/ShellPkg/DynamicCommand/HttpDynamicCommand/HttpApp.inf
new file mode 100644
index ..27b208b25437
--- /dev/null
+++ b/ShellPkg/DynamicCommand/HttpDynamicCommand/HttpApp.inf
@@ -0,0 +1,57 @@
+##  @file
+# Provides Shell 'http' standalone application.
+#
+# Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved. 
+# Copyright (c) 2015, ARM Ltd. All rights reserved.
+# Copyright (c) 2020, Broadcom. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010006
+  BASE_NAME  = http
+  FILE_GUID  = 56B00FB7-91D2-869B-CE5C-26CD1A89C73C
+  MODULE_TYPE= UEFI_APPLICATION
+  VERSION_STRING = 1.0
+  ENTRY_POINT= HttpAppInitialize
+#
+#  This flag specifies whether HII resource section is generated into PE image.
+#
+  UEFI_HII_RESOURCE_SECTION  = TRUE
+
+[Sources.common]
+  Http.c
+  HttpApp.c
+  Http.h
+  Http.uni
+
+[Packages]
+  MdeModulePkg/MdeModulePkg.dec
+  MdePkg/MdePkg.dec
+  NetworkPkg/NetworkPkg.dec
+  ShellPkg/ShellPkg.dec
+
+[LibraryClasses]
+  BaseLib
+  BaseMemoryLib
+  DebugLib
+  FileHandleLib
+  HiiLib
+  HttpLib
+  MemoryAllocationLib
+  NetLib
+  ShellLib
+  UefiApplicationEntryPoint
+  UefiBootServicesTableLib
+  UefiHiiServicesLib
+  UefiLib
+  UefiRuntimeServicesTableLib
+
+[Protocols]
+  gEfiHiiPackageListProtocolGuid

Re: [edk2-devel] TianoCore Community Design Meeting Minutes - Sep 18, 2020

[Rothman, Michael A]

I have some comments for the items below…. And a proposed solution, I think.

Thanks,
Mike Rothman
(迈克 罗斯曼 / माइकल रोथ्मेन् / Михаил Ротман / משה רוטמן)
רועה עיקרי של חתולים

From: Ni, Ray 
Sent: Thursday, September 17, 2020 9:28 PM
To: devel@edk2.groups.io
Cc: Wang, Sunny (HPS SW) ; Rothman, Michael A 
; Aggarwal, Nivedita 
; Desimone, Nathaniel L 
; Kinney, Michael D 
; Dong, Eric ; Wu, Hao A 
; Bi, Dandan 
Subject: TianoCore Community Design Meeting Minutes - Sep 18, 2020

Topic: Sanitization Protocols for Option Cards (Sunny Wang / HPE)

Slides: 
https://edk2.groups.io/g/devel/files/Designs/2020/0918/Sanitization%20Protocols%20for%20Option%20Cards_200918.pdf

More materials @ https://edk2.groups.io/g/devel/files/Designs/2020/0918/

1. Overview

Sunny presented HPE's UEFI Spec change proposal to meet NIST SP 800-88 
standard, sanitizing the firmware configuration and storage devices.

NIST SP 800-88:  HPE as the server vendor should be compliant to this standard.

Option Card = PCI device that contains Option ROM.

  2. Sanitizing firmware configuration

@Liming: HII design provides mechanism to restore the default.
@Nickle: Problems in HII: 1). Cannot support cases like removing iSCSI attempt 
password. 2). Default value for some HII settings is not available.
@Liming: We should follow the principle that anyone that produces the data is 
responsible for clearing/sanitizing.

Agree with this.

@Nickle: The design aligns to this idea.
@Ray: The requirements of clear and purge are different. Purge cannot be 
recovered. Clear can.

Yes, but if we are talking about HII menuing features, such as through the 
setup browser, various action buttons could trigger custom responses via 
callbacks into the driver. This would be no different in concept to triggering 
the desire to Format a raid array. HII has no concept of that, but it’s 
supported via a cooperation between the browser triggering a callback based on 
the user selection of a custom action op-code and the driver that services that 
callback. So a menu could contain a clear and/or purge command, it’s just 
dependent on the design of the IFR pages and driver. I would also note that we 
have a standard EFI_RESET_BUTTON_OP which sounds like a Clear operation.

I thought about the possibility of adding a purge operation as a new op-code, 
but it doesn’t really make sense to me since purging alone may very well leave 
the device’s configuration in an invalid state, and a restore to defaults would 
need to be done immediately after the purge so that we at least have a working 
configuration that has been purged. Both of those operations could be described 
and done via the EFI_RESET_BUTTON_OP operation. There might be some 
clarifications we could do to the spec, but I’m wondering – isn’t it the 
purview of the driver implementation that services the reset to actually KNOW 
what the policy is for that device and whether or not a reset actually means a 
clear and then reset, or a purge and then reset? I think it is.

@Nate: EFI_ is reserved prefix.
@Liming: Suggest to follow the code first process 
(https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Code-First-Process)
 to use proper prefix.
@Ray: Let's firstly see how to enhance HII design to support such requirement.

3. Sanitizing storage devices

@Nivedita: Internal discussion in Intel prefers to reuse BlockErase.
@Sunny: Some non-block devices may also need to sanitize. BlockErase cannot 
meet the needs.
@Ray: An example of non-block device is the label storage in NVDIMM.

I agree – so, similar to what we did in EraseBlock, I would suggest we extend 
the label storage protocol – something such as:

#define EFI_NVDIMM_LABEL_PROTOCOL2_GUID \
  {0xc2f67a65,0x9d98,0x4608, \
   {0x98,0xe3,0x83,0x90,0x57,0x51,0xd1,0x04}}

typedef struct _EFI_NVDIMM_LABEL_PROTOCOL2 {
   EFI_NVDIMM_LABEL_STORAGE_INFORMATION LabelStorageInformation;
   EFI_NVDIMM_LABEL_STORAGE_READLabelStorageRead;
   EFI_NVDIMM_LABEL_STORAGE_WRITE   LabelStorageWrite;
   EFI_NVDIMM_LABEL_STORAGE_ERASE   Erase;
}


EFI_NVDIMM_LABEL_PROTOCOL.Erase()
Summary
Erase the label data for the Label Storage Area that is associated with a 
specific NVDIMM Device Path.
Prototype
typedef
EFI_STATUS
(EFIAPI *EFI_NVDIMM_LABEL_STORAGE_ERASE) (
   IN  CONST  EFI_NVDIMM_LABEL_PROTOCOL*This,
   INEFI_LABEL_ERASE_TYPE EraseType
   );
Parameters
ThisA pointer to the 
EFI_NVDIMM_LABEL_PROTOCOL instance.
EraseType   The type of erase that 
should be completed on the Label Storage Area for the NVDIMM.

Description
Erase the data per the method specified by EraseType for the Label Storage Area 
for the NVDIMM.   See the Label Index Block and Label Definitions sections 
below for details on the contents of the label data.

typedef enum {
  Overwrite,
 BlockErase,
  CryptoErase
} EFI_LABEL_ERASE_TYPE;

Overwr

Re: [edk2-devel] [PATCH v2 1/1] UefiCpuPkg/MpInitLib: Reduce reset vector memory pressure

[Laszlo Ersek]

On 09/24/20 15:30, Tom Lendacky wrote:
> On 9/24/20 1:22 AM, Laszlo Ersek wrote:
>> On 09/23/20 20:04, Tom Lendacky wrote:
>>> From: Tom Lendacky 
>>>
>>> The AP reset vector stack allocation is only required if running as an
>>> SEV-ES guest. Since the reset vector allocation is below 1MB in memory,
>>> eliminate the requirement for bare-metal systems and non SEV-ES guests
>>> to allocate the extra stack area, which can be large if the
>>> PcdCpuMaxLogicalProcessorNumber value is large, and also remove the
>>> CPU_STACK_ALIGNMENT alignment.
>>>
>>> Fixes: 7b7508ad784d ("UefiCpuPkg: Allow AP booting under SEV-ES")
>>> Cc: Garrett Kirkendall 
>>> Signed-off-by: Tom Lendacky 
>>> ---
>>>   UefiCpuPkg/Library/MpInitLib/MpLib.c | 36 +---
>>>   1 file changed, 17 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c
>>> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
>>> index 07426274f639..a9708c6479d2 100644
>>> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
>>> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
>>> @@ -1141,20 +1141,6 @@ RestoreWakeupBuffer(
>>>   );
>>>   }
>>>   -/**
>>> -  Calculate the size of the reset stack.
>>> -
>>> -  @return Total amount of memory required for stacks
>>> -**/
>>> -STATIC
>>> -UINTN
>>> -GetApResetStackSize (
>>> -  VOID
>>> -  )
>>> -{
>>> -  return AP_RESET_STACK_SIZE *
>>> PcdGet32(PcdCpuMaxLogicalProcessorNumber);
>>> -}
>>> -
>>>   /**
>>>     Calculate the size of the reset vector.
>>>   @@ -1170,11 +1156,23 @@ GetApResetVectorSize (
>>>   {
>>>     UINTN  Size;
>>>   -  Size = ALIGN_VALUE (AddressMap->RendezvousFunnelSize +
>>> -    AddressMap->SwitchToRealSize +
>>> -    sizeof (MP_CPU_EXCHANGE_INFO),
>>> -  CPU_STACK_ALIGNMENT);
>>> -  Size += GetApResetStackSize ();
>>> +  Size = AddressMap->RendezvousFunnelSize +
>>> +   AddressMap->SwitchToRealSize +
>>> +   sizeof (MP_CPU_EXCHANGE_INFO);
>>> +
>>> +  //
>>> +  // The AP reset stack is only used by SEV-ES guests. Do not add to
>>> the
>>> +  // allocation if SEV-ES is not enabled.
>>> +  //
>>> +  if (PcdGetBool (PcdSevEsIsEnabled)) {
>>> +    //
>>> +    // Stack location is based on APIC ID, so use the total number of
>>> +    // processors for calculating the total stack area.
>>> +    //
>>> +    Size += AP_RESET_STACK_SIZE *
>>> PcdGet32(PcdCpuMaxLogicalProcessorNumber);
>>> +
>>> +    Size = ALIGN_VALUE (Size, CPU_STACK_ALIGNMENT);
>>> +  }
>>>       return Size;
>>>   }
>>>
>>
>> - I don't remember if it's required that the APIC ID space be densely
>> populated. For example, if we have a topology with 7 possible (=
>> maximum) logical CPUs, I'm unsure if a spec forbids any of those CPUs
>> from having APIC ID 7. That could cause a problem in
>> MpInitLibSevEsAPReset(), I assume.
>>
>> Anyway: that's a different topic. This patch looks OK to me because it
>> only spells out the existent assumption wrt. APIC IDs vs.
>> PcdCpuMaxLogicalProcessorNumber, plus it does solve the problem it wants
>> to solve.
>>
>> - I was a bit surprised at first upon seeing the reordering of alignment
>> vs. addition. But AP_RESET_STACK_SIZE is a whole multiple of
>> CPU_STACK_ALIGNMENT. So adding AP_RESET_STACK_SIZE to Size n times as
>> first step, does not change the congruence class of Size modulo
>> CPU_STACK_ALIGNMENT. Therefore ALIGN_VALUE() will increment Size by the
>> same value, regardless of whether it's done before or after the
>> AP_RESET_STACK_SIZE additions.
> 
> Ah, yes, I did change that order. I could submit one more version that
> puts the ALIGN_VALUE back to the original position and fix the PcdGet32
> space if that is desired (but, as you determined, it doesn't change the
> resulting value).

Given that the stack grows down, one could plausibly claim that the
variant seen in this patch (= align at last) is *more* intuitive.

I'm OK with this version merged (with the whitespace fixed up).

> I'm surprised that PatchCheck.py didn't pick up on the
> spacing with PcdGet32.

Or maybe ECC should warn about it in CI?...

Thanks
Laszlo



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

Re: [edk2-devel] [PATCH] BaseTools: Add RISCV64 binding

[Abner Chang]

Acked-by: Abner Chang 

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Nikita
> Sent: Tuesday, September 22, 2020 6:38 PM
> To: devel@edk2.groups.io
> Cc: Nikita Ermakov 
> Subject: [edk2-devel] [PATCH] BaseTools: Add RISCV64 binding
> 
> - Add RISCV64 ProcessorBind.h
> 
> - Add RISCV64 to Makefiles
> 
> Signed-off-by: Nikita Ermakov 
> ---
>  BaseTools/Source/C/GNUmakefile|  3 +
>  .../Source/C/Include/RiscV64/ProcessorBind.h  | 85 +++
> BaseTools/Source/C/Makefiles/header.makefile  |  6 ++
>  3 files changed, 94 insertions(+)
>  create mode 100644 BaseTools/Source/C/Include/RiscV64/ProcessorBind.h
> 
> diff --git a/BaseTools/Source/C/GNUmakefile
> b/BaseTools/Source/C/GNUmakefile index df4eb64ea9..464f432774 100644
> --- a/BaseTools/Source/C/GNUmakefile
> +++ b/BaseTools/Source/C/GNUmakefile
> @@ -26,6 +26,9 @@ ifndef HOST_ARCH
>else ifneq (,$(findstring arm,$(uname_m)))
>  HOST_ARCH=ARM
>endif
> +  ifneq (,$(findstring riscv64,$(uname_m)))
> +HOST_ARCH=RISCV64
> +  endif
>ifndef HOST_ARCH
>  $(info Could not detected HOST_ARCH from uname results)
>  $(error HOST_ARCH is not defined!)
> diff --git a/BaseTools/Source/C/Include/RiscV64/ProcessorBind.h
> b/BaseTools/Source/C/Include/RiscV64/ProcessorBind.h
> new file mode 100644
> index 00..1612d6ea7f
> --- /dev/null
> +++ b/BaseTools/Source/C/Include/RiscV64/ProcessorBind.h
> @@ -0,0 +1,85 @@
> +/** @file
> +  Processor or Compiler specific defines and types for RISC-V.
> +
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#ifndef __PROCESSOR_BIND_H__
> +#define __PROCESSOR_BIND_H__
> +
> +//
> +// Define the processor type so other code can make processor based
> +choices // #define MDE_CPU_RISCV64
> +
> +//
> +// Make sure we are using the correct packing rules per EFI
> +specification // #ifndef __GNUC__ #pragma pack() #endif
> +
> +//
> +// Use ANSI C 2000 stdint.h integer width declarations // #include
> +
> +typedef uint8_t   BOOLEAN;
> +typedef int8_tINT8;
> +typedef uint8_t   UINT8;
> +typedef int16_t   INT16;
> +typedef uint16_t  UINT16;
> +typedef int32_t   INT32;
> +typedef uint32_t  UINT32;
> +typedef int64_t   INT64;
> +typedef uint64_t  UINT64;
> +typedef char  CHAR8;
> +typedef uint16_t  CHAR16;
> +
> +//
> +// Unsigned value of native width.  (4 bytes on supported 32-bit
> +processor instructions, // 8 bytes on supported 64-bit processor
> +instructions) // typedef UINT64  UINTN;
> +
> +//
> +// Signed value of native width.  (4 bytes on supported 32-bit
> +processor instructions, // 8 bytes on supported 64-bit processor
> +instructions) //
> +typedef INT64   INTN;
> +
> +//
> +// Processor specific defines
> +//
> +
> +//
> +// A value of native width with the highest bit set.
> +//
> +#define MAX_BIT  0x8000
> +
> +//
> +// A value of native width with the two highest bits set.
> +//
> +#define MAX_2_BITS   0xC000
> +
> +//
> +// The stack alignment required for RISC-V // #define
> +CPU_STACK_ALIGNMENT  16
> +
> +//
> +// Modifier to ensure that all protocol member functions and EFI
> +intrinsics // use the correct C calling convention. All protocol member
> +functions and // EFI intrinsics are required to modify their member
> functions with EFIAPI.
> +//
> +#define EFIAPI
> +
> +#if defined(__GNUC__)
> +  //
> +  // For GNU assembly code, .global or .globl can declare global symbols.
> +  // Define this macro to unify the usage.
> +  //
> +  #define ASM_GLOBAL .globl
> +#endif
> +
> +#endif
> diff --git a/BaseTools/Source/C/Makefiles/header.makefile
> b/BaseTools/Source/C/Makefiles/header.makefile
> index 1c105ee7d4..0df728f327 100644
> --- a/BaseTools/Source/C/Makefiles/header.makefile
> +++ b/BaseTools/Source/C/Makefiles/header.makefile
> @@ -28,6 +28,9 @@ ifndef HOST_ARCH
>else ifneq (,$(findstring arm,$(uname_m)))
>  HOST_ARCH=ARM
>endif
> +  ifneq (,$(findstring riscv64,$(uname_m)))
> +HOST_ARCH=RISCV64
> +  endif
>ifndef HOST_ARCH
>  $(info Could not detected HOST_ARCH from uname results)
>  $(error HOST_ARCH is not defined!)
> @@ -64,6 +67,9 @@ ARCH_INCLUDE = -I $(MAKEROOT)/Include/Arm/  else
> ifeq ($(HOST_ARCH), AARCH64)  ARCH_INCLUDE = -I
> $(MAKEROOT)/Include/AArch64/
> 
> +else ifeq ($(HOST_ARCH), RISCV64)
> +ARCH_INCLUDE = -I $(MAKEROOT)/Include/RiscV64/
> +
>  else
>  $(error Bad HOST_ARCH)
>  endif
> --
> 2.28.0
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH v2 1/1] UefiCpuPkg/MpInitLib: Reduce reset vector memory pressure

[Lendacky, Thomas]

On 9/24/20 1:22 AM, Laszlo Ersek wrote:

On 09/23/20 20:04, Tom Lendacky wrote:

From: Tom Lendacky 

The AP reset vector stack allocation is only required if running as an
SEV-ES guest. Since the reset vector allocation is below 1MB in memory,
eliminate the requirement for bare-metal systems and non SEV-ES guests
to allocate the extra stack area, which can be large if the
PcdCpuMaxLogicalProcessorNumber value is large, and also remove the
CPU_STACK_ALIGNMENT alignment.

Fixes: 7b7508ad784d ("UefiCpuPkg: Allow AP booting under SEV-ES")
Cc: Garrett Kirkendall 
Signed-off-by: Tom Lendacky 
---
  UefiCpuPkg/Library/MpInitLib/MpLib.c | 36 +---
  1 file changed, 17 insertions(+), 19 deletions(-)

diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
b/UefiCpuPkg/Library/MpInitLib/MpLib.c
index 07426274f639..a9708c6479d2 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
@@ -1141,20 +1141,6 @@ RestoreWakeupBuffer(
  );
  }
  
-/**

-  Calculate the size of the reset stack.
-
-  @return Total amount of memory required for stacks
-**/
-STATIC
-UINTN
-GetApResetStackSize (
-  VOID
-  )
-{
-  return AP_RESET_STACK_SIZE * PcdGet32(PcdCpuMaxLogicalProcessorNumber);
-}
-
  /**
Calculate the size of the reset vector.
  
@@ -1170,11 +1156,23 @@ GetApResetVectorSize (

  {
UINTN  Size;
  
-  Size = ALIGN_VALUE (AddressMap->RendezvousFunnelSize +

-AddressMap->SwitchToRealSize +
-sizeof (MP_CPU_EXCHANGE_INFO),
-  CPU_STACK_ALIGNMENT);
-  Size += GetApResetStackSize ();
+  Size = AddressMap->RendezvousFunnelSize +
+   AddressMap->SwitchToRealSize +
+   sizeof (MP_CPU_EXCHANGE_INFO);
+
+  //
+  // The AP reset stack is only used by SEV-ES guests. Do not add to the
+  // allocation if SEV-ES is not enabled.
+  //
+  if (PcdGetBool (PcdSevEsIsEnabled)) {
+//
+// Stack location is based on APIC ID, so use the total number of
+// processors for calculating the total stack area.
+//
+Size += AP_RESET_STACK_SIZE * PcdGet32(PcdCpuMaxLogicalProcessorNumber);
+
+Size = ALIGN_VALUE (Size, CPU_STACK_ALIGNMENT);
+  }
  
return Size;

  }



- I don't remember if it's required that the APIC ID space be densely
populated. For example, if we have a topology with 7 possible (=
maximum) logical CPUs, I'm unsure if a spec forbids any of those CPUs
from having APIC ID 7. That could cause a problem in
MpInitLibSevEsAPReset(), I assume.

Anyway: that's a different topic. This patch looks OK to me because it
only spells out the existent assumption wrt. APIC IDs vs.
PcdCpuMaxLogicalProcessorNumber, plus it does solve the problem it wants
to solve.

- I was a bit surprised at first upon seeing the reordering of alignment
vs. addition. But AP_RESET_STACK_SIZE is a whole multiple of
CPU_STACK_ALIGNMENT. So adding AP_RESET_STACK_SIZE to Size n times as
first step, does not change the congruence class of Size modulo
CPU_STACK_ALIGNMENT. Therefore ALIGN_VALUE() will increment Size by the
same value, regardless of whether it's done before or after the
AP_RESET_STACK_SIZE additions.


Ah, yes, I did change that order. I could submit one more version that 
puts the ALIGN_VALUE back to the original position and fix the PcdGet32 
space if that is desired (but, as you determined, it doesn't change the 
resulting value). I'm surprised that PatchCheck.py didn't pick up on the 
spacing with PcdGet32.


Thanks,
Tom



- We should insert a space character after "PcdGet32", before merging
this patch. I think Ray or Eric could do this without a repost.

Reviewed-by: Laszlo Ersek 

Thanks
Laszlo




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

Re: [edk2-devel] [PATCH v2 0/2] UEFI memmap workaround for hiding page-access caps from OSes hides SP and CRYPTO caps too

[Laszlo Ersek]

On 09/24/20 12:21, Malgorzata Kukiello wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2982
> 
> The workaround in the UEFI memmap construction, near the end of the
> function CoreGetMemoryMap() [MdeModulePkg/Core/Dxe/Mem/Page.c] should
> not clear the SP and CRYPTO bits, because OSes do (apparently) correctly
> interpret SP and CRYPTO as capabilities, and not as currently set
> attributes (upon which the OSes should set their page tables). For this
> reason, the SP and CRYPTO bits should be separated from the bitmask that
> we use for hiding the page-access attributes, in the workaround
> 
> Signed-off-by: Malgorzata Kukiello 
> Cc: Michael D Kinney 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Dandan Bi 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Oleksiy Yakovlev 
> Cc: Ard Biesheuvel (ARM address) 
> 
>  MdeModulePkg/Core/Dxe/Mem/Page.c | 12 ++--
>  MdePkg/Include/Uefi/UefiSpec.h   |  3 ++-
>  2 files changed, 8 insertions(+), 7 deletions(-)

series
Reviewed-by: Laszlo Ersek 



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

[edk2-devel] [PATCH v2 2/2] MdeModulePkg/Core/Dxe: expose SP and CRYPTO capabilities in UEFI memmap

[Malgorzata Kukiello]

OSs are now capable of treating SP and CRYPTO memory as true capabilities
and therefore these should be exposed. This requires usage of a separate
ACCESS_MASK to hide all page-access permission capabilities.
Change in masking and hiding of SP and CRYPTO was introduced in 
3bd5c994c879f78e8e3d5346dc3b627f199291aa

Signed-off-by: Malgorzata Kukiello 
Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Oleksiy Yakovlev 
Cc: Ard Biesheuvel (ARM address) 
---
 MdeModulePkg/Core/Dxe/Mem/Page.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c b/MdeModulePkg/Core/Dxe/Mem/Page.c
index 2c2c9cd6c3..731bf08bc9 100644
--- a/MdeModulePkg/Core/Dxe/Mem/Page.c
+++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
@@ -1924,16 +1924,16 @@ CoreGetMemoryMap (
   //   set attributes and change memory paging attribute accordingly.
   //   But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
   //   value from Capabilities in GCD memory map. This might cause
-  //   boot problems. Clearing all paging related capabilities can
-  //   workaround it. Following code is supposed to be removed once
-  //   the usage of EFI_MEMORY_DESCRIPTOR.Attribute is clarified in
-  //   UEFI spec and adopted by both EDK-II Core and all supported
-  //   OSs.
+  //   boot problems. Clearing all page-access permission related
+  //   capabilities can workaround it. Following code is supposed to
+  //   be removed once the usage of EFI_MEMORY_DESCRIPTOR.Attribute
+  //   is clarified in UEFI spec and adopted by both EDK-II Core and
+  //   all supported OSs.
   //
   MemoryMapEnd = MemoryMap;
   MemoryMap = MemoryMapStart;
   while (MemoryMap < MemoryMapEnd) {
-MemoryMap->Attribute &= ~(UINT64)EFI_MEMORY_ATTRIBUTE_MASK;
+MemoryMap->Attribute &= ~(UINT64)EFI_MEMORY_ACCESS_MASK;
 MemoryMap = NEXT_MEMORY_DESCRIPTOR (MemoryMap, Size);
   }
   MergeMemoryMap (MemoryMapStart, &BufferSize, Size);
-- 
2.18.0.windows.1

-
Intel Technology Poland sp. z o.o.
ul. Sowackiego 173 | 80-298 Gdask | Sd Rejonowy Gdask Pnoc | VII Wydzia 
Gospodarczy Krajowego Rejestru Sdowego - KRS 101882 | NIP 957-07-52-316 | 
Kapita zakadowy 200.000 PLN.
Ta wiadomo wraz z zacznikami jest przeznaczona dla okrelonego adresata i moe 
zawiera informacje poufne. W razie przypadkowego otrzymania tej wiadomoci, 
prosimy o powiadomienie nadawcy oraz trwae jej usunicie; jakiekolwiek 
przegldanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). If you are not the intended recipient, please 
contact the sender and delete all copies; any review or distribution by others 
is strictly prohibited.
 



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

[edk2-devel] [PATCH v2 1/2] MdePkg/UefiSpec: separate page access bitmask from SP and CRYPTO caps

[Malgorzata Kukiello]

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

Operating systems are capable of treating SP and CRYPTO memory capabilities
and not as attributes. This means that these capabilites cannot be hidden
from OSs. For this reason, the SP and CRYPTO bits should be separated from
the bitmask that we use for hiding the page-access attributes. 
Common mask for ATTRIBUTES was introduced in 
3bd5c994c879f78e8e3d5346dc3b627f199291aa

Signed-off-by: Malgorzata Kukiello 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Oleksiy Yakovlev 
Cc: Ard Biesheuvel (ARM address) 
---
 MdePkg/Include/Uefi/UefiSpec.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/Uefi/UefiSpec.h b/MdePkg/Include/Uefi/UefiSpec.h
index 05b82e0be1..2b1b72d862 100644
--- a/MdePkg/Include/Uefi/UefiSpec.h
+++ b/MdePkg/Include/Uefi/UefiSpec.h
@@ -113,7 +113,8 @@ typedef enum {
 // Attributes bitmasks, grouped by type
 //
 #define EFI_CACHE_ATTRIBUTE_MASK (EFI_MEMORY_UC | EFI_MEMORY_WC | 
EFI_MEMORY_WT | EFI_MEMORY_WB | EFI_MEMORY_UCE | EFI_MEMORY_WP)
-#define EFI_MEMORY_ATTRIBUTE_MASK (EFI_MEMORY_RP | EFI_MEMORY_XP | 
EFI_MEMORY_RO | EFI_MEMORY_SP | EFI_MEMORY_CPU_CRYPTO)
+#define EFI_MEMORY_ACCESS_MASK (EFI_MEMORY_RP | EFI_MEMORY_XP | EFI_MEMORY_RO)
+#define EFI_MEMORY_ATTRIBUTE_MASK (EFI_MEMORY_ACCESS_MASK | EFI_MEMORY_SP | 
EFI_MEMORY_CPU_CRYPTO)
 
 ///
 /// Memory descriptor version number.
-- 
2.18.0.windows.1

-
Intel Technology Poland sp. z o.o.
ul. Sowackiego 173 | 80-298 Gdask | Sd Rejonowy Gdask Pnoc | VII Wydzia 
Gospodarczy Krajowego Rejestru Sdowego - KRS 101882 | NIP 957-07-52-316 | 
Kapita zakadowy 200.000 PLN.
Ta wiadomo wraz z zacznikami jest przeznaczona dla okrelonego adresata i moe 
zawiera informacje poufne. W razie przypadkowego otrzymania tej wiadomoci, 
prosimy o powiadomienie nadawcy oraz trwae jej usunicie; jakiekolwiek 
przegldanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). If you are not the intended recipient, please 
contact the sender and delete all copies; any review or distribution by others 
is strictly prohibited.
 



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

[edk2-devel] [PATCH v2 0/2] UEFI memmap workaround for hiding page-access caps from OSes hides SP and CRYPTO caps too

[Malgorzata Kukiello]

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

The workaround in the UEFI memmap construction, near the end of the
function CoreGetMemoryMap() [MdeModulePkg/Core/Dxe/Mem/Page.c] should
not clear the SP and CRYPTO bits, because OSes do (apparently) correctly
interpret SP and CRYPTO as capabilities, and not as currently set
attributes (upon which the OSes should set their page tables). For this
reason, the SP and CRYPTO bits should be separated from the bitmask that
we use for hiding the page-access attributes, in the workaround

Signed-off-by: Malgorzata Kukiello 
Cc: Michael D Kinney 
Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Oleksiy Yakovlev 
Cc: Ard Biesheuvel (ARM address) 

 MdeModulePkg/Core/Dxe/Mem/Page.c | 12 ++--
 MdePkg/Include/Uefi/UefiSpec.h   |  3 ++-
 2 files changed, 8 insertions(+), 7 deletions(-)
-
Intel Technology Poland sp. z o.o.
ul. Sowackiego 173 | 80-298 Gdask | Sd Rejonowy Gdask Pnoc | VII Wydzia 
Gospodarczy Krajowego Rejestru Sdowego - KRS 101882 | NIP 957-07-52-316 | 
Kapita zakadowy 200.000 PLN.
Ta wiadomo wraz z zacznikami jest przeznaczona dla okrelonego adresata i moe 
zawiera informacje poufne. W razie przypadkowego otrzymania tej wiadomoci, 
prosimy o powiadomienie nadawcy oraz trwae jej usunicie; jakiekolwiek 
przegldanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). If you are not the intended recipient, please 
contact the sender and delete all copies; any review or distribution by others 
is strictly prohibited.
 



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

[edk2-devel] [PATCH v2 2/2] ShellPkg/AcpiView: Fix field validator invocation

[Sami Mujawar]

The field validator function provides means to validate fields
in the ACPI table structures. To print complex field types a
print formatter function is provided.

The field validator was being invoked for simple data fields
for which the default print format is used. However, the field
validator function was not invoked if a print formatter function
was provided.

This problem is noticed when a Generic Address Structure (GAS)
is printed using DumpGas() and a field validator is present
to validate the GAS structure.

To fix this move the invocation of the field validator after
the field is printed such that the validation function is
called even when a print formatter function is present.

Signed-off-by: Sami Mujawar 
---

Notes:
v2:
 - This is a new patch introduced in v2 series. [SAMI]

 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
index 
02f6d771c7e1a9b8faa577b38e51c9de350d24fd..01ac9a9bafeb2ca12c1ba19f406d626b108f5fe2
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
@@ -1,7 +1,7 @@
 /** @file
   ACPI parser
 
-  Copyright (c) 2016 - 2020, ARM Limited. All rights reserved.
+  Copyright (c) 2016 - 2020, Arm Limited. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 **/
 
@@ -596,13 +596,12 @@ ParseAcpi (
   Parser[Index].Length
   );
 } // switch
-
-// Validating only makes sense if we are tracing
-// the parsed table entries, to report by table name.
-if (GetConsistencyChecking () &&
-(Parser[Index].FieldValidator != NULL)) {
-  Parser[Index].FieldValidator (Ptr, Parser[Index].Context);
-}
+  }
+  // Validating only makes sense if we are tracing
+  // the parsed table entries, to report by table name.
+  if (GetConsistencyChecking () &&
+  (Parser[Index].FieldValidator != NULL)) {
+Parser[Index].FieldValidator (Ptr, Parser[Index].Context);
   }
   Print (L"\n");
 } // if (Trace)
-- 
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'



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

[edk2-devel] [PATCH v2 0/2] ShellPkg/Acpiview: Add support for PCCT parser

[Sami Mujawar]

This patch series:
 - Addresses the feedback for v1 patch for PCCT parser.
 - Fixes an issue wherein the field validation is not
   invoked when a print formatter is present.

The changes can be seen at:
https://github.com/samimujawar/edk2/tree/840_pcct_parser_v2

Marc Moisson-Franckhauser (1):
  ShellPkg/AcpiView: PCCT Parser

Sami Mujawar (1):
  ShellPkg/AcpiView: Fix field validator invocation

 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c| 
 15 +-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h| 
 24 +-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiTableParser.h   | 
  4 +-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pcct/PcctParser.c   | 
615 
 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pcct/PcctParser.h   | 
 33 ++
 ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.c   | 
  4 +-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.inf | 
  4 +-
 7 files changed, 686 insertions(+), 13 deletions(-)
 create mode 100644 
ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pcct/PcctParser.c
 create mode 100644 
ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pcct/PcctParser.h

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



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

[edk2-devel] [PATCH v1 1/1] UefiPayloadPkg: Set default PciBaseSize on Ia32

[Marcello Sylvester Bauer]

Add missing PcdPciExpressBaseSize default on Ia32 targets analog to X64.

This adjustment relates to the changes in commit:
8028b2907e20b21cd7d69639a36ac82a77c81dc1

Signed-off-by: Marcello Sylvester Bauer 
Cc: Patrick Rudolph 
Cc: Maurice Ma 
Cc: Guo Dong 
Cc: Benjamin You 
---
 UefiPayloadPkg/UefiPayloadPkgIa32.dsc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/UefiPayloadPkg/UefiPayloadPkgIa32.dsc 
b/UefiPayloadPkg/UefiPayloadPkgIa32.dsc
index 12d7ffe81416..36ed460053d0 100644
--- a/UefiPayloadPkg/UefiPayloadPkgIa32.dsc
+++ b/UefiPayloadPkg/UefiPayloadPkgIa32.dsc
@@ -364,6 +364,7 @@ [PcdsDynamicDefault]
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutRow|31
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutColumn|100
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0
+  gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseSize|0
 
 

 #
-- 
2.28.0



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

[edk2-devel] [PATCH v1 0/1] UefiPayloadPkg: Set default PciBaseSize on Ia32

[Marcello Sylvester Bauer]

In commit 8028b2907e20b21cd7d69639a36ac82a77c81dc1 I did forget to set the
default value for PcdPciExpressBaseSize on Ia32 Targets. This patch does
inserts it afterwards.

Branch: https://github.com/9elements/edk2-1/tree/UefiPayloadPkg/MMCONF_IA32
PR: https://github.com/tianocore/edk2/pull/956

Marcello Sylvester Bauer (1):
  UefiPayloadPkg: Set default PciBaseSize on Ia32

 UefiPayloadPkg/UefiPayloadPkgIa32.dsc | 1 +
 1 file changed, 1 insertion(+)

-- 
2.28.0



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

[edk2-devel] [PATCH v2 1/2] ShellPkg/AcpiView: PCCT Parser

[Sami Mujawar]

From: Marc Moisson-Franckhauser 

Create a new parser for the PCCT Table.

The PCCT Table is used to describe how the OSPM can
communicate with entities outside the platform. It
describes which memory spaces correspond to which
entity as well as a few of the needed information
to handle the communications.

This new PCCT parser dumps the values and names of
the table fields. It also performs some validation
on the table's fields.

Signed-off-by: Marc Moisson-Franckhauser 
Signed-off-by: Sami Mujawar 
---

Notes:
v2:
 - Addressed review comments by adding validation functions [SAMI]
   for Doorbell, Interrupt Ack and Error Status GAS fields.
   Also added validation to check if the global platform
   interrupt flag is set for type 4 structure.

 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h| 
 24 +-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiTableParser.h   | 
  4 +-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pcct/PcctParser.c   | 
615 
 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pcct/PcctParser.h   | 
 33 ++
 ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.c   | 
  4 +-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.inf | 
  4 +-
 6 files changed, 679 insertions(+), 5 deletions(-)

diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
index 
f81ccac7e118378aa185db4b625e5bcd75f78347..051fdf807abb1067a264c136364bb6d145b38dab
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
@@ -1,7 +1,7 @@
 /** @file
   Header file for ACPI parser
 
-  Copyright (c) 2016 - 2020, ARM Limited. All rights reserved.
+  Copyright (c) 2016 - 2020, Arm Limited. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 **/
 
@@ -671,6 +671,28 @@ ParseAcpiMcfg (
   );
 
 /**
+  This function parses the ACPI PCCT table including its sub-structures
+  of type 0 through 4.
+  When trace is enabled this function parses the PCCT table and
+  traces the ACPI table fields.
+
+  This function also performs validation of the ACPI table fields.
+
+  @param [in] Trace  If TRUE, trace the ACPI fields.
+  @param [in] PtrPointer to the start of the buffer.
+  @param [in] AcpiTableLengthLength of the ACPI table.
+  @param [in] AcpiTableRevision  Revision of the ACPI table.
+**/
+VOID
+EFIAPI
+ParseAcpiPcct (
+  IN BOOLEAN Trace,
+  IN UINT8*  Ptr,
+  IN UINT32  AcpiTableLength,
+  IN UINT8   AcpiTableRevision
+  );
+
+/**
   This function parses the ACPI PPTT table.
   When trace is enabled this function parses the PPTT table and
   traces the ACPI table fields.
diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiTableParser.h 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiTableParser.h
index 
4f92596b90a6ee422d8d0959881015ffd3de4da0..0ebf79fb653ae3a8190273aee452723c6213eb58
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiTableParser.h
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiTableParser.h
@@ -1,7 +1,7 @@
 /** @file
   Header file for ACPI table parser
 
-  Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
+  Copyright (c) 2016 - 2020, Arm Limited. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 **/
 
@@ -11,7 +11,7 @@
 /**
   The maximum number of ACPI table parsers.
 */
-#define MAX_ACPI_TABLE_PARSERS  16
+#define MAX_ACPI_TABLE_PARSERS  32
 
 /** An invalid/NULL signature value.
 */
diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pcct/PcctParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pcct/PcctParser.c
new file mode 100644
index 
..ca553d5953f05651d8df4c95d1e39a73eded5129
--- /dev/null
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pcct/PcctParser.c
@@ -0,0 +1,615 @@
+/** @file
+  PCCT table parser
+
+  Copyright (c) 2020, Arm Limited.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Reference(s):
+- ACPI 6.3 Specification - January 2019
+**/
+
+#include 
+#include 
+#include 
+#include "AcpiParser.h"
+#include "AcpiView.h"
+#include "AcpiViewConfig.h"
+#include "PcctParser.h"
+
+// Local variables
+STATIC ACPI_DESCRIPTION_HEADER_INFO AcpiHdrInfo;
+
+STATIC UINT32* PccGlobalFlags;
+STATIC UINT8*  PccSubspaceLength;
+STATIC UINT8*  PccSubspaceType;
+STATIC UINT8*  ExtendedPccSubspaceInterruptFlags;
+
+/**
+  This function validates the length coded on 4 bytes of a shared memory range
+
+  @param [in] Ptr Pointer to the start of the field data.
+  @param [in] Context Pointer to context specific information e.g. this
+  could be a pointer to the ACPI table header.
+**/
+STATIC
+VOID
+EFIAPI
+ValidateRangeLength4 (
+  IN UINT8* Ptr,
+  IN VOID*  Context
+  )

Re: [edk2-devel] [PATCH v1 1/1] IntelSiliconPkg/ShadowMicrocodePei: Add PCD for shadowing all microcode.

[Ni, Ray]

Aaron,
I understand the requirement now.
Can we avoid adding new PCD but re-interpret the ShadowMicrocode() parameter to 
achieve the same result?

For example, we can say when CpuIdCount is 0 and MicrocodeCpuId == NULL, it 
means all microcode need to be shadowed.

The benefit is: platform can use the single interface to control the behavior.

Thanks,
Ray

> -Original Message-
> From: Li, Aaron 
> Sent: Thursday, September 24, 2020 9:38 AM
> To: Ni, Ray ; devel@edk2.groups.io
> Cc: Chaganty, Rangasai V ; Fu, Siyuan
> 
> Subject: RE: [PATCH v1 1/1] IntelSiliconPkg/ShadowMicrocodePei: Add PCD for
> shadowing all microcode.
> 
> Hi Ray,
> 
> Accroding to
> https://edk2.groups.io/g/devel/files/Designs/2020/0214/Support%20the%202nd
> %20Microcode%20FV%20Flash%20Region.pdf
> The ShadowMicrocodePei provide a FIT based shadow microcode ppi to
> MpInitLib. It's needed.
> 
> 
> Best,
> Aaron
> 
> > -Original Message-
> > From: Ni, Ray 
> > Sent: Wednesday, September 23, 2020 2:25 PM
> > To: Li, Aaron ; devel@edk2.groups.io
> > Cc: Chaganty, Rangasai V ; Fu, Siyuan
> > 
> > Subject: RE: [PATCH v1 1/1] IntelSiliconPkg/ShadowMicrocodePei: Add PCD
> > for shadowing all microcode.
> >
> > MpInitLib already contains logic to shadow microcode to memory.
> > Is this still needed?
> >
> > > -Original Message-
> > > From: Li, Aaron 
> > > Sent: Wednesday, August 12, 2020 3:55 PM
> > > To: devel@edk2.groups.io
> > > Cc: Ni, Ray ; Chaganty, Rangasai V
> > > ; Fu, Siyuan 
> > > Subject: [PATCH v1 1/1] IntelSiliconPkg/ShadowMicrocodePei: Add PCD for
> > > shadowing all microcode.
> > >
> > > This patch is to add a PCD PcdShadowAllMicrocode to support shadowing
> > > all microcode patch to memory.
> > >
> > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2891
> > >
> > > Signed-off-by: Aaron Li 
> > > Cc: Ray Ni 
> > > Cc: Rangasai V Chaganty 
> > > Cc: Siyuan Fu 
> > > ---
> > >
> > >
> > Silicon/Intel/IntelSiliconPkg/Feature/ShadowMicrocode/ShadowMicrocodeP
> > ei.c
> > > | 4 
> > >
> > >
> > Silicon/Intel/IntelSiliconPkg/Feature/ShadowMicrocode/ShadowMicrocodeP
> > ei.i
> > > nf | 3 +++
> > >  Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> > > | 7
> +++
> > >  3 files changed, 14 insertions(+)
> > >
> > > diff --git
> > >
> > a/Silicon/Intel/IntelSiliconPkg/Feature/ShadowMicrocode/ShadowMicrocod
> > ePei
> > > .c
> > >
> > b/Silicon/Intel/IntelSiliconPkg/Feature/ShadowMicrocode/ShadowMicrocod
> > ePei
> > > .c
> > > index 8d6574f66794..5c7ee6910c8e 100644
> > > ---
> > >
> > a/Silicon/Intel/IntelSiliconPkg/Feature/ShadowMicrocode/ShadowMicrocod
> > ePei
> > > .c
> > > +++
> > >
> > b/Silicon/Intel/IntelSiliconPkg/Feature/ShadowMicrocode/ShadowMicrocod
> > ePei
> > > .c
> > > @@ -132,6 +132,10 @@ IsMicrocodePatchNeedLoad (
> > >CPU_MICROCODE_EXTENDED_TABLE   *ExtendedTable;
> > >
> > >UINTN  Index;
> > >
> > >
> > >
> > > +  if (FeaturePcdGet (PcdShadowAllMicrocode)) {
> > >
> > > +return TRUE;
> > >
> > > +  }
> > >
> > > +
> > >
> > >//
> > >
> > >// Check the 'ProcessorSignature' and 'ProcessorFlags' in microcode 
> > > patch
> > > header.
> > >
> > >//
> > >
> > > diff --git
> > >
> > a/Silicon/Intel/IntelSiliconPkg/Feature/ShadowMicrocode/ShadowMicrocod
> > ePei
> > > .inf
> > >
> > b/Silicon/Intel/IntelSiliconPkg/Feature/ShadowMicrocode/ShadowMicrocod
> > ePei
> > > .inf
> > > index 019400ab31da..581780add891 100644
> > > ---
> > >
> > a/Silicon/Intel/IntelSiliconPkg/Feature/ShadowMicrocode/ShadowMicrocod
> > ePei
> > > .inf
> > > +++
> > >
> > b/Silicon/Intel/IntelSiliconPkg/Feature/ShadowMicrocode/ShadowMicrocod
> > ePei
> > > .inf
> > > @@ -39,5 +39,8 @@ [Guids]
> > >gEdkiiMicrocodeShadowInfoHobGuid
> > >
> > >gEdkiiMicrocodeStorageTypeFlashGuid
> > >
> > >
> > >
> > > +[Pcd]
> > >
> > > +  gIntelSiliconPkgTokenSpaceGuid.PcdShadowAllMicrocode
> > >
> > > +
> > >
> > >  [Depex]
> > >
> > >TRUE
> > >
> > > diff --git a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> > > b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> > > index e4a7fec3a3ea..3a12fe99fac6 100644
> > > --- a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> > > +++ b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> > > @@ -76,6 +76,13 @@ [Protocols]
> > ># Include/Protocol/PlatformDeviceSecurityPolicy.h
> > >
> > >gEdkiiDeviceSecurityPolicyProtocolGuid = {0x7ea41a99, 0x5e32, 0x4c97,
> > > {0x88, 0xc4, 0xd6, 0xe7, 0x46, 0x84, 0x9, 0xd4}}
> > >
> > >
> > >
> > > +[PcdsFeatureFlag]
> > >
> > > +  ## Indicates if all microcode update patches shall be shadowed to
> > memory.
> > >
> > > +  #   TRUE  - All microcode patches will be shadowed.
> > >
> > > +  #   FALSE - Only the microcode for current present processors will be
> > > shadowed.
> > >
> > > +  # @Prompt Shadow all microcode update patches.
> > >
> > > +
> > >
> > gIntelSiliconPkgTokenSpaceGuid.PcdShadowAllMicrocode|FALSE|BOOLEAN|
> > 0

Re: [edk2-devel] [PATCH] BaseTools: Add included files to deps_target file.

[Yuwei Chen]

Reviewed-by: Yuwei Chen

> -Original Message-
> From: Feng, Bob C 
> Sent: Wednesday, September 23, 2020 6:52 PM
> To: devel@edk2.groups.io
> Cc: Liang, MingyueX ; Liming Gao
> ; Chen, Christine 
> Subject: [PATCH] BaseTools: Add included files to deps_target file.
> 
> From: Mingyue Liang 
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2882
> 
> After changing the name of the include source file, when doing incremental
> build, the previous source file is not covered in the. DEPs file, and a build
> error occurs.
> 
> The root cause is that the build tools filter out some dependency files, which
> are listed in inf source section, from the deps_target file.
> Add those files back to deps_target file to resolve the above problem.
> 
> Signed-off-by: Mingyue Liang 
> Cc: Bob Feng 
> Cc: Liming Gao 
> Cc: Yuwei Chen 
> ---
>  BaseTools/Source/Python/AutoGen/IncludesAutoGen.py | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/AutoGen/IncludesAutoGen.py
> b/BaseTools/Source/Python/AutoGen/IncludesAutoGen.py
> index 720d93395a..c3e6333217 100644
> --- a/BaseTools/Source/Python/AutoGen/IncludesAutoGen.py
> +++ b/BaseTools/Source/Python/AutoGen/IncludesAutoGen.py
> @@ -103,7 +103,7 @@ ${END}
>  if os.path.normpath(dependency_file +".deps") == abspath:
>  continue
>  filename = os.path.basename(dependency_file).strip()
> -if filename not in self.SourceFileList and filename not 
> in
> targetname:
> +if filename not in targetname:
>  includes.add(dependency_file.strip())
> 
>  for item in lines[1:]:
> @@ -116,8 +116,6 @@ ${END}
>  if os.path.normpath(dependency_file +".deps") == abspath:
>  continue
>  filename = os.path.basename(dependency_file).strip()
> -if filename in self.SourceFileList:
> -continue
>  if filename in targetname:
>  continue
>  includes.add(dependency_file.strip())
> --
> 2.28.0.windows.1



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