date:20190306

Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code

2019-03-06 Thread Yao, Jiewen

Thanks.

I also recommend to take a look at MdePkg\Library\BaseSynchronizationLib.

That is also complicated and not so readable for me.

And we have 8 patches to *fix* the real problem in 2018.

Thank you
Yao Jiewen


From: Gao, Liming
Sent: Wednesday, March 6, 2019 11:15 PM
To: af...@apple.com; Yao, Jiewen 
Cc: Kinney, Michael D ; edk2-devel-01 

Subject: RE: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline 
X86 assembly code

Thanks for your clarification. Now, we will focus on SetJump/LongJump() first.

Thanks
Liming
From: af...@apple.com [mailto:af...@apple.com]
Sent: Wednesday, March 6, 2019 10:45 PM
To: Yao, Jiewen mailto:jiewen@intel.com>>
Cc: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>; Gao, Liming 
mailto:liming@intel.com>>; edk2-devel-01 
mailto:edk2-devel@lists.01.org>>
Subject: Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline 
X86 assembly code



On Mar 6, 2019, at 10:09 PM, Yao, Jiewen 
mailto:jiewen@intel.com>> wrote:

Thanks Andrew.
Now I 100% agree with you - I think it is fine to restrict new C inline 
assembler, or at least have a very high bar to add anything new. Any new inline 
assembler *should also be simple and just be a function abstracting a CPU 
op-code* that is not available to C. This is how we prevent the maintenance 
issues you are worrying about.

And I also agree with your case.

Let’s discuss another case. Below 2 functions SetJump/LongJump are updated 
recently, by me unfortunately.

It is unclear to me what is the size optimization we can get by inline 
SetJump/LongJump.
But obviously, it brings the maintenance issue to me.
And I don’t believe it meets the criteria you mentioned above.


Jiewen,

I agree it seems like given the rules we agree on this code should be written 
in NASM.

Thanks,

Andrew Fish

_declspec (naked)
RETURNS_TWICE
UINTN
EFIAPI
SetJump (
  OUT BASE_LIBRARY_JUMP_BUFFER  *JumpBuffer
  )
{
  _asm {
push[esp + 4]
callInternalAssertJumpBuffer
pop ecx
pop ecx
mov edx, [esp]

xor eax, eax
mov [edx + 24], eax; save 0 to SSP

mov eax, [PcdGet32 (PcdControlFlowEnforcementPropertyMask)]
testeax, eax
jz  CetDone
_emit  0x0F
_emit  0x20
_emit  0xE0; mov eax, cr4
bt  eax, 23; check if CET is enabled
jnc CetDone

mov eax, 1
_emit  0xF3
_emit  0x0F
_emit  0xAE
_emit  0xE8; INCSSP EAX to read original SSP
_emit  0xF3
_emit  0x0F
_emit  0x1E
_emit  0xC8; READSSP EAX
mov [edx + 0x24], eax  ; save SSP

CetDone:

mov [edx], ebx
mov [edx + 4], esi
mov [edx + 8], edi
mov [edx + 12], ebp
mov [edx + 16], esp
mov [edx + 20], ecx
xor eax, eax
jmp ecx
  }
}

__declspec (naked)
VOID
EFIAPI
InternalLongJump (
  IN  BASE_LIBRARY_JUMP_BUFFER  *JumpBuffer,
  IN  UINTN Value
  )
{
  _asm {
mov eax, [PcdGet32 (PcdControlFlowEnforcementPropertyMask)]
testeax, eax
jz  CetDone
_emit  0x0F
_emit  0x20
_emit  0xE0; mov eax, cr4
bt  eax, 23; check if CET is enabled
jnc CetDone

mov edx, [esp + 4] ; edx = JumpBuffer
mov edx, [edx + 24]; edx = target SSP
_emit  0xF3
_emit  0x0F
_emit  0x1E
_emit  0xC8; READSSP EAX
sub edx, eax   ; edx = delta
mov eax, edx   ; eax = delta

shr eax, 2 ; eax = delta/sizeof(UINT32)
_emit  0xF3
_emit  0x0F
_emit  0xAE
_emit  0xE8; INCSSP EAX

CetDone:

pop eax ; skip return address
pop edx ; edx <- JumpBuffer
pop eax ; eax <- Value
mov ebx, [edx]
mov esi, [edx + 4]
mov edi, [edx + 8]
mov ebp, [edx + 12]
mov esp, [edx + 16]
jmp dword ptr [edx + 20]
  }
}



From: af...@apple.com [mailto:af...@apple.com]
Sent: Wednesday, March 6, 2019 9:56 PM
To: Yao, Jiewen mailto:jiewen@intel.com>>
Cc: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>; Gao, Liming 
mailto:liming@intel.com>>; edk2-devel-01 
mailto:edk2-devel@lists.01.org>>
Subject: Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline 
X86 assembly code




On Mar 6, 2019, at 9:06 PM, Yao, Jiewen 
mailto:jiewen@intel.com>> wrote:

HI Mike and Andrew
The problem is maintainability.

If we have multiple copy of implementation, a developer need verify multiple 
copy of implementation, if we make update. Before that, a developer has to be 
aware that there is multiple copy of implementa

Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code

2019-03-06 Thread Gao, Liming

Thanks for your clarification. Now, we will focus on SetJump/LongJump() first.

Thanks
Liming
From: af...@apple.com [mailto:af...@apple.com]
Sent: Wednesday, March 6, 2019 10:45 PM
To: Yao, Jiewen 
Cc: Kinney, Michael D ; Gao, Liming 
; edk2-devel-01 
Subject: Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline 
X86 assembly code

On Mar 6, 2019, at 10:09 PM, Yao, Jiewen 
mailto:jiewen@intel.com>> wrote:

Thanks Andrew.
Now I 100% agree with you - I think it is fine to restrict new C inline 
assembler, or at least have a very high bar to add anything new. Any new inline 
assembler *should also be simple and just be a function abstracting a CPU 
op-code* that is not available to C. This is how we prevent the maintenance 
issues you are worrying about.

And I also agree with your case.

Let’s discuss another case. Below 2 functions SetJump/LongJump are updated 
recently, by me unfortunately.

It is unclear to me what is the size optimization we can get by inline 
SetJump/LongJump.
But obviously, it brings the maintenance issue to me.
And I don’t believe it meets the criteria you mentioned above.

Jiewen,

I agree it seems like given the rules we agree on this code should be written 
in NASM.

Thanks,

Andrew Fish

_declspec (naked)
RETURNS_TWICE
UINTN
EFIAPI
SetJump (
  OUT BASE_LIBRARY_JUMP_BUFFER  *JumpBuffer
  )
{
  _asm {
push[esp + 4]
callInternalAssertJumpBuffer
pop ecx
pop ecx
mov edx, [esp]

xor eax, eax
mov [edx + 24], eax; save 0 to SSP

mov eax, [PcdGet32 (PcdControlFlowEnforcementPropertyMask)]
testeax, eax
jz  CetDone
_emit  0x0F
_emit  0x20
_emit  0xE0; mov eax, cr4
bt  eax, 23; check if CET is enabled
jnc CetDone

mov eax, 1
_emit  0xF3
_emit  0x0F
_emit  0xAE
_emit  0xE8; INCSSP EAX to read original SSP
_emit  0xF3
_emit  0x0F
_emit  0x1E
_emit  0xC8; READSSP EAX
mov [edx + 0x24], eax  ; save SSP

CetDone:

mov [edx], ebx
mov [edx + 4], esi
mov [edx + 8], edi
mov [edx + 12], ebp
mov [edx + 16], esp
mov [edx + 20], ecx
xor eax, eax
jmp ecx
  }
}

__declspec (naked)
VOID
EFIAPI
InternalLongJump (
  IN  BASE_LIBRARY_JUMP_BUFFER  *JumpBuffer,
  IN  UINTN Value
  )
{
  _asm {
mov eax, [PcdGet32 (PcdControlFlowEnforcementPropertyMask)]
testeax, eax
jz  CetDone
_emit  0x0F
_emit  0x20
_emit  0xE0; mov eax, cr4
bt  eax, 23; check if CET is enabled
jnc CetDone

mov edx, [esp + 4] ; edx = JumpBuffer
mov edx, [edx + 24]; edx = target SSP
_emit  0xF3
_emit  0x0F
_emit  0x1E
_emit  0xC8; READSSP EAX
sub edx, eax   ; edx = delta
mov eax, edx   ; eax = delta

shr eax, 2 ; eax = delta/sizeof(UINT32)
_emit  0xF3
_emit  0x0F
_emit  0xAE
_emit  0xE8; INCSSP EAX

CetDone:

pop eax ; skip return address
pop edx ; edx <- JumpBuffer
pop eax ; eax <- Value
mov ebx, [edx]
mov esi, [edx + 4]
mov edi, [edx + 8]
mov ebp, [edx + 12]
mov esp, [edx + 16]
jmp dword ptr [edx + 20]
  }
}

From: af...@apple.com [mailto:af...@apple.com]
Sent: Wednesday, March 6, 2019 9:56 PM
To: Yao, Jiewen mailto:jiewen@intel.com>>
Cc: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>; Gao, Liming 
mailto:liming@intel.com>>; edk2-devel-01 
mailto:edk2-devel@lists.01.org>>
Subject: Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline 
X86 assembly code

On Mar 6, 2019, at 9:06 PM, Yao, Jiewen 
mailto:jiewen@intel.com>> wrote:

HI Mike and Andrew
The problem is maintainability.

If we have multiple copy of implementation, a developer need verify multiple 
copy of implementation, if we make update. Before that, a developer has to be 
aware that there is multiple copy of implementation. - That increases the 
complexity.

If we have everything, there MAY be 5 copy - ASM, NASM, S, GCC inline, MS 
inline, theoretically.
Now, we remove ASM. It is good first step.
But we may still have 4 copies. I suggest we consider do more.

Jiewen,

I think you are trying do the right thing, but are optimize the wrong thing.

Most of the GCC/Clang inline assembler code is in Gccinline.c and since that 
code is mostly just abstracting an x86 instruction and the functions are very 
simple and thus it is NOT code that needs ongoing maintenance.

Lets look at the history:
https://github.c

[edk2] [edk2-test][Patch 1/1] uefi-sct/SctPkg:update BlueTooth test with LE support

2019-03-06 Thread Eric Jin

revisit BlueTooth checkpoint for UEFI2.7 spec update
with LE support
Change original test to classic/low energy checkpoints
Add marco MAX_LENGTH for pre-defined string value
(yes or no) in EfiCompliant.ini.

Cc: Supreeth Venkatesh 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Jin 
---
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/EfiCompliant/BlackBoxTest/Guid_uefi.h 
   |   7 ++-
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/EfiCompliant/BlackBoxTest/EfiCompliantBBTestPlatform_uefi.c
  | 377 
