[edk2] 答复: [RFC v3 1/3] UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support

[Fan Jeff]

Paulo,


I don't understand why you - 1 when calculating EIP offset in image, it 
confused me.


+  for (;;) {
+//
+// Print stack frame in the following format:
+//
+// #  @ + (RBP) in [ | ]
+//
+InternalPrintMessage (
+  "%d 0x%016lx @ 0x%016lx+0x%x (0x%016lx) in %a\n",
+  *UnwoundStacksCount - 1,
+  Rip,
+  ImageBase,
+  Rip - ImageBase - 1,   // 
+  Rbp,
+  PdbFileName
+  );
+

Jeff





发件人: edk2-devel  代表 Paulo Alcantara 

发送时间: 2017年11月17日 5:56
收件人: edk2-devel@lists.01.org
抄送: Laszlo Ersek; Eric Dong
主题: [edk2] [RFC v3 1/3] UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace 
support

This patch adds stack trace support during a X64 CPU exception.

It will dump out back trace, stack contents as well as image module
names that were part of the call stack.

Contributed-under: TianoCore Contribution Agreement 1.1
Cc: Eric Dong 
Cc: Laszlo Ersek 
Signed-off-by: Paulo Alcantara 
---
 UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c | 376 
+++-
 1 file changed, 374 insertions(+), 2 deletions(-)

diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
index 65f0cff680..fe776ccc2d 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
@@ -14,6 +14,11 @@

 #include "CpuExceptionCommon.h"

+//
+// Unknown PDB file name
+//
+GLOBAL_REMOVE_IF_UNREFERENCED CONST CHAR8 *mUnknownPdbFileName = "";
+
 /**
   Return address map of exception handler template so that C code can generate
   exception tables.
@@ -242,6 +247,357 @@ DumpCpuContext (
 );
 }

+/**
+  Get absolute path and file name of PDB file in PE/COFF image.
+
+  @param[in]  ImageBaseBase address of PE/COFF image.
+  @param[out] PdbAbsoluteFilePath  Absolute path of PDB file.
+  @param[out] PdbFileName  File name of PDB file.
+**/
+STATIC
+VOID
+GetPdbFileName (
+  IN  UINTNImageBase,
+  OUT CHAR8**PdbAbsoluteFilePath,
+  OUT CHAR8**PdbFileName
+  )
+{
+  VOID   *PdbPointer;
+  CHAR8  *Str;
+
+  //
+  // Get PDB file name from PE/COFF image
+  //
+  PdbPointer = PeCoffLoaderGetPdbPointer ((VOID *)ImageBase);
+  if (PdbPointer == NULL) {
+//
+// No PDB file name found. Set it to an unknown file name.
+//
+*PdbFileName = (CHAR8 *)mUnknownPdbFileName;
+if (PdbAbsoluteFilePath != NULL) {
+  *PdbAbsoluteFilePath = NULL;
+}
+  } else {
+//
+// Get file name portion out of PDB file in PE/COFF image
+//
+Str = (CHAR8 *)((UINTN)PdbPointer +
+AsciiStrLen ((CHAR8 *)PdbPointer) - sizeof *Str);
+for (; *Str != '/' && *Str != '\\'; Str--) {
+  ;
+}
+
+//
+// Set PDB file name (also skip trailing path separator: '/' or '\\')
+//
+*PdbFileName = Str + 1;
+
+if (PdbAbsoluteFilePath != NULL) {
+  //
+  // Set absolute file path of PDB file
+  //
+  *PdbAbsoluteFilePath = PdbPointer;
+}
+  }
+}
+
+/**
+  Dump stack contents.
+
+  @param[in]  CurrentRsp Current stack pointer address.
+  @param[in]  UnwoundStacksCount  Count of unwound stack frames.
+**/
+STATIC
+VOID
+DumpStackContents (
+  IN UINT64  CurrentRsp,
+  IN INTNUnwoundStacksCount
+  )
+{
+  //
+  // Check for proper stack pointer alignment
+  //
+  if (((UINTN)CurrentRsp & (CPU_STACK_ALIGNMENT - 1)) != 0) {
+InternalPrintMessage (" Unaligned stack pointer. \n");
+return;
+  }
+
+  //
+  // Dump out stack contents
+  //
+  InternalPrintMessage ("\nStack dump:\n");
+  while (UnwoundStacksCount-- > 0) {
+InternalPrintMessage (
+  "0x%016lx: %016lx %016lx\n",
+  CurrentRsp,
+  *(UINT64 *)CurrentRsp,
+  *(UINT64 *)((UINTN)CurrentRsp + 8)
+  );
+
+//
+// Point to next stack
+//
+CurrentRsp += CPU_STACK_ALIGNMENT;
+  }
+}
+
+/**
+  Dump all image module names from call stack.
+
+  @param[in]  SystemContext  Pointer to EFI_SYSTEM_CONTEXT.
+**/
+STATIC
+VOID
+DumpImageModuleNames (
+  IN EFI_SYSTEM_CONTEXT   SystemContext
+  )
+{
+  EFI_STATUS  Status;
+  UINT64  Rip;
+  UINTN   ImageBase;
+  VOID*EntryPoint;
+  CHAR8   *PdbAbsoluteFilePath;
+  CHAR8   *PdbFileName;
+  UINT64  Rbp;
+  UINTN   LastImageBase;
+
+  //
+  // Set current RIP address
+  //
+  Rip = SystemContext.SystemContextX64->Rip;
+
+  //
+  // Set current frame pointer address
+  //
+  Rbp = SystemContext.SystemContextX64->Rbp;
+
+  //
+  // Check for proper frame pointer alignment
+  //
+  if (((UINTN)Rbp & (CPU_STACK_ALIGNMENT - 1)) != 0) {
+InternalPrintMessage (" Unaligned frame pointer. \n");
+return;
+  }
+
+  //
+  // Get initial PE/COFF image 

[edk2] [Patch v2] CryptoPkg/TlsLib: Change the return type of TlsInitialize().

[Jiaxin Wu]

V2:
* Correct the commit log.

Currently, the return code of OPENSSL_init_ssl(0 or 1) and RandomSeed
(TRUE or FALSE) are not checked in TlsInitialize(). Also "VOID" is used
as the return type of TlsInitialize(), which can't be used to capture
the returned value for error handling.

>From Long Qin (CryptoPkg owner):
The early version of OPENSSL_init_ssl() use the "VOID" as the return
value, which was updated to "int" later because the function changes
can fail.

So, this patch is to change the return type of TlsInitialize() to
follow up the OPENSSL_init_ssl() update.

Cc: Ye Ting 
Cc: Long Qin 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
---
 CryptoPkg/Include/Library/TlsLib.h |  7 +--
 CryptoPkg/Library/TlsLib/TlsInit.c | 20 ++--
 2 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/CryptoPkg/Include/Library/TlsLib.h 
b/CryptoPkg/Include/Library/TlsLib.h
index fa6cb99..b69d513 100644
--- a/CryptoPkg/Include/Library/TlsLib.h
+++ b/CryptoPkg/Include/Library/TlsLib.h
@@ -1,9 +1,9 @@
 /** @file
   Defines TLS Library APIs.
 
-Copyright (c) 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2016 - 2017, 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
 
@@ -20,12 +20,15 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
   This function registers ciphers and digests used directly and indirectly
   by SSL/TLS, and initializes the readable error messages.
   This function must be called before any other action takes places.
 
+  @retval TRUE   The OpenSSL library has been initialized.
+  @retval FALSE  Failed to initialize the OpenSSL library.
+
 **/
-VOID
+BOOLEAN
 EFIAPI
 TlsInitialize (
   VOID
   );
 
diff --git a/CryptoPkg/Library/TlsLib/TlsInit.c 
b/CryptoPkg/Library/TlsLib/TlsInit.c
index e524647..a530ff7 100644
--- a/CryptoPkg/Library/TlsLib/TlsInit.c
+++ b/CryptoPkg/Library/TlsLib/TlsInit.c
@@ -20,30 +20,38 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
   This function registers ciphers and digests used directly and indirectly
   by SSL/TLS, and initializes the readable error messages.
   This function must be called before any other action takes places.
 
+  @retval TRUE   The OpenSSL library has been initialized.
+  @retval FALSE  Failed to initialize the OpenSSL library.
+
 **/
-VOID
+BOOLEAN
 EFIAPI
 TlsInitialize (
   VOID
   )
 {
+  INTNRet;
+
   //
   // Performs initialization of crypto and ssl library, and loads required
   // algorithms.
   //
-  OPENSSL_init_ssl (
-OPENSSL_INIT_LOAD_SSL_STRINGS | OPENSSL_INIT_LOAD_CRYPTO_STRINGS,
-NULL
-);
+  Ret = OPENSSL_init_ssl (
+  OPENSSL_INIT_LOAD_SSL_STRINGS | OPENSSL_INIT_LOAD_CRYPTO_STRINGS,
+  NULL
+  );
+  if (Ret != 1) {
+return FALSE;
+  }
 
   //
   // Initialize the pseudorandom number generator.
   //
-  RandomSeed (NULL, 0);
+  return RandomSeed (NULL, 0);
 }
 
 /**
   Free an allocated SSL_CTX object.
 
-- 
1.9.5.msysgit.1

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

Re: [edk2] SCT Test crashes After HTTPS boot success.

[Wu, Jiaxin]

I will try to reproduce the issue with EDK2 trunk code, then feedback to you. 
Thanks the report.

Jiaxin

From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Friday, November 17, 2017 2:32 PM
To: Wu, Jiaxin ; 'edk2-devel@lists.01.org' 

Cc: Fu, Siyuan ; Ye, Ting 
Subject: RE: SCT Test crashes After HTTPS boot success.

Hi Jiaxin,

Below are the detailed steps for SCT test

[Steps to reproduce]
.
  5. Run SCT test

a.  Execute the following commands to run SCT test on SUT
 sct -r

  sct -u
   b.  In Test Case Management page, Enable GenericTest
   c.  Press F9 to run the selected test case

[Observation]
synchronous exception occurred in SCT ,Attached the Log for reference.

Thanks,
Karunakar

From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
Sent: Friday, November 17, 2017 6:01 AM
To: Karunakar P; 'edk2-devel@lists.01.org'
Cc: Fu, Siyuan; Ye, Ting
Subject: RE: SCT Test crashes After HTTPS boot success.

Hi Karunakar,

Can you provide more detailed info for the SCT test steps? The crash can happen 
after "Sct.efi -u" or need run any specific test case?

Thanks,
Jiaxin

From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Thursday, November 16, 2017 4:48 PM
To: 'edk2-devel@lists.01.org' 
>
Cc: Wu, Jiaxin >; Fu, Siyuan 
>; Ye, Ting 
>
Subject: SCT Test crashes After HTTPS boot success.

Hello All,

When I do SCT test, get the below failure
GenericTest\EFICompliantTest 0 0 CB6F7B77-0B15-43F7-A95B-8C7F9FD70B21 FAIL UEFI 
Compliant - TLS support is required

The reason for the failure is that the platform doesn't have TLS related 
protocols installed.

->if the platform supports TLS feature then, EFI_TLS_PROTOCOL, 
EFI_TLS_SERVICE_BINDING_PROTOCOL, EFI_TLS_CONFIGURATION_PROTOCOL must be 
existed.
-> According UEFI2.7 Spec - 28.10 EFI TLS Protocols(page-1787)
The TLS consumer need locate EFI_TLS_SERVICE_BINDING_PROTOCOL and call 
CreateChild() to create a new child of EFI_TLS_PROTOCOL instance. Then use 
EFI_TLS_PROTOCOL to start TLS session. After use, the TLS consumer need call 
DestroyChild() to destroy it.
-> Network Stack follows same in HTTPS boot.
While doing IPv4/6 HTTPS boot , will locate gEfiTlsServiceBindingProtocolGuid 
and call TlsServiceBindingCreateChild, So that EFI_TLS_PROTOCOL and 
EFI_TLS_CONFIGURATION_PROTOCOL will be installed.

So once HTTPS boot is success then TLS supported protocols exist.

And if we do SCT test after HTTPS boot is success, Then TLS related failures 
should NOT happen in SCT.

I've tried SCT test after HTTPS boot success, But SCT test Crashes.

[Steps to reproduce]

1.   Configure the HTTPS Server with EFI Shell as NBP file.

2.   Connect test machine and HTTPS server with LAN cable.

3.   Perform HTTPS boot in test machine

4.   Once HTTPS boot is success, It will launch Shell.

5.   Run SCT test


[Observations]

1.   SCT test was crashed and unable to continue the test.

Could you please provide your comments/Suggestion on this?


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

Re: [edk2] SCT Test crashes After HTTPS boot success.

[Karunakar P]

Hi Jiaxin,

Below are the detailed steps for SCT test

[Steps to reproduce]
.
  5. Run SCT test

a.  Execute the following commands to run SCT test on SUT
 sct -r

  sct -u
   b.  In Test Case Management page, Enable GenericTest
   c.  Press F9 to run the selected test case

[Observation]
synchronous exception occurred in SCT ,Attached the Log for reference.

Thanks,
Karunakar

From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
Sent: Friday, November 17, 2017 6:01 AM
To: Karunakar P; 'edk2-devel@lists.01.org'
Cc: Fu, Siyuan; Ye, Ting
Subject: RE: SCT Test crashes After HTTPS boot success.

Hi Karunakar,

Can you provide more detailed info for the SCT test steps? The crash can happen 
after "Sct.efi -u" or need run any specific test case?

Thanks,
Jiaxin

From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Thursday, November 16, 2017 4:48 PM
To: 'edk2-devel@lists.01.org' 
>
Cc: Wu, Jiaxin >; Fu, Siyuan 
>; Ye, Ting 
>
Subject: SCT Test crashes After HTTPS boot success.

Hello All,

When I do SCT test, get the below failure
GenericTest\EFICompliantTest 0 0 CB6F7B77-0B15-43F7-A95B-8C7F9FD70B21 FAIL UEFI 
Compliant - TLS support is required

The reason for the failure is that the platform doesn't have TLS related 
protocols installed.

->if the platform supports TLS feature then, EFI_TLS_PROTOCOL, 
EFI_TLS_SERVICE_BINDING_PROTOCOL, EFI_TLS_CONFIGURATION_PROTOCOL must be 
existed.
-> According UEFI2.7 Spec - 28.10 EFI TLS Protocols(page-1787)
The TLS consumer need locate EFI_TLS_SERVICE_BINDING_PROTOCOL and call 
CreateChild() to create a new child of EFI_TLS_PROTOCOL instance. Then use 
EFI_TLS_PROTOCOL to start TLS session. After use, the TLS consumer need call 
DestroyChild() to destroy it.
-> Network Stack follows same in HTTPS boot.
While doing IPv4/6 HTTPS boot , will locate gEfiTlsServiceBindingProtocolGuid 
and call TlsServiceBindingCreateChild, So that EFI_TLS_PROTOCOL and 
EFI_TLS_CONFIGURATION_PROTOCOL will be installed.

So once HTTPS boot is success then TLS supported protocols exist.

And if we do SCT test after HTTPS boot is success, Then TLS related failures 
should NOT happen in SCT.

I've tried SCT test after HTTPS boot success, But SCT test Crashes.

[Steps to reproduce]

1.   Configure the HTTPS Server with EFI Shell as NBP file.

2.   Connect test machine and HTTPS server with LAN cable.

3.   Perform HTTPS boot in test machine

4.   Once HTTPS boot is success, It will launch Shell.

5.   Run SCT test


[Observations]

1.   SCT test was crashed and unable to continue the test.

Could you please provide your comments/Suggestion on this?


Thanks,
Karunakar


  *RECOVERY*

System hangs or stops abnormally. -- FAILURE
DE687A18-0BBD-4396-8509-498FF23234F1
/home/supven01/upstream_edk2/edk2/SctPkg/TestInfrastructure/SCT/Framework/Execute/Execute.c:2104


Returned Status Code: Unsupported

PlatformSpecificElements: [FAILED]
  Passes... 18
  Warnings. 0
  Errors... 8

UEFI 2.6
Revision 0x00010001
Test Entry Point GUID: A0A8BED3-3D6F-4AD8-907A-84D52EE1543B

Logfile: 
"\UEFISCT_2.6\UEFISCT\SctPackageAARCH64\AARCH64\Log\GenericTest\EFICompliantTest0\PlatformSpecificElements_0_0_A0A8BED3-3D6F-4AD8-907A-84D52EE1543B.log"
Test Finished: 09/28/80  12:41p
Elapsed Time: 00 Days 00:00:02


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

[edk2] [Patch] BaseTools: Fix a bug for single module build with GenC/GenMake option

[Yonghong Zhu]

when build a single module with GenC/GenMake option, currently it will
direct return after create Autogen code files, then it cause MaList is
empty, which cause an incorrect error message is reported.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/build/build.py | 5 -
 1 file changed, 5 deletions(-)

diff --git a/BaseTools/Source/Python/build/build.py 
b/BaseTools/Source/Python/build/build.py
index 4f73bba..53f1245 100644
--- a/BaseTools/Source/Python/build/build.py
+++ b/BaseTools/Source/Python/build/build.py
@@ -1835,17 +1835,12 @@ class Build():
 # Not to auto-gen for targets 'clean', 'cleanlib', 
'cleanall', 'run', 'fds'
 if self.Target not in ['clean', 'cleanlib', 
'cleanall', 'run', 'fds']:
 # for target which must generate AutoGen code 
and makefile
 if not self.SkipAutoGen or self.Target == 
'genc':
 Ma.CreateCodeFile(True)
-if self.Target == "genc":
-continue
-
 if not self.SkipAutoGen or self.Target == 
'genmake':
 Ma.CreateMakeFile(True)
-if self.Target == "genmake":
-continue
 MaList.append(Ma)
 self.BuildModules.append(Ma)
 self.AutoGenTime += int(round((time.time() - 
AutoGenStart)))
 MakeStart = time.time()
 for Ma in self.BuildModules:
-- 
2.6.1.windows.1

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

[edk2] [Patch] CryptoPkg/TlsLib: Change the return type of TlsInitialize().

[Jiaxin Wu]

Currently, in TlsInitialize(), neither the return status of
OPENSSL_init_ssl(0, or 1) nor the return code of RandomSeed
(TRUE or FALSE) is not checked. Also VOID is used as the return
type of TlsInitialize(), which can't be used to capture the
returned value for the error handling.

>From Long Qin (CryptoPkg owner):
The early version of OPENSSL_init_ssl() use the "VOID" as the
return value, which was updated to "int" later because the
function changes can fail.

So, this patch is to change the return type of TlsInitialize()
to follow up the OPENSSL_init_ssl() update.

Cc: Ye Ting 
Cc: Long Qin 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
---
 CryptoPkg/Include/Library/TlsLib.h |  7 +--
 CryptoPkg/Library/TlsLib/TlsInit.c | 20 ++--
 2 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/CryptoPkg/Include/Library/TlsLib.h 
b/CryptoPkg/Include/Library/TlsLib.h
index fa6cb99..b69d513 100644
--- a/CryptoPkg/Include/Library/TlsLib.h
+++ b/CryptoPkg/Include/Library/TlsLib.h
@@ -1,9 +1,9 @@
 /** @file
   Defines TLS Library APIs.
 
-Copyright (c) 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2016 - 2017, 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
 
@@ -20,12 +20,15 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
   This function registers ciphers and digests used directly and indirectly
   by SSL/TLS, and initializes the readable error messages.
   This function must be called before any other action takes places.
 
+  @retval TRUE   The OpenSSL library has been initialized.
+  @retval FALSE  Failed to initialize the OpenSSL library.
+
 **/
-VOID
+BOOLEAN
 EFIAPI
 TlsInitialize (
   VOID
   );
 
diff --git a/CryptoPkg/Library/TlsLib/TlsInit.c 
b/CryptoPkg/Library/TlsLib/TlsInit.c
index e524647..a530ff7 100644
--- a/CryptoPkg/Library/TlsLib/TlsInit.c
+++ b/CryptoPkg/Library/TlsLib/TlsInit.c
@@ -20,30 +20,38 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
   This function registers ciphers and digests used directly and indirectly
   by SSL/TLS, and initializes the readable error messages.
   This function must be called before any other action takes places.
 
+  @retval TRUE   The OpenSSL library has been initialized.
+  @retval FALSE  Failed to initialize the OpenSSL library.
+
 **/
-VOID
+BOOLEAN
 EFIAPI
 TlsInitialize (
   VOID
   )
 {
+  INTNRet;
+
   //
   // Performs initialization of crypto and ssl library, and loads required
   // algorithms.
   //
-  OPENSSL_init_ssl (
-OPENSSL_INIT_LOAD_SSL_STRINGS | OPENSSL_INIT_LOAD_CRYPTO_STRINGS,
-NULL
-);
+  Ret = OPENSSL_init_ssl (
+  OPENSSL_INIT_LOAD_SSL_STRINGS | OPENSSL_INIT_LOAD_CRYPTO_STRINGS,
+  NULL
+  );
+  if (Ret != 1) {
+return FALSE;
+  }
 
   //
   // Initialize the pseudorandom number generator.
   //
-  RandomSeed (NULL, 0);
+  return RandomSeed (NULL, 0);
 }
 
 /**
   Free an allocated SSL_CTX object.
 
-- 
1.9.5.msysgit.1

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

Re: [edk2] [RFC v2 1/3] UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support

[Yao, Jiewen]

Thanks for your reply. Comments below:

> -Original Message-
> From: Paulo Alcantara [mailto:pca...@zytor.com]
> Sent: Friday, November 17, 2017 6:13 AM
> To: Yao, Jiewen 
> Cc: Paulo Alcantara ; edk2-devel@lists.01.org; Laszlo Ersek
> ; Dong, Eric 
> Subject: RE: [edk2] [RFC v2 1/3] UefiCpuPkg/CpuExceptionHandlerLib/X64: Add
> stack trace support
> 
> Hi Jiewen,
> 
> On Wed, November 15, 2017 11:57 pm, Yao, Jiewen wrote:
> > Hi Paulo
> > Thanks to bring this cool feature.
> >
> > I have same feeling as Jeff Fan. It is great!
> >
> > I have some questions, hope you can clarify.
> > 1) Would you please let us know which tool change is validated? Such as
> > MSVC, or GCC?
> 
> GCC only. This should not work on MSVC because it relies on frame pointers.

[Jiewen] Not work is OK.
But my question is more about: Have you tested? Or have you tried?
Do you see basic exception information can be dumped without any problem for 
MSVC?
Or do you see system crash immediately for MSVC?



> > 2) Would you please let us know which phase is validated? Such as PEI
> > PreMemory, PEI PostMemory, DXE, SMM?
> 
> DXE. I'm currently testing it by placing a random "CpuBreakpoint ()" in
> PartitionDxe driver.
> 

[Jiewen] Ummm.
Based upon the fact that the code you update may be used in all those phases.
I recommend to validate them in the final patch.


> > 3) Would you please let us know if there is any special condition
> > validated? Such as code is in an interrupt handler, SMM initialization
> > code, thunk code during mode switch, etc.
> > I ask this because I have seen lots of discussion on sanity check, to
> > avoid double exception.
> 
> At the moment I'm only ensuring proper aligned RSP and ESP values. But we
> still need to validate the RIP values, etc. as Andrew and Brian suggested.

[Jiewen] OK. I look forward to seeing your patch to validate more.
Same as #2. I suggest you validate all those corner cases in the final patch.

> > 4) We supported some security feature to create a hole in normal memory
> > map, such as PageGuard, StackGuard, SMM communication protection, etc.
> > Accessing those memory directly will cause #PF immediately.
> > Would you please let us know how we detect that case, to avoid RIP or RSP
> > fail to the non-present page?
> 
> Sorry. I have no idea :-( I'd hope to get some help from you guys.


[Jiewen] One possible solution is to scan page table, before access this 
address, to make sure you are accessing present page.
You can also filer invalid address directly by checking CPUID physical address 
bit before that. The invalid address will cause #GP instead of #PF.

All I all, I would like to clarify the goal for exception lib: whatever 
exception condition the BIOS meets, the exception handler can always dump the 
*basic* exception information and halt.
The missing of advanced symbol info is acceptable. But system crash, when we 
want to dump the advanced info, is not the best choice.



> > 5) May I know why we check RIP < ImageBase? Is that legal or illegal if
> > RIP > ImageBase+ImageSize, but RIP in another PE/COFF image?
> 
> That check was a wrong assumption that I had in the beginning. RIP may
> point to either lower or higher addresses where the other PE/COFF images
> are located. Fixed it in v3.


[Jiewen] Great. Thanks.


> Sorry for the delay in the response. I'm only able to work on this in my
> free time.
> 
> Thanks!
> Paulo
> 
> >> +//
> >> +// Check if RIP is within another PE/COFF image base address
> >> +//
> >> +if (Rip < ImageBase) {
> >> +  //
> >> +  // Search for the respective PE/COFF image based on RIP
> >> +  //
> >
> > Thank you
> > Yao Jiewen
> >
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> >> Paulo
> >> Alcantara
> >> Sent: Thursday, November 16, 2017 9:18 AM
> >> To: edk2-devel@lists.01.org
> >> Cc: Laszlo Ersek ; Dong, Eric 
> >> Subject: [edk2] [RFC v2 1/3] UefiCpuPkg/CpuExceptionHandlerLib/X64: Add
> >> stack
> >> trace support
> >>
> >> This patch adds stack trace support during a X64 CPU exception.
> >>
> >> It will dump out back trace, stack contents as well as image module
> >> names that were part of the call stack.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Cc: Eric Dong 
> >> Cc: Laszlo Ersek 
> >> Signed-off-by: Paulo Alcantara 
> >> ---
> >>  UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c |
> >> 369
> >> +++-
> >>  1 file changed, 367 insertions(+), 2 deletions(-)
> >>
> >> diff --git
> >> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
> >> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
> >> index 65f0cff680..11cd7c9e1c 100644
> >> ---
> >> 

Re: [edk2] [PATCH v6 3/7] UefiCpuPkg/CpuDxe: Reduce debug message

[Wang, Jian J]

I agree. Thanks for the comment.

> -Original Message-
> From: Zeng, Star
> Sent: Friday, November 17, 2017 10:31 AM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Dong, Eric ;
> Zeng, Star 
> Subject: RE: [edk2] [PATCH v6 3/7] UefiCpuPkg/CpuDxe: Reduce debug message
> 
> According to the definitions, DEBUG_POOL and DEBUG_PAGE are for alloc &
> free pool/page.
> 
> #define DEBUG_POOL  0x0010  // Alloc & Free (pool)
> #define DEBUG_PAGE  0x0020  // Alloc & Free (page)
> 
> How about changing the debug level to DEBUG_VERBOSE?
> If you agree, you do not need send a new patch, we can update it when
> pushing. :)
> 
> 
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
> Wang
> Sent: Tuesday, November 14, 2017 11:11 AM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Dong, Eric 
> Subject: [edk2] [PATCH v6 3/7] UefiCpuPkg/CpuDxe: Reduce debug message
> 
> Heap guard feature will frequently update page attributes. The debug message
> in CpuDxe driver will slow down the boot performance noticeably. Changing the
> debug level to DEBUG_POOL and DEBUG_PAGE to reduce the message output
> for normal debug configuration.
> 
> Cc: Eric Dong 
> Cc: Jiewen Yao 
> Suggested-by: Ayellet Wolman 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> Reviewed-by: Jiewen Yao 
> Regression-tested-by: Laszlo Ersek 
> ---
>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> index d312eb66f8..5270a1124f 100644
> --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> @@ -442,8 +442,9 @@ ConvertPageEntryAttribute (
>*PageEntry = NewPageEntry;
>if (CurrentPageEntry != NewPageEntry) {
>  *IsModified = TRUE;
> -DEBUG ((DEBUG_INFO, "ConvertPageEntryAttribute 0x%lx",
> CurrentPageEntry));
> -DEBUG ((DEBUG_INFO, "->0x%lx\n", NewPageEntry));
> +DEBUG ((DEBUG_POOL | DEBUG_PAGE, "ConvertPageEntryAttribute 0x%lx",
> +CurrentPageEntry));
> +DEBUG ((DEBUG_POOL | DEBUG_PAGE, "->0x%lx\n", NewPageEntry));
>} else {
>  *IsModified = FALSE;
>}
> --
> 2.14.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 v6 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

[Wang, Jian J]

1) Sure. I'll update the wording.
2) I still think this is just a workaround . In the long run, I don't think the 
merge is a good idea. It looks like it will "fix" more issues, but actually it 
just "hide" them and would cause more and more workaround in the future. 
Anyway, if no one else has objections, I'll update the code.

> -Original Message-
> From: Yao, Jiewen
> Sent: Friday, November 17, 2017 9:37 AM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Zeng, Star ; Laszlo Ersek ; Ard
> Biesheuvel 
> Subject: RE: [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging
> capabilities
> 
> HI
> I have 2 comments:
> 
> 1) I do not think we need mention: WORKAROUND.
> I suggest we just use "NOTE".
> 
> We have similar example before, see
> MdePkg\Library\BasePeCoffLib\BasePeCoff.c
>   //
>   // NOTE: Some versions of Linux ELILO for Itanium have an incorrect magic
> value
>   //   in the PE/COFF Header.  If the MachineType is Itanium(IA64) and the
>   //   Magic value in the OptionalHeader is
> EFI_IMAGE_NT_OPTIONAL_HDR32_MAGIC
>   //   then override the returned value to
> EFI_IMAGE_NT_OPTIONAL_HDR64_MAGIC
>   //
> 
> 2) I agree with Star. I think we should merge the final result.
> The suggestion before is: *Keep current UEFI memory map unchanged.*
> Changing it brings lots of risk without validating all UEFI OS.
> 
> 
> Thank you
> Yao Jiewen
> 
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Thursday, November 16, 2017 3:27 PM
> > To: edk2-devel@lists.01.org
> > Cc: Yao, Jiewen ; Zeng, Star ;
> > Laszlo Ersek ; Ard Biesheuvel
> 
> > Subject: [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging
> capabilities
> >
> > Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really
> > set attributes and change memory paging attribute accordingly.
> > But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
> > value from Capabilities in GCD memory map. This might cause
> > boot problems. Clearing all paging related capabilities can
> > workaround it. The code added in this patch is supposed to
> > be removed once the usage of EFI_MEMORY_DESCRIPTOR.Attribute
> > is clarified in UEFI spec and adopted by both EDK-II Core and
> > all supported OSs.
> >
> > Cc: Jiewen Yao 
> > Cc: Star Zeng 
> > Cc: Laszlo Ersek 
> > Cc: Ard Biesheuvel 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang 
> > ---
> >  MdeModulePkg/Core/Dxe/Mem/Page.c | 17 +
> >  1 file changed, 17 insertions(+)
> >
> > diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c
> > b/MdeModulePkg/Core/Dxe/Mem/Page.c
> > index c9219cc068..783b576e35 100644
> > --- a/MdeModulePkg/Core/Dxe/Mem/Page.c
> > +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
> > @@ -1829,6 +1829,23 @@ CoreGetMemoryMap (
> >//
> >BufferSize = ((UINT8 *)MemoryMap - (UINT8 *)MemoryMapStart);
> >
> > +  //
> > +  // WORKAROUND: Some OSs will treat
> EFI_MEMORY_DESCRIPTOR.Attribute
> > as really
> > +  // set attributes and change memory paging attribute
> > accordingly.
> > +  // But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned
> > by
> > +  // value from Capabilities in GCD memory map. This might
> > cause
> > +  // boot problems. Clearing all paging related capabilities 
> > can
> > +  // workaround it. Following code is supposed to be removed
> > once
> > +  // the usage of EFI_MEMORY_DESCRIPTOR.Attribute is clarified
> > in
> > +  // UEFI spec and adopted by both EDK-II Core and all
> > supported
> > +  // OSs.
> > +  //
> > +  while (MemoryMapStart < MemoryMap) {
> > +MemoryMapStart->Attribute &= ~(UINT64)(EFI_MEMORY_RP |
> > EFI_MEMORY_RO |
> > +   EFI_MEMORY_XP);
> > +MemoryMapStart = NEXT_MEMORY_DESCRIPTOR(MemoryMapStart,
> > Size);
> > +  }
> > +
> >Status = EFI_SUCCESS;
> >
> >  Done:
> > --
> > 2.14.1.windows.1

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

Re: [edk2] [PATCH v2] MdeModulePkg/UfsBlockIoPei: Support IoMmu

[Zeng, Star]

Yes, same comments to SD/eMMC series.

Thanks,
Star
-Original Message-
From: Wu, Hao A 
Sent: Friday, November 17, 2017 10:37 AM
To: Zeng, Star ; edk2-devel@lists.01.org
Cc: Yao, Jiewen 
Subject: RE: [edk2] [PATCH v2] MdeModulePkg/UfsBlockIoPei: Support IoMmu

> -Original Message-
> From: Zeng, Star
> Sent: Thursday, November 16, 2017 6:38 PM
> To: Wu, Hao A; edk2-devel@lists.01.org
> Cc: Wu, Hao A; Yao, Jiewen; Zeng, Star
> Subject: RE: [edk2] [PATCH v2] MdeModulePkg/UfsBlockIoPei: Support 
> IoMmu
> 
> How about calling IoMmuInit () after locating 
> gEdkiiPeiUfsHostControllerPpiGuid?
> 
> Same comment to SdBlockIoPei and EmmcBlockIoPei.
> 
> If you agree, Reviewed-by: Star Zeng 

Thanks.

I will update the codes according to your comments when I push the changes.

Also, for the SD/eMMC patch series, do you still need to review them? Or I can 
get your R-b with the above-mentioned change?


Best Regards,
Hao Wu

> 
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Hao Wu
> Sent: Tuesday, October 31, 2017 11:18 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Yao, Jiewen 
> ; Zeng, Star 
> Subject: [edk2] [PATCH v2] MdeModulePkg/UfsBlockIoPei: Support IoMmu
> 
> V2 changes:
> Resource cleanup logic update in UfsEndOfPei().
> 
> V1 history:
> Update the UfsBlockIoPei driver to consume IOMMU_PPI to allocate DMA 
> buffer.
> 
> If no IOMMU_PPI exists, this driver still calls PEI service to 
> allocate DMA buffer, with assumption that DRAM==DMA.
> 
> This is a compatible change.
> 
> Cc: Star Zeng 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  MdeModulePkg/Bus/Ufs/UfsBlockIoPei/DmaMem.c  | 249
> 
>  MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsBlockIoPei.c   |  60 -
>  MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsBlockIoPei.h   | 141 ++-
>  MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsBlockIoPei.inf |   5 +-
>  MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsHcMem.c|  23 +-
>  MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsHcMem.h|   4 +-
>  MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsHci.c  |  91 +--
>  7 files changed, 535 insertions(+), 38 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/DmaMem.c
> b/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/DmaMem.c
> new file mode 100644
> index 00..0a939a3879
> --- /dev/null
> +++ b/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/DmaMem.c
> @@ -0,0 +1,249 @@
> +/** @file
> +  The DMA memory help function.
> +
> +  Copyright (c) 2017, 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.
> +
> +**/
> +
> +#include "UfsBlockIoPei.h"
> +
> +EDKII_IOMMU_PPI  *mIoMmu;
> +
> +/**
> +  Provides the controller-specific addresses required to access 
> +system memory from a
> +  DMA bus master.
> +
> +  @param  Operation Indicates if the bus master is going to read 
> or
> write to system memory.
> +  @param  HostAddress   The system memory address to map to the PCI
> controller.
> +  @param  NumberOfBytes On input the number of bytes to map. On
> output the number of bytes
> +that were mapped.
> +  @param  DeviceAddress The resulting map address for the bus master
> PCI controller to use to
> +access the hosts HostAddress.
> +  @param  Mapping   A resulting value to pass to Unmap().
> +
> +  @retval EFI_SUCCESS   The range was mapped for the returned
> NumberOfBytes.
> +  @retval EFI_UNSUPPORTED   The HostAddress cannot be mapped as a
> common buffer.
> +  @retval EFI_INVALID_PARAMETER One or more parameters are invalid.
> +  @retval EFI_OUT_OF_RESOURCES  The request could not be completed 
> + due
> to a lack of resources.
> +  @retval EFI_DEVICE_ERROR  The system hardware could not map the
> requested address.
> +
> +**/
> +EFI_STATUS
> +IoMmuMap (
> +  IN  EDKII_IOMMU_OPERATION Operation,
> +  IN VOID   *HostAddress,
> +  IN  OUT UINTN *NumberOfBytes,
> +  OUT EFI_PHYSICAL_ADDRESS  *DeviceAddress,
> +  OUT VOID  **Mapping
> +  )
> +{
> +  EFI_STATUS  Status;
> +  UINT64  Attribute;
> +
> +  if (mIoMmu != NULL) {
> +Status = mIoMmu->Map (
> +   mIoMmu,
> +   Operation,

Re: [edk2] [PATCH v2] MdeModulePkg/UfsBlockIoPei: Support IoMmu

[Wu, Hao A]

> -Original Message-
> From: Zeng, Star
> Sent: Thursday, November 16, 2017 6:38 PM
> To: Wu, Hao A; edk2-devel@lists.01.org
> Cc: Wu, Hao A; Yao, Jiewen; Zeng, Star
> Subject: RE: [edk2] [PATCH v2] MdeModulePkg/UfsBlockIoPei: Support IoMmu
> 
> How about calling IoMmuInit () after locating
> gEdkiiPeiUfsHostControllerPpiGuid?
> 
> Same comment to SdBlockIoPei and EmmcBlockIoPei.
> 
> If you agree, Reviewed-by: Star Zeng 

Thanks.

I will update the codes according to your comments when I push the changes.

Also, for the SD/eMMC patch series, do you still need to review them? Or I
can get your R-b with the above-mentioned change?


Best Regards,
Hao Wu

> 
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Hao
> Wu
> Sent: Tuesday, October 31, 2017 11:18 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Yao, Jiewen ;
> Zeng, Star 
> Subject: [edk2] [PATCH v2] MdeModulePkg/UfsBlockIoPei: Support IoMmu
> 
> V2 changes:
> Resource cleanup logic update in UfsEndOfPei().
> 
> V1 history:
> Update the UfsBlockIoPei driver to consume IOMMU_PPI to allocate DMA
> buffer.
> 
> If no IOMMU_PPI exists, this driver still calls PEI service to allocate DMA 
> buffer,
> with assumption that DRAM==DMA.
> 
> This is a compatible change.
> 
> Cc: Star Zeng 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  MdeModulePkg/Bus/Ufs/UfsBlockIoPei/DmaMem.c  | 249
> 
>  MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsBlockIoPei.c   |  60 -
>  MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsBlockIoPei.h   | 141 ++-
>  MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsBlockIoPei.inf |   5 +-
>  MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsHcMem.c|  23 +-
>  MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsHcMem.h|   4 +-
>  MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsHci.c  |  91 +--
>  7 files changed, 535 insertions(+), 38 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/DmaMem.c
> b/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/DmaMem.c
> new file mode 100644
> index 00..0a939a3879
> --- /dev/null
> +++ b/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/DmaMem.c
> @@ -0,0 +1,249 @@
> +/** @file
> +  The DMA memory help function.
> +
> +  Copyright (c) 2017, 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.
> +
> +**/
> +
> +#include "UfsBlockIoPei.h"
> +
> +EDKII_IOMMU_PPI  *mIoMmu;
> +
> +/**
> +  Provides the controller-specific addresses required to access system
> +memory from a
> +  DMA bus master.
> +
> +  @param  Operation Indicates if the bus master is going to read 
> or
> write to system memory.
> +  @param  HostAddress   The system memory address to map to the PCI
> controller.
> +  @param  NumberOfBytes On input the number of bytes to map. On
> output the number of bytes
> +that were mapped.
> +  @param  DeviceAddress The resulting map address for the bus master
> PCI controller to use to
> +access the hosts HostAddress.
> +  @param  Mapping   A resulting value to pass to Unmap().
> +
> +  @retval EFI_SUCCESS   The range was mapped for the returned
> NumberOfBytes.
> +  @retval EFI_UNSUPPORTED   The HostAddress cannot be mapped as a
> common buffer.
> +  @retval EFI_INVALID_PARAMETER One or more parameters are invalid.
> +  @retval EFI_OUT_OF_RESOURCES  The request could not be completed due
> to a lack of resources.
> +  @retval EFI_DEVICE_ERROR  The system hardware could not map the
> requested address.
> +
> +**/
> +EFI_STATUS
> +IoMmuMap (
> +  IN  EDKII_IOMMU_OPERATION Operation,
> +  IN VOID   *HostAddress,
> +  IN  OUT UINTN *NumberOfBytes,
> +  OUT EFI_PHYSICAL_ADDRESS  *DeviceAddress,
> +  OUT VOID  **Mapping
> +  )
> +{
> +  EFI_STATUS  Status;
> +  UINT64  Attribute;
> +
> +  if (mIoMmu != NULL) {
> +Status = mIoMmu->Map (
> +   mIoMmu,
> +   Operation,
> +   HostAddress,
> +   NumberOfBytes,
> +   DeviceAddress,
> +   Mapping
> +   );
> +if (EFI_ERROR (Status)) {
> +  return EFI_OUT_OF_RESOURCES;
> +}
> +switch (Operation) {
> +case 

Re: [edk2] [PATCH V2] MdeModulePkg EhciPei: Support IoMmu

[Yao, Jiewen]

Reviewed-by: jiewen@intel.com

> -Original Message-
> From: Zeng, Star
> Sent: Thursday, November 16, 2017 6:03 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Yao, Jiewen 
> Subject: [PATCH V2] MdeModulePkg EhciPei: Support IoMmu
> 
> V2: Halt HC at EndOfPei.
> 
> Update the EhciPei driver to consume IOMMU_PPI to allocate DMA buffer.
> 
> If no IOMMU_PPI exists, this driver still calls PEI service to allocate
> DMA buffer, with assumption that DRAM==DMA.
> 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng 
> ---
>  MdeModulePkg/Bus/Pci/EhciPei/DmaMem.c| 250
> +++
>  MdeModulePkg/Bus/Pci/EhciPei/EhcPeim.c   |  40 -
>  MdeModulePkg/Bus/Pci/EhciPei/EhcPeim.h   | 119 ++-
>  MdeModulePkg/Bus/Pci/EhciPei/EhciPei.inf |   6 +-
>  MdeModulePkg/Bus/Pci/EhciPei/EhciSched.c |  38 +++--
>  MdeModulePkg/Bus/Pci/EhciPei/EhciUrb.c   |  42 --
>  MdeModulePkg/Bus/Pci/EhciPei/UsbHcMem.c  |  84 +--
>  MdeModulePkg/Bus/Pci/EhciPei/UsbHcMem.h  |  18 ++-
>  8 files changed, 551 insertions(+), 46 deletions(-)
>  create mode 100644 MdeModulePkg/Bus/Pci/EhciPei/DmaMem.c
> 
> diff --git a/MdeModulePkg/Bus/Pci/EhciPei/DmaMem.c
> b/MdeModulePkg/Bus/Pci/EhciPei/DmaMem.c
> new file mode 100644
> index ..1330f53f411a
> --- /dev/null
> +++ b/MdeModulePkg/Bus/Pci/EhciPei/DmaMem.c
> @@ -0,0 +1,250 @@
> +/** @file
> +The DMA memory help functions.
> +
> +Copyright (c) 2017, 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.
> +
> +**/
> +
> +#include "EhcPeim.h"
> +
> +/**
> +  Provides the controller-specific addresses required to access system memory
> from a
> +  DMA bus master.
> +
> +  @param IoMmu  Pointer to IOMMU PPI.
> +  @param Operation  Indicates if the bus master is going to read
> or write to system memory.
> +  @param HostAddressThe system memory address to map to
> the PCI controller.
> +  @param NumberOfBytes  On input the number of bytes to map.
> On output the number of bytes
> +that were mapped.
> +  @param DeviceAddress  The resulting map address for the bus
> master PCI controller to use to
> +access the hosts HostAddress.
> +  @param MappingA resulting value to pass to Unmap().
> +
> +  @retval EFI_SUCCESS   The range was mapped for the returned
> NumberOfBytes.
> +  @retval EFI_UNSUPPORTED   The HostAddress cannot be mapped as a
> common buffer.
> +  @retval EFI_INVALID_PARAMETER One or more parameters are invalid.
> +  @retval EFI_OUT_OF_RESOURCES  The request could not be completed due
> to a lack of resources.
> +  @retval EFI_DEVICE_ERROR  The system hardware could not map the
> requested address.
> +
> +**/
> +EFI_STATUS
> +IoMmuMap (
> +  IN EDKII_IOMMU_PPI*IoMmu,
> +  IN EDKII_IOMMU_OPERATION  Operation,
> +  IN VOID   *HostAddress,
> +  IN OUT UINTN  *NumberOfBytes,
> +  OUT EFI_PHYSICAL_ADDRESS  *DeviceAddress,
> +  OUT VOID  **Mapping
> +  )
> +{
> +  EFI_STATUSStatus;
> +  UINT64Attribute;
> +
> +  if (IoMmu != NULL) {
> +Status = IoMmu->Map (
> +  IoMmu,
> +  Operation,
> +  HostAddress,
> +  NumberOfBytes,
> +  DeviceAddress,
> +  Mapping
> +  );
> +if (EFI_ERROR (Status)) {
> +  return EFI_OUT_OF_RESOURCES;
> +}
> +switch (Operation) {
> +case EdkiiIoMmuOperationBusMasterRead:
> +case EdkiiIoMmuOperationBusMasterRead64:
> +  Attribute = EDKII_IOMMU_ACCESS_READ;
> +  break;
> +case EdkiiIoMmuOperationBusMasterWrite:
> +case EdkiiIoMmuOperationBusMasterWrite64:
> +  Attribute = EDKII_IOMMU_ACCESS_WRITE;
> +  break;
> +case EdkiiIoMmuOperationBusMasterCommonBuffer:
> +case EdkiiIoMmuOperationBusMasterCommonBuffer64:
> +  Attribute = EDKII_IOMMU_ACCESS_READ |
> EDKII_IOMMU_ACCESS_WRITE;
> +  break;
> +default:
> +  ASSERT(FALSE);
> +  return EFI_INVALID_PARAMETER;
> +}
> +Status = IoMmu->SetAttribute (
> +  IoMmu,
> +  *Mapping,
> +  Attribute
> +  );
> +if (EFI_ERROR (Status)) {
> +  IoMmu->Unmap (IoMmu, Mapping);
> +  *Mapping = NULL;
> +  

Re: [edk2] [PATCH v6 3/7] UefiCpuPkg/CpuDxe: Reduce debug message

[Zeng, Star]

According to the definitions, DEBUG_POOL and DEBUG_PAGE are for alloc & free 
pool/page.

#define DEBUG_POOL  0x0010  // Alloc & Free (pool)
#define DEBUG_PAGE  0x0020  // Alloc & Free (page)

How about changing the debug level to DEBUG_VERBOSE?
If you agree, you do not need send a new patch, we can update it when pushing. 
:)


Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J 
Wang
Sent: Tuesday, November 14, 2017 11:11 AM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen ; Dong, Eric 
Subject: [edk2] [PATCH v6 3/7] UefiCpuPkg/CpuDxe: Reduce debug message

Heap guard feature will frequently update page attributes. The debug message in 
CpuDxe driver will slow down the boot performance noticeably. Changing the 
debug level to DEBUG_POOL and DEBUG_PAGE to reduce the message output for 
normal debug configuration.

Cc: Eric Dong 
Cc: Jiewen Yao 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
Reviewed-by: Jiewen Yao 
Regression-tested-by: Laszlo Ersek 
---
 UefiCpuPkg/CpuDxe/CpuPageTable.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c b/UefiCpuPkg/CpuDxe/CpuPageTable.c
index d312eb66f8..5270a1124f 100644
--- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
+++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
@@ -442,8 +442,9 @@ ConvertPageEntryAttribute (
   *PageEntry = NewPageEntry;
   if (CurrentPageEntry != NewPageEntry) {
 *IsModified = TRUE;
-DEBUG ((DEBUG_INFO, "ConvertPageEntryAttribute 0x%lx", CurrentPageEntry));
-DEBUG ((DEBUG_INFO, "->0x%lx\n", NewPageEntry));
+DEBUG ((DEBUG_POOL | DEBUG_PAGE, "ConvertPageEntryAttribute 0x%lx",
+CurrentPageEntry));
+DEBUG ((DEBUG_POOL | DEBUG_PAGE, "->0x%lx\n", NewPageEntry));
   } else {
 *IsModified = FALSE;
   }
--
2.14.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] MdeModulePkg XhciPei: Minor refinement about IoMmu

[Yao, Jiewen]

Reviewed-by: jiewen@intel.com

> -Original Message-
> From: Zeng, Star
> Sent: Thursday, November 16, 2017 6:45 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Yao, Jiewen 
> Subject: [PATCH] MdeModulePkg XhciPei: Minor refinement about IoMmu
> 
> 1. Call IoMmuInit() after locating gPeiUsbControllerPpiGuid.
> 2. Call XhcPeiFreeSched() to do cleanup in XhcEndOfPei.
> 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng 
> ---
>  MdeModulePkg/Bus/Pci/XhciPei/XhcPeim.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/XhciPei/XhcPeim.c
> b/MdeModulePkg/Bus/Pci/XhciPei/XhcPeim.c
> index 99f69f730b3f..c5631e87cacc 100644
> --- a/MdeModulePkg/Bus/Pci/XhciPei/XhcPeim.c
> +++ b/MdeModulePkg/Bus/Pci/XhciPei/XhcPeim.c
> @@ -1427,6 +1427,8 @@ XhcEndOfPei (
> 
>XhcPeiHaltHC (Xhc, XHC_GENERIC_TIMEOUT);
> 
> +  XhcPeiFreeSched (Xhc);
> +
>return EFI_SUCCESS;
>  }
> 
> @@ -1461,8 +1463,6 @@ XhcPeimEntry (
>  return EFI_SUCCESS;
>}
> 
> -  IoMmuInit ();
> -
>Status = PeiServicesLocatePpi (
>   ,
>   0,
> @@ -1473,6 +1473,8 @@ XhcPeimEntry (
>  return EFI_UNSUPPORTED;
>}
> 
> +  IoMmuInit ();
> +
>Index = 0;
>while (TRUE) {
>  Status = UsbControllerPpi->GetUsbController (
> --
> 2.7.0.windows.1

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

Re: [edk2] [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

[Yao, Jiewen]

HI
I have 2 comments:

1) I do not think we need mention: WORKAROUND.
I suggest we just use "NOTE".

We have similar example before, see MdePkg\Library\BasePeCoffLib\BasePeCoff.c
  //
  // NOTE: Some versions of Linux ELILO for Itanium have an incorrect magic 
value 
  //   in the PE/COFF Header.  If the MachineType is Itanium(IA64) and the 
  //   Magic value in the OptionalHeader is  
EFI_IMAGE_NT_OPTIONAL_HDR32_MAGIC
  //   then override the returned value to EFI_IMAGE_NT_OPTIONAL_HDR64_MAGIC
  //

2) I agree with Star. I think we should merge the final result.
The suggestion before is: *Keep current UEFI memory map unchanged.*
Changing it brings lots of risk without validating all UEFI OS.


Thank you
Yao Jiewen


> -Original Message-
> From: Wang, Jian J
> Sent: Thursday, November 16, 2017 3:27 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Zeng, Star ;
> Laszlo Ersek ; Ard Biesheuvel 
> Subject: [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging 
> capabilities
> 
> Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really
> set attributes and change memory paging attribute accordingly.
> But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
> value from Capabilities in GCD memory map. This might cause
> boot problems. Clearing all paging related capabilities can
> workaround it. The code added in this patch is supposed to
> be removed once the usage of EFI_MEMORY_DESCRIPTOR.Attribute
> is clarified in UEFI spec and adopted by both EDK-II Core and
> all supported OSs.
> 
> Cc: Jiewen Yao 
> Cc: Star Zeng 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  MdeModulePkg/Core/Dxe/Mem/Page.c | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c
> b/MdeModulePkg/Core/Dxe/Mem/Page.c
> index c9219cc068..783b576e35 100644
> --- a/MdeModulePkg/Core/Dxe/Mem/Page.c
> +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
> @@ -1829,6 +1829,23 @@ CoreGetMemoryMap (
>//
>BufferSize = ((UINT8 *)MemoryMap - (UINT8 *)MemoryMapStart);
> 
> +  //
> +  // WORKAROUND: Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute
> as really
> +  // set attributes and change memory paging attribute
> accordingly.
> +  // But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned
> by
> +  // value from Capabilities in GCD memory map. This might
> cause
> +  // boot problems. Clearing all paging related capabilities can
> +  // workaround it. Following code is supposed to be removed
> once
> +  // the usage of EFI_MEMORY_DESCRIPTOR.Attribute is clarified
> in
> +  // UEFI spec and adopted by both EDK-II Core and all
> supported
> +  // OSs.
> +  //
> +  while (MemoryMapStart < MemoryMap) {
> +MemoryMapStart->Attribute &= ~(UINT64)(EFI_MEMORY_RP |
> EFI_MEMORY_RO |
> +   EFI_MEMORY_XP);
> +MemoryMapStart = NEXT_MEMORY_DESCRIPTOR(MemoryMapStart,
> Size);
> +  }
> +
>Status = EFI_SUCCESS;
> 
>  Done:
> --
> 2.14.1.windows.1

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

Re: [edk2] SCT Test crashes After HTTPS boot success.

[Wu, Jiaxin]

Hi Karunakar,

Can you provide more detailed info for the SCT test steps? The crash can happen 
after "Sct.efi -u" or need run any specific test case?

Thanks,
Jiaxin

From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Thursday, November 16, 2017 4:48 PM
To: 'edk2-devel@lists.01.org' 
Cc: Wu, Jiaxin ; Fu, Siyuan ; Ye, 
Ting 
Subject: SCT Test crashes After HTTPS boot success.

Hello All,

When I do SCT test, get the below failure
GenericTest\EFICompliantTest 0 0 CB6F7B77-0B15-43F7-A95B-8C7F9FD70B21 FAIL UEFI 
Compliant - TLS support is required

The reason for the failure is that the platform doesn't have TLS related 
protocols installed.

->if the platform supports TLS feature then, EFI_TLS_PROTOCOL, 
EFI_TLS_SERVICE_BINDING_PROTOCOL, EFI_TLS_CONFIGURATION_PROTOCOL must be 
existed.
-> According UEFI2.7 Spec - 28.10 EFI TLS Protocols(page-1787)
The TLS consumer need locate EFI_TLS_SERVICE_BINDING_PROTOCOL and call 
CreateChild() to create a new child of EFI_TLS_PROTOCOL instance. Then use 
EFI_TLS_PROTOCOL to start TLS session. After use, the TLS consumer need call 
DestroyChild() to destroy it.
-> Network Stack follows same in HTTPS boot.
While doing IPv4/6 HTTPS boot , will locate gEfiTlsServiceBindingProtocolGuid 
and call TlsServiceBindingCreateChild, So that EFI_TLS_PROTOCOL and 
EFI_TLS_CONFIGURATION_PROTOCOL will be installed.

So once HTTPS boot is success then TLS supported protocols exist.

And if we do SCT test after HTTPS boot is success, Then TLS related failures 
should NOT happen in SCT.

I've tried SCT test after HTTPS boot success, But SCT test Crashes.

[Steps to reproduce]

1.   Configure the HTTPS Server with EFI Shell as NBP file.

2.   Connect test machine and HTTPS server with LAN cable.

3.   Perform HTTPS boot in test machine

4.   Once HTTPS boot is success, It will launch Shell.

5.   Run SCT test


[Observations]

1.   SCT test was crashed and unable to continue the test.

Could you please provide your comments/Suggestion on this?


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

Re: [edk2] [PATCH v2 1/2] MdeModulePkg/PartitionDxe: Merge the discovery of ElTorito into UDF

[Paulo Alcantara]

On Thu, November 16, 2017 5:47 am, Hao Wu wrote:
> In order to create all of the children (El Torito standard and UDF) for
> a CD/DVD media in an entry of the PartitionDriverBindingStart(), this
> commit merges the discovery of the El Torito feature
> (PartitionInstallElToritoChildHandles) into function
> PartitionInstallUdfChildHandles.
>
> Cc: Paulo Alcantara 
> Cc: Ruiyu Ni 
> Cc: Star Zeng 
> Cc: Eric Dong 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c |  7 +++--
>  MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c   | 27
> ++--
>  2 files changed, 28 insertions(+), 6 deletions(-)

Reviewed-by: Paulo Alcantara 

Thanks!
Paulo

>
> diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c
> b/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c
> index f6030e0897..603abfe55a 100644
> --- a/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c
> +++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c
> @@ -43,7 +43,6 @@ EFI_DRIVER_BINDING_PROTOCOL gPartitionDriverBinding = {
>  //
>  PARTITION_DETECT_ROUTINE mPartitionDetectRoutineTable[] = {
>PartitionInstallGptChildHandles,
> -  PartitionInstallElToritoChildHandles,
>PartitionInstallMbrChildHandles,
>PartitionInstallUdfChildHandles,
>NULL
> @@ -306,9 +305,9 @@ PartitionDriverBindingStart (
>if (BlockIo->Media->MediaPresent ||
>(BlockIo->Media->RemovableMedia &&
> !BlockIo->Media->LogicalPartition)) {
>  //
> -// Try for GPT, then El Torito, then UDF, and then legacy MBR
> partition
> -// types. If the media supports a given partition type install child
> handles
> -// to represent the partitions described by the media.
> +// Try for GPT, then legacy MBR partition types, and then UDF and El
> Torito.
> +// If the media supports a given partition type install child handles
> to
> +// represent the partitions described by the media.
>  //
>  Routine = [0];
>  while (*Routine != NULL) {
> diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c
> b/MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c
> index 7eee748958..5aac5640f6 100644
> --- a/MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c
> +++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c
> @@ -688,8 +688,10 @@ PartitionInstallUdfChildHandles (
>EFI_PARTITION_INFO_PROTOCOL  PartitionInfo;
>EFI_LBA  StartingLBA;
>EFI_LBA  EndingLBA;
> +  BOOLEAN  ChildCreated;
>
>Media = BlockIo->Media;
> +  ChildCreated = FALSE;
>
>//
>// Check if UDF logical block size is multiple of underlying device
> block size
> @@ -704,11 +706,29 @@ PartitionInstallUdfChildHandles (
>}
>
>//
> +  // Detect El Torito feature first.
> +  // And always continue to search for UDF.
> +  //
> +  Status = PartitionInstallElToritoChildHandles (
> + This,
> + Handle,
> + DiskIo,
> + DiskIo2,
> + BlockIo,
> + BlockIo2,
> + DevicePath
> + );
> +  if (!EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_INFO, "PartitionDxe: El Torito standard found on handle
> 0x%p.\n", Handle));
> +ChildCreated = TRUE;
> +  }
> +
> +  //
>// Search for an UDF file system on block device
>//
>Status = FindUdfFileSystem (BlockIo, DiskIo, , );
>if (EFI_ERROR (Status)) {
> -return EFI_NOT_FOUND;
> +return (ChildCreated ? EFI_SUCCESS : EFI_NOT_FOUND);
>}
>
>//
> @@ -735,6 +755,9 @@ PartitionInstallUdfChildHandles (
>  EndingLBA,
>  Media->BlockSize
>  );
> +  if (EFI_ERROR (Status)) {
> +return (ChildCreated ? EFI_SUCCESS : Status);
> +  }
>
> -  return Status;
> +  return EFI_SUCCESS;
>  }
> --
> 2.12.0.windows.1
>
>


-- 
Paulo Alcantara, HP Inc.
Speaking for myself only.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC v2 1/3] UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support

[Paulo Alcantara]

Hi Brijan,

On Thu, November 16, 2017 1:43 pm, Brian J. Johnson
>
> (These comments apply to patch 3/3 as well.)
>
> Typo:  UnwondStacksCount should be UnwoundStacksCount

Fixed in v3. Thanks!

>
> It's good to check the alignment of the stack, as you're doing.  But
> I'll reiterate that you absolutely need some better sanity checking of
> the stack and IP addresses before you dereference them.  Remember that
> they could be absolutely *anything* at the entry to this code.
> Something caused an error, and it may have been one of those registers.

Yes - you're absolutely right. I currently have no idea how to validate
those values as well as didn't have time to do so. Sorry. I hope to get to
it ASAP or someone could help me with that.

>
> Also, if the code was built with a compiler which isn't using RBP as a
> base pointer, RBP is unlikely to contain a stack address.  That will
> cause issues if you use it for unwinding without a sanity check.

Yes. I haven't figured out how to do that yet. It's also in my TODO list.

Thank you very much for the suggestions!

Paulo

>
> Thanks,
> Brian
>
>> ---
>>   UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c |
>> 369 +++-
>>   1 file changed, 367 insertions(+), 2 deletions(-)
>>
>> diff --git
>> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
>> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
>> index 65f0cff680..11cd7c9e1c 100644
>> ---
>> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
>> +++
>> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
>> @@ -14,6 +14,11 @@
>>
>>   #include "CpuExceptionCommon.h"
>>
>> +//
>> +// Unknown PDB file name
>> +//
>> +GLOBAL_REMOVE_IF_UNREFERENCED CONST CHAR8 *mUnknownPdbFileName =
>> "";
>> +
>>   /**
>> Return address map of exception handler template so that C code can
>> generate
>> exception tables.
>> @@ -242,6 +247,350 @@ DumpCpuContext (
>>   );
>>   }
>>
>> +/**
>> +  Get absolute path and file name of PDB file in PE/COFF image.
>> +
>> +  @param[in]  ImageBaseBase address of PE/COFF image.
>> +  @param[out] PdbAbsoluteFilePath  Absolute path of PDB file.
>> +  @param[out] PdbFileName  File name of PDB file.
>> +**/
>> +STATIC
>> +VOID
>> +GetPdbFileName (
>> +  IN  UINTNImageBase,
>> +  OUT CHAR8**PdbAbsoluteFilePath,
>> +  OUT CHAR8**PdbFileName
>> +  )
>> +{
>> +  VOID   *PdbPointer;
>> +  CHAR8  *Str;
>> +
>> +  //
>> +  // Get PDB file name from PE/COFF image
>> +  //
>> +  PdbPointer = PeCoffLoaderGetPdbPointer ((VOID *)ImageBase);
>> +  if (PdbPointer == NULL) {
>> +//
>> +// No PDB file name found. Set it to an unknown file name.
>> +//
>> +*PdbFileName = (CHAR8 *)mUnknownPdbFileName;
>> +if (PdbAbsoluteFilePath != NULL) {
>> +  *PdbAbsoluteFilePath = NULL;
>> +}
>> +  } else {
>> +//
>> +// Get file name portion out of PDB file in PE/COFF image
>> +//
>> +Str = (CHAR8 *)((UINTN)PdbPointer +
>> +AsciiStrLen ((CHAR8 *)PdbPointer) - sizeof *Str);
>> +for (; *Str != '/' && *Str != '\\'; Str--) {
>> +  ;
>> +}
>> +
>> +//
>> +// Set PDB file name (also skip trailing path separator: '/' or
>> '\\')
>> +//
>> +*PdbFileName = Str + 1;
>> +
>> +if (PdbAbsoluteFilePath != NULL) {
>> +  //
>> +  // Set absolute file path of PDB file
>> +  //
>> +  *PdbAbsoluteFilePath = PdbPointer;
>> +}
>> +  }
>> +}
>> +
>> +/**
>> +  Dump stack contents.
>> +
>> +  @param[in]  CurrentRsp Current stack pointer address.
>> +  @param[in]  UnwondStacksCount  Count of unwond stack frames.
>> +**/
>> +STATIC
>> +VOID
>> +DumpStackContents (
>> +  IN UINT64  CurrentRsp,
>> +  IN INTNUnwondStacksCount
>> +  )
>> +{
>> +  //
>> +  // Check for proper stack pointer alignment
>> +  //
>> +  if (((UINTN)CurrentRsp & (CPU_STACK_ALIGNMENT - 1)) != 0) {
>> +InternalPrintMessage (" Unaligned stack pointer. \n");
>> +return;
>> +  }
>> +
>> +  //
>> +  // Dump out stack contents
>> +  //
>> +  InternalPrintMessage ("\nStack dump:\n");
>> +  while (UnwondStacksCount-- > 0) {
>> +InternalPrintMessage (
>> +  "0x%016lx: %016lx %016lx\n",
>> +  CurrentRsp,
>> +  *(UINT64 *)CurrentRsp,
>> +  *(UINT64 *)((UINTN)CurrentRsp + 8)
>> +  );
>> +
>> +//
>> +// Point to next stack
>> +//
>> +CurrentRsp += CPU_STACK_ALIGNMENT;
>> +  }
>> +}
>> +
>> +/**
>> +  Dump all image module names from call stack.
>> +
>> +  @param[in]  SystemContext  Pointer to EFI_SYSTEM_CONTEXT.
>> +**/
>> +STATIC
>> +VOID
>> +DumpImageModuleNames (
>> +  IN EFI_SYSTEM_CONTEXT   SystemContext
>> +  )
>> +{
>> +  EFI_STATUS  Status;
>> +  UINT64  Rip;
>> +  UINTN   ImageBase;
>> +  VOID*EntryPoint;
>> +  CHAR8   *PdbAbsoluteFilePath;
>> +  CHAR8   *PdbFileName;
>> +  UINT64  Rbp;
>> +
>> +  //
>> +  // Set 

Re: [edk2] [PATCH v2 2/2] ArmVirtPkg: switch to new PL011UartLib implementation

[Laszlo Ersek]

On 11/16/17 18:47, Ard Biesheuvel wrote:
> Switch to the new, cleaned up PL011UartLib implementation so we will
> be able to remove the old one.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmVirtPkg/ArmVirt.dsc.inc| 2 +-
>  ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c | 5 
> ++---
>  ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.c  | 5 
> ++---
>  3 files changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
> index c92a69281ae4..50eb8675d1c0 100644
> --- a/ArmVirtPkg/ArmVirt.dsc.inc
> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
> @@ -106,7 +106,7 @@ [LibraryClasses.common]
>
> RealTimeClockLib|ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.inf
>TimeBaseLib|EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf
># ARM PL011 UART Driver
> -  PL011UartLib|ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.inf
> +  PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
>
> SerialPortLib|ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.inf
>  
>#
> diff --git 
> a/ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c 
> b/ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c
> index e28750f3b4c4..d9fd0ef98359 100644
> --- a/ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c
> +++ b/ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c
> @@ -16,14 +16,13 @@
>  
>  **/
>  
> -#include 
> +#include 
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  
> -#include 
> -
>  RETURN_STATUS
>  EFIAPI
>  SerialPortInitialize (
> diff --git a/ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.c 
> b/ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.c
> index 05d3547fda91..c161dd6349d3 100644
> --- a/ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.c
> +++ b/ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.c
> @@ -17,9 +17,10 @@
>  
>  **/
>  
> -#include 
> +#include 
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -28,8 +29,6 @@
>  #include 
>  #include 
>  
> -#include 
> -
>  STATIC UINTN mSerialBaseAddress;
>  
>  RETURN_STATUS
> 

Awesome idea!

One comment: can you please check whether, if you replace

#include 

with

#include 

then stuff will still build?

Both SerialPortLib instances are BASE, so we should not include 
(in particular  included by it).

If it works, then:

Reviewed-by: Laszlo Ersek 

If it doesn't work, then I think we should figure out why not; it could
be a sign of some layering violation, which would be nice to document at
least in the commit message.

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

Re: [edk2] [RFC v2 1/3] UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support

[Paulo Alcantara]

Hi Jiewen,

On Wed, November 15, 2017 11:57 pm, Yao, Jiewen wrote:
> Hi Paulo
> Thanks to bring this cool feature.
>
> I have same feeling as Jeff Fan. It is great!
>
> I have some questions, hope you can clarify.
> 1) Would you please let us know which tool change is validated? Such as
> MSVC, or GCC?

GCC only. This should not work on MSVC because it relies on frame pointers.

> 2) Would you please let us know which phase is validated? Such as PEI
> PreMemory, PEI PostMemory, DXE, SMM?

DXE. I'm currently testing it by placing a random "CpuBreakpoint ()" in
PartitionDxe driver.

> 3) Would you please let us know if there is any special condition
> validated? Such as code is in an interrupt handler, SMM initialization
> code, thunk code during mode switch, etc.
> I ask this because I have seen lots of discussion on sanity check, to
> avoid double exception.

At the moment I'm only ensuring proper aligned RSP and ESP values. But we
still need to validate the RIP values, etc. as Andrew and Brian suggested.

> 4) We supported some security feature to create a hole in normal memory
> map, such as PageGuard, StackGuard, SMM communication protection, etc.
> Accessing those memory directly will cause #PF immediately.
> Would you please let us know how we detect that case, to avoid RIP or RSP
> fail to the non-present page?

Sorry. I have no idea :-( I'd hope to get some help from you guys.

> 5) May I know why we check RIP < ImageBase? Is that legal or illegal if
> RIP > ImageBase+ImageSize, but RIP in another PE/COFF image?

That check was a wrong assumption that I had in the beginning. RIP may
point to either lower or higher addresses where the other PE/COFF images
are located. Fixed it in v3.

Sorry for the delay in the response. I'm only able to work on this in my
free time.

Thanks!
Paulo

>> +//
>> +// Check if RIP is within another PE/COFF image base address
>> +//
>> +if (Rip < ImageBase) {
>> +  //
>> +  // Search for the respective PE/COFF image based on RIP
>> +  //
>
> Thank you
> Yao Jiewen
>
>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Paulo
>> Alcantara
>> Sent: Thursday, November 16, 2017 9:18 AM
>> To: edk2-devel@lists.01.org
>> Cc: Laszlo Ersek ; Dong, Eric 
>> Subject: [edk2] [RFC v2 1/3] UefiCpuPkg/CpuExceptionHandlerLib/X64: Add
>> stack
>> trace support
>>
>> This patch adds stack trace support during a X64 CPU exception.
>>
>> It will dump out back trace, stack contents as well as image module
>> names that were part of the call stack.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Cc: Eric Dong 
>> Cc: Laszlo Ersek 
>> Signed-off-by: Paulo Alcantara 
>> ---
>>  UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c |
>> 369
>> +++-
>>  1 file changed, 367 insertions(+), 2 deletions(-)
>>
>> diff --git
>> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
>> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
>> index 65f0cff680..11cd7c9e1c 100644
>> ---
>> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
>> +++
>> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
>> @@ -14,6 +14,11 @@
>>
>>  #include "CpuExceptionCommon.h"
>>
>> +//
>> +// Unknown PDB file name
>> +//
>> +GLOBAL_REMOVE_IF_UNREFERENCED CONST CHAR8
>> *mUnknownPdbFileName = "";
>> +
>>  /**
>>Return address map of exception handler template so that C code can
>> generate
>>exception tables.
>> @@ -242,6 +247,350 @@ DumpCpuContext (
>>  );
>>  }
>>
>> +/**
>> +  Get absolute path and file name of PDB file in PE/COFF image.
>> +
>> +  @param[in]  ImageBaseBase address of PE/COFF image.
>> +  @param[out] PdbAbsoluteFilePath  Absolute path of PDB file.
>> +  @param[out] PdbFileName  File name of PDB file.
>> +**/
>> +STATIC
>> +VOID
>> +GetPdbFileName (
>> +  IN  UINTNImageBase,
>> +  OUT CHAR8**PdbAbsoluteFilePath,
>> +  OUT CHAR8**PdbFileName
>> +  )
>> +{
>> +  VOID   *PdbPointer;
>> +  CHAR8  *Str;
>> +
>> +  //
>> +  // Get PDB file name from PE/COFF image
>> +  //
>> +  PdbPointer = PeCoffLoaderGetPdbPointer ((VOID *)ImageBase);
>> +  if (PdbPointer == NULL) {
>> +//
>> +// No PDB file name found. Set it to an unknown file name.
>> +//
>> +*PdbFileName = (CHAR8 *)mUnknownPdbFileName;
>> +if (PdbAbsoluteFilePath != NULL) {
>> +  *PdbAbsoluteFilePath = NULL;
>> +}
>> +  } else {
>> +//
>> +// Get file name portion out of PDB file in PE/COFF image
>> +//
>> +Str = (CHAR8 *)((UINTN)PdbPointer +
>> +AsciiStrLen ((CHAR8 *)PdbPointer) - sizeof *Str);
>> +for (; *Str != '/' && *Str != '\\'; Str--) {
>> +  ;
>> +}
>> +
>> +//
>> +// Set PDB file name (also skip trailing path separator: 

Re: [edk2] [RFC v2 0/3] Stack trace support in X64 exception handling

[Paulo Alcantara]

Hi Andrew,

On Thu, November 16, 2017 3:01 am, Andrew Fish wrote:
> Paulo,
>
> Those attached stack traces don't look right.

What about the new ones?

Thanks!
Paulo

>
> Thanks,
>
> Andrew Fish
>
>> On Nov 15, 2017, at 5:46 PM, Paulo Alcantara  wrote:
>>
>> Hi,
>>
>> On 11/15/2017 11:18 PM, Paulo Alcantara wrote:
>>> Hi,
>>> This series adds stack trace support during a X64 CPU exception.
>>> Informations like back trace, stack contents and image module names
>>> (that were part of the call stack) will be dumped out.
>>> We already have such support in ARM/AArch64 (IIRC) exception handling
>>> (thanks to Ard), and then I thought we'd also deserve it in X64 and
>>> IA-32 platforms.
>>> What do you think guys?
>>> BTW, I've tested this only with OVMF (X64 only), using:
>>>   - gcc-6.3.0, GCC5, NOOPT
>>> Any other tests  would be really appreciable.
>>> Thanks!
>>> Paulo
>>> Repo:   https://github.com/pcacjr/edk2.git
>>> Branch: stacktrace_v2
>>> Cc: Rick Bramley 
>>> Cc: Andrew Fish 
>>> Cc: Eric Dong 
>>> Cc: Laszlo Ersek 
>>> Cc: "Brian J. Johnson" 
>>> Cc: Jeff Fan 
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Paulo Alcantara 
>>> ---
>>> v1 -> v2:
>>>   * Add IA32 arch support (GCC toolchain only)
>>>   * Replace hard-coded stack alignment value (16) with
>>> CPU_STACK_ALIGNMENT.
>>>   * Check for proper stack and frame pointer alignments.
>>>   * Fix initialization of UnwoundStacksCount to 1.
>>>   * Move GetPdbFileName() to common code since it will be used by both
>>> IA32 and X64 implementations.
>>
>> Sorry for the delay in sending v2. It's holiday here :-)
>>
>> FWIW, I've attached two files which contain stack trace dumps of IA32
>> and X64 exceptions.
>>
>> The new IA32 arch support is still limited to GCC only (that is, relying
>> on frame pointers), but I'll start investing in a new solution that
>> would work on both MSVC and GCC toolchains -- probably this weekend. If
>> I come up with something, I'll let you know.
>>
>> On IA32, I performed the same test as in X64 to trigger an NMI interrupt
>> manually with: asm ("int $0x2") in PartitionDxe driver and watched out
>> the call stack. The difference between the two dumps, regardless the CPU
>> context, etc. is that we don't see the calls from PeiCore.dll. Then I
>> figured out that the EIP gets a value of 0 before jumping to
>> PartitionDxe's entry point.
>>
>> I guess that's related to the "push $0" that Andrew mentioned earlier so
>> the debugger knows when to stop unwinding. Although I can't see a "push
>> 0" equivalent neither in SwitchStack.nasm nor in SwitchStack.asm for X64
>> -- so we're able to see the calls within PeiCore.dll.
>>
>> Thanks!
>> Paulo
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org 
>> https://lists.01.org/mailman/listinfo/edk2-devel
>> 
>


-- 
Paulo Alcantara, HP Inc.
Speaking for myself only. IA32 Exception Type - 03(#BP - Breakpoint)  CPU Apic ID -  
EIP  - 7DBCD580, CS  - 0010, EFLAGS - 0206
EAX  - , ECX - 7EEC8CFF, EDX - 7ED9C220, EBX - 
ESP  - 7EEC8DDC, EBP - 7EEC8DDC, ESI - 0004, EDI - 
DS   - 0008, ES  - 0008, FS  - 0008, GS  - 0008, SS - 0008
CR0  - 0033, CR2 - , CR3 - , CR4 - 0640
DR0  - , DR1 - , DR2 - , DR3 - 
DR6  - 0FF0, DR7 - 0400
GDTR - 7EE97A90 0047, IDTR - 7E65B010 07FF
LDTR - , TR - 
FXSAVE_STATE - 7EEC8B20

Call trace:
0 0x7DBCD580 @ 0x7DBCD000+0x57F (0x7EEC8DDC) in PartitionDxe.dll
1 0x7DBD41BE @ 0x7DBCD000+0x71BD (0x7EEC8DFC) in PartitionDxe.dll
2 0x7DBD456C @ 0x7DBCD000+0x756B (0x7EEC8E1C) in PartitionDxe.dll
3 0x7DBCF7F4 @ 0x7DBCD000+0x27F3 (0x7EEC8E4C) in PartitionDxe.dll
4 0x7EED9EA4 @ 0x7EEC9000+0x10EA3 (0x7EEC8E9C) in DxeCore.dll
5 0x7EEF1A8C @ 0x7EEC9000+0x28A8B (0x7EEC8EDC) in DxeCore.dll
6 0x7EEF3DD0 @ 0x7EEC9000+0x2ADCF (0x7EEC8FAC) in DxeCore.dll
7 0x7EEF44A5 @ 0x7EEC9000+0x2B4A4 (0x7EEC8FCC) in DxeCore.dll
8 0x7EECD272 @ 0x7EEC9000+0x4271 (0x7EEC8FEC) in DxeCore.dll

PartitionDxe.dll (ImageBase=0x7DBCD000, EntryPoint=0x7DBCF71B):
/home/pcacjr/src/edk2/Build/OvmfIa32/NOOPT_GCC5/IA32/MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe/DEBUG/PartitionDxe.dll
DxeCore.dll (ImageBase=0x7EEC9000, EntryPoint=0x7EECD259):
/home/pcacjr/src/edk2/Build/OvmfIa32/NOOPT_GCC5/IA32/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll

Stack dump:
0x7EEC8DDC: 7EEC8DFC 7DBD41BE
0x7EEC8DE0: 7DBD41BE 7EAA1690
0x7EEC8DE4: 7EAA1690 7EEFC520
0x7EEC8DE8: 7EEFC520 7EEC8E1C
0x7EEC8DEC: 7EEC8E1C 7DBD44EA
0x7EEC8DF0: 7DBD44EA 7E10E010
0x7EEC8DF4: 7E10E010 7EE97010
0x7EEC8DF8: 7EE97010 7EEC8E1C
0x7EEC8DFC: 7EEC8E1C 

[edk2] [RFC v3 0/3] Stack trace support in X64 exception handling

[Paulo Alcantara]

Hi,

This series adds stack trace support during a X64 CPU exception.

Informations like back trace, stack contents and image module names
(that were part of the call stack) will be dumped out.

We already have such support in ARM/AArch64 (IIRC) exception handling
(thanks to Ard), and then I thought we'd also deserve it in X64 and
IA-32 platforms.

What do you think guys?

BTW, I've tested this only with OVMF (X64 only), using:
  - gcc-6.3.0, GCC5, NOOPT

Any other tests  would be really appreciable.

Thanks!
Paulo

Repo:   https://github.com/pcacjr/edk2.git
Branch: stacktrace_v2

Cc: Rick Bramley 
Cc: Andrew Fish 
Cc: Eric Dong 
Cc: Laszlo Ersek 
Cc: brian.john...@hpe.com
Cc: jiewen@intel.com
Cc: Jeff Fan 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Paulo Alcantara 
---

v1 -> v2:
  * Add IA32 arch support (GCC toolchain only)
  * Replace hard-coded stack alignment value (16) with
CPU_STACK_ALIGNMENT.
  * Check for proper stack and frame pointer alignments.
  * Fix initialization of UnwoundStacksCount to 1.
  * Move GetPdbFileName() to common code since it will be used by both
IA32 and X64 implementations.

v2 -> v3:
  * Fixed wrong assumption about "RIP < ImageBase" to start searching
for another PE/COFF image. That is, RIP may point to lower and
higher addresses for any other PE/COFF images. Both IA32 & X64.
(Thanks Andrew & Jiewen)
  * Fixed typo: unwond -> unwound. Both IA32 & X64. (Thanks Brian)

Brian: I didn't have a chance to investigate on how to validate the RIP
and RSP values yet as you've suggested, sorry. But I will any time soon.

NOTE: This RFC for stack trace in IA32 & X64 supports *only* GCC at the
moment.

Paulo Alcantara (3):
  UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support
  UefiCpuPkg/CpuExceptionHandlerLib: Export GetPdbFileName()
  UefiCpuPkg/CpuExceptionHandlerLib/Ia32: Add stack trace support

 UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c| 102 
---
 UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h|  25 +-
 UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c | 310 
++-
 UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c  | 317 
+++-
 4 files changed, 696 insertions(+), 58 deletions(-)

-- 
2.14.3

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

[edk2] [RFC v3 3/3] UefiCpuPkg/CpuExceptionHandlerLib/Ia32: Add stack trace support

[Paulo Alcantara]

This patch adds stack trace support during a IA32 CPU exception.

It will dump out back trace, stack contents as well as image module
names that were part of the call stack.

Contributed-under: TianoCore Contribution Agreement 1.1
Cc: Eric Dong 
Cc: Laszlo Ersek 
Signed-off-by: Paulo Alcantara 
---
 UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c|  42 ---
 UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h|  11 -
 UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c | 310 
+++-
 3 files changed, 308 insertions(+), 55 deletions(-)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
index f62ab8c48c..867c5c01d6 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
@@ -109,48 +109,6 @@ InternalPrintMessage (
   SerialPortWrite ((UINT8 *)Buffer, AsciiStrLen (Buffer));
 }
 
-/**
-  Find and display image base address and return image base and its entry 
point.
-
-  @param CurrentEip  Current instruction pointer.
-
-**/
-VOID
-DumpModuleImageInfo (
-  IN  UINTN  CurrentEip
-  )
-{
-  EFI_STATUS   Status;
-  UINTNPe32Data;
-  VOID *PdbPointer;
-  VOID *EntryPoint;
-
-  Pe32Data = PeCoffSearchImageBase (CurrentEip);
-  if (Pe32Data == 0) {
-InternalPrintMessage (" Can't find image information. \n");
-  } else {
-//
-// Find Image Base entry point
-//
-Status = PeCoffLoaderGetEntryPoint ((VOID *) Pe32Data, );
-if (EFI_ERROR (Status)) {
-  EntryPoint = NULL;
-}
-InternalPrintMessage (" Find image ");
-PdbPointer = PeCoffLoaderGetPdbPointer ((VOID *) Pe32Data);
-if (PdbPointer != NULL) {
-  InternalPrintMessage ("%a", PdbPointer);
-} else {
-  InternalPrintMessage ("(No PDB) " );
-}
-InternalPrintMessage (
-  " (ImageBase=%016lp, EntryPoint=%016p) \n",
-  (VOID *) Pe32Data,
-  EntryPoint
-  );
-  }
-}
-
 /**
   Read and save reserved vector information
 
diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
index 042207025e..478374d003 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
@@ -119,17 +119,6 @@ InternalPrintMessage (
   ...
   );
 
-/**
-  Find and display image base address and return image base and its entry 
point.
-
-  @param CurrentEip  Current instruction pointer.
-
-**/
-VOID
-DumpModuleImageInfo (
-  IN  UINTN  CurrentEip
-  );
-
 /**
   Display CPU information.
 
diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c
index f2c39eb193..db8013a5af 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c
@@ -210,6 +210,296 @@ DumpCpuContext (
 );
 }
 
+/**
+  Dump stack trace.
+
+  @param[in]  SystemContext  Pointer to EFI_SYSTEM_CONTEXT.
+  @param[out] UnwoundStacksCount  Count of unwound stack frames.
+**/
+STATIC
+VOID
+DumpStackTrace (
+  IN  EFI_SYSTEM_CONTEXT   SystemContext,
+  OUT INTN *UnwoundStacksCount
+  )
+{
+  UINT32  Eip;
+  UINT32  Ebp;
+  UINTN   ImageBase;
+  CHAR8   *PdbFileName;
+
+  //
+  // Set current EIP address
+  //
+  Eip = SystemContext.SystemContextIa32->Eip;
+
+  //
+  // Set current frame pointer address
+  //
+  Ebp = SystemContext.SystemContextIa32->Ebp;
+
+  //
+  // Check for proper frame pointer alignment
+  //
+  if (((UINTN)Ebp & (CPU_STACK_ALIGNMENT - 1)) != 0) {
+InternalPrintMessage (" Unaligned frame pointer. \n");
+return;
+  }
+
+  //
+  // Get initial PE/COFF image base address from current EIP
+  //
+  ImageBase = PeCoffSearchImageBase (Eip);
+  if (ImageBase == 0) {
+InternalPrintMessage (" Could not find backtrace information. ");
+return;
+  }
+
+  //
+  // Get PDB file name from initial PE/COFF image
+  //
+  GetPdbFileName (ImageBase, NULL, );
+
+  //
+  // Initialize count of unwound stacks
+  //
+  *UnwoundStacksCount = 1;
+
+  //
+  // Print out back trace
+  //
+  InternalPrintMessage ("\nCall trace:\n");
+
+  for (;;) {
+//
+// Print stack frame in the following format:
+//
+// #  @ + (EBP) in [ | ]
+//
+InternalPrintMessage (
+  "%d 0x%08x @ 0x%08x+0x%x (0x%08x) in %a\n",
+  *UnwoundStacksCount - 1,
+  Eip,
+  ImageBase,
+  Eip - ImageBase - 1,
+  Ebp,
+  PdbFileName
+  );
+
+//
+// Set 

[edk2] [RFC v3 2/3] UefiCpuPkg/CpuExceptionHandlerLib: Export GetPdbFileName()

[Paulo Alcantara]

This function will be used by both IA32 and X64 exception handling in
order to print out image module names during stack unwinding.

Cc: Eric Dong 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Paulo Alcantara 
---
 UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c   | 60 
+++-
 UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h   | 14 +
 UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c | 59 
---
 3 files changed, 73 insertions(+), 60 deletions(-)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
index dbfaae1d30..f62ab8c48c 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
@@ -54,6 +54,11 @@ CONST CHAR8 *mExceptionNameStr[] = {
 
 #define EXCEPTION_KNOWN_NAME_NUM  (sizeof (mExceptionNameStr) / sizeof (CHAR8 
*))
 
+//
+// Unknown PDB file name
+//
+GLOBAL_REMOVE_IF_UNREFERENCED CONST CHAR8 *mUnknownPdbFileName = "";
+
 /**
   Get ASCII format string exception name by exception type.
 
@@ -177,4 +182,57 @@ ReadAndVerifyVectorInfo (
 VectorInfo ++;
   }
   return EFI_SUCCESS;
-}
\ No newline at end of file
+}
+
+/**
+  Get absolute path and file name of PDB file in PE/COFF image.
+
+  @param[in]  ImageBaseBase address of PE/COFF image.
+  @param[out] PdbAbsoluteFilePath  Absolute path of PDB file.
+  @param[out] PdbFileName  File name of PDB file.
+**/
+VOID
+GetPdbFileName (
+  IN  UINTNImageBase,
+  OUT CHAR8**PdbAbsoluteFilePath,
+  OUT CHAR8**PdbFileName
+  )
+{
+  VOID   *PdbPointer;
+  CHAR8  *Str;
+
+  //
+  // Get PDB file name from PE/COFF image
+  //
+  PdbPointer = PeCoffLoaderGetPdbPointer ((VOID *)ImageBase);
+  if (PdbPointer == NULL) {
+//
+// No PDB file name found. Set it to an unknown file name.
+//
+*PdbFileName = (CHAR8 *)mUnknownPdbFileName;
+if (PdbAbsoluteFilePath != NULL) {
+  *PdbAbsoluteFilePath = NULL;
+}
+  } else {
+//
+// Get file name portion out of PDB file in PE/COFF image
+//
+Str = (CHAR8 *)((UINTN)PdbPointer +
+AsciiStrLen ((CHAR8 *)PdbPointer) - sizeof *Str);
+for (; *Str != '/' && *Str != '\\'; Str--) {
+  ;
+}
+
+//
+// Set PDB file name (also skip trailing path separator: '/' or '\\')
+//
+*PdbFileName = Str + 1;
+
+if (PdbAbsoluteFilePath != NULL) {
+  //
+  // Set absolute file path of PDB file
+  //
+  *PdbAbsoluteFilePath = PdbPointer;
+}
+  }
+}
diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
index 740a58828b..042207025e 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
@@ -288,5 +288,19 @@ CommonExceptionHandlerWorker (
   IN EXCEPTION_HANDLER_DATA  *ExceptionHandlerData
   );
 
+/**
+  Get absolute path and file name of PDB file in PE/COFF image.
+
+  @param[in]  ImageBaseBase address of PE/COFF image.
+  @param[out] PdbAbsoluteFilePath  Absolute path of PDB file.
+  @param[out] PdbFileName  File name of PDB file.
+**/
+VOID
+GetPdbFileName (
+  IN  UINTNImageBase,
+  OUT CHAR8**PdbAbsoluteFilePath,
+  OUT CHAR8**PdbFileName
+  );
+
 #endif
 
diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
index fe776ccc2d..7f8ec65e1d 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
@@ -14,11 +14,6 @@
 
 #include "CpuExceptionCommon.h"
 
-//
-// Unknown PDB file name
-//
-GLOBAL_REMOVE_IF_UNREFERENCED CONST CHAR8 *mUnknownPdbFileName = "";
-
 /**
   Return address map of exception handler template so that C code can generate
   exception tables.
@@ -247,60 +242,6 @@ DumpCpuContext (
 );
 }
 
-/**
-  Get absolute path and file name of PDB file in PE/COFF image.
-
-  @param[in]  ImageBaseBase address of PE/COFF image.
-  @param[out] PdbAbsoluteFilePath  Absolute path of PDB file.
-  @param[out] PdbFileName  File name of PDB file.
-**/
-STATIC
-VOID
-GetPdbFileName (
-  IN  UINTNImageBase,
-  OUT CHAR8**PdbAbsoluteFilePath,
-  OUT CHAR8**PdbFileName
-  )
-{
-  VOID   *PdbPointer;
-  CHAR8  *Str;
-
-  //
-  // Get PDB file name from PE/COFF image
-  //
-  PdbPointer = PeCoffLoaderGetPdbPointer ((VOID *)ImageBase);
-  if (PdbPointer == NULL) {
-//
-// No PDB file name found. Set it to an unknown file name.
-//
-*PdbFileName = (CHAR8 *)mUnknownPdbFileName;
-if 

[edk2] [RFC v3 1/3] UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support

[Paulo Alcantara]

This patch adds stack trace support during a X64 CPU exception.

It will dump out back trace, stack contents as well as image module
names that were part of the call stack.

Contributed-under: TianoCore Contribution Agreement 1.1
Cc: Eric Dong 
Cc: Laszlo Ersek 
Signed-off-by: Paulo Alcantara 
---
 UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c | 376 
+++-
 1 file changed, 374 insertions(+), 2 deletions(-)

diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
index 65f0cff680..fe776ccc2d 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
@@ -14,6 +14,11 @@
 
 #include "CpuExceptionCommon.h"
 
+//
+// Unknown PDB file name
+//
+GLOBAL_REMOVE_IF_UNREFERENCED CONST CHAR8 *mUnknownPdbFileName = "";
+
 /**
   Return address map of exception handler template so that C code can generate
   exception tables.
@@ -242,6 +247,357 @@ DumpCpuContext (
 );
 }
 
+/**
+  Get absolute path and file name of PDB file in PE/COFF image.
+
+  @param[in]  ImageBaseBase address of PE/COFF image.
+  @param[out] PdbAbsoluteFilePath  Absolute path of PDB file.
+  @param[out] PdbFileName  File name of PDB file.
+**/
+STATIC
+VOID
+GetPdbFileName (
+  IN  UINTNImageBase,
+  OUT CHAR8**PdbAbsoluteFilePath,
+  OUT CHAR8**PdbFileName
+  )
+{
+  VOID   *PdbPointer;
+  CHAR8  *Str;
+
+  //
+  // Get PDB file name from PE/COFF image
+  //
+  PdbPointer = PeCoffLoaderGetPdbPointer ((VOID *)ImageBase);
+  if (PdbPointer == NULL) {
+//
+// No PDB file name found. Set it to an unknown file name.
+//
+*PdbFileName = (CHAR8 *)mUnknownPdbFileName;
+if (PdbAbsoluteFilePath != NULL) {
+  *PdbAbsoluteFilePath = NULL;
+}
+  } else {
+//
+// Get file name portion out of PDB file in PE/COFF image
+//
+Str = (CHAR8 *)((UINTN)PdbPointer +
+AsciiStrLen ((CHAR8 *)PdbPointer) - sizeof *Str);
+for (; *Str != '/' && *Str != '\\'; Str--) {
+  ;
+}
+
+//
+// Set PDB file name (also skip trailing path separator: '/' or '\\')
+//
+*PdbFileName = Str + 1;
+
+if (PdbAbsoluteFilePath != NULL) {
+  //
+  // Set absolute file path of PDB file
+  //
+  *PdbAbsoluteFilePath = PdbPointer;
+}
+  }
+}
+
+/**
+  Dump stack contents.
+
+  @param[in]  CurrentRsp Current stack pointer address.
+  @param[in]  UnwoundStacksCount  Count of unwound stack frames.
+**/
+STATIC
+VOID
+DumpStackContents (
+  IN UINT64  CurrentRsp,
+  IN INTNUnwoundStacksCount
+  )
+{
+  //
+  // Check for proper stack pointer alignment
+  //
+  if (((UINTN)CurrentRsp & (CPU_STACK_ALIGNMENT - 1)) != 0) {
+InternalPrintMessage (" Unaligned stack pointer. \n");
+return;
+  }
+
+  //
+  // Dump out stack contents
+  //
+  InternalPrintMessage ("\nStack dump:\n");
+  while (UnwoundStacksCount-- > 0) {
+InternalPrintMessage (
+  "0x%016lx: %016lx %016lx\n",
+  CurrentRsp,
+  *(UINT64 *)CurrentRsp,
+  *(UINT64 *)((UINTN)CurrentRsp + 8)
+  );
+
+//
+// Point to next stack
+//
+CurrentRsp += CPU_STACK_ALIGNMENT;
+  }
+}
+
+/**
+  Dump all image module names from call stack.
+
+  @param[in]  SystemContext  Pointer to EFI_SYSTEM_CONTEXT.
+**/
+STATIC
+VOID
+DumpImageModuleNames (
+  IN EFI_SYSTEM_CONTEXT   SystemContext
+  )
+{
+  EFI_STATUS  Status;
+  UINT64  Rip;
+  UINTN   ImageBase;
+  VOID*EntryPoint;
+  CHAR8   *PdbAbsoluteFilePath;
+  CHAR8   *PdbFileName;
+  UINT64  Rbp;
+  UINTN   LastImageBase;
+
+  //
+  // Set current RIP address
+  //
+  Rip = SystemContext.SystemContextX64->Rip;
+
+  //
+  // Set current frame pointer address
+  //
+  Rbp = SystemContext.SystemContextX64->Rbp;
+
+  //
+  // Check for proper frame pointer alignment
+  //
+  if (((UINTN)Rbp & (CPU_STACK_ALIGNMENT - 1)) != 0) {
+InternalPrintMessage (" Unaligned frame pointer. \n");
+return;
+  }
+
+  //
+  // Get initial PE/COFF image base address from current RIP
+  //
+  ImageBase = PeCoffSearchImageBase (Rip);
+  if (ImageBase == 0) {
+InternalPrintMessage (" Could not find image module names. ");
+return;
+  }
+
+  //
+  // Set last PE/COFF image base address
+  //
+  LastImageBase = ImageBase;
+
+  //
+  // Get initial PE/COFF image's entry point
+  //
+  Status = PeCoffLoaderGetEntryPoint ((VOID *)ImageBase, );
+  if (EFI_ERROR (Status)) {
+EntryPoint = NULL;
+  }
+
+  //
+  // Get file name and absolute path of initial PDB file
+  //
+  GetPdbFileName (ImageBase, , );
+
+  //
+  // Print out initial image module name (if any)
+  //
+  if (PdbAbsoluteFilePath != NULL) {
+InternalPrintMessage (
+  "\n%a (ImageBase=0x%016lx, 

Re: [edk2] [PATCH] OvmfPkg/XenHypercallLib: enable virt extensions for ARM

[Laszlo Ersek]

On 11/16/17 17:56, Ard Biesheuvel wrote:
> XenHypercallLib uses the 'hvc' instruction, which is not implemented
> on all ARMv7 CPUs, and so we need to explicitly specify a CPU that
> has the virtualization extensions.
> 
> This override used to be set at the platform level, but this was removed
> in commit 0d36a219c7bdbb27d775b50837823b2a9928147c
> ('ArmPlatformPkg/PL031RealTimeClockLib: drop ArmPlatformSysConfigLib
> reference), under the assumption that all users of the 'hvc' instruction
> had already been fixed.
> 
> So fix this for GNU binutils by adding the 'virt' arch extension
> directive, and for RVCT by setting the --cpu command line option to a
> CPU that is virt capable.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  OvmfPkg/Library/XenHypercallLib/Arm/Hypercall.S | 2 ++
>  OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf | 3 +++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/OvmfPkg/Library/XenHypercallLib/Arm/Hypercall.S 
> b/OvmfPkg/Library/XenHypercallLib/Arm/Hypercall.S
> index c12c8658b729..0adf65840a2f 100644
> --- a/OvmfPkg/Library/XenHypercallLib/Arm/Hypercall.S
> +++ b/OvmfPkg/Library/XenHypercallLib/Arm/Hypercall.S
> @@ -16,6 +16,8 @@
>  #include 
>  
>.text
> +  .arch_extension virt
> +
>  GCC_ASM_EXPORT(XenHypercall2)
>  
>  ASM_PFX(XenHypercall2):
> diff --git a/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf 
> b/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
> index f4503a4b01f4..d268e540feca 100644
> --- a/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
> +++ b/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
> @@ -64,3 +64,6 @@ [LibraryClasses.IA32, LibraryClasses.X64]
>  
>  [Guids.IA32, Guids.X64]
>gEfiXenInfoGuid
> +
> +[BuildOptions.ARM]
> +  RVCT:*_*_ARM_PLATFORM_FLAGS == --cpu Cortex-A15
> 

Acked-by: Laszlo Ersek 

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

Re: [edk2] EDK2 build issues

[Desimone, Nathaniel L]

Hi Liming,

I chatted with Aaron on the phone today. The VfrCompiler race condition was 
discovered using "make -j " (where n > 1). I have filed the bug in Bugzilla:

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

For the ARCH environment variable, we brainstormed two possible new names 
HOST_ARCH or BASETOOLS_ARCH. Should I file the ARCH variable request in 
Bugzilla as well?

Thanks,

Nate

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao, 
Liming
Sent: Monday, November 13, 2017 5:46 PM
To: Aaron Durbin 
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] EDK2 build issues

I add my comments. 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Aaron Durbin
> Sent: Tuesday, November 14, 2017 1:38 AM
> To: Gao, Liming 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] EDK2 build issues
> 
> On Sun, Nov 12, 2017 at 7:15 PM, Gao, Liming  wrote:
> > Yes. BaseTools needs some environments. Before build BaseTools, we need to 
> > call edkset.sh to setup them.
> >
> > 1. BaseTools Soure tools are compiled in serial instead of parallel. 
> > And, VfrCompiler depends on Anltr tool. So, Anltr is required to be
> built first. I agree that this way takes some time to compile 
> BaseTools source. I have one proposal to compile C source tools with multiple 
> thread. I can share my draft patch.
> 
> If the depedencies are correctly met in the makefiles then why are 
> they built serially? It sounds like you understand the dependencies so 
> why aren't those explicitly noted so one can build in parallel?
> 
Seemly, VfrCompiler Makefile doesn't list those dependency clearly. Could you 
submit this issue in bugzillar (https://bugzilla.tianocore.org/)?
Besides, do you use make -j option to enable Parallel Execution? I want to know 
how to verify it. 

> > 2. BaseTools C source are compiled to the executable files. They run 
> > in host machine. Here ARCH is for the executable files those can
> run in host machine. edk2\BaseTools\Source\C\GNUmakefile auto detects ARCH 
> based on 'uname -m' command.
> 
> ARCH != host is my point. Why are those being conflated? Or are you 
> saying edk2 tools define ARCH to be what the host is?
> 
Yes. Edk2 BaseTools C source uses it as host arch. I agree ARCH name is too 
generic. In your environment, ARCH may be defined for the different purpose. 

> > 3. There are more GCC compiler distribution. We try to use the 
> > generic options in GCC tool chain. If you find the option doesn't 
> > work
> on your GCC compiler, please report it. And, we also notice 
> tools_def.txt is too big to be hard to be maintain. We have one proposal to 
> simplify it. I will send this RFC to edk2 community.
> >
> >>-Original Message-
> >>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> >>Of Aaron Durbin
> >>Sent: Saturday, November 11, 2017 6:27 AM
> >>To: edk2-devel@lists.01.org
> >>Subject: [edk2] EDK2 build issues
> >>
> >>Hello,
> >>
> >>Here are some observations I've encountered trying to utilize edk2 
> >>for certain builds. Part of the problem seems to be with implicit 
> >>assumptions in how edk2 is used. I'm trying to build things using 
> >>edk2 from a clean enviroment on an automated builder. i.e. there 
> >>isn't a workspace that exists on one persons computer for the 
> >>lifetime of development.
> >>
> >>1. BaseTools can't build in parallel. The tests are racey which 
> >>result in test failures. Because of this one has to build these in 
> >>serial instead of in parallel.
> >>
> >>===
> >>===
> >>FAIL: testHelp (TianoCompress.Tests)
> >>
> >>--
> >>Traceback (most recent call last):
> >>  File 
> >>"/build/zoombini/tmp/portage/sys-boot/fsp-cnl-/work/fsp-cnl-
> >>/Edk2/BaseTools/Tests/TianoCompress.py",
> >>line 34, in testHelp
> >>self.assertTrue(result == 0)
> >>AssertionError: False is not true
> >>
> >>===
> >>===
> >>FAIL: testRandomDataCycles (TianoCompress.Tests)
> >>
> >>--
> >>Traceback (most recent call last):
> >>  File 
> >>"/build/zoombini/tmp/portage/sys-boot/fsp-cnl-/work/fsp-cnl-
> >>/Edk2/BaseTools/Tests/TianoCompress.py",
> >>line 65, in testRandomDataCycles
> >>self.compressionTestCycle(data)
> >>  File 
> >>"/build/zoombini/tmp/portage/sys-boot/fsp-cnl-/work/fsp-cnl-
> >>/Edk2/BaseTools/Tests/TianoCompress.py",
> >>line 44, in compressionTestCycle
> >>self.assertTrue(result == 0)
> >>AssertionError: False is not true
> >>
> >>In addition, it seems compilation even breaks trying to build a parser:
> >>
> >>VfrSyntax.cpp:53:1: error: expected class-name before '{' token  {^M  
> 

[edk2] [PATCH v3 3/3] OvmfPkg: save on I/O port accesses when the debug port is not in use

[Paolo Bonzini]

When SEV is enabled, every debug message printed by OVMF to the
QEMU debug port traps from the guest to QEMU character by character
because "REP OUTSB" cannot be used by IoWriteFifo8.  Furthermore,
when OVMF is built with the DEBUG_VERBOSE bit (value 0x0040)
enabled in "gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel", then the
OvmfPkg/IoMmuDxe driver, and the OvmfPkg/Library/BaseMemEncryptSevLib
library instance that is built into it, produce a huge amount of
log messages.  Therefore, in SEV guests, the boot time impact is huge
(about 45 seconds _additional_ time spent writing to the debug port).

While these messages are very useful for analyzing guest behavior,
most of the time the user won't be capturing the OVMF debug log.
In fact libvirt does not provide a method for configuring log capture;
users that wish to do this (or are instructed to do this) have to resort
to .

The debug console device provides a handy detection mechanism; when read,
it returns 0xE9 (which is very much unlike the 0xFF that is returned by
an unused port).  Use it to skip the possibly expensive OUT instructions
when the debug I/O port isn't plugged anywhere.

For SEC, the debug port has to be read before each full message.
However:

- if the debug port is available, then reading one byte before writing
a full message isn't tragic, especially because SEC doesn't print many
messages

- if the debug port is not available, then reading one byte instead of
writing a full message is still a win.

Contributed-under: TianoCore Contribution Agreement 1.0
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Jordan Justen (Intel address) 
Signed-off-by: Paolo Bonzini 
---
 .../PlatformDebugLibIoPort/DebugLibDetect.h| 57 ++
 OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c  | 28 +--
 .../PlatformDebugLibIoPort/DebugLibDetect.c| 30 ++--
 .../PlatformDebugLibIoPort/DebugLibDetectRom.c | 21 +++-
 4 files changed, 127 insertions(+), 9 deletions(-)
 create mode 100644 OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.h

diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.h 
b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.h
new file mode 100644
index 00..1f739b55d8
--- /dev/null
+++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.h
@@ -0,0 +1,57 @@
+/** @file
+  Base Debug library instance for QEMU debug port.
+  It uses PrintLib to send debug messages to a fixed I/O port.
+
+  Copyright (c) 2017, Red Hat, Inc.
+  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.
+
+**/
+
+#ifndef __DEBUG_IO_PORT_DETECT_H__
+#define __DEBUG_IO_PORT_DETECT_H__
+
+#include 
+
+//
+// The constant value that is read from the debug I/O port
+//
+#define BOCHS_DEBUG_PORT_MAGIC0xE9
+
+
+/**
+  Helper function to return whether the virtual machine has a debug I/O port.
+  PlatformDebugLibIoPortFound can call this function directly or cache the
+  result.
+
+  @retval TRUE   if the debug I/O port device was detected.
+  @retval FALSE  otherwise
+
+**/
+BOOLEAN
+EFIAPI
+PlatformDebugLibIoPortDetect (
+  VOID
+  );
+
+/**
+  Return whether the virtual machine has a debug I/O port.  DebugLib.c
+  calls this function instead of PlatformDebugLibIoPortDetect, to allow
+  caching if possible.
+
+  @retval TRUE   if the debug I/O port device was detected.
+  @retval FALSE  otherwise
+
+**/
+BOOLEAN
+EFIAPI
+PlatformDebugLibIoPortFound (
+  VOID
+  );
+
+#endif
diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c 
b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
index 5a1c86f2c3..36cde54976 100644
--- a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
+++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include "DebugLibDetect.h"
 
 //
 // Define the maximum debug and assert message length that this library 
supports
@@ -61,9 +62,10 @@ DebugPrint (
   ASSERT (Format != NULL);
 
   //
-  // Check driver debug mask value and global mask
+  // Check if the global mask disables this message or the device is inactive
   //
-  if ((ErrorLevel & GetDebugPrintErrorLevel ()) == 0) {
+  if ((ErrorLevel & GetDebugPrintErrorLevel ()) == 0 ||
+  !PlatformDebugLibIoPortFound ()) {
 return;
   }
 
@@ -120,9 +122,11 @@ DebugAssert (
  FileName, (UINT64)LineNumber, Description);
 
   //
-  // Send the print string to the debug I/O port
+  // Send the print string to the debug I/O port, if present
   //
-  IoWriteFifo8 (PcdGet16 (PcdDebugIoPort), 

[edk2] [PATCH v3 0/3] OvmfPkg: save on I/O port accesses when the debug port is not in use

[Paolo Bonzini]

This is version 3 of the series to skip debug port I/O port writes
when the debug port device wasn't added to the virtual machine.
The differences from v2 are entirely cosmetic, and I'm including them
at the end of this message for ease of review.

Thanks,

Paolo

Paolo Bonzini (3):
  OvmfPkg: make PlatformDebugLibIoPort a proper BASE library
  OvmfPkg: create a separate PlatformDebugLibIoPort instance for SEC
  OvmfPkg: save on I/O port accesses when the debug port is not in use

 OvmfPkg/OvmfPkgIa32.dsc  |  2 +-
 OvmfPkg/OvmfPkgIa32X64.dsc   |  2 +-
 OvmfPkg/OvmfPkgX64.dsc   |  2 +-
 OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf|  3 ++-
 OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf | 52 
+
 OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.h  | 55 

 OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c| 44 
+++
 OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.c  | 55 

 OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetectRom.c   | 48 
++
 9 files changed, 241 insertions(+), 24 deletions(-)
 create mode 100644 
OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf
 create mode 100644 OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.h
 create mode 100644 OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.c
 create mode 100644 OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetectRom.c

-- 
2.14.3

diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf 
b/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
index 65d8683f1f..de3c2f542b 100644
--- a/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
+++ b/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
@@ -21,7 +21,7 @@ [Defines]
   FILE_GUID  = DF934DA3-CD31-49FE-AF50-B3C87C79325F
   MODULE_TYPE= BASE
   VERSION_STRING = 1.0
-  LIBRARY_CLASS  = DebugLib
+  LIBRARY_CLASS  = DebugLib|PEI_CORE PEIM DXE_CORE DXE_DRIVER 
DXE_RUNTIME_DRIVER SMM_CORE DXE_SMM_DRIVER UEFI_DRIVER UEFI_APPLICATION
   CONSTRUCTOR= PlatformDebugLibIoPortConstructor
 
 #
diff --git 
a/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf 
b/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf
index 93763d47dd..491c0318de 100644
--- a/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf
+++ b/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf
@@ -21,7 +21,7 @@ [Defines]
   FILE_GUID  = CEB0D9D3-328F-4C24-8C02-28FA1986AE1B
   MODULE_TYPE= BASE
   VERSION_STRING = 1.0
-  LIBRARY_CLASS  = DebugLib
+  LIBRARY_CLASS  = DebugLib|SEC
   CONSTRUCTOR= PlatformRomDebugLibIoPortConstructor
 
 #
diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.h 
b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.h
index c34ca9c72b..1f739b55d8 100644
--- a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.h
+++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.h
@@ -17,7 +17,6 @@
 #define __DEBUG_IO_PORT_DETECT_H__
 
 #include 
-#include 
 
 //
 // The constant value that is read from the debug I/O port
@@ -30,7 +29,8 @@
   PlatformDebugLibIoPortFound can call this function directly or cache the
   result.
 
-  @retval BOOLEAN   TRUE if the debug I/O port device was detected.
+  @retval TRUE   if the debug I/O port device was detected.
+  @retval FALSE  otherwise
 
 **/
 BOOLEAN
@@ -44,7 +44,8 @@ PlatformDebugLibIoPortDetect (
   calls this function instead of PlatformDebugLibIoPortDetect, to allow
   caching if possible.
 
-  @retval BOOLEAN   TRUE if the debug I/O port device was detected.
+  @retval TRUE   if the debug I/O port device was detected.
+  @retval FALSE  otherwise
 
 **/
 BOOLEAN
diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c 
b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
index 79486ac8a6..36cde54976 100644
--- a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
+++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
@@ -15,7 +15,6 @@
 **/
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -63,9 +62,10 @@ DebugPrint (
   ASSERT (Format != NULL);
 
   //
-  // Do nothing if the global mask disables this message or the device is 
inactive
+  // Check if the global mask disables this message or the device is inactive
   //
-  if ((ErrorLevel & GetDebugPrintErrorLevel ()) == 0 || 
!PlatformDebugLibIoPortFound ()) {
+  if ((ErrorLevel & 

[edk2] [PATCH v3 2/3] OvmfPkg: create a separate PlatformDebugLibIoPort instance for SEC

[Paolo Bonzini]

The next patch will want to add a global variable to
PlatformDebugLibIoPort, but this is not suitable for the SEC
phase, because SEC runs from read-only flash.  The solution is
to have two library instances, one for SEC and another
for all other firmware phases.  This patch adds the "plumbing"
for the SEC library instance, separating the INF files and
moving the constructor to a separate C source file.

Contributed-under: TianoCore Contribution Agreement 1.1
Tested-by: Laszlo Ersek 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Jordan Justen (Intel address) 
Signed-off-by: Paolo Bonzini 
---
 OvmfPkg/OvmfPkgIa32.dsc  |  2 +-
 OvmfPkg/OvmfPkgIa32X64.dsc   |  2 +-
 OvmfPkg/OvmfPkgX64.dsc   |  2 +-
 OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf|  3 ++-
 OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf | 52 

 OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c| 15 
-
 OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.c  | 31 
++
 OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetectRom.c   | 31 
++
 8 files changed, 119 insertions(+), 19 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index c2f534fdbf..7ccb61147f 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -207,7 +207,7 @@ [LibraryClasses.common.SEC]
 !ifdef $(DEBUG_ON_SERIAL_PORT)
   DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
 !else
-  DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
+  DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf
 !endif
   
ReportStatusCodeLib|MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf
   
ExtractGuidedSectionLib|MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 9f300a2e6f..237ec71b5e 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -212,7 +212,7 @@ [LibraryClasses.common.SEC]
 !ifdef $(DEBUG_ON_SERIAL_PORT)
   DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
 !else
-  DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
+  DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf
 !endif
   
ReportStatusCodeLib|MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf
   
ExtractGuidedSectionLib|MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 1ffcf37f8b..a5047fa38e 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -212,7 +212,7 @@ [LibraryClasses.common.SEC]
 !ifdef $(DEBUG_ON_SERIAL_PORT)
   DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
 !else
-  DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
+  DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf
 !endif
   
ReportStatusCodeLib|MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf
   
ExtractGuidedSectionLib|MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.inf
diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf 
b/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
index 0e74fe94cb..de3c2f542b 100644
--- a/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
+++ b/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
@@ -21,7 +21,7 @@ [Defines]
   FILE_GUID  = DF934DA3-CD31-49FE-AF50-B3C87C79325F
   MODULE_TYPE= BASE
   VERSION_STRING = 1.0
-  LIBRARY_CLASS  = DebugLib
+  LIBRARY_CLASS  = DebugLib|PEI_CORE PEIM DXE_CORE DXE_DRIVER 
DXE_RUNTIME_DRIVER SMM_CORE DXE_SMM_DRIVER UEFI_DRIVER UEFI_APPLICATION
   CONSTRUCTOR= PlatformDebugLibIoPortConstructor
 
 #
@@ -30,6 +30,7 @@ [Defines]
 
 [Sources]
   DebugLib.c
+  DebugLibDetect.c
 
 [Packages]
   MdePkg/MdePkg.dec
diff --git 
a/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf 
b/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf
new file mode 100644
index 00..491c0318de
--- /dev/null
+++ b/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf
@@ -0,0 +1,52 @@
+## @file
+#  Instance of Debug Library for the QEMU debug console port.
+#  It uses Print Library to produce formatted output strings.
+#
+#  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+#  Copyright (c) 

[edk2] [PATCH v3 1/3] OvmfPkg: make PlatformDebugLibIoPort a proper BASE library

[Paolo Bonzini]

Remove Uefi.h, which includes UefiSpec.h, and change the
return value to match the RETURN_STATUS type.

Contributed-under: TianoCore Contribution Agreement 1.1
Tested-by: Laszlo Ersek 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Jordan Justen (Intel address) 
Signed-off-by: Paolo Bonzini 
---
 OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c 
b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
index 5435767c1c..74f4d9c2d6 100644
--- a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
+++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
@@ -15,7 +15,6 @@
 **/
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -32,7 +31,7 @@
 /**
   This constructor function does not have to do anything.
 
-  @retval EFI_SUCCESS   The constructor always returns RETURN_SUCCESS.
+  @retval RETURN_SUCCESS   The constructor always returns RETURN_SUCCESS.
 
 **/
 RETURN_STATUS
@@ -41,7 +40,7 @@ PlatformDebugLibIoPortConstructor (
   VOID
   )
 {
-  return EFI_SUCCESS;
+  return RETURN_SUCCESS;
 }
 
 /**
-- 
2.14.3


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

Re: [edk2] [PATCH 2/2] OvmfPkg: save on I/O port accesses when the debug port is not in use

[Laszlo Ersek]

On 11/16/17 11:47, Paolo Bonzini wrote:
> When SEV is enabled, every debug message printed by OVMF to the
> QEMU debug port traps from the guest to QEMU character by character
> because "REP OUTSB" cannot be used by IoWriteFifo8.  Furthermore,
> when OVMF is built with the DEBUG_VERBOSE bit (value 0x0040)
> enabled in "gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel", then the
> OvmfPkg/IoMmuDxe driver, and the OvmfPkg/Library/BaseMemEncryptSevLib
> library instance that is built into it, produce a huge amount of
> log messages.  Therefore, in SEV guests, the boot time impact is huge
> (about 45 seconds _additional_ time spent writing to the debug port).
> 
> While these messages are very useful for analyzing guest behavior,
> most of the time the user won't be capturing the OVMF debug log.
> In fact libvirt does not provide a method for configuring log capture;
> users that wish to do this (or are instructed to do this) have to resort
> to .
> 
> The debug console device provides a handy detection mechanism; when read,
> it returns 0xE9 (which is very much unlike the 0xFF that is returned by
> an unused port).  Use it to skip the possibly expensive OUT instructions
> when the debug I/O port isn't plugged anywhere.
> 
> For SEC, the debug port has to be read before each full message.
> However:
> 
> - if the debug port is available, then reading one byte before writing
> a full message isn't tragic, especially because SEC doesn't print many
> messages
> 
> - if the debug port is not available, then reading one byte instead of
> writing a full message is still a win.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen (Intel address) 
> Signed-off-by: Paolo Bonzini 
> ---
>  OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c  | 26 --
>  .../PlatformDebugLibIoPort/DebugLibDetect.c| 29 +--
>  .../PlatformDebugLibIoPort/DebugLibDetect.h| 56 
> ++
>  .../PlatformDebugLibIoPort/DebugLibDetectRom.c | 20 +++-
>  4 files changed, 122 insertions(+), 9 deletions(-)
>  create mode 100644 OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.h
> 
> diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c 
> b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> index a5572a8eeb..79486ac8a6 100644
> --- a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> +++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include "DebugLibDetect.h"
>  
>  //
>  // Define the maximum debug and assert message length that this library 
> supports
> @@ -62,9 +63,9 @@ DebugPrint (
>ASSERT (Format != NULL);
>  
>//
> -  // Check driver debug mask value and global mask
> +  // Do nothing if the global mask disables this message or the device is 
> inactive
>//
> -  if ((ErrorLevel & GetDebugPrintErrorLevel ()) == 0) {
> +  if ((ErrorLevel & GetDebugPrintErrorLevel ()) == 0 || 
> !PlatformDebugLibIoPortFound ()) {

(1) I feel terrible for wasting your time with this -- we prefer to keep
a line length of 80 characters:

  if ((ErrorLevel & GetDebugPrintErrorLevel ()) == 0 ||
  !PlatformDebugLibIoPortFound ()) {

("we prefer" is a bit of a lie -- I personally totally insist on it :) ,
while many people ignore it until I raise a stink about their overlong
lines. So I guess "we prefer" is an expected value, with large stddev.)

>  return;
>}
>  
> @@ -121,9 +122,11 @@ DebugAssert (
>   FileName, (UINT64)LineNumber, Description);
>  
>//
> -  // Send the print string to the debug I/O port
> +  // Send the print string to the debug I/O port, if present
>//
> -  IoWriteFifo8 (PcdGet16 (PcdDebugIoPort), Length, Buffer);
> +  if (PlatformDebugLibIoPortFound ()) {
> +IoWriteFifo8 (PcdGet16 (PcdDebugIoPort), Length, Buffer);
> +  }
>  
>//
>// Generate a Breakpoint, DeadLoop, or NOP based on PCD settings
> @@ -266,3 +269,18 @@ DebugPrintLevelEnabled (
>  {
>return (BOOLEAN) ((ErrorLevel & PcdGet32(PcdFixedDebugPrintErrorLevel)) != 
> 0);
>  }
> +
> +/**
> +  Return the result of detecting the debug I/O port device.
> +
> +  @retval BOOLEAN   TRUE if the debug I/O port device was detected.

(2) Another non-intuitive edk2 quirk; we have two possibilities for
retval documentation:

  @retval VALUE  description

and

  @return  just description

For example,

  @retval TRUE   if the debug I/O port device was detected
  @retval FALSE  otherwise

and

  @return  a BOOLEAN indicating whether the debug I/O port device was
   detected

(I apologize -- I know this is annoying.)

> +
> +**/
> +BOOLEAN
> +EFIAPI
> +PlatformDebugLibIoPortDetect (
> +  VOID
> +  )
> +{
> +  return IoRead8 (PcdGet16 (PcdDebugIoPort)) == BOCHS_DEBUG_PORT_MAGIC;
> +}
> diff --git 

Re: [edk2] [PATCH 1/2] OvmfPkg: create a separate PlatformDebugLibIoPort instance for SEC

[Laszlo Ersek]

On 11/16/17 11:47, Paolo Bonzini wrote:
> The next patch will want to add a global variable to
> PlatformDebugLibIoPort, but this is not suitable for the SEC
> phase, because SEC runs from read-only flash.  The solution is
> to have two library instances, one for SEC and another
> for all other firmware phases.  This patch adds the "plumbing"
> for the SEC library instance, separating the INF files and
> moving the constructor to a separate C source file.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen (Intel address) 
> Signed-off-by: Paolo Bonzini 
> ---
>  OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c  | 15 ---
>  .../PlatformDebugLibIoPort/DebugLibDetect.c| 32 +
>  .../PlatformDebugLibIoPort/DebugLibDetectRom.c | 32 +
>  .../PlatformDebugLibIoPort.inf |  1 +
>  .../PlatformRomDebugLibIoPort.inf  | 52 
> ++
>  OvmfPkg/OvmfPkgIa32.dsc|  2 +-
>  OvmfPkg/OvmfPkgIa32X64.dsc |  2 +-
>  OvmfPkg/OvmfPkgX64.dsc |  2 +-
>  8 files changed, 120 insertions(+), 18 deletions(-)
>  create mode 100644 OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.c
>  create mode 100644 OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetectRom.c
>  create mode 100644 
> OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf

Very nice!

I have a number of superficial comments. I've considered squashing these 
changes into your patch myself, but I didn't know what you'd prefer, so first 
I'll just list them.

> diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c 
> b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> index 5435767c1c..a5572a8eeb 100644
> --- a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> +++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> @@ -29,21 +29,6 @@
>  //
>  #define MAX_DEBUG_MESSAGE_LENGTH  0x100
>  
> -/**
> -  This constructor function does not have to do anything.
> -
> -  @retval EFI_SUCCESS   The constructor always returns RETURN_SUCCESS.
> -
> -**/
> -RETURN_STATUS
> -EFIAPI
> -PlatformDebugLibIoPortConstructor (
> -  VOID
> -  )
> -{
> -  return EFI_SUCCESS;
> -}
> -
>  /**
>Prints a debug message to the debug output device if the specified error 
> level is enabled.
>  

(1) This is a pre-existent wart in the code. The return type is RETURN_STATUS, 
but we return EFI_SUCCESS instead of RETURN_SUCCESS.

Numerically they are the same, but the message is different. RETURN_* is for 
library instances that have MODULE_TYPE=BASE, meaning that they can be built 
into modules that are more "primitive" than DXE_DRIVERs (such as SEC, PEIM, 
PEI_CORE, ...). This distinction primarily influences the constructor 
function's parameter list -- for MODULE_TYPE=BASE library instances, it is just 
VOID --, but it also dictates whether we should use EFI_xxx or RETURN_xxx as 
status codes.

Can you please prepend a patch to the series that replaces EFI_SUCCESS with 
RETURN_SUCCESS in this function?

(2) Similarly, as a "precursor cleanup",  should not be included 
anywhere in this library instance. Namely, "MdePkg/Include/Uefi.h" has the 
following leading comment (rewrapped here for readability):

> Root include file for Mde Package UEFI, UEFI_APPLICATION type modules.
>
> This is the include file for any module of type UEFI and
> UEFI_APPLICATION. Uefi modules only use types defined via this include
> file and can be ported easily to any environment.

UEFI_DRIVER and UEFI_APPLICATION modules are the *least* primitive module 
types, while this library instance is on the other end of the spectrum.

Now, "MdePkg/Include/Uefi.h" is just a convenience header for including:

#include 
#include 

>From these, "MdePkg/Include/Uefi/UefiBaseType.h" is totally fine to include 
>wherever, while "MdePkg/Include/Uefi/UefiSpec.h" is the one that should be 
>kept out of BASE lib classes.

Thus, in the same prepended patch, can you please also try to replace  
with ? The lib instance should continue building just the 
same. (If it breaks, that means we have a layering violation in the code 
somewhere.)

Consequently:

> diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.c 
> b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.c
> new file mode 100644
> index 00..fee908861b
> --- /dev/null
> +++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.c
> @@ -0,0 +1,32 @@
> +/** @file
> +  Constructor code for QEMU debug port library.
> +  Non-SEC instance.
> +
> +  Copyright (c) 2017, Red Hat, Inc.
> +  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 
> 

Re: [edk2] [PATCH v2 0/2] ArmplatformPkg: clean up PL011 support library

[Leif Lindholm]

On Thu, Nov 16, 2017 at 05:47:06PM +, Ard Biesheuvel wrote:
> Clean up the PL011 UART support library, by moving it into the appropriate
> place for libraries, and splitting the header file into an implementation
> and an interface part.

For the series:
Reviewed-by: Leif Lindholm 

> Ard Biesheuvel (2):
>   ArmPlatformPkg: reorganize PL011 code
>   ArmVirtPkg: switch to new PL011UartLib implementation
> 
>  ArmPlatformPkg/ArmPlatformPkg.dec |   3 +
>  ArmPlatformPkg/Include/Library/PL011UartLib.h | 187 
> 
>  ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c|   5 
> +-
>  ArmPlatformPkg/Library/PL011UartLib/PL011Uart.h   | 120 
> +
>  ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.c| 474 
> 
>  ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf  |  43 
> ++
>  ArmVirtPkg/ArmVirt.dsc.inc|   2 
> +-
>  ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c |   5 
> +-
>  ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.c  |   5 
> +-
>  9 files changed, 834 insertions(+), 10 deletions(-)
>  create mode 100644 ArmPlatformPkg/Include/Library/PL011UartLib.h
>  create mode 100644 ArmPlatformPkg/Library/PL011UartLib/PL011Uart.h
>  create mode 100644 ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.c
>  create mode 100644 ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
> 
> -- 
> 2.11.0
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmPlatformPkg ArmVirtPkg: reorganize PL011 code

[Leif Lindholm]

On Thu, Nov 16, 2017 at 05:38:10PM +, Ard Biesheuvel wrote:
> On 16 November 2017 at 17:36, Leif Lindholm  wrote:
> > On Thu, Nov 16, 2017 at 05:12:16PM +, Ard Biesheuvel wrote:
> >> The PL011 code in ArmPlatformPkg is organized in a weird way: there is
> >> a single PL011Uart.h header file under Include/Drivers containing both
> >> register definitions and function entry points. The PL011Uart library
> >> itself is in Drivers/ but it is actually a library.
> >>
> >> So let's clean this up: add a new PL011UartLib library class and associated
> >> header file containing only the library prototypes, and move the library
> >> itself under Library/ using a new GUID, with the register definitions moved
> >> into a local header file.
> >>
> >> Note that we need to retain the old implementation for out of tree
> >> platforms,
> >
> > s/need to//
> >
> > Do we need to?
> 
> At least until we switch over edk2-platforms, yes.

Sure, but given the people involved (when available) are the same at
both ends, this kind of thing can be done near-atomically enough that
I'm happy to buy everyone caught out a beer and apologise.

(This is not to be considered further feedback on this set, but
stating an opinion for potential similar situations in future.)

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

[edk2] [PATCH edk2-platforms v2 12/13] Platform: remove stale EBL related PCD setting

[Ard Biesheuvel]

Remove all gEmbeddedTokenSpaceGuid.PcdEmbeddedPrompt assignments, which
are no longer meaningful with EBL removed.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/ARM/JunoPkg/ArmJuno.dsc | 1 -
 Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc| 1 -
 Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc | 1 -
 Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc | 1 -
 Platform/Hisilicon/D02/Pv660D02.dsc  | 2 --
 Platform/Hisilicon/D03/D03.dsc   | 2 --
 Platform/Hisilicon/D05/D05.dsc   | 2 --
 Platform/Hisilicon/HiKey/HiKey.dsc   | 1 -
 Platform/Marvell/Armada/Armada.dsc.inc   | 1 -
 Silicon/Hisilicon/Hisilicon.dsc.inc  | 1 -
 10 files changed, 13 deletions(-)

diff --git a/Platform/ARM/JunoPkg/ArmJuno.dsc b/Platform/ARM/JunoPkg/ArmJuno.dsc
index 3cbacb35dae3..af6fce978efc 100644
--- a/Platform/ARM/JunoPkg/ArmJuno.dsc
+++ b/Platform/ARM/JunoPkg/ArmJuno.dsc
@@ -88,7 +88,6 @@ [PcdsFeatureFlag.common]
 
 [PcdsFixedAtBuild.common]
   gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"ARM Juno"
-  gEmbeddedTokenSpaceGuid.PcdEmbeddedPrompt|"ArmJuno"
 
   #
   # NV Storage PCDs. Use base of 0x0800 for NOR0
diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc 
b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc
index 4a55dac7a4a4..62d992d351af 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc
@@ -94,7 +94,6 @@ [PcdsFeatureFlag.common]
 
 [PcdsFixedAtBuild.common]
   gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"ARM Versatile Express"
-  gEmbeddedTokenSpaceGuid.PcdEmbeddedPrompt|"ArmVExpress-CTA15-A7"
 
   gArmPlatformTokenSpaceGuid.PcdCoreCount|5
 
diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc 
b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
index 829854963b30..c7710564df5e 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
@@ -85,7 +85,6 @@ [PcdsFeatureFlag.common]
 
 [PcdsFixedAtBuild.common]
   gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"ARM Fixed Virtual Platform"
-  gEmbeddedTokenSpaceGuid.PcdEmbeddedPrompt|"ARM-FVP"
 
   # Only one core enters UEFI, and PSCI is implemented in EL3 by ATF
   gArmPlatformTokenSpaceGuid.PcdCoreCount|1
diff --git a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc 
b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
index c9bb236168cf..58edf3ea6f8a 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
@@ -291,7 +291,6 @@ [PcdsFixedAtBuild.common]
   gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"$(FIRMWARE_VER)"
 !endif
 
-  gEmbeddedTokenSpaceGuid.PcdEmbeddedPrompt|"VExpress"
   gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength|100
   gEfiMdePkgTokenSpaceGuid.PcdMaximumAsciiStringLength|100
   gEfiMdePkgTokenSpaceGuid.PcdMaximumLinkedListLength|100
diff --git a/Platform/Hisilicon/D02/Pv660D02.dsc 
b/Platform/Hisilicon/D02/Pv660D02.dsc
index cd0fbdb56fdf..d5eb963e8f2a 100644
--- a/Platform/Hisilicon/D02/Pv660D02.dsc
+++ b/Platform/Hisilicon/D02/Pv660D02.dsc
@@ -99,8 +99,6 @@ [PcdsFeatureFlag.common]
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|FALSE
 
 [PcdsFixedAtBuild.common]
-  gEmbeddedTokenSpaceGuid.PcdEmbeddedPrompt|"D02"
-
   gArmPlatformTokenSpaceGuid.PcdCoreCount|8
 
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000
diff --git a/Platform/Hisilicon/D03/D03.dsc b/Platform/Hisilicon/D03/D03.dsc
index a5aa5f7fcd0a..6b141dcdcbc3 100644
--- a/Platform/Hisilicon/D03/D03.dsc
+++ b/Platform/Hisilicon/D03/D03.dsc
@@ -109,8 +109,6 @@ [PcdsFeatureFlag.common]
   gHisiTokenSpaceGuid.PcdIsItsSupported|TRUE
 
 [PcdsFixedAtBuild.common]
-  gEmbeddedTokenSpaceGuid.PcdEmbeddedPrompt|"D03"
-
   gArmPlatformTokenSpaceGuid.PcdCoreCount|8
 
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000
diff --git a/Platform/Hisilicon/D05/D05.dsc b/Platform/Hisilicon/D05/D05.dsc
index de2d3579a494..00cf0f20d23f 100644
--- a/Platform/Hisilicon/D05/D05.dsc
+++ b/Platform/Hisilicon/D05/D05.dsc
@@ -123,8 +123,6 @@ [PcdsFeatureFlag.common]
   gHisiTokenSpaceGuid.PcdIsItsSupported|TRUE
 
 [PcdsFixedAtBuild.common]
-  gEmbeddedTokenSpaceGuid.PcdEmbeddedPrompt|"D05"
-
   gArmPlatformTokenSpaceGuid.PcdCoreCount|8
 
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000
diff --git a/Platform/Hisilicon/HiKey/HiKey.dsc 
b/Platform/Hisilicon/HiKey/HiKey.dsc
index f0380ee1f929..a339eadc30ac 100644
--- a/Platform/Hisilicon/HiKey/HiKey.dsc
+++ b/Platform/Hisilicon/HiKey/HiKey.dsc
@@ -272,7 +272,6 @@ [PcdsFixedAtBuild.common]
 
   gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"hikey"
   gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"Alpha"
-  gEmbeddedTokenSpaceGuid.PcdEmbeddedPrompt|"HiKey"
 
   #
   # NV Storage PCDs.
diff --git 

[edk2] [PATCH edk2-platforms v2 13/13] Platform: switch to new PL011UartLib

[Ard Biesheuvel]

Switch to the new version of PL011UartLib which supersedes the one
residing in Drivers/ inappropriately.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/AMD/OverdriveBoard/OverdriveBoard.dsc   | 2 +-
 Platform/Hisilicon/HiKey/HiKey.dsc   | 2 +-
 Platform/LeMaker/CelloBoard/CelloBoard.dsc   | 2 +-
 Platform/Socionext/DeveloperBox/DeveloperBox.dsc | 2 +-
 Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc | 2 +-
 Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc  | 2 +-
 Silicon/Hisilicon/Hisilicon.dsc.inc  | 2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc 
b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
index 7258daa76094..2cc71d499ece 100644
--- a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
+++ b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
@@ -106,7 +106,7 @@ [LibraryClasses.common]
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
 
   # ARM PL011 UART Driver
-  PL011UartLib|ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.inf
+  PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
 
   #
diff --git a/Platform/Hisilicon/HiKey/HiKey.dsc 
b/Platform/Hisilicon/HiKey/HiKey.dsc
index a339eadc30ac..97811eb8d991 100644
--- a/Platform/Hisilicon/HiKey/HiKey.dsc
+++ b/Platform/Hisilicon/HiKey/HiKey.dsc
@@ -84,7 +84,7 @@ [LibraryClasses.common]
   
UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
   
UefiApplicationEntryPoint|MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf
 
-  PL011UartLib|ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.inf
+  PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
   
RealTimeClockLib|ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.inf
   TimeBaseLib|EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf
diff --git a/Platform/LeMaker/CelloBoard/CelloBoard.dsc 
b/Platform/LeMaker/CelloBoard/CelloBoard.dsc
index 30b080495639..33e9ebee3255 100644
--- a/Platform/LeMaker/CelloBoard/CelloBoard.dsc
+++ b/Platform/LeMaker/CelloBoard/CelloBoard.dsc
@@ -102,7 +102,7 @@ [LibraryClasses.common]
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
 
   # ARM PL011 UART Driver
-  PL011UartLib|ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.inf
+  PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
 
   #
diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
index 21987d890997..2405ffaf3dc0 100644
--- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
+++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
@@ -115,7 +115,7 @@ [LibraryClasses.common]
   DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
   
DebugAgentTimerLib|EmbeddedPkg/Library/DebugAgentTimerLibNull/DebugAgentTimerLibNull.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
-  PL011UartLib|ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.inf
+  PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
 
   HttpLib|MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.inf
   TcpIoLib|MdeModulePkg/Library/DxeTcpIoLib/DxeTcpIoLib.inf
diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc 
b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
index 6c9afa518fdf..5635286dbfc4 100644
--- a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
+++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
@@ -115,7 +115,7 @@ [LibraryClasses.common]
   DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
   
DebugAgentTimerLib|EmbeddedPkg/Library/DebugAgentTimerLibNull/DebugAgentTimerLibNull.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
-  PL011UartLib|ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.inf
+  PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
 
   HttpLib|MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.inf
   TcpIoLib|MdeModulePkg/Library/DxeTcpIoLib/DxeTcpIoLib.inf
diff --git a/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc 
b/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
index 5cbf3628fb89..5352fc4e5575 100644
--- a/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
+++ b/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
@@ -104,7 +104,7 @@ [LibraryClasses.common]
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
 
   # ARM PL011 UART Driver
-  PL011UartLib|ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.inf
+  

[edk2] [PATCH edk2-platforms v2 10/13] Platform: remove stale PL35xSmcLib references

[Ard Biesheuvel]

No drivers actually use PL35xSmcLib so remove any resolutions for it.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc | 2 --
 Silicon/Hisilicon/Hisilicon.dsc.inc  | 2 --
 2 files changed, 4 deletions(-)

diff --git a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc 
b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
index 079c743dd2e9..0fbef7e378cd 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
@@ -88,8 +88,6 @@ [LibraryClasses.common]
   # ARM PL031 RTC Driver
   
RealTimeClockLib|ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.inf
   TimeBaseLib|EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf
-  # ARM PL354 SMC Driver
-  PL35xSmcLib|ArmPlatformPkg/Drivers/PL35xSmc/PL35xSmc.inf
   # ARM PL011 UART Driver
   PL011UartLib|ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
diff --git a/Silicon/Hisilicon/Hisilicon.dsc.inc 
b/Silicon/Hisilicon/Hisilicon.dsc.inc
index 84e5a38475be..318c4ffeb250 100644
--- a/Silicon/Hisilicon/Hisilicon.dsc.inc
+++ b/Silicon/Hisilicon/Hisilicon.dsc.inc
@@ -64,8 +64,6 @@ [LibraryClasses.common]
 
   
ResetSystemLib|ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.inf
 
-  # ARM PL354 SMC Driver
-  PL35xSmcLib|ArmPlatformPkg/Drivers/PL35xSmc/PL35xSmc.inf
   # ARM PL011 UART Driver
   PL011UartLib|ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.inf
 
-- 
2.11.0

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

[edk2] [PATCH edk2-platforms v2 09/13] Platform: remove references to EBL libraries

[Ard Biesheuvel]

None of these platforms still include EBL, but some references
remained to its support libraries. Get rid of that.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc | 6 --
 Platform/Marvell/Armada/Armada.dsc.inc   | 6 --
 Silicon/Hisilicon/Hisilicon.dsc.inc  | 6 --
 3 files changed, 18 deletions(-)

diff --git a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc 
b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
index 269636878977..079c743dd2e9 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
@@ -95,12 +95,6 @@ [LibraryClasses.common]
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
 
-  # EBL Related Libraries
-  EblCmdLib|ArmPlatformPkg/Library/EblCmdLib/EblCmdLib.inf
-  EfiFileLib|EmbeddedPkg/Library/EfiFileLib/EfiFileLib.inf
-  
EblAddExternalCommandLib|EmbeddedPkg/Library/EblAddExternalCommandLib/EblAddExternalCommandLib.inf
-  EblNetworkLib|EmbeddedPkg/Library/EblNetworkLib/EblNetworkLib.inf
-
   #
   # Uncomment (and comment out the next line) For RealView Debugger. The 
Standard IO window
   # in the debugger will show load and unload commands for symbols. You can 
cut and paste this
diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
b/Platform/Marvell/Armada/Armada.dsc.inc
index 2cd96e60a82c..77f08c419417 100644
--- a/Platform/Marvell/Armada/Armada.dsc.inc
+++ b/Platform/Marvell/Armada/Armada.dsc.inc
@@ -105,12 +105,6 @@ [LibraryClasses.common]
   FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
   SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
 
-  # EBL Related Libraries
-  EblCmdLib|ArmPlatformPkg/Library/EblCmdLib/EblCmdLib.inf
-  EfiFileLib|EmbeddedPkg/Library/EfiFileLib/EfiFileLib.inf
-  
EblAddExternalCommandLib|EmbeddedPkg/Library/EblAddExternalCommandLib/EblAddExternalCommandLib.inf
-  EblNetworkLib|EmbeddedPkg/Library/EblNetworkLib/EblNetworkLib.inf
-
   #
   # Uncomment (and comment out the next line) For RealView Debugger. The 
Standard IO window
   # in the debugger will show load and unload commands for symbols. You can 
cut and paste this
diff --git a/Silicon/Hisilicon/Hisilicon.dsc.inc 
b/Silicon/Hisilicon/Hisilicon.dsc.inc
index f24f6dabd12c..84e5a38475be 100644
--- a/Silicon/Hisilicon/Hisilicon.dsc.inc
+++ b/Silicon/Hisilicon/Hisilicon.dsc.inc
@@ -72,12 +72,6 @@ [LibraryClasses.common]
   
SerialPortLib|Silicon/Hisilicon/Library/Dw8250SerialPortLib/Dw8250SerialPortLib.inf
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
 
-  # EBL Related Libraries
-  EblCmdLib|ArmPlatformPkg/Library/EblCmdLib/EblCmdLib.inf
-  EfiFileLib|EmbeddedPkg/Library/EfiFileLib/EfiFileLib.inf
-  
EblAddExternalCommandLib|EmbeddedPkg/Library/EblAddExternalCommandLib/EblAddExternalCommandLib.inf
-  EblNetworkLib|EmbeddedPkg/Library/EblNetworkLib/EblNetworkLib.inf
-
   UefiDevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
   #
   # Uncomment (and comment out the next line) For RealView Debugger. The 
Standard IO window
-- 
2.11.0

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

[edk2] [PATCH edk2-platforms v2 05/13] Platform/ARM/Juno: import ArmJunoPkg from EDK2

[Ard Biesheuvel]

Move ArmJunoPkg into edk2-platforms, so it can be removed from the main
EDK2 tree.

This allows use to remove the dodgy -I arguments to GCC to build shared
modules with a different copy of ArmPlatform.h, which was making it very
difficult to properly split the various modules into their own packages.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/ARM/JunoPkg/AcpiTables/AcpiTables.inf |   
3 +-
 Platform/ARM/JunoPkg/ArmJuno.dec   |  
48 ++
 Platform/ARM/JunoPkg/ArmJuno.dsc   |   
8 +-
 Platform/ARM/JunoPkg/ArmJuno.fdf   |   
2 +-
 Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/AcpiTables.c   |  
78 +++
 Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c   | 
550 
 Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf |  
88 
 Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h   |  
54 ++
 Platform/ARM/JunoPkg/Include/ArmPlatform.h | 
180 +++
 Platform/ARM/JunoPkg/Library/ArmJunoLib/AArch64/ArmJunoHelper.S|  
58 +++
 Platform/ARM/JunoPkg/Library/ArmJunoLib/Arm/ArmJunoHelper.S|  
91 
 Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJuno.c  | 
193 +++
 Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJunoLib.inf |  
80 +++
 Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJunoMem.c   | 
173 ++
 Platform/ARM/JunoPkg/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.inf |   
2 +-
 Platform/ARM/JunoPkg/Library/NorFlashJunoLib/NorFlashJuno.c|  
68 +++
 Platform/ARM/JunoPkg/Library/NorFlashJunoLib/NorFlashJunoLib.inf   |  
33 ++
 Platform/ARM/JunoPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf   |   
2 +-
 Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc  |  
12 +
 Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc   |   
3 +
 Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc   |  
10 -
 21 files changed, 1716 insertions(+), 20 deletions(-)

diff --git a/Platform/ARM/JunoPkg/AcpiTables/AcpiTables.inf 
b/Platform/ARM/JunoPkg/AcpiTables/AcpiTables.inf
index 741ea191be36..539974ff2416 100644
--- a/Platform/ARM/JunoPkg/AcpiTables/AcpiTables.inf
+++ b/Platform/ARM/JunoPkg/AcpiTables/AcpiTables.inf
@@ -33,11 +33,10 @@ [Sources]
 [Packages]
   ArmPkg/ArmPkg.dec
   ArmPlatformPkg/ArmPlatformPkg.dec
-  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressPkg.dec
-  ArmPlatformPkg/ArmJunoPkg/ArmJuno.dec
   EmbeddedPkg/EmbeddedPkg.dec
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
+  Platform/ARM/JunoPkg/ArmJuno.dec
 
 [FixedPcd]
   gArmPlatformTokenSpaceGuid.PcdCoreCount
diff --git a/Platform/ARM/JunoPkg/ArmJuno.dec b/Platform/ARM/JunoPkg/ArmJuno.dec
new file mode 100644
index ..60cef6d23a2d
--- /dev/null
+++ b/Platform/ARM/JunoPkg/ArmJuno.dec
@@ -0,0 +1,48 @@
+#
+#  Copyright (c) 2013-2015, ARM Limited. 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.
+#
+
+[Defines]
+  DEC_SPECIFICATION  = 0x0001001A
+  PACKAGE_NAME   = ArmJunoPkg
+  PACKAGE_GUID   = a1147a20-3144-4f8d-8295-b48311c8e4a4
+  PACKAGE_VERSION= 0.1
+
+
+#
+# Include Section - list of Include Paths that are provided by this package.
+#   Comments are used for Keywords and Module Types.
+#
+# Supported Module Types:
+#  BASE SEC PEI_CORE PEIM DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER 
DXE_SMM_DRIVER DXE_SAL_DRIVER UEFI_DRIVER UEFI_APPLICATION
+#
+
+[Includes.common]
+  Include# Root include for the package
+
+[Guids.common]
+  gArmJunoTokenSpaceGuid=  { 0xa1147a20, 0x3144, 0x4f8d, { 0x82, 0x95, 
0xb4, 0x83, 0x11, 0xc8, 0xe4, 0xa4 } }
+
+[PcdsFeatureFlag.common]
+  gArmJunoTokenSpaceGuid.PcdPciMaxPayloadFixup|FALSE|BOOLEAN|0x0013
+
+[PcdsFixedAtBuild.common]
+  gArmJunoTokenSpaceGuid.PcdPcieControlBaseAddress|0x7FF2|UINT64|0x000B
+  
gArmJunoTokenSpaceGuid.PcdPcieRootPortBaseAddress|0x7FF3|UINT64|0x000C
+  
gArmJunoTokenSpaceGuid.PcdPciConfigurationSpaceBaseAddress|0x4000|UINT64|0x0011
+  

[edk2] [PATCH edk2-platforms v2 04/13] Platform/Hisilicon: remove bogus VExpress dependencies

[Ard Biesheuvel]

Remove false copy-pasted dependencies on various VExpress support
libraries.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/Hisilicon/D02/Pv660D02.dsc | 3 ---
 Platform/Hisilicon/D03/D03.dsc  | 5 -
 Platform/Hisilicon/D05/D05.dsc  | 4 
 Platform/Hisilicon/HiKey/HiKey.dsc  | 1 -
 Silicon/Hisilicon/Hisilicon.dsc.inc | 5 -
 5 files changed, 18 deletions(-)

diff --git a/Platform/Hisilicon/D02/Pv660D02.dsc 
b/Platform/Hisilicon/D02/Pv660D02.dsc
index 1fd2b98f1552..ba3047882611 100644
--- a/Platform/Hisilicon/D02/Pv660D02.dsc
+++ b/Platform/Hisilicon/D02/Pv660D02.dsc
@@ -36,9 +36,6 @@ [LibraryClasses.common]
   ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
   
ArmPlatformLib|Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf
 
-  
ArmPlatformSysConfigLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfigLib.inf
-  
NorFlashPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/NorFlashArmVExpressLib/NorFlashArmVExpressLib.inf
-  
LcdPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
   I2CLib|Silicon/Hisilicon/Library/I2CLib/I2CLib.inf
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
 
diff --git a/Platform/Hisilicon/D03/D03.dsc b/Platform/Hisilicon/D03/D03.dsc
index f2a120e31b16..491862a3b27e 100644
--- a/Platform/Hisilicon/D03/D03.dsc
+++ b/Platform/Hisilicon/D03/D03.dsc
@@ -36,11 +36,6 @@ [LibraryClasses.common]
   ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
   
ArmPlatformLib|Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf
 
-  
ArmPlatformSysConfigLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfigLib.inf
-  
NorFlashPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/NorFlashArmVExpressLib/NorFlashArmVExpressLib.inf
-  
LcdPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
-
-
   I2CLib|Silicon/Hisilicon/Library/I2CLib/I2CLib.inf
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
 
diff --git a/Platform/Hisilicon/D05/D05.dsc b/Platform/Hisilicon/D05/D05.dsc
index 64101a7d0160..de2d3579a494 100644
--- a/Platform/Hisilicon/D05/D05.dsc
+++ b/Platform/Hisilicon/D05/D05.dsc
@@ -38,10 +38,6 @@ [Defines]
 [LibraryClasses.common]
   ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
   
ArmPlatformLib|Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf
-  
ArmPlatformSysConfigLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfigLib.inf
-  
NorFlashPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/NorFlashArmVExpressLib/NorFlashArmVExpressLib.inf
-  
LcdPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
-
 
   I2CLib|Silicon/Hisilicon/Library/I2CLib/I2CLib.inf
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
diff --git a/Platform/Hisilicon/HiKey/HiKey.dsc 
b/Platform/Hisilicon/HiKey/HiKey.dsc
index 2e3b1c8799cc..f0380ee1f929 100644
--- a/Platform/Hisilicon/HiKey/HiKey.dsc
+++ b/Platform/Hisilicon/HiKey/HiKey.dsc
@@ -45,7 +45,6 @@ [LibraryClasses.common]
   ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
   ArmPlatformLib|Platform/Hisilicon/HiKey/Library/HiKeyLib/HiKeyLib.inf
   
ArmPlatformStackLib|ArmPlatformPkg/Library/ArmPlatformStackLib/ArmPlatformStackLib.inf
-  
ArmPlatformSysConfigLib|ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.inf
 
   BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
   BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
diff --git a/Silicon/Hisilicon/Hisilicon.dsc.inc 
b/Silicon/Hisilicon/Hisilicon.dsc.inc
index fbecb6497469..f24f6dabd12c 100644
--- a/Silicon/Hisilicon/Hisilicon.dsc.inc
+++ b/Silicon/Hisilicon/Hisilicon.dsc.inc
@@ -62,12 +62,7 @@ [LibraryClasses.common]
   ArmSmcLib|ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf
   ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
 
-  # Versatile Express Specific Libraries
-  
ArmPlatformSysConfigLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfigLib.inf
-  
NorFlashPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/NorFlashArmVExpressLib/NorFlashArmVExpressLib.inf
   
ResetSystemLib|ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.inf
-  # ARM PL111 Lcd Driver
-  
LcdPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
 
   # ARM PL354 SMC Driver
   PL35xSmcLib|ArmPlatformPkg/Drivers/PL35xSmc/PL35xSmc.inf
-- 
2.11.0

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

[edk2] [PATCH edk2-platforms v2 03/13] Platform/ArmVExpress-FVP: remove bogus ArmPlatformSecLib reference

[Ard Biesheuvel]

No FVP driver uses this library so remove the resolution.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc 
b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
index 51f0529db251..fc628ad08c9e 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
@@ -62,7 +62,6 @@ [LibraryClasses.common]
   
DtPlatformDtbLoaderLib|Platform/ARM/VExpressPkg/Library/ArmVExpressDtPlatformDtbLoaderLib/ArmVExpressDtPlatformDtbLoaderLib.inf
 
 [LibraryClasses.common.SEC]
-  
ArmPlatformSecLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/ArmVExpressSecLib.inf
   
ArmPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/ArmVExpressLibSec.inf
 
 [LibraryClasses.common.UEFI_DRIVER, LibraryClasses.common.UEFI_APPLICATION, 
LibraryClasses.common.DXE_RUNTIME_DRIVER, LibraryClasses.common.DXE_DRIVER]
-- 
2.11.0

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

[edk2] [PATCH edk2-platforms v2 07/13] Platform/ARM: remove outdated SP804 TimerLib reference

[Ard Biesheuvel]

ArmVExpress.dsc.inc declares a TimerLib dependency and resolves it
using ArmPlatformPkg/Library/SP804TimerLib/SP804TimerLib.inf, but
all users of the include file supersede it with ArmArchTimerLib.inf
so let's just use that instead.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/ARM/JunoPkg/ArmJuno.dsc | 1 -
 Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc| 1 -
 Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc | 2 --
 Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc | 3 +--
 4 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/Platform/ARM/JunoPkg/ArmJuno.dsc b/Platform/ARM/JunoPkg/ArmJuno.dsc
index 187c9f5602e5..80a5ef631ce9 100644
--- a/Platform/ARM/JunoPkg/ArmJuno.dsc
+++ b/Platform/ARM/JunoPkg/ArmJuno.dsc
@@ -41,7 +41,6 @@ [LibraryClasses.common]
 
   
NorFlashPlatformLib|Platform/ARM/JunoPkg/Library/NorFlashJunoLib/NorFlashJunoLib.inf
 
-  TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
 
diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc 
b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc
index 51da85fe8bc0..4a55dac7a4a4 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc
@@ -51,7 +51,6 @@ [LibraryClasses.common]
 
   
LcdPlatformLib|Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
 
-  TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
   ArmSmcLib|ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf
 
 [LibraryClasses.common.DXE_RUNTIME_DRIVER]
diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc 
b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
index df6951900ed8..829854963b30 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
@@ -49,8 +49,6 @@ [LibraryClasses.common]
   
LcdPlatformLib|Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
 !endif
 
-  TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
-
   # Virtio Support
   VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
   
VirtioMmioDeviceLib|OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
diff --git a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc 
b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
index 40e1c868fcb2..269636878977 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
@@ -93,8 +93,7 @@ [LibraryClasses.common]
   # ARM PL011 UART Driver
   PL011UartLib|ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.inf
   
SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
-  # ARM SP804 Dual Timer Driver
-  TimerLib|ArmPlatformPkg/Library/SP804TimerLib/SP804TimerLib.inf
+  TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
 
   # EBL Related Libraries
   EblCmdLib|ArmPlatformPkg/Library/EblCmdLib/EblCmdLib.inf
-- 
2.11.0

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

[edk2] [PATCH edk2-platforms v2 08/13] Platform/Hisilicon: remove SP804 PCD definitions

[Ard Biesheuvel]

These platforms don't actually include the SP804 driver so no need
to set the PCDs.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/Hisilicon/D02/Pv660D02.dsc | 8 
 Platform/Hisilicon/D03/D03.dsc  | 8 
 2 files changed, 16 deletions(-)

diff --git a/Platform/Hisilicon/D02/Pv660D02.dsc 
b/Platform/Hisilicon/D02/Pv660D02.dsc
index ba3047882611..cd0fbdb56fdf 100644
--- a/Platform/Hisilicon/D02/Pv660D02.dsc
+++ b/Platform/Hisilicon/D02/Pv660D02.dsc
@@ -201,14 +201,6 @@ [PcdsFixedAtBuild.common]
   gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 
0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
 
-  ## SP804 DualTimer
-  gArmPlatformTokenSpaceGuid.PcdSP804TimerFrequencyInMHz|200
-  gArmPlatformTokenSpaceGuid.PcdSP804TimerPeriodicInterruptNum|304
-  gArmPlatformTokenSpaceGuid.PcdSP804TimerPeriodicBase|0x8006
-  ## TODO: need to confirm the base for Performance and Metronome base for 
PV660
-  gArmPlatformTokenSpaceGuid.PcdSP804TimerPerformanceBase|0x8006
-  gArmPlatformTokenSpaceGuid.PcdSP804TimerMetronomeBase|0x8006
-
   gHisiTokenSpaceGuid.PcdPcieRootBridgeMask|0x6 # 
bit0:HB0RB0,bit1:HB0RB1,bit2:HB0RB2,bit3:HB0RB3,bit4:HB1RB0,bit5:HB1RB1,bit6:HB1RB2,bit7:HB1RB3
   gHisiTokenSpaceGuid.PcdHb1BaseAddress|0x4000 # 4T
 
diff --git a/Platform/Hisilicon/D03/D03.dsc b/Platform/Hisilicon/D03/D03.dsc
index 491862a3b27e..a5aa5f7fcd0a 100644
--- a/Platform/Hisilicon/D03/D03.dsc
+++ b/Platform/Hisilicon/D03/D03.dsc
@@ -286,14 +286,6 @@ [PcdsFixedAtBuild.common]
   gHisiTokenSpaceGuid.PcdHb0Rb2IoSize|0x #64K
 
   gHisiTokenSpaceGuid.Pcdsoctype|0x1610
-  ## SP804 DualTimer
-  gArmPlatformTokenSpaceGuid.PcdSP804TimerFrequencyInMHz|200
-  gArmPlatformTokenSpaceGuid.PcdSP804TimerPeriodicInterruptNum|0xb0
-  gArmPlatformTokenSpaceGuid.PcdSP804TimerPeriodicBase|0x4006
-  ## TODO: need to confirm the base for Performance and Metronome base for 
PV660
-  gArmPlatformTokenSpaceGuid.PcdSP804TimerPerformanceBase|0x4006
-  gArmPlatformTokenSpaceGuid.PcdSP804TimerMetronomeBase|0x4006
-
 
 

 #
-- 
2.11.0

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

[edk2] [PATCH edk2-platforms v2 02/13] Platform: remove bogus ArmTrustedMonitorLib references

[Ard Biesheuvel]

Remove copy-pasted ArmTrustedMonitorLib library class resolutions
that none of the platforms actually need.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/AMD/OverdriveBoard/OverdriveBoard.dsc  | 2 --
 Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc| 3 ---
 Platform/LeMaker/CelloBoard/CelloBoard.dsc  | 2 --
 Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc | 2 --
 Silicon/Hisilicon/Hisilicon.dsc.inc | 3 ---
 5 files changed, 12 deletions(-)

diff --git a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc 
b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
index ec350c999f19..7258daa76094 100644
--- a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
+++ b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
@@ -175,8 +175,6 @@ [LibraryClasses.common.SEC]
   
DebugAgentLib|ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf
   
DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf
 
-  # Trustzone Support
-  
ArmTrustedMonitorLib|ArmPlatformPkg/Library/ArmTrustedMonitorLibNull/ArmTrustedMonitorLibNull.inf
   ArmGicArchLib|ArmPkg/Library/ArmGicArchSecLib/ArmGicArchSecLib.inf
 
 [LibraryClasses.common.PEIM, LibraryClasses.common.SEC]
diff --git a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc 
b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
index 7b405a949ebd..3db269086d5b 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
@@ -169,9 +169,6 @@ [LibraryClasses.common.SEC]
   PerformanceLib|MdeModulePkg/Library/PeiPerformanceLib/PeiPerformanceLib.inf
 !endif
 
-  # Trustzone Support
-  
ArmTrustedMonitorLib|ArmPlatformPkg/Library/ArmTrustedMonitorLibNull/ArmTrustedMonitorLibNull.inf
-
   ArmGicArchLib|ArmPkg/Library/ArmGicArchSecLib/ArmGicArchSecLib.inf
 
 [LibraryClasses.common.PEI_CORE]
diff --git a/Platform/LeMaker/CelloBoard/CelloBoard.dsc 
b/Platform/LeMaker/CelloBoard/CelloBoard.dsc
index 7c4adb3a53bf..30b080495639 100644
--- a/Platform/LeMaker/CelloBoard/CelloBoard.dsc
+++ b/Platform/LeMaker/CelloBoard/CelloBoard.dsc
@@ -154,8 +154,6 @@ [LibraryClasses.common.SEC]
   
DebugAgentLib|ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf
   
DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf
 
-  # Trustzone Support
-  
ArmTrustedMonitorLib|ArmPlatformPkg/Library/ArmTrustedMonitorLibNull/ArmTrustedMonitorLibNull.inf
   ArmGicArchLib|ArmPkg/Library/ArmGicArchSecLib/ArmGicArchSecLib.inf
 
 [LibraryClasses.common.PEIM, LibraryClasses.common.SEC]
diff --git a/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc 
b/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
index 73c0c7531f26..5cbf3628fb89 100644
--- a/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
+++ b/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
@@ -160,8 +160,6 @@ [LibraryClasses.common.SEC]
   
DebugAgentLib|ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf
   
DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf
 
-  # Trustzone Support
-  
ArmTrustedMonitorLib|ArmPlatformPkg/Library/ArmTrustedMonitorLibNull/ArmTrustedMonitorLibNull.inf
   ArmGicArchLib|ArmPkg/Library/ArmGicArchSecLib/ArmGicArchSecLib.inf
 
 [LibraryClasses.common.PEIM, LibraryClasses.common.SEC]
diff --git a/Silicon/Hisilicon/Hisilicon.dsc.inc 
b/Silicon/Hisilicon/Hisilicon.dsc.inc
index c1c947f38cba..fbecb6497469 100644
--- a/Silicon/Hisilicon/Hisilicon.dsc.inc
+++ b/Silicon/Hisilicon/Hisilicon.dsc.inc
@@ -126,9 +126,6 @@ [LibraryClasses.common]
 [LibraryClasses.common.SEC]
   
DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf
 
-  # Trustzone Support
-  
ArmTrustedMonitorLib|ArmPlatformPkg/Library/ArmTrustedMonitorLibNull/ArmTrustedMonitorLibNull.inf
-
   ArmGicArchLib|ArmPkg/Library/ArmGicArchSecLib/ArmGicArchSecLib.inf
   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
   BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
-- 
2.11.0

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

[edk2] [PATCH edk2-platforms v2 01/13] Platform: remove bogus ArmPlatformSecExtraActionLib references

[Ard Biesheuvel]

Remove copy-pasted ArmPlatformSecExtraActionLib library class resolutions
that none of the platforms actually need.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/AMD/OverdriveBoard/OverdriveBoard.dsc  | 2 --
 Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc| 2 --
 Platform/LeMaker/CelloBoard/CelloBoard.dsc  | 2 --
 Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc | 2 --
 Silicon/Hisilicon/Hisilicon.dsc.inc | 2 --
 5 files changed, 10 deletions(-)

diff --git a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc 
b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
index 8620f6be3514..ec350c999f19 100644
--- a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
+++ b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
@@ -172,8 +172,6 @@ [LibraryClasses.common.SEC]
   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
   ArmPlatformLib|Silicon/AMD/Styx/Library/AmdStyxLib/AmdStyxLibSec.inf
 
-  
ArmPlatformSecExtraActionLib|ArmPlatformPkg/Library/DebugSecExtraActionLib/DebugSecExtraActionLib.inf
-
   
DebugAgentLib|ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf
   
DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf
 
diff --git a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc 
b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
index 1605eedbdd8c..7b405a949ebd 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
@@ -156,8 +156,6 @@ [LibraryClasses.common]
   
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
 
 [LibraryClasses.common.SEC]
-  
ArmPlatformSecExtraActionLib|ArmPlatformPkg/Library/DebugSecExtraActionLib/DebugSecExtraActionLib.inf
-
   
DebugAgentLib|ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf
   
DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf
 
diff --git a/Platform/LeMaker/CelloBoard/CelloBoard.dsc 
b/Platform/LeMaker/CelloBoard/CelloBoard.dsc
index e03c7c4c3526..7c4adb3a53bf 100644
--- a/Platform/LeMaker/CelloBoard/CelloBoard.dsc
+++ b/Platform/LeMaker/CelloBoard/CelloBoard.dsc
@@ -151,8 +151,6 @@ [LibraryClasses.common.SEC]
   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
   ArmPlatformLib|Silicon/AMD/Styx/Library/AmdStyxLib/AmdStyxLibSec.inf
 
-  
ArmPlatformSecExtraActionLib|ArmPlatformPkg/Library/DebugSecExtraActionLib/DebugSecExtraActionLib.inf
-
   
DebugAgentLib|ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf
   
DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf
 
diff --git a/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc 
b/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
index 29ce8b3bd18e..73c0c7531f26 100644
--- a/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
+++ b/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
@@ -157,8 +157,6 @@ [LibraryClasses.common.SEC]
   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
   ArmPlatformLib|Silicon/AMD/Styx/Library/AmdStyxLib/AmdStyxLibSec.inf
 
-  
ArmPlatformSecExtraActionLib|ArmPlatformPkg/Library/DebugSecExtraActionLib/DebugSecExtraActionLib.inf
-
   
DebugAgentLib|ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf
   
DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf
 
diff --git a/Silicon/Hisilicon/Hisilicon.dsc.inc 
b/Silicon/Hisilicon/Hisilicon.dsc.inc
index d77f0e35431e..c1c947f38cba 100644
--- a/Silicon/Hisilicon/Hisilicon.dsc.inc
+++ b/Silicon/Hisilicon/Hisilicon.dsc.inc
@@ -124,8 +124,6 @@ [LibraryClasses.common]
   NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
 
 [LibraryClasses.common.SEC]
-  
ArmPlatformSecExtraActionLib|ArmPlatformPkg/Library/DebugSecExtraActionLib/DebugSecExtraActionLib.inf
-
   
DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf
 
   # Trustzone Support
-- 
2.11.0

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

[edk2] [PATCH edk2-platforms v2 00/13] Move ArmPlatformPkg stuff into edk2-platforms

[Ard Biesheuvel]

This is mostly a preparatory series that will allow us to get rid of a lot
of code that is specific to only a single ARM development platform out of
the main EDK2 tree.

First of all, it removes a couple of false dependencies of various platforms
on libraries that are no longer used, or not actually used by the platform
in question. Patches #5, #6 and #11 move the bulk of the support for ARM
development platforms into edk2-platforms.

Ard Biesheuvel (13):
  Platform: remove bogus ArmPlatformSecExtraActionLib references
  Platform: remove bogus ArmTrustedMonitorLib references
  Platform/ArmVExpress-FVP: remove bogus ArmPlatformSecLib reference
  Platform/Hisilicon: remove bogus VExpress dependencies
  Platform/ARM/Juno: import ArmJunoPkg from EDK2
  Platform/ARM/VExpress: import VExpressPkg from EDK2
  Platform/ARM: remove outdated SP804 TimerLib reference
  Platform/Hisilicon: remove SP804 PCD definitions
  Platform: remove references to EBL libraries
  Platform: remove stale PL35xSmcLib references
  Platform/ARM: import BootMonFs and ArmShellCmdRunAxf from EDK2
  Platform: remove stale EBL related PCD setting
  Platform: switch to new PL011UartLib

 Platform/AMD/OverdriveBoard/OverdriveBoard.dsc 
|6 +-
 Platform/ARM/ARM.dec   
|   25 +
 Platform/ARM/Drivers/BootMonFs/BootMonFs.dec   
|   26 +
 Platform/ARM/Drivers/BootMonFs/BootMonFs.inf   
|   63 ++
 Platform/ARM/Drivers/BootMonFs/BootMonFsApi.h  
|  388 +++
 Platform/ARM/Drivers/BootMonFs/BootMonFsDir.c  
|  766 ++
 Platform/ARM/Drivers/BootMonFs/BootMonFsEntryPoint.c   
|  529 ++
 Platform/ARM/Drivers/BootMonFs/BootMonFsHw.h   
|   57 ++
 Platform/ARM/Drivers/BootMonFs/BootMonFsImages.c   
|  222 
 Platform/ARM/Drivers/BootMonFs/BootMonFsInternal.h 
|  101 ++
 Platform/ARM/Drivers/BootMonFs/BootMonFsOpenClose.c
|  795 +++
 Platform/ARM/Drivers/BootMonFs/BootMonFsReadWrite.c
|  259 +
 Platform/ARM/Drivers/BootMonFs/BootMonFsUnsupported.c  
|   37 +
 Platform/ARM/Include/Guid/BootMonFsFileInfo.h  
|   47 +
 Platform/ARM/Include/Library/ArmShellCmdLib.h  
|   57 ++
 Platform/ARM/JunoPkg/AcpiTables/AcpiTables.inf 
|3 +-
 Platform/ARM/JunoPkg/ArmJuno.dec   
|   48 +
 Platform/ARM/JunoPkg/ArmJuno.dsc   
|   12 +-
 Platform/ARM/JunoPkg/ArmJuno.fdf   
|4 +-
 Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/AcpiTables.c   
|   78 ++
 Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c   
|  550 ++
 Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf 
|   89 ++
 Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h   
|   54 +
 Platform/ARM/JunoPkg/Include/ArmPlatform.h 
|  180 
 Platform/ARM/JunoPkg/Library/ArmJunoLib/AArch64/ArmJunoHelper.S
|   58 ++
 Platform/ARM/JunoPkg/Library/ArmJunoLib/Arm/ArmJunoHelper.S
|   91 ++
 Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJuno.c  
|  193 
 Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJunoLib.inf 
|   80 ++
 Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJunoMem.c   
|  173 
 Platform/ARM/JunoPkg/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.inf 
|2 +-
 Platform/ARM/JunoPkg/Library/NorFlashJunoLib/NorFlashJuno.c
|   68 ++
 Platform/ARM/JunoPkg/Library/NorFlashJunoLib/NorFlashJunoLib.inf   
|   33 +
 Platform/ARM/JunoPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf   
|2 +-
 Platform/ARM/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.c 
|   95 ++
 

[edk2] [PATCH v2 2/2] ArmVirtPkg: switch to new PL011UartLib implementation

[Ard Biesheuvel]

Switch to the new, cleaned up PL011UartLib implementation so we will
be able to remove the old one.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmVirtPkg/ArmVirt.dsc.inc| 2 +-
 ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c | 5 ++---
 ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.c  | 5 ++---
 3 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
index c92a69281ae4..50eb8675d1c0 100644
--- a/ArmVirtPkg/ArmVirt.dsc.inc
+++ b/ArmVirtPkg/ArmVirt.dsc.inc
@@ -106,7 +106,7 @@ [LibraryClasses.common]
   
RealTimeClockLib|ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.inf
   TimeBaseLib|EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf
   # ARM PL011 UART Driver
-  PL011UartLib|ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.inf
+  PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
   
SerialPortLib|ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.inf
 
   #
diff --git 
a/ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c 
b/ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c
index e28750f3b4c4..d9fd0ef98359 100644
--- a/ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c
+++ b/ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c
@@ -16,14 +16,13 @@
 
 **/
 
-#include 
+#include 
 
 #include 
+#include 
 #include 
 #include 
 
-#include 
-
 RETURN_STATUS
 EFIAPI
 SerialPortInitialize (
diff --git a/ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.c 
b/ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.c
index 05d3547fda91..c161dd6349d3 100644
--- a/ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.c
+++ b/ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.c
@@ -17,9 +17,10 @@
 
 **/
 
-#include 
+#include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -28,8 +29,6 @@
 #include 
 #include 
 
-#include 
-
 STATIC UINTN mSerialBaseAddress;
 
 RETURN_STATUS
-- 
2.11.0

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

[edk2] [PATCH v2 0/2] ArmplatformPkg: clean up PL011 support library

[Ard Biesheuvel]

Clean up the PL011 UART support library, by moving it into the appropriate
place for libraries, and splitting the header file into an implementation
and an interface part.

Ard Biesheuvel (2):
  ArmPlatformPkg: reorganize PL011 code
  ArmVirtPkg: switch to new PL011UartLib implementation

 ArmPlatformPkg/ArmPlatformPkg.dec |   3 +
 ArmPlatformPkg/Include/Library/PL011UartLib.h | 187 

 ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c|   5 +-
 ArmPlatformPkg/Library/PL011UartLib/PL011Uart.h   | 120 
+
 ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.c| 474 

 ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf  |  43 ++
 ArmVirtPkg/ArmVirt.dsc.inc|   2 +-
 ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c |   5 +-
 ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.c  |   5 +-
 9 files changed, 834 insertions(+), 10 deletions(-)
 create mode 100644 ArmPlatformPkg/Include/Library/PL011UartLib.h
 create mode 100644 ArmPlatformPkg/Library/PL011UartLib/PL011Uart.h
 create mode 100644 ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.c
 create mode 100644 ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf

-- 
2.11.0

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

[edk2] [PATCH v2 1/2] ArmPlatformPkg: reorganize PL011 code

[Ard Biesheuvel]

The PL011 code in ArmPlatformPkg is organized in a weird way: there is
a single PL011Uart.h header file under Include/Drivers containing both
register definitions and function entry points. The PL011Uart library
itself is in Drivers/ but it is actually a library.

So let's clean this up: add a new PL011UartLib library class and associated
header file containing only the library prototypes, and move the library
itself under Library/ using a new GUID, with the register definitions moved
into a local header file.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/ArmPlatformPkg.dec  |   3 +
 ArmPlatformPkg/Include/Library/PL011UartLib.h  | 187 
 ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c |   5 +-
 ArmPlatformPkg/Library/PL011UartLib/PL011Uart.h| 120 +
 ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.c | 474 

 ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf   |  43 ++
 6 files changed, 829 insertions(+), 3 deletions(-)

diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec 
b/ArmPlatformPkg/ArmPlatformPkg.dec
index 2d82ead7612a..e282e76667b1 100644
--- a/ArmPlatformPkg/ArmPlatformPkg.dec
+++ b/ArmPlatformPkg/ArmPlatformPkg.dec
@@ -31,6 +31,9 @@ [Defines]
 [Includes.common]
   Include# Root include for the package
 
+[LibraryClasses]
+  PL011UartLib|Include/Library/PL011UartLib.h
+
 [Guids.common]
   gArmPlatformTokenSpaceGuid   = { 0x9c0aaed4, 0x74c5, 0x4043, { 0xb4, 0x17, 
0xa3, 0x22, 0x38, 0x14, 0xce, 0x76 } }
   #
diff --git a/ArmPlatformPkg/Include/Library/PL011UartLib.h 
b/ArmPlatformPkg/Include/Library/PL011UartLib.h
new file mode 100644
index ..9e923a2218d1
--- /dev/null
+++ b/ArmPlatformPkg/Include/Library/PL011UartLib.h
@@ -0,0 +1,187 @@
+/** @file
+*
+*  Copyright (c) 2011-2016, ARM Limited. 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.
+*
+**/
+
+#ifndef __PL011_UART_LIB_H__
+#define __PL011_UART_LIB_H__
+
+#include 
+
+/**
+
+  Initialise the serial port to the specified settings.
+  All unspecified settings will be set to the default values.
+
+  @param[in]  UartBaseThe base address of the serial device.
+  @param[in]  UartClkInHz The clock in Hz for the serial device.
+  Ignored if the PCD PL011UartInteger is not 0
+  @param[in out] BaudRate The baud rate of the serial device. If the
+  baud rate is not supported, the speed will be
+  reduced to the nearest supported one and the
+  variable's value will be updated accordingly.
+  @param[in out] ReceiveFifoDepth The number of characters the device will
+  buffer on input.  Value of 0 will use the
+  device's default FIFO depth.
+  @param[in out]  Parity  If applicable, this is the EFI_PARITY_TYPE
+  that is computed or checked as each character
+  is transmitted or received. If the device
+  does not support parity, the value is the
+  default parity value.
+  @param[in out]  DataBitsThe number of data bits in each character.
+  @param[in out]  StopBitsIf applicable, the EFI_STOP_BITS_TYPE number
+  of stop bits per character.
+  If the device does not support stop bits, the
+  value is the default stop bit value.
+
+  @retval RETURN_SUCCESSAll attributes were set correctly on the
+serial device.
+  @retval RETURN_INVALID_PARAMETER  One or more of the attributes has an
+unsupported value.
+
+**/
+RETURN_STATUS
+EFIAPI
+PL011UartInitializePort (
+  IN UINTN   UartBase,
+  IN UINT32  UartClkInHz,
+  IN OUT UINT64  *BaudRate,
+  IN OUT UINT32  *ReceiveFifoDepth,
+  IN OUT EFI_PARITY_TYPE *Parity,
+  IN OUT UINT8   *DataBits,
+  IN OUT EFI_STOP_BITS_TYPE  *StopBits
+  );
+
+/**
+
+  Assert or deassert the control signals on a serial port.
+  The following control signals are set according their bit settings :
+  . Request to Send
+  . Data Terminal Ready
+
+  @param[in]  UartBase  UART 

Re: [edk2] [PATCH] ArmPlatformPkg ArmVirtPkg: reorganize PL011 code

[Ard Biesheuvel]

On 16 November 2017 at 17:36, Leif Lindholm  wrote:
> On Thu, Nov 16, 2017 at 05:12:16PM +, Ard Biesheuvel wrote:
>> The PL011 code in ArmPlatformPkg is organized in a weird way: there is
>> a single PL011Uart.h header file under Include/Drivers containing both
>> register definitions and function entry points. The PL011Uart library
>> itself is in Drivers/ but it is actually a library.
>>
>> So let's clean this up: add a new PL011UartLib library class and associated
>> header file containing only the library prototypes, and move the library
>> itself under Library/ using a new GUID, with the register definitions moved
>> into a local header file.
>>
>> Note that we need to retain the old implementation for out of tree
>> platforms,
>
> s/need to//
>
> Do we need to?

At least until we switch over edk2-platforms, yes.

> I mean, we could, and give a bit of a warning for people to switch
> over. But does the change actually entail anything more than pointing
> to the new .inf location?

No.

> If not, we're just moving the point at
> which platforms fail and have to modify their .dsc/.fdf.
>
> That said, I'm not religiously opposed to a grace period - but I
> don't want the old version hanging around to get included in the next
> UDK release.
>
> I _would_ prefer to see the ArmVirtPkg change as a separate patch.
> Especially if the old copy is kept around.
>

Fair enough.

> Nice bit of cleanup though.
>
> /
> Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmPlatformPkg ArmVirtPkg: reorganize PL011 code

[Leif Lindholm]

On Thu, Nov 16, 2017 at 05:12:16PM +, Ard Biesheuvel wrote:
> The PL011 code in ArmPlatformPkg is organized in a weird way: there is
> a single PL011Uart.h header file under Include/Drivers containing both
> register definitions and function entry points. The PL011Uart library
> itself is in Drivers/ but it is actually a library.
> 
> So let's clean this up: add a new PL011UartLib library class and associated
> header file containing only the library prototypes, and move the library
> itself under Library/ using a new GUID, with the register definitions moved
> into a local header file.
> 
> Note that we need to retain the old implementation for out of tree
> platforms,

s/need to//

Do we need to?
I mean, we could, and give a bit of a warning for people to switch
over. But does the change actually entail anything more than pointing
to the new .inf location? If not, we're just moving the point at
which platforms fail and have to modify their .dsc/.fdf.

That said, I'm not religiously opposed to a grace period - but I
don't want the old version hanging around to get included in the next
UDK release.

I _would_ prefer to see the ArmVirtPkg change as a separate patch.
Especially if the old copy is kept around.

Nice bit of cleanup though.

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

Re: [edk2] [PATCH] OvmfPkg/XenHypercallLib: enable virt extensions for ARM

[Ard Biesheuvel]

Forward to Julien at his @linaro.org address.



-- Forwarded message --
From: Ard Biesheuvel 
Date: 16 November 2017 at 16:56
Subject: [PATCH] OvmfPkg/XenHypercallLib: enable virt extensions for ARM
To: edk2-devel@lists.01.org, leif.lindh...@linaro.org,
ler...@redhat.com, julien.gr...@arm.com
Cc: Ard Biesheuvel 


XenHypercallLib uses the 'hvc' instruction, which is not implemented
on all ARMv7 CPUs, and so we need to explicitly specify a CPU that
has the virtualization extensions.

This override used to be set at the platform level, but this was removed
in commit 0d36a219c7bdbb27d775b50837823b2a9928147c
('ArmPlatformPkg/PL031RealTimeClockLib: drop ArmPlatformSysConfigLib
reference), under the assumption that all users of the 'hvc' instruction
had already been fixed.

So fix this for GNU binutils by adding the 'virt' arch extension
directive, and for RVCT by setting the --cpu command line option to a
CPU that is virt capable.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 OvmfPkg/Library/XenHypercallLib/Arm/Hypercall.S | 2 ++
 OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/OvmfPkg/Library/XenHypercallLib/Arm/Hypercall.S
b/OvmfPkg/Library/XenHypercallLib/Arm/Hypercall.S
index c12c8658b729..0adf65840a2f 100644
--- a/OvmfPkg/Library/XenHypercallLib/Arm/Hypercall.S
+++ b/OvmfPkg/Library/XenHypercallLib/Arm/Hypercall.S
@@ -16,6 +16,8 @@
 #include 

   .text
+  .arch_extension virt
+
 GCC_ASM_EXPORT(XenHypercall2)

 ASM_PFX(XenHypercall2):
diff --git a/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
b/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
index f4503a4b01f4..d268e540feca 100644
--- a/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+++ b/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
@@ -64,3 +64,6 @@ [LibraryClasses.IA32, LibraryClasses.X64]

 [Guids.IA32, Guids.X64]
   gEfiXenInfoGuid
+
+[BuildOptions.ARM]
+  RVCT:*_*_ARM_PLATFORM_FLAGS == --cpu Cortex-A15
--
2.11.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] ArmPlatformPkg ArmVirtPkg: reorganize PL011 code

[Ard Biesheuvel]

The PL011 code in ArmPlatformPkg is organized in a weird way: there is
a single PL011Uart.h header file under Include/Drivers containing both
register definitions and function entry points. The PL011Uart library
itself is in Drivers/ but it is actually a library.

So let's clean this up: add a new PL011UartLib library class and associated
header file containing only the library prototypes, and move the library
itself under Library/ using a new GUID, with the register definitions moved
into a local header file.

Note that we need to retain the old implementation for out of tree
platforms, but we can update ArmVirtPkg to switch to the new version
right away.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/ArmPlatformPkg.dec |   3 +
 ArmPlatformPkg/Include/Library/PL011UartLib.h | 187 

 ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c|   3 +-
 ArmPlatformPkg/Library/PL011UartLib/PL011Uart.h   | 120 
+
 ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.c| 474 

 ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf  |  43 ++
 ArmVirtPkg/ArmVirt.dsc.inc|   2 +-
 ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c |   5 +-
 ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.c  |   5 +-
 9 files changed, 833 insertions(+), 9 deletions(-)

diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec 
b/ArmPlatformPkg/ArmPlatformPkg.dec
index 8df7c8adf9f5..84291db6cfec 100644
--- a/ArmPlatformPkg/ArmPlatformPkg.dec
+++ b/ArmPlatformPkg/ArmPlatformPkg.dec
@@ -31,6 +31,9 @@ [Defines]
 [Includes.common]
   Include# Root include for the package
 
+[LibraryClasses]
+  PL011UartLib|Include/Library/PL011UartLib.h
+
 [Guids.common]
   gArmPlatformTokenSpaceGuid   = { 0x9c0aaed4, 0x74c5, 0x4043, { 0xb4, 0x17, 
0xa3, 0x22, 0x38, 0x14, 0xce, 0x76 } }
   #
diff --git a/ArmPlatformPkg/Include/Library/PL011UartLib.h 
b/ArmPlatformPkg/Include/Library/PL011UartLib.h
new file mode 100644
index ..9e923a2218d1
--- /dev/null
+++ b/ArmPlatformPkg/Include/Library/PL011UartLib.h
@@ -0,0 +1,187 @@
+/** @file
+*
+*  Copyright (c) 2011-2016, ARM Limited. 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.
+*
+**/
+
+#ifndef __PL011_UART_LIB_H__
+#define __PL011_UART_LIB_H__
+
+#include 
+
+/**
+
+  Initialise the serial port to the specified settings.
+  All unspecified settings will be set to the default values.
+
+  @param[in]  UartBaseThe base address of the serial device.
+  @param[in]  UartClkInHz The clock in Hz for the serial device.
+  Ignored if the PCD PL011UartInteger is not 0
+  @param[in out] BaudRate The baud rate of the serial device. If the
+  baud rate is not supported, the speed will be
+  reduced to the nearest supported one and the
+  variable's value will be updated accordingly.
+  @param[in out] ReceiveFifoDepth The number of characters the device will
+  buffer on input.  Value of 0 will use the
+  device's default FIFO depth.
+  @param[in out]  Parity  If applicable, this is the EFI_PARITY_TYPE
+  that is computed or checked as each character
+  is transmitted or received. If the device
+  does not support parity, the value is the
+  default parity value.
+  @param[in out]  DataBitsThe number of data bits in each character.
+  @param[in out]  StopBitsIf applicable, the EFI_STOP_BITS_TYPE number
+  of stop bits per character.
+  If the device does not support stop bits, the
+  value is the default stop bit value.
+
+  @retval RETURN_SUCCESSAll attributes were set correctly on the
+serial device.
+  @retval RETURN_INVALID_PARAMETER  One or more of the attributes has an
+unsupported value.
+
+**/
+RETURN_STATUS
+EFIAPI
+PL011UartInitializePort (
+  IN UINTN   UartBase,
+  IN UINT32  UartClkInHz,
+  

[edk2] [PATCH] OvmfPkg/XenHypercallLib: enable virt extensions for ARM

[Ard Biesheuvel]

XenHypercallLib uses the 'hvc' instruction, which is not implemented
on all ARMv7 CPUs, and so we need to explicitly specify a CPU that
has the virtualization extensions.

This override used to be set at the platform level, but this was removed
in commit 0d36a219c7bdbb27d775b50837823b2a9928147c
('ArmPlatformPkg/PL031RealTimeClockLib: drop ArmPlatformSysConfigLib
reference), under the assumption that all users of the 'hvc' instruction
had already been fixed.

So fix this for GNU binutils by adding the 'virt' arch extension
directive, and for RVCT by setting the --cpu command line option to a
CPU that is virt capable.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 OvmfPkg/Library/XenHypercallLib/Arm/Hypercall.S | 2 ++
 OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/OvmfPkg/Library/XenHypercallLib/Arm/Hypercall.S 
b/OvmfPkg/Library/XenHypercallLib/Arm/Hypercall.S
index c12c8658b729..0adf65840a2f 100644
--- a/OvmfPkg/Library/XenHypercallLib/Arm/Hypercall.S
+++ b/OvmfPkg/Library/XenHypercallLib/Arm/Hypercall.S
@@ -16,6 +16,8 @@
 #include 
 
   .text
+  .arch_extension virt
+
 GCC_ASM_EXPORT(XenHypercall2)
 
 ASM_PFX(XenHypercall2):
diff --git a/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf 
b/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
index f4503a4b01f4..d268e540feca 100644
--- a/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+++ b/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
@@ -64,3 +64,6 @@ [LibraryClasses.IA32, LibraryClasses.X64]
 
 [Guids.IA32, Guids.X64]
   gEfiXenInfoGuid
+
+[BuildOptions.ARM]
+  RVCT:*_*_ARM_PLATFORM_FLAGS == --cpu Cortex-A15
-- 
2.11.0

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

[edk2] [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

[Jian J Wang]

Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really
set attributes and change memory paging attribute accordingly.
But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
value from Capabilities in GCD memory map. This might cause
boot problems. Clearing all paging related capabilities can
workaround it. The code added in this patch is supposed to
be removed once the usage of EFI_MEMORY_DESCRIPTOR.Attribute
is clarified in UEFI spec and adopted by both EDK-II Core and
all supported OSs.

Cc: Jiewen Yao 
Cc: Star Zeng 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Core/Dxe/Mem/Page.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c b/MdeModulePkg/Core/Dxe/Mem/Page.c
index c9219cc068..783b576e35 100644
--- a/MdeModulePkg/Core/Dxe/Mem/Page.c
+++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
@@ -1829,6 +1829,23 @@ CoreGetMemoryMap (
   //
   BufferSize = ((UINT8 *)MemoryMap - (UINT8 *)MemoryMapStart);
 
+  //
+  // WORKAROUND: Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really
+  // set attributes and change memory paging attribute accordingly.
+  // But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
+  // value from Capabilities in GCD memory map. This might cause
+  // boot problems. Clearing all paging related capabilities can
+  // workaround it. Following code is supposed to be removed once
+  // the usage of EFI_MEMORY_DESCRIPTOR.Attribute is clarified in
+  // UEFI spec and adopted by both EDK-II Core and all supported
+  // OSs.
+  //
+  while (MemoryMapStart < MemoryMap) {
+MemoryMapStart->Attribute &= ~(UINT64)(EFI_MEMORY_RP | EFI_MEMORY_RO |
+   EFI_MEMORY_XP);
+MemoryMapStart = NEXT_MEMORY_DESCRIPTOR(MemoryMapStart, Size);
+  }
+
   Status = EFI_SUCCESS;
 
 Done:
-- 
2.14.1.windows.1

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

Re: [edk2] [PATCH v5] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

[Zeng, Star]

Seemingly, the Memory Attributes Table should be consumed for memory protection.

UEFI spec: "The Memory Attributes Table is currently used to describe memory 
protections that may be applied to the EFI Runtime code and data by an 
operating system or hypervisor."
Someone (Jiewen?) familiar with the table could help introduce the background.

And seemingly, the capabilities in UEFI memory map could not have paging 
related as it will break the compatibility to OS.


Thanks,
Star
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] 
Sent: Wednesday, November 15, 2017 11:59 PM
To: Laszlo Ersek 
Cc: Wang, Jian J ; Zeng, Star ; 
Matt Fleming ; edk2-devel@lists.01.org; Yao, Jiewen 
; Dong, Eric 
Subject: Re: [PATCH v5] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in 
memory map

On 15 November 2017 at 15:48, Laszlo Ersek  wrote:
> Hi Jian,
>
> On 11/15/17 10:27, Wang, Jian J wrote:
>> I tried this workaround and there're no failure in booting Fedora 26 
>> and Windows server 2016 now. If no objection, I'll merge it into new version 
>> of this patch.
>
> I'm not too familiar with the Linux kernel's EFI pieces myself; that's 
> why I added Ard and Matt earlier to the thread (when I responded with 
> the regression report) -- Ard and Matt maintain EFI in the Linux kernel.
>
> So, if you think there's a bug in Linux (i.e., a mis-interpretation of 
> the UEFI spec), can you guys please discuss that together? Below you wrote:
>
> - "I think it must be that the kernel will mark the memory block to be
>RO/XP/RP memory according to its capabilities but not its current
>attributes"
>

The UEFI spec does not distinguish between capabilities and attributes, so how 
on earth should the OS be able to make this distinction?

For instance, the UEFI spec defines EFI_MEMORY_RO as

"""
Physical memory protection attribute: The memory region supports making this 
memory range read-only by system hardware.
"""

which is essentially a capability not an attribute. However, EFI_MEMORY_RO/XP 
are also used to convey information about the nature of the *contents* of the 
memory region, i.e., is it .text, .rodata or .data/.bss

So given that the OS only has the UEFI memory map to go on, how exactly should 
it figure out what these attributes are meant to imply?

> - "there's real gap between UEFI and OS on how to interpret the memory
>capabilities"
>

Yes. There is also a gap between how GCD and the UEFI memory map interpret 
these attributes, which is why nobody bothers to set the protection 
capabilities for GCD: it gets copied into the UEFI memory map, and nobody has a 
clue how the OS should treat it.

When the [short lived]
EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA
feature was introduced, it was essentially decided that RO and XP may be used 
to annotate the nature of the contents of memory regions, where code was mapped 
RO and data mapped XP.

> Why is it wrong for the OS kernel, according to the UEFI spec, to 
> change the attributes / mappings of a memory area, as long as it stays 
> compliant with the advertised capabilities? How is an OS expected to 
> work, upon seeing those new "paging capabilities from UEFI memory map"
> (in Star's words)?
>
> Apparently, it's not just Linux that's confused; see the Win2016 crash 
> too. Is the UEFI spec detailed enough on those capabilities? (Recently 
> I tried to review the paging capabilities myself in the spec, and I 
> ended up totally confused...)
>

I think it is simply impossible at this point to interpret those flags as 
attributes, i.e., RO means code that may be mapped read-only, and XP means data 
that may be mapped non-executable. Anything beyond that opens a can of worms 
that is bound to break stuff all over the place.

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

[edk2] [PATCH 2/2] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

[Jian J Wang]

> v6:
>Add ExecuteDisable feature check to include/exclude EFI_MEMORY_XP

> v5:
>Coding style clean-up

> v4:
> a. Remove DoUpdate and check attributes mismatch all the time to avoid
>a logic hole
> b. Add warning message if failed to update capability
> c. Add local variable to hold new attributes to make code cleaner

> v3:
> a. Add comment to explain more on updating memory capabilities
> b. Fix logic hole in updating attributes
> c. Instead of checking illegal memory space address and size, use return
>status of gDS->SetMemorySpaceCapabilities() to skip memory block which
>cannot be updated with new capabilities.

> v2
> a. Fix an issue which will cause setting capability failure if size is smaller
>than a page.

More than one entry of RT_CODE memory might cause boot problem for some
old OSs. This patch will fix this issue to keep OS compatibility as much
as possible.

More detailed information, please refer to
https://bugzilla.tianocore.org/show_bug.cgi?id=753

Cc: Eric Dong 
Cc: Jiewen Yao 
Cc: Star Zeng 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 UefiCpuPkg/CpuDxe/CpuPageTable.c | 94 +++-
 1 file changed, 73 insertions(+), 21 deletions(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c b/UefiCpuPkg/CpuDxe/CpuPageTable.c
index d312eb66f8..3297c1900b 100644
--- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
+++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
@@ -769,6 +769,20 @@ AssignMemoryPageAttributes (
   return Status;
 }
 
+/**
+ Check if Execute Disable feature is enabled or not.
+**/
+BOOLEAN
+IsExecuteDisableEnabled (
+  VOID
+  )
+{
+  MSR_CORE_IA32_EFER_REGISTERMsrEfer;
+
+  MsrEfer.Uint64 = AsmReadMsr64 (MSR_IA32_EFER);
+  return (MsrEfer.Bits.NXE == 1);
+}
+
 /**
   Update GCD memory space attributes according to current page table setup.
 **/
@@ -790,7 +804,7 @@ RefreshGcdMemoryAttributesFromPaging (
   UINT64  PageStartAddress;
   UINT64  Attributes;
   UINT64  Capabilities;
-  BOOLEAN DoUpdate;
+  UINT64  NewAttributes;
   UINTN   Index;
 
   //
@@ -802,17 +816,50 @@ RefreshGcdMemoryAttributesFromPaging (
 
   GetCurrentPagingContext ();
 
-  DoUpdate  = FALSE;
-  Capabilities  = 0;
-  Attributes= 0;
-  BaseAddress   = 0;
-  PageLength= 0;
+  Attributes  = 0;
+  NewAttributes   = 0;
+  BaseAddress = 0;
+  PageLength  = 0;
+
+  if (IsExecuteDisableEnabled ()) {
+Capabilities = EFI_MEMORY_RO | EFI_MEMORY_RP | EFI_MEMORY_XP;
+  } else {
+Capabilities = EFI_MEMORY_RO | EFI_MEMORY_RP;
+  }
 
   for (Index = 0; Index < NumberOfDescriptors; Index++) {
 if (MemorySpaceMap[Index].GcdMemoryType == EfiGcdMemoryTypeNonExistent) {
   continue;
 }
 
+//
+// Sync the actual paging related capabilities back to GCD service first.
+// As a side effect (good one), this can also help to avoid unnecessary
+// memory map entries due to the different capabilities of the same type
+// memory, such as multiple RT_CODE and RT_DATA entries in memory map,
+// which could cause boot failure of some old Linux distro (before v4.3).
+//
+Status = gDS->SetMemorySpaceCapabilities (
+MemorySpaceMap[Index].BaseAddress,
+MemorySpaceMap[Index].Length,
+MemorySpaceMap[Index].Capabilities | Capabilities
+);
+if (EFI_ERROR (Status)) {
+  //
+  // If we cannot udpate the capabilities, we cannot update its
+  // attributes either. So just simply skip current block of memory.
+  //
+  DEBUG ((
+DEBUG_WARN,
+"Failed to update capability: [%lu] %016lx - %016lx (%016lx -> 
%016lx)\r\n",
+(UINT64)Index, MemorySpaceMap[Index].BaseAddress,
+MemorySpaceMap[Index].BaseAddress + MemorySpaceMap[Index].Length - 1,
+MemorySpaceMap[Index].Capabilities,
+MemorySpaceMap[Index].Capabilities | Capabilities
+));
+  continue;
+}
+
 if (MemorySpaceMap[Index].BaseAddress >= (BaseAddress + PageLength)) {
   //
   // Current memory space starts at a new page. Resetting PageLength will
@@ -826,7 +873,9 @@ RefreshGcdMemoryAttributesFromPaging (
   PageLength -= (MemorySpaceMap[Index].BaseAddress - BaseAddress);
 }
 
-// Sync real page attributes to GCD
+//
+// Sync actual page attributes to GCD
+//
 BaseAddress   = MemorySpaceMap[Index].BaseAddress;
 MemorySpaceLength = MemorySpaceMap[Index].Length;
 while (MemorySpaceLength > 0) {
@@ -842,23 +891,26 @@ RefreshGcdMemoryAttributesFromPaging (
 PageStartAddress  = (*PageEntry) & 

[edk2] [PATCH] MdeModulePkg XhciPei: Minor refinement about IoMmu

[Star Zeng]

1. Call IoMmuInit() after locating gPeiUsbControllerPpiGuid.
2. Call XhcPeiFreeSched() to do cleanup in XhcEndOfPei.

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Bus/Pci/XhciPei/XhcPeim.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/XhciPei/XhcPeim.c 
b/MdeModulePkg/Bus/Pci/XhciPei/XhcPeim.c
index 99f69f730b3f..c5631e87cacc 100644
--- a/MdeModulePkg/Bus/Pci/XhciPei/XhcPeim.c
+++ b/MdeModulePkg/Bus/Pci/XhciPei/XhcPeim.c
@@ -1427,6 +1427,8 @@ XhcEndOfPei (
 
   XhcPeiHaltHC (Xhc, XHC_GENERIC_TIMEOUT);
 
+  XhcPeiFreeSched (Xhc);
+
   return EFI_SUCCESS;
 }
 
@@ -1461,8 +1463,6 @@ XhcPeimEntry (
 return EFI_SUCCESS;
   }
 
-  IoMmuInit ();
-
   Status = PeiServicesLocatePpi (
  ,
  0,
@@ -1473,6 +1473,8 @@ XhcPeimEntry (
 return EFI_UNSUPPORTED;
   }
 
+  IoMmuInit ();
+
   Index = 0;
   while (TRUE) {
 Status = UsbControllerPpi->GetUsbController (
-- 
2.7.0.windows.1

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

[edk2] [PATCH v6 0/2] Fix multiple entries of RT_CODE in memory map

[Jian J Wang]

> v6
> a. Add workaround in core to filter out all paging related capabilities.
>This is to fix boot issue in Fedora 26 and Windows Server 2016.
> b. Add code to check if EFI_MEMORY_XP should be added for GCD memory map

More than one entry of RT_CODE memory might cause boot problem for some
old OSs. This patch will fix this issue to keep OS compatibility as much
as possible.

Jian J Wang (2):
  MdeModulePkg/DxeCore: Filter out all paging capabilities
  UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

 MdeModulePkg/Core/Dxe/Mem/Page.c | 17 
 UefiCpuPkg/CpuDxe/CpuPageTable.c | 94 +++-
 2 files changed, 90 insertions(+), 21 deletions(-)

-- 
2.14.1.windows.1

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

Re: [edk2] [PATCH] EmbeddedPkg: add mx66u1g45g nor flash info

[Ard Biesheuvel]

On 16 November 2017 at 16:24, Leif Lindholm  wrote:
> On Wed, Nov 15, 2017 at 11:19:32AM +, Ard Biesheuvel wrote:
>> From: Pipat Methavanitpong 
>>
>> Add Macronix MX66U1G45G definition to NorFlashInfoLib
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Pipat Methavanitpong 
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c 
>> b/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
>> index 750f37a0e8..fb26b4f9bc 100644
>> --- a/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
>> +++ b/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
>> @@ -57,6 +57,7 @@ STATIC CONST NOR_FLASH_INFO NorFlashIds[] = {
>>{L"mx25l51235f",{0xc2, 0x20, 0x1a}, 3, 256, 64 * 1024,  1024, 0},
>>{L"mx25l12855e",{0xc2, 0x26, 0x18}, 3, 256, 64 * 1024,   256, 0},
>>{L"mx66u51235f",{0xc2, 0x25, 0x3a}, 3, 256, 64 * 1024,  1024, 0},
>> +  {L"mx66u1g45g", {0xc2, 0x25, 0x3b}, 3, 256, 64 * 1024,  2048, 0},
>>{L"mx66l1g45g", {0xc2, 0x20, 0x1b}, 3, 256, 64 * 1024,  2048, 0},
>
> Hmm, I'm beginning to think we should have figured out a sorting
> strategy for this table ... oh well.
>
> The values match what QEMU uses, so:
> Reviewed-by: Leif Lindholm 
>

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

Re: [edk2] [PATCH] ArmVirtPkg: remove ArmPlatformSysConfigLib dependency

[Ard Biesheuvel]

On 16 November 2017 at 14:15, Ard Biesheuvel  wrote:
> On 16 November 2017 at 12:34, Ard Biesheuvel  
> wrote:
>>
>>
>>> On 16 Nov 2017, at 11:59, Leif Lindholm  wrote:
>>>
 On Thu, Nov 16, 2017 at 09:40:58AM +, Ard Biesheuvel wrote:
> On 15 November 2017 at 14:03, Ard Biesheuvel  
> wrote:
> Now that the PL031 RTC driver library no longer depends on the ARM
> platform specific ArmPlatformSysConfigLib, we no longer need to
> implement ArmPlatform.h or have a resolution for that library.
> This allows us to get rid of a rather dodgy practice of including
> platform headers using compiler flags, which is a bad idea at various
> levels.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
> PL031 patch is on-list and pending.
>
> ArmVirtPkg/ArmVirtQemu.dsc |  7 
> -
> ArmVirtPkg/ArmVirtQemuKernel.dsc   |  6 
> 
> ArmVirtPkg/ArmVirtXen.dsc  |  6 
> 
> ArmVirtPkg/Include/ArmPlatform.h   | 33 
> 
> ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/QemuVirtMem.c |  1 -
> ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/RelocatableVirt.c |  1 -
> ArmVirtPkg/Library/ArmVirtPlatformLib/Virt.c   |  1 -
> ArmVirtPkg/Library/ArmVirtPlatformLib/VirtMem.c|  1 -
> ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/RelocatableVirt.c  |  1 -
> ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/XenVirtMem.c   |  1 -
> ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c   |  7 
> -
> 11 files changed, 6 insertions(+), 59 deletions(-)
>
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index 8a60b61f2aa6..d1b3849d856a 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -49,7 +49,6 @@ [LibraryClasses.common]
>   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/BaseQemuFwCfgS3LibNull.inf
>
>   
> ArmPlatformLib|ArmVirtPkg/Library/ArmVirtPlatformLib/ArmVirtPlatformLib.inf
> -  
> ArmPlatformSysConfigLib|ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.inf
>
>   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
>   
> NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
> @@ -71,12 +70,6 @@ [LibraryClasses.common]
> [LibraryClasses.common.UEFI_DRIVER]
>   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
>
> -[BuildOptions]
> -  RVCT:*_*_ARM_PLATFORM_FLAGS == --cpu Cortex-A15 
> -I$(WORKSPACE)/ArmVirtPkg/Include
> -  GCC:*_*_ARM_PLATFORM_FLAGS == -mcpu=cortex-a15 
> -I$(WORKSPACE)/ArmVirtPkg/Include

 Oops. I will need to retain the -mcpu setting here, or the 'hvc'
 instruction will be rejected by the assembler.
>>>
>>> Don't we have source-level overrides for that?
>>> At least ".arch_extension virt" for GNU.
>>>
>>
>> Yeah, or at least move the cflags override to the .inf of the library that 
>> uses the hvc instruction
>
> As it turns out, ArmVirtQemu.dsc builds find without the -mcpu CFLAGS,
> due to the fact that we already have .arch_extension virt' in
> ArmPkg/Library/ArmHvcLib/Arm/ArmHvc.S, which is the only file that is
> affected by this AFAICT. I will double check how RVCT deals with this,
> but I will move the --cpu=Cortex-A15 flag into
> ArmPkg/Library/ArmHvcLib/ArmHvcLib.inf at the very least


Pushed as f311e5d8b5e1928eec602334194187d7811d905a (with the --cpu
issue fixed due to 302e8eda3b2f848e54bd21d0a8b2e5d8b891bffd 'ArmPkg:
move RVCT PLATFORM_FLAGS override into ArmHvcLib/ArmSmcLib')
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] EmbeddedPkg: add mx66u1g45g nor flash info

[Leif Lindholm]

On Wed, Nov 15, 2017 at 11:19:32AM +, Ard Biesheuvel wrote:
> From: Pipat Methavanitpong 
> 
> Add Macronix MX66U1G45G definition to NorFlashInfoLib
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Pipat Methavanitpong 
> Signed-off-by: Ard Biesheuvel 
> ---
>  EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c 
> b/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
> index 750f37a0e8..fb26b4f9bc 100644
> --- a/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
> +++ b/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
> @@ -57,6 +57,7 @@ STATIC CONST NOR_FLASH_INFO NorFlashIds[] = {
>{L"mx25l51235f",{0xc2, 0x20, 0x1a}, 3, 256, 64 * 1024,  1024, 0},
>{L"mx25l12855e",{0xc2, 0x26, 0x18}, 3, 256, 64 * 1024,   256, 0},
>{L"mx66u51235f",{0xc2, 0x25, 0x3a}, 3, 256, 64 * 1024,  1024, 0},
> +  {L"mx66u1g45g", {0xc2, 0x25, 0x3b}, 3, 256, 64 * 1024,  2048, 0},
>{L"mx66l1g45g", {0xc2, 0x20, 0x1b}, 3, 256, 64 * 1024,  2048, 0},

Hmm, I'm beginning to think we should have figured out a sorting
strategy for this table ... oh well.

The values match what QEMU uses, so:
Reviewed-by: Leif Lindholm 

>/* SPANSION */
>{L"s25fl008a",  {0x01, 0x02, 0x13}, 3, 256, 64 * 1024,16, 0},
> -- 
> 2.14.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmPlatformPkg/PL031RealTimeClockLib: drop ArmPlatformSysConfigLib reference

[Leif Lindholm]

On Wed, Nov 15, 2017 at 01:06:45PM +, Ard Biesheuvel wrote:
> The PL031 driver implements a VExpress/Juno specific hack to set the
> battery backed clock in addition to the PL031. However, none of the
> remaining VExpress based hardware we support in EDK2 actuall implements
> this feature so we can just remove it, and get rid of the cumbersome
> dependency on ArmPlatform.h.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

Yes, this is an improvement.

Can you also delete the ArmPlatformSysConfigLib dependency in .inf as
part of this patch? If you can, and fold that in:
Reviewed-by: Leif Lindholm 

/
Leif

> ---
>  ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c | 43 
> +++-
>  1 file changed, 6 insertions(+), 37 deletions(-)
> 
> diff --git 
> a/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c 
> b/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c
> index 459dcc0a0519..1334ad446cd9 100644
> --- a/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c
> +++ b/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c
> @@ -23,7 +23,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -38,8 +37,6 @@
>  
>  #include 
>  
> -#include 
> -
>  STATIC BOOLEANmPL031Initialized = FALSE;
>  STATIC EFI_EVENT  mRtcVirtualAddrChangeEvent;
>  STATIC UINTN  mPL031RtcBase;
> @@ -133,6 +130,11 @@ LibGetTime (
>EFI_STATUS  Status = EFI_SUCCESS;
>UINT32  EpochSeconds;
>  
> +  // Ensure Time is a valid pointer
> +  if (Time == NULL) {
> +return EFI_INVALID_PARAMETER;
> +  }
> +
>// Initialize the hardware if not already done
>if (!mPL031Initialized) {
>  Status = InitializePL031 ();
> @@ -141,27 +143,7 @@ LibGetTime (
>  }
>}
>  
> -  // Snapshot the time as early in the function call as possible
> -  // On some platforms we may have access to a battery backed up hardware 
> clock.
> -  // If such RTC exists try to use it first.
> -  Status = ArmPlatformSysConfigGet (SYS_CFG_RTC, );
> -  if (Status == EFI_UNSUPPORTED) {
> -// Battery backed up hardware RTC does not exist, revert to PL031
> -EpochSeconds = MmioRead32 (mPL031RtcBase + PL031_RTC_DR_DATA_REGISTER);
> -Status = EFI_SUCCESS;
> -  } else if (EFI_ERROR (Status)) {
> -// Battery backed up hardware RTC exists but could not be read due to 
> error. Abort.
> -return Status;
> -  } else {
> -// Battery backed up hardware RTC exists and we read the time correctly 
> from it.
> -// Now sync the PL031 to the new time.
> -MmioWrite32 (mPL031RtcBase + PL031_RTC_LR_LOAD_REGISTER, EpochSeconds);
> -  }
> -
> -  // Ensure Time is a valid pointer
> -  if (Time == NULL) {
> -return EFI_INVALID_PARAMETER;
> -  }
> +  EpochSeconds = MmioRead32 (mPL031RtcBase + PL031_RTC_DR_DATA_REGISTER);
>  
>// Adjust for the correct time zone
>// The timezone setting also reflects the DST setting of the clock
> @@ -235,19 +217,6 @@ LibSetTime (
>  EpochSeconds -= SEC_PER_HOUR;
>}
>  
> -  // On some platforms we may have access to a battery backed up hardware 
> clock.
> -  //
> -  // If such RTC exists then it must be updated first, before the PL031,
> -  // to minimise any time drift. This is important because the battery 
> backed-up
> -  // RTC maintains the master time for the platform across reboots.
> -  //
> -  // If such RTC does not exist then the following function returns 
> UNSUPPORTED.
> -  Status = ArmPlatformSysConfigSet (SYS_CFG_RTC, EpochSeconds);
> -  if ((EFI_ERROR (Status)) && (Status != EFI_UNSUPPORTED)){
> -// Any status message except SUCCESS and UNSUPPORTED indicates a 
> hardware failure.
> -return Status;
> -  }
> -
>// Set the PL031
>MmioWrite32 (mPL031RtcBase + PL031_RTC_LR_LOAD_REGISTER, EpochSeconds);
>  
> -- 
> 2.11.0
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] GRUB issue on device priority

[Leif Lindholm]

Apologies for delay in responding.

On Thu, Nov 09, 2017 at 04:41:55PM +0800, Haojian Zhuang wrote:
> > > In the HiKey platform, I prepared the same driver for both eMMC and
> > > SD. So the device paths are in below.
> > > SD: /HardwareVendor(0d51905b-b77e-452a-a2c0-eca0cc8d514a)[9: 00 e0 23 f7 
> > > 00 00 00 00 00 ]/UnknownMessaging(1a)/EndEntire
> > > eMMC: /HardwareVendor(0d51905b-b77e-452a-a2c0-eca0cc8d514a)[9: 00 d0 23 
> > > f7 00 00 00 00 00]/UnknownMessaging(1d)/Ctrl(0)/EndEntire
> > > 
> > > #define MSG_SD_DP   0x1A
> > > #define MSG_EMMC_DP 0x1D
> > > 
> > > In the second level, the device paths are different.
> > > 
> > > And GRUB resort the sequence by ascending order (with above
> > > code). So SD device always gets higher priority than eMMC device.
> > > 
> > > If we always use installer to install OS, it may not an issue. Since
> > > installer could create grub.cfg by itself. But it imports another
> > > issue on lacking of persistent variable storage. And we need to
> > > deploy system without installer on embedded device.
> > 
> > Yes, this is the bit which is interesting, and why I requested you
> > post this problem to edk2-devel.
> > 
> > I believe that we need to have a sensible way to deal with embedded
> > platforms that do not have operating systems "installed" to them, but
> > rather written as images to flash devices.
> > 
> > So, can you clarify a few things for me?:
> > - Where is GRUB located in your (pre-SD) system?
> 
> In eMMC.
>
> > - Where is GRUB located in your SD system?
>
> In SD.
>
> > - Are you looking for a way to support GRUB being located on either
> >eMMC or SD? Or are you looking to always have GRUB loaded from eMMC?
> 
> GRUB could be located in either in eMMC or SD.

OK, so which one should be loaded in preference if both exist?

I.e., what if you write a GRUB to eMMC via USB uplink, and at some
later point you insert an uSD card?

One (hackish, but at least predictable) way of resolving this would be
to implement a PlatformBootManagerLib that never connects more than
one of those devices. Alternatively one that always disconnects the
one not used for booting.

(Yes, I always argue that we should try to use a single library across
most/all ARM platforms, but in order to figure out the useful
abstractions that would make this possible, it would be worth to have
some different versions implementing different features.)

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

Re: [edk2] [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

[Ard Biesheuvel]

On 16 November 2017 at 09:48, Zeng, Star  wrote:
> As I remember UEFI 2.5 clarified this and added EFI_MEMORY_RO was because 
> EFI_MEMORY_WP had been typically used for cache even before UEFI 2.5.
>
> And I do not think this patch should filter out EFI_MEMORY_WP since this 
> patch is to filter out new paging bits caused by 
> 14dde9e903bb9a719ebb8f3381da72b19509bc36 [MdeModulePkg/Core: Fix out-of-sync 
> issue in GCD].
>

Ah ok. If the bit does not get copied from the GCD map then there is
no need to filter it here.

>
> Thanks,
> Star
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, November 16, 2017 5:30 PM
> To: Zeng, Star 
> Cc: Wang, Jian J ; Laszlo Ersek ; 
> edk2-devel@lists.01.org; Yao, Jiewen 
> Subject: Re: [edk2] [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all 
> paging capabilities
>
> On 16 November 2017 at 09:28, Zeng, Star  wrote:
>> Ard,
>>
>> EFI_MEMORY_WP is for cache.
>>
>> UefiSpec.h
>> //
>> // Note: UEFI spec 2.5 and following: use EFI_MEMORY_RO as
>> write-protected physical memory // protection attribute. Also, EFI_MEMORY_WP 
>> means cacheability attribute.
>> //
>> #define EFI_MEMORY_WP   0x1000ULL
>>
>
> Yes, but that was a change in v2.5, before that it was a permission 
> attribute. So it should be filtered from the OS visible memory map as well.
>
>> Thanks,
>> Star
>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Thursday, November 16, 2017 5:25 PM
>> To: Wang, Jian J 
>> Cc: edk2-devel@lists.01.org; Yao, Jiewen ; Zeng,
>> Star ; Laszlo Ersek 
>> Subject: Re: [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all
>> paging capabilities
>>
>> On 16 November 2017 at 07:26, Jian J Wang  wrote:
>>> Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really set
>>> attributes and change memory paging attribute accordingly.
>>> But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by value from
>>> Capabilities in GCD memory map. This might cause boot problems.
>>> Clearing all paging related capabilities can workaround it. The code
>>> added in this patch is supposed to be removed once the usage of
>>> EFI_MEMORY_DESCRIPTOR.Attribute is clarified in UEFI spec and adopted
>>> by both EDK-II Core and all supported OSs.
>>>
>>> Cc: Jiewen Yao 
>>> Cc: Star Zeng 
>>> Cc: Laszlo Ersek 
>>> Cc: Ard Biesheuvel 
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Jian J Wang 
>>> ---
>>>  MdeModulePkg/Core/Dxe/Mem/Page.c | 17 +
>>>  1 file changed, 17 insertions(+)
>>>
>>> diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c
>>> b/MdeModulePkg/Core/Dxe/Mem/Page.c
>>> index c9219cc068..783b576e35 100644
>>> --- a/MdeModulePkg/Core/Dxe/Mem/Page.c
>>> +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
>>> @@ -1829,6 +1829,23 @@ CoreGetMemoryMap (
>>>//
>>>BufferSize = ((UINT8 *)MemoryMap - (UINT8 *)MemoryMapStart);
>>>
>>> +  //
>>> +  // WORKAROUND: Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as 
>>> really
>>> +  // set attributes and change memory paging attribute 
>>> accordingly.
>>> +  // But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
>>> +  // value from Capabilities in GCD memory map. This might 
>>> cause
>>> +  // boot problems. Clearing all paging related capabilities 
>>> can
>>> +  // workaround it. Following code is supposed to be removed 
>>> once
>>> +  // the usage of EFI_MEMORY_DESCRIPTOR.Attribute is clarified 
>>> in
>>> +  // UEFI spec and adopted by both EDK-II Core and all 
>>> supported
>>> +  // OSs.
>>> +  //
>>> +  while (MemoryMapStart < MemoryMap) {
>>> +MemoryMapStart->Attribute &= ~(UINT64)(EFI_MEMORY_RP | EFI_MEMORY_RO |
>>> +   EFI_MEMORY_XP);
>>
>> Why is EFI_MEMORY_WP missing here?
>>
>>> +MemoryMapStart = NEXT_MEMORY_DESCRIPTOR(MemoryMapStart, Size);
>>> + }
>>> +
>>>Status = EFI_SUCCESS;
>>>
>>>  Done:
>>> --
>>> 2.14.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 1/1] BaseTools: Use VS2017 SDK path if defined and reorganize variables

[Pete Batard]

On 2017.11.16 14:48, Gao, Liming wrote:

I agree to separate HOST and ARCH. For this patch, I have minor comment on 
WINSDK10_BIN.

DEFINE WINSDK10_BIN   = ENV(WINSDK10_PREFIX)x86
==>
DEFINE WINSDK10_BIN   = ENV(WINSDK10_PREFIX)DEF(VS2017_HOST)


Good point. I agree that the SDK should use the VS2017_HOST definition too.

If that's okay with you, I'm going to wait 24 hours to give a chance for 
people to comment, and then resubmit a v2 of your VS2017 patch series, 
that includes my proposed modifications as well as the change above.


Regards,

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

Re: [edk2] [PATCH] BaseTools/tools_def AARCH64 ARM: disable PIE linking for .aslc sources

[Ard Biesheuvel]

On 16 November 2017 at 15:31, Gao, Liming  wrote:
> Ard:
>   Does this error only happen on ACPI table compiling? But, I see -no-pie is 
> also in normal DLINK flag. Why is the driver not compiled failed?
>

The main difference is that the ACPI tables don't tolerate any padding
at the start of the binary image. This is different for ELF binaries
that are converted to PE/COFF, given that the entry point is exposed
in the header, so the padding is just ignored. However, we should
still try to omit those sections if we can.



>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Thursday, November 16, 2017 11:09 PM
>> To: Marcin Wojtas 
>> Cc: Gao, Liming ; edk2-devel@lists.01.org; 
>> daniel.thomp...@linaro.org; leif.lindh...@linaro.org
>> Subject: Re: [edk2] [PATCH] BaseTools/tools_def AARCH64 ARM: disable PIE 
>> linking for .aslc sources
>>
>> On 16 November 2017 at 15:07, Marcin Wojtas  wrote:
>> > Hi Ard,
>> >
>> > 2017-11-16 15:48 GMT+01:00 Ard Biesheuvel :
>> >> On 16 November 2017 at 14:38, Marcin Wojtas  wrote:
>> >>> Hi Ard,
>> >>>
>> >>> With both PIE disabling patches for AARCH64, when compiling ACPI tables 
>> >>> with
>> >>> gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-
>> >>> I get following errors:
>> >>> [...]
>> >>> aarch64-linux-gnu-gcc: error: unrecognized command line option '-no-pie'
>> >>> Do I understand correctly, that I should either revert those patches
>> >>> or upgrade to the newer toolchain?
>> >>>
>> >>
>> >> Ugh.
>> >>
>> >> I thought GCC 5 and later implemented -no-pie, but apparently not.
>> >>
>> >> Does this fix your build? I will need to check whether it fixes the
>> >> original issue, but hopefully your toolchain doesn't choke on this:
>> >>
>> >> diff --git a/BaseTools/Conf/tools_def.template
>> >> b/BaseTools/Conf/tools_def.template
>> >> index aebd7d558633..111fe8da7773 100755
>> >> --- a/BaseTools/Conf/tools_def.template
>> >> +++ b/BaseTools/Conf/tools_def.template
>> >> @@ -4496,10 +4496,10 @@ DEFINE GCC5_AARCH64_CC_FLAGS =
>> >> DEF(GCC49_AARCH64_CC_FLAGS)
>> >>  DEFINE GCC5_AARCH64_CC_XIPFLAGS  = DEF(GCC49_AARCH64_CC_XIPFLAGS)
>> >>  DEFINE GCC5_ARM_DLINK_FLAGS  = DEF(GCC49_ARM_DLINK_FLAGS) -no-pie
>> >>  DEFINE GCC5_ARM_DLINK2_FLAGS = DEF(GCC49_ARM_DLINK2_FLAGS) 
>> >> -Wno-error
>> >> -DEFINE GCC5_AARCH64_DLINK_FLAGS  = DEF(GCC49_AARCH64_DLINK_FLAGS) 
>> >> -no-pie
>> >> +DEFINE GCC5_AARCH64_DLINK_FLAGS  = DEF(GCC49_AARCH64_DLINK_FLAGS)
>> >> -Wl,-no-pie
>> >>  DEFINE GCC5_AARCH64_DLINK2_FLAGS =
>> >> DEF(GCC49_AARCH64_DLINK2_FLAGS) -Wno-error
>> >>  DEFINE GCC5_ARM_ASLDLINK_FLAGS   = DEF(GCC49_ARM_ASLDLINK_FLAGS) 
>> >> -no-pie
>> >> -DEFINE GCC5_AARCH64_ASLDLINK_FLAGS   =
>> >> DEF(GCC49_AARCH64_ASLDLINK_FLAGS) -no-pie
>> >> +DEFINE GCC5_AARCH64_ASLDLINK_FLAGS   =
>> >> DEF(GCC49_AARCH64_ASLDLINK_FLAGS) -Wl,-no-pie
>> >>
>> >>  
>> >> 
>> >>  #
>> >>
>> >
>> > Unfortunately no change, still:
>> > aarch64-linux-gnu-gcc: error: unrecognized command line option '-no-pie'
>> > In order to make sure, I double checked twice cleaninig everything and
>> > rebuilding from scratch.
>> >
>>
>> Thanks, but it doesn't matter anyway: it doesn't fix the original
>> issues on affected toolchains.
>>
>> It appears the only way we can deal with this is introducing GCC6 and
>> move the workaround there.
>>
>> Thanks,
>> Ard.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmPkg: move RVCT PLATFORM_FLAGS override into ArmHvcLib/ArmSmcLib

[Leif Lindholm]

On Thu, Nov 16, 2017 at 02:35:46PM +, Ard Biesheuvel wrote:
> Currently, each ARM platform built with RVCT that uses ArmHvcLib
> or ArmSmcLib needs to specify a CPU target that implements both the
> security and virtualization extensions, so that the assembler does
> not choke on the 'hvc' and 'smc' instructions in ArmHvcLib/ArmSvcLib.
> Let's move these overrides into the module .INFs so we can lift this
> requirement at the platform side.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/ArmPkg.dsc  | 2 --
>  ArmPkg/Library/ArmHvcLib/ArmHvcLib.inf | 3 +++
>  ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf | 3 +++
>  3 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
> index 382e99868453..622720ab2aef 100644
> --- a/ArmPkg/ArmPkg.dsc
> +++ b/ArmPkg/ArmPkg.dsc
> @@ -33,8 +33,6 @@ [Defines]
>  [BuildOptions]
>XCODE:*_*_ARM_PLATFORM_FLAGS  == -arch armv7
>GCC:*_*_ARM_PLATFORM_FLAGS== -march=armv7-a -mfpu=neon
> -  # We use A15 to get the Secure and Virtualization extensions
> -  RVCT:*_*_ARM_PLATFORM_FLAGS  == --cpu Cortex-A15
>  
>RELEASE_*_*_CC_FLAGS  = -DMDEPKG_NDEBUG
>*_*_*_CC_FLAGS  = -DDISABLE_NEW_DEPRECATED_INTERFACES
> diff --git a/ArmPkg/Library/ArmHvcLib/ArmHvcLib.inf 
> b/ArmPkg/Library/ArmHvcLib/ArmHvcLib.inf
> index 92efac5741c8..d046ef3ba253 100644
> --- a/ArmPkg/Library/ArmHvcLib/ArmHvcLib.inf
> +++ b/ArmPkg/Library/ArmHvcLib/ArmHvcLib.inf
> @@ -30,3 +30,6 @@ [Sources.AARCH64]
>  [Packages]
>MdePkg/MdePkg.dec
>ArmPkg/ArmPkg.dec
> +
> +[BuildOptions]
> +  RVCT:*_*_ARM_PLATFORM_FLAGS == --cpu Cortex-A15
> diff --git a/ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf 
> b/ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf
> index 9f9ba729967c..0aa64d467129 100644
> --- a/ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf
> +++ b/ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf
> @@ -29,3 +29,6 @@ [Sources.AARCH64]
>  [Packages]
>MdePkg/MdePkg.dec
>ArmPkg/ArmPkg.dec
> +
> +[BuildOptions]
> +  RVCT:*_*_ARM_PLATFORM_FLAGS == --cpu Cortex-A15

For this one, you should be able to get away with --cpu 7-A.security
rather than listing a random CPU that happens to implement the
required extension.

This on the surface minor cleanup makes me unreasonably happy - thanks.
So if you can fold that in:
Reviewed-by: Leif Lindholm 

For whatever reason, a --cpu 7-A.virtualization never seems to have
been implemented...

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

Re: [edk2] [RFC v2 1/3] UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support

[Brian J. Johnson]

On 11/15/2017 07:18 PM, Paulo Alcantara wrote:

This patch adds stack trace support during a X64 CPU exception.

It will dump out back trace, stack contents as well as image module
names that were part of the call stack.

Contributed-under: TianoCore Contribution Agreement 1.1
Cc: Eric Dong 
Cc: Laszlo Ersek 
Signed-off-by: Paulo Alcantara 


(These comments apply to patch 3/3 as well.)

Typo:  UnwondStacksCount should be UnwoundStacksCount

It's good to check the alignment of the stack, as you're doing.  But 
I'll reiterate that you absolutely need some better sanity checking of 
the stack and IP addresses before you dereference them.  Remember that 
they could be absolutely *anything* at the entry to this code. 
Something caused an error, and it may have been one of those registers.


Also, if the code was built with a compiler which isn't using RBP as a 
base pointer, RBP is unlikely to contain a stack address.  That will 
cause issues if you use it for unwinding without a sanity check.


Thanks,
Brian


---
  UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c | 369 
+++-
  1 file changed, 367 insertions(+), 2 deletions(-)

diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
index 65f0cff680..11cd7c9e1c 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
@@ -14,6 +14,11 @@
  
  #include "CpuExceptionCommon.h"
  
+//

+// Unknown PDB file name
+//
+GLOBAL_REMOVE_IF_UNREFERENCED CONST CHAR8 *mUnknownPdbFileName = "";
+
  /**
Return address map of exception handler template so that C code can generate
exception tables.
@@ -242,6 +247,350 @@ DumpCpuContext (
  );
  }
  
+/**

+  Get absolute path and file name of PDB file in PE/COFF image.
+
+  @param[in]  ImageBaseBase address of PE/COFF image.
+  @param[out] PdbAbsoluteFilePath  Absolute path of PDB file.
+  @param[out] PdbFileName  File name of PDB file.
+**/
+STATIC
+VOID
+GetPdbFileName (
+  IN  UINTNImageBase,
+  OUT CHAR8**PdbAbsoluteFilePath,
+  OUT CHAR8**PdbFileName
+  )
+{
+  VOID   *PdbPointer;
+  CHAR8  *Str;
+
+  //
+  // Get PDB file name from PE/COFF image
+  //
+  PdbPointer = PeCoffLoaderGetPdbPointer ((VOID *)ImageBase);
+  if (PdbPointer == NULL) {
+//
+// No PDB file name found. Set it to an unknown file name.
+//
+*PdbFileName = (CHAR8 *)mUnknownPdbFileName;
+if (PdbAbsoluteFilePath != NULL) {
+  *PdbAbsoluteFilePath = NULL;
+}
+  } else {
+//
+// Get file name portion out of PDB file in PE/COFF image
+//
+Str = (CHAR8 *)((UINTN)PdbPointer +
+AsciiStrLen ((CHAR8 *)PdbPointer) - sizeof *Str);
+for (; *Str != '/' && *Str != '\\'; Str--) {
+  ;
+}
+
+//
+// Set PDB file name (also skip trailing path separator: '/' or '\\')
+//
+*PdbFileName = Str + 1;
+
+if (PdbAbsoluteFilePath != NULL) {
+  //
+  // Set absolute file path of PDB file
+  //
+  *PdbAbsoluteFilePath = PdbPointer;
+}
+  }
+}
+
+/**
+  Dump stack contents.
+
+  @param[in]  CurrentRsp Current stack pointer address.
+  @param[in]  UnwondStacksCount  Count of unwond stack frames.
+**/
+STATIC
+VOID
+DumpStackContents (
+  IN UINT64  CurrentRsp,
+  IN INTNUnwondStacksCount
+  )
+{
+  //
+  // Check for proper stack pointer alignment
+  //
+  if (((UINTN)CurrentRsp & (CPU_STACK_ALIGNMENT - 1)) != 0) {
+InternalPrintMessage (" Unaligned stack pointer. \n");
+return;
+  }
+
+  //
+  // Dump out stack contents
+  //
+  InternalPrintMessage ("\nStack dump:\n");
+  while (UnwondStacksCount-- > 0) {
+InternalPrintMessage (
+  "0x%016lx: %016lx %016lx\n",
+  CurrentRsp,
+  *(UINT64 *)CurrentRsp,
+  *(UINT64 *)((UINTN)CurrentRsp + 8)
+  );
+
+//
+// Point to next stack
+//
+CurrentRsp += CPU_STACK_ALIGNMENT;
+  }
+}
+
+/**
+  Dump all image module names from call stack.
+
+  @param[in]  SystemContext  Pointer to EFI_SYSTEM_CONTEXT.
+**/
+STATIC
+VOID
+DumpImageModuleNames (
+  IN EFI_SYSTEM_CONTEXT   SystemContext
+  )
+{
+  EFI_STATUS  Status;
+  UINT64  Rip;
+  UINTN   ImageBase;
+  VOID*EntryPoint;
+  CHAR8   *PdbAbsoluteFilePath;
+  CHAR8   *PdbFileName;
+  UINT64  Rbp;
+
+  //
+  // Set current RIP address
+  //
+  Rip = SystemContext.SystemContextX64->Rip;
+
+  //
+  // Set current frame pointer address
+  //
+  Rbp = SystemContext.SystemContextX64->Rbp;
+
+  //
+  // Check for proper frame pointer alignment
+  //
+  if (((UINTN)Rbp & (CPU_STACK_ALIGNMENT - 1)) != 0) {
+InternalPrintMessage (" Unaligned frame pointer. \n");
+return;
+  }
+
+  //
+  // Get initial PE/COFF image base address from current RIP
+  //
+  

Re: [edk2] [PATCH] BaseTools/tools_def AARCH64 ARM: disable PIE linking for .aslc sources

[Gao, Liming]

Ard:
  Does this error only happen on ACPI table compiling? But, I see -no-pie is 
also in normal DLINK flag. Why is the driver not compiled failed?

Thanks
Liming
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, November 16, 2017 11:09 PM
> To: Marcin Wojtas 
> Cc: Gao, Liming ; edk2-devel@lists.01.org; 
> daniel.thomp...@linaro.org; leif.lindh...@linaro.org
> Subject: Re: [edk2] [PATCH] BaseTools/tools_def AARCH64 ARM: disable PIE 
> linking for .aslc sources
> 
> On 16 November 2017 at 15:07, Marcin Wojtas  wrote:
> > Hi Ard,
> >
> > 2017-11-16 15:48 GMT+01:00 Ard Biesheuvel :
> >> On 16 November 2017 at 14:38, Marcin Wojtas  wrote:
> >>> Hi Ard,
> >>>
> >>> With both PIE disabling patches for AARCH64, when compiling ACPI tables 
> >>> with
> >>> gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-
> >>> I get following errors:
> >>> [...]
> >>> aarch64-linux-gnu-gcc: error: unrecognized command line option '-no-pie'
> >>> Do I understand correctly, that I should either revert those patches
> >>> or upgrade to the newer toolchain?
> >>>
> >>
> >> Ugh.
> >>
> >> I thought GCC 5 and later implemented -no-pie, but apparently not.
> >>
> >> Does this fix your build? I will need to check whether it fixes the
> >> original issue, but hopefully your toolchain doesn't choke on this:
> >>
> >> diff --git a/BaseTools/Conf/tools_def.template
> >> b/BaseTools/Conf/tools_def.template
> >> index aebd7d558633..111fe8da7773 100755
> >> --- a/BaseTools/Conf/tools_def.template
> >> +++ b/BaseTools/Conf/tools_def.template
> >> @@ -4496,10 +4496,10 @@ DEFINE GCC5_AARCH64_CC_FLAGS =
> >> DEF(GCC49_AARCH64_CC_FLAGS)
> >>  DEFINE GCC5_AARCH64_CC_XIPFLAGS  = DEF(GCC49_AARCH64_CC_XIPFLAGS)
> >>  DEFINE GCC5_ARM_DLINK_FLAGS  = DEF(GCC49_ARM_DLINK_FLAGS) -no-pie
> >>  DEFINE GCC5_ARM_DLINK2_FLAGS = DEF(GCC49_ARM_DLINK2_FLAGS) 
> >> -Wno-error
> >> -DEFINE GCC5_AARCH64_DLINK_FLAGS  = DEF(GCC49_AARCH64_DLINK_FLAGS) 
> >> -no-pie
> >> +DEFINE GCC5_AARCH64_DLINK_FLAGS  = DEF(GCC49_AARCH64_DLINK_FLAGS)
> >> -Wl,-no-pie
> >>  DEFINE GCC5_AARCH64_DLINK2_FLAGS =
> >> DEF(GCC49_AARCH64_DLINK2_FLAGS) -Wno-error
> >>  DEFINE GCC5_ARM_ASLDLINK_FLAGS   = DEF(GCC49_ARM_ASLDLINK_FLAGS) 
> >> -no-pie
> >> -DEFINE GCC5_AARCH64_ASLDLINK_FLAGS   =
> >> DEF(GCC49_AARCH64_ASLDLINK_FLAGS) -no-pie
> >> +DEFINE GCC5_AARCH64_ASLDLINK_FLAGS   =
> >> DEF(GCC49_AARCH64_ASLDLINK_FLAGS) -Wl,-no-pie
> >>
> >>  
> >> 
> >>  #
> >>
> >
> > Unfortunately no change, still:
> > aarch64-linux-gnu-gcc: error: unrecognized command line option '-no-pie'
> > In order to make sure, I double checked twice cleaninig everything and
> > rebuilding from scratch.
> >
> 
> Thanks, but it doesn't matter anyway: it doesn't fix the original
> issues on affected toolchains.
> 
> It appears the only way we can deal with this is introducing GCC6 and
> move the workaround there.
> 
> Thanks,
> Ard.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] BaseTools/tools_def AARCH64 ARM: disable PIE linking for .aslc sources

[Ard Biesheuvel]

On 16 November 2017 at 15:07, Marcin Wojtas  wrote:
> Hi Ard,
>
> 2017-11-16 15:48 GMT+01:00 Ard Biesheuvel :
>> On 16 November 2017 at 14:38, Marcin Wojtas  wrote:
>>> Hi Ard,
>>>
>>> With both PIE disabling patches for AARCH64, when compiling ACPI tables with
>>> gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-
>>> I get following errors:
>>> [...]
>>> aarch64-linux-gnu-gcc: error: unrecognized command line option '-no-pie'
>>> Do I understand correctly, that I should either revert those patches
>>> or upgrade to the newer toolchain?
>>>
>>
>> Ugh.
>>
>> I thought GCC 5 and later implemented -no-pie, but apparently not.
>>
>> Does this fix your build? I will need to check whether it fixes the
>> original issue, but hopefully your toolchain doesn't choke on this:
>>
>> diff --git a/BaseTools/Conf/tools_def.template
>> b/BaseTools/Conf/tools_def.template
>> index aebd7d558633..111fe8da7773 100755
>> --- a/BaseTools/Conf/tools_def.template
>> +++ b/BaseTools/Conf/tools_def.template
>> @@ -4496,10 +4496,10 @@ DEFINE GCC5_AARCH64_CC_FLAGS =
>> DEF(GCC49_AARCH64_CC_FLAGS)
>>  DEFINE GCC5_AARCH64_CC_XIPFLAGS  = DEF(GCC49_AARCH64_CC_XIPFLAGS)
>>  DEFINE GCC5_ARM_DLINK_FLAGS  = DEF(GCC49_ARM_DLINK_FLAGS) -no-pie
>>  DEFINE GCC5_ARM_DLINK2_FLAGS = DEF(GCC49_ARM_DLINK2_FLAGS) 
>> -Wno-error
>> -DEFINE GCC5_AARCH64_DLINK_FLAGS  = DEF(GCC49_AARCH64_DLINK_FLAGS) 
>> -no-pie
>> +DEFINE GCC5_AARCH64_DLINK_FLAGS  = DEF(GCC49_AARCH64_DLINK_FLAGS)
>> -Wl,-no-pie
>>  DEFINE GCC5_AARCH64_DLINK2_FLAGS =
>> DEF(GCC49_AARCH64_DLINK2_FLAGS) -Wno-error
>>  DEFINE GCC5_ARM_ASLDLINK_FLAGS   = DEF(GCC49_ARM_ASLDLINK_FLAGS) -no-pie
>> -DEFINE GCC5_AARCH64_ASLDLINK_FLAGS   =
>> DEF(GCC49_AARCH64_ASLDLINK_FLAGS) -no-pie
>> +DEFINE GCC5_AARCH64_ASLDLINK_FLAGS   =
>> DEF(GCC49_AARCH64_ASLDLINK_FLAGS) -Wl,-no-pie
>>
>>  
>> 
>>  #
>>
>
> Unfortunately no change, still:
> aarch64-linux-gnu-gcc: error: unrecognized command line option '-no-pie'
> In order to make sure, I double checked twice cleaninig everything and
> rebuilding from scratch.
>

Thanks, but it doesn't matter anyway: it doesn't fix the original
issues on affected toolchains.

It appears the only way we can deal with this is introducing GCC6 and
move the workaround there.

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

Re: [edk2] [PATCH] BaseTools/tools_def AARCH64 ARM: disable PIE linking for .aslc sources

[Marcin Wojtas]

Hi Ard,

2017-11-16 15:48 GMT+01:00 Ard Biesheuvel :
> On 16 November 2017 at 14:38, Marcin Wojtas  wrote:
>> Hi Ard,
>>
>> With both PIE disabling patches for AARCH64, when compiling ACPI tables with
>> gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-
>> I get following errors:
>> [...]
>> aarch64-linux-gnu-gcc: error: unrecognized command line option '-no-pie'
>> Do I understand correctly, that I should either revert those patches
>> or upgrade to the newer toolchain?
>>
>
> Ugh.
>
> I thought GCC 5 and later implemented -no-pie, but apparently not.
>
> Does this fix your build? I will need to check whether it fixes the
> original issue, but hopefully your toolchain doesn't choke on this:
>
> diff --git a/BaseTools/Conf/tools_def.template
> b/BaseTools/Conf/tools_def.template
> index aebd7d558633..111fe8da7773 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -4496,10 +4496,10 @@ DEFINE GCC5_AARCH64_CC_FLAGS =
> DEF(GCC49_AARCH64_CC_FLAGS)
>  DEFINE GCC5_AARCH64_CC_XIPFLAGS  = DEF(GCC49_AARCH64_CC_XIPFLAGS)
>  DEFINE GCC5_ARM_DLINK_FLAGS  = DEF(GCC49_ARM_DLINK_FLAGS) -no-pie
>  DEFINE GCC5_ARM_DLINK2_FLAGS = DEF(GCC49_ARM_DLINK2_FLAGS) -Wno-error
> -DEFINE GCC5_AARCH64_DLINK_FLAGS  = DEF(GCC49_AARCH64_DLINK_FLAGS) -no-pie
> +DEFINE GCC5_AARCH64_DLINK_FLAGS  = DEF(GCC49_AARCH64_DLINK_FLAGS)
> -Wl,-no-pie
>  DEFINE GCC5_AARCH64_DLINK2_FLAGS =
> DEF(GCC49_AARCH64_DLINK2_FLAGS) -Wno-error
>  DEFINE GCC5_ARM_ASLDLINK_FLAGS   = DEF(GCC49_ARM_ASLDLINK_FLAGS) -no-pie
> -DEFINE GCC5_AARCH64_ASLDLINK_FLAGS   =
> DEF(GCC49_AARCH64_ASLDLINK_FLAGS) -no-pie
> +DEFINE GCC5_AARCH64_ASLDLINK_FLAGS   =
> DEF(GCC49_AARCH64_ASLDLINK_FLAGS) -Wl,-no-pie
>
>  
> 
>  #
>

Unfortunately no change, still:
aarch64-linux-gnu-gcc: error: unrecognized command line option '-no-pie'
In order to make sure, I double checked twice cleaninig everything and
rebuilding from scratch.

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

Re: [edk2] [PATCH] BaseTools/tools_def AARCH64 ARM: disable PIE linking for .aslc sources

[Ard Biesheuvel]

On 16 November 2017 at 14:38, Marcin Wojtas  wrote:
> Hi Ard,
>
> With both PIE disabling patches for AARCH64, when compiling ACPI tables with
> gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-
> I get following errors:
> [...]
> aarch64-linux-gnu-gcc: error: unrecognized command line option '-no-pie'
> Do I understand correctly, that I should either revert those patches
> or upgrade to the newer toolchain?
>

Ugh.

I thought GCC 5 and later implemented -no-pie, but apparently not.

Does this fix your build? I will need to check whether it fixes the
original issue, but hopefully your toolchain doesn't choke on this:

diff --git a/BaseTools/Conf/tools_def.template
b/BaseTools/Conf/tools_def.template
index aebd7d558633..111fe8da7773 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -4496,10 +4496,10 @@ DEFINE GCC5_AARCH64_CC_FLAGS =
DEF(GCC49_AARCH64_CC_FLAGS)
 DEFINE GCC5_AARCH64_CC_XIPFLAGS  = DEF(GCC49_AARCH64_CC_XIPFLAGS)
 DEFINE GCC5_ARM_DLINK_FLAGS  = DEF(GCC49_ARM_DLINK_FLAGS) -no-pie
 DEFINE GCC5_ARM_DLINK2_FLAGS = DEF(GCC49_ARM_DLINK2_FLAGS) -Wno-error
-DEFINE GCC5_AARCH64_DLINK_FLAGS  = DEF(GCC49_AARCH64_DLINK_FLAGS) -no-pie
+DEFINE GCC5_AARCH64_DLINK_FLAGS  = DEF(GCC49_AARCH64_DLINK_FLAGS)
-Wl,-no-pie
 DEFINE GCC5_AARCH64_DLINK2_FLAGS =
DEF(GCC49_AARCH64_DLINK2_FLAGS) -Wno-error
 DEFINE GCC5_ARM_ASLDLINK_FLAGS   = DEF(GCC49_ARM_ASLDLINK_FLAGS) -no-pie
-DEFINE GCC5_AARCH64_ASLDLINK_FLAGS   =
DEF(GCC49_AARCH64_ASLDLINK_FLAGS) -no-pie
+DEFINE GCC5_AARCH64_ASLDLINK_FLAGS   =
DEF(GCC49_AARCH64_ASLDLINK_FLAGS) -Wl,-no-pie

 

 #



>
> 2017-11-01 16:18 GMT+01:00 Ard Biesheuvel :
>> On 1 November 2017 at 15:13, Gao, Liming  wrote:
>>> Reviewed-by: Liming Gao 
>>>
>>
>> Thanks - pushed as 3380a591232de2ab3007ab051010a67c3d000d1c
>>
 -Original Message-
 From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
 Sent: Wednesday, November 1, 2017 11:01 PM
 To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; Gao, Liming 
 ; Zhu, Yonghong
 
 Cc: daniel.thomp...@linaro.org; Ard Biesheuvel 
 Subject: [PATCH] BaseTools/tools_def AARCH64 ARM: disable PIE linking for 
 .aslc sources

 Commit 1894a7c64c0a ("BaseTools/tools_def AARCH64 ARM: disable PIE
 linking") works around an issue that was caught due to the fact that
 PIE linking produces broken .acpi files. However, v2 of that fix
 inadvertently only applied the workaround to the normal linker command
 line, and not to the ASLD one, so the issue still persists.

 So add the missing -no-pie options for ASLD on ARM and AARCH64.

 Contributed-under: TianoCore Contribution Agreement 1.1
 Signed-off-by: Ard Biesheuvel 
 ---
  BaseTools/Conf/tools_def.template | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/BaseTools/Conf/tools_def.template 
 b/BaseTools/Conf/tools_def.template
 index 98df0ffc9294..aebd7d558633 100755
 --- a/BaseTools/Conf/tools_def.template
 +++ b/BaseTools/Conf/tools_def.template
 @@ -4498,8 +4498,8 @@ DEFINE GCC5_ARM_DLINK_FLAGS  = 
 DEF(GCC49_ARM_DLINK_FLAGS) -no-pie
  DEFINE GCC5_ARM_DLINK2_FLAGS = DEF(GCC49_ARM_DLINK2_FLAGS) 
 -Wno-error
  DEFINE GCC5_AARCH64_DLINK_FLAGS  = DEF(GCC49_AARCH64_DLINK_FLAGS) 
 -no-pie
  DEFINE GCC5_AARCH64_DLINK2_FLAGS = DEF(GCC49_AARCH64_DLINK2_FLAGS) 
 -Wno-error
 -DEFINE GCC5_ARM_ASLDLINK_FLAGS   = DEF(GCC49_ARM_ASLDLINK_FLAGS)
 -DEFINE GCC5_AARCH64_ASLDLINK_FLAGS   = DEF(GCC49_AARCH64_ASLDLINK_FLAGS)
 +DEFINE GCC5_ARM_ASLDLINK_FLAGS   = DEF(GCC49_ARM_ASLDLINK_FLAGS) 
 -no-pie
 +DEFINE GCC5_AARCH64_ASLDLINK_FLAGS   = DEF(GCC49_AARCH64_ASLDLINK_FLAGS) 
 -no-pie

  
 
  #
 --
 2.11.0
>>>
>> ___
>> 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] BaseTools/tools_def AARCH64 ARM: disable PIE linking for .aslc sources

[Marcin Wojtas]

Hi Ard,

With both PIE disabling patches for AARCH64, when compiling ACPI tables with
gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-
I get following errors:
[...]
aarch64-linux-gnu-gcc: error: unrecognized command line option '-no-pie'
Do I understand correctly, that I should either revert those patches
or upgrade to the newer toolchain?

Best regards,
Marcin

2017-11-01 16:18 GMT+01:00 Ard Biesheuvel :
> On 1 November 2017 at 15:13, Gao, Liming  wrote:
>> Reviewed-by: Liming Gao 
>>
>
> Thanks - pushed as 3380a591232de2ab3007ab051010a67c3d000d1c
>
>>> -Original Message-
>>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>>> Sent: Wednesday, November 1, 2017 11:01 PM
>>> To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; Gao, Liming 
>>> ; Zhu, Yonghong
>>> 
>>> Cc: daniel.thomp...@linaro.org; Ard Biesheuvel 
>>> Subject: [PATCH] BaseTools/tools_def AARCH64 ARM: disable PIE linking for 
>>> .aslc sources
>>>
>>> Commit 1894a7c64c0a ("BaseTools/tools_def AARCH64 ARM: disable PIE
>>> linking") works around an issue that was caught due to the fact that
>>> PIE linking produces broken .acpi files. However, v2 of that fix
>>> inadvertently only applied the workaround to the normal linker command
>>> line, and not to the ASLD one, so the issue still persists.
>>>
>>> So add the missing -no-pie options for ASLD on ARM and AARCH64.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Ard Biesheuvel 
>>> ---
>>>  BaseTools/Conf/tools_def.template | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/BaseTools/Conf/tools_def.template 
>>> b/BaseTools/Conf/tools_def.template
>>> index 98df0ffc9294..aebd7d558633 100755
>>> --- a/BaseTools/Conf/tools_def.template
>>> +++ b/BaseTools/Conf/tools_def.template
>>> @@ -4498,8 +4498,8 @@ DEFINE GCC5_ARM_DLINK_FLAGS  = 
>>> DEF(GCC49_ARM_DLINK_FLAGS) -no-pie
>>>  DEFINE GCC5_ARM_DLINK2_FLAGS = DEF(GCC49_ARM_DLINK2_FLAGS) 
>>> -Wno-error
>>>  DEFINE GCC5_AARCH64_DLINK_FLAGS  = DEF(GCC49_AARCH64_DLINK_FLAGS) 
>>> -no-pie
>>>  DEFINE GCC5_AARCH64_DLINK2_FLAGS = DEF(GCC49_AARCH64_DLINK2_FLAGS) 
>>> -Wno-error
>>> -DEFINE GCC5_ARM_ASLDLINK_FLAGS   = DEF(GCC49_ARM_ASLDLINK_FLAGS)
>>> -DEFINE GCC5_AARCH64_ASLDLINK_FLAGS   = DEF(GCC49_AARCH64_ASLDLINK_FLAGS)
>>> +DEFINE GCC5_ARM_ASLDLINK_FLAGS   = DEF(GCC49_ARM_ASLDLINK_FLAGS) 
>>> -no-pie
>>> +DEFINE GCC5_AARCH64_ASLDLINK_FLAGS   = DEF(GCC49_AARCH64_ASLDLINK_FLAGS) 
>>> -no-pie
>>>
>>>  
>>> 
>>>  #
>>> --
>>> 2.11.0
>>
> ___
> 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] ArmPkg: move RVCT PLATFORM_FLAGS override into ArmHvcLib/ArmSmcLib

[Ard Biesheuvel]

Currently, each ARM platform built with RVCT that uses ArmHvcLib
or ArmSmcLib needs to specify a CPU target that implements both the
security and virtualization extensions, so that the assembler does
not choke on the 'hvc' and 'smc' instructions in ArmHvcLib/ArmSvcLib.
Let's move these overrides into the module .INFs so we can lift this
requirement at the platform side.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/ArmPkg.dsc  | 2 --
 ArmPkg/Library/ArmHvcLib/ArmHvcLib.inf | 3 +++
 ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf | 3 +++
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
index 382e99868453..622720ab2aef 100644
--- a/ArmPkg/ArmPkg.dsc
+++ b/ArmPkg/ArmPkg.dsc
@@ -33,8 +33,6 @@ [Defines]
 [BuildOptions]
   XCODE:*_*_ARM_PLATFORM_FLAGS  == -arch armv7
   GCC:*_*_ARM_PLATFORM_FLAGS== -march=armv7-a -mfpu=neon
-  # We use A15 to get the Secure and Virtualization extensions
-  RVCT:*_*_ARM_PLATFORM_FLAGS  == --cpu Cortex-A15
 
   RELEASE_*_*_CC_FLAGS  = -DMDEPKG_NDEBUG
   *_*_*_CC_FLAGS  = -DDISABLE_NEW_DEPRECATED_INTERFACES
diff --git a/ArmPkg/Library/ArmHvcLib/ArmHvcLib.inf 
b/ArmPkg/Library/ArmHvcLib/ArmHvcLib.inf
index 92efac5741c8..d046ef3ba253 100644
--- a/ArmPkg/Library/ArmHvcLib/ArmHvcLib.inf
+++ b/ArmPkg/Library/ArmHvcLib/ArmHvcLib.inf
@@ -30,3 +30,6 @@ [Sources.AARCH64]
 [Packages]
   MdePkg/MdePkg.dec
   ArmPkg/ArmPkg.dec
+
+[BuildOptions]
+  RVCT:*_*_ARM_PLATFORM_FLAGS == --cpu Cortex-A15
diff --git a/ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf 
b/ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf
index 9f9ba729967c..0aa64d467129 100644
--- a/ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf
+++ b/ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf
@@ -29,3 +29,6 @@ [Sources.AARCH64]
 [Packages]
   MdePkg/MdePkg.dec
   ArmPkg/ArmPkg.dec
+
+[BuildOptions]
+  RVCT:*_*_ARM_PLATFORM_FLAGS == --cpu Cortex-A15
-- 
2.11.0

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

Re: [edk2] [PATCH] ArmVirtPkg: remove ArmPlatformSysConfigLib dependency

[Ard Biesheuvel]

On 16 November 2017 at 12:34, Ard Biesheuvel  wrote:
>
>
>> On 16 Nov 2017, at 11:59, Leif Lindholm  wrote:
>>
>>> On Thu, Nov 16, 2017 at 09:40:58AM +, Ard Biesheuvel wrote:
 On 15 November 2017 at 14:03, Ard Biesheuvel  
 wrote:
 Now that the PL031 RTC driver library no longer depends on the ARM
 platform specific ArmPlatformSysConfigLib, we no longer need to
 implement ArmPlatform.h or have a resolution for that library.
 This allows us to get rid of a rather dodgy practice of including
 platform headers using compiler flags, which is a bad idea at various
 levels.

 Contributed-under: TianoCore Contribution Agreement 1.1
 Signed-off-by: Ard Biesheuvel 
 ---
 PL031 patch is on-list and pending.

 ArmVirtPkg/ArmVirtQemu.dsc |  7 
 -
 ArmVirtPkg/ArmVirtQemuKernel.dsc   |  6 
 
 ArmVirtPkg/ArmVirtXen.dsc  |  6 
 
 ArmVirtPkg/Include/ArmPlatform.h   | 33 
 
 ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/QemuVirtMem.c |  1 -
 ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/RelocatableVirt.c |  1 -
 ArmVirtPkg/Library/ArmVirtPlatformLib/Virt.c   |  1 -
 ArmVirtPkg/Library/ArmVirtPlatformLib/VirtMem.c|  1 -
 ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/RelocatableVirt.c  |  1 -
 ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/XenVirtMem.c   |  1 -
 ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c   |  7 
 -
 11 files changed, 6 insertions(+), 59 deletions(-)

 diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
 index 8a60b61f2aa6..d1b3849d856a 100644
 --- a/ArmVirtPkg/ArmVirtQemu.dsc
 +++ b/ArmVirtPkg/ArmVirtQemu.dsc
 @@ -49,7 +49,6 @@ [LibraryClasses.common]
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/BaseQemuFwCfgS3LibNull.inf

   
 ArmPlatformLib|ArmVirtPkg/Library/ArmVirtPlatformLib/ArmVirtPlatformLib.inf
 -  
 ArmPlatformSysConfigLib|ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.inf

   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
   
 NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
 @@ -71,12 +70,6 @@ [LibraryClasses.common]
 [LibraryClasses.common.UEFI_DRIVER]
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf

 -[BuildOptions]
 -  RVCT:*_*_ARM_PLATFORM_FLAGS == --cpu Cortex-A15 
 -I$(WORKSPACE)/ArmVirtPkg/Include
 -  GCC:*_*_ARM_PLATFORM_FLAGS == -mcpu=cortex-a15 
 -I$(WORKSPACE)/ArmVirtPkg/Include
>>>
>>> Oops. I will need to retain the -mcpu setting here, or the 'hvc'
>>> instruction will be rejected by the assembler.
>>
>> Don't we have source-level overrides for that?
>> At least ".arch_extension virt" for GNU.
>>
>
> Yeah, or at least move the cflags override to the .inf of the library that 
> uses the hvc instruction

As it turns out, ArmVirtQemu.dsc builds find without the -mcpu CFLAGS,
due to the fact that we already have .arch_extension virt' in
ArmPkg/Library/ArmHvcLib/Arm/ArmHvc.S, which is the only file that is
affected by this AFAICT. I will double check how RVCT deals with this,
but I will move the --cpu=Cortex-A15 flag into
ArmPkg/Library/ArmHvcLib/ArmHvcLib.inf at the very least
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 0/4] UefiCpuPkg, OvmfPkg: add reset vector docs, tweak temp stack / RAM

[Jordan Justen]

Series Reviewed-by: Jordan Justen 

On 2017-11-15 13:56:59, Laszlo Ersek wrote:
> Repo:   https://github.com/lersek/edk2.git
> Branch: temp_ram_tweaks_v2
> 
> This is a series for
> 
>   https://bugzilla.tianocore.org/show_bug.cgi?id=747
> 
> specifically an update on the v1 series at
> 
>   https://lists.01.org/pipermail/edk2-devel/2017-November/017239.html
> 
> Each patch has its notes section on the changes relative to v1.
> 
> I re-ran the unit tests described in some of the patches; in addition to
> the functional tests and my usual regression tests.
> 
> Cc: Ard Biesheuvel 
> Cc: Eric Dong 
> Cc: Jordan Justen 
> 
> Thanks
> Laszlo
> 
> Laszlo Ersek (4):
>   UefiCpuPkg/ResetVector/Vtf0: document segment register setup
>   OvmfPkg/Sec/Ia32: seed the temporary RAM with PcdInitValueInTempStack
>   OvmfPkg/Sec/X64: seed the temporary RAM with PcdInitValueInTempStack
>   OvmfPkg: restore temporary SEC/PEI RAM size to 64KB
> 
>  OvmfPkg/OvmfPkgIa32.fdf |  2 +-
>  OvmfPkg/OvmfPkgIa32X64.fdf  |  2 +-
>  OvmfPkg/OvmfPkgX64.fdf  |  2 +-
>  OvmfPkg/Sec/Ia32/SecEntry.nasm  | 18 +
>  OvmfPkg/Sec/SecMain.inf |  1 +
>  OvmfPkg/Sec/X64/SecEntry.nasm   | 21 
>  UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm |  6 ++
>  UefiCpuPkg/ResetVector/Vtf0/Main.asm|  5 +
>  8 files changed, 54 insertions(+), 3 deletions(-)
> 
> -- 
> 2.14.1.3.gb7cf6e02401b
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH V2] MdeModulePkg EhciPei: Support IoMmu

[Star Zeng]

V2: Halt HC at EndOfPei.

Update the EhciPei driver to consume IOMMU_PPI to allocate DMA buffer.

If no IOMMU_PPI exists, this driver still calls PEI service to allocate
DMA buffer, with assumption that DRAM==DMA.

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Bus/Pci/EhciPei/DmaMem.c| 250 +++
 MdeModulePkg/Bus/Pci/EhciPei/EhcPeim.c   |  40 -
 MdeModulePkg/Bus/Pci/EhciPei/EhcPeim.h   | 119 ++-
 MdeModulePkg/Bus/Pci/EhciPei/EhciPei.inf |   6 +-
 MdeModulePkg/Bus/Pci/EhciPei/EhciSched.c |  38 +++--
 MdeModulePkg/Bus/Pci/EhciPei/EhciUrb.c   |  42 --
 MdeModulePkg/Bus/Pci/EhciPei/UsbHcMem.c  |  84 +--
 MdeModulePkg/Bus/Pci/EhciPei/UsbHcMem.h  |  18 ++-
 8 files changed, 551 insertions(+), 46 deletions(-)
 create mode 100644 MdeModulePkg/Bus/Pci/EhciPei/DmaMem.c

diff --git a/MdeModulePkg/Bus/Pci/EhciPei/DmaMem.c 
b/MdeModulePkg/Bus/Pci/EhciPei/DmaMem.c
new file mode 100644
index ..1330f53f411a
--- /dev/null
+++ b/MdeModulePkg/Bus/Pci/EhciPei/DmaMem.c
@@ -0,0 +1,250 @@
+/** @file
+The DMA memory help functions.
+
+Copyright (c) 2017, 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.
+
+**/
+
+#include "EhcPeim.h"
+
+/**
+  Provides the controller-specific addresses required to access system memory 
from a
+  DMA bus master.
+
+  @param IoMmu  Pointer to IOMMU PPI.
+  @param Operation  Indicates if the bus master is going to read 
or write to system memory.
+  @param HostAddressThe system memory address to map to the PCI 
controller.
+  @param NumberOfBytes  On input the number of bytes to map. On output 
the number of bytes
+that were mapped.
+  @param DeviceAddress  The resulting map address for the bus master 
PCI controller to use to
+access the hosts HostAddress.
+  @param MappingA resulting value to pass to Unmap().
+
+  @retval EFI_SUCCESS   The range was mapped for the returned 
NumberOfBytes.
+  @retval EFI_UNSUPPORTED   The HostAddress cannot be mapped as a common 
buffer.
+  @retval EFI_INVALID_PARAMETER One or more parameters are invalid.
+  @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a 
lack of resources.
+  @retval EFI_DEVICE_ERROR  The system hardware could not map the 
requested address.
+
+**/
+EFI_STATUS
+IoMmuMap (
+  IN EDKII_IOMMU_PPI*IoMmu,
+  IN EDKII_IOMMU_OPERATION  Operation,
+  IN VOID   *HostAddress,
+  IN OUT UINTN  *NumberOfBytes,
+  OUT EFI_PHYSICAL_ADDRESS  *DeviceAddress,
+  OUT VOID  **Mapping
+  )
+{
+  EFI_STATUSStatus;
+  UINT64Attribute;
+
+  if (IoMmu != NULL) {
+Status = IoMmu->Map (
+  IoMmu,
+  Operation,
+  HostAddress,
+  NumberOfBytes,
+  DeviceAddress,
+  Mapping
+  );
+if (EFI_ERROR (Status)) {
+  return EFI_OUT_OF_RESOURCES;
+}
+switch (Operation) {
+case EdkiiIoMmuOperationBusMasterRead:
+case EdkiiIoMmuOperationBusMasterRead64:
+  Attribute = EDKII_IOMMU_ACCESS_READ;
+  break;
+case EdkiiIoMmuOperationBusMasterWrite:
+case EdkiiIoMmuOperationBusMasterWrite64:
+  Attribute = EDKII_IOMMU_ACCESS_WRITE;
+  break;
+case EdkiiIoMmuOperationBusMasterCommonBuffer:
+case EdkiiIoMmuOperationBusMasterCommonBuffer64:
+  Attribute = EDKII_IOMMU_ACCESS_READ | EDKII_IOMMU_ACCESS_WRITE;
+  break;
+default:
+  ASSERT(FALSE);
+  return EFI_INVALID_PARAMETER;
+}
+Status = IoMmu->SetAttribute (
+  IoMmu,
+  *Mapping,
+  Attribute
+  );
+if (EFI_ERROR (Status)) {
+  IoMmu->Unmap (IoMmu, Mapping);
+  *Mapping = NULL;
+  return Status;
+}
+  } else {
+*DeviceAddress = (EFI_PHYSICAL_ADDRESS) (UINTN) HostAddress;
+*Mapping = NULL;
+Status = EFI_SUCCESS;
+  }
+  return Status;
+}
+
+/**
+  Completes the Map() operation and releases any corresponding resources.
+
+  @param IoMmu  Pointer to IOMMU PPI.
+  @param MappingThe mapping value returned from Map().
+
+**/
+VOID
+IoMmuUnmap (
+  IN EDKII_IOMMU_PPI*IoMmu,
+  IN VOID  *Mapping
+  )
+{
+  if (IoMmu != NULL) {
+IoMmu->SetAttribute 

[edk2] [PATCH 0/1] Update for the 2017-10-18 VS2017 proposal

[Pete Batard]

The following is a set of changes that I'd like to see applied to Liming's
2017-10-18 VS2017 support proposal for IA32 and X64.
(See https://lists.01.org/pipermail/edk2-devel/2017-October/016175.html)

Since I am planning to submit a v2 of my VS2017 ARM/AARCH64 proposal, that
relies on these alterations, I am sending this preliminary patch for review.

The 3 main changes that are being introduced from the existing proposal are:
1. The use of %WindowsSdkVerBinPath% if defined, to locate the most recent
   version of the Windows 10 SDK. The fact that vcvars32.bat should have been
   called should usually ensure that this variable has been set, which in turn
   should ensure that we can access the required ARM64 tools and libraries. Of
   course, if the variable is not defined, the fallback to the hardcoded SDK
   top directory should still work fine for IA32 and X64.
2. Follow the way Microsoft structured the Visual Studio 2017 toolchains by
   introducing a specific VS2017_BIN_HOST, for host-specific elements, that is
   separate from the various VS2017_BIN_ targets. I believe this will
   make maintenance easier in the long run, as it makes the breakdown of what
   relates to the host and what relates to the target a lot more explicit.
   Note that, for clarity's sake, and unlike the convention that was used
   previously, I chose to add an underscore between BIN and . This is
   because, once we start dealing with things like VS2017_BIN_ARM and
   VS2017_BIN_AARCH64, we'll probably be happier with a separator for .
3. Factorize the elements that are HOST related, since they don't need to be
   duplicated.

I'm hoping that these alterations can be agreed on. If that is the case, and
considering that these changes need to be applied on top of the current VS2017
proposal, I can submit a v2 of Liming's patches, that includes these changes,
for review and integration.

I should also point out that, outside of these modification, the current
proposal looks good to me especially as I have tested the generation of the
IA32 and X64 OVMF using VS2017 (from a regular command prompt rather than a
VS2017 one), as well as a handful of IA32 and X64 applications and found no
issues. For the sake of validating my proposed changes, I tested both the
x86 and x64 VS2017 HOSTs.

Regards,

/Pete

Pete Batard (1):
  BaseTools: Use VS2017 SDK path if defined and reorganize variables

 BaseTools/Conf/tools_def.template | 66 ++-
 BaseTools/set_vsprefix_envs.bat   | 15 -
 2 files changed, 39 insertions(+), 42 deletions(-)

-- 
2.9.3.windows.2

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

[edk2] [PATCH 1/1] BaseTools: Use VS2017 SDK path if defined and reorganize variables

[Pete Batard]

1. The use of WindowsSdkVerBinPath allows us to access the latest SDK,
   which we will need when we introduce VS2017 support for AARCH64.
2. Make the breakdown between host and target more explicit, and more in
   line  with how Microsoft reorganized the latest Visual Studio
   toolchains, by introducing explicit and separate _HOST and _
   variables.
3. Factorize _DLL and _MAKE_PATH as these are host rather than arch
   dependent.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 BaseTools/Conf/tools_def.template | 66 ++-
 BaseTools/set_vsprefix_envs.bat   | 15 -
 2 files changed, 39 insertions(+), 42 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 4af883463d4f..ad900d821e65 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -74,9 +74,11 @@ DEFINE VS2015x86_BIN= ENV(VS2015_PREFIX)Vc\bin
 DEFINE VS2015x86_DLL= ENV(VS2015_PREFIX)Common7\IDE;DEF(VS2015x86_BIN)
 DEFINE VS2015x86_BINX64 = DEF(VS2015x86_BIN)\x86_amd64
 
-DEFINE VS2017_BIN= ENV(VS2017_PREFIX)
-DEFINE VS2017_DLL= ENV(VS2017_PREFIX)
-DEFINE VS2017_BINX64 = ENV(VS2017X64_PREFIX)
+DEFINE VS2017_BIN = ENV(VS2017_PREFIX)bin
+DEFINE VS2017_HOST= x86
+DEFINE VS2017_BIN_HOST= 
DEF(VS2017_BIN)\HostDEF(VS2017_HOST)\DEF(VS2017_HOST)
+DEFINE VS2017_BIN_IA32= DEF(VS2017_BIN)\HostDEF(VS2017_HOST)\x86
+DEFINE VS2017_BIN_X64 = DEF(VS2017_BIN)\HostDEF(VS2017_HOST)\x64
 
 DEFINE WINSDK_BIN   = ENV(WINSDK_PREFIX)
 DEFINE WINSDKx86_BIN= ENV(WINSDKx86_PREFIX)
@@ -98,7 +100,7 @@ DEFINE WINSDK81_BIN   = ENV(WINSDK81_PREFIX)x86\
 DEFINE WINSDK81x86_BIN= ENV(WINSDK81x86_PREFIX)x64
 
 # Microsoft Visual Studio 2017 Professional Edition
-DEFINE WINSDK10_BIN   = ENV(WINSDK10_PREFIX)
+DEFINE WINSDK10_BIN   = ENV(WINSDK10_PREFIX)x86
 
 # These defines are needed for certain Microsoft Visual Studio tools that
 # are used by other toolchains.  An example is that ICC on Windows normally
@@ -4074,8 +4076,9 @@ NOOPT_VS2015x86xASL_X64_DLINK_FLAGS= /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT
 

 #   VS2017   - Microsoft Visual Studio 2017 professional Edition with 
Intel ASL
 *_VS2017_*_*_FAMILY= MSFT
+*_VS2017_*_*_DLL   = DEF(VS2017_BIN_HOST)
 
-*_VS2017_*_MAKE_PATH   = DEF(VS2017_BIN)\nmake.exe
+*_VS2017_*_MAKE_PATH   = DEF(VS2017_BIN_HOST)\nmake.exe
 *_VS2017_*_MAKE_FLAG   = /nologo
 *_VS2017_*_RC_PATH = DEF(WINSDK10_BIN)\rc.exe
 
@@ -4085,7 +4088,7 @@ NOOPT_VS2015x86xASL_X64_DLINK_FLAGS= /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT
 *_VS2017_*_PP_FLAGS= /nologo /E /TC /FIAutoGen.h
 *_VS2017_*_VFRPP_FLAGS = /nologo /E /TC /DVFRCOMPILE 
/FI$(MODULE_NAME)StrDefs.h
 *_VS2017_*_DLINK2_FLAGS= /WHOLEARCHIVE
-*_VS2017_*_ASM16_PATH  = DEF(VS2017_BIN)\ml.exe
+*_VS2017_*_ASM16_PATH  = DEF(VS2017_BIN_IA32)\ml.exe
 
 ##
 # ASL definitions
@@ -4100,19 +4103,16 @@ NOOPT_VS2015x86xASL_X64_DLINK_FLAGS= /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT
 ##
 # IA32 definitions
 ##
-*_VS2017_IA32_*_DLL= DEF(VS2017_DLL)
-
-*_VS2017_IA32_MAKE_PATH= DEF(VS2017_BIN)\nmake.exe
-*_VS2017_IA32_CC_PATH  = DEF(VS2017_BIN)\cl.exe
-*_VS2017_IA32_VFRPP_PATH   = DEF(VS2017_BIN)\cl.exe
-*_VS2017_IA32_ASLCC_PATH   = DEF(VS2017_BIN)\cl.exe
-*_VS2017_IA32_ASLPP_PATH   = DEF(VS2017_BIN)\cl.exe
-*_VS2017_IA32_SLINK_PATH   = DEF(VS2017_BIN)\lib.exe
-*_VS2017_IA32_DLINK_PATH   = DEF(VS2017_BIN)\link.exe
-*_VS2017_IA32_ASLDLINK_PATH= DEF(VS2017_BIN)\link.exe
-*_VS2017_IA32_APP_PATH = DEF(VS2017_BIN)\cl.exe
-*_VS2017_IA32_PP_PATH  = DEF(VS2017_BIN)\cl.exe
-*_VS2017_IA32_ASM_PATH = DEF(VS2017_BIN)\ml.exe
+*_VS2017_IA32_CC_PATH  = DEF(VS2017_BIN_IA32)\cl.exe
+*_VS2017_IA32_VFRPP_PATH   = DEF(VS2017_BIN_IA32)\cl.exe
+*_VS2017_IA32_ASLCC_PATH   = DEF(VS2017_BIN_IA32)\cl.exe
+*_VS2017_IA32_ASLPP_PATH   = DEF(VS2017_BIN_IA32)\cl.exe
+*_VS2017_IA32_SLINK_PATH   = DEF(VS2017_BIN_IA32)\lib.exe
+*_VS2017_IA32_DLINK_PATH   = DEF(VS2017_BIN_IA32)\link.exe
+*_VS2017_IA32_ASLDLINK_PATH= DEF(VS2017_BIN_IA32)\link.exe
+*_VS2017_IA32_APP_PATH = DEF(VS2017_BIN_IA32)\cl.exe
+*_VS2017_IA32_PP_PATH  = DEF(VS2017_BIN_IA32)\cl.exe
+*_VS2017_IA32_ASM_PATH = DEF(VS2017_BIN_IA32)\ml.exe
 
   *_VS2017_IA32_MAKE_FLAGS  = /nologo
   DEBUG_VS2017_IA32_CC_FLAGS= /nologo /arch:IA32 /c /WX /GS- /W4 /Gs32768 
/D UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm
@@ -4134,18 +4134,16 @@ NOOPT_VS2017_IA32_DLINK_FLAGS   = /NOLOGO /NODEFAULTLIB 
/IGNORE:4001 /OPT:REF /O
 ##
 # X64 definitions
 ##
-*_VS2017_X64_*_DLL = DEF(VS2017_DLL)
-
-*_VS2017_X64_CC_PATH   = DEF(VS2017_BINX64)\cl.exe

Re: [edk2] [PATCH] ArmVirtPkg: remove ArmPlatformSysConfigLib dependency

[Ard Biesheuvel]

> On 16 Nov 2017, at 11:59, Leif Lindholm  wrote:
> 
>> On Thu, Nov 16, 2017 at 09:40:58AM +, Ard Biesheuvel wrote:
>>> On 15 November 2017 at 14:03, Ard Biesheuvel  
>>> wrote:
>>> Now that the PL031 RTC driver library no longer depends on the ARM
>>> platform specific ArmPlatformSysConfigLib, we no longer need to
>>> implement ArmPlatform.h or have a resolution for that library.
>>> This allows us to get rid of a rather dodgy practice of including
>>> platform headers using compiler flags, which is a bad idea at various
>>> levels.
>>> 
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Ard Biesheuvel 
>>> ---
>>> PL031 patch is on-list and pending.
>>> 
>>> ArmVirtPkg/ArmVirtQemu.dsc |  7 
>>> -
>>> ArmVirtPkg/ArmVirtQemuKernel.dsc   |  6 
>>> ArmVirtPkg/ArmVirtXen.dsc  |  6 
>>> ArmVirtPkg/Include/ArmPlatform.h   | 33 
>>> 
>>> ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/QemuVirtMem.c |  1 -
>>> ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/RelocatableVirt.c |  1 -
>>> ArmVirtPkg/Library/ArmVirtPlatformLib/Virt.c   |  1 -
>>> ArmVirtPkg/Library/ArmVirtPlatformLib/VirtMem.c|  1 -
>>> ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/RelocatableVirt.c  |  1 -
>>> ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/XenVirtMem.c   |  1 -
>>> ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c   |  7 
>>> -
>>> 11 files changed, 6 insertions(+), 59 deletions(-)
>>> 
>>> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
>>> index 8a60b61f2aa6..d1b3849d856a 100644
>>> --- a/ArmVirtPkg/ArmVirtQemu.dsc
>>> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
>>> @@ -49,7 +49,6 @@ [LibraryClasses.common]
>>>   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/BaseQemuFwCfgS3LibNull.inf
>>> 
>>>   
>>> ArmPlatformLib|ArmVirtPkg/Library/ArmVirtPlatformLib/ArmVirtPlatformLib.inf
>>> -  
>>> ArmPlatformSysConfigLib|ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.inf
>>> 
>>>   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
>>>   NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
>>> @@ -71,12 +70,6 @@ [LibraryClasses.common]
>>> [LibraryClasses.common.UEFI_DRIVER]
>>>   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
>>> 
>>> -[BuildOptions]
>>> -  RVCT:*_*_ARM_PLATFORM_FLAGS == --cpu Cortex-A15 
>>> -I$(WORKSPACE)/ArmVirtPkg/Include
>>> -  GCC:*_*_ARM_PLATFORM_FLAGS == -mcpu=cortex-a15 
>>> -I$(WORKSPACE)/ArmVirtPkg/Include
>> 
>> Oops. I will need to retain the -mcpu setting here, or the 'hvc'
>> instruction will be rejected by the assembler.
> 
> Don't we have source-level overrides for that?
> At least ".arch_extension virt" for GNU.
> 

Yeah, or at least move the cflags override to the .inf of the library that uses 
the hvc instruction
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Change BIOS Version

[Guo, Mang]

Contributed-under: TianoCore Contribution Agreement 1.1

Signed-off-by: Guo Mang 
---
 Platform/BroxtonPlatformPkg/BiosId.env | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/BroxtonPlatformPkg/BiosId.env 
b/Platform/BroxtonPlatformPkg/BiosId.env
index 3993fb2..851c2d3 100644
--- a/Platform/BroxtonPlatformPkg/BiosId.env
+++ b/Platform/BroxtonPlatformPkg/BiosId.env
@@ -31,5 +31,5 @@ BOARD_ID  = APLKRVP
 BOARD_REV = 3
 BUILD_TYPE= D
 VERSION_MAJOR = 0067
-VERSION_MINOR = 04
+VERSION_MINOR = 05
 BOARD_EXT = X64
-- 
2.10.1.windows.1

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

Re: [edk2] [PATCH] ArmVirtPkg: remove ArmPlatformSysConfigLib dependency

[Leif Lindholm]

On Thu, Nov 16, 2017 at 09:40:58AM +, Ard Biesheuvel wrote:
> On 15 November 2017 at 14:03, Ard Biesheuvel  
> wrote:
> > Now that the PL031 RTC driver library no longer depends on the ARM
> > platform specific ArmPlatformSysConfigLib, we no longer need to
> > implement ArmPlatform.h or have a resolution for that library.
> > This allows us to get rid of a rather dodgy practice of including
> > platform headers using compiler flags, which is a bad idea at various
> > levels.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel 
> > ---
> > PL031 patch is on-list and pending.
> >
> >  ArmVirtPkg/ArmVirtQemu.dsc |  7 
> > -
> >  ArmVirtPkg/ArmVirtQemuKernel.dsc   |  6 
> > 
> >  ArmVirtPkg/ArmVirtXen.dsc  |  6 
> > 
> >  ArmVirtPkg/Include/ArmPlatform.h   | 33 
> > 
> >  ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/QemuVirtMem.c |  1 -
> >  ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/RelocatableVirt.c |  1 -
> >  ArmVirtPkg/Library/ArmVirtPlatformLib/Virt.c   |  1 -
> >  ArmVirtPkg/Library/ArmVirtPlatformLib/VirtMem.c|  1 -
> >  ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/RelocatableVirt.c  |  1 -
> >  ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/XenVirtMem.c   |  1 -
> >  ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c   |  7 
> > -
> >  11 files changed, 6 insertions(+), 59 deletions(-)
> >
> > diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> > index 8a60b61f2aa6..d1b3849d856a 100644
> > --- a/ArmVirtPkg/ArmVirtQemu.dsc
> > +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> > @@ -49,7 +49,6 @@ [LibraryClasses.common]
> >QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/BaseQemuFwCfgS3LibNull.inf
> >
> >
> > ArmPlatformLib|ArmVirtPkg/Library/ArmVirtPlatformLib/ArmVirtPlatformLib.inf
> > -  
> > ArmPlatformSysConfigLib|ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.inf
> >
> >TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
> >
> > NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
> > @@ -71,12 +70,6 @@ [LibraryClasses.common]
> >  [LibraryClasses.common.UEFI_DRIVER]
> >UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
> >
> > -[BuildOptions]
> > -  RVCT:*_*_ARM_PLATFORM_FLAGS == --cpu Cortex-A15 
> > -I$(WORKSPACE)/ArmVirtPkg/Include
> > -  GCC:*_*_ARM_PLATFORM_FLAGS == -mcpu=cortex-a15 
> > -I$(WORKSPACE)/ArmVirtPkg/Include
> 
> Oops. I will need to retain the -mcpu setting here, or the 'hvc'
> instruction will be rejected by the assembler.

Don't we have source-level overrides for that?
At least ".arch_extension virt" for GNU.

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

Re: [edk2] [Patch V3 2/2] MdeModulePkg/UsbMassStorageDxe: Check Get Max LUN status/value

[Zeng, Star]

Mike,

After this patch, the return status of UsbBotGetMaxLun seems confusing and 
useless. Fortunately, there is no one using the return status of it.
What do you think?


Thanks,
Star
-Original Message-
From: Kinney, Michael D 
Sent: Thursday, November 16, 2017 11:58 AM
To: edk2-devel@lists.01.org
Cc: Zeng, Star ; Dong, Eric 
Subject: [Patch V3 2/2] MdeModulePkg/UsbMassStorageDxe: Check Get Max LUN 
status/value

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

If a USB Mass Storage device does not support the Get Max LUN command, then the 
USB I/O Protocol ControlTransfer() service may return an error.  If an error is 
returned for this command, then assume that the device does not support 
multiple LUNs and return a maximum LUN value of 0.

The USB Mass Storage Class Specification states that a maximum LUN value larger 
than 0x0F is invalid.  Add a check to make sure this maximum LUN value is in 
this valid range, and if it is not, then assume that the device does not 
support multiple LUNs and return a maximum LUN value of 0.

This change improves compatibility with USB FLASH drives that do not support 
the Get Max LUN command or return an invalid maximum LUN value.

Cc: Star Zeng 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
---
 MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c 
b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c
index 4bb7222b89..6afe2ae235 100644
--- a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c
+++ b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c
@@ -2,7 +2,7 @@
   Implementation of the USB mass storage Bulk-Only Transport protocol,
   according to USB Mass Storage Class Bulk-Only Transport, Revision 1.0.
 
-Copyright (c) 2007 - 2011, Intel Corporation. All rights reserved.
+Copyright (c) 2007 - 2017, 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 @@ -576,6 +576,18 
@@ UsbBotGetMaxLun (
 1,
 
 );
+  if (EFI_ERROR (Status) || *MaxLun > USB_BOT_MAX_LUN) {
+//
+// If the Get LUN request returns an error or the MaxLun is larger than
+// the maximum LUN value (0x0f) supported by the USB Mass Storage Class
+// Bulk-Only Transport Spec, then set MaxLun to 0.
+//
+// This improves compatibility with USB FLASH drives that have a single LUN
+// and either do not return a max LUN value or return an invalid maximum 
LUN
+// value.
+//
+*MaxLun = 0;
+  }
 
   return Status;
 }
--
2.14.2.windows.3

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

Re: [edk2] [Patch] MdeModulePkg/UsbMassStorageDxe: Enhance Request Sense Handling

[Zeng, Star]

Mike,

Returning EFI_NOT_READY for USB_BOOT_ASC_NO_MEDIA seems a little confusing, but 
based on the real case, I am ok with the patch.

Reviewed-by: Star Zeng 


Thanks,
Star
-Original Message-
From: Kinney, Michael D 
Sent: Wednesday, November 15, 2017 9:28 AM
To: edk2-devel@lists.01.org
Cc: Zeng, Star ; Dong, Eric 
Subject: [Patch] MdeModulePkg/UsbMassStorageDxe: Enhance Request Sense Handling

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

Update the Request Sense check for the Request Sense Key of 
USB_BOOT_SENSE_UNIT_ATTENTION.  For this Sense Key, the Additional Sense Key to 
EFI_STATUS mappings are:

USB_BOOT_ASC_MEDIA_CHANGE -> EFI_MEDIA_CHANGE
USB_BOOT_ASC_NOT_READY-> EFI_NOT_READY
USB_BOOT_ASC_NO_MEDIA -> EFI_NOT_READY
All others-> EFI_DEVICE_ERROR

A USB flash drive is returning Request Sense Key of 
USB_BOOT_SENSE_UNIT_ATTENTION and an Additional Sense Key of 
USB_BOOT_ASC_NO_MEDIA for a few seconds before returning an Additional Sense 
Key of USB_BOOT_ASC_MEDIA_CHANGE.

The current logic treats this initial Request Sense info as an error and reties 
the command 5 times before failing completely.

With this change the USB Flash Drive works correctly.

Cc: Star Zeng 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
---
 MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c 
b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
index 2eb30f0c5f..a8b6a1c5f1 100644
--- a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
+++ b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
@@ -120,6 +120,10 @@ UsbBootRequestSense (
   Status = EFI_MEDIA_CHANGED;
   Media->ReadOnly = FALSE;
   Media->MediaId++;
+} else if (SenseData.Asc == USB_BOOT_ASC_NOT_READY) {
+  Status = EFI_NOT_READY;
+} else if (SenseData.Asc == USB_BOOT_ASC_NO_MEDIA) {
+  Status = EFI_NOT_READY;
 }
 break;
 
--
2.14.2.windows.3

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

[edk2] [PATCH v2 0/2] OvmfPkg: save on I/O port accesses when the debug port is not in use

[Paolo Bonzini]

This is version 2 of the patch I sent yesterday, now with proper SEC
support.  The series makes OvmfPkg's PlatformDebugLibIoPort library
skip I/O port writes when the debug port device wasn't added to the
virtual machine.

Patch 1 creates a separate PlatformDebugLibIoPort instance for SEC, so
that the non-SEC version will be able to use a writable global variable.
Patch 2 then adds the detection machinery to both library instances.

The commit messages in both patches liberally pillage Laszlo's v1 review.

Thanks,

Paolo

Paolo Bonzini (2):
  OvmfPkg: create a separate PlatformDebugLibIoPort instance for SEC
  OvmfPkg: save on I/O port accesses when the debug port is not in use

 OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c  | 41 
 .../PlatformDebugLibIoPort/DebugLibDetect.c| 55 +
 .../PlatformDebugLibIoPort/DebugLibDetect.h| 56 ++
 .../PlatformDebugLibIoPort/DebugLibDetectRom.c | 48 +++
 .../PlatformDebugLibIoPort.inf |  1 +
 .../PlatformRomDebugLibIoPort.inf  | 52 
 OvmfPkg/OvmfPkgIa32.dsc|  2 +-
 OvmfPkg/OvmfPkgIa32X64.dsc |  2 +-
 OvmfPkg/OvmfPkgX64.dsc |  2 +-
 9 files changed, 237 insertions(+), 22 deletions(-)
 create mode 100644 OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.c
 create mode 100644 OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.h
 create mode 100644 OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetectRom.c
 create mode 100644 
OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf

-- 
2.14.3

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

[edk2] [PATCH 1/2] OvmfPkg: create a separate PlatformDebugLibIoPort instance for SEC

[Paolo Bonzini]

The next patch will want to add a global variable to
PlatformDebugLibIoPort, but this is not suitable for the SEC
phase, because SEC runs from read-only flash.  The solution is
to have two library instances, one for SEC and another
for all other firmware phases.  This patch adds the "plumbing"
for the SEC library instance, separating the INF files and
moving the constructor to a separate C source file.

Contributed-under: TianoCore Contribution Agreement 1.1
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Jordan Justen (Intel address) 
Signed-off-by: Paolo Bonzini 
---
 OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c  | 15 ---
 .../PlatformDebugLibIoPort/DebugLibDetect.c| 32 +
 .../PlatformDebugLibIoPort/DebugLibDetectRom.c | 32 +
 .../PlatformDebugLibIoPort.inf |  1 +
 .../PlatformRomDebugLibIoPort.inf  | 52 ++
 OvmfPkg/OvmfPkgIa32.dsc|  2 +-
 OvmfPkg/OvmfPkgIa32X64.dsc |  2 +-
 OvmfPkg/OvmfPkgX64.dsc |  2 +-
 8 files changed, 120 insertions(+), 18 deletions(-)
 create mode 100644 OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.c
 create mode 100644 OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetectRom.c
 create mode 100644 
OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf

diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c 
b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
index 5435767c1c..a5572a8eeb 100644
--- a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
+++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
@@ -29,21 +29,6 @@
 //
 #define MAX_DEBUG_MESSAGE_LENGTH  0x100
 
-/**
-  This constructor function does not have to do anything.
-
-  @retval EFI_SUCCESS   The constructor always returns RETURN_SUCCESS.
-
-**/
-RETURN_STATUS
-EFIAPI
-PlatformDebugLibIoPortConstructor (
-  VOID
-  )
-{
-  return EFI_SUCCESS;
-}
-
 /**
   Prints a debug message to the debug output device if the specified error 
level is enabled.
 
diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.c 
b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.c
new file mode 100644
index 00..fee908861b
--- /dev/null
+++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetect.c
@@ -0,0 +1,32 @@
+/** @file
+  Constructor code for QEMU debug port library.
+  Non-SEC instance.
+
+  Copyright (c) 2017, Red Hat, Inc.
+  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.
+
+**/
+
+#include 
+#include 
+
+/**
+  This constructor function does not have anything to do.
+
+  @retval EFI_SUCCESS   The constructor always returns RETURN_SUCCESS.
+
+**/
+RETURN_STATUS
+EFIAPI
+PlatformDebugLibIoPortConstructor (
+  VOID
+  )
+{
+  return EFI_SUCCESS;
+}
diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetectRom.c 
b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetectRom.c
new file mode 100644
index 00..407fe613ff
--- /dev/null
+++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLibDetectRom.c
@@ -0,0 +1,32 @@
+/** @file
+  Constructor code for QEMU debug port library.
+  SEC instance.
+
+  Copyright (c) 2017, Red Hat, Inc.
+  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.
+
+**/
+
+#include 
+#include 
+
+/**
+  This constructor function does not have to do anything.
+
+  @retval EFI_SUCCESS   The constructor always returns RETURN_SUCCESS.
+
+**/
+RETURN_STATUS
+EFIAPI
+PlatformRomDebugLibIoPortConstructor (
+  VOID
+  )
+{
+  return EFI_SUCCESS;
+}
diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf 
b/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
index 0e74fe94cb..65d8683f1f 100644
--- a/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
+++ b/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
@@ -30,6 +30,7 @@
 
 [Sources]
   DebugLib.c
+  DebugLibDetect.c
 
 [Packages]
   MdePkg/MdePkg.dec
diff --git 
a/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf 
b/OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf
new file mode 100644
index 

Re: [edk2] [PATCH v2] MdeModulePkg/UfsBlockIoPei: Support IoMmu

[Zeng, Star]

How about calling IoMmuInit () after locating gEdkiiPeiUfsHostControllerPpiGuid?

Same comment to SdBlockIoPei and EmmcBlockIoPei.

If you agree, Reviewed-by: Star Zeng 

Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Hao Wu
Sent: Tuesday, October 31, 2017 11:18 AM
To: edk2-devel@lists.01.org
Cc: Wu, Hao A ; Yao, Jiewen ; Zeng, 
Star 
Subject: [edk2] [PATCH v2] MdeModulePkg/UfsBlockIoPei: Support IoMmu

V2 changes:
Resource cleanup logic update in UfsEndOfPei().

V1 history:
Update the UfsBlockIoPei driver to consume IOMMU_PPI to allocate DMA buffer.

If no IOMMU_PPI exists, this driver still calls PEI service to allocate DMA 
buffer, with assumption that DRAM==DMA.

This is a compatible change.

Cc: Star Zeng 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Bus/Ufs/UfsBlockIoPei/DmaMem.c  | 249 
 MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsBlockIoPei.c   |  60 -
 MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsBlockIoPei.h   | 141 ++-
 MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsBlockIoPei.inf |   5 +-
 MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsHcMem.c|  23 +-
 MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsHcMem.h|   4 +-
 MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsHci.c  |  91 +--
 7 files changed, 535 insertions(+), 38 deletions(-)

diff --git a/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/DmaMem.c 
b/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/DmaMem.c
new file mode 100644
index 00..0a939a3879
--- /dev/null
+++ b/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/DmaMem.c
@@ -0,0 +1,249 @@
+/** @file
+  The DMA memory help function.
+
+  Copyright (c) 2017, 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.
+
+**/
+
+#include "UfsBlockIoPei.h"
+
+EDKII_IOMMU_PPI  *mIoMmu;
+
+/**
+  Provides the controller-specific addresses required to access system 
+memory from a
+  DMA bus master.
+
+  @param  Operation Indicates if the bus master is going to read 
or write to system memory.
+  @param  HostAddress   The system memory address to map to the PCI 
controller.
+  @param  NumberOfBytes On input the number of bytes to map. On output 
the number of bytes
+that were mapped.
+  @param  DeviceAddress The resulting map address for the bus master 
PCI controller to use to
+access the hosts HostAddress.
+  @param  Mapping   A resulting value to pass to Unmap().
+
+  @retval EFI_SUCCESS   The range was mapped for the returned 
NumberOfBytes.
+  @retval EFI_UNSUPPORTED   The HostAddress cannot be mapped as a common 
buffer.
+  @retval EFI_INVALID_PARAMETER One or more parameters are invalid.
+  @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a 
lack of resources.
+  @retval EFI_DEVICE_ERROR  The system hardware could not map the 
requested address.
+
+**/
+EFI_STATUS
+IoMmuMap (
+  IN  EDKII_IOMMU_OPERATION Operation,
+  IN VOID   *HostAddress,
+  IN  OUT UINTN *NumberOfBytes,
+  OUT EFI_PHYSICAL_ADDRESS  *DeviceAddress,
+  OUT VOID  **Mapping
+  )
+{
+  EFI_STATUS  Status;
+  UINT64  Attribute;
+
+  if (mIoMmu != NULL) {
+Status = mIoMmu->Map (
+   mIoMmu,
+   Operation,
+   HostAddress,
+   NumberOfBytes,
+   DeviceAddress,
+   Mapping
+   );
+if (EFI_ERROR (Status)) {
+  return EFI_OUT_OF_RESOURCES;
+}
+switch (Operation) {
+case EdkiiIoMmuOperationBusMasterRead:
+case EdkiiIoMmuOperationBusMasterRead64:
+  Attribute = EDKII_IOMMU_ACCESS_READ;
+  break;
+case EdkiiIoMmuOperationBusMasterWrite:
+case EdkiiIoMmuOperationBusMasterWrite64:
+  Attribute = EDKII_IOMMU_ACCESS_WRITE;
+  break;
+case EdkiiIoMmuOperationBusMasterCommonBuffer:
+case EdkiiIoMmuOperationBusMasterCommonBuffer64:
+  Attribute = EDKII_IOMMU_ACCESS_READ | EDKII_IOMMU_ACCESS_WRITE;
+  break;
+default:
+  ASSERT(FALSE);
+  return EFI_INVALID_PARAMETER;
+}
+Status = mIoMmu->SetAttribute (
+   mIoMmu,
+   *Mapping,
+   Attribute
+   );
+if (EFI_ERROR (Status)) {

Re: [edk2] [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

[Zeng, Star]

As I remember UEFI 2.5 clarified this and added EFI_MEMORY_RO was because 
EFI_MEMORY_WP had been typically used for cache even before UEFI 2.5.

And I do not think this patch should filter out EFI_MEMORY_WP since this patch 
is to filter out new paging bits caused by 
14dde9e903bb9a719ebb8f3381da72b19509bc36 [MdeModulePkg/Core: Fix out-of-sync 
issue in GCD].


Thanks,
Star
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] 
Sent: Thursday, November 16, 2017 5:30 PM
To: Zeng, Star 
Cc: Wang, Jian J ; Laszlo Ersek ; 
edk2-devel@lists.01.org; Yao, Jiewen 
Subject: Re: [edk2] [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging 
capabilities

On 16 November 2017 at 09:28, Zeng, Star  wrote:
> Ard,
>
> EFI_MEMORY_WP is for cache.
>
> UefiSpec.h
> //
> // Note: UEFI spec 2.5 and following: use EFI_MEMORY_RO as 
> write-protected physical memory // protection attribute. Also, EFI_MEMORY_WP 
> means cacheability attribute.
> //
> #define EFI_MEMORY_WP   0x1000ULL
>

Yes, but that was a change in v2.5, before that it was a permission attribute. 
So it should be filtered from the OS visible memory map as well.

> Thanks,
> Star
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, November 16, 2017 5:25 PM
> To: Wang, Jian J 
> Cc: edk2-devel@lists.01.org; Yao, Jiewen ; Zeng, 
> Star ; Laszlo Ersek 
> Subject: Re: [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all 
> paging capabilities
>
> On 16 November 2017 at 07:26, Jian J Wang  wrote:
>> Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really set 
>> attributes and change memory paging attribute accordingly.
>> But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by value from 
>> Capabilities in GCD memory map. This might cause boot problems.
>> Clearing all paging related capabilities can workaround it. The code 
>> added in this patch is supposed to be removed once the usage of 
>> EFI_MEMORY_DESCRIPTOR.Attribute is clarified in UEFI spec and adopted 
>> by both EDK-II Core and all supported OSs.
>>
>> Cc: Jiewen Yao 
>> Cc: Star Zeng 
>> Cc: Laszlo Ersek 
>> Cc: Ard Biesheuvel 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Jian J Wang 
>> ---
>>  MdeModulePkg/Core/Dxe/Mem/Page.c | 17 +
>>  1 file changed, 17 insertions(+)
>>
>> diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c
>> b/MdeModulePkg/Core/Dxe/Mem/Page.c
>> index c9219cc068..783b576e35 100644
>> --- a/MdeModulePkg/Core/Dxe/Mem/Page.c
>> +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
>> @@ -1829,6 +1829,23 @@ CoreGetMemoryMap (
>>//
>>BufferSize = ((UINT8 *)MemoryMap - (UINT8 *)MemoryMapStart);
>>
>> +  //
>> +  // WORKAROUND: Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as 
>> really
>> +  // set attributes and change memory paging attribute 
>> accordingly.
>> +  // But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
>> +  // value from Capabilities in GCD memory map. This might cause
>> +  // boot problems. Clearing all paging related capabilities can
>> +  // workaround it. Following code is supposed to be removed 
>> once
>> +  // the usage of EFI_MEMORY_DESCRIPTOR.Attribute is clarified 
>> in
>> +  // UEFI spec and adopted by both EDK-II Core and all supported
>> +  // OSs.
>> +  //
>> +  while (MemoryMapStart < MemoryMap) {
>> +MemoryMapStart->Attribute &= ~(UINT64)(EFI_MEMORY_RP | EFI_MEMORY_RO |
>> +   EFI_MEMORY_XP);
>
> Why is EFI_MEMORY_WP missing here?
>
>> +MemoryMapStart = NEXT_MEMORY_DESCRIPTOR(MemoryMapStart, Size);  
>> + }
>> +
>>Status = EFI_SUCCESS;
>>
>>  Done:
>> --
>> 2.14.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] ArmVirtPkg: remove ArmPlatformSysConfigLib dependency

[Ard Biesheuvel]

On 15 November 2017 at 14:03, Ard Biesheuvel  wrote:
> Now that the PL031 RTC driver library no longer depends on the ARM
> platform specific ArmPlatformSysConfigLib, we no longer need to
> implement ArmPlatform.h or have a resolution for that library.
> This allows us to get rid of a rather dodgy practice of including
> platform headers using compiler flags, which is a bad idea at various
> levels.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
> PL031 patch is on-list and pending.
>
>  ArmVirtPkg/ArmVirtQemu.dsc |  7 -
>  ArmVirtPkg/ArmVirtQemuKernel.dsc   |  6 
>  ArmVirtPkg/ArmVirtXen.dsc  |  6 
>  ArmVirtPkg/Include/ArmPlatform.h   | 33 
> 
>  ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/QemuVirtMem.c |  1 -
>  ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/RelocatableVirt.c |  1 -
>  ArmVirtPkg/Library/ArmVirtPlatformLib/Virt.c   |  1 -
>  ArmVirtPkg/Library/ArmVirtPlatformLib/VirtMem.c|  1 -
>  ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/RelocatableVirt.c  |  1 -
>  ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/XenVirtMem.c   |  1 -
>  ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c   |  7 -
>  11 files changed, 6 insertions(+), 59 deletions(-)
>
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index 8a60b61f2aa6..d1b3849d856a 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -49,7 +49,6 @@ [LibraryClasses.common]
>QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/BaseQemuFwCfgS3LibNull.inf
>
>ArmPlatformLib|ArmVirtPkg/Library/ArmVirtPlatformLib/ArmVirtPlatformLib.inf
> -  
> ArmPlatformSysConfigLib|ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.inf
>
>TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
>NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
> @@ -71,12 +70,6 @@ [LibraryClasses.common]
>  [LibraryClasses.common.UEFI_DRIVER]
>UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
>
> -[BuildOptions]
> -  RVCT:*_*_ARM_PLATFORM_FLAGS == --cpu Cortex-A15 
> -I$(WORKSPACE)/ArmVirtPkg/Include
> -  GCC:*_*_ARM_PLATFORM_FLAGS == -mcpu=cortex-a15 
> -I$(WORKSPACE)/ArmVirtPkg/Include

Oops. I will need to retain the -mcpu setting here, or the 'hvc'
instruction will be rejected by the assembler.

> -  *_*_AARCH64_PLATFORM_FLAGS == -I$(WORKSPACE)/ArmVirtPkg/Include
> -
> -
>  
> 
>  #
>  # Pcd Section - list of all EDK II PCD Entries defined by this Platform
> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc 
> b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> index 9a31ec93ca06..c7058718b0a6 100644
> --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
> +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> @@ -49,7 +49,6 @@ [LibraryClasses.common]
>QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/BaseQemuFwCfgS3LibNull.inf
>
>
> ArmPlatformLib|ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/ArmQemuRelocatablePlatformLib.inf
> -  
> ArmPlatformSysConfigLib|ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.inf
>
>TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
>NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
> @@ -71,11 +70,6 @@ [LibraryClasses.common]
>  [LibraryClasses.common.UEFI_DRIVER]
>UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
>
> -[BuildOptions]
> -  RVCT:*_*_ARM_PLATFORM_FLAGS == --cpu Cortex-A15 
> -I$(WORKSPACE)/ArmVirtPkg/Include
> -  GCC:*_*_ARM_PLATFORM_FLAGS == -mcpu=cortex-a15 
> -I$(WORKSPACE)/ArmVirtPkg/Include
> -  *_*_AARCH64_PLATFORM_FLAGS == -I$(WORKSPACE)/ArmVirtPkg/Include
> -
>  [BuildOptions.ARM.EDKII.SEC, BuildOptions.ARM.EDKII.BASE]
># Avoid MOVT/MOVW instruction pairs in code that may end up in the PIE
># executable we build for the relocatable PrePi. They are not runtime
> diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
> index e9437066ca56..7a443483d1ac 100644
> --- a/ArmVirtPkg/ArmVirtXen.dsc
> +++ b/ArmVirtPkg/ArmVirtXen.dsc
> @@ -44,7 +44,6 @@ [LibraryClasses]
>
> VirtioMmioDeviceLib|OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
>
>
> ArmPlatformLib|ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/ArmXenRelocatablePlatformLib.inf
> -  
> ArmPlatformSysConfigLib|ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.inf
>
>TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
>
> @@ -56,11 +55,6 @@ [LibraryClasses]
>  [LibraryClasses.common.UEFI_DRIVER]
>UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
>
> -[BuildOptions]
> -  

Re: [edk2] [PATCH] ArmVirtPkg/ArmVirtQemu: use non-accelerated CopyMem for VariableRuntimeDxe

[Ard Biesheuvel]

On 16 November 2017 at 01:01, Shannon Zhao  wrote:
>
>
> On 2017/11/15 22:03, Ard Biesheuvel wrote:
>> On 15 November 2017 at 13:51, Laszlo Ersek  wrote:
>>> > On 11/14/17 11:22, Ard Biesheuvel wrote:
 >> The VariableRuntimeDxe driver may use CopyMem () on NOR flash regions,
 >> assuming such regions always have full memory semantics. Given that
 >> those regions cannot be mapped as ordinary memory on ARM (due to the
 >> fact that the NOR flash requires device semantics while in write mode)
 >> this prevents us from using BaseMemoryLibOptDxe in VariableRuntimeDxe,
 >> since it may use unaligned accesses and/or DC ZVA instructions, both
 >> of which are incompatible with mappings using device semantics.
 >>
 >> Note that there is no way we can work around this by changing the
 >> mapping type between 'memory' and 'device' when switching from read to
 >> write mode and back, because the runtime mapping is created by the OS,
 >> and cannot be changed at will.
 >>
 >> So let's just switch to the unaccelerated version of BaseMemoryLib which
 >> does not have the same problem.
 >>
 >> Contributed-under: TianoCore Contribution Agreement 1.1
 >> Signed-off-by: Ard Biesheuvel 
 >> ---
 >>  ArmVirtPkg/ArmVirtQemu.dsc   | 2 ++
 >>  ArmVirtPkg/ArmVirtQemuKernel.dsc | 2 ++
 >>  2 files changed, 4 insertions(+)
 >>
 >> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
 >> index 8a60b61f2aa6..7b220d6e3c31 100644
 >> --- a/ArmVirtPkg/ArmVirtQemu.dsc
 >> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
 >> @@ -261,6 +261,8 @@ [Components.common]
 >>MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
 >>  
 >>NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
 >> +  # don't use unaligned CopyMem () on the UEFI varstore NOR flash 
 >> region
 >> +  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
 >>}
 >>  !if $(SECURE_BOOT_ENABLE) == TRUE
 >>MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
 >> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc 
 >> b/ArmVirtPkg/ArmVirtQemuKernel.dsc
 >> index 9a31ec93ca06..7c032e1b07e0 100644
 >> --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
 >> +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
 >> @@ -252,6 +252,8 @@ [Components.common]
 >>MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
 >>  
 >>NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
 >> +  # don't use unaligned CopyMem () on the UEFI varstore NOR flash 
 >> region
 >> +  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
 >>}
 >>  !if $(SECURE_BOOT_ENABLE) == TRUE
 >>MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
 >>
>>> >
>>> > Reviewed-by: Laszlo Ersek 
>>> >
>>> > Given that we've never seen the symptom reported by Shannon, I must
>>> > think Shannon is using some kind of new hardware. May I ask what
>>> > hardware that is?
>>> >
>> I think this is equally likely to occur in any KVM hardware
>> virtualization context. It is simply a regression after moving to the
>> OptDxe BaseMemoryLib flavor.
>
> Exactly. I'm using Huawei D05. It works well when I use a older edk2
> while fails when updating to UDK2017 branch.
>
> Tested-by: Shannon Zhao 
>

Pushed as 44d71c217ccb

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

Re: [edk2] [PATCH v2 3/4] OvmfPkg/Sec/X64: seed the temporary RAM with PcdInitValueInTempStack

[Ard Biesheuvel]

On 15 November 2017 at 21:57, Laszlo Ersek  wrote:
> This allows the PEI core to report the maximum temporary SEC/PEI stack
> usage on the DEBUG_INFO level, in the PeiCheckAndSwitchStack() function
> [MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c]:
>
> * Normal boot:
>
>> Temp Stack : BaseAddress=0x814000 Length=0x4000
>> Temp Heap  : BaseAddress=0x81 Length=0x4000
>> Total temporary memory:32768 bytes.
>>   temporary memory stack ever used:   5080 bytes. <
>>   temporary memory heap used for HobList: 8080 bytes.
>>   temporary memory heap occupied by memory pages: 0 bytes.
>
> * S3 resume (no SMM / PEI decompression)
>
>> Temp Stack : BaseAddress=0x814000 Length=0x4000
>> Temp Heap  : BaseAddress=0x81 Length=0x4000
>> Total temporary memory:32768 bytes.
>>   temporary memory stack ever used:   5048 bytes. <
>>   temporary memory heap used for HobList: 7112 bytes.
>>   temporary memory heap occupied by memory pages: 0 bytes.
>
> I unit-tested this change by transitorily adding an infinite loop right
> after the "rep stosq", and dumping the guest's temp SEC/PEI RAM (32KB
> currently) while the guest was stuck in the loop. The dump includes one
> dword from before and after the temp SEC/PEI RAM:
>
>> $ virsh qemu-monitor-command GUEST_NAME --hmp 'xp /8194wx 0x80FFFC'
>>
>> 0080fffc: 0x 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5
>> 0081000c: 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5
>> ...
>> 00817fec: 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5
>> 00817ffc: 0x5aa55aa5 0x
>
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=747
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek 

Reviewed-by: Ard Biesheuvel 

> ---
>
> Notes:
> v2:
> - update comment on ES [Jordan]
> - document the other segment registers too [Jordan]
> - move seeding to top of routine, for consistency with the IA32 version
> - replace runtime right shift with compile-time division [Jordan]
> - compose qword-to-write at compile-time, not at runtime
> - drop Ard's Reviewed-by
>
>  OvmfPkg/Sec/X64/SecEntry.nasm | 21 
>  1 file changed, 21 insertions(+)
>
> diff --git a/OvmfPkg/Sec/X64/SecEntry.nasm b/OvmfPkg/Sec/X64/SecEntry.nasm
> index f40427aa8e04..7c55032ac962 100644
> --- a/OvmfPkg/Sec/X64/SecEntry.nasm
> +++ b/OvmfPkg/Sec/X64/SecEntry.nasm
> @@ -30,12 +30,33 @@ extern ASM_PFX(SecCoreStartupWithStack)
>  ; @param[in]  RAX   Initial value of the EAX register (BIST: Built-in Self 
> Test)
>  ; @param[in]  DI'BP': boot-strap processor, or 'AP': application 
> processor
>  ; @param[in]  RBP   Pointer to the start of the Boot Firmware Volume
> +; @param[in]  DSSelector allowing flat access to all addresses
> +; @param[in]  ESSelector allowing flat access to all addresses
> +; @param[in]  FSSelector allowing flat access to all addresses
> +; @param[in]  GSSelector allowing flat access to all addresses
> +; @param[in]  SSSelector allowing flat access to all addresses
>  ;
>  ; @return None  This routine does not return
>  ;
>  global ASM_PFX(_ModuleEntryPoint)
>  ASM_PFX(_ModuleEntryPoint):
>
> +;
> +; Fill the temporary RAM with the initial stack value.
> +; The loop below will seed the heap as well, but that's harmless.
> +;
> +mov rax, (FixedPcdGet32 (\
> +PcdInitValueInTempStack  \
> +) << 32) |   \
> + FixedPcdGet32 (PcdInitValueInTempStack)  ; qword to 
> store
> +mov rdi, FixedPcdGet32 (PcdOvmfSecPeiTempRamBase) ; base address,
> +  ;   relative to
> +  ;   ES
> +mov rcx, FixedPcdGet32 (PcdOvmfSecPeiTempRamSize) / 8 ; qword count
> +cld   ; store from 
> base
> +  ;   up
> +rep stosq
> +
>  ;
>  ; Load temporary RAM stack based on PCDs
>  ;
> --
> 2.14.1.3.gb7cf6e02401b
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 2/4] OvmfPkg/Sec/Ia32: seed the temporary RAM with PcdInitValueInTempStack

[Ard Biesheuvel]

On 15 November 2017 at 21:57, Laszlo Ersek  wrote:
> This allows the PEI core to report the maximum temporary SEC/PEI stack
> usage on the DEBUG_INFO level, in the PeiCheckAndSwitchStack() function
> [MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c]:
>
> * Normal boot:
>
>> Temp Stack : BaseAddress=0x814000 Length=0x4000
>> Temp Heap  : BaseAddress=0x81 Length=0x4000
>> Total temporary memory:32768 bytes.
>>   temporary memory stack ever used:   3664 bytes. <
>>   temporary memory heap used for HobList: 5904 bytes.
>>   temporary memory heap occupied by memory pages: 0 bytes.
>
> * S3 resume (with PEI decompression / SMM):
>
>> Temp Stack : BaseAddress=0x814000 Length=0x4000
>> Temp Heap  : BaseAddress=0x81 Length=0x4000
>> Total temporary memory:32768 bytes.
>>   temporary memory stack ever used:   3428 bytes. <
>>   temporary memory heap used for HobList: 4816 bytes.
>>   temporary memory heap occupied by memory pages: 0 bytes.
>
> I unit-tested this change by transitorily adding an infinite loop right
> after the "rep stosd", and dumping the guest's temp SEC/PEI RAM (32KB
> currently) while the guest was stuck in the loop. The dump includes one
> dword from before and after the temp SEC/PEI RAM:
>
>> $ virsh qemu-monitor-command GUEST_NAME --hmp 'xp /8194wx 0x80FFFC'
>>
>> 0080fffc: 0x 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5
>> 0081000c: 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5
>> ...
>> 00817fec: 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5
>> 00817ffc: 0x5aa55aa5 0x
>
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=747
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek 

Reviewed-by: Ard Biesheuvel 

> ---
>
> Notes:
> v2:
> - update comment on ES [Jordan]
> - document the other segment registers too [Jordan]
> - move seeding to top of routine [Jordan]
> - hence, drop earlier EAX -> EBX renaming [Jordan]
> - replace runtime right shift with compile-time division [Jordan]
> - drop Ard's Reviewed-by
>
>  OvmfPkg/Sec/SecMain.inf|  1 +
>  OvmfPkg/Sec/Ia32/SecEntry.nasm | 18 ++
>  2 files changed, 19 insertions(+)
>
> diff --git a/OvmfPkg/Sec/SecMain.inf b/OvmfPkg/Sec/SecMain.inf
> index 711b59530907..6051cb3c6c4c 100644
> --- a/OvmfPkg/Sec/SecMain.inf
> +++ b/OvmfPkg/Sec/SecMain.inf
> @@ -71,6 +71,7 @@ [Pcd]
>gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
>gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdInitValueInTempStack
>
>  [FeaturePcd]
>gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
> diff --git a/OvmfPkg/Sec/Ia32/SecEntry.nasm b/OvmfPkg/Sec/Ia32/SecEntry.nasm
> index 7fee1c2b2e4f..03501969ebce 100644
> --- a/OvmfPkg/Sec/Ia32/SecEntry.nasm
> +++ b/OvmfPkg/Sec/Ia32/SecEntry.nasm
> @@ -29,12 +29,30 @@ extern ASM_PFX(SecCoreStartupWithStack)
>  ; @param[in]  EAX   Initial value of the EAX register (BIST: Built-in Self 
> Test)
>  ; @param[in]  DI'BP': boot-strap processor, or 'AP': application 
> processor
>  ; @param[in]  EBP   Pointer to the start of the Boot Firmware Volume
> +; @param[in]  DSSelector allowing flat access to all addresses
> +; @param[in]  ESSelector allowing flat access to all addresses
> +; @param[in]  FSSelector allowing flat access to all addresses
> +; @param[in]  GSSelector allowing flat access to all addresses
> +; @param[in]  SSSelector allowing flat access to all addresses
>  ;
>  ; @return None  This routine does not return
>  ;
>  global ASM_PFX(_ModuleEntryPoint)
>  ASM_PFX(_ModuleEntryPoint):
>
> +;
> +; Fill the temporary RAM with the initial stack value.
> +; The loop below will seed the heap as well, but that's harmless.
> +;
> +mov eax, FixedPcdGet32 (PcdInitValueInTempStack)  ; dword to 
> store
> +mov edi, FixedPcdGet32 (PcdOvmfSecPeiTempRamBase) ; base address,
> +  ;   relative to
> +  ;   ES
> +mov ecx, FixedPcdGet32 (PcdOvmfSecPeiTempRamSize) / 4 ; dword count
> +cld   ; store from 
> base
> +  ;   up
> +rep stosd
> +
>  ;
>  ; Load temporary RAM stack based on PCDs
>  ;
> --
> 2.14.1.3.gb7cf6e02401b
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 1/4] UefiCpuPkg/ResetVector/Vtf0: document segment register setup

[Ard Biesheuvel]

On 15 November 2017 at 21:57, Laszlo Ersek  wrote:
> "Main.asm" calls TransitionFromReal16To32BitFlat (and does some other
> things) before it jumps to the platform's SEC entry point.
>
> TransitionFromReal16To32BitFlat enters big real mode, and sets the DS, ES,
> FS, GS, and SS registers to offset ("selector") LINEAR_SEL in the GDT
> (defined in "UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm"). The
> GDT entry ("segment descriptor") at LINEAR_SEL defines a segment covering
> the full 32-bit address space, meant for "read/write data".
>
> Document this fact for all the affected segment registers, as output
> parameters for TransitionFromReal16To32BitFlat, saying "Selector allowing
> flat access to all addresses".
>
> For 64-bit SEC, "Main.asm" calls Transition32FlatTo64Flat in addition,
> between calling TransitionFromReal16To32BitFlat and jumping to the SEC
> entry point. Transition32FlatTo64Flat enters long mode. In long mode,
> segmentation is largely ignored:
>
> - all segments are considered flat (covering the whole 64-bit address
>   space),
>
> - with the (possible) exception of FS and GS, whose bases can still be
>   changed, albeit with new methods, not through the GDT. (Through the
>   IA32_FS_BASE and IA32_GS_BASE Model Specific Registers, and/or the
>   WRFSBASE, WRGSBASE and SWAPGS instructions.)
>
> Thus, document the segment registers with the same "Selector allowing flat
> access to all addresses" language on the "Main.asm" level too, since that
> is valid for both 32-bit and 64-bit modes.
>
> (Technically, "Main.asm" does not return, but RBP/EBP, passed similarly to
> the SEC entry point, is already documented as an output parameter.)
>
> Cc: Ard Biesheuvel 
> Cc: Eric Dong 
> Cc: Jordan Justen 
> Suggested-by: Jordan Justen 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek 

Acked-by: Ard Biesheuvel 

> ---
>
> Notes:
> v2:
> - new patch [Jordan]
>
>  UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm | 6 ++
>  UefiCpuPkg/ResetVector/Vtf0/Main.asm| 5 +
>  2 files changed, 11 insertions(+)
>
> diff --git a/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm 
> b/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm
> index 146df600a63b..bc68c8dd749a 100644
> --- a/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm
> +++ b/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm
> @@ -21,6 +21,12 @@ BITS16
>  ;
>  ; Modified:  EAX, EBX
>  ;
> +; @param[out] DS   Selector allowing flat access to all addresses
> +; @param[out] ES   Selector allowing flat access to all addresses
> +; @param[out] FS   Selector allowing flat access to all addresses
> +; @param[out] GS   Selector allowing flat access to all addresses
> +; @param[out] SS   Selector allowing flat access to all addresses
> +;
>  TransitionFromReal16To32BitFlat:
>
>  debugShowPostCode POSTCODE_16BIT_MODE
> diff --git a/UefiCpuPkg/ResetVector/Vtf0/Main.asm 
> b/UefiCpuPkg/ResetVector/Vtf0/Main.asm
> index ebfb9015d49c..57f080688b6f 100644
> --- a/UefiCpuPkg/ResetVector/Vtf0/Main.asm
> +++ b/UefiCpuPkg/ResetVector/Vtf0/Main.asm
> @@ -24,6 +24,11 @@ BITS16
>  ; @param[in,out]  DI   'BP': boot-strap processor, or
>  ;  'AP': application processor
>  ; @param[out] RBP/EBP  Address of Boot Firmware Volume (BFV)
> +; @param[out] DS   Selector allowing flat access to all addresses
> +; @param[out] ES   Selector allowing flat access to all addresses
> +; @param[out] FS   Selector allowing flat access to all addresses
> +; @param[out] GS   Selector allowing flat access to all addresses
> +; @param[out] SS   Selector allowing flat access to all addresses
>  ;
>  ; @return None  This routine jumps to SEC and does not return
>  ;
> --
> 2.14.1.3.gb7cf6e02401b
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

[Ard Biesheuvel]

On 16 November 2017 at 09:28, Zeng, Star  wrote:
> Ard,
>
> EFI_MEMORY_WP is for cache.
>
> UefiSpec.h
> //
> // Note: UEFI spec 2.5 and following: use EFI_MEMORY_RO as write-protected 
> physical memory
> // protection attribute. Also, EFI_MEMORY_WP means cacheability attribute.
> //
> #define EFI_MEMORY_WP   0x1000ULL
>

Yes, but that was a change in v2.5, before that it was a permission
attribute. So it should be filtered from the OS visible memory map as
well.

> Thanks,
> Star
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, November 16, 2017 5:25 PM
> To: Wang, Jian J 
> Cc: edk2-devel@lists.01.org; Yao, Jiewen ; Zeng, Star 
> ; Laszlo Ersek 
> Subject: Re: [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging 
> capabilities
>
> On 16 November 2017 at 07:26, Jian J Wang  wrote:
>> Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really set
>> attributes and change memory paging attribute accordingly.
>> But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by value from
>> Capabilities in GCD memory map. This might cause boot problems.
>> Clearing all paging related capabilities can workaround it. The code
>> added in this patch is supposed to be removed once the usage of
>> EFI_MEMORY_DESCRIPTOR.Attribute is clarified in UEFI spec and adopted
>> by both EDK-II Core and all supported OSs.
>>
>> Cc: Jiewen Yao 
>> Cc: Star Zeng 
>> Cc: Laszlo Ersek 
>> Cc: Ard Biesheuvel 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Jian J Wang 
>> ---
>>  MdeModulePkg/Core/Dxe/Mem/Page.c | 17 +
>>  1 file changed, 17 insertions(+)
>>
>> diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c
>> b/MdeModulePkg/Core/Dxe/Mem/Page.c
>> index c9219cc068..783b576e35 100644
>> --- a/MdeModulePkg/Core/Dxe/Mem/Page.c
>> +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
>> @@ -1829,6 +1829,23 @@ CoreGetMemoryMap (
>>//
>>BufferSize = ((UINT8 *)MemoryMap - (UINT8 *)MemoryMapStart);
>>
>> +  //
>> +  // WORKAROUND: Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as 
>> really
>> +  // set attributes and change memory paging attribute 
>> accordingly.
>> +  // But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
>> +  // value from Capabilities in GCD memory map. This might cause
>> +  // boot problems. Clearing all paging related capabilities can
>> +  // workaround it. Following code is supposed to be removed 
>> once
>> +  // the usage of EFI_MEMORY_DESCRIPTOR.Attribute is clarified 
>> in
>> +  // UEFI spec and adopted by both EDK-II Core and all supported
>> +  // OSs.
>> +  //
>> +  while (MemoryMapStart < MemoryMap) {
>> +MemoryMapStart->Attribute &= ~(UINT64)(EFI_MEMORY_RP | EFI_MEMORY_RO |
>> +   EFI_MEMORY_XP);
>
> Why is EFI_MEMORY_WP missing here?
>
>> +MemoryMapStart = NEXT_MEMORY_DESCRIPTOR(MemoryMapStart, Size);  }
>> +
>>Status = EFI_SUCCESS;
>>
>>  Done:
>> --
>> 2.14.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 v6 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

[Zeng, Star]

Ard,

EFI_MEMORY_WP is for cache.

UefiSpec.h
//
// Note: UEFI spec 2.5 and following: use EFI_MEMORY_RO as write-protected 
physical memory
// protection attribute. Also, EFI_MEMORY_WP means cacheability attribute.
//
#define EFI_MEMORY_WP   0x1000ULL

Thanks,
Star
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] 
Sent: Thursday, November 16, 2017 5:25 PM
To: Wang, Jian J 
Cc: edk2-devel@lists.01.org; Yao, Jiewen ; Zeng, Star 
; Laszlo Ersek 
Subject: Re: [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging 
capabilities

On 16 November 2017 at 07:26, Jian J Wang  wrote:
> Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really set 
> attributes and change memory paging attribute accordingly.
> But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by value from 
> Capabilities in GCD memory map. This might cause boot problems. 
> Clearing all paging related capabilities can workaround it. The code 
> added in this patch is supposed to be removed once the usage of 
> EFI_MEMORY_DESCRIPTOR.Attribute is clarified in UEFI spec and adopted 
> by both EDK-II Core and all supported OSs.
>
> Cc: Jiewen Yao 
> Cc: Star Zeng 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  MdeModulePkg/Core/Dxe/Mem/Page.c | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c 
> b/MdeModulePkg/Core/Dxe/Mem/Page.c
> index c9219cc068..783b576e35 100644
> --- a/MdeModulePkg/Core/Dxe/Mem/Page.c
> +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
> @@ -1829,6 +1829,23 @@ CoreGetMemoryMap (
>//
>BufferSize = ((UINT8 *)MemoryMap - (UINT8 *)MemoryMapStart);
>
> +  //
> +  // WORKAROUND: Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as 
> really
> +  // set attributes and change memory paging attribute 
> accordingly.
> +  // But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
> +  // value from Capabilities in GCD memory map. This might cause
> +  // boot problems. Clearing all paging related capabilities can
> +  // workaround it. Following code is supposed to be removed once
> +  // the usage of EFI_MEMORY_DESCRIPTOR.Attribute is clarified in
> +  // UEFI spec and adopted by both EDK-II Core and all supported
> +  // OSs.
> +  //
> +  while (MemoryMapStart < MemoryMap) {
> +MemoryMapStart->Attribute &= ~(UINT64)(EFI_MEMORY_RP | EFI_MEMORY_RO |
> +   EFI_MEMORY_XP);

Why is EFI_MEMORY_WP missing here?

> +MemoryMapStart = NEXT_MEMORY_DESCRIPTOR(MemoryMapStart, Size);  }
> +
>Status = EFI_SUCCESS;
>
>  Done:
> --
> 2.14.1.windows.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

[Ard Biesheuvel]

On 16 November 2017 at 07:26, Jian J Wang  wrote:
> Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really
> set attributes and change memory paging attribute accordingly.
> But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
> value from Capabilities in GCD memory map. This might cause
> boot problems. Clearing all paging related capabilities can
> workaround it. The code added in this patch is supposed to
> be removed once the usage of EFI_MEMORY_DESCRIPTOR.Attribute
> is clarified in UEFI spec and adopted by both EDK-II Core and
> all supported OSs.
>
> Cc: Jiewen Yao 
> Cc: Star Zeng 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  MdeModulePkg/Core/Dxe/Mem/Page.c | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c 
> b/MdeModulePkg/Core/Dxe/Mem/Page.c
> index c9219cc068..783b576e35 100644
> --- a/MdeModulePkg/Core/Dxe/Mem/Page.c
> +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
> @@ -1829,6 +1829,23 @@ CoreGetMemoryMap (
>//
>BufferSize = ((UINT8 *)MemoryMap - (UINT8 *)MemoryMapStart);
>
> +  //
> +  // WORKAROUND: Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as 
> really
> +  // set attributes and change memory paging attribute 
> accordingly.
> +  // But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
> +  // value from Capabilities in GCD memory map. This might cause
> +  // boot problems. Clearing all paging related capabilities can
> +  // workaround it. Following code is supposed to be removed once
> +  // the usage of EFI_MEMORY_DESCRIPTOR.Attribute is clarified in
> +  // UEFI spec and adopted by both EDK-II Core and all supported
> +  // OSs.
> +  //
> +  while (MemoryMapStart < MemoryMap) {
> +MemoryMapStart->Attribute &= ~(UINT64)(EFI_MEMORY_RP | EFI_MEMORY_RO |
> +   EFI_MEMORY_XP);

Why is EFI_MEMORY_WP missing here?

> +MemoryMapStart = NEXT_MEMORY_DESCRIPTOR(MemoryMapStart, Size);
> +  }
> +
>Status = EFI_SUCCESS;
>
>  Done:
> --
> 2.14.1.windows.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch] BaseTools: Guid.xref contain information from FILE statements in FDF

[Yonghong Zhu]

Update Guid.xref to contain information from FILE statements in FDF
file.

Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=778
Cc: Liming Gao 
Cc: Dmitry Antipov 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/GenFds/GenFds.py | 88 +++-
 1 file changed, 86 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/Python/GenFds/GenFds.py 
b/BaseTools/Source/Python/GenFds/GenFds.py
index 277da35..c19dc40 100644
--- a/BaseTools/Source/Python/GenFds/GenFds.py
+++ b/BaseTools/Source/Python/GenFds/GenFds.py
@@ -40,10 +40,13 @@ from Common.Misc import ClearDuplicatedInf
 from Common.Misc import GuidStructureStringToGuidString
 from Common.Misc import CheckPcdDatum
 from Common.Misc import BuildOptionPcdValueFormat
 from Common.BuildVersion import gBUILD_VERSION
 from Common.MultipleWorkspace import MultipleWorkspace as mws
+import FfsFileStatement
+import glob
+from struct import unpack
 
 ## Version and Copyright
 versionNumber = "1.0" + ' ' + gBUILD_VERSION
 __version__ = "%prog Version " + versionNumber
 __copyright__ = "Copyright (c) 2007 - 2017, Intel Corporation  All rights 
reserved."
@@ -325,11 +328,11 @@ def main():
 
 """Call GenFds"""
 GenFds.GenFd('', FdfParserObj, BuildWorkSpace, ArchList)
 
 """Generate GUID cross reference file"""
-GenFds.GenerateGuidXRefFile(BuildWorkSpace, ArchList)
+GenFds.GenerateGuidXRefFile(BuildWorkSpace, ArchList, FdfParserObj)
 
 """Display FV space info."""
 GenFds.DisplayFvSpaceInfo(FdfParserObj)
 
 except FdfParser.Warning, X:
@@ -722,25 +725,106 @@ class GenFds :
 ModuleDict = BuildDb.BuildObject[DscFile, 'COMMON', 
GenFdsGlobalVariable.TargetName, GenFdsGlobalVariable.ToolChainTag].Modules
 for Key in ModuleDict:
 ModuleObj = BuildDb.BuildObject[Key, 'COMMON', 
GenFdsGlobalVariable.TargetName, GenFdsGlobalVariable.ToolChainTag]
 print ModuleObj.BaseName + ' ' + ModuleObj.ModuleType
 
-def GenerateGuidXRefFile(BuildDb, ArchList):
+def GenerateGuidXRefFile(BuildDb, ArchList, FdfParserObj):
 GuidXRefFileName = os.path.join(GenFdsGlobalVariable.FvDir, 
"Guid.xref")
 GuidXRefFile = StringIO.StringIO('')
 GuidDict = {}
+ModuleList = []
+FileGuidList = []
 for Arch in ArchList:
 PlatformDataBase = 
BuildDb.BuildObject[GenFdsGlobalVariable.ActivePlatform, Arch, 
GenFdsGlobalVariable.TargetName, GenFdsGlobalVariable.ToolChainTag]
 for ModuleFile in PlatformDataBase.Modules:
 Module = BuildDb.BuildObject[ModuleFile, Arch, 
GenFdsGlobalVariable.TargetName, GenFdsGlobalVariable.ToolChainTag]
+if Module in ModuleList:
+continue
+else:
+ModuleList.append(Module)
 GuidXRefFile.write("%s %s\n" % (Module.Guid, Module.BaseName))
 for key, item in Module.Protocols.items():
 GuidDict[key] = item
 for key, item in Module.Guids.items():
 GuidDict[key] = item
 for key, item in Module.Ppis.items():
 GuidDict[key] = item
+for FvName in FdfParserObj.Profile.FvDict:
+for FfsObj in FdfParserObj.Profile.FvDict[FvName].FfsList:
+if not isinstance(FfsObj, FfsFileStatement.FileStatement):
+InfPath = 
PathClass(NormPath(mws.join(GenFdsGlobalVariable.WorkSpaceDir, 
FfsObj.InfFileName)))
+FdfModule = BuildDb.BuildObject[InfPath, Arch, 
GenFdsGlobalVariable.TargetName, GenFdsGlobalVariable.ToolChainTag]
+if FdfModule in ModuleList:
+continue
+else:
+ModuleList.append(FdfModule)
+GuidXRefFile.write("%s %s\n" % (FdfModule.Guid, 
FdfModule.BaseName))
+for key, item in FdfModule.Protocols.items():
+GuidDict[key] = item
+for key, item in FdfModule.Guids.items():
+GuidDict[key] = item
+for key, item in FdfModule.Ppis.items():
+GuidDict[key] = item
+else:
+FileStatementGuid = FfsObj.NameGuid
+if FileStatementGuid in FileGuidList:
+continue
+else:
+FileGuidList.append(FileStatementGuid)
+Name = []
+FfsPath = os.path.join(GenFdsGlobalVariable.FvDir, 
'Ffs')
+FfsPath = glob.glob(os.path.join(FfsPath, 
FileStatementGuid) + '*')
+if not FfsPath:
+   

[edk2] SCT Test crashes After HTTPS boot success.

[Karunakar P]

Hello All,

When I do SCT test, get the below failure
GenericTest\EFICompliantTest 0 0 CB6F7B77-0B15-43F7-A95B-8C7F9FD70B21 FAIL UEFI 
Compliant - TLS support is required

The reason for the failure is that the platform doesn't have TLS related 
protocols installed.

->if the platform supports TLS feature then, EFI_TLS_PROTOCOL, 
EFI_TLS_SERVICE_BINDING_PROTOCOL, EFI_TLS_CONFIGURATION_PROTOCOL must be 
existed.
-> According UEFI2.7 Spec - 28.10 EFI TLS Protocols(page-1787)
The TLS consumer need locate EFI_TLS_SERVICE_BINDING_PROTOCOL and call 
CreateChild() to create a new child of EFI_TLS_PROTOCOL instance. Then use 
EFI_TLS_PROTOCOL to start TLS session. After use, the TLS consumer need call 
DestroyChild() to destroy it.
-> Network Stack follows same in HTTPS boot.
While doing IPv4/6 HTTPS boot , will locate gEfiTlsServiceBindingProtocolGuid 
and call TlsServiceBindingCreateChild, So that EFI_TLS_PROTOCOL and 
EFI_TLS_CONFIGURATION_PROTOCOL will be installed.

So once HTTPS boot is success then TLS supported protocols exist.

And if we do SCT test after HTTPS boot is success, Then TLS related failures 
should NOT happen in SCT.

I've tried SCT test after HTTPS boot success, But SCT test Crashes.

[Steps to reproduce]

1.   Configure the HTTPS Server with EFI Shell as NBP file.

2.   Connect test machine and HTTPS server with LAN cable.

3.   Perform HTTPS boot in test machine

4.   Once HTTPS boot is success, It will launch Shell.

5.   Run SCT test


[Observations]

1.   SCT test was crashed and unable to continue the test.

Could you please provide your comments/Suggestion on this?


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