+
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/EfiCompliant/BlackBoxTest/Guid_uefi.c 
   |   4 +++-
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/EfiCompliant/BlackBoxTest/Dependency/Config/EfiCompliant.ini
 |   9 ++---
 4 files changed, 240 insertions(+), 157 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/EfiCompliant/BlackBoxTest/Guid_uefi.h
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/EfiCompliant/BlackBoxTest/Guid_uefi.h
index b6e1f3797462..158231c46d37 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/EfiCompliant/BlackBoxTest/Guid_uefi.h
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/EfiCompliant/BlackBoxTest/Guid_uefi.h
@@ -1,7 +1,7 @@
 /** @file
 
   Copyright 2006 - 2016 Unified EFI, Inc.
-  Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -160,6 +160,11 @@ extern EFI_GUID 
gEfiCompliantBbTestPlatformAssertionGuid026;
 
 extern EFI_GUID gEfiCompliantBbTestPlatformAssertionGuid027;
 
+#define EFI_TEST_EFICOMPLIANTBBTESTPLATFORM_ASSERTION_028_GUID \
+{ 0xeff461eb, 0x4f56, 0x44a5, { 0x89, 0x5e, 0xee, 0x5e, 0xe4, 0x2a, 0xd3, 0x9 
}}
+
+extern EFI_GUID gEfiCompliantBbTestPlatformAssertionGuid028;
+
 #define EFI_TEST_EFICOMPLIANTBBTESTREQUIRED_ASSERTION_001_GUID \
 { 0xf6a871e3, 0xef8a, 0x420f, {0x82, 0x01, 0x35, 0xb6, 0x1c, 0xe2, 0xe8, 0xdb 
}}
 
diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/EfiCompliant/BlackBoxTest/EfiCompliantBBTestPlatform_uefi.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/EfiCompliant/BlackBoxTest/EfiCompliantBBTestPlatform_uefi.c
index 186e44bfb1ed..b3f1b8c557d2 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/EfiCompliant/BlackBoxTest/EfiCompliantBBTestPlatform_uefi.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/EfiCompliant/BlackBoxTest/EfiCompliantBBTestPlatform_uefi.c
@@ -1,7 +1,7 @@
 /** @file
 
   Copyright 2006 - 2016 Unified EFI, Inc.
-  Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -166,6 +166,17 @@ EFI_GUID gEfiIPSecConfigProtocolGuid = { 0xce5e5929, 
0xc7a3, 0x4602, {0xad, 0x9e
 
 EFI_GUID gEfiIPSec2ProtocolGuid = { 0xa3979e64, 0xace8, 0x4ddc, {0xbc, 0x07, 
0x4d, 0x66, 0xb8, 0xfd, 0x09, 0x77 }};
 
+EFI_GUID gEfiBlueToothAttributeProtocolGuid = { 0x898890e9, 0x84b2, 0x4f3a, { 
0x8c, 0x58, 0xd8, 0x57, 0x78, 0x13, 0xe0, 0xac }};
+
+EFI_GUID gEfiBlueToothLEConfigProtocolGuid = { 0x8f76da58, 0x1f99, 0x4275, { 
0xa4, 0xec, 0x47, 0x56, 0x51, 0x5b, 0x1c, 0xe8 }};
+
+//
+// The Max length of pre-defined string value(yes or no)
+// in the EfiCompliant.ini
+// which is the platform specific configuration
+//
+#define MAX_LENGTH  10
+
 //
 // Internal functions declarations
 //
@@ -353,7 +364,13 @@ CheckEAPProtocols (
   );
 
 EFI_STATUS
-CheckBlueToothProtocols (
+CheckBlueToothClassicProtocols (
+  IN EFI_STANDARD_TEST_LIBRARY_PROTOCOL   *StandardLib,
+  IN EFI_INI_FILE_HANDLE  IniFile
+  );
+
+EFI_STATUS
+CheckBlueToothLEProtocols (
   IN EFI_STANDARD_TEST_LIBRARY_PROTOCOL   *StandardLib,
   IN EFI_INI_FILE_HANDLE  IniFile
   );
@@ -564,7 +581,8 @@ Routine Description:
   //
   // Check the BlueTooth protocols
   //
-  CheckBlueToothProtocols (StandardLib, IniFile);
+  CheckBlueToothClassicProtocols (StandardLib, IniFile);
+  CheckBlueToothLEProtocols (StandardLib, IniFile);
 
   //
   // Check the IPSec protocols
@@ -722,7 +740,7 @@ CheckConsoleProtocols (
 {
   EFI_STATUS  Status;
   UINT32  MaxLength;
-  CHAR16  String[10];
+  CHAR16  String[MAX_LENGTH];
   BOOLEAN ValueA;
   BOOLEAN ValueB;
   BOOLEAN ValueC;
@@ -780,9 +798,8 @@ CheckC

Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code

2019-03-06 Thread Andrew Fish via edk2-devel



> On Mar 6, 2019, at 10:09 PM, Yao, Jiewen  wrote:
> 
> Thanks Andrew.
> Now I 100% agree with you - I think it is fine to restrict new C inline 
> assembler, or at least have a very high bar to add anything new. Any new 
> inline assembler *should also be simple and just be a function abstracting a 
> CPU op-code* that is not available to C. This is how we prevent the 
> maintenance issues you are worrying about.
>  
> And I also agree with your case.
>  
> Let’s discuss another case. Below 2 functions SetJump/LongJump are updated 
> recently, by me unfortunately.
>  
> It is unclear to me what is the size optimization we can get by inline 
> SetJump/LongJump.
> But obviously, it brings the maintenance issue to me.
> And I don’t believe it meets the criteria you mentioned above.
>  

Jiewen,

I agree it seems like given the rules we agree on this code should be written 
in NASM. 

Thanks,

Andrew Fish

> _declspec (naked)
> RETURNS_TWICE
> UINTN
> EFIAPI
> SetJump (
>   OUT BASE_LIBRARY_JUMP_BUFFER  *JumpBuffer
>   )
> {
>   _asm {
> push[esp + 4]
> callInternalAssertJumpBuffer
> pop ecx
> pop ecx
> mov edx, [esp]
>  
> xor eax, eax
> mov [edx + 24], eax; save 0 to SSP
>  
> mov eax, [PcdGet32 (PcdControlFlowEnforcementPropertyMask)]
> testeax, eax
> jz  CetDone
> _emit  0x0F
> _emit  0x20
> _emit  0xE0; mov eax, cr4
> bt  eax, 23; check if CET is enabled
> jnc CetDone
>  
> mov eax, 1
> _emit  0xF3
> _emit  0x0F
> _emit  0xAE
> _emit  0xE8; INCSSP EAX to read original SSP
> _emit  0xF3
> _emit  0x0F
> _emit  0x1E
> _emit  0xC8; READSSP EAX
> mov [edx + 0x24], eax  ; save SSP
>  
> CetDone:
>  
> mov [edx], ebx
> mov [edx + 4], esi
> mov [edx + 8], edi
> mov [edx + 12], ebp
> mov [edx + 16], esp
> mov [edx + 20], ecx
> xor eax, eax
> jmp ecx
>   }
> }
>  
> __declspec (naked)
> VOID
> EFIAPI
> InternalLongJump (
>   IN  BASE_LIBRARY_JUMP_BUFFER  *JumpBuffer,
>   IN  UINTN Value
>   )
> {
>   _asm {
> mov eax, [PcdGet32 (PcdControlFlowEnforcementPropertyMask)]
> testeax, eax
> jz  CetDone
> _emit  0x0F
> _emit  0x20
> _emit  0xE0; mov eax, cr4
> bt  eax, 23; check if CET is enabled
> jnc CetDone
>  
> mov edx, [esp + 4] ; edx = JumpBuffer
> mov edx, [edx + 24]; edx = target SSP
> _emit  0xF3
> _emit  0x0F
> _emit  0x1E
> _emit  0xC8; READSSP EAX
> sub edx, eax   ; edx = delta
> mov eax, edx   ; eax = delta
>  
> shr eax, 2 ; eax = delta/sizeof(UINT32)
> _emit  0xF3
> _emit  0x0F
> _emit  0xAE
> _emit  0xE8; INCSSP EAX
>  
> CetDone:
>  
> pop eax ; skip return address
> pop edx ; edx <- JumpBuffer
> pop eax ; eax <- Value
> mov ebx, [edx]
> mov esi, [edx + 4]
> mov edi, [edx + 8]
> mov ebp, [edx + 12]
> mov esp, [edx + 16]
> jmp dword ptr [edx + 20]
>   }
> }
>  
>  
>   <>
>  <>From: af...@apple.com [mailto:af...@apple.com] 
> Sent: Wednesday, March 6, 2019 9:56 PM
> To: Yao, Jiewen 
> Cc: Kinney, Michael D ; Gao, Liming 
> ; edk2-devel-01 
> Subject: Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline 
> X86 assembly code
>  
>  
> 
> 
> On Mar 6, 2019, at 9:06 PM, Yao, Jiewen  > wrote:
>  
> HI Mike and Andrew
> The problem is maintainability.
> 
> If we have multiple copy of implementation, a developer need verify multiple 
> copy of implementation, if we make update. Before that, a developer has to be 
> aware that there is multiple copy of implementation. - That increases the 
> complexity.
> 
> If we have everything, there MAY be 5 copy - ASM, NASM, S, GCC inline, MS 
> inline, theoretically.
> Now, we remove ASM. It is good first step.
> But we may still have 4 copies. I suggest we consider do more.
> 
>  
> Jiewen,
>  
> I think you are trying do the right thing, but are optimize the wrong thing. 
>  
> Most of the GCC/Clang inline assembler code is in Gccinline.c and since that 
> code is mostly just abstracting an x86 instruction and the functions are very 
> simple and thus it is NOT code that needs ongoing maintenance. 
>  
> Lets look at the history:
> https://github.com/tianocore/edk2/commits/master/MdePkg/Library/BaseLib/X64/GccInline.c
>  
> 
> The last logic

Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code

2019-03-06 Thread Yao, Jiewen

Thanks Andrew.
Now I 100% agree with you - I think it is fine to restrict new C inline 
assembler, or at least have a very high bar to add anything new. Any new inline 
assembler *should also be simple and just be a function abstracting a CPU 
op-code* that is not available to C. This is how we prevent the maintenance 
issues you are worrying about.

And I also agree with your case.

Let's discuss another case. Below 2 functions SetJump/LongJump are updated 
recently, by me unfortunately.

It is unclear to me what is the size optimization we can get by inline 
SetJump/LongJump.
But obviously, it brings the maintenance issue to me.
And I don't believe it meets the criteria you mentioned above.

_declspec (naked)
RETURNS_TWICE
UINTN
EFIAPI
SetJump (
  OUT BASE_LIBRARY_JUMP_BUFFER  *JumpBuffer
  )
{
  _asm {
push[esp + 4]
callInternalAssertJumpBuffer
pop ecx
pop ecx
mov edx, [esp]

xor eax, eax
mov [edx + 24], eax; save 0 to SSP

mov eax, [PcdGet32 (PcdControlFlowEnforcementPropertyMask)]
testeax, eax
jz  CetDone
_emit  0x0F
_emit  0x20
_emit  0xE0; mov eax, cr4
bt  eax, 23; check if CET is enabled
jnc CetDone

mov eax, 1
_emit  0xF3
_emit  0x0F
_emit  0xAE
_emit  0xE8; INCSSP EAX to read original SSP
_emit  0xF3
_emit  0x0F
_emit  0x1E
_emit  0xC8; READSSP EAX
mov [edx + 0x24], eax  ; save SSP

CetDone:

mov [edx], ebx
mov [edx + 4], esi
mov [edx + 8], edi
mov [edx + 12], ebp
mov [edx + 16], esp
mov [edx + 20], ecx
xor eax, eax
jmp ecx
  }
}

__declspec (naked)
VOID
EFIAPI
InternalLongJump (
  IN  BASE_LIBRARY_JUMP_BUFFER  *JumpBuffer,
  IN  UINTN Value
  )
{
  _asm {
mov eax, [PcdGet32 (PcdControlFlowEnforcementPropertyMask)]
testeax, eax
jz  CetDone
_emit  0x0F
_emit  0x20
_emit  0xE0; mov eax, cr4
bt  eax, 23; check if CET is enabled
jnc CetDone

mov edx, [esp + 4] ; edx = JumpBuffer
mov edx, [edx + 24]; edx = target SSP
_emit  0xF3
_emit  0x0F
_emit  0x1E
_emit  0xC8; READSSP EAX
sub edx, eax   ; edx = delta
mov eax, edx   ; eax = delta

shr eax, 2 ; eax = delta/sizeof(UINT32)
_emit  0xF3
_emit  0x0F
_emit  0xAE
_emit  0xE8; INCSSP EAX

CetDone:

pop eax ; skip return address
pop edx ; edx <- JumpBuffer
pop eax ; eax <- Value
mov ebx, [edx]
mov esi, [edx + 4]
mov edi, [edx + 8]
mov ebp, [edx + 12]
mov esp, [edx + 16]
jmp dword ptr [edx + 20]
  }
}



From: af...@apple.com [mailto:af...@apple.com]
Sent: Wednesday, March 6, 2019 9:56 PM
To: Yao, Jiewen 
Cc: Kinney, Michael D ; Gao, Liming 
; edk2-devel-01 
Subject: Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline 
X86 assembly code




On Mar 6, 2019, at 9:06 PM, Yao, Jiewen 
mailto:jiewen@intel.com>> wrote:

HI Mike and Andrew
The problem is maintainability.

If we have multiple copy of implementation, a developer need verify multiple 
copy of implementation, if we make update. Before that, a developer has to be 
aware that there is multiple copy of implementation. - That increases the 
complexity.

If we have everything, there MAY be 5 copy - ASM, NASM, S, GCC inline, MS 
inline, theoretically.
Now, we remove ASM. It is good first step.
But we may still have 4 copies. I suggest we consider do more.

Jiewen,

I think you are trying do the right thing, but are optimize the wrong thing.

Most of the GCC/Clang inline assembler code is in Gccinline.c and since that 
code is mostly just abstracting an x86 instruction and the functions are very 
simple and thus it is NOT code that needs ongoing maintenance.

Lets look at the history:
https://github.com/tianocore/edk2/commits/master/MdePkg/Library/BaseLib/X64/GccInline.c
The last logic fix was Jun 1, 2010

https://github.com/tianocore/edk2/commits/master/MdePkg/Library/BaseLib/Ia32/GccInline.c
Ok so Mike had to make a fix in this file in 2015 to make something optional, 
due to an embedded CPU defeating an instruction. But prior to that it was 2010.

The set of things that are C inline assembler we have should be static and not 
require much maintenance. More complex code should be written in C and use the 
C inline assembler functions we already have. If any more complex assembly code 
is required we should just write it in NASM. So I think it is fine to restrict 
new C inline assembler, or a

Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code

2019-03-06 Thread Andrew Fish via edk2-devel

> On Mar 6, 2019, at 9:06 PM, Yao, Jiewen  wrote:
> 
> HI Mike and Andrew
> The problem is maintainability.
> 
> If we have multiple copy of implementation, a developer need verify multiple 
> copy of implementation, if we make update. Before that, a developer has to be 
> aware that there is multiple copy of implementation. - That increases the 
> complexity.
> 
> If we have everything, there MAY be 5 copy - ASM, NASM, S, GCC inline, MS 
> inline, theoretically.
> Now, we remove ASM. It is good first step.
> But we may still have 4 copies. I suggest we consider do more.
> 

Jiewen,

I think you are trying do the right thing, but are optimize the wrong thing. 

Most of the GCC/Clang inline assembler code is in Gccinline.c and since that 
code is mostly just abstracting an x86 instruction and the functions are very 
simple and thus it is NOT code that needs ongoing maintenance. 

Lets look at the history:
https://github.com/tianocore/edk2/commits/master/MdePkg/Library/BaseLib/X64/GccInline.c
The last logic fix was Jun 1, 2010

https://github.com/tianocore/edk2/commits/master/MdePkg/Library/BaseLib/Ia32/GccInline.c
Ok so Mike had to make a fix in this file in 2015 to make something optional, 
due to an embedded CPU defeating an instruction. But prior to that it was 2010. 

The set of things that are C inline assembler we have should be static and not 
require much maintenance. More complex code should be written in C and use the 
C inline assembler functions we already have. If any more complex assembly code 
is required we should just write it in NASM. So I think it is fine to restrict 
new C inline assembler, or at least have a very high bar to add anything new. 
Any new inline assembler should also be simple and just be a function 
abstracting a CPU op-code that is not available to C. This is how we prevent 
the maintenance issues you are worrying about. 

I gave an example in this  mail thread on how a Breakpoint goes from being 1 
byte to 11 bytes if you remove the C inline assembler. For clang with LTO 
enabled a CpuBreakpoint will always get inlined into the callers code and it 
will only take the one byte for int 3 instruction. If that code moves to NASM 
then it get replaces with a 5 byte call instruction and an actual C ABI 
function for the breakpoint. 

VOID
EFIAPI
CpuBreakpoint (
  VOID
  )
{
  __asm__ __volatile__ ("int $3");
}

Today with clang LTO turned on calling CpuBreakpoint() looks like this from the 
callers point of view. 

a.out[0x1fa5] <+6>:  cc  int3   

But if we move that to NASM:

a.out[0x1fa6] <+7>:  e8 07 00 00 00  calll  0x1fb2; 
CpuBreakpoint

plus:
a.out`CpuBreakpoint:
a.out[0x1f99] <+0>: 55 pushl  %ebp
a.out[0x1f9a] <+1>: 89 e5  movl   %esp, %ebp
a.out[0x1f9c] <+3>: cc int3   
a.out[0x1f9d] <+4>: 5d popl   %ebp
a.out[0x1f9e] <+5>: c3 retl   

For any compiler that emits the frame pointer if you move the INT 3 to assembly 
you need the frame pointer or the Exception Lib is not going to be able to 
print out the stack backtrace of the code when you hit a breakpoint. So this is 
how I get to 11 vs. 1 bytes. 

Thanks,

Andrew Fish

PS for clang LTO the compiler compiles to bitcode and that is an abstracted 
assembly language. At link time all that code gets optimized to together and 
then passed through the CPU specific code gen. For C inline assembler the 
assembly instructions end up in the bitcode with lots of information about the 
constraints. That is why these GccInline.c functions almost always get inlined 
with clang and LTO. 

The CpuBreakpoint() function looks like this in bitcode, but the function call 
gets optimized away by LTO in the code gen. 

; Function Attrs: noinline nounwind optnone ssp uwtable
define void @CpuBreakpoint() #0 {
  call void asm sideeffect "int $$3", "~{dirflag},~{fpsr},~{flags}"() #2, 
!srcloc !3
  ret void
}

Even something more complex like AsmReadMsr64() can get inlined, but it 
contains a lot more info about the constraints:

; Function Attrs: noinline nounwind optnone ssp uwtable
define i64 @AsmReadMsr64(i32) #0 {
  %2 = alloca i32, align 4
  %3 = alloca i64, align 8
  store i32 %0, i32* %2, align 4
  %4 = load i32, i32* %2, align 4
  %5 = call i64 asm sideeffect "rdmsr", 
"=A,{cx},~{dirflag},~{fpsr},~{flags}"(i32 %4) #2, !srcloc !4
  store i64 %5, i64* %3, align 8
  %6 = load i64, i64* %3, align 8
  ret i64 %6
}

The alloca, store, load, etc are the same bitcode instructions you would see 
with C code. 

> A recently case that SetJump/LongJump, I updated the NASM file for both IA32 
> and X64.
> 
> Later, to my surprise, only X64 version NASM works, and IA32 version NASM 
> does not work.
> Then I notice that there is a different copy if IA32 Jump.c MS inline - I 
> also need update. That is frustrated.
> 
> I think there should be a balance between optimization and code 
> readability/maintainability.
> 
> Do we have data on what size benefit we can get with these inline function, 
> f

[edk2] [Patch V2 1/1] Document: Add PCD flexible format value EBNF in Fdf.

2019-03-06 Thread Feng, Bob C

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

This patch is to add flexible PCD value format EBNF into Fdf spec.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng 
Cc: Liming Gao 
Cc: Yonghong Zhu 
---
 3_edk_ii_fdf_file_format/32_fdf_definition.md | 25 
+
 3_edk_ii_fdf_file_format/35_[fd]_sections.md  |  4 ++--
 3_edk_ii_fdf_file_format/36_[fv]_sections.md  |  4 ++--
 3_edk_ii_fdf_file_format/37_[capsule]_sections.md |  4 ++--
 README.md |  1 +
 5 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/3_edk_ii_fdf_file_format/32_fdf_definition.md 
b/3_edk_ii_fdf_file_format/32_fdf_definition.md
index db098cf..2b044ab 100644
--- a/3_edk_ii_fdf_file_format/32_fdf_definition.md
+++ b/3_edk_ii_fdf_file_format/32_fdf_definition.md
@@ -1,9 +1,9 @@

[edk2] [Patch V2 0/1] Document: Add PCD flexible format value EBNF in Fdf.

2019-03-06 Thread Feng, Bob C

V2:
Update the revision history in README.md

This patch is to add flexible PCD value format EBNF into Fdf spec.

Feng, Bob C (1):
  Document: Add PCD flexible format value EBNF in Fdf.

 3_edk_ii_fdf_file_format/32_fdf_definition.md | 25 
+
 3_edk_ii_fdf_file_format/35_[fd]_sections.md  |  4 ++--
 3_edk_ii_fdf_file_format/36_[fv]_sections.md  |  4 ++--
 3_edk_ii_fdf_file_format/37_[capsule]_sections.md |  4 ++--
 README.md |  1 +
 5 files changed, 28 insertions(+), 10 deletions(-)

-- 
2.20.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code

2019-03-06 Thread Yao, Jiewen

HI Mike and Andrew
The problem is maintainability.

If we have multiple copy of implementation, a developer need verify multiple 
copy of implementation, if we make update. Before that, a developer has to be 
aware that there is multiple copy of implementation. - That increases the 
complexity.

If we have everything, there MAY be 5 copy - ASM, NASM, S, GCC inline, MS 
inline, theoretically.
Now, we remove ASM. It is good first step.
But we may still have 4 copies. I suggest we consider do more.

A recently case that SetJump/LongJump, I updated the NASM file for both IA32 
and X64.

Later, to my surprise, only X64 version NASM works, and IA32 version NASM does 
not work.
Then I notice that there is a different copy if IA32 Jump.c MS inline - I also 
need update. That is frustrated.

I think there should be a balance between optimization and code 
readability/maintainability.

Do we have data on what size benefit we can get with these inline function, 
from whole image level?
We can do evaluation at function level, case by case.
If we see a huge size benefit, I agree to keep this function.
If we see no size benefit, I suggest we do the cleanup for this function.


Thank you
Yao Jiewen



> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Andrew Fish via edk2-devel
> Sent: Wednesday, March 6, 2019 5:31 PM
> To: Kinney, Michael D 
> Cc: edk2-devel-01 ; Gao, Liming
> 
> Subject: Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove
> inline X86 assembly code
> 
> 
> 
> > On Mar 6, 2019, at 4:41 PM, Kinney, Michael D
>  wrote:
> >
> > Liming,
> >
> > That does not work either because inline assembly uses compiler specific
> syntax.
> >
> > Please update with the specific list of functions that you think the inline
> should be removed to improve maintenance with no impacts in size/perf.
> >
> 
> Mike,
> 
> It is easy to find the gcc/clang inline assembler, just `git grep "__asm__
> __volatile__"`
> 
> The main files are:
> https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseIoLib
> Intrinsic/IoLibGcc.c
> https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/X
> 64/GccInline.c
> https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/I
> a32/GccInline.c
> https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseSync
> hronizationLib/Ia32/GccInline.c
> https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseSync
> hronizationLib/X64/GccInline.c
> 
> This is really just compiler optimizer control.
> Library/BaseSynchronizationLib/SynchronizationGcc.c:21:#define
> _ReadWriteBarrier() do { __asm__ __volatile__ ("": : : "memory"); } while(0)
> 
> Looks like this is working around the alignment ASSERT in BaseIoLibIntrinsic.
> OvmfPkg/QemuVideoDxe/UnalignedIoGcc.c:43:  __asm__ __volatile__
> ( "outl %0, %1" : : "a" (Value), "d" ((UINT16)Port) );
> OvmfPkg/QemuVideoDxe/UnalignedIoGcc.c:67:  __asm__ __volatile__
> ( "inl %1, %0" : "=a" (Data) : "d" ((UINT16)Port) );
> 
> It seems like we have a reasonable set and should not use the inline
> assembly for any more complex code.
> 
> Thanks,
> 
> Andrew Fish
> 
> > The issue you pointed to was around SetJump()/LongJump().  Can we limit
> this BZ to only those 2 functions?
> >
> > Mike
> >   <>
> > From: Gao, Liming
> > Sent: Wednesday, March 6, 2019 4:28 PM
> > To: af...@apple.com
> > Cc: Zhang, Shenglei ; edk2-devel-01
> ; Kinney, Michael D
> 
> > Subject: RE: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove
> inline X86 assembly code
> >
> > Andrew:
> >   I want to keep only one implementation. If inline assembly c source is
> preferred, I suggest to remove its nasm implementation.
> >
> > Thanks
> > Liming
> >  <>From: af...@apple.com 
> [mailto:af...@apple.com ]
> > Sent: Tuesday, March 5, 2019 2:44 PM
> > To: Gao, Liming mailto:liming@intel.com>>
> > Cc: Zhang, Shenglei  >; edk2-devel-01
> mailto:edk2-devel@lists.01.org>>; Kinney,
> Michael D  >
> > Subject: Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove
> inline X86 assembly code
> >
> >
> >
> >
> > On Mar 5, 2019, at 1:32 PM, Gao, Liming  > wrote:
> >
> > Andrew:
> >  BZ 1163 is to remove inline X86 assembly code in C source file. But, this
> patch is wrong. I have gave my comments to update this patch.
> >
> >
> > Why do we want to remove inline X86 assembly. As I mentioned it will lead
> to larger binaries, slower binaries, and less optimized code.
> >
> > For example take this simple inline assembly function:
> >
> > VOID
> > EFIAPI
> > CpuBreakpoint (
> >   VOID
> >   )
> > {
> >   __asm__ __volatile__ ("int $3");
> > }
> >
> >
> > Today with clang LTO turned on calling CpuBreakpoint() looks like this from
> the callers point of view.
> >
> > a.out[0x1fa5] <+6>:  cc  int3
> >
> >
> > But if we move that to NASM:
> >
>

Re: [edk2] [Patch] UefiCpuPkg/MpInitLib: Direct allocate buffer for Wake up Buffer.

2019-03-06 Thread Dong, Eric

Hi Star,

This logic seems much complicated than mine. Also after CSM retired from EDKII, 
we will change this code back to only require allocate buffer below 1M. I will 
add such notes in the code comments.  So I prefer to use my change.

Thanks,
Eric

> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, March 5, 2019 3:33 PM
> To: Dong, Eric ; edk2-devel@lists.01.org
> Cc: Ni, Ray ; Laszlo Ersek (ler...@redhat.com)
> ; Zeng, Star 
> Subject: RE: [edk2] [Patch] UefiCpuPkg/MpInitLib: Direct allocate buffer for
> Wake up Buffer.
> 
> Just an idea to avoid hard code value 0x88000.
> 
> Before EndOfDxe: Allocate buffer in AllocateResetVector(), and free buffer
> in FreeResetVector().
> At EndOfDxe (it is after LegacyBiosDxe driver entry point) callback: Allocate
> buffer and record it to CpuMpData->WakeupBuffer, and always occupy the
> buffer, that means no free.
> After EndOfDxe: Use CpuMpData->WakeupBuffer.
> 
> 
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Eric Dong
> Sent: Tuesday, March 5, 2019 10:07 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch] UefiCpuPkg/MpInitLib: Direct allocate buffer for
> Wake up Buffer.
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=1538
> 
> Current CpuDxe driver "borrows" Wakeup Buffer (through Allocate & free to
> get the buffer pointer, backup the buffer data before using it and restore it
> after using).  Now this logic met a problem described in the above BZ
> because the test tool and the CpuDxe both use the same memory at the
> same time.
> 
> In order to fix the above issue, CpuDxe changed to allocate the buffer below
> 1M instead of borrow it. After investigation, we found below
> 0x88000 is the possible space which can be used. For now, range
> 0x6 ~ 0x88000 used for Legacy OPROMs by LegacyBios driver. And it tries
> to allocate these range page(4K size) by page. It just reports warning
> message if specific page been used by others already.
> 
> Also CpuDxe driver will produce CPU arch protocol and LegacyBios driver has
> dependency for this protocol. So CpuDxe driver will start before LegacyBios
> driver and CpuDxe driver can allocate that space successful.
> 
> With this change, CpuDxe driver will use 0x87000 ~ 0x88000 as wakeup buffer.
> 
> Cc: Ray Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong 
> ---
>  UefiCpuPkg/Library/MpInitLib/DxeMpLib.c | 30 +++
> ---
>  1 file changed, 19 insertions(+), 11 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> index b2307cbb61..5bc9a47efb 100644
> --- a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> @@ -76,7 +76,7 @@ SaveCpuMpData (
>  }
> 
>  /**
> -  Get available system memory below 1MB by specified size.
> +  Get available system memory below 0x88000 by specified size.
> 
>@param[in] WakeupBufferSize   Wakeup buffer size required
> 
> @@ -91,7 +91,19 @@ GetWakeupBuffer (
>EFI_STATUS  Status;
>EFI_PHYSICAL_ADDRESSStartAddress;
> 
> -  StartAddress = BASE_1MB;
> +  //
> +  // Current "Borrow" space mechanism caused potential race condition
> + if both  // AP and the original owner use the share space.
> +  //
> +  // LegacyBios driver tries to allocate 4K pages between 0x6 ~
> + 0x88000  // space. It will just report an waring message if the page
> + has been allocate  // by other drivers.
> +  // LagacyBios driver depends on CPU Arch protocol, so it will start
> + after  // CpuDxe driver which produce Cpu Arch Protocol and use this
> library.
> +  // So below allocate logic will be trigged before LegacyBios driver
> + and it  // will always return success.
> +  //
> +  StartAddress = BASE_512KB + BASE_32KB;
>Status = gBS->AllocatePages (
>AllocateMaxAddress,
>EfiBootServicesData,
> @@ -99,17 +111,13 @@ GetWakeupBuffer (
>&StartAddress
>);
>ASSERT_EFI_ERROR (Status);
> -  if (!EFI_ERROR (Status)) {
> -Status = gBS->FreePages(
> -   StartAddress,
> -   EFI_SIZE_TO_PAGES (WakeupBufferSize)
> -   );
> -ASSERT_EFI_ERROR (Status);
> -DEBUG ((DEBUG_INFO, "WakeupBufferStart = %x, WakeupBufferSize
> = %x\n",
> -(UINTN) StartAddress, WakeupBufferSize));
> -  } else {
> +  if (EFI_ERROR (Status)) {
>  StartAddress = (EFI_PHYSICAL_ADDRESS) -1;
>}
> +
> +  DEBUG ((DEBUG_INFO, "WakeupBufferStart = %x, WakeupBufferSize
> = %x\n",
> +  (UINTN) StartAddress, WakeupBufferSize));
> +
>return (UINTN) StartAddress;
>  }
> 
> --
> 2.15.0.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___

Re: [edk2] [Patch v2 2/4] UefiCpuPkg/RegisterCpuFeaturesLib: Optimize PCD PcdCpuFeaturesUserConfiguration.

2019-03-06 Thread Dong, Eric

Hi Star,

Thanks for your comments. It's more clear when mine. Will update it in my next 
version changes.

Also I will add this change info in the upgrade notes.

Thanks,
Eric

> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, March 5, 2019 5:57 PM
> To: Dong, Eric ; edk2-devel@lists.01.org
> Cc: Ni, Ray ; Laszlo Ersek (ler...@redhat.com)
> ; Gao, Liming ; Zeng, Star
> 
> Subject: RE: [edk2] [Patch v2 2/4] UefiCpuPkg/RegisterCpuFeaturesLib:
> Optimize PCD PcdCpuFeaturesUserConfiguration.
> 
> And suggest update the title to be like "UefiCpuPkg: Retire
> PcdCpuFeaturesUserConfiguration".
> 
> Thanks,
> Star
> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, March 5, 2019 5:55 PM
> To: Dong, Eric ; edk2-devel@lists.01.org
> Cc: Ni, Ray ; Laszlo Ersek (ler...@redhat.com)
> ; Gao, Liming ; Zeng, Star
> 
> Subject: RE: [edk2] [Patch v2 2/4] UefiCpuPkg/RegisterCpuFeaturesLib:
> Optimize PCD PcdCpuFeaturesUserConfiguration.
> 
> It should be an incompatible change to remove
> PcdCpuFeaturesUserConfiguration.
> Please add upgrade notes for it. I know upgrade notes for 2019 Q1 stable tag
> is at https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-
> Notes. I do not know where is the link for 2019 Q1 stable tag. Liming may
> know it.
> 
> 
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Eric Dong
> Sent: Friday, March 1, 2019 1:40 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch v2 2/4] UefiCpuPkg/RegisterCpuFeaturesLib: Optimize
> PCD PcdCpuFeaturesUserConfiguration.
> 
> Merge PcdCpuFeaturesUserConfiguration into PcdCpuFeaturesSetting.
> Use PcdCpuFeaturesSetting as input for the user input feature setting Use
> PcdCpuFeaturesSetting as output for the final CPU feature setting
> 
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1375
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong 
> ---
>  .../RegisterCpuFeaturesLib/CpuFeaturesInitialize.c | 71 
> +-
>  .../DxeRegisterCpuFeaturesLib.inf  |  3 +-
>  .../PeiRegisterCpuFeaturesLib.inf  |  3 +-
>  .../RegisterCpuFeaturesLib/RegisterCpuFeatures.h   |  1 -
>  UefiCpuPkg/UefiCpuPkg.dec  |  9 +--
>  5 files changed, 21 insertions(+), 66 deletions(-)
> 
> diff --git
> a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> index bae92b89a6..d877caff74 100644
> --- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> +++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> @@ -21,16 +21,21 @@ CHAR16 *mRegisterTypeStr[] = {L"MSR", L"CR",
> L"MMIO", L"CACHE", L"SEMAP", L"INVA
>Worker function to save PcdCpuFeaturesCapability.
> 
>@param[in]  SupportedFeatureMask  The pointer to CPU feature bits mask
> buffer
> +  @param[in]  FeatureMaskSize   CPU feature bits mask buffer size.
> +
>  **/
>  VOID
>  SetCapabilityPcd (
> -  IN UINT8   *SupportedFeatureMask
> +  IN UINT8   *SupportedFeatureMask,
> +  IN UINT32  FeatureMaskSize
>)
>  {
>EFI_STATUS Status;
>UINTN  BitMaskSize;
> 
>BitMaskSize = PcdGetSize (PcdCpuFeaturesCapability);
> +  ASSERT (FeatureMaskSize == BitMaskSize);
> +
>Status = PcdSetPtrS (PcdCpuFeaturesCapability, &BitMaskSize,
> SupportedFeatureMask);
>ASSERT_EFI_ERROR (Status);
>  }
> @@ -53,48 +58,6 @@ SetSettingPcd (
>ASSERT_EFI_ERROR (Status);
>  }
> 
> -/**
> -  Worker function to get PcdCpuFeaturesSupport.
> -
> -  @return  The pointer to CPU feature bits mask buffer.
> -**/
> -UINT8 *
> -GetSupportPcd (
> -  VOID
> -  )
> -{
> -  UINT8  *SupportBitMask;
> -
> -  SupportBitMask = AllocateCopyPool (
> -  PcdGetSize (PcdCpuFeaturesSupport),
> -  PcdGetPtr (PcdCpuFeaturesSupport)
> -  );
> -  ASSERT (SupportBitMask != NULL);
> -
> -  return SupportBitMask;
> -}
> -
> -/**
> -  Worker function to get PcdCpuFeaturesUserConfiguration.
> -
> -  @return  The pointer to CPU feature bits mask buffer.
> -**/
> -UINT8 *
> -GetConfigurationPcd (
> -  VOID
> -  )
> -{
> -  UINT8  *SupportBitMask;
> -
> -  SupportBitMask = AllocateCopyPool (
> -  PcdGetSize (PcdCpuFeaturesUserConfiguration),
> -  PcdGetPtr (PcdCpuFeaturesUserConfiguration)
> -  );
> -  ASSERT (SupportBitMask != NULL);
> -
> -  return SupportBitMask;
> -}
> -
>  /**
>Collects CPU type and feature information.
> 
> @@ -287,7 +250,6 @@ CpuInitDataInitialize (
>// Get support and configuration PCDs
>//
>CpuFeaturesData->SupportPcd   = GetSupportPcd ();
> -  CpuFeaturesData->ConfigurationPcd = GetConfigurationPcd ();  }
> 
>  /**
> @@ -610,16 +572,9 @@ AnalysisProcessorFeatures (
>//
>// Calculate the last setting
>//
> -
>CpuFeaturesDat

[edk2] [PATCH 05/10] MdePkg/BaseLib: Remove .S files for IA32 and X64 arch

2019-03-06 Thread Shenglei Zhang

.nasm file has been added for X86 arch. .S assembly code
is not required any more.
https://bugzilla.tianocore.org/show_bug.cgi?id=1594

Cc: Michael D Kinney 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 MdePkg/Library/BaseLib/BaseLib.inf|  38 --
 MdePkg/Library/BaseLib/Ia32/ARShiftU64.S  |  43 ---
 MdePkg/Library/BaseLib/Ia32/CpuId.S   |  63 
 MdePkg/Library/BaseLib/Ia32/CpuIdEx.S |  67 
 MdePkg/Library/BaseLib/Ia32/DisableCache.S|  39 --
 MdePkg/Library/BaseLib/Ia32/DisablePaging32.S |  52 ---
 MdePkg/Library/BaseLib/Ia32/DivU64x32.S   |  41 ---
 .../Library/BaseLib/Ia32/DivU64x32Remainder.S |  46 ---
 .../Library/BaseLib/Ia32/DivU64x64Remainder.S |  89 -
 MdePkg/Library/BaseLib/Ia32/EnableCache.S |  39 --
 .../BaseLib/Ia32/EnableDisableInterrupts.S|  36 --
 MdePkg/Library/BaseLib/Ia32/EnablePaging32.S  |  52 ---
 MdePkg/Library/BaseLib/Ia32/EnablePaging64.S  |  63 
 .../BaseLib/Ia32/InternalSwitchStack.S|  48 ---
 MdePkg/Library/BaseLib/Ia32/LRotU64.S |  48 ---
 MdePkg/Library/BaseLib/Ia32/LShiftU64.S   |  43 ---
 MdePkg/Library/BaseLib/Ia32/LongJump.S|  41 ---
 MdePkg/Library/BaseLib/Ia32/ModU64x32.S   |  40 ---
 MdePkg/Library/BaseLib/Ia32/Monitor.S |  40 ---
 MdePkg/Library/BaseLib/Ia32/MultU64x32.S  |  41 ---
 MdePkg/Library/BaseLib/Ia32/MultU64x64.S  |  44 ---
 MdePkg/Library/BaseLib/Ia32/Mwait.S   |  38 --
 MdePkg/Library/BaseLib/Ia32/RRotU64.S |  48 ---
 MdePkg/Library/BaseLib/Ia32/RShiftU64.S   |  46 ---
 MdePkg/Library/BaseLib/Ia32/RdRand.S  |  80 -
 MdePkg/Library/BaseLib/Ia32/SetJump.S |  44 ---
 MdePkg/Library/BaseLib/Ia32/SwapBytes64.S |  38 --
 MdePkg/Library/BaseLib/Ia32/Thunk16.S | 222 
 MdePkg/Library/BaseLib/X64/CpuId.S|  60 
 MdePkg/Library/BaseLib/X64/CpuIdEx.S  |  62 
 MdePkg/Library/BaseLib/X64/DisableCache.S |  39 --
 MdePkg/Library/BaseLib/X64/DisablePaging64.S  |  82 -
 MdePkg/Library/BaseLib/X64/EnableCache.S  |  39 --
 .../BaseLib/X64/EnableDisableInterrupts.S |  36 --
 MdePkg/Library/BaseLib/X64/LongJump.S |  54 ---
 MdePkg/Library/BaseLib/X64/RdRand.S   |  72 
 MdePkg/Library/BaseLib/X64/SetJump.S  |  53 ---
 MdePkg/Library/BaseLib/X64/SwitchStack.S  |  52 ---
 MdePkg/Library/BaseLib/X64/Thunk16.S  | 334 --
 39 files changed, 2412 deletions(-)
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/ARShiftU64.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/CpuId.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/CpuIdEx.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/DisableCache.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/DisablePaging32.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/DivU64x32.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/DivU64x32Remainder.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/DivU64x64Remainder.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/EnableCache.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/EnableDisableInterrupts.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/EnablePaging32.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/EnablePaging64.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/InternalSwitchStack.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/LRotU64.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/LShiftU64.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/LongJump.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/ModU64x32.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/Monitor.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/MultU64x32.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/MultU64x64.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/Mwait.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/RRotU64.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/RShiftU64.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/RdRand.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/SetJump.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/SwapBytes64.S
 delete mode 100644 MdePkg/Library/BaseLib/Ia32/Thunk16.S
 delete mode 100644 MdePkg/Library/BaseLib/X64/CpuId.S
 delete mode 100644 MdePkg/Library/BaseLib/X64/CpuIdEx.S
 delete mode 100644 MdePkg/Library/BaseLib/X64/DisableCache.S
 delete mode 100644 MdePkg/Library/BaseLib/X64/DisablePaging64.S
 delete mode 100644 MdePkg/Library/BaseLib/X64/EnableCache.S
 delete mode 100644 MdePkg/Library/BaseLib/X64/EnableDisableInterrupts.S
 delete mode 100644 MdePkg/Library/BaseLib/X64/LongJump.S
 delete mode 100644 MdePkg/Library/BaseLib/X64/RdRand.S
 delete mode 100644 MdePkg/Library/BaseLib/X64/SetJump.S
 delete mode 100644 MdePkg/Library/BaseLib/X64/SwitchStack.S
 delete mode 100644 MdePkg/Library/BaseLib/X64/Thunk16.S

diff --git a/MdePkg/Library/BaseLib/BaseLib.inf 
b/MdePkg/Library/BaseLib/BaseLib.inf
index a0d6c372f9..16829deeb4 10064

[edk2] [PATCH 10/10] MdePkg/BaseMemoryLibSse2: Remove .S files for IA32 and X64 arch

2019-03-06 Thread Shenglei Zhang

.nasm file has been added for X86 arch. .S assembly code
is not required any more.
https://bugzilla.tianocore.org/show_bug.cgi?id=1594

Cc: Michael D Kinney 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 .../BaseMemoryLibSse2/BaseMemoryLibSse2.inf   | 22 -
 .../BaseMemoryLibSse2/Ia32/CompareMem.S   | 55 
 .../Library/BaseMemoryLibSse2/Ia32/CopyMem.S  | 85 ---
 .../BaseMemoryLibSse2/Ia32/ScanMem16.S| 52 
 .../BaseMemoryLibSse2/Ia32/ScanMem32.S| 52 
 .../BaseMemoryLibSse2/Ia32/ScanMem64.S| 61 -
 .../Library/BaseMemoryLibSse2/Ia32/ScanMem8.S | 52 
 .../Library/BaseMemoryLibSse2/Ia32/SetMem.S   | 76 -
 .../Library/BaseMemoryLibSse2/Ia32/SetMem16.S | 69 ---
 .../Library/BaseMemoryLibSse2/Ia32/SetMem32.S | 68 ---
 .../Library/BaseMemoryLibSse2/Ia32/SetMem64.S | 58 -
 .../Library/BaseMemoryLibSse2/Ia32/ZeroMem.S  | 65 --
 .../BaseMemoryLibSse2/X64/CompareMem.S| 59 -
 .../Library/BaseMemoryLibSse2/X64/CopyMem.S   | 83 --
 .../Library/BaseMemoryLibSse2/X64/ScanMem16.S | 56 
 .../Library/BaseMemoryLibSse2/X64/ScanMem32.S | 56 
 .../Library/BaseMemoryLibSse2/X64/ScanMem64.S | 56 
 .../Library/BaseMemoryLibSse2/X64/ScanMem8.S  | 56 
 MdePkg/Library/BaseMemoryLibSse2/X64/SetMem.S | 72 
 .../Library/BaseMemoryLibSse2/X64/SetMem16.S  | 70 ---
 .../Library/BaseMemoryLibSse2/X64/SetMem32.S  | 69 ---
 .../Library/BaseMemoryLibSse2/X64/SetMem64.S  | 60 -
 .../Library/BaseMemoryLibSse2/X64/ZeroMem.S   | 65 --
 23 files changed, 1417 deletions(-)
 delete mode 100644 MdePkg/Library/BaseMemoryLibSse2/Ia32/CompareMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibSse2/Ia32/CopyMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibSse2/Ia32/ScanMem16.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibSse2/Ia32/ScanMem32.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibSse2/Ia32/ScanMem64.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibSse2/Ia32/ScanMem8.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibSse2/Ia32/SetMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibSse2/Ia32/SetMem16.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibSse2/Ia32/SetMem32.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibSse2/Ia32/SetMem64.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibSse2/Ia32/ZeroMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibSse2/X64/CompareMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibSse2/X64/CopyMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibSse2/X64/ScanMem16.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibSse2/X64/ScanMem32.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibSse2/X64/ScanMem64.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibSse2/X64/ScanMem8.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibSse2/X64/SetMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibSse2/X64/SetMem16.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibSse2/X64/SetMem32.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibSse2/X64/SetMem64.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibSse2/X64/ZeroMem.S

diff --git a/MdePkg/Library/BaseMemoryLibSse2/BaseMemoryLibSse2.inf 
b/MdePkg/Library/BaseMemoryLibSse2/BaseMemoryLibSse2.inf
index 771fddaa45..340ca15f06 100644
--- a/MdePkg/Library/BaseMemoryLibSse2/BaseMemoryLibSse2.inf
+++ b/MdePkg/Library/BaseMemoryLibSse2/BaseMemoryLibSse2.inf
@@ -47,27 +47,16 @@
 
 [Sources.Ia32]
   Ia32/ScanMem64.nasm
-  Ia32/ScanMem64.S
   Ia32/ScanMem32.nasm
-  Ia32/ScanMem32.S
   Ia32/ScanMem16.nasm
-  Ia32/ScanMem16.S
   Ia32/ScanMem8.nasm
-  Ia32/ScanMem8.S
   Ia32/CompareMem.nasm
-  Ia32/CompareMem.S
   Ia32/ZeroMem.nasm
-  Ia32/ZeroMem.S
   Ia32/SetMem64.nasm
-  Ia32/SetMem64.S
   Ia32/SetMem32.nasm
-  Ia32/SetMem32.S
   Ia32/SetMem16.nasm
-  Ia32/SetMem16.S
   Ia32/SetMem.nasm
-  Ia32/SetMem.S
   Ia32/CopyMem.nasm
-  Ia32/CopyMem.S
   Ia32/ScanMem64.nasm
   Ia32/ScanMem32.nasm
   Ia32/ScanMem16.nasm
@@ -94,27 +83,16 @@
   X64/SetMem.nasm
   X64/CopyMem.nasm
   X64/ScanMem64.nasm
-  X64/ScanMem64.S
   X64/ScanMem32.nasm
-  X64/ScanMem32.S
   X64/ScanMem16.nasm
-  X64/ScanMem16.S
   X64/ScanMem8.nasm
-  X64/ScanMem8.S
   X64/CompareMem.nasm
-  X64/CompareMem.S
   X64/ZeroMem.nasm
-  X64/ZeroMem.S
   X64/SetMem64.nasm
-  X64/SetMem64.S
   X64/SetMem32.nasm
-  X64/SetMem32.S
   X64/SetMem16.nasm
-  X64/SetMem16.S
   X64/SetMem.nasm
-  X64/SetMem.S
   X64/CopyMem.nasm
-  X64/CopyMem.S
   X64/IsZeroBuffer.nasm
 
 [Packages]
diff --git a/MdePkg/Library/BaseMemoryLibSse2/Ia32/CompareMem.S 
b/MdePkg/Library/BaseMemoryLibSse2/Ia32/CompareMem.S
deleted file mode 100644
index b509586adb..00
--- a/MdePkg/Library/BaseMemoryLibSse2/Ia32/CompareMem.S
+++ /dev/null
@@ -1,55 +0,0 @@
-#--

[edk2] [PATCH 06/10] MdePkg/BaseMemoryLibMmx: Remove .S files for IA32 and X64 arch

2019-03-06 Thread Shenglei Zhang

.nasm file has been added for X86 arch. .S assembly code
is not required any more.
https://bugzilla.tianocore.org/show_bug.cgi?id=1594

Cc: Michael D Kinney 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 .../BaseMemoryLibMmx/BaseMemoryLibMmx.inf | 22 -
 .../BaseMemoryLibMmx/Ia32/CompareMem.S| 55 
 .../Library/BaseMemoryLibMmx/Ia32/CopyMem.S   | 86 ---
 .../Library/BaseMemoryLibMmx/Ia32/ScanMem16.S | 52 ---
 .../Library/BaseMemoryLibMmx/Ia32/ScanMem32.S | 52 ---
 .../Library/BaseMemoryLibMmx/Ia32/ScanMem64.S | 61 -
 .../Library/BaseMemoryLibMmx/Ia32/ScanMem8.S  | 52 ---
 MdePkg/Library/BaseMemoryLibMmx/Ia32/SetMem.S | 66 --
 .../Library/BaseMemoryLibMmx/Ia32/SetMem16.S  | 59 -
 .../Library/BaseMemoryLibMmx/Ia32/SetMem32.S  | 52 ---
 .../Library/BaseMemoryLibMmx/Ia32/SetMem64.S  | 43 --
 .../Library/BaseMemoryLibMmx/Ia32/ZeroMem.S   | 54 
 .../Library/BaseMemoryLibMmx/X64/CompareMem.S | 59 -
 MdePkg/Library/BaseMemoryLibMmx/X64/CopyMem.S | 74 
 .../Library/BaseMemoryLibMmx/X64/ScanMem16.S  | 56 
 .../Library/BaseMemoryLibMmx/X64/ScanMem32.S  | 56 
 .../Library/BaseMemoryLibMmx/X64/ScanMem64.S  | 55 
 .../Library/BaseMemoryLibMmx/X64/ScanMem8.S   | 56 
 MdePkg/Library/BaseMemoryLibMmx/X64/SetMem.S  | 61 -
 .../Library/BaseMemoryLibMmx/X64/SetMem16.S   | 60 -
 .../Library/BaseMemoryLibMmx/X64/SetMem32.S   | 55 
 .../Library/BaseMemoryLibMmx/X64/SetMem64.S   | 47 --
 MdePkg/Library/BaseMemoryLibMmx/X64/ZeroMem.S | 57 
 23 files changed, 1290 deletions(-)
 delete mode 100644 MdePkg/Library/BaseMemoryLibMmx/Ia32/CompareMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibMmx/Ia32/CopyMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibMmx/Ia32/ScanMem16.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibMmx/Ia32/ScanMem32.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibMmx/Ia32/ScanMem64.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibMmx/Ia32/ScanMem8.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibMmx/Ia32/SetMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibMmx/Ia32/SetMem16.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibMmx/Ia32/SetMem32.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibMmx/Ia32/SetMem64.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibMmx/Ia32/ZeroMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibMmx/X64/CompareMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibMmx/X64/CopyMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibMmx/X64/ScanMem16.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibMmx/X64/ScanMem32.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibMmx/X64/ScanMem64.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibMmx/X64/ScanMem8.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibMmx/X64/SetMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibMmx/X64/SetMem16.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibMmx/X64/SetMem32.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibMmx/X64/SetMem64.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibMmx/X64/ZeroMem.S

diff --git a/MdePkg/Library/BaseMemoryLibMmx/BaseMemoryLibMmx.inf 
b/MdePkg/Library/BaseMemoryLibMmx/BaseMemoryLibMmx.inf
index d17fcf24b6..9a073d1cd9 100644
--- a/MdePkg/Library/BaseMemoryLibMmx/BaseMemoryLibMmx.inf
+++ b/MdePkg/Library/BaseMemoryLibMmx/BaseMemoryLibMmx.inf
@@ -52,27 +52,16 @@
 
 [Sources.Ia32]
   Ia32/ScanMem64.nasm
-  Ia32/ScanMem64.S
   Ia32/ScanMem32.nasm
-  Ia32/ScanMem32.S
   Ia32/ScanMem16.nasm
-  Ia32/ScanMem16.S
   Ia32/ScanMem8.nasm
-  Ia32/ScanMem8.S
   Ia32/CompareMem.nasm
-  Ia32/CompareMem.S
   Ia32/SetMem64.nasm
-  Ia32/SetMem64.S
   Ia32/SetMem32.nasm
-  Ia32/SetMem32.S
   Ia32/SetMem16.nasm
-  Ia32/SetMem16.S
   Ia32/ZeroMem.nasm
-  Ia32/ZeroMem.S
   Ia32/SetMem.nasm
-  Ia32/SetMem.S
   Ia32/CopyMem.nasm
-  Ia32/CopyMem.S
   Ia32/ScanMem64.nasm
   Ia32/ScanMem32.nasm
   Ia32/ScanMem16.nasm
@@ -99,27 +88,16 @@
   X64/SetMem.nasm
   X64/CopyMem.nasm
   X64/ScanMem64.nasm
-  X64/ScanMem64.S
   X64/ScanMem32.nasm
-  X64/ScanMem32.S
   X64/ScanMem16.nasm
-  X64/ScanMem16.S
   X64/ScanMem8.nasm
-  X64/ScanMem8.S
   X64/CompareMem.nasm
-  X64/CompareMem.S
   X64/SetMem64.nasm
-  X64/SetMem64.S
   X64/SetMem32.nasm
-  X64/SetMem32.S
   X64/SetMem16.nasm
-  X64/SetMem16.S
   X64/ZeroMem.nasm
-  X64/ZeroMem.S
   X64/SetMem.nasm
-  X64/SetMem.S
   X64/CopyMem.nasm
-  X64/CopyMem.S
   X64/IsZeroBuffer.nasm
 
 
diff --git a/MdePkg/Library/BaseMemoryLibMmx/Ia32/CompareMem.S 
b/MdePkg/Library/BaseMemoryLibMmx/Ia32/CompareMem.S
deleted file mode 100644
index b509586adb..00
--- a/MdePkg/Library/BaseMemoryLibMmx/Ia32/CompareMem.S
+++ /dev/null
@@ -1,55 +0,0 @@
-#--
-#
-# Copyright (c

[edk2] [PATCH 07/10] MdePkg/BaseMemoryLibOptDxe: Remove .S files for IA32 and X64 arch

2019-03-06 Thread Shenglei Zhang

.nasm file has been added for X86 arch. .S assembly code
is not required any more.
https://bugzilla.tianocore.org/show_bug.cgi?id=1594

Cc: Michael D Kinney 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 .../BaseMemoryLibOptDxe.inf   | 22 -
 .../BaseMemoryLibOptDxe/Ia32/CompareMem.S | 55 
 .../BaseMemoryLibOptDxe/Ia32/CopyMem.S| 85 ---
 .../BaseMemoryLibOptDxe/Ia32/ScanMem16.S  | 52 
 .../BaseMemoryLibOptDxe/Ia32/ScanMem32.S  | 52 
 .../BaseMemoryLibOptDxe/Ia32/ScanMem64.S  | 61 -
 .../BaseMemoryLibOptDxe/Ia32/ScanMem8.S   | 52 
 .../Library/BaseMemoryLibOptDxe/Ia32/SetMem.S | 50 ---
 .../BaseMemoryLibOptDxe/Ia32/SetMem16.S   | 43 --
 .../BaseMemoryLibOptDxe/Ia32/SetMem32.S   | 43 --
 .../BaseMemoryLibOptDxe/Ia32/SetMem64.S   | 46 --
 .../BaseMemoryLibOptDxe/Ia32/ZeroMem.S| 49 ---
 .../BaseMemoryLibOptDxe/X64/CompareMem.S  | 59 -
 .../Library/BaseMemoryLibOptDxe/X64/CopyMem.S | 82 --
 .../BaseMemoryLibOptDxe/X64/ScanMem16.S   | 56 
 .../BaseMemoryLibOptDxe/X64/ScanMem32.S   | 56 
 .../BaseMemoryLibOptDxe/X64/ScanMem64.S   | 55 
 .../BaseMemoryLibOptDxe/X64/ScanMem8.S| 56 
 .../Library/BaseMemoryLibOptDxe/X64/SetMem.S  | 57 -
 .../BaseMemoryLibOptDxe/X64/SetMem16.S| 47 --
 .../BaseMemoryLibOptDxe/X64/SetMem32.S| 47 --
 .../BaseMemoryLibOptDxe/X64/SetMem64.S| 46 --
 .../Library/BaseMemoryLibOptDxe/X64/ZeroMem.S | 51 ---
 23 files changed, 1222 deletions(-)
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptDxe/Ia32/CompareMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptDxe/Ia32/CopyMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptDxe/Ia32/ScanMem16.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptDxe/Ia32/ScanMem32.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptDxe/Ia32/ScanMem64.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptDxe/Ia32/ScanMem8.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptDxe/Ia32/SetMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptDxe/Ia32/SetMem16.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptDxe/Ia32/SetMem32.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptDxe/Ia32/SetMem64.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptDxe/Ia32/ZeroMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptDxe/X64/CompareMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptDxe/X64/CopyMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptDxe/X64/ScanMem16.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptDxe/X64/ScanMem32.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptDxe/X64/ScanMem64.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptDxe/X64/ScanMem8.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptDxe/X64/SetMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptDxe/X64/SetMem16.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptDxe/X64/SetMem32.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptDxe/X64/SetMem64.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptDxe/X64/ZeroMem.S

diff --git a/MdePkg/Library/BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf 
b/MdePkg/Library/BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf
index 3f756647e1..5ee1d70473 100644
--- a/MdePkg/Library/BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf
+++ b/MdePkg/Library/BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf
@@ -35,27 +35,16 @@
 
 [Sources.Ia32]
   Ia32/ScanMem64.nasm
-  Ia32/ScanMem64.S
   Ia32/ScanMem32.nasm
-  Ia32/ScanMem32.S
   Ia32/ScanMem16.nasm
-  Ia32/ScanMem16.S
   Ia32/ScanMem8.nasm
-  Ia32/ScanMem8.S
   Ia32/CompareMem.nasm
-  Ia32/CompareMem.S
   Ia32/ZeroMem.nasm
-  Ia32/ZeroMem.S
   Ia32/SetMem64.nasm
-  Ia32/SetMem64.S
   Ia32/SetMem32.nasm
-  Ia32/SetMem32.S
   Ia32/SetMem16.nasm
-  Ia32/SetMem16.S
   Ia32/SetMem.nasm
-  Ia32/SetMem.S
   Ia32/CopyMem.nasm
-  Ia32/CopyMem.S
   Ia32/ScanMem64.nasm
   Ia32/ScanMem32.nasm
   Ia32/ScanMem16.nasm
@@ -72,27 +61,16 @@
 
 [Sources.X64]
   X64/ScanMem64.nasm
-  X64/ScanMem64.S
   X64/ScanMem32.nasm
-  X64/ScanMem32.S
   X64/ScanMem16.nasm
-  X64/ScanMem16.S
   X64/ScanMem8.nasm
-  X64/ScanMem8.S
   X64/CompareMem.nasm
-  X64/CompareMem.S
   X64/ZeroMem.nasm
-  X64/ZeroMem.S
   X64/SetMem64.nasm
-  X64/SetMem64.S
   X64/SetMem32.nasm
-  X64/SetMem32.S
   X64/SetMem16.nasm
-  X64/SetMem16.S
   X64/SetMem.nasm
-  X64/SetMem.S
   X64/CopyMem.nasm
-  X64/CopyMem.S
   X64/IsZeroBuffer.nasm
   MemLibGuid.c
 
diff --git a/MdePkg/Library/BaseMemoryLibOptDxe/Ia32/CompareMem.S 
b/MdePkg/Library/BaseMemoryLibOptDxe/Ia32/CompareMem.S
deleted file mode 100644
index 23758781c9..00
--- a/MdePkg/Library/BaseMemoryLibOptDxe/Ia32/CompareMem.S
+++ /dev/null
@@ -1,55 +0,0 @@
-#---

[edk2] [PATCH 09/10] MdePkg/BaseMemoryLibRepStr: Remove .S files for IA32 and X64 arch

2019-03-06 Thread Shenglei Zhang

.nasm file has been added for X86 arch. .S assembly code
is not required any more.
https://bugzilla.tianocore.org/show_bug.cgi?id=1594

Cc: Michael D Kinney 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 .../BaseMemoryLibRepStr.inf   | 22 ---
 .../BaseMemoryLibRepStr/Ia32/CompareMem.S | 55 
 .../BaseMemoryLibRepStr/Ia32/CopyMem.S| 65 --
 .../BaseMemoryLibRepStr/Ia32/ScanMem16.S  | 54 ---
 .../BaseMemoryLibRepStr/Ia32/ScanMem32.S  | 54 ---
 .../BaseMemoryLibRepStr/Ia32/ScanMem64.S  | 63 --
 .../BaseMemoryLibRepStr/Ia32/ScanMem8.S   | 54 ---
 .../Library/BaseMemoryLibRepStr/Ia32/SetMem.S | 46 -
 .../BaseMemoryLibRepStr/Ia32/SetMem16.S   | 43 
 .../BaseMemoryLibRepStr/Ia32/SetMem32.S   | 43 
 .../BaseMemoryLibRepStr/Ia32/SetMem64.S   | 46 -
 .../BaseMemoryLibRepStr/Ia32/ZeroMem.S| 49 --
 .../BaseMemoryLibRepStr/X64/CompareMem.S  | 59 -
 .../Library/BaseMemoryLibRepStr/X64/CopyMem.S | 66 ---
 .../BaseMemoryLibRepStr/X64/ScanMem16.S   | 56 
 .../BaseMemoryLibRepStr/X64/ScanMem32.S   | 56 
 .../BaseMemoryLibRepStr/X64/ScanMem64.S   | 56 
 .../BaseMemoryLibRepStr/X64/ScanMem8.S| 56 
 .../Library/BaseMemoryLibRepStr/X64/SetMem.S  | 47 -
 .../BaseMemoryLibRepStr/X64/SetMem16.S| 47 -
 .../BaseMemoryLibRepStr/X64/SetMem32.S| 47 -
 .../BaseMemoryLibRepStr/X64/SetMem64.S| 46 -
 .../Library/BaseMemoryLibRepStr/X64/ZeroMem.S | 50 --
 23 files changed, 1180 deletions(-)
 delete mode 100644 MdePkg/Library/BaseMemoryLibRepStr/Ia32/CompareMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibRepStr/Ia32/CopyMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibRepStr/Ia32/ScanMem16.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibRepStr/Ia32/ScanMem32.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibRepStr/Ia32/ScanMem64.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibRepStr/Ia32/ScanMem8.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibRepStr/Ia32/SetMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibRepStr/Ia32/SetMem16.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibRepStr/Ia32/SetMem32.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibRepStr/Ia32/SetMem64.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibRepStr/Ia32/ZeroMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibRepStr/X64/CompareMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibRepStr/X64/CopyMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibRepStr/X64/ScanMem16.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibRepStr/X64/ScanMem32.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibRepStr/X64/ScanMem64.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibRepStr/X64/ScanMem8.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibRepStr/X64/SetMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibRepStr/X64/SetMem16.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibRepStr/X64/SetMem32.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibRepStr/X64/SetMem64.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibRepStr/X64/ZeroMem.S

diff --git a/MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf 
b/MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf
index 049936deab..7b315b8302 100644
--- a/MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf
+++ b/MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf
@@ -48,27 +48,16 @@
 
 [Sources.Ia32]
   Ia32/ScanMem64.nasm
-  Ia32/ScanMem64.S
   Ia32/ScanMem32.nasm
-  Ia32/ScanMem32.S
   Ia32/ScanMem16.nasm
-  Ia32/ScanMem16.S
   Ia32/ScanMem8.nasm
-  Ia32/ScanMem8.S
   Ia32/CompareMem.nasm
-  Ia32/CompareMem.S
   Ia32/ZeroMem.nasm
-  Ia32/ZeroMem.S
   Ia32/SetMem64.nasm
-  Ia32/SetMem64.S
   Ia32/SetMem32.nasm
-  Ia32/SetMem32.S
   Ia32/SetMem16.nasm
-  Ia32/SetMem16.S
   Ia32/SetMem.nasm
-  Ia32/SetMem.S
   Ia32/CopyMem.nasm
-  Ia32/CopyMem.S
   Ia32/ScanMem64.nasm
   Ia32/ScanMem32.nasm
   Ia32/ScanMem16.nasm
@@ -84,27 +73,16 @@
 
 [Sources.X64]
   X64/ScanMem64.nasm
-  X64/ScanMem64.S
   X64/ScanMem32.nasm
-  X64/ScanMem32.S
   X64/ScanMem16.nasm
-  X64/ScanMem16.S
   X64/ScanMem8.nasm
-  X64/ScanMem8.S
   X64/CompareMem.nasm
-  X64/CompareMem.S
   X64/ZeroMem.nasm
-  X64/ZeroMem.S
   X64/SetMem64.nasm
-  X64/SetMem64.S
   X64/SetMem32.nasm
-  X64/SetMem32.S
   X64/SetMem16.nasm
-  X64/SetMem16.S
   X64/SetMem.nasm
-  X64/SetMem.S
   X64/CopyMem.nasm
-  X64/CopyMem.S
   X64/ScanMem64.nasm
   X64/ScanMem32.nasm
   X64/ScanMem16.nasm
diff --git a/MdePkg/Library/BaseMemoryLibRepStr/Ia32/CompareMem.S 
b/MdePkg/Library/BaseMemoryLibRepStr/Ia32/CompareMem.S
deleted file mode 100644
index b509586adb..00
--- a/MdePkg/Library

[edk2] [PATCH 00/10] Remove .S files for IA32 and X64 arch in MdePkg and UefiCpuPkg

2019-03-06 Thread Shenglei Zhang

.nasm file has been added for X86 arch. .S assembly code
is not required any more.
https://bugzilla.tianocore.org/show_bug.cgi?id=1594

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Shenglei Zhang (10):
  UefiCpuPkg/SmmCpuFeaturesLib: Remove .S files for IA32 and X64 arch
  UefiCpuPkg/BaseUefiCpuLib: Remove .S files for IA32 and X64 arch
  UefiCpuPkg/CpuExceptionHandlerLib:Remove.S files for IA32 and X64 arch
  MdePkg/BaseCpuLib: Remove .S files for IA32 and X64 arch
  MdePkg/BaseLib: Remove .S files for IA32 and X64 arch
  MdePkg/BaseMemoryLibMmx: Remove .S files for IA32 and X64 arch
  MdePkg/BaseMemoryLibOptDxe: Remove .S files for IA32 and X64 arch
  MdePkg/BaseMemoryLibOptPei: Remove .S files for IA32 and X64 arch
  MdePkg/BaseMemoryLibRepStr: Remove .S files for IA32 and X64 arch
  MdePkg/BaseMemoryLibSse2: Remove .S files for IA32 and X64 arch

 MdePkg/Library/BaseCpuLib/BaseCpuLib.inf  |   2 -
 MdePkg/Library/BaseCpuLib/X64/CpuFlushTlb.S   |  35 -
 MdePkg/Library/BaseCpuLib/X64/CpuSleep.S  |  34 -
 MdePkg/Library/BaseLib/BaseLib.inf|  38 -
 MdePkg/Library/BaseLib/Ia32/ARShiftU64.S  |  43 --
 MdePkg/Library/BaseLib/Ia32/CpuId.S   |  63 --
 MdePkg/Library/BaseLib/Ia32/CpuIdEx.S |  67 --
 MdePkg/Library/BaseLib/Ia32/DisableCache.S|  39 -
 MdePkg/Library/BaseLib/Ia32/DisablePaging32.S |  52 --
 MdePkg/Library/BaseLib/Ia32/DivU64x32.S   |  41 --
 .../Library/BaseLib/Ia32/DivU64x32Remainder.S |  46 --
 .../Library/BaseLib/Ia32/DivU64x64Remainder.S |  89 ---
 MdePkg/Library/BaseLib/Ia32/EnableCache.S |  39 -
 .../BaseLib/Ia32/EnableDisableInterrupts.S|  36 -
 MdePkg/Library/BaseLib/Ia32/EnablePaging32.S  |  52 --
 MdePkg/Library/BaseLib/Ia32/EnablePaging64.S  |  63 --
 .../BaseLib/Ia32/InternalSwitchStack.S|  48 --
 MdePkg/Library/BaseLib/Ia32/LRotU64.S |  48 --
 MdePkg/Library/BaseLib/Ia32/LShiftU64.S   |  43 --
 MdePkg/Library/BaseLib/Ia32/LongJump.S|  41 --
 MdePkg/Library/BaseLib/Ia32/ModU64x32.S   |  40 --
 MdePkg/Library/BaseLib/Ia32/Monitor.S |  40 --
 MdePkg/Library/BaseLib/Ia32/MultU64x32.S  |  41 --
 MdePkg/Library/BaseLib/Ia32/MultU64x64.S  |  44 --
 MdePkg/Library/BaseLib/Ia32/Mwait.S   |  38 -
 MdePkg/Library/BaseLib/Ia32/RRotU64.S |  48 --
 MdePkg/Library/BaseLib/Ia32/RShiftU64.S   |  46 --
 MdePkg/Library/BaseLib/Ia32/RdRand.S  |  80 ---
 MdePkg/Library/BaseLib/Ia32/SetJump.S |  44 --
 MdePkg/Library/BaseLib/Ia32/SwapBytes64.S |  38 -
 MdePkg/Library/BaseLib/Ia32/Thunk16.S | 222 --
 MdePkg/Library/BaseLib/X64/CpuId.S|  60 --
 MdePkg/Library/BaseLib/X64/CpuIdEx.S  |  62 --
 MdePkg/Library/BaseLib/X64/DisableCache.S |  39 -
 MdePkg/Library/BaseLib/X64/DisablePaging64.S  |  82 ---
 MdePkg/Library/BaseLib/X64/EnableCache.S  |  39 -
 .../BaseLib/X64/EnableDisableInterrupts.S |  36 -
 MdePkg/Library/BaseLib/X64/LongJump.S |  54 --
 MdePkg/Library/BaseLib/X64/RdRand.S   |  72 --
 MdePkg/Library/BaseLib/X64/SetJump.S  |  53 --
 MdePkg/Library/BaseLib/X64/SwitchStack.S  |  52 --
 MdePkg/Library/BaseLib/X64/Thunk16.S  | 334 -
 .../BaseMemoryLibMmx/BaseMemoryLibMmx.inf |  22 -
 .../BaseMemoryLibMmx/Ia32/CompareMem.S|  55 --
 .../Library/BaseMemoryLibMmx/Ia32/CopyMem.S   |  86 ---
 .../Library/BaseMemoryLibMmx/Ia32/ScanMem16.S |  52 --
 .../Library/BaseMemoryLibMmx/Ia32/ScanMem32.S |  52 --
 .../Library/BaseMemoryLibMmx/Ia32/ScanMem64.S |  61 --
 .../Library/BaseMemoryLibMmx/Ia32/ScanMem8.S  |  52 --
 MdePkg/Library/BaseMemoryLibMmx/Ia32/SetMem.S |  66 --
 .../Library/BaseMemoryLibMmx/Ia32/SetMem16.S  |  59 --
 .../Library/BaseMemoryLibMmx/Ia32/SetMem32.S  |  52 --
 .../Library/BaseMemoryLibMmx/Ia32/SetMem64.S  |  43 --
 .../Library/BaseMemoryLibMmx/Ia32/ZeroMem.S   |  54 --
 .../Library/BaseMemoryLibMmx/X64/CompareMem.S |  59 --
 MdePkg/Library/BaseMemoryLibMmx/X64/CopyMem.S |  74 --
 .../Library/BaseMemoryLibMmx/X64/ScanMem16.S  |  56 --
 .../Library/BaseMemoryLibMmx/X64/ScanMem32.S  |  56 --
 .../Library/BaseMemoryLibMmx/X64/ScanMem64.S  |  55 --
 .../Library/BaseMemoryLibMmx/X64/ScanMem8.S   |  56 --
 MdePkg/Library/BaseMemoryLibMmx/X64/SetMem.S  |  61 --
 .../Library/BaseMemoryLibMmx/X64/SetMem16.S   |  60 --
 .../Library/BaseMemoryLibMmx/X64/SetMem32.S   |  55 --
 .../Library/BaseMemoryLibMmx/X64/SetMem64.S   |  47 --
 MdePkg/Library/BaseMemoryLibMmx/X64/ZeroMem.S |  57 --
 .../BaseMemoryLibOptDxe.inf   |  22 -
 .../BaseMemoryLibOptDxe/Ia32/CompareMem.S |  55 --
 .../BaseMemoryLibOptDxe/Ia32/CopyMem.S|  85 ---
 .../BaseMemoryLibOptDxe/Ia32/ScanMem16.S  |  52 --
 .../BaseMemoryLibOptDxe/Ia32/ScanMem32.S  |  52 --
 .../BaseMemoryLibOptDxe/Ia32/ScanMem64.S  |  61 --
 .../BaseMemoryLibOptDxe/Ia32/ScanMem8.S   |  52 --
 .../Library/BaseMemoryLibOptDxe/Ia32/SetMem.S |  50 --
 .../Bas

[edk2] [PATCH 01/10] UefiCpuPkg/SmmCpuFeaturesLib: Remove .S files for IA32 and X64 arch

2019-03-06 Thread Shenglei Zhang

.nasm file has been added for X86 arch. .S assembly code
is not required any more.
https://bugzilla.tianocore.org/show_bug.cgi?id=1594

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 .../Library/SmmCpuFeaturesLib/Ia32/SmiEntry.S | 278 -
 .../SmmCpuFeaturesLib/Ia32/SmiException.S | 174 ---
 .../SmmCpuFeaturesLibStm.inf  |   6 -
 .../Library/SmmCpuFeaturesLib/X64/SmiEntry.S  | 282 --
 .../SmmCpuFeaturesLib/X64/SmiException.S  | 178 ---
 5 files changed, 918 deletions(-)
 delete mode 100644 UefiCpuPkg/Library/SmmCpuFeaturesLib/Ia32/SmiEntry.S
 delete mode 100644 UefiCpuPkg/Library/SmmCpuFeaturesLib/Ia32/SmiException.S
 delete mode 100644 UefiCpuPkg/Library/SmmCpuFeaturesLib/X64/SmiEntry.S
 delete mode 100644 UefiCpuPkg/Library/SmmCpuFeaturesLib/X64/SmiException.S

diff --git a/UefiCpuPkg/Library/SmmCpuFeaturesLib/Ia32/SmiEntry.S 
b/UefiCpuPkg/Library/SmmCpuFeaturesLib/Ia32/SmiEntry.S
deleted file mode 100644
index 4c0f8c8933..00
--- a/UefiCpuPkg/Library/SmmCpuFeaturesLib/Ia32/SmiEntry.S
+++ /dev/null
@@ -1,278 +0,0 @@
-#--
-#
-# Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.
-# This program and the accompanying materials
-# are licensed and made available under the terms and conditions of the BSD 
License
-# which accompanies this distribution.  The full text of the license may be 
found at
-# http://opensource.org/licenses/bsd-license.php.
-#
-# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-#
-# Module Name:
-#
-#   SmiEntry.S
-#
-# Abstract:
-#
-#   Code template of the SMI handler for a particular processor
-#
-#--
-
-ASM_GLOBAL  ASM_PFX(gcStmSmiHandlerTemplate)
-ASM_GLOBAL  ASM_PFX(gcStmSmiHandlerSize)
-ASM_GLOBAL  ASM_PFX(gcStmSmiHandlerOffset)
-ASM_GLOBAL  ASM_PFX(gStmSmiCr3)
-ASM_GLOBAL  ASM_PFX(gStmSmiStack)
-ASM_GLOBAL  ASM_PFX(gStmSmbase)
-ASM_GLOBAL  ASM_PFX(gStmXdSupported)
-ASM_GLOBAL  ASM_PFX(FeaturePcdGet (PcdCpuSmmStackGuard))
-ASM_GLOBAL  ASM_PFX(gStmSmiHandlerIdtr)
-
-.equMSR_IA32_MISC_ENABLE, 0x1A0
-.equMSR_EFER, 0xc080
-.equMSR_EFER_XD, 0x800
-
-#
-# Constants relating to TXT_PROCESSOR_SMM_DESCRIPTOR
-#
-.equDSC_OFFSET, 0xfb00
-.equDSC_GDTPTR, 0x48
-.equDSC_GDTSIZ, 0x50
-.equDSC_CS, 0x14
-.equDSC_DS, 0x16
-.equDSC_SS, 0x18
-.equDSC_OTHERSEG, 0x1A
-
-.equPROTECT_MODE_CS, 0x08
-.equPROTECT_MODE_DS, 0x20
-.equTSS_SEGMENT, 0x40
-
-.text
-ASM_PFX(gcStmSmiHandlerTemplate):
-
-_StmSmiEntryPoint:
-.byte 0xbb  # mov bx, imm16
-.word _StmGdtDesc - _StmSmiEntryPoint + 0x8000
-.byte 0x2e,0xa1 # mov ax, cs:[offset16]
-.word DSC_OFFSET + DSC_GDTSIZ
-decl%eax
-movl%eax, %cs:(%edi)# mov cs:[bx], ax
-.byte 0x66,0x2e,0xa1# mov eax, cs:[offset16]
-.word   DSC_OFFSET + DSC_GDTPTR
-movw%ax, %cs:2(%edi)
-movw%ax, %bp# ebp = GDT base
-.byte 0x66
-lgdt%cs:(%edi)
-# Patch ProtectedMode Segment
-.byte   0xb8# mov ax, imm16
-.word   PROTECT_MODE_CS # set AX for segment directly
-movl%eax, %cs:-2(%edi)  # mov cs:[bx - 2], ax
-# Patch ProtectedMode entry
-.byte 0x66, 0xbf# mov edi, SMBASE
-ASM_PFX(gStmSmbase): .space 4
-.byte 0x67
-lea ((Start32bit - _StmSmiEntryPoint) + 0x8000)(%edi), %ax
-movw %ax, %cs:-6(%edi)
-movl%cr0, %ebx
-.byte 0x66
-andl$0x9ffafff3, %ebx
-.byte 0x66
-orl $0x23, %ebx
-movl%ebx, %cr0
-.byte 0x66,0xea
-.space  4
-.space  2
-_StmGdtDesc:   .space 4
-.space 2
-
-Start32bit:
-movw$PROTECT_MODE_DS, %ax
-movl%eax,%ds
-movl%eax,%es
-movl%eax,%fs
-movl%eax,%gs
-movl%eax,%ss
-.byte   0xbc  # mov esp, imm32
-ASM_PFX(gStmSmiStack): .space 4
-movl$ASM_PFX(gStmSmiHandlerIdtr), %eax
-lidt(%eax)
-jmp ProtFlatMode
-
-ProtFlatMode:
-.byte   0xb8   # mov eax, imm32
-ASM_PFX(gStmSmiCr3): .space 4
-movl%eax, %cr3
-#
-# Need to test for CR4 specific bit support
-#
-movl$1, %eax
-cpuid  # use CPUID to determine if 
specific CR4 bits are supported
-xorl%eax, %eax # Clear EAX
-testl   $BIT2, %edx# Check for DE capabilities
-jz  L8
-orl $BIT3, %eax
-

[edk2] [PATCH 04/10] MdePkg/BaseCpuLib: Remove .S files for IA32 and X64 arch

2019-03-06 Thread Shenglei Zhang

.nasm file has been added for X86 arch. .S assembly code
is not required any more.
https://bugzilla.tianocore.org/show_bug.cgi?id=1594

Cc: Michael D Kinney 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 MdePkg/Library/BaseCpuLib/BaseCpuLib.inf|  2 --
 MdePkg/Library/BaseCpuLib/X64/CpuFlushTlb.S | 35 -
 MdePkg/Library/BaseCpuLib/X64/CpuSleep.S| 34 
 3 files changed, 71 deletions(-)
 delete mode 100644 MdePkg/Library/BaseCpuLib/X64/CpuFlushTlb.S
 delete mode 100644 MdePkg/Library/BaseCpuLib/X64/CpuSleep.S

diff --git a/MdePkg/Library/BaseCpuLib/BaseCpuLib.inf 
b/MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
index af2f09617a..1b5ca0bedd 100644
--- a/MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
+++ b/MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
@@ -47,9 +47,7 @@
   X64/CpuSleep.nasm
 
   X64/CpuSleep.nasm| GCC
-  X64/CpuSleep.S | GCC
   X64/CpuFlushTlb.nasm| GCC
-  X64/CpuFlushTlb.S | GCC
 
 [Sources.EBC]
   Ebc/CpuSleepFlushTlb.c
diff --git a/MdePkg/Library/BaseCpuLib/X64/CpuFlushTlb.S 
b/MdePkg/Library/BaseCpuLib/X64/CpuFlushTlb.S
deleted file mode 100644
index 05d916a589..00
--- a/MdePkg/Library/BaseCpuLib/X64/CpuFlushTlb.S
+++ /dev/null
@@ -1,35 +0,0 @@
-#--
-# Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
-# This program and the accompanying materials
-# are licensed and made available under the terms and conditions of the BSD 
License
-# which accompanies this distribution.  The full text of the license may be 
found at
-# http://opensource.org/licenses/bsd-license.php.
-#
-# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-#
-# Module Name:
-#
-#   CpuFlushTlb.Asm
-#
-# Abstract:
-#
-#   CpuFlushTlb function
-#
-# Notes:
-#
-#--
-
-ASM_GLOBAL ASM_PFX(CpuFlushTlb)
-
-#--
-# VOID
-# EFIAPI
-# CpuFlushTlb (
-#   VOID
-#   );
-#--
-ASM_PFX(CpuFlushTlb):
-mov %cr3, %rax
-mov %rax, %cr3
-ret
diff --git a/MdePkg/Library/BaseCpuLib/X64/CpuSleep.S 
b/MdePkg/Library/BaseCpuLib/X64/CpuSleep.S
deleted file mode 100644
index cf763689d7..00
--- a/MdePkg/Library/BaseCpuLib/X64/CpuSleep.S
+++ /dev/null
@@ -1,34 +0,0 @@
-#--
 ;
-# Copyright (c) 2006 - 2008, Intel Corporation. All rights reserved.
-# This program and the accompanying materials
-# are licensed and made available under the terms and conditions of the BSD 
License
-# which accompanies this distribution.  The full text of the license may be 
found at
-# http://opensource.org/licenses/bsd-license.php.
-#
-# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-#
-# Module Name:
-#
-#   CpuSleep.S
-#
-# Abstract:
-#
-#   CpuSleep function
-#
-# Notes:
-#
-#--
-
-
-#--
-# VOID
-# EFIAPI
-# CpuSleep (
-#   VOID
-#   );
-#--
-ASM_GLOBAL ASM_PFX(CpuSleep)
-ASM_PFX(CpuSleep):
-hlt
-ret
-- 
2.18.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 08/10] MdePkg/BaseMemoryLibOptPei: Remove .S files for IA32 and X64 arch

2019-03-06 Thread Shenglei Zhang

.nasm file has been added for X86 arch. .S assembly code
is not required any more.
https://bugzilla.tianocore.org/show_bug.cgi?id=1594

Cc: Michael D Kinney 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 .../BaseMemoryLibOptPei.inf   | 22 ---
 .../BaseMemoryLibOptPei/Ia32/CompareMem.S | 55 
 .../BaseMemoryLibOptPei/Ia32/CopyMem.S| 62 -
 .../BaseMemoryLibOptPei/Ia32/ScanMem16.S  | 52 ---
 .../BaseMemoryLibOptPei/Ia32/ScanMem32.S  | 52 ---
 .../BaseMemoryLibOptPei/Ia32/ScanMem64.S  | 61 -
 .../BaseMemoryLibOptPei/Ia32/ScanMem8.S   | 52 ---
 .../Library/BaseMemoryLibOptPei/Ia32/SetMem.S | 50 --
 .../BaseMemoryLibOptPei/Ia32/SetMem16.S   | 43 
 .../BaseMemoryLibOptPei/Ia32/SetMem32.S   | 43 
 .../BaseMemoryLibOptPei/Ia32/SetMem64.S   | 46 -
 .../BaseMemoryLibOptPei/Ia32/ZeroMem.S| 49 --
 .../BaseMemoryLibOptPei/X64/CompareMem.S  | 59 -
 .../Library/BaseMemoryLibOptPei/X64/CopyMem.S | 66 ---
 .../BaseMemoryLibOptPei/X64/ScanMem16.S   | 56 
 .../BaseMemoryLibOptPei/X64/ScanMem32.S   | 56 
 .../BaseMemoryLibOptPei/X64/ScanMem64.S   | 56 
 .../BaseMemoryLibOptPei/X64/ScanMem8.S| 56 
 .../Library/BaseMemoryLibOptPei/X64/SetMem.S  | 47 -
 .../BaseMemoryLibOptPei/X64/SetMem16.S| 47 -
 .../BaseMemoryLibOptPei/X64/SetMem32.S| 47 -
 .../BaseMemoryLibOptPei/X64/SetMem64.S| 46 -
 .../Library/BaseMemoryLibOptPei/X64/ZeroMem.S | 50 --
 23 files changed, 1173 deletions(-)
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptPei/Ia32/CompareMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptPei/Ia32/CopyMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptPei/Ia32/ScanMem16.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptPei/Ia32/ScanMem32.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptPei/Ia32/ScanMem64.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptPei/Ia32/ScanMem8.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptPei/Ia32/SetMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptPei/Ia32/SetMem16.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptPei/Ia32/SetMem32.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptPei/Ia32/SetMem64.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptPei/Ia32/ZeroMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptPei/X64/CompareMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptPei/X64/CopyMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptPei/X64/ScanMem16.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptPei/X64/ScanMem32.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptPei/X64/ScanMem64.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptPei/X64/ScanMem8.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptPei/X64/SetMem.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptPei/X64/SetMem16.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptPei/X64/SetMem32.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptPei/X64/SetMem64.S
 delete mode 100644 MdePkg/Library/BaseMemoryLibOptPei/X64/ZeroMem.S

diff --git a/MdePkg/Library/BaseMemoryLibOptPei/BaseMemoryLibOptPei.inf 
b/MdePkg/Library/BaseMemoryLibOptPei/BaseMemoryLibOptPei.inf
index 8f274d83b0..6fcb5fdac2 100644
--- a/MdePkg/Library/BaseMemoryLibOptPei/BaseMemoryLibOptPei.inf
+++ b/MdePkg/Library/BaseMemoryLibOptPei/BaseMemoryLibOptPei.inf
@@ -35,27 +35,16 @@
 
 [Sources.Ia32]
   Ia32/ScanMem64.nasm
-  Ia32/ScanMem64.S
   Ia32/ScanMem32.nasm
-  Ia32/ScanMem32.S
   Ia32/ScanMem16.nasm
-  Ia32/ScanMem16.S
   Ia32/ScanMem8.nasm
-  Ia32/ScanMem8.S
   Ia32/CompareMem.nasm
-  Ia32/CompareMem.S
   Ia32/ZeroMem.nasm
-  Ia32/ZeroMem.S
   Ia32/SetMem64.nasm
-  Ia32/SetMem64.S
   Ia32/SetMem32.nasm
-  Ia32/SetMem32.S
   Ia32/SetMem16.nasm
-  Ia32/SetMem16.S
   Ia32/SetMem.nasm
-  Ia32/SetMem.S
   Ia32/CopyMem.nasm
-  Ia32/CopyMem.S
   Ia32/ScanMem64.nasm
   Ia32/ScanMem32.nasm
   Ia32/ScanMem16.nasm
@@ -84,27 +73,16 @@
 
 [Sources.X64]
   X64/ScanMem64.nasm
-  X64/ScanMem64.S
   X64/ScanMem32.nasm
-  X64/ScanMem32.S
   X64/ScanMem16.nasm
-  X64/ScanMem16.S
   X64/ScanMem8.nasm
-  X64/ScanMem8.S
   X64/CompareMem.nasm
-  X64/CompareMem.S
   X64/ZeroMem.nasm
-  X64/ZeroMem.S
   X64/SetMem64.nasm
-  X64/SetMem64.S
   X64/SetMem32.nasm
-  X64/SetMem32.S
   X64/SetMem16.nasm
-  X64/SetMem16.S
   X64/SetMem.nasm
-  X64/SetMem.S
   X64/CopyMem.nasm
-  X64/CopyMem.S
   X64/IsZeroBuffer.nasm
   ScanMem64Wrapper.c
   ScanMem32Wrapper.c
diff --git a/MdePkg/Library/BaseMemoryLibOptPei/Ia32/CompareMem.S 
b/MdePkg/Library/BaseMemoryLibOptPei/Ia32/CompareMem.S
deleted file mode 100644
index 23758781c9..00
--- a/MdePkg/Libra

[edk2] [PATCH 03/10] UefiCpuPkg/CpuExceptionHandlerLib:Remove.S files for IA32 and X64 arch

2019-03-06 Thread Shenglei Zhang

.nasm file has been added for X86 arch. .S assembly code
is not required any more.
https://bugzilla.tianocore.org/show_bug.cgi?id=1594

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 .../DxeCpuExceptionHandlerLib.inf |   2 -
 .../Ia32/ExceptionHandlerAsm.S| 667 --
 .../PeiCpuExceptionHandlerLib.inf |   2 -
 .../SecPeiCpuExceptionHandlerLib.inf  |   2 -
 .../SmmCpuExceptionHandlerLib.inf |   2 -
 .../X64/ExceptionHandlerAsm.S | 434 
 6 files changed, 1109 deletions(-)
 delete mode 100644 
UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionHandlerAsm.S
 delete mode 100644 
UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.S

diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
index a480890165..391e49f077 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
@@ -30,13 +30,11 @@
 [Sources.Ia32]
   Ia32/ExceptionHandlerAsm.nasm
   Ia32/ExceptionTssEntryAsm.nasm
-  Ia32/ExceptionHandlerAsm.S
   Ia32/ArchExceptionHandler.c
   Ia32/ArchInterruptDefs.h
 
 [Sources.X64]
   X64/ExceptionHandlerAsm.nasm
-  X64/ExceptionHandlerAsm.S
   X64/ArchExceptionHandler.c
   X64/ArchInterruptDefs.h
 
diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionHandlerAsm.S 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionHandlerAsm.S
deleted file mode 100644
index c134257d9d..00
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionHandlerAsm.S
+++ /dev/null
@@ -1,667 +0,0 @@
-#--
-#*
-#*   Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
-#*   This program and the accompanying materials
-#*   are licensed and made available under the terms and conditions of the BSD 
License
-#*   which accompanies this distribution.  The full text of the license may be 
found at
-#*   http://opensource.org/licenses/bsd-license.php
-#*
-#*   THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-#*   WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
-#*
-#*ExceptionHandlerAsm.S
-#*
-#*   Abstract:
-#*
-#* IA32 CPU Exception Handler
-#
-#--
-
-
-#.MMX
-#.XMM
-
-ASM_GLOBAL ASM_PFX(CommonExceptionHandler)
-ASM_GLOBAL ASM_PFX(CommonInterruptEntry)
-ASM_GLOBAL ASM_PFX(HookAfterStubHeaderEnd)
-
-#EXTRN ASM_PFX(mErrorCodeFlag):DWORD   # Error code flags for 
exceptions
-#EXTRN ASM_PFX(mDoFarReturnFlag):DWORD # Do far return flag
-
-.text
-
-#
-# exception handler stub table
-#
-Exception0Handle:
-.byte   0x6a#  push #VectorNum
-.byte   0
-pushl   %eax
-.byte   0xB8
-.long   ASM_PFX(CommonInterruptEntry)
-jmp *%eax
-Exception1Handle:
-.byte   0x6a#  push #VectorNum
-.byte   1
-pushl   %eax
-.byte   0xB8
-.long   ASM_PFX(CommonInterruptEntry)
-jmp *%eax
-Exception2Handle:
-.byte   0x6a#  push #VectorNum
-.byte   2
-pushl   %eax
-.byte   0xB8
-.long   ASM_PFX(CommonInterruptEntry)
-jmp *%eax
-Exception3Handle:
-.byte   0x6a#  push #VectorNum
-.byte   3
-pushl   %eax
-.byte   0xB8
-.long   ASM_PFX(CommonInterruptEntry)
-jmp *%eax
-Exception4Handle:
-.byte   0x6a#  push #VectorNum
-.byte   4
-pushl   %eax
-.byte   0xB8
-.long   ASM_PFX(CommonInterruptEntry)
-jmp *%eax
-Exception5Handle:
-.byte   0x6a#  push #VectorNum
-.byte   5
-pushl   %eax
-.byte   0xB8
-.long   ASM_PFX(CommonInterruptEntry)
-jmp *%eax
-Exception6Handle:
-.byte   0x6a#  push #VectorNum
-.byte   6
-pushl   %eax
-.byte   0xB8
-.long   ASM_PFX(CommonInterruptEntry)
-jmp *%eax
-Exception7Handle:
-.byte   0x6a#  push #VectorNum
-.byte   7
-pushl   %eax
-.byte   0xB8
-.long   ASM_PFX(CommonInterruptEntry)
-jmp *%eax
-Exception8Handle:
-.byte   0x6a#  push #VectorNum
-.byte   8
-pushl   %eax
- .byte   0xB8
-.long   ASM_PFX(CommonInterruptEntry)
-jmp *%eax
-Exception9Handle:
-.byte   0x6a#  push #VectorNum
-.byte   9
-pushl   %eax
-.byte   0xB8
-.long   ASM_PFX(CommonInterruptEntry)
-jmp *%eax
-Exception10Handle:
-.byte   0x6a#  push #VectorNum
-.byte   10
-pushl   %eax
-.byte   0xB8
-.long   ASM_PFX(CommonInterruptEntry)
-jmp *%eax
-Exception11Handle:
-.byte   0x6a#  push #VectorNum
-.byte   11
-pushl   %eax
-.byte   0xB8
-.long   A

[edk2] [PATCH 02/10] UefiCpuPkg/BaseUefiCpuLib: Remove .S files for IA32 and X64 arch

2019-03-06 Thread Shenglei Zhang

.nasm file has been added for X86 arch. .S assembly code
is not required any more.
https://bugzilla.tianocore.org/show_bug.cgi?id=1594

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 .../Library/BaseUefiCpuLib/BaseUefiCpuLib.inf |  2 -
 .../BaseUefiCpuLib/Ia32/InitializeFpu.S   | 73 ---
 .../BaseUefiCpuLib/X64/InitializeFpu.S| 57 ---
 3 files changed, 132 deletions(-)
 delete mode 100644 UefiCpuPkg/Library/BaseUefiCpuLib/Ia32/InitializeFpu.S
 delete mode 100644 UefiCpuPkg/Library/BaseUefiCpuLib/X64/InitializeFpu.S

diff --git a/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf 
b/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf
index 5614452a88..2e9756e50e 100644
--- a/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf
+++ b/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf
@@ -31,11 +31,9 @@
 
 [Sources.IA32]
   Ia32/InitializeFpu.nasm
-  Ia32/InitializeFpu.S
 
 [Sources.X64]
   X64/InitializeFpu.nasm
-  X64/InitializeFpu.S
 
 [Packages]
   MdePkg/MdePkg.dec
diff --git a/UefiCpuPkg/Library/BaseUefiCpuLib/Ia32/InitializeFpu.S 
b/UefiCpuPkg/Library/BaseUefiCpuLib/Ia32/InitializeFpu.S
deleted file mode 100644
index 0a1a9198f6..00
--- a/UefiCpuPkg/Library/BaseUefiCpuLib/Ia32/InitializeFpu.S
+++ /dev/null
@@ -1,73 +0,0 @@
-#--
-#*
-#*   Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
-#*   This program and the accompanying materials
-#*   are licensed and made available under the terms and conditions of the BSD 
License
-#*   which accompanies this distribution.  The full text of the license may be 
found at
-#*   http://opensource.org/licenses/bsd-license.php
-#*
-#*   THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-#*   WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
-#*
-#*
-#--
-
-#
-# Float control word initial value:
-# all exceptions masked, double-precision, round-to-nearest
-#
-ASM_PFX(mFpuControlWord): .word 0x027F
-#
-# Multimedia-extensions control word:
-# all exceptions masked, round-to-nearest, flush to zero for masked underflow
-#
-ASM_PFX(mMmxControlWord): .long 0x01F80
-
-#
-# Initializes floating point units for requirement of UEFI specification.
-#
-# This function initializes floating-point control word to 0x027F (all 
exceptions
-# masked,double-precision, round-to-nearest) and multimedia-extensions control 
word
-# (if supported) to 0x1F80 (all exceptions masked, round-to-nearest, flush to 
zero
-# for masked underflow).
-#
-ASM_GLOBAL ASM_PFX(InitializeFloatingPointUnits)
-ASM_PFX(InitializeFloatingPointUnits):
-
-pushl   %ebx
-
-#
-# Initialize floating point units
-#
-finit
-fldcw   ASM_PFX(mFpuControlWord)
-
-#
-# Use CpuId instructuion (CPUID.01H:EDX.SSE[bit 25] = 1) to test
-# whether the processor supports SSE instruction.
-#
-movl$1,  %eax
-cpuid
-btl $25, %edx
-jnc Done
-
-#
-# Set OSFXSR bit 9 in CR4
-#
-movl%cr4, %eax
-or  $0x200, %eax
-movl%eax, %cr4
-
-#
-# The processor should support SSE instruction and we can use
-# ldmxcsr instruction
-#
-ldmxcsr ASM_PFX(mMmxControlWord)
-
-Done:
-popl%ebx
-
-ret
-
-#END
-
diff --git a/UefiCpuPkg/Library/BaseUefiCpuLib/X64/InitializeFpu.S 
b/UefiCpuPkg/Library/BaseUefiCpuLib/X64/InitializeFpu.S
deleted file mode 100644
index f0b0d3e264..00
--- a/UefiCpuPkg/Library/BaseUefiCpuLib/X64/InitializeFpu.S
+++ /dev/null
@@ -1,57 +0,0 @@
-#--
-#*
-#*   Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
-#*   This program and the accompanying materials
-#*   are licensed and made available under the terms and conditions of the BSD 
License
-#*   which accompanies this distribution.  The full text of the license may be 
found at
-#*   http://opensource.org/licenses/bsd-license.php
-#*
-#*   THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-#*   WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
-#*
-#*
-#--
-
-#
-# Initializes floating point units for requirement of UEFI specification.
-#
-# This function initializes floating-point control word to 0x037F (all 
exceptions
-# masked,double-extended-precision, round-to-nearest) and 
multimedia-extensions control word
-# (if supported) to 0x1F80 (all exceptions masked, round-to-nearest, flush to 
zero
-# for masked underflow).
-#
-ASM_GLOBAL ASM_PFX(InitializeFloatingPointUnits)
-ASM_PFX(InitializeFloatingPointUnits):
-
-#
-# Initialize floating point units
-#

Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA Support

2019-03-06 Thread Wu, Hao A

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Cohen, Eugene
> Sent: Thursday, March 07, 2019 8:54 AM
> To: Ashish Singhal; Wu, Hao A; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b
> DMA Support
> 
> Tested-by: Eugene Cohen 

Eugene,

Thanks for the testing. Really appreciate your help.

Best Regards,
Hao Wu

> 
> Thanks again.
> 
> From: Ashish Singhal 
> Sent: Wednesday, March 6, 2019 4:07 PM
> To: Cohen, Eugene ; Wu, Hao A ;
> edk2-devel@lists.01.org
> Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA
> Support
> 
> Hi Eugene,
> 
> Thanks for confirming. Can you please validate the v2 patch I sent as well for
> completeness?
> 
> Thanks
> Ashish
> 
> From: Cohen, Eugene mailto:eug...@hp.com>>
> Sent: Wednesday, March 6, 2019 4:05 PM
> To: Wu, Hao A mailto:hao.a...@intel.com>>; Ashish
> Singhal mailto:ashishsin...@nvidia.com>>;
> edk2-devel@lists.01.org
> Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA
> Support
> 
> 
> Ø  I verified the patch on SDHC version 3.00 with 64-bit System Address
> Ø  Support. Hope more configurations are available for testing on Eugene's
> Ø  side.
> 
> This patch works for us.  Tested that the V3 64-bit DMA works and verified
> that addresses above 4GB DMA correctly.
> 
> Thanks for putting this together.
> 
> Feel free to add my Tested-By.
> 
> Eugene
> 
> From: Wu, Hao A mailto:hao.a...@intel.com>>
> Sent: Tuesday, March 5, 2019 8:01 PM
> To: Ashish Singhal
> mailto:ashishsin...@nvidia.com>>; edk2-
> de...@lists.01.org
> Cc: Cohen, Eugene mailto:eug...@hp.com>>
> Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA
> Support
> 
> Hi Ashish,
> 
> One thing to confirm, for the updated checks within
> SdMmcPciHcDriverBindingStart():
> 
> > if ((Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_300 &&
> > Private->Capability[Slot].SysBus64V3 == 0) ||
> > (Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_400 &&
> > Private->Capability[Slot].SysBus64V3 == 0) ||
> > (Private->ControllerVersion[Slot] >= SD_MMC_HC_CTRL_VER_410 &&
> > Private->Capability[Slot].SysBus64V4 == 0)) {
> > Support64BitDma = FALSE;
> > }
> 
> When the SDHC with version greater than 4.10, the check is only performed
> against the 'SysBus64V4' bit. My understanding of the purpose is that:
> 
> 1. For SDHC with version 4.00, the support of V3 mode and V4 mode of
> 64-bit System Address are reflect by bit 'SysBus64V3'. Thus, I can infer
> that the possible support case is both or neither.
> 
> 2. The spec states that SDHC with version greater than 4.10 divides the V3
> mode and V4 mode support into 2 bits (SysBus64V3, SysBus64V4) so that the
> V3 mode support can be optional.
> 
> So based on 1 & 2, we do not even bother to check the 'SysBus64V3' bit
> when HC version >= 4.10. Is that right?
> 
> 
> I verified the patch on SDHC version 3.00 with 64-bit System Address
> Support. Hope more configurations are available for testing on Eugene's
> side.
> 
> 
> Besides, some minor comments below:
> 
> > -Original Message-
> > From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> > Sent: Saturday, March 02, 2019 2:30 AM
> > To: edk2-devel@lists.01.org
> > Cc: Wu, Hao A; eug...@hp.com; Ashish Singhal
> > Subject: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA
> > Support
> 
> Please help to add the below Bugzilla tracker for reference:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1583 ore.org/show_bug.cgi?id=1583>
> 
> I have updated the above tracker to match the purpose of the proposed
> patch.
> 
> 
> >
> > Driver was supporting only 32b DMA support for V3 controllers. Add
> > support for 64b DMA as well for completeness.
> >
> > For V4.0 64b support, driver was looking at incorrect capability
> > register bit. Fix for that is present as well.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ashish Singhal
> mailto:ashishsin...@nvidia.com>>
> > ---
> > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 10 +-
> > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 6 +-
> > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 199
> > ++---
> > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 29 ++-
> > 4 files changed, 170 insertions(+), 74 deletions(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> > b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> > index b474f8d..9b7b88c 100644
> > --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> > +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> > @@ -6,7 +6,7 @@
> >
> > It would expose EFI_SD_MMC_PASS_THRU_PROTOCOL for upper layer
> use.
> >
> > - Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> > + Copyright (c) 2018-2019, NVIDIA CORPORATION. All r

Re: [edk2] [PATCH v2] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA Support

2019-03-06 Thread Wu, Hao A

Ashish,

Thanks for the contribution.
Reviewed-by: Hao Wu 

I will push this one after the release tag is created.

Best Regards,
Hao Wu


> -Original Message-
> From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> Sent: Wednesday, March 06, 2019 10:05 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A; eug...@hp.com; Ashish Singhal
> Subject: [PATCH v2] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA
> Support
> 
> Driver was supporting only 32b DMA support for V3 controllers. Add
> support for 64b DMA as well for completeness.
> 
> For V4.0 64b support, driver was looking at incorrect capability
> register bit. Fix for that is present as well.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1583
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ashish Singhal 
> ---
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c |  10 +-
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h |   6 +-
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c   | 189
> ++---
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h   |  29 +++-
>  4 files changed, 161 insertions(+), 73 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> index b474f8d..9b7b88c 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> @@ -6,7 +6,7 @@
> 
>It would expose EFI_SD_MMC_PASS_THRU_PROTOCOL for upper layer use.
> 
> -  Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> +  Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
>Copyright (c) 2015 - 2019, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
> @@ -666,8 +666,12 @@ SdMmcPciHcDriverBindingStart (
>  // If any of the slots does not support 64b system bus
>  // do not enable 64b DMA in the PCI layer.
>  //
> -if (Private->Capability[Slot].SysBus64V3 == 0 &&
> -Private->Capability[Slot].SysBus64V4 == 0) {
> +if ((Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_300 &&
> + Private->Capability[Slot].SysBus64V3 == 0) ||
> +(Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_400 &&
> + Private->Capability[Slot].SysBus64V3 == 0) ||
> +(Private->ControllerVersion[Slot] >= SD_MMC_HC_CTRL_VER_410 &&
> + Private->Capability[Slot].SysBus64V4 == 0)) {
>Support64BitDma = FALSE;
>  }
> 
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> index 1bb701a..8846fde 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> @@ -2,7 +2,7 @@
> 
>Provides some data structure definitions used by the SD/MMC host
> controller driver.
> 
> -Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> +Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
>  Copyright (c) 2015, Intel Corporation. All rights reserved.
>  This program and the accompanying materials
>  are licensed and made available under the terms and conditions of the BSD
> License
> @@ -145,13 +145,15 @@ typedef struct {
>EFI_PHYSICAL_ADDRESSDataPhy;
>VOID*DataMap;
>SD_MMC_HC_TRANSFER_MODE Mode;
> +  SD_MMC_HC_ADMA_LENGTH_MODE  AdmaLengthMode;
> 
>EFI_EVENT   Event;
>BOOLEAN Started;
>UINT64  Timeout;
> 
>SD_MMC_HC_ADMA_32_DESC_LINE *Adma32Desc;
> -  SD_MMC_HC_ADMA_64_DESC_LINE *Adma64Desc;
> +  SD_MMC_HC_ADMA_64_V3_DESC_LINE  *Adma64V3Desc;
> +  SD_MMC_HC_ADMA_64_V4_DESC_LINE  *Adma64V4Desc;
>EFI_PHYSICAL_ADDRESSAdmaDescPhy;
>VOID*AdmaMap;
>UINT32  AdmaPages;
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> index d73fa10..6fefed1 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> @@ -6,7 +6,7 @@
> 
>It would expose EFI_SD_MMC_PASS_THRU_PROTOCOL for upper layer use.
> 
> -  Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> +  Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
>Copyright (c) 2015 - 2019, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
> @@ -1010,16 +1010,28 @@ SdMmcHcInitV4Enhancements (
>if (ControllerVer >= SD_MMC_HC_CTRL_VER_400) {
>  HostCtrl2 = SD_MMC_HC_V4_EN;
>  //
> -// Check if V4 64bit support is available
> +

Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code

2019-03-06 Thread Andrew Fish via edk2-devel



> On Mar 6, 2019, at 4:41 PM, Kinney, Michael D  
> wrote:
> 
> Liming,
>  
> That does not work either because inline assembly uses compiler specific 
> syntax.
>  
> Please update with the specific list of functions that you think the inline 
> should be removed to improve maintenance with no impacts in size/perf.
>  

Mike,

It is easy to find the gcc/clang inline assembler, just `git grep "__asm__ 
__volatile__"`

The main files are:
https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c
https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/X64/GccInline.c
https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/Ia32/GccInline.c
https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c
https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c

This is really just compiler optimizer control. 
Library/BaseSynchronizationLib/SynchronizationGcc.c:21:#define 
_ReadWriteBarrier() do { __asm__ __volatile__ ("": : : "memory"); } while(0)

Looks like this is working around the alignment ASSERT in BaseIoLibIntrinsic. 
OvmfPkg/QemuVideoDxe/UnalignedIoGcc.c:43:  __asm__ __volatile__ ( "outl %0, %1" 
: : "a" (Value), "d" ((UINT16)Port) );
OvmfPkg/QemuVideoDxe/UnalignedIoGcc.c:67:  __asm__ __volatile__ ( "inl %1, %0" 
: "=a" (Data) : "d" ((UINT16)Port) );

It seems like we have a reasonable set and should not use the inline assembly 
for any more complex code. 

Thanks,

Andrew Fish

> The issue you pointed to was around SetJump()/LongJump().  Can we limit this 
> BZ to only those 2 functions?
>  
> Mike
>   <>
> From: Gao, Liming 
> Sent: Wednesday, March 6, 2019 4:28 PM
> To: af...@apple.com
> Cc: Zhang, Shenglei ; edk2-devel-01 
> ; Kinney, Michael D 
> Subject: RE: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline 
> X86 assembly code
>  
> Andrew:
>   I want to keep only one implementation. If inline assembly c source is 
> preferred, I suggest to remove its nasm implementation.
>  
> Thanks
> Liming
>  <>From: af...@apple.com  [mailto:af...@apple.com 
> ] 
> Sent: Tuesday, March 5, 2019 2:44 PM
> To: Gao, Liming mailto:liming@intel.com>>
> Cc: Zhang, Shenglei  >; edk2-devel-01  >; Kinney, Michael D 
> mailto:michael.d.kin...@intel.com>>
> Subject: Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline 
> X86 assembly code
>  
>  
>  
> 
> On Mar 5, 2019, at 1:32 PM, Gao, Liming  > wrote:
>  
> Andrew:
>  BZ 1163 is to remove inline X86 assembly code in C source file. But, this 
> patch is wrong. I have gave my comments to update this patch.
> 
>  
> Why do we want to remove inline X86 assembly. As I mentioned it will lead to 
> larger binaries, slower binaries, and less optimized code.
>  
> For example take this simple inline assembly function:
>  
> VOID
> EFIAPI
> CpuBreakpoint (
>   VOID
>   )
> {
>   __asm__ __volatile__ ("int $3");
> }
>  
> 
> Today with clang LTO turned on calling CpuBreakpoint() looks like this from 
> the callers point of view. 
>  
> a.out[0x1fa5] <+6>:  cc  int3   
>  
> 
> But if we move that to NASM:
>  
> 
> a.out[0x1fa6] <+7>:  e8 07 00 00 00  calll  0x1fb2; 
> CpuBreakpoint
>  
> 
> plus:
> a.out`CpuBreakpoint:
> a.out[0x1fb2] <+0>: cc int3   
> a.out[0x1fb3] <+1>: c3 retl   
>  
> 
> And there is also an extra push and pop on the stack. The other issue is the 
> call to the function that is unknown to the compiler will act like a 
> _ReadWriteBarrier (Yikes I see _ReadWriteBarrier is deprecated in VC++ 2017). 
> Is the depreciation of some of these intrinsics in VC++ driving the removal 
> of inline assembly? For GCC inline assembly works great for local compile, 
> and for clang LTO it works in entire program optimization.
>  
> The LTO bitcode includes inline assembly and constraints so that the 
> optimizer knows what to do so it can get optimized just like the abstract 
> bitcode during the Link Time Optimization. 
>  
> This is CpuBreakpoint():
> ; Function Attrs: noinline nounwind optnone ssp uwtable
> define void @CpuBreakpoint() #0 {
>   call void asm sideeffect "int $$3", "~{dirflag},~{fpsr},~{flags}"() #2, 
> !srcloc !3
>   ret void
> }
>  
> 
> This is AsmReadMsr64():
> ; Function Attrs: noinline nounwind optnone ssp uwtable
> define i64 @AsmReadMsr64(i32) #0 {
>   %2 = alloca i32, align 4
>   %3 = alloca i64, align 8
>   store i32 %0, i32* %2, align 4
>   %4 = load i32, i32* %2, align 4
>   %5 = call i64 asm sideeffect "rdmsr", 
> "=A,{cx},~{dirflag},~{fpsr},~{flags}"(i32 %4) #2, !srcloc !4
>   store i64 %5, i64* %3, align 8
>   %6 = load i64, i64* %3, align 8
>   ret i64 %6
> }
>  
> 
>  
> I agree it make sense to remove .S and .asm files and only have .nasm files. 
>  
> Thanks,
>  
> Andrew Fish
>  
> PS

[edk2] [edk2-test][Patch 1/1] uefi-sct/SctPkg:Fix flaw in BBTestCreateEventEx_Func_Sub3

2019-03-06 Thread Eric Jin

The intention of test is to validate the signal sequence among
three events with gEfiEventMemoryMapChangeGuid and different
Tpl. The call of AllocatePages() causes memorymap change and
trigger event Notify.
But the test has an assumption that CreateEventEx() will not
cause memorymap change itself, which is not true. When memory
pool is out of resource, the memory service will be called to
reserve more memory pool.
The fix is to filter the exception and only leave memorymap
change caused by AllocatePages() in test.

Cc: Supreeth Venkatesh 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Jin 
---
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/BlackBoxTest/EventTimerTaskPriorityServicesBBTestMain.h
  |  5 +++--
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/BlackBoxTest/EventTimerTaskPriorityServicesBBTestCreateEventEx.c
 | 26 +++---
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/BlackBoxTest/Support.c
   | 23 +--
 3 files changed, 39 insertions(+), 15 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/BlackBoxTest/EventTimerTaskPriorityServicesBBTestMain.h
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/BlackBoxTest/EventTimerTaskPriorityServicesBBTestMain.h
index 4431b5b22888..87451f9f9a91 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/BlackBoxTest/EventTimerTaskPriorityServicesBBTestMain.h
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/BlackBoxTest/EventTimerTaskPriorityServicesBBTestMain.h
@@ -1,7 +1,7 @@
 /** @file
 
   Copyright 2006 - 2016 Unified EFI, Inc.
-  Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -49,7 +49,8 @@ Abstract:
  Status \
  );
 
-#define MAX_TEST_EVENT_NUM 3
+#define MAX_TEST_EVENT_NUM3
+#define SIGNAL_CONTEXT0xAA//To check the buffer content is modifed 
by exception or not
 //
 // Prototypes: Test Cases
 //
diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/BlackBoxTest/EventTimerTaskPriorityServicesBBTestCreateEventEx.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/BlackBoxTest/EventTimerTaskPriorityServicesBBTestCreateEventEx.c
index e2e173ab04c0..4a8e44e29b4e 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/BlackBoxTest/EventTimerTaskPriorityServicesBBTestCreateEventEx.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/BlackBoxTest/EventTimerTaskPriorityServicesBBTestCreateEventEx.c
@@ -1,7 +1,7 @@
 /** @file
 
   Copyright 2006 - 2016 Unified EFI, Inc.
-  Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -192,6 +192,10 @@ BBTestCreateEventEx_Func (
   BBTestCreateEventEx_Func_Sub2 (StandardLib);
 #endif
 
+  //
+  // The test for the EFI_EVENT_GROUP_MEMORY_MAP_CHANGE
+  // This event group is notified by the system when the memory map has 
changed.
+  //
   BBTestCreateEventEx_Func_Sub3 (StandardLib);
 
   //
@@ -599,12 +603,12 @@ BBTestCreateEventEx_Func_Sub1 (
   UINTN   Buffer[MAX_TEST_EVENT_NUM + MAX_TEST_EVENT_NUM*2];
 
   //
-  // Initialize Buffer
+  // Initialize Buffer as SIGNAL_CONTEXT
   //
   for (Index = 0; Index < MAX_TEST_EVENT_NUM; Index ++) {
 Buffer[Index] = Index;
-Buffer[Index + MAX_TEST_EVENT_NUM + Index] = (UINTN)(-1);
-Buffer[Index + MAX_TEST_EVENT_NUM + 1 + Index] = (UINTN)(-1);
+Buffer[Index + MAX_TEST_EVENT_NUM + Index] = (UINTN)(SIGNAL_CONTEXT);
+Buffer[Index + MAX_TEST_EVENT_NUM + 1 + Index] = (UINTN)(SIGNAL_CONTEXT);
   }
 
   //
@@ -755,12 +759,12 @@ BBTestCreateEventEx_Func_Sub2 (
   UINTN   Buffer[MAX_TEST_EVENT_NUM + MAX_TEST_EVENT_NUM*2];
 
   //
-  // Initialize Buffer
+  // Initialize Buffer as SIGNAL_CONTEXT
   //
   for (Index = 0; Index < MAX_TEST_EVENT_NUM; Index ++) {
 Buffer[Index] = Index;
-Buffer[Index + MAX_TEST_EVENT_NUM + Index] = (UINTN)(-1);
-Buffer[Index + MAX_TEST_EVENT_NUM + 1 + Index] = (UINTN)(-1);
+Buffer[Index + MAX_TEST_EVENT_NUM + Index] = (UINTN)(SIGNAL_CONTEXT);
+Buffer[Index + MAX_TEST_EVENT_NUM + 1 + Index] = (UINTN)(SIGNAL_CONTEXT);
   }
 
   //
@@ -914,12 +918,12 @@ BBTestCreateEventEx_Func_Su

Re: [edk2] EDK II Specifications for edk2-stable201903 tag

2019-03-06 Thread Feng, Bob C

Hi Mike,

Yes. the Revision history need to update. I have sent the spec patches v2 which 
update the Revision History in README.md and table of content in SUMMARY.md for 
INF/FDF/DSC spec.
And I added the BZ in the README.md.

Thanks,
Bob

-Original Message-
From: Kinney, Michael D 
Sent: Thursday, March 7, 2019 12:59 AM
To: Gao, Liming ; Feng, Bob C ; 
edk2-devel@lists.01.org; Kinney, Michael D 
Subject: EDK II Specifications for edk2-stable201903 tag

Hi Liming and Bob,

I see several EDK II specification updates.

I do not see consistent updates to the Revision History In the README.md with 
link to the BZ for the document change.  Please make sure all revision 
histories are up to date with BZ links, and as each BZ is closed put the links 
to commits made in the BZ.  This allows anyone reading the documents to follow 
the link to the BZ from the Revision History, review the change request and 
follow the links to the commits in GitHub and the easily view the document 
changes.

Do you want released versions of these documents to align with the 
edk2-stable201903 tag?  The document release process is documented here:

https://github.com/tianocore-docs/edk2-TemplateSpecification/wiki/TianoCore-Documents-Releasing

If so, please enter BZ for each document with the requested release version 
number along with the SHA hash of on master the release branch is being 
requested.

Thanks,

Mike

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA Support

2019-03-06 Thread Cohen, Eugene

Tested-by: Eugene Cohen 

Thanks again.

From: Ashish Singhal 
Sent: Wednesday, March 6, 2019 4:07 PM
To: Cohen, Eugene ; Wu, Hao A ; 
edk2-devel@lists.01.org
Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA Support

Hi Eugene,

Thanks for confirming. Can you please validate the v2 patch I sent as well for 
completeness?

Thanks
Ashish

From: Cohen, Eugene mailto:eug...@hp.com>>
Sent: Wednesday, March 6, 2019 4:05 PM
To: Wu, Hao A mailto:hao.a...@intel.com>>; Ashish Singhal 
mailto:ashishsin...@nvidia.com>>; 
edk2-devel@lists.01.org
Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA Support


Ø  I verified the patch on SDHC version 3.00 with 64-bit System Address
Ø  Support. Hope more configurations are available for testing on Eugene's
Ø  side.

This patch works for us.  Tested that the V3 64-bit DMA works and verified that 
addresses above 4GB DMA correctly.

Thanks for putting this together.

Feel free to add my Tested-By.

Eugene

From: Wu, Hao A mailto:hao.a...@intel.com>>
Sent: Tuesday, March 5, 2019 8:01 PM
To: Ashish Singhal mailto:ashishsin...@nvidia.com>>; 
edk2-devel@lists.01.org
Cc: Cohen, Eugene mailto:eug...@hp.com>>
Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA Support

Hi Ashish,

One thing to confirm, for the updated checks within
SdMmcPciHcDriverBindingStart():

> if ((Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_300 &&
> Private->Capability[Slot].SysBus64V3 == 0) ||
> (Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_400 &&
> Private->Capability[Slot].SysBus64V3 == 0) ||
> (Private->ControllerVersion[Slot] >= SD_MMC_HC_CTRL_VER_410 &&
> Private->Capability[Slot].SysBus64V4 == 0)) {
> Support64BitDma = FALSE;
> }

When the SDHC with version greater than 4.10, the check is only performed
against the 'SysBus64V4' bit. My understanding of the purpose is that:

1. For SDHC with version 4.00, the support of V3 mode and V4 mode of
64-bit System Address are reflect by bit 'SysBus64V3'. Thus, I can infer
that the possible support case is both or neither.

2. The spec states that SDHC with version greater than 4.10 divides the V3
mode and V4 mode support into 2 bits (SysBus64V3, SysBus64V4) so that the
V3 mode support can be optional.

So based on 1 & 2, we do not even bother to check the 'SysBus64V3' bit
when HC version >= 4.10. Is that right?


I verified the patch on SDHC version 3.00 with 64-bit System Address
Support. Hope more configurations are available for testing on Eugene's
side.


Besides, some minor comments below:

> -Original Message-
> From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> Sent: Saturday, March 02, 2019 2:30 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A; eug...@hp.com; Ashish Singhal
> Subject: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA
> Support

Please help to add the below Bugzilla tracker for reference:
https://bugzilla.tianocore.org/show_bug.cgi?id=1583

I have updated the above tracker to match the purpose of the proposed
patch.


>
> Driver was supporting only 32b DMA support for V3 controllers. Add
> support for 64b DMA as well for completeness.
>
> For V4.0 64b support, driver was looking at incorrect capability
> register bit. Fix for that is present as well.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ashish Singhal 
> mailto:ashishsin...@nvidia.com>>
> ---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 10 +-
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 6 +-
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 199
> ++---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 29 ++-
> 4 files changed, 170 insertions(+), 74 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> index b474f8d..9b7b88c 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> @@ -6,7 +6,7 @@
>
> It would expose EFI_SD_MMC_PASS_THRU_PROTOCOL for upper layer use.
>
> - Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> + Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
> Copyright (c) 2015 - 2019, Intel Corporation. All rights reserved.
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> License
> @@ -666,8 +666,12 @@ SdMmcPciHcDriverBindingStart (
> // If any of the slots does not support 64b system bus
> // do not enable 64b DMA in the PCI layer.
> //
> - if (Private->Capability[Slot].SysBus64V3 == 0 &&
> - Private->Capability[Slot].SysBus64V4 == 0) {
> + if ((Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_300 &&
> + Private->Capability[Slot].SysBus64V3 == 0) ||
> + (Private->ControllerVersion[Slot] == SD_

Re: [edk2] [PATCH] ShellPkg/UefiShellAcpiViewCommandLib: Change the note in uni

2019-03-06 Thread Gao, Zhichao

Thanks for your careful check.
I would update it.

Thanks,
Zhichao

From: Carsey, Jaben
Sent: Thursday, March 7, 2019 12:47 AM
To: Nariman Poushin 
Cc: Gao, Zhichao ; edk2-devel@lists.01.org; Gao, Liming 

Subject: Re: [edk2] [PATCH] ShellPkg/UefiShellAcpiViewCommandLib: Change the 
note in uni

Good catch.  After fixing this typo, my RB stands.
Sent from my iPad

On Mar 6, 2019, at 7:59 AM, Nariman Poushin 
mailto:nariman.pous...@linaro.org>> wrote:


On Wed, 6 Mar 2019 at 15:54, Carsey, Jaben 
mailto:jaben.car...@intel.com>> wrote:
Reviewed-by: Jaben Carsey 
mailto:jaben.car...@intel.com>>

> -Original Message-
> From: Gao, Zhichao
> Sent: Tuesday, March 05, 2019 11:05 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ray mailto:ray...@intel.com>>; Carsey, Jaben 
> mailto:jaben.car...@intel.com>>;
> Gao, Liming mailto:liming@intel.com>>
> Subject: [PATCH] ShellPkg/UefiShellAcpiViewCommandLib: Change the note
> in uni
> Importance: High
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1146
>
> Add DSDT and SSDT description in the help information. Depend
> on the implement of UefiShellAcpiViewCommandLib, the "acpiview"
> command support to show all present type in the system not only
> support the listed type in the help information. So change the
> help information of this command.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao 
> mailto:zhichao@intel.com>>
> Cc: Ruiyu Ni mailto:ruiyu...@intel.com>>
> Cc: Jaben Carsey mailto:jaben.car...@intel.com>>
> Cc: Liming Gao mailto:liming@intel.com>>
> ---
>  .../UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.uni   | 8
> +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewComm
> andLib.uni
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewComm
> andLib.uni
> index 0762eeba53..f2a2400b91 100644
> ---
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewComm
> andLib.uni
> +++
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewComm
> andLib.uni
> @@ -74,10 +74,15 @@
>  "  1. The AcpiTable parameter can match any installed table type.\r\n"
>  " Tables without specific handling will be displayed as a raw hex dump
> (or\r\n"
>  " dumped to a file if -d is used).\r\n"
> -"  2. Formatted display and checking is provided for these signature
> types:\r\n"
> +"  2. -s option supports to display the specified AcpiTable type that is
> present\r\n"
> +" in the system. For normal type AcpiTable, it would display the data of
> the\r\n"
> +" AcpiTable and AcpiTable header. The following type may contain header
> type\r\n"
> +" other than AcpiTable header. The acual header can refer to the ACPI
> spec 6.2\r\n"
> +" Extra A. Particual types:\r\n"

Should this be "Particular"?

>  "   APIC  - Multiple APIC Description Table (MADT)\r\n"
>  "   BGRT  - Boot Graphics Resource Table\r\n"
>  "   DBG2  - Debug Port Table 2\r\n"
> +"   DSDT  - Differentiated System Description Table\r\n"
>  "   FACP  - Fixed ACPI Description Table (FADT)\r\n"
>  "   GTDT  - Generic Timer Description Table\r\n"
>  "   IORT  - IO Remapping Table\r\n"
> @@ -87,6 +92,7 @@
>  "   SLIT  - System Locality Information Table\r\n"
>  "   SPCR  - Serial Port Console Redirection Table\r\n"
>  "   SRAT  - System Resource Affinity Table\r\n"
> +"   SSDT  - Secondary SystemDescription Table\r\n"
>  "   XSDT  - Extended System Description Table\r\n"
>  " \r\n"
>  ".SH STANDARDS\r\n"
> --
> 2.16.2.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code

2019-03-06 Thread Kinney, Michael D

Liming,

That does not work either because inline assembly uses compiler specific syntax.

Please update with the specific list of functions that you think the inline 
should be removed to improve maintenance with no impacts in size/perf.

The issue you pointed to was around SetJump()/LongJump().  Can we limit this BZ 
to only those 2 functions?

Mike

From: Gao, Liming
Sent: Wednesday, March 6, 2019 4:28 PM
To: af...@apple.com
Cc: Zhang, Shenglei ; edk2-devel-01 
; Kinney, Michael D 
Subject: RE: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline 
X86 assembly code

Andrew:
  I want to keep only one implementation. If inline assembly c source is 
preferred, I suggest to remove its nasm implementation.

Thanks
Liming
From: af...@apple.com [mailto:af...@apple.com]
Sent: Tuesday, March 5, 2019 2:44 PM
To: Gao, Liming mailto:liming@intel.com>>
Cc: Zhang, Shenglei 
mailto:shenglei.zh...@intel.com>>; edk2-devel-01 
mailto:edk2-devel@lists.01.org>>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Subject: Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline 
X86 assembly code



On Mar 5, 2019, at 1:32 PM, Gao, Liming 
mailto:liming@intel.com>> wrote:

Andrew:
 BZ 1163 is to remove inline X86 assembly code in C source file. But, this 
patch is wrong. I have gave my comments to update this patch.

Why do we want to remove inline X86 assembly. As I mentioned it will lead to 
larger binaries, slower binaries, and less optimized code.

For example take this simple inline assembly function:

VOID
EFIAPI
CpuBreakpoint (
  VOID
  )
{
  __asm__ __volatile__ ("int $3");
}

Today with clang LTO turned on calling CpuBreakpoint() looks like this from the 
callers point of view.

a.out[0x1fa5] <+6>:  cc  int3

But if we move that to NASM:

a.out[0x1fa6] <+7>:  e8 07 00 00 00  calll  0x1fb2; 
CpuBreakpoint

plus:
a.out`CpuBreakpoint:
a.out[0x1fb2] <+0>: cc int3
a.out[0x1fb3] <+1>: c3 retl

And there is also an extra push and pop on the stack. The other issue is the 
call to the function that is unknown to the compiler will act like a 
_ReadWriteBarrier (Yikes I see _ReadWriteBarrier is deprecated in VC++ 2017). 
Is the depreciation of some of these intrinsics in VC++ driving the removal of 
inline assembly? For GCC inline assembly works great for local compile, and for 
clang LTO it works in entire program optimization.

The LTO bitcode includes inline assembly and constraints so that the optimizer 
knows what to do so it can get optimized just like the abstract bitcode during 
the Link Time Optimization.

This is CpuBreakpoint():
; Function Attrs: noinline nounwind optnone ssp uwtable
define void @CpuBreakpoint() #0 {
  call void asm sideeffect "int $$3", "~{dirflag},~{fpsr},~{flags}"() #2, 
!srcloc !3
  ret void
}

This is AsmReadMsr64():
; Function Attrs: noinline nounwind optnone ssp uwtable
define i64 @AsmReadMsr64(i32) #0 {
  %2 = alloca i32, align 4
  %3 = alloca i64, align 8
  store i32 %0, i32* %2, align 4
  %4 = load i32, i32* %2, align 4
  %5 = call i64 asm sideeffect "rdmsr", 
"=A,{cx},~{dirflag},~{fpsr},~{flags}"(i32 %4) #2, !srcloc !4
  store i64 %5, i64* %3, align 8
  %6 = load i64, i64* %3, align 8
  ret i64 %6
}


I agree it make sense to remove .S and .asm files and only have .nasm files.

Thanks,

Andrew Fish

PS For the Xcode clang since it emits frame pointers by default we need to add 
the extra 4 bytes to save the assembly functions so the stack can get unwound.

a.out`CpuBreakpoint:
a.out[0x1f99] <+0>: 55 pushl  %ebp
a.out[0x1f9a] <+1>: 89 e5  movl   %esp, %ebp
a.out[0x1f9c] <+3>: cc int3
a.out[0x1f9d] <+4>: 5d popl   %ebp
a.out[0x1f9e] <+5>: c3 retl

So breakpoint goes from 1 byte to 11 bytes if we get rid of the intrinsics.

 The change is to reduce the duplicated implementation. It will be good on the 
code maintain. Recently, one patch has to update .c and .nasm both. Please see 
https://lists.01.org/pipermail/edk2-devel/2019-February/037165.html. Beside 
this change, I propose to remove all GAS assembly code for IA32 and X64 arch. 
After those change, the patch owner will collect the impact of the image size.

Thanks
Liming

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code

2019-03-06 Thread Gao, Liming

Andrew:
  I want to keep only one implementation. If inline assembly c source is 
preferred, I suggest to remove its nasm implementation.

Thanks
Liming
From: af...@apple.com [mailto:af...@apple.com]
Sent: Tuesday, March 5, 2019 2:44 PM
To: Gao, Liming 
Cc: Zhang, Shenglei ; edk2-devel-01 
; Kinney, Michael D 
Subject: Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline 
X86 assembly code

On Mar 5, 2019, at 1:32 PM, Gao, Liming 
mailto:liming@intel.com>> wrote:

Andrew:
 BZ 1163 is to remove inline X86 assembly code in C source file. But, this 
patch is wrong. I have gave my comments to update this patch.

Why do we want to remove inline X86 assembly. As I mentioned it will lead to 
larger binaries, slower binaries, and less optimized code.

For example take this simple inline assembly function:

VOID
EFIAPI
CpuBreakpoint (
  VOID
  )
{
  __asm__ __volatile__ ("int $3");
}

Today with clang LTO turned on calling CpuBreakpoint() looks like this from the 
callers point of view.

a.out[0x1fa5] <+6>:  cc  int3

But if we move that to NASM:

a.out[0x1fa6] <+7>:  e8 07 00 00 00  calll  0x1fb2; 
CpuBreakpoint

plus:
a.out`CpuBreakpoint:
a.out[0x1fb2] <+0>: cc int3
a.out[0x1fb3] <+1>: c3 retl

And there is also an extra push and pop on the stack. The other issue is the 
call to the function that is unknown to the compiler will act like a 
_ReadWriteBarrier (Yikes I see _ReadWriteBarrier is deprecated in VC++ 2017). 
Is the depreciation of some of these intrinsics in VC++ driving the removal of 
inline assembly? For GCC inline assembly works great for local compile, and for 
clang LTO it works in entire program optimization.

The LTO bitcode includes inline assembly and constraints so that the optimizer 
knows what to do so it can get optimized just like the abstract bitcode during 
the Link Time Optimization.

This is CpuBreakpoint():
; Function Attrs: noinline nounwind optnone ssp uwtable
define void @CpuBreakpoint() #0 {
  call void asm sideeffect "int $$3", "~{dirflag},~{fpsr},~{flags}"() #2, 
!srcloc !3
  ret void
}

This is AsmReadMsr64():
; Function Attrs: noinline nounwind optnone ssp uwtable
define i64 @AsmReadMsr64(i32) #0 {
  %2 = alloca i32, align 4
  %3 = alloca i64, align 8
  store i32 %0, i32* %2, align 4
  %4 = load i32, i32* %2, align 4
  %5 = call i64 asm sideeffect "rdmsr", 
"=A,{cx},~{dirflag},~{fpsr},~{flags}"(i32 %4) #2, !srcloc !4
  store i64 %5, i64* %3, align 8
  %6 = load i64, i64* %3, align 8
  ret i64 %6
}

I agree it make sense to remove .S and .asm files and only have .nasm files.

Thanks,

Andrew Fish

PS For the Xcode clang since it emits frame pointers by default we need to add 
the extra 4 bytes to save the assembly functions so the stack can get unwound.

a.out`CpuBreakpoint:
a.out[0x1f99] <+0>: 55 pushl  %ebp
a.out[0x1f9a] <+1>: 89 e5  movl   %esp, %ebp
a.out[0x1f9c] <+3>: cc int3
a.out[0x1f9d] <+4>: 5d popl   %ebp
a.out[0x1f9e] <+5>: c3 retl

So breakpoint goes from 1 byte to 11 bytes if we get rid of the intrinsics.

 The change is to reduce the duplicated implementation. It will be good on the 
code maintain. Recently, one patch has to update .c and .nasm both. Please see 
https://lists.01.org/pipermail/edk2-devel/2019-February/037165.html. Beside 
this change, I propose to remove all GAS assembly code for IA32 and X64 arch. 
After those change, the patch owner will collect the impact of the image size.

Thanks
Liming

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA Support

2019-03-06 Thread Ashish Singhal

Hi Eugene,

Thanks for confirming. Can you please validate the v2 patch I sent as well for 
completeness?

Thanks
Ashish

From: Cohen, Eugene 
Sent: Wednesday, March 6, 2019 4:05 PM
To: Wu, Hao A ; Ashish Singhal ; 
edk2-devel@lists.01.org
Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA Support



  *   I verified the patch on SDHC version 3.00 with 64-bit System Address
  *   Support. Hope more configurations are available for testing on Eugene's
  *   side.

This patch works for us.  Tested that the V3 64-bit DMA works and verified that 
addresses above 4GB DMA correctly.

Thanks for putting this together.

Feel free to add my Tested-By.

Eugene

From: Wu, Hao A mailto:hao.a...@intel.com>>
Sent: Tuesday, March 5, 2019 8:01 PM
To: Ashish Singhal mailto:ashishsin...@nvidia.com>>; 
edk2-devel@lists.01.org
Cc: Cohen, Eugene mailto:eug...@hp.com>>
Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA Support

Hi Ashish,

One thing to confirm, for the updated checks within
SdMmcPciHcDriverBindingStart():

> if ((Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_300 &&
> Private->Capability[Slot].SysBus64V3 == 0) ||
> (Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_400 &&
> Private->Capability[Slot].SysBus64V3 == 0) ||
> (Private->ControllerVersion[Slot] >= SD_MMC_HC_CTRL_VER_410 &&
> Private->Capability[Slot].SysBus64V4 == 0)) {
> Support64BitDma = FALSE;
> }

When the SDHC with version greater than 4.10, the check is only performed
against the 'SysBus64V4' bit. My understanding of the purpose is that:

1. For SDHC with version 4.00, the support of V3 mode and V4 mode of
64-bit System Address are reflect by bit 'SysBus64V3'. Thus, I can infer
that the possible support case is both or neither.

2. The spec states that SDHC with version greater than 4.10 divides the V3
mode and V4 mode support into 2 bits (SysBus64V3, SysBus64V4) so that the
V3 mode support can be optional.

So based on 1 & 2, we do not even bother to check the 'SysBus64V3' bit
when HC version >= 4.10. Is that right?


I verified the patch on SDHC version 3.00 with 64-bit System Address
Support. Hope more configurations are available for testing on Eugene's
side.


Besides, some minor comments below:

> -Original Message-
> From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> Sent: Saturday, March 02, 2019 2:30 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A; eug...@hp.com; Ashish Singhal
> Subject: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA
> Support

Please help to add the below Bugzilla tracker for reference:
https://bugzilla.tianocore.org/show_bug.cgi?id=1583

I have updated the above tracker to match the purpose of the proposed
patch.


>
> Driver was supporting only 32b DMA support for V3 controllers. Add
> support for 64b DMA as well for completeness.
>
> For V4.0 64b support, driver was looking at incorrect capability
> register bit. Fix for that is present as well.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ashish Singhal 
> mailto:ashishsin...@nvidia.com>>
> ---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 10 +-
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 6 +-
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 199
> ++---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 29 ++-
> 4 files changed, 170 insertions(+), 74 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> index b474f8d..9b7b88c 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> @@ -6,7 +6,7 @@
>
> It would expose EFI_SD_MMC_PASS_THRU_PROTOCOL for upper layer use.
>
> - Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> + Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
> Copyright (c) 2015 - 2019, Intel Corporation. All rights reserved.
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> License
> @@ -666,8 +666,12 @@ SdMmcPciHcDriverBindingStart (
> // If any of the slots does not support 64b system bus
> // do not enable 64b DMA in the PCI layer.
> //
> - if (Private->Capability[Slot].SysBus64V3 == 0 &&
> - Private->Capability[Slot].SysBus64V4 == 0) {
> + if ((Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_300 &&
> + Private->Capability[Slot].SysBus64V3 == 0) ||
> + (Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_400 &&
> + Private->Capability[Slot].SysBus64V3 == 0) ||
> + (Private->ControllerVersion[Slot] >= SD_MMC_HC_CTRL_VER_410 &&
> + Private->Capability[Slot].SysBus64V4 == 0)) {
> Support64BitDma = FALSE;
> }
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> index 1bb701a..68d8a5c 100644
> --- a/MdeMo

Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA Support

2019-03-06 Thread Cohen, Eugene




Ø  I verified the patch on SDHC version 3.00 with 64-bit System Address

Ø  Support. Hope more configurations are available for testing on Eugene's

Ø  side.

This patch works for us.  Tested that the V3 64-bit DMA works and verified that 
addresses above 4GB DMA correctly.

Thanks for putting this together.

Feel free to add my Tested-By.

Eugene

From: Wu, Hao A 
Sent: Tuesday, March 5, 2019 8:01 PM
To: Ashish Singhal ; edk2-devel@lists.01.org
Cc: Cohen, Eugene 
Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA Support

Hi Ashish,

One thing to confirm, for the updated checks within
SdMmcPciHcDriverBindingStart():

> if ((Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_300 &&
> Private->Capability[Slot].SysBus64V3 == 0) ||
> (Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_400 &&
> Private->Capability[Slot].SysBus64V3 == 0) ||
> (Private->ControllerVersion[Slot] >= SD_MMC_HC_CTRL_VER_410 &&
> Private->Capability[Slot].SysBus64V4 == 0)) {
> Support64BitDma = FALSE;
> }

When the SDHC with version greater than 4.10, the check is only performed
against the 'SysBus64V4' bit. My understanding of the purpose is that:

1. For SDHC with version 4.00, the support of V3 mode and V4 mode of
64-bit System Address are reflect by bit 'SysBus64V3'. Thus, I can infer
that the possible support case is both or neither.

2. The spec states that SDHC with version greater than 4.10 divides the V3
mode and V4 mode support into 2 bits (SysBus64V3, SysBus64V4) so that the
V3 mode support can be optional.

So based on 1 & 2, we do not even bother to check the 'SysBus64V3' bit
when HC version >= 4.10. Is that right?


I verified the patch on SDHC version 3.00 with 64-bit System Address
Support. Hope more configurations are available for testing on Eugene's
side.


Besides, some minor comments below:

> -Original Message-
> From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> Sent: Saturday, March 02, 2019 2:30 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A; eug...@hp.com; Ashish Singhal
> Subject: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA
> Support

Please help to add the below Bugzilla tracker for reference:
https://bugzilla.tianocore.org/show_bug.cgi?id=1583

I have updated the above tracker to match the purpose of the proposed
patch.


>
> Driver was supporting only 32b DMA support for V3 controllers. Add
> support for 64b DMA as well for completeness.
>
> For V4.0 64b support, driver was looking at incorrect capability
> register bit. Fix for that is present as well.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ashish Singhal 
> mailto:ashishsin...@nvidia.com>>
> ---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 10 +-
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 6 +-
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 199
> ++---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 29 ++-
> 4 files changed, 170 insertions(+), 74 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> index b474f8d..9b7b88c 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> @@ -6,7 +6,7 @@
>
> It would expose EFI_SD_MMC_PASS_THRU_PROTOCOL for upper layer use.
>
> - Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> + Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
> Copyright (c) 2015 - 2019, Intel Corporation. All rights reserved.
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> License
> @@ -666,8 +666,12 @@ SdMmcPciHcDriverBindingStart (
> // If any of the slots does not support 64b system bus
> // do not enable 64b DMA in the PCI layer.
> //
> - if (Private->Capability[Slot].SysBus64V3 == 0 &&
> - Private->Capability[Slot].SysBus64V4 == 0) {
> + if ((Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_300 &&
> + Private->Capability[Slot].SysBus64V3 == 0) ||
> + (Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_400 &&
> + Private->Capability[Slot].SysBus64V3 == 0) ||
> + (Private->ControllerVersion[Slot] >= SD_MMC_HC_CTRL_VER_410 &&
> + Private->Capability[Slot].SysBus64V4 == 0)) {
> Support64BitDma = FALSE;
> }
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> index 1bb701a..68d8a5c 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> @@ -2,7 +2,7 @@
>
> Provides some data structure definitions used by the SD/MMC host
> controller driver.
>
> -Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> +Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
> Copyright (c) 2015, Intel Corp

Re: [edk2] [PATCH RESEND 3/3] OvmfPkg/XenSupport: turn off address decoding before BAR sizing

2019-03-06 Thread Laszlo Ersek

On 03/06/19 15:26, Igor Druzhinin wrote:
> On 06/03/2019 13:22, Laszlo Ersek wrote:
>> On 03/06/19 13:40, Igor Druzhinin wrote:
>>> On Xen, hvmloader firmware leaves address decoding enabled for
>>> enumerated PCI device before jumping into OVMF. OVMF seems to
>>> expect it to be disabled and tries to size PCI BARs in several places
>>> without disabling it which causes BAR64, for example, being
>>> incorrectly placed by QEMU.
>>>
>>> Fix it by disabling PCI address decoding explicitly before the
>>> first attempt to size BARs on Xen.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Igor Druzhinin 
>>> ---
>>>  OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 34 
>>> +++
>>>  1 file changed, 34 insertions(+)
>>>
>>> diff --git a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c 
>>> b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
>>> index 408fb24..9940335 100644
>>> --- a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
>>> +++ b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
>>> @@ -55,6 +55,33 @@ PcatPciRootBridgeBarExisted (
>>>EnableInterrupts ();
>>>  }
>>>  
>>> +#define EFI_PCI_COMMAND_DECODE ((UINT16)(EFI_PCI_COMMAND_IO_SPACE | \
>>> + EFI_PCI_COMMAND_MEMORY_SPACE))
>>
>> I thought I asked you not to define a macro here that started with the
>> "EFI_" prefix :/
>>
>> dd8e3c9e-cb76-d3fe-6a10-c0a41c714b56@redhat.com">http://mid.mail-archive.com/dd8e3c9e-cb76-d3fe-6a10-c0a41c714b56@redhat.com
>>
> 
> This is a resend of v1 patch series to get Xen folks into CC and gather
> comments. I expect v2.

My bad, thanks for the clarification. On edk2-devel we very rarely post
RESENDs without updates, and so I missed the implications now.

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 09/10] StandaloneMmPkg/Core: remove legacy boot support

2019-03-06 Thread Achin Gupta

Reviewed-by: achin.gu...@arm.com

On Tue, Mar 05, 2019 at 02:32:47PM +0100, Ard Biesheuvel wrote:
> Remove the support for booting 'legacy' (i.e., non-UEFI boot) OSes.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  StandaloneMmPkg/Core/StandaloneMmCore.h |  22 
>  StandaloneMmPkg/Core/StandaloneMmCore.c | 124 ++--
>  2 files changed, 33 insertions(+), 113 deletions(-)
>
> diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.h 
> b/StandaloneMmPkg/Core/StandaloneMmCore.h
> index 74338dc9da0d..5d336b3dbbf6 100644
> --- a/StandaloneMmPkg/Core/StandaloneMmCore.h
> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.h
> @@ -635,28 +635,6 @@ MmDriverDispatchHandler (
>
>@return Status Code
>
> -**/
> -EFI_STATUS
> -EFIAPI
> -MmLegacyBootHandler (
> -  IN EFI_HANDLE   DispatchHandle,
> -  IN CONST VOID   *Context,OPTIONAL
> -  IN OUT VOID *CommBuffer, OPTIONAL
> -  IN OUT UINTN*CommBufferSize  OPTIONAL
> -  );
> -
> -/**
> -  This function is the main entry point for an MM handler dispatch
> -  or communicate-based callback.
> -
> -  @param  DispatchHandle  The unique handle assigned to this handler by 
> MmiHandlerRegister().
> -  @param  Context Points to an optional handler context which was 
> specified when the handler was registered.
> -  @param  CommBuffer  A pointer to a collection of data in memory that 
> will
> -  be conveyed from a non-MM environment into an MM 
> environment.
> -  @param  CommBufferSize  The size of the CommBuffer.
> -
> -  @return Status Code
> -
>  **/
>  EFI_STATUS
>  EFIAPI
> diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.c 
> b/StandaloneMmPkg/Core/StandaloneMmCore.c
> index 766cdb5c848c..fb6b3055e9c6 100644
> --- a/StandaloneMmPkg/Core/StandaloneMmCore.c
> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.c
> @@ -87,21 +87,12 @@ EFI_MM_SYSTEM_TABLE  gMmCoreMmst = {
>MmiHandlerUnRegister
>  };
>
> -//
> -// Flag to determine if the platform has performed a legacy boot.
> -// If this flag is TRUE, then the runtime code and runtime data associated 
> with the
> -// MM IPL are converted to free memory, so the MM Core must guarantee that is
> -// does not touch of the code/data associated with the MM IPL if this flag 
> is TRUE.
> -//
> -BOOLEAN  mInLegacyBoot = FALSE;
> -
>  //
>  // Table of MMI Handlers that are registered by the MM Core when it is 
> initialized
>  //
>  MM_CORE_MMI_HANDLERS  mMmCoreMmiHandlers[] = {
>{ MmReadyToLockHandler,&gEfiDxeMmReadyToLockProtocolGuid,  NULL, TRUE  
> },
>{ MmEndOfDxeHandler,   &gEfiEndOfDxeEventGroupGuid,NULL, FALSE 
> },
> -  { MmLegacyBootHandler, &gEfiEventLegacyBootGuid,   NULL, FALSE 
> },
>{ MmExitBootServiceHandler,&gEfiEventExitBootServicesGuid, NULL, FALSE 
> },
>{ MmReadyToBootHandler,&gEfiEventReadyToBootGuid,  NULL, FALSE 
> },
>{ NULL,NULL,   NULL, FALSE 
> },
> @@ -142,47 +133,6 @@ MmEfiNotAvailableYetArg5 (
>return EFI_NOT_AVAILABLE_YET;
>  }
>
> -/**
> -  Software MMI handler that is called when a Legacy Boot event is signaled.  
> The MM
> -  Core uses this signal to know that a Legacy Boot has been performed and 
> that
> -  gMmCorePrivate that is shared between the UEFI and MM execution 
> environments can
> -  not be accessed from MM anymore since that structure is considered free 
> memory by
> -  a legacy OS.
> -
> -  @param  DispatchHandle  The unique handle assigned to this handler by 
> MmiHandlerRegister().
> -  @param  Context Points to an optional handler context which was 
> specified when the handler was registered.
> -  @param  CommBuffer  A pointer to a collection of data in memory that 
> will
> -  be conveyed from a non-MM environment into an MM 
> environment.
> -  @param  CommBufferSize  The size of the CommBuffer.
> -
> -  @return Status Code
> -
> -**/
> -EFI_STATUS
> -EFIAPI
> -MmLegacyBootHandler (
> -  IN EFI_HANDLE  DispatchHandle,
> -  IN CONST VOID  *Context,OPTIONAL
> -  IN OUT VOID*CommBuffer, OPTIONAL
> -  IN OUT UINTN   *CommBufferSize  OPTIONAL
> -  )
> -{
> -  EFI_HANDLE  MmHandle;
> -  EFI_STATUS  Status = EFI_SUCCESS;
> -
> -  if (!mInLegacyBoot) {
> -MmHandle = NULL;
> -Status = MmInstallProtocolInterface (
> -   &MmHandle,
> -   &gEfiEventLegacyBootGuid,
> -   EFI_NATIVE_INTERFACE,
> -   NULL
> -   );
> -  }
> -  mInLegacyBoot = TRUE;
> -  return Status;
> -}
> -
>  /**
>Software MMI handler that is called when a ExitBoot Service event is 
> signaled.
>
> @@ -396,7 +346,6 @@ MmEntryPoint (
>  {
>EFI_STATUS  Status;
>EFI_MM_COMMUNICATE_HEADER  *CommunicateHeader;
> -  BOOLEAN InLegacyBoot;
>
>DEBUG ((

Re: [edk2] Does ARM platform produce MP protocol?

2019-03-06 Thread Andrew Fish via edk2-devel




> On Mar 6, 2019, at 5:22 AM, Ard Biesheuvel  wrote:
> 
> On Wed, 6 Mar 2019 at 13:41, Achin Gupta  > wrote:
>> 
>> On Wed, Mar 06, 2019 at 10:37:58AM +0100, Ard Biesheuvel wrote:
>>> (adding Achin and Charles)
>>> 
>>> On Wed, 6 Mar 2019 at 10:16, Ni, Ray  wrote:
 
> -Original Message-
> From: edk2-devel  On Behalf Of Ard
> Biesheuvel
> Sent: Wednesday, March 6, 2019 3:38 PM
> To: Ni, Ray 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] Does ARM platform produce MP protocol?
> 
> On Wed, 6 Mar 2019 at 06:44, Ni, Ray  wrote:
>> 
>> Ard, Leif,
>> I am a bit interested in how ARM platform supports the MP?
>> PI Spec defines below protocol but I failed to find a driver in ARM 
>> platform
> producing this protocol.
>> Or did I miss anything?
>> 
> 
> No you are right. We don't expose that on ARM, since UEFI only runs on a
> single core. Bringing up and taking down cores is done via a protocol 
> called
> PSCI, which is implemented by firmware running at a higher privilege 
> level.
> 
> So while it would be possible to implement the MP protocol on top of PSCI,
> we haven't identified a use case for it yet. (The OS calls PSCI directly 
> to boot
> the secondary cores)
>> 
>> IIUC, the MP protocol enables communication between processors that are 
>> already
>> up instead of bringing them up or taking them down. So, it is orthogonal to
>> PSCI. Is that what you meant?
>> 
> 
> Surely, StartupThisAP starts up the AP, no?
> 
> In any case, I didn't dig any deeper, but I know that PSCI can be used
> (even in the UEFI context) to execute pieces of code on another core
> (ACS uses this IIRC)

Ard,

I take it that the PSCI is replacing the INIT SIPI SIPI mechanism on x86. For 
PI you need to setup the APs (BSP is running EFI) and the MP protocol gets used 
for this on boot. Things like setting up SMM, syncing page tables, and MTRR 
registers. Seems like PSCI kind of replaces this usage on ARM. 

Since the APs don't run EFI, and it is not safe to call EFI APIs on APIs the 
usage for running code on the APs is limited. What I've seen is mostly 
utilities and diagnostics. For example you can write a utility to dump out the 
MTRR and MSR registers that are per CPU. From a diagnostic point of view it is 
easier to generate more memory and cache traffic if you have code running on 
the APs. 

Note: BSP and AP are terms from the original MP Spec on x86. BSP == Boot Strap 
Processor (so runs EFI) and AP == Application Processor (all the CPUs not 
running EFI).

Note: The INIT SIPI SIPI is painful to code since the SIPI sends a real mode 
address for code to run so it involves a lot of complex mode transitions so 
this is why it makes sense to centralize that code for x86. 

Thanks,

Andrew Fish


> 
 
 Is below EFI_MM_MP_PROTOCOL (added in PI spec 1.6) implemented in ARM?
 Or will it be implemented by an ARM module?
>>> 
>>> No it is currently not implemented, and I am not aware of any plans to do 
>>> so.
>> 
>> +1. There is no need to do this until UEFI runs on a single core on Arm.
>> 
> 
> until -> as long as ??
> 
>>> 
 I am asking this because MP_SERVICES protocol exposes CPU location 
 information
 (Package/Core/Thread) through *GetProcessorInfo*, but MM_MP protocol 
 doesn't
 have a way to expose that information.
 If such location information isn't exposed by MM_MP, is that because ARM 
 doesn't
 care about the location information? Or because ARM cares but forgot to 
 add similar
 *GetProcessorInfo* interface to MM_MP when changing the PI spec?
 Or ARM doesn't use the MM_MP at all?
>> 
>> Even if Arm used this protocol, it can work with the logical processor 
>> number. I
>> don't see a need to expose the location information to the caller. It seems 
>> very
>> Intel specific. Is the EFI_MP_SERVICES_PROTOCOL used on Arm?
>> 
> 
> No, that is what started the discussion.
> 
 
>>> 
>>> I don't know the history of this protocol and who proposed it, but
>>> today, we don't have a need for running per-CPU initialization code in
>>> the context of MM. Even if MM is a component of the more privileged
>>> firmware running on an ARM system, it is running in a sandbox that was
>>> primarily designed around exposing MM services to UEFI code running at
>>> the same privilege level as the OS (such as the authenticated variable
>>> store). Platform initialization code (which is more likely to require
>>> dispatch to each core) runs in the secure world as well, but not in
>>> the context of MM.
>>> 
>>> I will let Achin chime in here as well.
>> 
>> +1.
>> 
>> I will let Charles comment on the history. Maybe this protocol was designed
>> for Arm systems where MM is the most privileged firmware. The upstream
>> implementation runs MM in the lowest privilege level. Either way, this 
>> protocol
>> sense only when MM

Re: [edk2] Any open source EFI app to dump USB descriptors from Shell

2019-03-06 Thread Yao, Jiewen

For UEFI, you may refer to 
https://github.com/jyao1/EdkiiShellTool/tree/master/EdkiiShellToolPkg/UsbInfo

As cross reference, you may use USBView in windows or lsusb in Linux.

Thank you
Yao Jiewen

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> galla rao
> Sent: Wednesday, March 6, 2019 5:13 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Any open source EFI app to dump USB descriptors from Shell
> 
> Hi All,
> 
> Am looking for an app in EFI, to dump USB descriptors
> Any info on such utility, please educate
> 
> Regards
> Ranga
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] EDK II Specifications for edk2-stable201903 tag

2019-03-06 Thread Kinney, Michael D

Hi Liming and Bob,

I see several EDK II specification updates.

I do not see consistent updates to the Revision History
In the README.md with link to the BZ for the document
change.  Please make sure all revision histories are
up to date with BZ links, and as each BZ is closed put
the links to commits made in the BZ.  This allows anyone
reading the documents to follow the link to the BZ from
the Revision History, review the change request and follow
the links to the commits in GitHub and the easily view the
document changes.

Do you want released versions of these documents to 
align with the edk2-stable201903 tag?  The document
release process is documented here:

https://github.com/tianocore-docs/edk2-TemplateSpecification/wiki/TianoCore-Documents-Releasing

If so, please enter BZ for each document with the
requested release version number along with the 
SHA hash of on master the release branch is being
requested.

Thanks,

Mike

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 10/10] ArmPkg/MmCommunicationDxe: signal architected PI events into MM context

2019-03-06 Thread Achin Gupta

Reviewed-by: achin.gu...@arm.com

On Tue, Mar 05, 2019 at 02:32:48PM +0100, Ard Biesheuvel wrote:
> PI defines a few architected events that have significance in the MM
> context as well as in the non-secure DXE context. So register notify
> handlers for these events, and relay them into the standalone MM world.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf |  5 +++
>  ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c   | 47 
> +++-
>  2 files changed, 50 insertions(+), 2 deletions(-)
>
> diff --git a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf 
> b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
> index 88beafa39c05..8bf269270f9d 100644
> --- a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
> +++ b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
> @@ -48,6 +48,11 @@ [LibraryClasses]
>  [Protocols]
>gEfiMmCommunicationProtocolGuid  ## PRODUCES
>
> +[Guids]
> +  gEfiEndOfDxeEventGroupGuid
> +  gEfiEventExitBootServicesGuid
> +  gEfiEventReadyToBootGuid
> +
>  [Pcd.common]
>gArmTokenSpaceGuid.PcdMmBufferBase
>gArmTokenSpaceGuid.PcdMmBufferSize
> diff --git a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c 
> b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> index feb9fa9f4ead..3203cf801a19 100644
> --- a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> +++ b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> @@ -265,6 +265,43 @@ GetMmCompatibility ()
>return Status;
>  }
>
> +STATIC EFI_GUID* CONST mGuidedEventGuid[] = {
> +  &gEfiEndOfDxeEventGroupGuid,
> +  &gEfiEventExitBootServicesGuid,
> +  &gEfiEventReadyToBootGuid,
> +};
> +
> +STATIC EFI_EVENT mGuidedEvent[ARRAY_SIZE (mGuidedEventGuid)];
> +
> +/**
> +  Event notification that is fired when GUIDed Event Group is signaled.
> +
> +  @param  Event The Event that is being processed, not used.
> +  @param  Context   Event Context, not used.
> +
> +**/
> +STATIC
> +VOID
> +EFIAPI
> +MmGuidedEventNotify (
> +  IN EFI_EVENT  Event,
> +  IN VOID   *Context
> +  )
> +{
> +  EFI_MM_COMMUNICATE_HEADER   Header;
> +  UINTN   Size;
> +
> +  //
> +  // Use Guid to initialize EFI_SMM_COMMUNICATE_HEADER structure
> +  //
> +  CopyGuid (&Header.HeaderGuid, Context);
> +  Header.MessageLength = 1;
> +  Header.Data[0] = 0;
> +
> +  Size = sizeof (Header);
> +  MmCommunicationCommunicate (&mMmCommunication, &Header, &Size);
> +}
> +
>  /**
>The Entry Point for MM Communication
>
> @@ -287,6 +324,7 @@ MmCommunicationInitialize (
>)
>  {
>EFI_STATUS Status;
> +  UINTN  Index;
>
>// Check if we can make the MM call
>Status = GetMmCompatibility ();
> @@ -351,8 +389,13 @@ MmCommunicationInitialize (
>NULL,
>&mSetVirtualAddressMapEvent
>);
> -  if (Status == EFI_SUCCESS) {
> -return Status;
> +  ASSERT_EFI_ERROR (Status);
> +
> +  for (Index = 0; Index < ARRAY_SIZE (mGuidedEventGuid); Index++) {
> +Status = gBS->CreateEventEx (EVT_NOTIFY_SIGNAL, TPL_CALLBACK,
> +MmGuidedEventNotify, mGuidedEventGuid[Index],
> +mGuidedEventGuid[Index], &mGuidedEvent[Index]);
> +ASSERT_EFI_ERROR (Status);
>}
>
>gBS->UninstallProtocolInterface (
> --
> 2.20.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 08/10] StandaloneMmPkg/Core: drop support for dispatching FVs into MM

2019-03-06 Thread Achin Gupta

Reviewed-by: achin.gu...@arm.com

On Tue, Mar 05, 2019 at 02:32:46PM +0100, Ard Biesheuvel wrote:
> Remove the support that permits calls into the MM context to dispatch
> firmware volumes that are not part of the initial standalone MM firmware
> volume.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  StandaloneMmPkg/Core/StandaloneMmCore.h | 22 --
>  StandaloneMmPkg/Core/Dispatcher.c   | 46 
>  StandaloneMmPkg/Core/StandaloneMmCore.c |  1 -
>  3 files changed, 69 deletions(-)
>
> diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.h 
> b/StandaloneMmPkg/Core/StandaloneMmCore.h
> index 0d20bcaa6be5..74338dc9da0d 100644
> --- a/StandaloneMmPkg/Core/StandaloneMmCore.h
> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.h
> @@ -635,28 +635,6 @@ MmDriverDispatchHandler (
>
>@return Status Code
>
> -**/
> -EFI_STATUS
> -EFIAPI
> -MmFvDispatchHandler (
> -  IN EFI_HANDLE   DispatchHandle,
> -  IN CONST VOID   *Context,OPTIONAL
> -  IN OUT VOID *CommBuffer, OPTIONAL
> -  IN OUT UINTN*CommBufferSize  OPTIONAL
> -  );
> -
> -/**
> -  This function is the main entry point for an MM handler dispatch
> -  or communicate-based callback.
> -
> -  @param  DispatchHandle  The unique handle assigned to this handler by 
> MmiHandlerRegister().
> -  @param  Context Points to an optional handler context which was 
> specified when the handler was registered.
> -  @param  CommBuffer  A pointer to a collection of data in memory that 
> will
> -  be conveyed from a non-MM environment into an MM 
> environment.
> -  @param  CommBufferSize  The size of the CommBuffer.
> -
> -  @return Status Code
> -
>  **/
>  EFI_STATUS
>  EFIAPI
> diff --git a/StandaloneMmPkg/Core/Dispatcher.c 
> b/StandaloneMmPkg/Core/Dispatcher.c
> index bede4832cfb7..4b2f38f700a0 100644
> --- a/StandaloneMmPkg/Core/Dispatcher.c
> +++ b/StandaloneMmPkg/Core/Dispatcher.c
> @@ -883,52 +883,6 @@ MmAddToDriverList (
>return EFI_SUCCESS;
>  }
>
> -/**
> -  This function is the main entry point for an MM handler dispatch
> -  or communicate-based callback.
> -
> -  @param  DispatchHandle  The unique handle assigned to this handler by 
> SmiHandlerRegister().
> -  @param  Context Points to an optional handler context which was 
> specified when the handler was registered.
> -  @param  CommBuffer  A pointer to a collection of data in memory that 
> will
> -  be conveyed from a non-MM environment into an MM 
> environment.
> -  @param  CommBufferSize  The size of the CommBuffer.
> -
> -  @return Status Code
> -
> -**/
> -EFI_STATUS
> -EFIAPI
> -MmFvDispatchHandler (
> -  IN EFI_HANDLE   DispatchHandle,
> -  IN CONST VOID   *Context,OPTIONAL
> -  IN OUT VOID *CommBuffer, OPTIONAL
> -  IN OUT UINTN*CommBufferSize  OPTIONAL
> -  )
> -{
> -  EFI_STATUSStatus;
> -  EFI_MM_COMMUNICATE_FV_DISPATCH_DATA  *CommunicationFvDispatchData;
> -  EFI_FIRMWARE_VOLUME_HEADER*FwVolHeader;
> -
> -  DEBUG ((DEBUG_INFO, "MmFvDispatchHandler\n"));
> -
> -  CommunicationFvDispatchData = CommBuffer;
> -
> -  DEBUG ((DEBUG_INFO, "  Dispatch - 0x%016lx - 0x%016lx\n", 
> CommunicationFvDispatchData->Address,
> -  CommunicationFvDispatchData->Size));
> -
> -  FwVolHeader = (EFI_FIRMWARE_VOLUME_HEADER 
> *)(UINTN)CommunicationFvDispatchData->Address;
> -
> -  MmCoreFfsFindMmDriver (FwVolHeader);
> -
> -  //
> -  // Execute the MM Dispatcher on any newly discovered FVs and previously
> -  // discovered MM drivers that have been discovered but not dispatched.
> -  //
> -  Status = MmDispatcher ();
> -
> -  return Status;
> -}
> -
>  /**
>Traverse the discovered list for any drivers that were discovered but not 
> loaded
>because the dependency experessions evaluated to false.
> diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.c 
> b/StandaloneMmPkg/Core/StandaloneMmCore.c
> index ec53b8d8bec4..766cdb5c848c 100644
> --- a/StandaloneMmPkg/Core/StandaloneMmCore.c
> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.c
> @@ -99,7 +99,6 @@ BOOLEAN  mInLegacyBoot = FALSE;
>  // Table of MMI Handlers that are registered by the MM Core when it is 
> initialized
>  //
>  MM_CORE_MMI_HANDLERS  mMmCoreMmiHandlers[] = {
> -  { MmFvDispatchHandler, &gMmFvDispatchGuid, NULL, TRUE  
> },
>{ MmReadyToLockHandler,&gEfiDxeMmReadyToLockProtocolGuid,  NULL, TRUE  
> },
>{ MmEndOfDxeHandler,   &gEfiEndOfDxeEventGroupGuid,NULL, FALSE 
> },
>{ MmLegacyBootHandler, &gEfiEventLegacyBootGuid,   NULL, FALSE 
> },
> --
> 2.20.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 07/10] StandaloneMmPkg/Core: dispatch all drivers at init time

2019-03-06 Thread Achin Gupta

Reviewed-by: achin.gu...@arm.com

On Tue, Mar 05, 2019 at 02:32:45PM +0100, Ard Biesheuvel wrote:
> Instead of deferring dispatch of the remaining MM drivers once the
> CPU driver has been dispatched, proceed and dispatch all drivers.
> This makes sense for standalone MM, since all dispatchable drivers
> should be present in the initial firmware volume anyway: dispatch
> of additional FVs originating in the non-secure side is not supported.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  StandaloneMmPkg/Core/Dispatcher.c   | 92 
>  StandaloneMmPkg/Core/StandaloneMmCore.c |  1 -
>  2 files changed, 93 deletions(-)
>
> diff --git a/StandaloneMmPkg/Core/Dispatcher.c 
> b/StandaloneMmPkg/Core/Dispatcher.c
> index 8a2ad5118d92..bede4832cfb7 100644
> --- a/StandaloneMmPkg/Core/Dispatcher.c
> +++ b/StandaloneMmPkg/Core/Dispatcher.c
> @@ -575,7 +575,6 @@ MmDispatcher (
>LIST_ENTRY*Link;
>EFI_MM_DRIVER_ENTRY  *DriverEntry;
>BOOLEAN   ReadyToRun;
> -  BOOLEAN   PreviousMmEntryPointRegistered;
>
>DEBUG ((DEBUG_INFO, "MmDispatcher\n"));
>
> @@ -639,11 +638,6 @@ MmDispatcher (
>DriverEntry->Initialized  = TRUE;
>RemoveEntryList (&DriverEntry->ScheduledLink);
>
> -  //
> -  // Cache state of MmEntryPointRegistered before calling entry point
> -  //
> -  PreviousMmEntryPointRegistered = 
> gMmCorePrivate->MmEntryPointRegistered;
> -
>//
>// For each MM driver, pass NULL as ImageHandle
>//
> @@ -661,20 +655,6 @@ MmDispatcher (
>  DEBUG ((DEBUG_INFO, "StartImage Status - %r\n", Status));
>  MmFreePages(DriverEntry->ImageBuffer, DriverEntry->NumberOfPage);
>}
> -
> -  if (!PreviousMmEntryPointRegistered && 
> gMmCorePrivate->MmEntryPointRegistered) {
> -//
> -// Return immediately if the MM Entry Point was registered by the MM
> -// Driver that was just dispatched.  The MM IPL will reinvoke the MM
> -// Core Dispatcher.  This is required so MM Mode may be enabled as 
> soon
> -// as all the dependent MM Drivers for MM Mode have been dispatched.
> -// Once the MM Entry Point has been registered, then MM Mode will be
> -// used.
> -//
> -gRequestDispatch = TRUE;
> -gDispatcherRunning = FALSE;
> -return EFI_NOT_READY;
> -  }
>  }
>
>  //
> @@ -903,78 +883,6 @@ MmAddToDriverList (
>return EFI_SUCCESS;
>  }
>
> -/**
> -  This function is the main entry point for an MM handler dispatch
> -  or communicate-based callback.
> -
> -  Event notification that is fired every time a FV dispatch protocol is 
> added.
> -  More than one protocol may have been added when this event is fired, so you
> -  must loop on MmLocateHandle () to see how many protocols were added and
> -  do the following to each FV:
> -  If the Fv has already been processed, skip it. If the Fv has not been
> -  processed then mark it as being processed, as we are about to process it.
> -  Read the Fv and add any driver in the Fv to the mDiscoveredList.The
> -  mDiscoveredList is never free'ed and contains variables that define
> -  the other states the MM driver transitions to..
> -  While you are at it read the A Priori file into memory.
> -  Place drivers in the A Priori list onto the mScheduledQueue.
> -
> -  @param  DispatchHandle  The unique handle assigned to this handler by 
> SmiHandlerRegister().
> -  @param  Context Points to an optional handler context which was 
> specified when the handler was registered.
> -  @param  CommBuffer  A pointer to a collection of data in memory that 
> will
> -  be conveyed from a non-MM environment into an MM 
> environment.
> -  @param  CommBufferSize  The size of the CommBuffer.
> -
> -  @return Status Code
> -
> -**/
> -EFI_STATUS
> -EFIAPI
> -MmDriverDispatchHandler (
> -  IN EFI_HANDLE  DispatchHandle,
> -  IN CONST VOID  *Context,OPTIONAL
> -  IN OUT VOID*CommBuffer, OPTIONAL
> -  IN OUT UINTN   *CommBufferSize  OPTIONAL
> -  )
> -{
> -  EFI_STATUSStatus;
> -
> -  DEBUG ((DEBUG_INFO, "MmDriverDispatchHandler\n"));
> -
> -  //
> -  // Execute the MM Dispatcher on any newly discovered FVs and previously
> -  // discovered MM drivers that have been discovered but not dispatched.
> -  //
> -  Status = MmDispatcher ();
> -
> -  //
> -  // Check to see if CommBuffer and CommBufferSize are valid
> -  //
> -  if (CommBuffer != NULL && CommBufferSize != NULL) {
> -if (*CommBufferSize > 0) {
> -  if (Status == EFI_NOT_READY) {
> -//
> -// If a the MM Core Entry Point was just registered, then set flag to
> -// request the MM Dispatcher to be restarted.
> -//
> -*(UINT8 *)CommBuffer = COMM_BUFFER_MM_DISPATCH_RESTART;
> -  } else if (!EFI_ERROR (Status)) {
> -//
>

Re: [edk2] [PATCH 06/10] StandaloneMmPkg/Core: permit encapsulated firmware volumes

2019-03-06 Thread Achin Gupta

Reviewed-by: achin.gu...@arm.com

On Tue, Mar 05, 2019 at 02:32:44PM +0100, Ard Biesheuvel wrote:
> Standalone MM requires 4 KB section alignment for all images, so that
> strict permissions can be applied. Unfortunately, this results in a
> lot of wasted space, which is usually costly in the secure world
> environment that standalone MM is expected to operate in.
>
> So let's permit the standalone MM drivers (but not the core) to be
> delivered in a compressed firmware volume.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  StandaloneMmPkg/Core/StandaloneMmCore.inf |  1 +
>  StandaloneMmPkg/Core/FwVol.c  | 99 ++--
>  2 files changed, 91 insertions(+), 9 deletions(-)
>
> diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.inf 
> b/StandaloneMmPkg/Core/StandaloneMmCore.inf
> index ff2b8b9cef03..83d31e2d92c5 100644
> --- a/StandaloneMmPkg/Core/StandaloneMmCore.inf
> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.inf
> @@ -49,6 +49,7 @@ [LibraryClasses]
>BaseMemoryLib
>CacheMaintenanceLib
>DebugLib
> +  ExtractGuidedSectionLib
>FvLib
>HobLib
>MemoryAllocationLib
> diff --git a/StandaloneMmPkg/Core/FwVol.c b/StandaloneMmPkg/Core/FwVol.c
> index 5abf98c24797..d95491f252f9 100644
> --- a/StandaloneMmPkg/Core/FwVol.c
> +++ b/StandaloneMmPkg/Core/FwVol.c
> @@ -14,6 +14,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
> EXPRESS OR IMPLIED.
>
>  #include "StandaloneMmCore.h"
>  #include 
> +#include 
>
>  //
>  // List of file types supported by dispatcher
> @@ -65,15 +66,25 @@ Returns:
>
>  --*/
>  {
> -  EFI_STATUS  Status;
> -  EFI_STATUS  DepexStatus;
> -  EFI_FFS_FILE_HEADER *FileHeader;
> -  EFI_FV_FILETYPE FileType;
> -  VOID*Pe32Data;
> -  UINTN   Pe32DataSize;
> -  VOID*Depex;
> -  UINTN   DepexSize;
> -  UINTN   Index;
> +  EFI_STATUS  Status;
> +  EFI_STATUS  DepexStatus;
> +  EFI_FFS_FILE_HEADER *FileHeader;
> +  EFI_FV_FILETYPE FileType;
> +  VOID*Pe32Data;
> +  UINTN   Pe32DataSize;
> +  VOID*Depex;
> +  UINTN   DepexSize;
> +  UINTN   Index;
> +  EFI_COMMON_SECTION_HEADER   *Section;
> +  VOID*SectionData;
> +  UINTN   SectionDataSize;
> +  UINT32  DstBufferSize;
> +  VOID*ScratchBuffer;
> +  UINT32  ScratchBufferSize;
> +  VOID*DstBuffer;
> +  UINT16  SectionAttribute;
> +  UINT32  AuthenticationStatus;
> +  EFI_FIRMWARE_VOLUME_HEADER  *InnerFvHeader;
>
>DEBUG ((DEBUG_INFO, "MmCoreFfsFindMmDriver - 0x%x\n", FwVolHeader));
>
> @@ -83,6 +94,71 @@ Returns:
>
>FvIsBeingProcesssed (FwVolHeader);
>
> +  //
> +  // First check for encapsulated compressed firmware volumes
> +  //
> +  FileHeader = NULL;
> +  do {
> +Status = FfsFindNextFile (EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE,
> +   FwVolHeader, &FileHeader);
> +if (EFI_ERROR (Status)) {
> +  break;
> +}
> +Status = FfsFindSectionData (EFI_SECTION_GUID_DEFINED, FileHeader,
> +   &SectionData, &SectionDataSize);
> +if (EFI_ERROR (Status)) {
> +  break;
> +}
> +Section = (EFI_COMMON_SECTION_HEADER *)(FileHeader + 1);
> +Status = ExtractGuidedSectionGetInfo (Section, &DstBufferSize,
> +   &ScratchBufferSize, &SectionAttribute);
> +if (EFI_ERROR (Status)) {
> +  break;
> +}
> +
> +//
> +// Allocate scratch buffer
> +//
> +ScratchBuffer = (VOID *)(UINTN)AllocatePages (EFI_SIZE_TO_PAGES 
> (ScratchBufferSize));
> +if (ScratchBuffer == NULL) {
> +  return EFI_OUT_OF_RESOURCES;
> +}
> +
> +//
> +// Allocate destination buffer, extra one page for adjustment
> +//
> +DstBuffer = (VOID *)(UINTN)AllocatePages (EFI_SIZE_TO_PAGES 
> (DstBufferSize));
> +if (DstBuffer == NULL) {
> +  return EFI_OUT_OF_RESOURCES;
> +}
> +
> +//
> +// Call decompress function
> +//
> +Status = ExtractGuidedSectionDecode (Section, &DstBuffer, ScratchBuffer,
> +&AuthenticationStatus);
> +FreePages (ScratchBuffer, EFI_SIZE_TO_PAGES (ScratchBufferSize));
> +if (EFI_ERROR (Status)) {
> +  goto FreeDstBuffer;
> +}
> +
> +DEBUG ((DEBUG_INFO,
> +  "Processing compressed firmware volume (AuthenticationStatus == %x)\n",
> +  AuthenticationStatus));
> +
> +Status = FindFfsSectionInSections (DstBuffer, DstBufferSize,
> +   EFI

Re: [edk2] [PATCH 05/10] StandaloneMmPkg/StandaloneMmCoreEntryPoint: drop explicit SerialPortLib call

2019-03-06 Thread Achin Gupta

On Wed, Mar 06, 2019 at 05:41:30PM +0100, Ard Biesheuvel wrote:
> On Wed, 6 Mar 2019 at 17:35, Achin Gupta  wrote:
> >
> > Hi Ard,
> >
> > On Tue, Mar 05, 2019 at 02:32:43PM +0100, Ard Biesheuvel wrote:
> > > Sending DEBUG output to the serial port should only be done via
> > > DebugLib calls, which is in charge of initializing the serial
> > > port when appropriate. So drop the explicit SerialPortInitialize ()
> > > invocation, and rely on normal constructor ordering to get the
> > > serial port into the appropriate state at the right time.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Ard Biesheuvel 
> > > ---
> > >  
> > > StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
> > >  | 3 ---
> > >  1 file changed, 3 deletions(-)
> > >
> > > diff --git 
> > > a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
> > >  
> > > b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
> > > index 5cca532456fd..c8e11a253d24 100644
> > > --- 
> > > a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
> > > +++ 
> > > b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
> > > @@ -232,9 +232,6 @@ _ModuleEntryPoint (
> > >VOID*TeData;
> > >UINTN   TeDataSize;
> > >
> > > -  Status = SerialPortInitialize ();
> > > -  ASSERT_EFI_ERROR (Status);
> >
> > This is done in the first few instructions after EL3 ERETs into S-EL0 to
> > initialise the StMM partition. The constructors will be called a bit later. 
> > I
> > agree with the change but does EDK2 provide a mechanism for early prints to 
> > the
> > console in case we need this in future.
> >
>
> If so, the correct way to achieve this would be to call the DebugLib
> constructor by hand, and that should call the SerialPortLib
> constructor. Unfortunately, EDK2 is not put together like that, and
> especially constructor ordering is slightly broken.

Thanks!

Reviewed-by: achin.gu...@arm.com
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg/UefiShellAcpiViewCommandLib: Change the note in uni

2019-03-06 Thread Carsey, Jaben

Good catch.  After fixing this typo, my RB stands.

Sent from my iPad

On Mar 6, 2019, at 7:59 AM, Nariman Poushin 
mailto:nariman.pous...@linaro.org>> wrote:



On Wed, 6 Mar 2019 at 15:54, Carsey, Jaben 
mailto:jaben.car...@intel.com>> wrote:
Reviewed-by: Jaben Carsey 
mailto:jaben.car...@intel.com>>

> -Original Message-
> From: Gao, Zhichao
> Sent: Tuesday, March 05, 2019 11:05 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ray mailto:ray...@intel.com>>; Carsey, Jaben 
> mailto:jaben.car...@intel.com>>;
> Gao, Liming mailto:liming@intel.com>>
> Subject: [PATCH] ShellPkg/UefiShellAcpiViewCommandLib: Change the note
> in uni
> Importance: High
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1146
>
> Add DSDT and SSDT description in the help information. Depend
> on the implement of UefiShellAcpiViewCommandLib, the "acpiview"
> command support to show all present type in the system not only
> support the listed type in the help information. So change the
> help information of this command.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao 
> mailto:zhichao@intel.com>>
> Cc: Ruiyu Ni mailto:ruiyu...@intel.com>>
> Cc: Jaben Carsey mailto:jaben.car...@intel.com>>
> Cc: Liming Gao mailto:liming@intel.com>>
> ---
>  .../UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.uni   | 8
> +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewComm
> andLib.uni
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewComm
> andLib.uni
> index 0762eeba53..f2a2400b91 100644
> ---
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewComm
> andLib.uni
> +++
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewComm
> andLib.uni
> @@ -74,10 +74,15 @@
>  "  1. The AcpiTable parameter can match any installed table type.\r\n"
>  " Tables without specific handling will be displayed as a raw hex dump
> (or\r\n"
>  " dumped to a file if -d is used).\r\n"
> -"  2. Formatted display and checking is provided for these signature
> types:\r\n"
> +"  2. -s option supports to display the specified AcpiTable type that is
> present\r\n"
> +" in the system. For normal type AcpiTable, it would display the data of
> the\r\n"
> +" AcpiTable and AcpiTable header. The following type may contain header
> type\r\n"
> +" other than AcpiTable header. The acual header can refer to the ACPI
> spec 6.2\r\n"
> +" Extra A. Particual types:\r\n"

Should this be "Particular"?

>  "   APIC  - Multiple APIC Description Table (MADT)\r\n"
>  "   BGRT  - Boot Graphics Resource Table\r\n"
>  "   DBG2  - Debug Port Table 2\r\n"
> +"   DSDT  - Differentiated System Description Table\r\n"
>  "   FACP  - Fixed ACPI Description Table (FADT)\r\n"
>  "   GTDT  - Generic Timer Description Table\r\n"
>  "   IORT  - IO Remapping Table\r\n"
> @@ -87,6 +92,7 @@
>  "   SLIT  - System Locality Information Table\r\n"
>  "   SPCR  - Serial Port Console Redirection Table\r\n"
>  "   SRAT  - System Resource Affinity Table\r\n"
> +"   SSDT  - Secondary SystemDescription Table\r\n"
>  "   XSDT  - Extended System Description Table\r\n"
>  " \r\n"
>  ".SH STANDARDS\r\n"
> --
> 2.16.2.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 05/10] StandaloneMmPkg/StandaloneMmCoreEntryPoint: drop explicit SerialPortLib call

2019-03-06 Thread Ard Biesheuvel

On Wed, 6 Mar 2019 at 17:35, Achin Gupta  wrote:
>
> Hi Ard,
>
> On Tue, Mar 05, 2019 at 02:32:43PM +0100, Ard Biesheuvel wrote:
> > Sending DEBUG output to the serial port should only be done via
> > DebugLib calls, which is in charge of initializing the serial
> > port when appropriate. So drop the explicit SerialPortInitialize ()
> > invocation, and rely on normal constructor ordering to get the
> > serial port into the appropriate state at the right time.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel 
> > ---
> >  
> > StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
> >  | 3 ---
> >  1 file changed, 3 deletions(-)
> >
> > diff --git 
> > a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
> >  
> > b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
> > index 5cca532456fd..c8e11a253d24 100644
> > --- 
> > a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
> > +++ 
> > b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
> > @@ -232,9 +232,6 @@ _ModuleEntryPoint (
> >VOID*TeData;
> >UINTN   TeDataSize;
> >
> > -  Status = SerialPortInitialize ();
> > -  ASSERT_EFI_ERROR (Status);
>
> This is done in the first few instructions after EL3 ERETs into S-EL0 to
> initialise the StMM partition. The constructors will be called a bit later. I
> agree with the change but does EDK2 provide a mechanism for early prints to 
> the
> console in case we need this in future.
>

If so, the correct way to achieve this would be to call the DebugLib
constructor by hand, and that should call the SerialPortLib
constructor. Unfortunately, EDK2 is not put together like that, and
especially constructor ordering is slightly broken.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 05/10] StandaloneMmPkg/StandaloneMmCoreEntryPoint: drop explicit SerialPortLib call

2019-03-06 Thread Achin Gupta

Hi Ard,

On Tue, Mar 05, 2019 at 02:32:43PM +0100, Ard Biesheuvel wrote:
> Sending DEBUG output to the serial port should only be done via
> DebugLib calls, which is in charge of initializing the serial
> port when appropriate. So drop the explicit SerialPortInitialize ()
> invocation, and rely on normal constructor ordering to get the
> serial port into the appropriate state at the right time.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
>  | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git 
> a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
>  
> b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
> index 5cca532456fd..c8e11a253d24 100644
> --- 
> a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
> +++ 
> b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c
> @@ -232,9 +232,6 @@ _ModuleEntryPoint (
>VOID*TeData;
>UINTN   TeDataSize;
>
> -  Status = SerialPortInitialize ();
> -  ASSERT_EFI_ERROR (Status);

This is done in the first few instructions after EL3 ERETs into S-EL0 to
initialise the StMM partition. The constructors will be called a bit later. I
agree with the change but does EDK2 provide a mechanism for early prints to the
console in case we need this in future.

cheers,
Achin

> -
>// Get Secure Partition Manager Version Information
>Status = GetSpmVersion ();
>if (EFI_ERROR (Status)) {
> --
> 2.20.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg/UefiShellAcpiViewCommandLib: Change the note in uni

2019-03-06 Thread Nariman Poushin

On Wed, 6 Mar 2019 at 15:54, Carsey, Jaben  wrote:

> Reviewed-by: Jaben Carsey 
>
> > -Original Message-
> > From: Gao, Zhichao
> > Sent: Tuesday, March 05, 2019 11:05 PM
> > To: edk2-devel@lists.01.org
> > Cc: Ni, Ray ; Carsey, Jaben ;
> > Gao, Liming 
> > Subject: [PATCH] ShellPkg/UefiShellAcpiViewCommandLib: Change the note
> > in uni
> > Importance: High
> >
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1146
> >
> > Add DSDT and SSDT description in the help information. Depend
> > on the implement of UefiShellAcpiViewCommandLib, the "acpiview"
> > command support to show all present type in the system not only
> > support the listed type in the help information. So change the
> > help information of this command.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Zhichao Gao 
> > Cc: Ruiyu Ni 
> > Cc: Jaben Carsey 
> > Cc: Liming Gao 
> > ---
> >  .../UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.uni   | 8
> > +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git
> > a/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewComm
> > andLib.uni
> > b/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewComm
> > andLib.uni
> > index 0762eeba53..f2a2400b91 100644
> > ---
> > a/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewComm
> > andLib.uni
> > +++
> > b/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewComm
> > andLib.uni
> > @@ -74,10 +74,15 @@
> >  "  1. The AcpiTable parameter can match any installed table type.\r\n"
> >  " Tables without specific handling will be displayed as a raw hex
> dump
> > (or\r\n"
> >  " dumped to a file if -d is used).\r\n"
> > -"  2. Formatted display and checking is provided for these signature
> > types:\r\n"
> > +"  2. -s option supports to display the specified AcpiTable type that is
> > present\r\n"
> > +" in the system. For normal type AcpiTable, it would display the
> data of
> > the\r\n"
> > +" AcpiTable and AcpiTable header. The following type may contain
> header
> > type\r\n"
> > +" other than AcpiTable header. The acual header can refer to the
> ACPI
> > spec 6.2\r\n"
> > +" Extra A. Particual types:\r\n"
>

Should this be "Particular"?


> >  "   APIC  - Multiple APIC Description Table (MADT)\r\n"
> >  "   BGRT  - Boot Graphics Resource Table\r\n"
> >  "   DBG2  - Debug Port Table 2\r\n"
> > +"   DSDT  - Differentiated System Description Table\r\n"
> >  "   FACP  - Fixed ACPI Description Table (FADT)\r\n"
> >  "   GTDT  - Generic Timer Description Table\r\n"
> >  "   IORT  - IO Remapping Table\r\n"
> > @@ -87,6 +92,7 @@
> >  "   SLIT  - System Locality Information Table\r\n"
> >  "   SPCR  - Serial Port Console Redirection Table\r\n"
> >  "   SRAT  - System Resource Affinity Table\r\n"
> > +"   SSDT  - Secondary SystemDescription Table\r\n"
> >  "   XSDT  - Extended System Description Table\r\n"
> >  " \r\n"
> >  ".SH STANDARDS\r\n"
> > --
> > 2.16.2.windows.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 03/10] StandaloneMmPkg: switch to NULL DebugLib resolution

2019-03-06 Thread Achin Gupta

Reviewed-by: achin.gu...@arm.com

On Tue, Mar 05, 2019 at 02:32:41PM +0100, Ard Biesheuvel wrote:
> Building StandaloneMmPkg from its .DSC is mainly intended for build
> coverage, and so platform specific configuration such as UART addresses
> don't belong here.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  StandaloneMmPkg/StandaloneMmPkg.dsc | 11 +--
>  1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/StandaloneMmPkg/StandaloneMmPkg.dsc 
> b/StandaloneMmPkg/StandaloneMmPkg.dsc
> index f279d9e7e5c7..8def9688fe7d 100644
> --- a/StandaloneMmPkg/StandaloneMmPkg.dsc
> +++ b/StandaloneMmPkg/StandaloneMmPkg.dsc
> @@ -43,7 +43,7 @@ [LibraryClasses]
>#
>BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
>BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
> -  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
> +  DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
>
> DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
>FvLib|StandaloneMmPkg/Library/FvLib/FvLib.inf
>
> HobLib|StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf
> @@ -66,10 +66,6 @@ [LibraryClasses.AARCH64]
>ArmSvcLib|ArmPkg/Library/ArmSvcLib/ArmSvcLib.inf
>
> CacheMaintenanceLib|ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.inf
>
> PeCoffExtraActionLib|StandaloneMmPkg/Library/StandaloneMmPeCoffExtraActionLib/StandaloneMmPeCoffExtraActionLib.inf
> -  PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
> -  
> PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
> -  # ARM PL011 UART Driver
> -  
> SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
>
>
> StandaloneMmCoreEntryPoint|StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf
>
> @@ -83,11 +79,6 @@ [PcdsFixedAtBuild]
>gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0xff
>gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x0f
>
> -[PcdsFixedAtBuild.AARCH64]
> -  ## PL011 - Serial Terminal
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x1c0b
> -  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200
> -
>  
> ###
>  #
>  # Components Section - list of the modules and components that will be 
> processed by compilation
> --
> 2.20.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg/UefiShellAcpiViewCommandLib: Change the note in uni

2019-03-06 Thread Carsey, Jaben

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Gao, Zhichao
> Sent: Tuesday, March 05, 2019 11:05 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ray ; Carsey, Jaben ;
> Gao, Liming 
> Subject: [PATCH] ShellPkg/UefiShellAcpiViewCommandLib: Change the note
> in uni
> Importance: High
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1146
> 
> Add DSDT and SSDT description in the help information. Depend
> on the implement of UefiShellAcpiViewCommandLib, the "acpiview"
> command support to show all present type in the system not only
> support the listed type in the help information. So change the
> help information of this command.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao 
> Cc: Ruiyu Ni 
> Cc: Jaben Carsey 
> Cc: Liming Gao 
> ---
>  .../UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.uni   | 8
> +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewComm
> andLib.uni
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewComm
> andLib.uni
> index 0762eeba53..f2a2400b91 100644
> ---
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewComm
> andLib.uni
> +++
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewComm
> andLib.uni
> @@ -74,10 +74,15 @@
>  "  1. The AcpiTable parameter can match any installed table type.\r\n"
>  " Tables without specific handling will be displayed as a raw hex dump
> (or\r\n"
>  " dumped to a file if -d is used).\r\n"
> -"  2. Formatted display and checking is provided for these signature
> types:\r\n"
> +"  2. -s option supports to display the specified AcpiTable type that is
> present\r\n"
> +" in the system. For normal type AcpiTable, it would display the data of
> the\r\n"
> +" AcpiTable and AcpiTable header. The following type may contain header
> type\r\n"
> +" other than AcpiTable header. The acual header can refer to the ACPI
> spec 6.2\r\n"
> +" Extra A. Particual types:\r\n"
>  "   APIC  - Multiple APIC Description Table (MADT)\r\n"
>  "   BGRT  - Boot Graphics Resource Table\r\n"
>  "   DBG2  - Debug Port Table 2\r\n"
> +"   DSDT  - Differentiated System Description Table\r\n"
>  "   FACP  - Fixed ACPI Description Table (FADT)\r\n"
>  "   GTDT  - Generic Timer Description Table\r\n"
>  "   IORT  - IO Remapping Table\r\n"
> @@ -87,6 +92,7 @@
>  "   SLIT  - System Locality Information Table\r\n"
>  "   SPCR  - Serial Port Console Redirection Table\r\n"
>  "   SRAT  - System Resource Affinity Table\r\n"
> +"   SSDT  - Secondary SystemDescription Table\r\n"
>  "   XSDT  - Extended System Description Table\r\n"
>  " \r\n"
>  ".SH STANDARDS\r\n"
> --
> 2.16.2.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 02/10] StandaloneMmPkg: drop unused PCD PcdStandaloneMmEnable

2019-03-06 Thread Achin Gupta

On Wed, Mar 06, 2019 at 04:17:51PM +0100, Ard Biesheuvel wrote:
> On Wed, 6 Mar 2019 at 16:16, Achin Gupta  wrote:
> >
> > Hi Ard,
> >
> > On Tue, Mar 05, 2019 at 02:32:40PM +0100, Ard Biesheuvel wrote:
> > > The PCD PcdStandaloneMmEnable is unused, and shouldn't exist in the
> > > first place since the value is implied by the context (it is never
> > > valid to set it to FALSE for standalone MM or TRUE for traditional
> > > MM). So drop it.
> >
> > This is being used to determine if the ArmVExpressPkg should include 
> > support for
> > StMM comm. buffer or not [1] but it does look redundant now.
> >
>
> If that is the case, the PCD should be defined in that package.

The Arm FVP port for StMM needs a rewrite on the lines of other platforms. This
change is fine.

Reviewed-by: achin.gu...@arm.com
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 02/10] StandaloneMmPkg: drop unused PCD PcdStandaloneMmEnable

2019-03-06 Thread Ard Biesheuvel

On Wed, 6 Mar 2019 at 16:16, Achin Gupta  wrote:
>
> Hi Ard,
>
> On Tue, Mar 05, 2019 at 02:32:40PM +0100, Ard Biesheuvel wrote:
> > The PCD PcdStandaloneMmEnable is unused, and shouldn't exist in the
> > first place since the value is implied by the context (it is never
> > valid to set it to FALSE for standalone MM or TRUE for traditional
> > MM). So drop it.
>
> This is being used to determine if the ArmVExpressPkg should include support 
> for
> StMM comm. buffer or not [1] but it does look redundant now.
>

If that is the case, the PCD should be defined in that package.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 02/10] StandaloneMmPkg: drop unused PCD PcdStandaloneMmEnable

2019-03-06 Thread Achin Gupta

Hi Ard,

On Tue, Mar 05, 2019 at 02:32:40PM +0100, Ard Biesheuvel wrote:
> The PCD PcdStandaloneMmEnable is unused, and shouldn't exist in the
> first place since the value is implied by the context (it is never
> valid to set it to FALSE for standalone MM or TRUE for traditional
> MM). So drop it.

This is being used to determine if the ArmVExpressPkg should include support for
StMM comm. buffer or not [1] but it does look redundant now.

cheers,
Achin

[1] https://lists.01.org/pipermail/edk2-devel/2018-December/034432.html

>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  StandaloneMmPkg/StandaloneMmPkg.dec  
>  | 3 ---
>  StandaloneMmPkg/StandaloneMmPkg.dsc  
>  | 3 ---
>  
> StandaloneMmPkg/Library/StandaloneMmPeCoffExtraActionLib/StandaloneMmPeCoffExtraActionLib.inf
>  | 3 ---
>  3 files changed, 9 deletions(-)
>
> diff --git a/StandaloneMmPkg/StandaloneMmPkg.dec 
> b/StandaloneMmPkg/StandaloneMmPkg.dec
> index 0b5fbf9e1767..2d178c5e20a6 100644
> --- a/StandaloneMmPkg/StandaloneMmPkg.dec
> +++ b/StandaloneMmPkg/StandaloneMmPkg.dec
> @@ -39,6 +39,3 @@ [Guids]
>gEfiStandaloneMmNonSecureBufferGuid  = { 0xf00497e3, 0xbfa2, 0x41a1, { 
> 0x9d, 0x29, 0x54, 0xc2, 0xe9, 0x37, 0x21, 0xc5 }}
>gEfiArmTfCpuDriverEpDescriptorGuid   = { 0x6ecbd5a1, 0xc0f8, 0x4702, { 
> 0x83, 0x01, 0x4f, 0xc2, 0xc5, 0x47, 0x0a, 0x51 }}
>
> -[PcdsFeatureFlag]
> -  
> gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable|FALSE|BOOLEAN|0x0001
> -
> diff --git a/StandaloneMmPkg/StandaloneMmPkg.dsc 
> b/StandaloneMmPkg/StandaloneMmPkg.dsc
> index e8d71ad56f52..f279d9e7e5c7 100644
> --- a/StandaloneMmPkg/StandaloneMmPkg.dsc
> +++ b/StandaloneMmPkg/StandaloneMmPkg.dsc
> @@ -78,9 +78,6 @@ [LibraryClasses.AARCH64]
>  # Pcd Section - list of all EDK II PCD Entries defined by this Platform
>  #
>  
> 
> -[PcdsFeatureFlag]
> -  gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable|TRUE
> -
>  [PcdsFixedAtBuild]
>gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80CF
>gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0xff
> diff --git 
> a/StandaloneMmPkg/Library/StandaloneMmPeCoffExtraActionLib/StandaloneMmPeCoffExtraActionLib.inf
>  
> b/StandaloneMmPkg/Library/StandaloneMmPeCoffExtraActionLib/StandaloneMmPeCoffExtraActionLib.inf
> index eef3d7c6e253..181c15b9345a 100644
> --- 
> a/StandaloneMmPkg/Library/StandaloneMmPeCoffExtraActionLib/StandaloneMmPeCoffExtraActionLib.inf
> +++ 
> b/StandaloneMmPkg/Library/StandaloneMmPeCoffExtraActionLib/StandaloneMmPeCoffExtraActionLib.inf
> @@ -37,9 +37,6 @@ [Packages]
>MdePkg/MdePkg.dec
>StandaloneMmPkg/StandaloneMmPkg.dec
>
> -[FeaturePcd]
> -  gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable
> -
>  [LibraryClasses]
>StandaloneMmMmuLib
>PcdLib
> --
> 2.20.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH RESEND 3/3] OvmfPkg/XenSupport: turn off address decoding before BAR sizing

2019-03-06 Thread Igor Druzhinin

On 06/03/2019 13:22, Laszlo Ersek wrote:
> On 03/06/19 13:40, Igor Druzhinin wrote:
>> On Xen, hvmloader firmware leaves address decoding enabled for
>> enumerated PCI device before jumping into OVMF. OVMF seems to
>> expect it to be disabled and tries to size PCI BARs in several places
>> without disabling it which causes BAR64, for example, being
>> incorrectly placed by QEMU.
>>
>> Fix it by disabling PCI address decoding explicitly before the
>> first attempt to size BARs on Xen.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Igor Druzhinin 
>> ---
>>  OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 34 
>> +++
>>  1 file changed, 34 insertions(+)
>>
>> diff --git a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c 
>> b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
>> index 408fb24..9940335 100644
>> --- a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
>> +++ b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
>> @@ -55,6 +55,33 @@ PcatPciRootBridgeBarExisted (
>>EnableInterrupts ();
>>  }
>>  
>> +#define EFI_PCI_COMMAND_DECODE ((UINT16)(EFI_PCI_COMMAND_IO_SPACE | \
>> + EFI_PCI_COMMAND_MEMORY_SPACE))
> 
> I thought I asked you not to define a macro here that started with the
> "EFI_" prefix :/
> 
> dd8e3c9e-cb76-d3fe-6a10-c0a41c714b56@redhat.com">http://mid.mail-archive.com/dd8e3c9e-cb76-d3fe-6a10-c0a41c714b56@redhat.com
> 

This is a resend of v1 patch series to get Xen folks into CC and gather
comments. I expect v2.

Igor
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA Support

2019-03-06 Thread Ashish Singhal

Driver was supporting only 32b DMA support for V3 controllers. Add
support for 64b DMA as well for completeness.

For V4.0 64b support, driver was looking at incorrect capability
register bit. Fix for that is present as well.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1583
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ashish Singhal 
---
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c |  10 +-
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h |   6 +-
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c   | 189 ++---
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h   |  29 +++-
 4 files changed, 161 insertions(+), 73 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c 
b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
index b474f8d..9b7b88c 100644
--- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
+++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
@@ -6,7 +6,7 @@
 
   It would expose EFI_SD_MMC_PASS_THRU_PROTOCOL for upper layer use.
 
-  Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
+  Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
   Copyright (c) 2015 - 2019, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -666,8 +666,12 @@ SdMmcPciHcDriverBindingStart (
 // If any of the slots does not support 64b system bus
 // do not enable 64b DMA in the PCI layer.
 //
-if (Private->Capability[Slot].SysBus64V3 == 0 &&
-Private->Capability[Slot].SysBus64V4 == 0) {
+if ((Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_300 &&
+ Private->Capability[Slot].SysBus64V3 == 0) ||
+(Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_400 &&
+ Private->Capability[Slot].SysBus64V3 == 0) ||
+(Private->ControllerVersion[Slot] >= SD_MMC_HC_CTRL_VER_410 &&
+ Private->Capability[Slot].SysBus64V4 == 0)) {
   Support64BitDma = FALSE;
 }
 
diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h 
b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
index 1bb701a..8846fde 100644
--- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
+++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
@@ -2,7 +2,7 @@
 
   Provides some data structure definitions used by the SD/MMC host controller 
driver.
 
-Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
+Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
 Copyright (c) 2015, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
@@ -145,13 +145,15 @@ typedef struct {
   EFI_PHYSICAL_ADDRESSDataPhy;
   VOID*DataMap;
   SD_MMC_HC_TRANSFER_MODE Mode;
+  SD_MMC_HC_ADMA_LENGTH_MODE  AdmaLengthMode;
 
   EFI_EVENT   Event;
   BOOLEAN Started;
   UINT64  Timeout;
 
   SD_MMC_HC_ADMA_32_DESC_LINE *Adma32Desc;
-  SD_MMC_HC_ADMA_64_DESC_LINE *Adma64Desc;
+  SD_MMC_HC_ADMA_64_V3_DESC_LINE  *Adma64V3Desc;
+  SD_MMC_HC_ADMA_64_V4_DESC_LINE  *Adma64V4Desc;
   EFI_PHYSICAL_ADDRESSAdmaDescPhy;
   VOID*AdmaMap;
   UINT32  AdmaPages;
diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c 
b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
index d73fa10..6fefed1 100644
--- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
+++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
@@ -6,7 +6,7 @@
 
   It would expose EFI_SD_MMC_PASS_THRU_PROTOCOL for upper layer use.
 
-  Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
+  Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
   Copyright (c) 2015 - 2019, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -1010,16 +1010,28 @@ SdMmcHcInitV4Enhancements (
   if (ControllerVer >= SD_MMC_HC_CTRL_VER_400) {
 HostCtrl2 = SD_MMC_HC_V4_EN;
 //
-// Check if V4 64bit support is available
+// Check if controller version V4.0
 //
-if (Capability.SysBus64V4 != 0) {
-  HostCtrl2 |= SD_MMC_HC_64_ADDR_EN;
-  DEBUG ((DEBUG_INFO, "Enabled V4 64 bit system bus support\n"));
+if (ControllerVer == SD_MMC_HC_CTRL_VER_400) {
+  //
+  // Check if 64bit support is available
+  //
+  if (Capability.SysBus64V3 != 0) {
+HostCtrl2 |= SD_MMC_HC_64_ADDR_EN;
+DEBUG ((DEBUG_INFO, "Enabled V4 64 bit system bus support\n"));
+  }
 }
 //
 // Check if controller version V4.10 or higher
 //
-if (ControllerVer >= SD_MMC_HC_CTRL_VER_410)

Re: [edk2] Does ARM platform produce MP protocol?

2019-03-06 Thread Ard Biesheuvel

On Wed, 6 Mar 2019 at 13:41, Achin Gupta  wrote:
>
> On Wed, Mar 06, 2019 at 10:37:58AM +0100, Ard Biesheuvel wrote:
> > (adding Achin and Charles)
> >
> > On Wed, 6 Mar 2019 at 10:16, Ni, Ray  wrote:
> > >
> > > > -Original Message-
> > > > From: edk2-devel  On Behalf Of Ard
> > > > Biesheuvel
> > > > Sent: Wednesday, March 6, 2019 3:38 PM
> > > > To: Ni, Ray 
> > > > Cc: edk2-devel@lists.01.org
> > > > Subject: Re: [edk2] Does ARM platform produce MP protocol?
> > > >
> > > > On Wed, 6 Mar 2019 at 06:44, Ni, Ray  wrote:
> > > > >
> > > > > Ard, Leif,
> > > > > I am a bit interested in how ARM platform supports the MP?
> > > > > PI Spec defines below protocol but I failed to find a driver in ARM 
> > > > > platform
> > > > producing this protocol.
> > > > > Or did I miss anything?
> > > > >
> > > >
> > > > No you are right. We don't expose that on ARM, since UEFI only runs on a
> > > > single core. Bringing up and taking down cores is done via a protocol 
> > > > called
> > > > PSCI, which is implemented by firmware running at a higher privilege 
> > > > level.
> > > >
> > > > So while it would be possible to implement the MP protocol on top of 
> > > > PSCI,
> > > > we haven't identified a use case for it yet. (The OS calls PSCI 
> > > > directly to boot
> > > > the secondary cores)
>
> IIUC, the MP protocol enables communication between processors that are 
> already
> up instead of bringing them up or taking them down. So, it is orthogonal to
> PSCI. Is that what you meant?
>

Surely, StartupThisAP starts up the AP, no?

In any case, I didn't dig any deeper, but I know that PSCI can be used
(even in the UEFI context) to execute pieces of code on another core
(ACS uses this IIRC)

> > >
> > > Is below EFI_MM_MP_PROTOCOL (added in PI spec 1.6) implemented in ARM?
> > > Or will it be implemented by an ARM module?
> >
> > No it is currently not implemented, and I am not aware of any plans to do 
> > so.
>
> +1. There is no need to do this until UEFI runs on a single core on Arm.
>

until -> as long as ??

> >
> > > I am asking this because MP_SERVICES protocol exposes CPU location 
> > > information
> > > (Package/Core/Thread) through *GetProcessorInfo*, but MM_MP protocol 
> > > doesn't
> > > have a way to expose that information.
> > > If such location information isn't exposed by MM_MP, is that because ARM 
> > > doesn't
> > > care about the location information? Or because ARM cares but forgot to 
> > > add similar
> > > *GetProcessorInfo* interface to MM_MP when changing the PI spec?
> > > Or ARM doesn't use the MM_MP at all?
>
> Even if Arm used this protocol, it can work with the logical processor 
> number. I
> don't see a need to expose the location information to the caller. It seems 
> very
> Intel specific. Is the EFI_MP_SERVICES_PROTOCOL used on Arm?
>

No, that is what started the discussion.

> > >
> >
> > I don't know the history of this protocol and who proposed it, but
> > today, we don't have a need for running per-CPU initialization code in
> > the context of MM. Even if MM is a component of the more privileged
> > firmware running on an ARM system, it is running in a sandbox that was
> > primarily designed around exposing MM services to UEFI code running at
> > the same privilege level as the OS (such as the authenticated variable
> > store). Platform initialization code (which is more likely to require
> > dispatch to each core) runs in the secure world as well, but not in
> > the context of MM.
> >
> > I will let Achin chime in here as well.
>
> +1.
>
> I will let Charles comment on the history. Maybe this protocol was designed
> for Arm systems where MM is the most privileged firmware. The upstream
> implementation runs MM in the lowest privilege level. Either way, this 
> protocol
> sense only when MM on Arm is MP capable.
>
> cheers,
> Achin
>
>
> >
> >
> > > typedef struct _EFI_MM_MP_PROTOCOL {
> > > UINT32   Revision,
> > > UINT32   Attributes,
> > > EFI_MM_ GET_NUMBER_OF_PROCESSORS GetNumberOfProcessors,
> > > EFI_MM_DISPATCH_PROCEDUREDispatchProcedure,
> > > EFI_MM_BROADCAST_PROCEDURE   BroadcastProcedure,
> > > EFI_MM_SET_STARTUP_PROCEDURE SetStartupProcedure,
> > > EFI_CHECK_FOR_PROCEDURE  CheckOnProcedure,
> > > EFI_WAIT_FOR_PROCEDURE   WaitForProcedure,
> > > }EFI_MM_MP_PROTOCOL;
> > > >
> > > > > typedef struct _EFI_MP_SERVICES_PROTOCOL {
> > > > > EFI_MP_SERVICES_GET_NUMBER_OF_PROCESSORS
> > > > GetNumberOfProcessors;
> > > > > EFI_MP_SERVICES_GET_PROCESSOR_INFO GetProcessorInfo;
> > > > > EFI_MP_SERVICES_STARTUP_ALL_APS StartupAllAPs;
> > > > > EFI_MP_SERVICES_STARTUP_THIS_AP StartupThisAP;
> > > > > EFI_MP_SERVICES_SWITCH_BSP SwitchBSP;
> > > > EFI_MP_SERVICES_ENABLEDISABLEAP
> > > > > EnableDisableAP; EFI_MP_SERVICES_WHOAMI WhoAmI; }
> > > > > EFI_MP_SERVICES_PROTOCOL;
> > > > >
> > > > > Thanks,
> > > > > Ray
> > > >

Re: [edk2] [PATCH RESEND 3/3] OvmfPkg/XenSupport: turn off address decoding before BAR sizing

2019-03-06 Thread Laszlo Ersek

On 03/06/19 13:40, Igor Druzhinin wrote:
> On Xen, hvmloader firmware leaves address decoding enabled for
> enumerated PCI device before jumping into OVMF. OVMF seems to
> expect it to be disabled and tries to size PCI BARs in several places
> without disabling it which causes BAR64, for example, being
> incorrectly placed by QEMU.
> 
> Fix it by disabling PCI address decoding explicitly before the
> first attempt to size BARs on Xen.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Igor Druzhinin 
> ---
>  OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 34 
> +++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c 
> b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
> index 408fb24..9940335 100644
> --- a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
> +++ b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
> @@ -55,6 +55,33 @@ PcatPciRootBridgeBarExisted (
>EnableInterrupts ();
>  }
>  
> +#define EFI_PCI_COMMAND_DECODE ((UINT16)(EFI_PCI_COMMAND_IO_SPACE | \
> + EFI_PCI_COMMAND_MEMORY_SPACE))

I thought I asked you not to define a macro here that started with the
"EFI_" prefix :/

dd8e3c9e-cb76-d3fe-6a10-c0a41c714b56@redhat.com">http://mid.mail-archive.com/dd8e3c9e-cb76-d3fe-6a10-c0a41c714b56@redhat.com

Laszlo

> +STATIC
> +VOID
> +PcatPciRootBridgeDecoding (
> +  IN  UINTN  Address,
> +  IN  BOOLEANEnabled,
> +  OUT UINT16 *OriginalValue
> +  )
> +{
> +  UINT16Value;
> +
> +  //
> +  // Preserve the original value
> +  //
> +  Value = *OriginalValue;
> +  *OriginalValue = PciRead16 (Address);
> +
> +  if (!Enabled) {
> +if (*OriginalValue & EFI_PCI_COMMAND_DECODE)
> +   PciWrite16 (Address, *OriginalValue & ~EFI_PCI_COMMAND_DECODE);
> +  } else {
> +if (Value & EFI_PCI_COMMAND_DECODE)
> +  PciWrite16 (Address, Value);
> +  }
> +}
> +
>  STATIC
>  VOID
>  PcatPciRootBridgeParseBars (
> @@ -76,6 +103,7 @@ PcatPciRootBridgeParseBars (
>UINT32Value;
>UINT32OriginalUpperValue;
>UINT32UpperValue;
> +  UINT16OriginalCommand;
>UINT64Mask;
>UINTN Offset;
>UINT64Base;
> @@ -83,6 +111,12 @@ PcatPciRootBridgeParseBars (
>UINT64Limit;
>PCI_ROOT_BRIDGE_APERTURE  *MemAperture;
>  
> +  // Disable address decoding for every device before OVMF starts sizing it
> +  PcatPciRootBridgeDecoding (
> +PCI_LIB_ADDRESS (Bus, Device, Function, PCI_COMMAND_OFFSET),
> +FALSE, &OriginalCommand
> +  );
> +
>for (Offset = BarOffsetBase; Offset < BarOffsetEnd; Offset += sizeof 
> (UINT32)) {
>  PcatPciRootBridgeBarExisted (
>PCI_LIB_ADDRESS (Bus, Device, Function, Offset),
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Any open source EFI app to dump USB descriptors from Shell

2019-03-06 Thread galla rao

Hi All,

Am looking for an app in EFI, to dump USB descriptors
Any info on such utility, please educate

Regards
Ranga
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH RESEND 2/3] OvmfPkg/XenSupport: use a correct PCI host bridge aperture for BAR64

2019-03-06 Thread Igor Druzhinin

In case BAR64 is placed below 4G choose the correct aperture.
This fixes a failed assertion down the code path.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Igor Druzhinin 
---
 OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c 
b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
index c23c46d..408fb24 100644
--- a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
+++ b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
@@ -145,7 +145,11 @@ PcatPciRootBridgeParseBars (
   Length = Length | LShiftU64 ((UINT64) UpperValue, 32);
   Length = (~Length) + 1;
 
-  MemAperture = MemAbove4G;
+  if (Base < 0x1) {
+MemAperture = Mem;
+  } else {
+MemAperture = MemAbove4G;
+  }
 }
 
 Limit = Base + Length - 1;
-- 
2.7.4

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Does ARM platform produce MP protocol?

2019-03-06 Thread Achin Gupta

On Wed, Mar 06, 2019 at 10:37:58AM +0100, Ard Biesheuvel wrote:
> (adding Achin and Charles)
>
> On Wed, 6 Mar 2019 at 10:16, Ni, Ray  wrote:
> >
> > > -Original Message-
> > > From: edk2-devel  On Behalf Of Ard
> > > Biesheuvel
> > > Sent: Wednesday, March 6, 2019 3:38 PM
> > > To: Ni, Ray 
> > > Cc: edk2-devel@lists.01.org
> > > Subject: Re: [edk2] Does ARM platform produce MP protocol?
> > >
> > > On Wed, 6 Mar 2019 at 06:44, Ni, Ray  wrote:
> > > >
> > > > Ard, Leif,
> > > > I am a bit interested in how ARM platform supports the MP?
> > > > PI Spec defines below protocol but I failed to find a driver in ARM 
> > > > platform
> > > producing this protocol.
> > > > Or did I miss anything?
> > > >
> > >
> > > No you are right. We don't expose that on ARM, since UEFI only runs on a
> > > single core. Bringing up and taking down cores is done via a protocol 
> > > called
> > > PSCI, which is implemented by firmware running at a higher privilege 
> > > level.
> > >
> > > So while it would be possible to implement the MP protocol on top of PSCI,
> > > we haven't identified a use case for it yet. (The OS calls PSCI directly 
> > > to boot
> > > the secondary cores)

IIUC, the MP protocol enables communication between processors that are already
up instead of bringing them up or taking them down. So, it is orthogonal to
PSCI. Is that what you meant?

> >
> > Is below EFI_MM_MP_PROTOCOL (added in PI spec 1.6) implemented in ARM?
> > Or will it be implemented by an ARM module?
>
> No it is currently not implemented, and I am not aware of any plans to do so.

+1. There is no need to do this until UEFI runs on a single core on Arm.

>
> > I am asking this because MP_SERVICES protocol exposes CPU location 
> > information
> > (Package/Core/Thread) through *GetProcessorInfo*, but MM_MP protocol doesn't
> > have a way to expose that information.
> > If such location information isn't exposed by MM_MP, is that because ARM 
> > doesn't
> > care about the location information? Or because ARM cares but forgot to add 
> > similar
> > *GetProcessorInfo* interface to MM_MP when changing the PI spec?
> > Or ARM doesn't use the MM_MP at all?

Even if Arm used this protocol, it can work with the logical processor number. I
don't see a need to expose the location information to the caller. It seems very
Intel specific. Is the EFI_MP_SERVICES_PROTOCOL used on Arm?

> >
>
> I don't know the history of this protocol and who proposed it, but
> today, we don't have a need for running per-CPU initialization code in
> the context of MM. Even if MM is a component of the more privileged
> firmware running on an ARM system, it is running in a sandbox that was
> primarily designed around exposing MM services to UEFI code running at
> the same privilege level as the OS (such as the authenticated variable
> store). Platform initialization code (which is more likely to require
> dispatch to each core) runs in the secure world as well, but not in
> the context of MM.
>
> I will let Achin chime in here as well.

+1.

I will let Charles comment on the history. Maybe this protocol was designed
for Arm systems where MM is the most privileged firmware. The upstream
implementation runs MM in the lowest privilege level. Either way, this protocol
sense only when MM on Arm is MP capable.

cheers,
Achin


>
>
> > typedef struct _EFI_MM_MP_PROTOCOL {
> > UINT32   Revision,
> > UINT32   Attributes,
> > EFI_MM_ GET_NUMBER_OF_PROCESSORS GetNumberOfProcessors,
> > EFI_MM_DISPATCH_PROCEDUREDispatchProcedure,
> > EFI_MM_BROADCAST_PROCEDURE   BroadcastProcedure,
> > EFI_MM_SET_STARTUP_PROCEDURE SetStartupProcedure,
> > EFI_CHECK_FOR_PROCEDURE  CheckOnProcedure,
> > EFI_WAIT_FOR_PROCEDURE   WaitForProcedure,
> > }EFI_MM_MP_PROTOCOL;
> > >
> > > > typedef struct _EFI_MP_SERVICES_PROTOCOL {
> > > > EFI_MP_SERVICES_GET_NUMBER_OF_PROCESSORS
> > > GetNumberOfProcessors;
> > > > EFI_MP_SERVICES_GET_PROCESSOR_INFO GetProcessorInfo;
> > > > EFI_MP_SERVICES_STARTUP_ALL_APS StartupAllAPs;
> > > > EFI_MP_SERVICES_STARTUP_THIS_AP StartupThisAP;
> > > > EFI_MP_SERVICES_SWITCH_BSP SwitchBSP;
> > > EFI_MP_SERVICES_ENABLEDISABLEAP
> > > > EnableDisableAP; EFI_MP_SERVICES_WHOAMI WhoAmI; }
> > > > EFI_MP_SERVICES_PROTOCOL;
> > > >
> > > > Thanks,
> > > > Ray
> > > ___
> > > edk2-devel mailing list
> > > edk2-devel@lists.01.org
> > > https://lists.01.org/mailman/listinfo/edk2-devel
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
edk2-devel mailing list
edk2-devel@list

[edk2] [PATCH RESEND 0/3] Xen PCI passthrough fixes

2019-03-06 Thread Igor Druzhinin

Resend to include xen-de...@lists.xenproject.org to CC

Igor Druzhinin (3):
  OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge
aperture
  OvmfPkg/XenSupport: use a correct PCI host bridge aperture for BAR64
  OvmfPkg/XenSupport: turn off address decoding before BAR sizing

 OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 44 ++-
 1 file changed, 37 insertions(+), 7 deletions(-)

-- 
2.7.4

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH RESEND 3/3] OvmfPkg/XenSupport: turn off address decoding before BAR sizing

2019-03-06 Thread Igor Druzhinin

On Xen, hvmloader firmware leaves address decoding enabled for
enumerated PCI device before jumping into OVMF. OVMF seems to
expect it to be disabled and tries to size PCI BARs in several places
without disabling it which causes BAR64, for example, being
incorrectly placed by QEMU.

Fix it by disabling PCI address decoding explicitly before the
first attempt to size BARs on Xen.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Igor Druzhinin 
---
 OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 34 +++
 1 file changed, 34 insertions(+)

diff --git a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c 
b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
index 408fb24..9940335 100644
--- a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
+++ b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
@@ -55,6 +55,33 @@ PcatPciRootBridgeBarExisted (
   EnableInterrupts ();
 }
 
+#define EFI_PCI_COMMAND_DECODE ((UINT16)(EFI_PCI_COMMAND_IO_SPACE | \
+ EFI_PCI_COMMAND_MEMORY_SPACE))
+STATIC
+VOID
+PcatPciRootBridgeDecoding (
+  IN  UINTN  Address,
+  IN  BOOLEANEnabled,
+  OUT UINT16 *OriginalValue
+  )
+{
+  UINT16Value;
+
+  //
+  // Preserve the original value
+  //
+  Value = *OriginalValue;
+  *OriginalValue = PciRead16 (Address);
+
+  if (!Enabled) {
+if (*OriginalValue & EFI_PCI_COMMAND_DECODE)
+   PciWrite16 (Address, *OriginalValue & ~EFI_PCI_COMMAND_DECODE);
+  } else {
+if (Value & EFI_PCI_COMMAND_DECODE)
+  PciWrite16 (Address, Value);
+  }
+}
+
 STATIC
 VOID
 PcatPciRootBridgeParseBars (
@@ -76,6 +103,7 @@ PcatPciRootBridgeParseBars (
   UINT32Value;
   UINT32OriginalUpperValue;
   UINT32UpperValue;
+  UINT16OriginalCommand;
   UINT64Mask;
   UINTN Offset;
   UINT64Base;
@@ -83,6 +111,12 @@ PcatPciRootBridgeParseBars (
   UINT64Limit;
   PCI_ROOT_BRIDGE_APERTURE  *MemAperture;
 
+  // Disable address decoding for every device before OVMF starts sizing it
+  PcatPciRootBridgeDecoding (
+PCI_LIB_ADDRESS (Bus, Device, Function, PCI_COMMAND_OFFSET),
+FALSE, &OriginalCommand
+  );
+
   for (Offset = BarOffsetBase; Offset < BarOffsetEnd; Offset += sizeof 
(UINT32)) {
 PcatPciRootBridgeBarExisted (
   PCI_LIB_ADDRESS (Bus, Device, Function, Offset),
-- 
2.7.4

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH RESEND 1/3] OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge aperture

2019-03-06 Thread Igor Druzhinin

This aperture doesn't exist in OVMF and trying to use it causes
failing assertions later in cases there are prefetchable and
non-prefetchable BARs following each other. This configuration is
quite likely with some PCI passthrough devices.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Igor Druzhinin 
---
 OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c 
b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
index 9204179..c23c46d 100644
--- a/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
+++ b/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
@@ -129,11 +129,7 @@ PcatPciRootBridgeParseBars (
   //
   Length = ((~Length) + 1) & 0x;
 
-  if ((Value & BIT3) == BIT3) {
-MemAperture = PMem;
-  } else {
-MemAperture = Mem;
-  }
+  MemAperture = Mem;
 } else {
   //
   // 64bit
@@ -149,11 +145,7 @@ PcatPciRootBridgeParseBars (
   Length = Length | LShiftU64 ((UINT64) UpperValue, 32);
   Length = (~Length) + 1;
 
-  if ((Value & BIT3) == BIT3) {
-MemAperture = PMemAbove4G;
-  } else {
-MemAperture = MemAbove4G;
-  }
+  MemAperture = MemAbove4G;
 }
 
 Limit = Base + Length - 1;
-- 
2.7.4

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch V2 0/1] Document: Update FDF spec to remove EDK and IPF related contents

2019-03-06 Thread Feng, Bob C

V2:
Update the table of content and update history.
Update commit message and fixed a bug.

Feng, Bob C (1):
  Document: Update FDF spec to remove EDK and IPF related contents

 1_introduction/11_overview.md  
 |  22 +++---
 1_introduction/12_terms.md 
 |   8 +---
 1_introduction/README.md   
 |   9 ++---
 2_fdf_design_discussion/22_flash_description_file_format.md
 |  34 --
 2_fdf_design_discussion/24_[fd]_sections.md
 |   9 ++---
 2_fdf_design_discussion/25_[fv]_sections.md
 |   9 +++--
 2_fdf_design_discussion/{28_[rule]_sections.md => 27_[rule]_sections.md}   
 | 232 

 2_fdf_design_discussion/27_[vtf]_sections.md   
 |  82 
--
 2_fdf_design_discussion/{29_[optionrom]_sections.md => 
28_[optionrom]_sections.md}  | 112 

 2_fdf_design_discussion/README.md  
 |   2 --
 3_edk_ii_fdf_file_format/310_[vtf]_section.md  
 | 203 
---
 3_edk_ii_fdf_file_format/{311_pci_optionrom_section.md => 
310_pci_optionrom_section.md} | 228 
++--
 3_edk_ii_fdf_file_format/31_general_rules.md   
 |  13 +
 3_edk_ii_fdf_file_format/32_fdf_definition.md  
 |  67 
+--
 README.md  
 |   1 +
 SUMMARY.md 
 |   8 +++-
 appendix_a_nt32pkg_flash_description_file.md   
 |   4 ++--
 17 files changed, 321 insertions(+), 722 deletions(-)
 rename 2_fdf_design_discussion/{28_[rule]_sections.md => 
27_[rule]_sections.md} (95%)
 delete mode 100644 2_fdf_design_discussion/27_[vtf]_sections.md
 rename 2_fdf_design_discussion/{29_[optionrom]_sections.md => 
28_[optionrom]_sections.md} (94%)
 delete mode 100644 3_edk_ii_fdf_file_format/310_[vtf]_section.md
 rename 3_edk_ii_fdf_file_format/{311_pci_optionrom_section.md => 
310_pci_optionrom_section.md} (93%)

-- 
2.20.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch 1/1] Document: Update FDF spec to remove EDK and IPF related contents

2019-03-06 Thread Feng, Bob C

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

Remove EDK and IPF related contents inf Fdf spec.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng 
Cc: Liming Gao 
Cc: Jaben Carsey 
---
 1_introduction/11_overview.md  
 |  22 +++---
 1_introduction/12_terms.md 
 |   8 +---
 1_introduction/README.md   
 |   9 ++---
 2_fdf_design_discussion/22_flash_description_file_format.md
 |  34 --
 2_fdf_design_discussion/24_[fd]_sections.md
 |   9 ++---
 2_fdf_design_discussion/25_[fv]_sections.md
 |   9 +++--
 2_fdf_design_discussion/{28_[rule]_sections.md => 27_[rule]_sections.md}   
 | 232 

 2_fdf_design_discussion/27_[vtf]_sections.md   
 |  82 
--
 2_fdf_design_discussion/{29_[optionrom]_sections.md => 
28_[optionrom]_sections.md}  | 112 

 2_fdf_design_discussion/README.md  
 |   2 --
 3_edk_ii_fdf_file_format/310_[vtf]_section.md  
 | 203 
---
 3_edk_ii_fdf_file_format/{311_pci_optionrom_section.md => 
310_pci_optionrom_section.md} | 228 
++--
 3_edk_ii_fdf_file_format/31_general_rules.md   
 |  13 +
 3_edk_ii_fdf_file_format/32_fdf_definition.md  
 |  67 
+--
 README.md  
 |   1 +
 SUMMARY.md 
 |   8 +++-
 appendix_a_nt32pkg_flash_description_file.md   
 |   4 ++--
 17 files changed, 321 insertions(+), 722 deletions(-)

diff --git a/1_introduction/11_overview.md b/1_introduction/11_overview.md
index 6db8a26..d7dbb20 100644
--- a/1_introduction/11_overview.md
+++ b/1_introduction/11_overview.md
@@ -1,9 +1,9 @@
 
-
-## 2.8 [Rule] Sections
-
-The optional `[Rule]` sections in the FDF file are used for combining binary
-images, not for compiling code. Rules are use with the `[FV]` section's module
-INF type to define how an FFS file is created for a given INF file. The EDK II
-Build Specification defines the default rules that are implicitly used for
-creating FFS files. The implicit rules follow the _PI Specification_ and
-_UEFI Specification_.
-
-The `[Rule]` section of the FDF file is used to define custom rules, which may
-be applied to a given INF file listed in an `[FV]` section. This section is
-also used to define rules for module types that permit the user to define the
-content of the FFS file - when an FFS type is not specified by either PI or
-UEFI specifications.
-
-The Rules can have multiple modifiers as shown below.
-
-`[Rule.ARCH.MODULE_TYPE.TEMPLATE_NAME]`
-
-If no `TEMPLATE_NAME` is given then the match is based on `ARCH` and
-`MODULE_TYPE` modifiers. `BINARY` is a reserved `TEMPLATE_NAME` as a default 
rule
-name for binary modules. The `TEMPLATE_NAME` must be unique to the `ARCH` and
-`MODULE_TYPE`. It is permissible to use the same `TEMPLATE_NAME` for two or
-more `[Rule]` sections if the `ARCH` or the `MODULE_TYPE` listed are different
-for each of the sections.
-
-A `[Rule]` section is terminated by another section header or the end of file.
-
-The content of the `[Rule]` section is based on the `FILE` and section grammar
-of the FV section. The difference is the `FILE` referenced in the `[RULE]` is a
-`MACRO`. The section grammar is extended to include an optional argument,
-`Optional`. The `Optional` argument is used to say a section is optional. That
-is to say, if it does not exist, then it is O.K.
-
-**
-**Note:** The `!include` statement is valid for any part of the

Re: [edk2] Does ARM platform produce MP protocol?

2019-03-06 Thread Ard Biesheuvel

(adding Achin and Charles)

On Wed, 6 Mar 2019 at 10:16, Ni, Ray  wrote:
>
> > -Original Message-
> > From: edk2-devel  On Behalf Of Ard
> > Biesheuvel
> > Sent: Wednesday, March 6, 2019 3:38 PM
> > To: Ni, Ray 
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [edk2] Does ARM platform produce MP protocol?
> >
> > On Wed, 6 Mar 2019 at 06:44, Ni, Ray  wrote:
> > >
> > > Ard, Leif,
> > > I am a bit interested in how ARM platform supports the MP?
> > > PI Spec defines below protocol but I failed to find a driver in ARM 
> > > platform
> > producing this protocol.
> > > Or did I miss anything?
> > >
> >
> > No you are right. We don't expose that on ARM, since UEFI only runs on a
> > single core. Bringing up and taking down cores is done via a protocol called
> > PSCI, which is implemented by firmware running at a higher privilege level.
> >
> > So while it would be possible to implement the MP protocol on top of PSCI,
> > we haven't identified a use case for it yet. (The OS calls PSCI directly to 
> > boot
> > the secondary cores)
>
> Is below EFI_MM_MP_PROTOCOL (added in PI spec 1.6) implemented in ARM?
> Or will it be implemented by an ARM module?

No it is currently not implemented, and I am not aware of any plans to do so.

> I am asking this because MP_SERVICES protocol exposes CPU location information
> (Package/Core/Thread) through *GetProcessorInfo*, but MM_MP protocol doesn't
> have a way to expose that information.
> If such location information isn't exposed by MM_MP, is that because ARM 
> doesn't
> care about the location information? Or because ARM cares but forgot to add 
> similar
> *GetProcessorInfo* interface to MM_MP when changing the PI spec?
> Or ARM doesn't use the MM_MP at all?
>

I don't know the history of this protocol and who proposed it, but
today, we don't have a need for running per-CPU initialization code in
the context of MM. Even if MM is a component of the more privileged
firmware running on an ARM system, it is running in a sandbox that was
primarily designed around exposing MM services to UEFI code running at
the same privilege level as the OS (such as the authenticated variable
store). Platform initialization code (which is more likely to require
dispatch to each core) runs in the secure world as well, but not in
the context of MM.

I will let Achin chime in here as well.


> typedef struct _EFI_MM_MP_PROTOCOL {
> UINT32   Revision,
> UINT32   Attributes,
> EFI_MM_ GET_NUMBER_OF_PROCESSORS GetNumberOfProcessors,
> EFI_MM_DISPATCH_PROCEDUREDispatchProcedure,
> EFI_MM_BROADCAST_PROCEDURE   BroadcastProcedure,
> EFI_MM_SET_STARTUP_PROCEDURE SetStartupProcedure,
> EFI_CHECK_FOR_PROCEDURE  CheckOnProcedure,
> EFI_WAIT_FOR_PROCEDURE   WaitForProcedure,
> }EFI_MM_MP_PROTOCOL;
> >
> > > typedef struct _EFI_MP_SERVICES_PROTOCOL {
> > > EFI_MP_SERVICES_GET_NUMBER_OF_PROCESSORS
> > GetNumberOfProcessors;
> > > EFI_MP_SERVICES_GET_PROCESSOR_INFO GetProcessorInfo;
> > > EFI_MP_SERVICES_STARTUP_ALL_APS StartupAllAPs;
> > > EFI_MP_SERVICES_STARTUP_THIS_AP StartupThisAP;
> > > EFI_MP_SERVICES_SWITCH_BSP SwitchBSP;
> > EFI_MP_SERVICES_ENABLEDISABLEAP
> > > EnableDisableAP; EFI_MP_SERVICES_WHOAMI WhoAmI; }
> > > EFI_MP_SERVICES_PROTOCOL;
> > >
> > > Thanks,
> > > Ray
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch V2 1/1] Document: Update DSC spec to remove EDK and IPF related contents

2019-03-06 Thread Feng, Bob C

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

Remove EDK and IPF related contents inf Dsc spec.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng 
Cc: Liming Gao 
Cc: Jaben Carsey 
---
 1_introduction/11_overview.md  
 | 14 --
 2_dsc_overview/{211_[components]_section_processing.md => 
210_[components]_section_processing.md}   | 27 +--
 2_dsc_overview/{212_[userextensions]_section.md => 
211_[userextensions]_section.md} |  4 ++--
 2_dsc_overview/{213_[defaultstores]_section_processing.md => 
212_[defaultstores]_section_processing.md} |  4 ++--
 2_dsc_overview/22_build_description_file_format.md 
 | 50 ++
 2_dsc_overview/23_[defines]_section_processing.md  
 | 12 +++-
 2_dsc_overview/24_[buildoptions]_section.md
 | 72 
+++-
 2_dsc_overview/26_[libraries]_section_processing.md
 | 69 
-
 2_dsc_overview/{27_[libraryclasses]_section_processing.md => 
26_[libraryclasses]_section_processing.md} |  4 ++--
 2_dsc_overview/{28_pcd_section_processing.md => 27_pcd_section_processing.md}  
 | 34 +-
 2_dsc_overview/{29_pcd_sections.md => 28_pcd_sections.md}  
 | 26 +-
 2_dsc_overview/{210_pcd_database.md => 29_pcd_database.md} 
 |  4 ++--
 3_edk_ii_dsc_file_format/{311_[components]_sections.md => 
310_[components]_sections.md} | 62 
+-
 3_edk_ii_dsc_file_format/{312_[userextensions]_sections.md => 
311_[userextensions]_sections.md} |  4 ++--
 3_edk_ii_dsc_file_format/{313_[defaultstores]_section.md => 
312_[defaultstores]_section.md} |  4 ++--
 3_edk_ii_dsc_file_format/32_general_rules.md   
 | 13 +
 3_edk_ii_dsc_file_format/33_platform_dsc_definition.md 
 | 17 +
 3_edk_ii_dsc_file_format/35_[defines]_section.md   
 | 12 +---
 3_edk_ii_dsc_file_format/36_[buildoptions]_sections.md 
 | 19 +--
 3_edk_ii_dsc_file_format/38_[libraries]_sections.md
 | 94 
--
 3_edk_ii_dsc_file_format/{39_[libraryclasses]_sections.md => 
38_[libraryclasses]_sections.md}   |  4 ++--
 3_edk_ii_dsc_file_format/{310_pcd_sections.md => 39_pcd_sections.md}   
 | 14 +++---
 README.md  
 |  1 +
 SUMMARY.md 
 | 26 --
 24 files changed, 114 insertions(+), 476 deletions(-)

diff --git a/1_introduction/11_overview.md b/1_introduction/11_overview.md
index d9006df..ff2b517 100644
--- a/1_introduction/11_overview.md
+++ b/1_introduction/11_overview.md
@@ -1,9 +1,9 @@
 
 
-## 2.11 [Components] Section Processing
+## 2.10 [Components] Section Processing
 
-One or more `[Components]` sections contain lists of EDK components and EDK II
-Modules. The format for specifying the INF file for EDK II modules incorporates
-new scoping capabilities.
+One or more `[Components]` sections contain lists of EDK II Modules. The 
format 
+for specifying the INF file for EDK II modules incorporates new scoping 
capabilities.
 
 This section uses one or more of the following section definitions:
 
 * `[Components]`
 * `[Components.IA32]`
 * `[Components.X64]`
 * `[Components.EBC]`
 * `[Components.common]`
 
-EDK components are specified using a fully qualified path to the EDK INF file.
-
-`$(EDK_SOURCE)/Path/and/Filename.inf`
-
-Because EDK II modules have different requirements than EDK I components,
-specifying the INF filename in the extended DSC file may require more than just
-the INF filename and options. A scoping structure, that binds library class
+A scoping structure, that binds library class
 (with an optional override instance,) PCD settings (also overriding the values
 specified in the `[PcdsPatchableInModule]` or `[PcdsFixedAtBuild]` sections)
 and build options for an EDK II module may be r

[edk2] [Patch V2 0/1] Document: Update DSC spec to remove EDK and IPF related contents

2019-03-06 Thread Feng, Bob C

V2:
Update the table of contents and the update history.

Feng, Bob C (1):
  Document: Update DSC spec to remove EDK and IPF related contents

 1_introduction/11_overview.md  
 | 14 --
 2_dsc_overview/{211_[components]_section_processing.md => 
210_[components]_section_processing.md}   | 27 +--
 2_dsc_overview/{212_[userextensions]_section.md => 
211_[userextensions]_section.md} |  4 ++--
 2_dsc_overview/{213_[defaultstores]_section_processing.md => 
212_[defaultstores]_section_processing.md} |  4 ++--
 2_dsc_overview/22_build_description_file_format.md 
 | 50 ++
 2_dsc_overview/23_[defines]_section_processing.md  
 | 12 +++-
 2_dsc_overview/24_[buildoptions]_section.md
 | 72 
+++-
 2_dsc_overview/26_[libraries]_section_processing.md
 | 69 
-
 2_dsc_overview/{27_[libraryclasses]_section_processing.md => 
26_[libraryclasses]_section_processing.md} |  4 ++--
 2_dsc_overview/{28_pcd_section_processing.md => 27_pcd_section_processing.md}  
 | 34 +-
 2_dsc_overview/{29_pcd_sections.md => 28_pcd_sections.md}  
 | 26 +-
 2_dsc_overview/{210_pcd_database.md => 29_pcd_database.md} 
 |  4 ++--
 3_edk_ii_dsc_file_format/{311_[components]_sections.md => 
310_[components]_sections.md} | 62 
+-
 3_edk_ii_dsc_file_format/{312_[userextensions]_sections.md => 
311_[userextensions]_sections.md} |  4 ++--
 3_edk_ii_dsc_file_format/{313_[defaultstores]_section.md => 
312_[defaultstores]_section.md} |  4 ++--
 3_edk_ii_dsc_file_format/32_general_rules.md   
 | 13 +
 3_edk_ii_dsc_file_format/33_platform_dsc_definition.md 
 | 17 +
 3_edk_ii_dsc_file_format/35_[defines]_section.md   
 | 12 +---
 3_edk_ii_dsc_file_format/36_[buildoptions]_sections.md 
 | 19 +--
 3_edk_ii_dsc_file_format/38_[libraries]_sections.md
 | 94 
--
 3_edk_ii_dsc_file_format/{39_[libraryclasses]_sections.md => 
38_[libraryclasses]_sections.md}   |  4 ++--
 3_edk_ii_dsc_file_format/{310_pcd_sections.md => 39_pcd_sections.md}   
 | 14 +++---
 README.md  
 |  1 +
 SUMMARY.md 
 | 26 --
 24 files changed, 114 insertions(+), 476 deletions(-)
 rename 2_dsc_overview/{211_[components]_section_processing.md => 
210_[components]_section_processing.md} (84%)
 rename 2_dsc_overview/{212_[userextensions]_section.md => 
211_[userextensions]_section.md} (93%)
 rename 2_dsc_overview/{213_[defaultstores]_section_processing.md => 
212_[defaultstores]_section_processing.md} (93%)
 delete mode 100644 2_dsc_overview/26_[libraries]_section_processing.md
 rename 2_dsc_overview/{27_[libraryclasses]_section_processing.md => 
26_[libraryclasses]_section_processing.md} (96%)
 rename 2_dsc_overview/{28_pcd_section_processing.md => 
27_pcd_section_processing.md} (94%)
 rename 2_dsc_overview/{29_pcd_sections.md => 28_pcd_sections.md} (93%)
 rename 2_dsc_overview/{210_pcd_database.md => 29_pcd_database.md} (96%)
 rename 3_edk_ii_dsc_file_format/{311_[components]_sections.md => 
310_[components]_sections.md} (81%)
 rename 3_edk_ii_dsc_file_format/{312_[userextensions]_sections.md => 
311_[userextensions]_sections.md} (94%)
 rename 3_edk_ii_dsc_file_format/{313_[defaultstores]_section.md => 
312_[defaultstores]_section.md} (93%)
 delete mode 100644 3_edk_ii_dsc_file_format/38_[libraries]_sections.md
 rename 3_edk_ii_dsc_file_format/{39_[libraryclasses]_sections.md => 
38_[libraryclasses]_sections.md} (95%)
 rename 3_edk_ii_dsc_file_format/{310_pcd_sections.md => 39_pcd_sections.md} 
(97%)

-- 
2.20.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Does ARM platform produce MP protocol?

2019-03-06 Thread Ni, Ray

> -Original Message-
> From: edk2-devel  On Behalf Of Ard
> Biesheuvel
> Sent: Wednesday, March 6, 2019 3:38 PM
> To: Ni, Ray 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] Does ARM platform produce MP protocol?
> 
> On Wed, 6 Mar 2019 at 06:44, Ni, Ray  wrote:
> >
> > Ard, Leif,
> > I am a bit interested in how ARM platform supports the MP?
> > PI Spec defines below protocol but I failed to find a driver in ARM platform
> producing this protocol.
> > Or did I miss anything?
> >
> 
> No you are right. We don't expose that on ARM, since UEFI only runs on a
> single core. Bringing up and taking down cores is done via a protocol called
> PSCI, which is implemented by firmware running at a higher privilege level.
> 
> So while it would be possible to implement the MP protocol on top of PSCI,
> we haven't identified a use case for it yet. (The OS calls PSCI directly to 
> boot
> the secondary cores)

Is below EFI_MM_MP_PROTOCOL (added in PI spec 1.6) implemented in ARM?
Or will it be implemented by an ARM module?
I am asking this because MP_SERVICES protocol exposes CPU location information
(Package/Core/Thread) through *GetProcessorInfo*, but MM_MP protocol doesn't
have a way to expose that information.
If such location information isn't exposed by MM_MP, is that because ARM doesn't
care about the location information? Or because ARM cares but forgot to add 
similar
*GetProcessorInfo* interface to MM_MP when changing the PI spec?
Or ARM doesn't use the MM_MP at all?

typedef struct _EFI_MM_MP_PROTOCOL {
UINT32   Revision,
UINT32   Attributes,
EFI_MM_ GET_NUMBER_OF_PROCESSORS GetNumberOfProcessors,
EFI_MM_DISPATCH_PROCEDUREDispatchProcedure,
EFI_MM_BROADCAST_PROCEDURE   BroadcastProcedure,
EFI_MM_SET_STARTUP_PROCEDURE SetStartupProcedure,
EFI_CHECK_FOR_PROCEDURE  CheckOnProcedure,
EFI_WAIT_FOR_PROCEDURE   WaitForProcedure,
}EFI_MM_MP_PROTOCOL;
> 
> > typedef struct _EFI_MP_SERVICES_PROTOCOL {
> > EFI_MP_SERVICES_GET_NUMBER_OF_PROCESSORS
> GetNumberOfProcessors;
> > EFI_MP_SERVICES_GET_PROCESSOR_INFO GetProcessorInfo;
> > EFI_MP_SERVICES_STARTUP_ALL_APS StartupAllAPs;
> > EFI_MP_SERVICES_STARTUP_THIS_AP StartupThisAP;
> > EFI_MP_SERVICES_SWITCH_BSP SwitchBSP;
> EFI_MP_SERVICES_ENABLEDISABLEAP
> > EnableDisableAP; EFI_MP_SERVICES_WHOAMI WhoAmI; }
> > EFI_MP_SERVICES_PROTOCOL;
> >
> > Thanks,
> > Ray
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch V2 1/1] Document: Update Inf spec to remove EDK and IPF related contents

2019-03-06 Thread Feng, Bob C

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

Remove EDK and IPF related contents

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng 
Cc: Liming Gao 
Cc: Jaben Carsey 
---
 1_introduction/11_overview.md  
  |   4 ++--
 2_inf_overview/210_[ppis]_section.md   
  |   3 +--
 2_inf_overview/211_[guids]_section.md  
  |   3 +--
 2_inf_overview/212_[libraryclasses]_section.md 
  |   3 +--
 2_inf_overview/213_[packages]_section.md   
  |   3 +--
 2_inf_overview/214_pcd_sections.md 
  |  16 +---
 2_inf_overview/215_[depex]_section.md  
  |   6 +-
 2_inf_overview/21_processing_overview.md   
  |  21 +
 2_inf_overview/22_information_file_general_rules.md
  |  32 +++-
 2_inf_overview/24_[defines]_section.md 
  |   6 +++---
 2_inf_overview/25_[sources]_section.md 
  |   6 +-
 2_inf_overview/26_[buildoptions]_section.md
  |  11 ++-
 2_inf_overview/27_[binaries]_section.md
  |   7 +--
 2_inf_overview/29_[protocols]_section.md   
  |   3 +--
 2_inf_overview/README.md   
  |  13 +
 3_edk_ii_inf_file_format/314_[depex]_sections.md   
  |   8 +++-
 3_edk_ii_inf_file_format/315_[binaries]_section.md 
  |   7 +--
 3_edk_ii_inf_file_format/32_component_inf_definition.md
  |   6 +++---
 3_edk_ii_inf_file_format/34_[defines]_section.md   
  |   8 ++--
 3_edk_ii_inf_file_format/35_[buildoptions]_sections.md 
  |   7 +++
 3_edk_ii_inf_file_format/39_[sources]_sections.md  
  |   9 ++---
 3_edk_ii_inf_file_format/README.md 
  |   6 +-
 README.md  
  |   3 ++-
 SUMMARY.md 
  |  37 +
 appendix_b_build_changes_and_customizations.md => 
appendix_a_build_changes_and_customizations.md |  10 +-
 appendix_a_edk_inf_file_specification/README.md
  |  40 
 appendix_a_edk_inf_file_specification/a1_design_discussion.md  
  | 317 
-
 appendix_a_edk_inf_file_specification/a2_edk_file_specification.md 
  | 461 
-
 appendix_c_symbols.md => appendix_b_symbols.md 
  |   4 ++--
 appendix_d_sample_driver_inf_files.md => appendix_c_sample_driver_inf_files.md 
  |   8 
 appendix_e_sample_library_inf_files.md => 
appendix_d_sample_library_inf_files.md |  10 +-
 appendix_f_sample_binary_inf_files.md => appendix_e_sample_binary_inf_files.md 
  |   8 
 appendix_g_module_types.md => appendix_f_module_types.md   
  |   4 ++--
 33 files changed, 93 insertions(+), 997 deletions(-)

diff --git a/1_introduction/11_overview.md b/1_introduction/11_overview.md
index 9239080..2dcf02f 100644
--- a/1_introduction/11_overview.md

[edk2] [Patch V2 0/1] Document: Update Inf spec to remove EDK and IPF related contents

2019-03-06 Thread Feng, Bob C

V2:
Update the table of content and update history.
Update commit message and fixed a bug.

Feng, Bob C (1):
  Document: Update Inf spec to remove EDK related contents

 1_introduction/11_overview.md  
  |   4 ++--
 2_inf_overview/210_[ppis]_section.md   
  |   3 +--
 2_inf_overview/211_[guids]_section.md  
  |   3 +--
 2_inf_overview/212_[libraryclasses]_section.md 
  |   3 +--
 2_inf_overview/213_[packages]_section.md   
  |   3 +--
 2_inf_overview/214_pcd_sections.md 
  |  16 +---
 2_inf_overview/215_[depex]_section.md  
  |   6 +-
 2_inf_overview/21_processing_overview.md   
  |  21 +
 2_inf_overview/22_information_file_general_rules.md
  |  32 +++-
 2_inf_overview/24_[defines]_section.md 
  |   6 +++---
 2_inf_overview/25_[sources]_section.md 
  |   6 +-
 2_inf_overview/26_[buildoptions]_section.md
  |  11 ++-
 2_inf_overview/27_[binaries]_section.md
  |   7 +--
 2_inf_overview/29_[protocols]_section.md   
  |   3 +--
 2_inf_overview/README.md   
  |  13 +
 3_edk_ii_inf_file_format/314_[depex]_sections.md   
  |   8 +++-
 3_edk_ii_inf_file_format/315_[binaries]_section.md 
  |   7 +--
 3_edk_ii_inf_file_format/32_component_inf_definition.md
  |   6 +++---
 3_edk_ii_inf_file_format/34_[defines]_section.md   
  |   8 ++--
 3_edk_ii_inf_file_format/35_[buildoptions]_sections.md 
  |   7 +++
 3_edk_ii_inf_file_format/39_[sources]_sections.md  
  |   9 ++---
 3_edk_ii_inf_file_format/README.md 
  |   6 +-
 README.md  
  |   3 ++-
 SUMMARY.md 
  |  37 +
 appendix_b_build_changes_and_customizations.md => 
appendix_a_build_changes_and_customizations.md |  10 +-
 appendix_a_edk_inf_file_specification/README.md
  |  40 
 appendix_a_edk_inf_file_specification/a1_design_discussion.md  
  | 317 
-
 appendix_a_edk_inf_file_specification/a2_edk_file_specification.md 
  | 461 
-
 appendix_c_symbols.md => appendix_b_symbols.md 
  |   4 ++--
 appendix_d_sample_driver_inf_files.md => appendix_c_sample_driver_inf_files.md 
  |   8 
 appendix_e_sample_library_inf_files.md => 
appendix_d_sample_library_inf_files.md |  10 +-
 appendix_f_sample_binary_inf_files.md => appendix_e_sample_binary_inf_files.md 
  |   8 
 appendix_g_module_types.md => appendix_f_module_types.md   
  |   4 ++--
 33 files changed, 93 insertions(+), 997 deletions(-)
 rename appendix_b_build_changes_and_customizations.md => 
appendix_a_build_changes_and_customizations.md (91%)
 delete mode 100644 appendix_a_edk_inf_file_specification/README.md
 delet

Re: [edk2] [Patch] Document: Update Inf spec to remove EDK related contents

2019-03-06 Thread Feng, Bob C

Hi Liming,

I'll update patch for 1) and 2)

For 3)
This patch removed "and are valid for EDK-II modules only."  Because I think 
there is only EDK-II now, we don't need to point out this section is for EDKII 
ONLY here.

Thanks,
Bob
-Original Message-
From: Gao, Liming 
Sent: Wednesday, March 6, 2019 4:02 PM
To: Feng, Bob C ; edk2-devel@lists.01.org
Cc: Carsey, Jaben 
Subject: RE: [edk2] [Patch] Document: Update Inf spec to remove EDK related 
contents

Bob:
  I have some comments. 

1) Please update the commit message. The change is to remove EDK and IPF 
related contents. 
2) The below change should make sure the updated one keep the same alignment. 
-||-
+||
3) Below content is correct. It is for EDKII. No need to change it. 
-These sections are used for specifying PCD information and are valid for EDK
-II modules only. The entries for these sections are looked up from the package
-declaration files (DEC) for generating the `AutoGen.c` and `AutoGen.h` files.
+These sections are used for specifying PCD information. The entries for these 
+sections are looked up from the packagedeclaration files (DEC) for generating 
+the `AutoGen.c` and `AutoGen.h` files.

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Feng, 
> Bob C
> Sent: Monday, March 4, 2019 5:52 AM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Gao, Liming 
> Subject: [edk2] [Patch] Document: Update Inf spec to remove EDK related 
> contents
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1453
> 
> Remove EDK related contents
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Bob Feng 
> Cc: Liming Gao 
> Cc: Jaben Carsey 
> ---
>  1_introduction/11_overview.md |   2 +-
>  2_inf_overview/210_[ppis]_section.md  |   1 -
>  2_inf_overview/211_[guids]_section.md |   1 -
>  .../212_[libraryclasses]_section.md   |   1 -
>  2_inf_overview/213_[packages]_section.md  |   1 -
>  2_inf_overview/214_pcd_sections.md|  14 +-
>  2_inf_overview/215_[depex]_section.md |   4 -
>  2_inf_overview/21_processing_overview.md  |  19 +-
>  .../22_information_file_general_rules.md  |  30 +-
>  2_inf_overview/24_[defines]_section.md|   4 +-
>  2_inf_overview/25_[sources]_section.md|   4 -
>  2_inf_overview/26_[buildoptions]_section.md   |   9 +-
>  2_inf_overview/27_[binaries]_section.md   |   5 -
>  2_inf_overview/29_[protocols]_section.md  |   1 -
>  2_inf_overview/README.md  |  11 -
>  .../314_[depex]_sections.md   |   6 +-
>  .../315_[binaries]_section.md |   5 -
>  .../32_component_inf_definition.md|   4 +-
>  .../34_[defines]_section.md   |   6 +-
>  .../35_[buildoptions]_sections.md |   5 +-
>  .../39_[sources]_sections.md  |   7 +-
>  3_edk_ii_inf_file_format/README.md|   4 -
>  ...ndix_a_build_changes_and_customizations.md |   0
>  .../README.md |  40 --
>  .../a1_design_discussion.md   | 317 
>  .../a2_edk_file_specification.md  | 461 --
>  ...ndix_c_symbols.md => appendix_b_symbols.md |   0
>  ...d => appendix_c_sample_driver_inf_files.md |   0
>  ... => appendix_d_sample_library_inf_files.md |   0
>  ...d => appendix_e_sample_binary_inf_files.md |   0
>  ...ule_types.md => appendix_f_module_types.md |   0
>  31 files changed, 30 insertions(+), 932 deletions(-)
>  rename appendix_b_build_changes_and_customizations.md => 
> appendix_a_build_changes_and_customizations.md (100%)
>  delete mode 100644 appendix_a_edk_inf_file_specification/README.md
>  delete mode 100644 
> appendix_a_edk_inf_file_specification/a1_design_discussion.md
>  delete mode 100644 
> appendix_a_edk_inf_file_specification/a2_edk_file_specification.md
>  rename appendix_c_symbols.md => appendix_b_symbols.md (100%)
>  rename appendix_d_sample_driver_inf_files.md => 
> appendix_c_sample_driver_inf_files.md (100%)
>  rename appendix_e_sample_library_inf_files.md => 
> appendix_d_sample_library_inf_files.md (100%)
>  rename appendix_f_sample_binary_inf_files.md => 
> appendix_e_sample_binary_inf_files.md (100%)
>  rename appendix_g_module_types.md => appendix_f_module_types.md (100%)
> 
> diff --git a/1_introduction/11_overview.md b/1_introduction/11_overview.md
> index 9239080..7349614 100644
> --- a/1_introduction/11_overview.md
> +++ b/1_introduction/11_overview.md
> @@ -40,11 +40,11 @@ Backward compatibility with the existing INF file 
> formats. Changes made to this
>  specification must not require changes to existing INF files.
> 
>  **Simplified platform build and configuration**
> 
>  Simplify the build setup and configuration for a given platform. The process 
> of
> -adding EDK and EDK II firmware components to a firmwa

Re: [edk2] [Patch] Document: Add PCD flexible format value EBNF in Fdf.

2019-03-06 Thread Gao, Liming

Reviewed-by: Liming Gao 

> -Original Message-
> From: Feng, Bob C
> Sent: Tuesday, March 5, 2019 12:16 AM
> To: edk2-devel@lists.01.org
> Cc: Feng, Bob C ; Gao, Liming ; 
> Zhu, Yonghong 
> Subject: [Patch] Document: Add PCD flexible format value EBNF in Fdf.
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=541
> 
> This patch is to add flexible PCD value format EBNF into Fdf spec.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Bob Feng 
> Cc: Liming Gao 
> Cc: Yonghong Zhu 
> ---
>  3_edk_ii_fdf_file_format/32_fdf_definition.md | 25 ---
>  3_edk_ii_fdf_file_format/35_[fd]_sections.md  |  4 +--
>  3_edk_ii_fdf_file_format/36_[fv]_sections.md  |  4 +--
>  .../37_[capsule]_sections.md  |  4 +--
>  4 files changed, 27 insertions(+), 10 deletions(-)
> 
> diff --git a/3_edk_ii_fdf_file_format/32_fdf_definition.md 
> b/3_edk_ii_fdf_file_format/32_fdf_definition.md
> index db098cf..2b044ab 100644
> --- a/3_edk_ii_fdf_file_format/32_fdf_definition.md
> +++ b/3_edk_ii_fdf_file_format/32_fdf_definition.md
> @@ -1,9 +1,9 @@
>   2.20.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch V2 0/1] Document: Update Build spec to remove EDK related

2019-03-06 Thread Gao, Liming

Bob:
  Please ignore the previous comments. For build spec change, I have only one 
comment to update the commit message to remove EDK and IPF contents. With this 
change, Reviewed-by: Liming Gao 

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao, 
> Liming
> Sent: Wednesday, March 6, 2019 12:29 AM
> To: Feng, Bob C ; edk2-devel@lists.01.org
> Subject: Re: [edk2] [Patch V2 0/1] Document: Update Build spec to remove EDK 
> related
> 
> 1.  2.12 [UserExtensions] Section and ## 2.11 [UserExtensions] Section are 
> inconsistent. There are the similar issue in this patch. Please
> check them to make sure they are same.
> 
> Thanks
> Liming
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> > Feng, Bob C
> > Sent: Tuesday, March 5, 2019 11:49 PM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] [Patch V2 0/1] Document: Update Build spec to remove EDK 
> > related
> >
> > V2:
> > Update the top level README to add the update history.
> >
> > Feng, Bob C (1):
> >   Document: Update Build spec to remove EDK related contents
> >
> >  10_post-build_imagegen_stage_-_flash/103_build_intermediate_images.md |  3 
> > +--
> >  12_build_changes_and_customizations/README.md |  4 
> > ++--
> >  4_edk_ii_build_process_overview/42_build_process_overview.md  |  6 
> > ++
> >  4_edk_ii_build_process_overview/46_file_specifications.md | 20 
> > +---
> >  6_quick_start/61_environment_variables.md | 24 
> > +---
> >  8_pre-build_autogen_stage/82_auto-generation_process.md   | 76
> > +++-
> >  8_pre-build_autogen_stage/83_auto-generated_code.md   | 43 
> > +++
> >  8_pre-build_autogen_stage/85_auto-generated_makefiles.md  | 23 
> > +--
> >  9_build_or_make_stage/README.md   |  9 
> > -
> >  README.md |  1 
> > +
> >  appendix_a_variables.md   |  3 
> > +--
> >  11 files changed, 44 insertions(+), 168 deletions(-)
> >
> > --
> > 2.20.1.windows.1
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] Document: Update DSC spec to remove EDK related contents

2019-03-06 Thread Gao, Liming



1. 2.12 [UserExtensions] Section and ## 2.11 [UserExtensions] Section are 
inconsistent. There are the similar issue in this patch. Please check them to 
make sure they are same.
2. Update commit message for EDK and IPF both. 

> -Original Message-
> From: Feng, Bob C
> Sent: Monday, March 4, 2019 7:49 PM
> To: edk2-devel@lists.01.org
> Cc: Feng, Bob C ; Gao, Liming ; 
> Carsey, Jaben 
> Subject: [Patch] Document: Update DSC spec to remove EDK related contents
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1453
> 
> Remove EDK related contents inf Dsc spec.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Bob Feng 
> Cc: Liming Gao 
> Cc: Jaben Carsey 
> ---
>  1_introduction/11_overview.md | 14 +--
>  ...=> 210_[components]_section_processing.md} | 27 +-
>  ...ion.md => 211_[userextensions]_section.md} |  4 +-
>  ...212_[defaultstores]_section_processing.md} |  4 +-
>  .../22_build_description_file_format.md   | 50 ++
>  .../23_[defines]_section_processing.md| 12 +--
>  2_dsc_overview/24_[buildoptions]_section.md   | 72 ++
>  .../26_[libraries]_section_processing.md  | 69 --
>  ...26_[libraryclasses]_section_processing.md} |  4 +-
>  ...essing.md => 27_pcd_section_processing.md} | 34 +++
>  ...{29_pcd_sections.md => 28_pcd_sections.md} | 26 ++---
>  ...210_pcd_database.md => 29_pcd_database.md} |  4 +-
>  ...ctions.md => 310_[components]_sections.md} | 62 +---
>  ...ns.md => 311_[userextensions]_sections.md} |  4 +-
>  ...tion.md => 312_[defaultstores]_section.md} |  4 +-
>  3_edk_ii_dsc_file_format/32_general_rules.md  | 13 +--
>  .../33_platform_dsc_definition.md | 17 +---
>  .../35_[defines]_section.md   | 12 +--
>  .../36_[buildoptions]_sections.md | 19 ++--
>  .../38_[libraries]_sections.md| 94 ---
>  ...ons.md => 38_[libraryclasses]_sections.md} |  4 +-
>  ...310_pcd_sections.md => 39_pcd_sections.md} | 14 +--
>  22 files changed, 101 insertions(+), 462 deletions(-)
>  rename 2_dsc_overview/{211_[components]_section_processing.md => 
> 210_[components]_section_processing.md} (84%)
>  rename 2_dsc_overview/{212_[userextensions]_section.md => 
> 211_[userextensions]_section.md} (93%)
>  rename 2_dsc_overview/{213_[defaultstores]_section_processing.md => 
> 212_[defaultstores]_section_processing.md} (93%)
>  delete mode 100644 2_dsc_overview/26_[libraries]_section_processing.md
>  rename 2_dsc_overview/{27_[libraryclasses]_section_processing.md => 
> 26_[libraryclasses]_section_processing.md} (96%)
>  rename 2_dsc_overview/{28_pcd_section_processing.md => 
> 27_pcd_section_processing.md} (94%)
>  rename 2_dsc_overview/{29_pcd_sections.md => 28_pcd_sections.md} (93%)
>  rename 2_dsc_overview/{210_pcd_database.md => 29_pcd_database.md} (96%)
>  rename 3_edk_ii_dsc_file_format/{311_[components]_sections.md => 
> 310_[components]_sections.md} (81%)
>  rename 3_edk_ii_dsc_file_format/{312_[userextensions]_sections.md => 
> 311_[userextensions]_sections.md} (94%)
>  rename 3_edk_ii_dsc_file_format/{313_[defaultstores]_section.md => 
> 312_[defaultstores]_section.md} (93%)
>  delete mode 100644 3_edk_ii_dsc_file_format/38_[libraries]_sections.md
>  rename 3_edk_ii_dsc_file_format/{39_[libraryclasses]_sections.md => 
> 38_[libraryclasses]_sections.md} (95%)
>  rename 3_edk_ii_dsc_file_format/{310_pcd_sections.md => 39_pcd_sections.md} 
> (97%)
> 
> diff --git a/1_introduction/11_overview.md b/1_introduction/11_overview.md
> index d9006df..ff2b517 100644
> --- a/1_introduction/11_overview.md
> +++ b/1_introduction/11_overview.md
> @@ -1,9 +1,9 @@
>   |:-:|::|:-:|::|:-:|::|
>  | EDK Build Tools| YES   | NO   | YES   | NO   | 
> YES   | NO   |
> -| EDK II Build Tools | NO| YES  | NO| YES  | 
> YES   | YES  |
> +| EDK II Build Tools | NO| YES  | NO| YES  | 
> NO| YES  |
> 
>  **
>  **Note:** This document is intended for persons doing EFI development and
>  support for different platforms. It is most likely only of interest in the
>  event that there is a problem with a build, or if a developer needs to 
> perform
> @@ -90,9 +87,6 @@ contain information on the EFI format for FFS or FV file 
> creation. The
>  Makefiles will support third party compilation tools - Microsoft, Intel and 
> GCC
>  tool chains - and at least one EDK II tool, GenFw. The GenFw tool is used to
>  manipulate the files emitted from the compilation tools.
> 
>  The EDK II build provides UEFI and PI (Unified EFI, Inc.)
> -specification-compliant images. Use of the tools in the EDK Compatibility
> -package can be used for creating earlier versions of EFI 1.10 and/or UEFI 2.0
> -compliant components. To be clear, EDK II tools do not have the limitation

Re: [edk2] [Patch V2 0/1] Document: Update Build spec to remove EDK related

2019-03-06 Thread Gao, Liming

1.  2.12 [UserExtensions] Section and ## 2.11 [UserExtensions] Section are 
inconsistent. There are the similar issue in this patch. Please check them to 
make sure they are same. 

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Feng, 
> Bob C
> Sent: Tuesday, March 5, 2019 11:49 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch V2 0/1] Document: Update Build spec to remove EDK 
> related
> 
> V2:
> Update the top level README to add the update history.
> 
> Feng, Bob C (1):
>   Document: Update Build spec to remove EDK related contents
> 
>  10_post-build_imagegen_stage_-_flash/103_build_intermediate_images.md |  3 
> +--
>  12_build_changes_and_customizations/README.md |  4 
> ++--
>  4_edk_ii_build_process_overview/42_build_process_overview.md  |  6 
> ++
>  4_edk_ii_build_process_overview/46_file_specifications.md | 20 
> +---
>  6_quick_start/61_environment_variables.md | 24 
> +---
>  8_pre-build_autogen_stage/82_auto-generation_process.md   | 76
> +++-
>  8_pre-build_autogen_stage/83_auto-generated_code.md   | 43 
> +++
>  8_pre-build_autogen_stage/85_auto-generated_makefiles.md  | 23 
> +--
>  9_build_or_make_stage/README.md   |  9 
> -
>  README.md |  1 +
>  appendix_a_variables.md   |  3 
> +--
>  11 files changed, 44 insertions(+), 168 deletions(-)
> 
> --
> 2.20.1.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch V2 1/1] Document: Update DEC spec to remove EDK related contents

2019-03-06 Thread Gao, Liming

Update commit message and version info to remove EDK and IFP related contents 
from DEC spec. 

With this change, Reviewed-by: Liming Gao 

> -Original Message-
> From: Feng, Bob C
> Sent: Tuesday, March 5, 2019 11:50 PM
> To: edk2-devel@lists.01.org
> Cc: Feng, Bob C ; Gao, Liming ; 
> Carsey, Jaben 
> Subject: [Patch V2 1/1] Document: Update DEC spec to remove EDK related 
> contents
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1453
> 
> Remove EDK related contents from DEC spec.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Bob Feng 
> Cc: Liming Gao 
> Cc: Jaben Carsey 
> ---
>  2_dec_file_overview/210_pcd_usage.md | 4 +---
>  2_dec_file_overview/25_[includes]_usage.md   | 6 +-
>  2_dec_file_overview/26_[guids]_usage.md  | 6 +-
>  2_dec_file_overview/27_[protocols]_usage.md  | 6 +-
>  2_dec_file_overview/28_[ppis]_usage.md   | 6 +-
>  2_dec_file_overview/29_[libraryclasses]_usage.md | 4 +---
>  3_edk_ii_dec_file_format/310_pcd_sections.md | 8 ++--
>  3_edk_ii_dec_file_format/35_[includes]_sections.md   | 5 +
>  3_edk_ii_dec_file_format/39_[libraryclasses]_sections.md | 5 +
>  README.md| 1 +
>  10 files changed, 11 insertions(+), 40 deletions(-)
> 
> diff --git a/2_dec_file_overview/210_pcd_usage.md 
> b/2_dec_file_overview/210_pcd_usage.md
> index 9b554be..e600db2 100644
> --- a/2_dec_file_overview/210_pcd_usage.md
> +++ b/2_dec_file_overview/210_pcd_usage.md
> @@ -1,9 +1,9 @@
>   2.20.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] Document: Update FDF spec to remove EDK related contents

2019-03-06 Thread Gao, Liming

1. Update commit message
2. + 2.8 [Rule] Sections, and +## 2.7 [Rule] Sections. They are not consistent. 
3. +[Rule.Common.ACPITABLE] Here ACPITABLE is EDK type. Please change it to 
[Rule.Common.USER_DEFINED.ACPITABLE]

> -Original Message-
> From: Feng, Bob C
> Sent: Monday, March 4, 2019 7:00 AM
> To: edk2-devel@lists.01.org
> Cc: Feng, Bob C ; Gao, Liming ; 
> Carsey, Jaben 
> Subject: [Patch] Document: Update FDF spec to remove EDK related contents
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1453
> 
> Remove EDK related contents inf Fdf spec.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Bob Feng 
> Cc: Liming Gao 
> Cc: Jaben Carsey 
> ---
>  1_introduction/11_overview.md |  22 +-
>  1_introduction/12_terms.md|   8 +-
>  1_introduction/README.md  |   9 +-
>  .../22_flash_description_file_format.md   |  34 +--
>  2_fdf_design_discussion/24_[fd]_sections.md   |   9 +-
>  2_fdf_design_discussion/25_[fv]_sections.md   |   9 +-
>  ...ule]_sections.md => 27_[rule]_sections.md} | 232 +-
>  2_fdf_design_discussion/27_[vtf]_sections.md  |  82 ---
>  ...sections.md => 28_[optionrom]_sections.md} | 112 -
>  2_fdf_design_discussion/README.md |   2 -
>  3_edk_ii_fdf_file_format/310_[vtf]_section.md | 203 ---
>  ...ection.md => 310_pci_optionrom_section.md} | 228 -
>  3_edk_ii_fdf_file_format/31_general_rules.md  |  13 +-
>  3_edk_ii_fdf_file_format/32_fdf_definition.md |  67 +
>  appendix_a_nt32pkg_flash_description_file.md  |   4 +-
>  15 files changed, 317 insertions(+), 717 deletions(-)
>  rename 2_fdf_design_discussion/{28_[rule]_sections.md => 
> 27_[rule]_sections.md} (96%)
>  delete mode 100644 2_fdf_design_discussion/27_[vtf]_sections.md
>  rename 2_fdf_design_discussion/{29_[optionrom]_sections.md => 
> 28_[optionrom]_sections.md} (94%)
>  delete mode 100644 3_edk_ii_fdf_file_format/310_[vtf]_section.md
>  rename 3_edk_ii_fdf_file_format/{311_pci_optionrom_section.md => 
> 310_pci_optionrom_section.md} (93%)
> 
> diff --git a/1_introduction/11_overview.md b/1_introduction/11_overview.md
> index 6db8a26..d7dbb20 100644
> --- a/1_introduction/11_overview.md
> +++ b/1_introduction/11_overview.md
> @@ -1,9 +1,9 @@
>   --- |
>  | `$(WORKSPACE)`| System Environment Variable.
> |
>  | `PACKAGES_PATH`   | System Environment Variable that cannot be used in 
> EDK II meta-data Files. The build system will
> automatically detect if this variable is present and use directories listed 
> in this variable as if they were listed in $(WORKSPACE) |
> -| `$(EDK_SOURCE)`   | System Environment Variable.
> |
> -| `$(EFI_SOURCE)`   | System Environment Variable.
> |
>  | `$(EDK_TOOLS_PATH)`   | System Environment Variable
> |
>  | `EDK_TOOLS_BIN`   | System Environment Variable that cannot be used in 
> EDK II meta-data Files.
> |
> -| `$(ECP_SOURCE)`   | System Environment Variable
> |
>  | `$(OUTPUT_DIRECTORY)` | Tool parsing from either the DSC file or via a 
> command line option. This is typically the Build/Platform name
> directory created by the build system in the EDK II WORKSPACE 
>  |
>  | `$(BUILD_NUMBER)` | Tool parsing from either an EDK INF file or the 
> EDK II DSC file's `BUILD_NUMBER` statement. The EDK II DSC
> file's `BUILD_NUMBER` takes precedence over an EDK INF file's 
> |
>  |   | `BUILD_NUMBER` if and only if the EDK II DSC 
> specifies a
> |
>  |   | `BUILD_NUMBER`.
> |
>  |   | Future implementation may allow for setting the
> |
> @@ -408,14 +401,11 @@ must not be altered.
>  ## Table 3 Using System Environment Variable
> 
>  | Macro Style Used in Meta-Data files | Windows Environment Variable | Linux 
> & OS/X Environment Variable |
>  | --- | -- | - |
>  | `$(WORKSPACE)`  | `%WORKSPACE%`  | `$WORKSPACE`  |
> -| `$(EFI_SOURCE)` | `%EFI_SOURCE%` | `$EFI_SOURCE` |
> -| `$(EDK_SOURCE)` | `%EDK_SOURCE%` | `$EDK_SOURCE` |
>  | `$(EDK_TOOLS_PATH)` | `%EDK_TOOLS_PATH%` | `$EDK_TOOLS_PATH` |
> -| `$(ECP_SOURCE)` | `%ECP_SOURCE%` | `$ECP_SOURCE` |
> 
>  The system environment variables, `PACKAGES_PATH` and `EDK_TOOLS_BIN`, are 
> not
>  permitted in EDK II meta-data files.
> 
>  Macros defined in the FDF file are local to the FDF file. They are also
> diff --git a/2_fdf_design_discussion/24_[fd]_sections.md 
> b/2_fdf_design_discussion/24_[fd]_sections.md
> index 67e478e..fc0fb14 100644
> --- a/2_fdf_design_discussion/24_[fd]_sections.md
> +++ b/2_fdf_design_discussion/24_[fd]_sections.md
> @@ -1,9 +1,9 @@
>  
> -
> -## 2.8 [Rule] Sections
> -
> -The optional `[Rule]` sections in the FDF file are

Re: [edk2] [Patch] Document: Update Inf spec to remove EDK related contents

2019-03-06 Thread Gao, Liming

Bob:
  I have some comments. 

1) Please update the commit message. The change is to remove EDK and IPF 
related contents. 
2) The below change should make sure the updated one keep the same alignment. 
-||-
+||
3) Below content is correct. It is for EDKII. No need to change it. 
-These sections are used for specifying PCD information and are valid for EDK
-II modules only. The entries for these sections are looked up from the package
-declaration files (DEC) for generating the `AutoGen.c` and `AutoGen.h` files.
+These sections are used for specifying PCD information. The entries for these 
+sections are looked up from the packagedeclaration files (DEC) for generating 
+the `AutoGen.c` and `AutoGen.h` files.

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Feng, 
> Bob C
> Sent: Monday, March 4, 2019 5:52 AM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Gao, Liming 
> Subject: [edk2] [Patch] Document: Update Inf spec to remove EDK related 
> contents
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1453
> 
> Remove EDK related contents
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Bob Feng 
> Cc: Liming Gao 
> Cc: Jaben Carsey 
> ---
>  1_introduction/11_overview.md |   2 +-
>  2_inf_overview/210_[ppis]_section.md  |   1 -
>  2_inf_overview/211_[guids]_section.md |   1 -
>  .../212_[libraryclasses]_section.md   |   1 -
>  2_inf_overview/213_[packages]_section.md  |   1 -
>  2_inf_overview/214_pcd_sections.md|  14 +-
>  2_inf_overview/215_[depex]_section.md |   4 -
>  2_inf_overview/21_processing_overview.md  |  19 +-
>  .../22_information_file_general_rules.md  |  30 +-
>  2_inf_overview/24_[defines]_section.md|   4 +-
>  2_inf_overview/25_[sources]_section.md|   4 -
>  2_inf_overview/26_[buildoptions]_section.md   |   9 +-
>  2_inf_overview/27_[binaries]_section.md   |   5 -
>  2_inf_overview/29_[protocols]_section.md  |   1 -
>  2_inf_overview/README.md  |  11 -
>  .../314_[depex]_sections.md   |   6 +-
>  .../315_[binaries]_section.md |   5 -
>  .../32_component_inf_definition.md|   4 +-
>  .../34_[defines]_section.md   |   6 +-
>  .../35_[buildoptions]_sections.md |   5 +-
>  .../39_[sources]_sections.md  |   7 +-
>  3_edk_ii_inf_file_format/README.md|   4 -
>  ...ndix_a_build_changes_and_customizations.md |   0
>  .../README.md |  40 --
>  .../a1_design_discussion.md   | 317 
>  .../a2_edk_file_specification.md  | 461 --
>  ...ndix_c_symbols.md => appendix_b_symbols.md |   0
>  ...d => appendix_c_sample_driver_inf_files.md |   0
>  ... => appendix_d_sample_library_inf_files.md |   0
>  ...d => appendix_e_sample_binary_inf_files.md |   0
>  ...ule_types.md => appendix_f_module_types.md |   0
>  31 files changed, 30 insertions(+), 932 deletions(-)
>  rename appendix_b_build_changes_and_customizations.md => 
> appendix_a_build_changes_and_customizations.md (100%)
>  delete mode 100644 appendix_a_edk_inf_file_specification/README.md
>  delete mode 100644 
> appendix_a_edk_inf_file_specification/a1_design_discussion.md
>  delete mode 100644 
> appendix_a_edk_inf_file_specification/a2_edk_file_specification.md
>  rename appendix_c_symbols.md => appendix_b_symbols.md (100%)
>  rename appendix_d_sample_driver_inf_files.md => 
> appendix_c_sample_driver_inf_files.md (100%)
>  rename appendix_e_sample_library_inf_files.md => 
> appendix_d_sample_library_inf_files.md (100%)
>  rename appendix_f_sample_binary_inf_files.md => 
> appendix_e_sample_binary_inf_files.md (100%)
>  rename appendix_g_module_types.md => appendix_f_module_types.md (100%)
> 
> diff --git a/1_introduction/11_overview.md b/1_introduction/11_overview.md
> index 9239080..7349614 100644
> --- a/1_introduction/11_overview.md
> +++ b/1_introduction/11_overview.md
> @@ -40,11 +40,11 @@ Backward compatibility with the existing INF file 
> formats. Changes made to this
>  specification must not require changes to existing INF files.
> 
>  **Simplified platform build and configuration**
> 
>  Simplify the build setup and configuration for a given platform. The process 
> of
> -adding EDK and EDK II firmware components to a firmware volume on any given
> +adding EDK II firmware components to a firmware volume on any given
>  platform was also simplified.
> 
>  **Distributing Modules**
> 
>  Enable easy distribution of modules, both in source and binary form. 
> Individual
> diff --git a/2_inf_overview/210_[ppis]_section.md 
> b/2_inf_overview/210_[ppis]_section.md
> index bbdd2a4..1ab84eb 100644
> --- a/2_inf_overview/210_[ppis]_section.md
> +++ b/2_inf_overview/210_[ppis]_section.md
> @@

78 matches

Mail list logo