Re: [edk2] [PATCH v4 0/7] ResetSystemLib changings

[Gao, Liming]

Reviewed-by: Liming Gao 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Zhichao Gao
> Sent: Thursday, February 21, 2019 9:00 AM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: [edk2] [PATCH v4 0/7] ResetSystemLib changings
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1460
> Add a new API ResetSystem in ResetSystemLib.
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1461
> Implement a runtime library instance of ResetSystemLib base on the new 
> changing.
> 
> V2: Add some required data type header file
> 
> V3: Resolve a case-typing error.
> 
> V4: Change the ResetSystemRuntimeDxe/ResetSystem.c name to 
> RuntimeServiceResetSystem.
> Add a new interface for PEI version ResetSystemLib.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao 
> Cc: Ray Ni 
> Cc: Liming Gao 
> 
> Zhichao Gao (7):
>   MdeModulePkg: change the function name ResetSystem
>   MdeModulePkg: Add the new API ResetSystem in the head file
>   MdeModulePkg: Add a new API ResetSystem for DXE ResetSystemLib
>   MdeModulePkg: Add a new API ResetSystem for Null version
>   MdeModulePkg: Add a new API ResetSystem for PEI ResetSystemLib
>   MdeModulePkg: Add a runtime library instance of ResetSystemLib
>   MdeModulePkg: Add the runtime ResetSystemLib in MdeModulePkg.dsc
> 
>  MdeModulePkg/Include/Library/ResetSystemLib.h  |  28 ++-
>  .../BaseResetSystemLibNull.c   |  27 +++
>  .../Library/DxeResetSystemLib/DxeResetSystemLib.c  |  28 ++-
>  .../Library/PeiResetSystemLib/PeiResetSystemLib.c  |  28 ++-
>  .../RuntimeResetSystemLib/RuntimeResetSystemLib.c  | 216 
> +
>  .../RuntimeResetSystemLib.inf  |  50 +
>  .../RuntimeResetSystemLib.uni  |  21 ++
>  MdeModulePkg/MdeModulePkg.dsc  |   1 +
>  .../Universal/ResetSystemRuntimeDxe/ResetSystem.c  |   8 +-
>  .../Universal/ResetSystemRuntimeDxe/ResetSystem.h  |   4 +-
>  10 files changed, 402 insertions(+), 9 deletions(-)
>  create mode 100644 
> MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.c
>  create mode 100644 
> MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.inf
>  create mode 100644 
> MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.uni
> 
> --
> 2.16.2.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] BaseTools:Some build generated files content are not ordered on linux

[Feng, Bob C]

Reviewed-by: Bob Feng 

-Original Message-
From: Fan, ZhijuX 
Sent: Thursday, February 21, 2019 1:18 PM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Feng, Bob C 
Subject: [edk2][PATCH] BaseTools:Some build generated files content are not 
ordered on linux

If the WORKSPACE environment variable has been set,The variables that control 
stable sorting will not be set.

Cc: Bob Feng 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhiju.Fan 
---
 edksetup.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/edksetup.sh b/edksetup.sh
index a8897d10f8..39f62a29bd 100755
--- a/edksetup.sh
+++ b/edksetup.sh
@@ -49,6 +49,7 @@ function SetWorkspace()
   #
   # If WORKSPACE is already set, then we can return right now
   #
+  export PYTHONHASHSEED=1
   if [ -n "$WORKSPACE" ]
   then
 return 0
@@ -77,7 +78,6 @@ function SetWorkspace()
   # Set $WORKSPACE
   #
   export WORKSPACE=`pwd`
-  export PYTHONHASHSEED=1
   return 0
 }
 
--
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] BaseTools:Build fail if define [DEPEX] in library inf

[Feng, Bob C]

Reviewed-by: Bob Feng 

-Original Message-
From: Fan, ZhijuX 
Sent: Thursday, February 21, 2019 9:34 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Feng, Bob C 
Subject: [PATCH] BaseTools:Build fail if define [DEPEX] in library inf

When define [DEPEX] in lib inf to build, it will fail and report"
gUefiOvmfPkgTokenSpaceGuid.test1 used in [Depex] section should be used as 
FixedAtBuild type and VOID* datum type in the module."
But we define this PCD to FixedAtBuild type and VOID* datum type indeed.

DEC:
[PcdsFixedAtBuild]
gUefiOvmfPkgTokenSpaceGuid.test1 |
{GUID("4096267b-da0a-42eb-b5eb-fef31d207cb4")}|VOID*|0x3c

DSC:
add pcd under lib inf as below:

NULL|TestPkg/TestLib/TestLib.inf
 
gUefiOvmfPkgTokenSpaceGuid.test1 | {GUID(gUefiOvmfPkgTokenSpaceGuid)}

Lib inf:(TestPkg/TestLib/TestLib.inf)
[Depex]
gUefiOvmfPkgTokenSpaceGuid.test1
[FixedPcd]
gUefiOvmfPkgTokenSpaceGuid.test1

Cc: Bob Feng 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhiju.Fan 
---
 BaseTools/Source/Python/AutoGen/AutoGen.py | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index 2452ecbcba..81361559b3 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -2892,10 +2892,16 @@ class ModuleAutoGen(AutoGen):
 if '.' not in item:
 NewList.append(item)
 else:
-if item not in self.FixedVoidTypePcds:
+FixedVoidTypePcds = {}
+if item in self.FixedVoidTypePcds:
+FixedVoidTypePcds = self.FixedVoidTypePcds
+elif M in self.PlatformInfo.LibraryAutoGenList:
+Index = 
self.PlatformInfo.LibraryAutoGenList.index(M)
+FixedVoidTypePcds = 
self.PlatformInfo.LibraryAutoGenList[Index].FixedVoidTypePcds
+if item not in FixedVoidTypePcds:
 EdkLogger.error("build", FORMAT_INVALID, "{} used 
in [Depex] section should be used as FixedAtBuild type and VOID* datum type in 
the module.".format(item))
 else:
-Value = self.FixedVoidTypePcds[item]
+Value = FixedVoidTypePcds[item]
 if len(Value.split(',')) != 16:
 EdkLogger.error("build", FORMAT_INVALID,
 "{} used in [Depex] section 
should be used as FixedAtBuild type and VOID* datum type and 16 bytes in the 
module.".format(item))
--
2.14.1.windows.1

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

[edk2] [Patch edk2 Wiki] Add ATA Security feature set support for edk2-stable201903

[Hao Wu]

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 EDK-II-Release-Planning.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/EDK-II-Release-Planning.md b/EDK-II-Release-Planning.md
index 095da69..9244fc4 100644
--- a/EDK-II-Release-Planning.md
+++ b/EDK-II-Release-Planning.md
@@ -27,6 +27,7 @@
 * [Support PI1.7 
EFI_PEI_CORE_FV_LOCATION_PPI](https://bugzilla.tianocore.org/show_bug.cgi?id=1524)
 * [Remove unused tool chain configuration in 
tools_def.template](https://bugzilla.tianocore.org/show_bug.cgi?id=1377)
 * [BaseTools supports to the driver 
combination](https://bugzilla.tianocore.org/show_bug.cgi?id=1520)
+* [Add Security feature set support for ATA 
devices](https://bugzilla.tianocore.org/show_bug.cgi?id=1529)
 * Standalone MM build of authenticated variable stack (bugzilla link TBD)
 * TBD Bugzilla List
 
-- 
2.12.0.windows.1

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

[edk2] [PATCH] BaseTools:Some build generated files content are not ordered on linux

[Fan, ZhijuX]

If the WORKSPACE environment variable has been set,The variables that
control stable sorting will not be set.

Cc: Bob Feng 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhiju.Fan 
---
 edksetup.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/edksetup.sh b/edksetup.sh
index a8897d10f8..39f62a29bd 100755
--- a/edksetup.sh
+++ b/edksetup.sh
@@ -49,6 +49,7 @@ function SetWorkspace()
   #
   # If WORKSPACE is already set, then we can return right now
   #
+  export PYTHONHASHSEED=1
   if [ -n "$WORKSPACE" ]
   then
 return 0
@@ -77,7 +78,6 @@ function SetWorkspace()
   # Set $WORKSPACE
   #
   export WORKSPACE=`pwd`
-  export PYTHONHASHSEED=1
   return 0
 }
 
-- 
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 00/10] Fix PEI Core issue during TemporaryRamMigration

[Ni, Ray]

> -Original Message-
> From: Justen, Jordan L 
> Sent: Thursday, February 21, 2019 9:03 AM
> To: Gao, Liming ; Ni, Ray ; edk2-
> de...@lists.01.org
> Cc: Wu, Hao A ; Anthony Perard
> ; Laszlo Ersek ; Zeng,
> Star ; Andrew Fish 
> Subject: RE: [PATCH 00/10] Fix PEI Core issue during TemporaryRamMigration
> 
> On 2019-02-20 16:15:59, Ni, Ray wrote:
> > > -Original Message-
> > > From: Justen, Jordan L 
> > > Sent: Thursday, February 21, 2019 1:44 AM
> > > To: Gao, Liming ; Ni, Ray ;
> > > edk2- de...@lists.01.org
> > > Cc: Wu, Hao A ; Anthony Perard
> > > ; Laszlo Ersek ; Zeng,
> > > Star 
> > > Subject: Re: [PATCH 00/10] Fix PEI Core issue during
> > > TemporaryRamMigration
> > >
> > > On 2019-02-20 05:27:21, Ni, Ray wrote:
> > > > On 2/19/2019 9:25 PM, Gao, Liming wrote:
> > > > > Ray:
> > > > >
> > > > >  Now, real platform has no side effect. So, only TempRamDone
> > > > >  PPI is produced. For emulator platform, is there any side
> > > > >  effect when both Temporary RAM and Permanent RAM are
> enabled?
> > > > >
> > > >
> > > > No side effect when both of T-RAM and P-RAM are enabled.
> > > > Which means no side effect when neither of the PPIs is produced.
> > > > But for demo purpose, I think producing TemporaryRamDone PPI
> makes
> > > sense.
> > >
> > > In addition to being a demo/sample, it also provides a check that no
> > > modules are accessing temp-ram after temp-ram should no longer be
> used.
> > >
> > > > I will work out patches for EmulatorPkg to produce TemoraryRamDone.
> > >
> > > I think we should first fix TemporaryRamSupport usage. Otherwise, we
> > > are just hiding the bug.
> > >
> > > Have you tried these patches to verify that they fix the issue in your
> setup?
> > > Have you taken a look at the patches to see what problem is being fixed?
> >
> > I feel the change to PeiCore is a bit complex and introduce additional deps
> (assembly).
> 
> I asked about this last November, and as I recall, Andrew said we can (and
> should) add assembly to PEI Core if it is required to meet the specs.
> 
> > Behavior of ARM and x86 becomes different. (The patch only fixes x86
> > issue.)
> 
> Yes. Similar code should be written for ARM, but I don't have experience
> with ARM assembly code.
> 
> > Given there is no real requirement on this,
> 
> Isn't the requirement to be compatible with the PI specification?
> 
> It seems that at least you and Liu Yu have encountered a build environment
> that produces code for PEI Core that isn't compatible with the PI 
> specification.
> 
> It doesn't seem like the best response to this is to just change the platform
> boot path and ignore the bug.

The environment Liu Yu and I encountered is the same Emulator environment.
I think the code change you did to PeiCore is great. It re-wrote the C code in
assembly to make sure the implementation doesn't rely on C compiler's
behavior.
But looking back, if a PI spec interface should depend on assembly
Implementation, I will pursue to change the PI spec interface directly.
Given the fact that no platform is producing this RamMigration PPI,
changing PI spec then changing the PeiCore to use new PPI interface
has no impact.

To be honest, I don't want to introduce complexity to PeiCore or edk2. That's
my only concern.

> 
> I do agree that after this issue is fixed, we can then consider changing the
> platform. The downside to changing it then will be to leave an untested code
> path, but at least we won't leave it with a known bug present.
> 
> -Jordan
> 
> > I prefer to not change PeiCore.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms v2 17/18] Hisilicon/D0x: Delete some header files

[Ming Huang]

On 2/21/2019 1:24 AM, Leif Lindholm wrote:
> Hi Ming,
> 
> Thank you for this rework.
> 
> However, can you move it first in the series, so that it's obvious
> this series contains no changes to these headers (because they have
> all happened in edk2-non-osi)?

Ok. Actually the patch "Rename StartupAp() function" modify function
name in PlatformSysCtrlLib.h, so this change need to move to edk2-non-osi.

Thanks

> 
> Regards,
> 
> Leif
> 
> On Wed, Feb 20, 2019 at 03:28:36PM +0800, Ming Huang wrote:
>> As some interfaces exposed only by implementations in edk2-non-osi,
>> so delete corresponding header files and modify code to make build.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ming Huang 
>> ---
>>  Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.inf   
>>|   1 +
>>  Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf  
>>|   2 +-
>>  Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.inf   
>>|   1 +
>>  Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf  
>>|   1 +
>>  Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.inf   
>>|   1 +
>>  Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.inf  
>>|   1 +
>>  Silicon/Hisilicon/Drivers/Smbios/MemorySubClassDxe/MemorySubClassDxe.inf
>>|   1 +
>>  
>> Silicon/Hisilicon/Drivers/Smbios/ProcessorSubClassDxe/ProcessorSubClassDxe.inf
>>  |   1 +
>>  Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf
>>|   2 +-
>>  Silicon/Hisilicon/Drivers/VirtualEhciPciIo/VirtualEhciPciIo.inf 
>>|   1 +
>>  Silicon/Hisilicon/Hi1610/Drivers/IoInitDxe/IoInitDxe.inf
>>|   1 +
>>  Silicon/Hisilicon/Library/BmcConfigBootLib/BmcConfigBootLib.inf 
>>|   1 +
>>  Silicon/Hisilicon/Library/I2CLib/I2CLib.inf 
>>|   1 +
>>  Silicon/Hisilicon/Library/I2CLib/I2CLibRuntime.inf  
>>|   1 +
>>  Silicon/Hisilicon/Hi1610/Include/Library/SerdesLib.h
>>|  22 
>>  Silicon/Hisilicon/Hi1616/Include/Library/SerdesLib.h
>>|  22 
>>  Silicon/Hisilicon/Include/Library/IpmiCmdLib.h  
>>| 110 ---
>>  Silicon/Hisilicon/Include/Library/LpcLib.h  
>>| 113 
>>  Silicon/Hisilicon/Include/Library/OemAddressMapLib.h
>>|  45 
>>  Silicon/Hisilicon/Include/Library/PlatformSysCtrlLib.h  
>>| 112 ---
>>  20 files changed, 14 insertions(+), 426 deletions(-)
>>
>> diff --git a/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.inf 
>> b/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.inf
>> index c65cf7b6dd9f..90e40ae2b393 100644
>> --- a/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.inf
>> +++ b/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.inf
>> @@ -30,6 +30,7 @@ [Packages]
>>MdeModulePkg/MdeModulePkg.dec
>>  
>>ArmPkg/ArmPkg.dec
>> +  Silicon/Hisilicon/HisiliconNonOsi.dec
>>Silicon/Hisilicon/HisiPkg.dec
>>  
>>  [LibraryClasses]
>> diff --git 
>> a/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf 
>> b/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf
>> index 0fa7fdf80fa8..c0195b2fa9cf 100644
>> --- a/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf
>> +++ b/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf
>> @@ -30,7 +30,7 @@ [Packages]
>>MdePkg/MdePkg.dec
>>MdeModulePkg/MdeModulePkg.dec
>>ArmPkg/ArmPkg.dec
>> -
>> +  Silicon/Hisilicon/HisiliconNonOsi.dec
>>Silicon/Hisilicon/HisiPkg.dec
>>  
>>  [LibraryClasses]
>> diff --git a/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.inf 
>> b/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.inf
>> index 0f6b68d4c88d..e82c9204d5d6 100644
>> --- a/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.inf
>> +++ b/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.inf
>> @@ -29,6 +29,7 @@ [Packages]
>>ArmPkg/ArmPkg.dec
>>MdePkg/MdePkg.dec
>>MdeModulePkg/MdeModulePkg.dec
>> +  Silicon/Hisilicon/HisiliconNonOsi.dec
>>Silicon/Hisilicon/HisiPkg.dec
>>  
>>  [LibraryClasses]
>> diff --git a/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf 
>> b/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf
>> index 022c3e940a31..7ec577530610 100644
>> --- a/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf
>> +++ b/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf
>> @@ -30,6 +30,7 @@ [Packages]
>>ArmPkg/ArmPkg.dec
>>MdeModulePkg/MdeModulePkg.dec
>>MdePkg/MdePkg.dec
>> +  Silicon/Hisilicon/HisiliconNonOsi.dec
>>Silicon/Hisilicon/HisiPkg.dec
>>  
>>  

Re: [edk2] [PATCH] ShellPkg: Correct a parameter's name

[krishnaLee]

Hi Shenglei,
I am confused some times,see UEFI_Shell_specification_2_2,chapter-3.7:


3.7 File Names
The UEFI Shell supports file names and paths with the following format:
fs-path := [fs-map-name] [fs-divider][fs-dirs][fs-name]  



May be if the define name "fs-path" rename to "file-full-path-name" is more 
clear,:)


thanks,
krishna.






At 2019-02-21 09:28:07, "Shenglei Zhang"  wrote:
>The parameter FilePath of ShellOpenFileByName defined in
>ShellLib.h is incorrect. It should be FileName.
>https://bugzilla.tianocore.org/show_bug.cgi?id=1221
>
>Cc: Jaben Carsey 
>Cc: Ruiyu Ni 
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: shenglei 
>---
> ShellPkg/Include/Library/ShellLib.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/ShellPkg/Include/Library/ShellLib.h 
>b/ShellPkg/Include/Library/ShellLib.h
>index 2ecc5ee006..78bdcc8c53 100644
>--- a/ShellPkg/Include/Library/ShellLib.h
>+++ b/ShellPkg/Include/Library/ShellLib.h
>@@ -161,7 +161,7 @@ ShellOpenFileByDevicePath(
>   otherwise, the Filehandle is NULL. Attributes is valid only for
>   EFI_FILE_MODE_CREATE.
> 
>-  @param[in] FilePath   The pointer to file name.
>+  @param[in] FileName   The pointer to file name.
>   @param[out] FileHandleThe pointer to the file handle.
>   @param[in] OpenMode   The mode to open the file with.
>   @param[in] Attributes The file's file attributes.
>@@ -186,7 +186,7 @@ ShellOpenFileByDevicePath(
> EFI_STATUS
> EFIAPI
> ShellOpenFileByName(
>-  IN CONST CHAR16   *FilePath,
>+  IN CONST CHAR16   *FileName,
>   OUT SHELL_FILE_HANDLE *FileHandle,
>   IN UINT64 OpenMode,
>   IN UINT64 Attributes
>-- 
>2.18.0.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] [PATCH V2] BaseTool/GenC: Fix build error when type is BASE or USER_DEFINED.

[Jiewen Yao]

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

=
V2: (Feedback from Liming) Add filter for 1) below:
Only constructor/destructor with BASE type is included here.
The constructor/destructor with PEI/DXE/SMM type is still excluded
to keep original behavior.

Test: NT32 build and boot successfully.

=

1) The GenC tool does not include the constructor/destructor for
USER_DEFINED module. It should be included.
Only constructor/destructor with BASE type is included here.
The constructor/destructor with PEI/DXE/SMM type is still excluded
to keep original behavior.

2) The GenC tool includes the UnloadImage code for BASE module.
It should NOT be included.

3) The GenC tool uses EFI_STATUS and ASSERT_EFI_ERROR for BASE type.
It should use RETURN_STATUS and ASSERT_RETURN_ERROR.

4) The GenC tool miss DebugLib.h for BASE or USER_DEFINED module
AutoGen.c. Only Base.h is there. It should add Library/DebugLib.h.

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao 
---
 BaseTools/Source/Python/AutoGen/GenC.py | 56 ++--
 1 file changed, 29 insertions(+), 27 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/GenC.py 
b/BaseTools/Source/Python/AutoGen/GenC.py
index 9700bf8527..a922464f56 100644
--- a/BaseTools/Source/Python/AutoGen/GenC.py
+++ b/BaseTools/Source/Python/AutoGen/GenC.py
@@ -684,7 +684,7 @@ ${Function} (
 gLibraryStructorCall = {
 SUP_MODULE_BASE  : TemplateString("""${BEGIN}
   Status = ${Function} ();
-  ASSERT_EFI_ERROR (Status);${END}
+  ASSERT_RETURN_ERROR (Status);${END}
 """),
 
 'PEI'   : TemplateString("""${BEGIN}
@@ -714,7 +714,7 @@ ProcessLibrary${Type}List (
   VOID
   )
 {
-${BEGIN}  EFI_STATUS  Status;
+${BEGIN}  RETURN_STATUS  Status;
 ${FunctionCall}${END}
 }
 """),
@@ -768,7 +768,7 @@ ${FunctionCall}${END}
 gBasicHeaderFile = "Base.h"
 
 gModuleTypeHeaderFile = {
-SUP_MODULE_BASE  :   [gBasicHeaderFile],
+SUP_MODULE_BASE  :   [gBasicHeaderFile, "Library/DebugLib.h"],
 SUP_MODULE_SEC   :   ["PiPei.h", "Library/DebugLib.h"],
 SUP_MODULE_PEI_CORE  :   ["PiPei.h", "Library/DebugLib.h", 
"Library/PeiCoreEntryPoint.h"],
 SUP_MODULE_PEIM  :   ["PiPei.h", "Library/DebugLib.h", 
"Library/PeimEntryPoint.h"],
@@ -782,7 +782,7 @@ gModuleTypeHeaderFile = {
 SUP_MODULE_SMM_CORE  :   ["PiDxe.h", "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/UefiDriverEntryPoint.h"],
 SUP_MODULE_MM_STANDALONE :   ["PiMm.h", "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/StandaloneMmDriverEntryPoint.h"],
 SUP_MODULE_MM_CORE_STANDALONE :  ["PiMm.h", "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/StandaloneMmCoreEntryPoint.h"],
-SUP_MODULE_USER_DEFINED  :   [gBasicHeaderFile]
+SUP_MODULE_USER_DEFINED  :   [gBasicHeaderFile, "Library/DebugLib.h"]
 }
 
 ## Autogen internal worker macro to define DynamicEx PCD name includes both 
the TokenSpaceGuidName
@@ -1345,16 +1345,17 @@ def CreateLibraryConstructorCode(Info, AutoGenC, 
AutoGenH):
 if Lib.ModuleType in [SUP_MODULE_BASE, SUP_MODULE_SEC]:
 
ConstructorPrototypeString.Append(gLibraryStructorPrototype[SUP_MODULE_BASE].Replace(Dict))
 
ConstructorCallingString.Append(gLibraryStructorCall[SUP_MODULE_BASE].Replace(Dict))
-elif Lib.ModuleType in SUP_MODULE_SET_PEI:
-
ConstructorPrototypeString.Append(gLibraryStructorPrototype['PEI'].Replace(Dict))
-
ConstructorCallingString.Append(gLibraryStructorCall['PEI'].Replace(Dict))
-elif Lib.ModuleType in [SUP_MODULE_DXE_CORE, SUP_MODULE_DXE_DRIVER, 
SUP_MODULE_DXE_SMM_DRIVER, SUP_MODULE_DXE_RUNTIME_DRIVER,
-SUP_MODULE_DXE_SAL_DRIVER, 
SUP_MODULE_UEFI_DRIVER, SUP_MODULE_UEFI_APPLICATION, SUP_MODULE_SMM_CORE]:
-
ConstructorPrototypeString.Append(gLibraryStructorPrototype['DXE'].Replace(Dict))
-
ConstructorCallingString.Append(gLibraryStructorCall['DXE'].Replace(Dict))
-elif Lib.ModuleType in [SUP_MODULE_MM_STANDALONE, 
SUP_MODULE_MM_CORE_STANDALONE]:
-
ConstructorPrototypeString.Append(gLibraryStructorPrototype['MM'].Replace(Dict))
-
ConstructorCallingString.Append(gLibraryStructorCall['MM'].Replace(Dict))
+if Info.ModuleType not in [SUP_MODULE_BASE, SUP_MODULE_USER_DEFINED]:
+if Lib.ModuleType in SUP_MODULE_SET_PEI:
+
ConstructorPrototypeString.Append(gLibraryStructorPrototype['PEI'].Replace(Dict))
+
ConstructorCallingString.Append(gLibraryStructorCall['PEI'].Replace(Dict))
+elif Lib.ModuleType in [SUP_MODULE_DXE_CORE, 
SUP_MODULE_DXE_DRIVER, SUP_MODULE_DXE_SMM_DRIVER, SUP_MODULE_DXE_RUNTIME_DRIVER,
+SUP_MODULE_DXE_SAL_DRIVER, 
SUP_MODULE_UEFI_DRIVER, SUP_MODULE_UEFI_APPLICATION, SUP_MODULE_SMM_CORE]:
+  

[edk2] [PATCH] BaseTools:Build fail if define [DEPEX] in library inf

[Fan, ZhijuX]

When define [DEPEX] in lib inf to build, it will fail and report"
gUefiOvmfPkgTokenSpaceGuid.test1 used in [Depex] section should be
used as FixedAtBuild type and VOID* datum type in the module."
But we define this PCD to FixedAtBuild type and VOID* datum type indeed.

DEC:
[PcdsFixedAtBuild]
gUefiOvmfPkgTokenSpaceGuid.test1 |
{GUID("4096267b-da0a-42eb-b5eb-fef31d207cb4")}|VOID*|0x3c

DSC:
add pcd under lib inf as below:

NULL|TestPkg/TestLib/TestLib.inf
 
gUefiOvmfPkgTokenSpaceGuid.test1 | {GUID(gUefiOvmfPkgTokenSpaceGuid)}

Lib inf:(TestPkg/TestLib/TestLib.inf)
[Depex]
gUefiOvmfPkgTokenSpaceGuid.test1
[FixedPcd]
gUefiOvmfPkgTokenSpaceGuid.test1

Cc: Bob Feng 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhiju.Fan 
---
 BaseTools/Source/Python/AutoGen/AutoGen.py | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index 2452ecbcba..81361559b3 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -2892,10 +2892,16 @@ class ModuleAutoGen(AutoGen):
 if '.' not in item:
 NewList.append(item)
 else:
-if item not in self.FixedVoidTypePcds:
+FixedVoidTypePcds = {}
+if item in self.FixedVoidTypePcds:
+FixedVoidTypePcds = self.FixedVoidTypePcds
+elif M in self.PlatformInfo.LibraryAutoGenList:
+Index = 
self.PlatformInfo.LibraryAutoGenList.index(M)
+FixedVoidTypePcds = 
self.PlatformInfo.LibraryAutoGenList[Index].FixedVoidTypePcds
+if item not in FixedVoidTypePcds:
 EdkLogger.error("build", FORMAT_INVALID, "{} used 
in [Depex] section should be used as FixedAtBuild type and VOID* datum type in 
the module.".format(item))
 else:
-Value = self.FixedVoidTypePcds[item]
+Value = FixedVoidTypePcds[item]
 if len(Value.split(',')) != 16:
 EdkLogger.error("build", FORMAT_INVALID,
 "{} used in [Depex] section 
should be used as FixedAtBuild type and VOID* datum type and 16 bytes in the 
module.".format(item))
-- 
2.14.1.windows.1

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

[edk2] [PATCH] ShellPkg: Correct a parameter's name

[Shenglei Zhang]

The parameter FilePath of ShellOpenFileByName defined in
ShellLib.h is incorrect. It should be FileName.
https://bugzilla.tianocore.org/show_bug.cgi?id=1221

Cc: Jaben Carsey 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: shenglei 
---
 ShellPkg/Include/Library/ShellLib.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ShellPkg/Include/Library/ShellLib.h 
b/ShellPkg/Include/Library/ShellLib.h
index 2ecc5ee006..78bdcc8c53 100644
--- a/ShellPkg/Include/Library/ShellLib.h
+++ b/ShellPkg/Include/Library/ShellLib.h
@@ -161,7 +161,7 @@ ShellOpenFileByDevicePath(
   otherwise, the Filehandle is NULL. Attributes is valid only for
   EFI_FILE_MODE_CREATE.
 
-  @param[in] FilePath   The pointer to file name.
+  @param[in] FileName   The pointer to file name.
   @param[out] FileHandleThe pointer to the file handle.
   @param[in] OpenMode   The mode to open the file with.
   @param[in] Attributes The file's file attributes.
@@ -186,7 +186,7 @@ ShellOpenFileByDevicePath(
 EFI_STATUS
 EFIAPI
 ShellOpenFileByName(
-  IN CONST CHAR16   *FilePath,
+  IN CONST CHAR16   *FileName,
   OUT SHELL_FILE_HANDLE *FileHandle,
   IN UINT64 OpenMode,
   IN UINT64 Attributes
-- 
2.18.0.windows.1

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

Re: [edk2] [PATCH 00/10] Fix PEI Core issue during TemporaryRamMigration

[Jordan Justen]

On 2019-02-20 16:15:59, Ni, Ray wrote:
> > -Original Message-
> > From: Justen, Jordan L 
> > Sent: Thursday, February 21, 2019 1:44 AM
> > To: Gao, Liming ; Ni, Ray ; edk2-
> > de...@lists.01.org
> > Cc: Wu, Hao A ; Anthony Perard
> > ; Laszlo Ersek ; Zeng,
> > Star 
> > Subject: Re: [PATCH 00/10] Fix PEI Core issue during TemporaryRamMigration
> > 
> > On 2019-02-20 05:27:21, Ni, Ray wrote:
> > > On 2/19/2019 9:25 PM, Gao, Liming wrote:
> > > > Ray:
> > > >
> > > >  Now, real platform has no side effect. So, only TempRamDone
> > > >  PPI is produced. For emulator platform, is there any side
> > > >  effect when both Temporary RAM and Permanent RAM are enabled?
> > > >
> > >
> > > No side effect when both of T-RAM and P-RAM are enabled.
> > > Which means no side effect when neither of the PPIs is produced.
> > > But for demo purpose, I think producing TemporaryRamDone PPI makes
> > sense.
> > 
> > In addition to being a demo/sample, it also provides a check that no modules
> > are accessing temp-ram after temp-ram should no longer be used.
> > 
> > > I will work out patches for EmulatorPkg to produce TemoraryRamDone.
> > 
> > I think we should first fix TemporaryRamSupport usage. Otherwise, we are
> > just hiding the bug.
> > 
> > Have you tried these patches to verify that they fix the issue in your 
> > setup?
> > Have you taken a look at the patches to see what problem is being fixed?
> 
> I feel the change to PeiCore is a bit complex and introduce additional deps 
> (assembly).

I asked about this last November, and as I recall, Andrew said we can
(and should) add assembly to PEI Core if it is required to meet the
specs.

> Behavior of ARM and x86 becomes different. (The patch only fixes x86 issue.)

Yes. Similar code should be written for ARM, but I don't have
experience with ARM assembly code.

> Given there is no real requirement on this,

Isn't the requirement to be compatible with the PI specification?

It seems that at least you and Liu Yu have encountered a build
environment that produces code for PEI Core that isn't compatible with
the PI specification.

It doesn't seem like the best response to this is to just change the
platform boot path and ignore the bug.

I do agree that after this issue is fixed, we can then consider
changing the platform. The downside to changing it then will be to
leave an untested code path, but at least we won't leave it with a
known bug present.

-Jordan

> I prefer to not change PeiCore.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v4 5/7] MdeModulePkg: Add a new API ResetSystem for PEI ResetSystemLib

[Zhichao Gao]

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

Add a new API ResetSystem for PEI ResetSystemLib to be in accord with
DXE instance.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhichao Gao 
Cc: Ray Ni 
Cc: Liming Gao 
---
 .../Library/PeiResetSystemLib/PeiResetSystemLib.c  | 28 +-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/PeiResetSystemLib/PeiResetSystemLib.c 
b/MdeModulePkg/Library/PeiResetSystemLib/PeiResetSystemLib.c
index d8219775d1..f35acb3c6e 100644
--- a/MdeModulePkg/Library/PeiResetSystemLib/PeiResetSystemLib.c
+++ b/MdeModulePkg/Library/PeiResetSystemLib/PeiResetSystemLib.c
@@ -1,7 +1,7 @@
 /** @file
   PEI Reset System Library instance that calls the ResetSystem2() PEI Service.
 
-  Copyright (c) 2017 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -96,3 +96,29 @@ ResetPlatformSpecific (
 {
   PeiServicesResetSystem2 (EfiResetPlatformSpecific, EFI_SUCCESS, DataSize, 
ResetData);
 }
+
+/**
+  The ResetSystem function resets the entire platform.
+
+  @param[in] ResetType  The type of reset to perform.
+  @param[in] ResetStatusThe status code for the reset.
+  @param[in] DataSize   The size, in bytes, of ResetData.
+  @param[in] ResetData  For a ResetType of EfiResetCold, EfiResetWarm, or 
EfiResetShutdown
+the data buffer starts with a Null-terminated 
string, optionally
+followed by additional binary data. The string is 
a description
+that the caller may use to further indicate the 
reason for the
+system reset. ResetData is only valid if 
ResetStatus is something
+other than EFI_SUCCESS unless the ResetType is 
EfiResetPlatformSpecific
+where a minimum amount of ResetData is always 
required.
+**/
+VOID
+EFIAPI
+ResetSystem (
+  IN EFI_RESET_TYPE   ResetType,
+  IN EFI_STATUS   ResetStatus,
+  IN UINTNDataSize,
+  IN VOID *ResetData OPTIONAL
+  )
+{
+  PeiServicesResetSystem2 (ResetType, ResetStatus, DataSize, ResetData);
+}
-- 
2.16.2.windows.1

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

[edk2] [PATCH v4 3/7] MdeModulePkg: Add a new API ResetSystem for DXE ResetSystemLib

[Zhichao Gao]

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

Add a new API ResetSystem for DXE ResetSystemLib. So the consumer of
ResetSystemLib can use this API to reset system with additional reset
data.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhichao Gao 
Cc: Ray Ni 
Cc: Liming Gao 
---
 .../Library/DxeResetSystemLib/DxeResetSystemLib.c  | 28 +-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/DxeResetSystemLib/DxeResetSystemLib.c 
b/MdeModulePkg/Library/DxeResetSystemLib/DxeResetSystemLib.c
index ea4878cab1..f5c7386c9a 100644
--- a/MdeModulePkg/Library/DxeResetSystemLib/DxeResetSystemLib.c
+++ b/MdeModulePkg/Library/DxeResetSystemLib/DxeResetSystemLib.c
@@ -1,7 +1,7 @@
 /** @file
   DXE Reset System Library instance that calls gRT->ResetSystem().
 
-  Copyright (c) 2017 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -96,3 +96,29 @@ ResetPlatformSpecific (
 {
   gRT->ResetSystem (EfiResetPlatformSpecific, EFI_SUCCESS, DataSize, 
ResetData);
 }
+
+/**
+  The ResetSystem function resets the entire platform.
+
+  @param[in] ResetType  The type of reset to perform.
+  @param[in] ResetStatusThe status code for the reset.
+  @param[in] DataSize   The size, in bytes, of ResetData.
+  @param[in] ResetData  For a ResetType of EfiResetCold, EfiResetWarm, or 
EfiResetShutdown
+the data buffer starts with a Null-terminated 
string, optionally
+followed by additional binary data. The string is 
a description
+that the caller may use to further indicate the 
reason for the
+system reset. ResetData is only valid if 
ResetStatus is something
+other than EFI_SUCCESS unless the ResetType is 
EfiResetPlatformSpecific
+where a minimum amount of ResetData is always 
required.
+**/
+VOID
+EFIAPI
+ResetSystem (
+  IN EFI_RESET_TYPE   ResetType,
+  IN EFI_STATUS   ResetStatus,
+  IN UINTNDataSize,
+  IN VOID *ResetData OPTIONAL
+  )
+{
+  gRT->ResetSystem (ResetType, ResetStatus, DataSize, ResetData);
+}
-- 
2.16.2.windows.1

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

[edk2] [PATCH v4 7/7] MdeModulePkg: Add the runtime ResetSystemLib in MdeModulePkg.dsc

[Zhichao Gao]

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

Add the runtime library instance of ResetSystemLib in
MdeModulePkg.dsc to make sure it can build pass.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhichao Gao 
Cc: Ray Ni 
Cc: Liming Gao 
---
 MdeModulePkg/MdeModulePkg.dsc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index 3b315fca5a..790a5fa05d 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -286,6 +286,7 @@
   MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf
   MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
   
MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/RuntimeDxeReportStatusCodeLib.inf
+  MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.inf
   MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
   MdeModulePkg/Library/BasePlatformHookLibNull/BasePlatformHookLibNull.inf
   
MdeModulePkg/Library/DxeDebugPrintErrorLevelLib/DxeDebugPrintErrorLevelLib.inf
-- 
2.16.2.windows.1

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

[edk2] [PATCH v4 1/7] MdeModulePkg: change the function name ResetSystem

[Zhichao Gao]

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

Change the function name form ResetSystem to RuntimeServiceResetSystem.
Because ResetSystem and EfiResetSystem would be used in ResetSystemLib
and RuntimeLib.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhichao Gao 
Cc: Ray Ni 
Cc: Liming Gao 
---
 MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c | 8 
 MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.h | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c 
b/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c
index afc35587fc..4c7107faea 100644
--- a/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c
+++ b/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c
@@ -1,7 +1,7 @@
 /** @file
   Reset Architectural and Reset Notification protocols implementation.
 
-  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -187,7 +187,7 @@ InitializeResetSystem (
   //
   // Hook the runtime service table
   //
-  gRT->ResetSystem = ResetSystem;
+  gRT->ResetSystem = RuntimeServiceResetSystem;
 
   //
   // Now install the Reset RT AP on a new handle
@@ -242,7 +242,7 @@ DoS3 (
 **/
 VOID
 EFIAPI
-ResetSystem (
+RuntimeServiceResetSystem (
   IN EFI_RESET_TYPE   ResetType,
   IN EFI_STATUS   ResetStatus,
   IN UINTNDataSize,
@@ -256,7 +256,7 @@ ResetSystem (
   RESET_NOTIFY_ENTRY  *Entry;
 
   //
-  // Only do REPORT_STATUS_CODE() on first call to ResetSystem()
+  // Only do REPORT_STATUS_CODE() on first call to RuntimeServiceResetSystem()
   //
   if (mResetNotifyDepth == 0) {
 //
diff --git a/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.h 
b/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.h
index 8529de675c..938dbd5011 100644
--- a/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.h
+++ b/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.h
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -97,7 +97,7 @@ InitializeResetSystem (
 **/
 VOID
 EFIAPI
-ResetSystem (
+RuntimeServiceResetSystem (
   IN EFI_RESET_TYPE   ResetType,
   IN EFI_STATUS   ResetStatus,
   IN UINTNDataSize,
-- 
2.16.2.windows.1

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

[edk2] [PATCH v4 2/7] MdeModulePkg: Add the new API ResetSystem in the head file

[Zhichao Gao]

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

Add the new API ResetSystem in the related head file so that
the consumer can use it through the combination of library
instance and head file.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhichao Gao 
Cc: Ray Ni 
Cc: Liming Gao 
---
 MdeModulePkg/Include/Library/ResetSystemLib.h | 28 ++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Include/Library/ResetSystemLib.h 
b/MdeModulePkg/Include/Library/ResetSystemLib.h
index 55d1923ae1..e438a0a90e 100644
--- a/MdeModulePkg/Include/Library/ResetSystemLib.h
+++ b/MdeModulePkg/Include/Library/ResetSystemLib.h
@@ -2,7 +2,7 @@
   System reset Library Services.  This library class defines a set of
   methods that reset the whole system.
 
-Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2005 - 2019, Intel Corporation. All rights reserved.
 This program and the accompanying materials are licensed and made available 
under
 the terms and conditions of the BSD License that accompanies this distribution.
 The full text of the license may be found at
@@ -16,6 +16,9 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #ifndef __RESET_SYSTEM_LIB_H__
 #define __RESET_SYSTEM_LIB_H__
 
+#include 
+#include 
+
 /**
   This function causes a system-wide reset (cold reset), in which
   all circuitry within the system returns to its initial state. This type of 
reset
@@ -83,4 +86,27 @@ ResetPlatformSpecific (
   IN VOID*ResetData
   );
 
+/**
+  The ResetSystem function resets the entire platform.
+
+  @param[in] ResetType  The type of reset to perform.
+  @param[in] ResetStatusThe status code for the reset.
+  @param[in] DataSize   The size, in bytes, of ResetData.
+  @param[in] ResetData  For a ResetType of EfiResetCold, EfiResetWarm, or 
EfiResetShutdown
+the data buffer starts with a Null-terminated 
string, optionally
+followed by additional binary data. The string is 
a description
+that the caller may use to further indicate the 
reason for the
+system reset. ResetData is only valid if 
ResetStatus is something
+other than EFI_SUCCESS unless the ResetType is 
EfiResetPlatformSpecific
+where a minimum amount of ResetData is always 
required.
+**/
+VOID
+EFIAPI
+ResetSystem (
+  IN EFI_RESET_TYPE   ResetType,
+  IN EFI_STATUS   ResetStatus,
+  IN UINTNDataSize,
+  IN VOID *ResetData OPTIONAL
+  );
+
 #endif
-- 
2.16.2.windows.1

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

[edk2] [PATCH v4 6/7] MdeModulePkg: Add a runtime library instance of ResetSystemLib

[Zhichao Gao]

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

Implement a runtime library instance of ResetSystemLib. It would
use a internal point instead of gRT and convert it depend on
gEfiEventVirtualAddressChangeGuid.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhichao Gao 
Cc: Ray Ni 
Cc: Liming Gao 
---
 .../RuntimeResetSystemLib/RuntimeResetSystemLib.c  | 216 +
 .../RuntimeResetSystemLib.inf  |  50 +
 .../RuntimeResetSystemLib.uni  |  21 ++
 3 files changed, 287 insertions(+)
 create mode 100644 
MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.c
 create mode 100644 
MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.inf
 create mode 100644 
MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.uni

diff --git a/MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.c 
b/MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.c
new file mode 100644
index 00..17826cd6a9
--- /dev/null
+++ b/MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.c
@@ -0,0 +1,216 @@
+/** @file
+  DXE Reset System Library instance that calls gRT->ResetSystem().
+
+  Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  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 
+#include 
+#include 
+#include 
+
+EFI_EVENT mRuntimeResetSystemLibVirtualAddressChangeEvent;
+EFI_RUNTIME_SERVICES  *mInternalRT;
+
+/**
+  This function causes a system-wide reset (cold reset), in which
+  all circuitry within the system returns to its initial state. This type of 
reset
+  is asynchronous to system operation and operates without regard to
+  cycle boundaries.
+
+  If this function returns, it means that the system does not support cold 
reset.
+**/
+VOID
+EFIAPI
+ResetCold (
+  VOID
+  )
+{
+  mInternalRT->ResetSystem (EfiResetCold, EFI_SUCCESS, 0, NULL);
+}
+
+/**
+  This function causes a system-wide initialization (warm reset), in which all 
processors
+  are set to their initial state. Pending cycles are not corrupted.
+
+  If this function returns, it means that the system does not support warm 
reset.
+**/
+VOID
+EFIAPI
+ResetWarm (
+  VOID
+  )
+{
+  mInternalRT->ResetSystem (EfiResetWarm, EFI_SUCCESS, 0, NULL);
+}
+
+/**
+  This function causes the system to enter a power state equivalent
+  to the ACPI G2/S5 or G3 states.
+
+  If this function returns, it means that the system does not support shut 
down reset.
+**/
+VOID
+EFIAPI
+ResetShutdown (
+  VOID
+  )
+{
+  mInternalRT->ResetSystem (EfiResetShutdown, EFI_SUCCESS, 0, NULL);
+}
+
+/**
+  This function causes the system to enter S3 and then wake up immediately.
+
+  If this function returns, it means that the system does not support S3 
feature.
+**/
+VOID
+EFIAPI
+EnterS3WithImmediateWake (
+  VOID
+  )
+{
+}
+
+/**
+  This function causes a systemwide reset. The exact type of the reset is
+  defined by the EFI_GUID that follows the Null-terminated Unicode string 
passed
+  into ResetData. If the platform does not recognize the EFI_GUID in ResetData
+  the platform must pick a supported reset type to perform.The platform may
+  optionally log the parameters from any non-normal reset that occurs.
+
+  @param[in]  DataSize   The size, in bytes, of ResetData.
+  @param[in]  ResetData  The data buffer starts with a Null-terminated string,
+ followed by the EFI_GUID.
+**/
+VOID
+EFIAPI
+ResetPlatformSpecific (
+  IN UINTN   DataSize,
+  IN VOID*ResetData
+  )
+{
+  mInternalRT->ResetSystem (EfiResetPlatformSpecific, EFI_SUCCESS, DataSize, 
ResetData);
+}
+
+/**
+  The ResetSystem function resets the entire platform.
+
+  @param[in] ResetType  The type of reset to perform.
+  @param[in] ResetStatusThe status code for the reset.
+  @param[in] DataSize   The size, in bytes, of ResetData.
+  @param[in] ResetData  For a ResetType of EfiResetCold, EfiResetWarm, or 
EfiResetShutdown
+the data buffer starts with a Null-terminated 
string, optionally
+followed by additional binary data. The string is 
a description
+that the caller may use to further indicate the 
reason for the
+system reset. ResetData is only valid if 
ResetStatus is something
+other than EFI_SUCCESS unless the ResetType is 
EfiResetPlatformSpecific
+where a minimum amount of ResetData is always 
required.

[edk2] [PATCH v4 4/7] MdeModulePkg: Add a new API ResetSystem for Null version

[Zhichao Gao]

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

Add a new API ResetSystem for BaseResetSystemLibNull to be
in accord with other instances.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhichao Gao 
Cc: Ray Ni 
Cc: Liming Gao 
---
 .../BaseResetSystemLibNull.c   | 27 ++
 1 file changed, 27 insertions(+)

diff --git 
a/MdeModulePkg/Library/BaseResetSystemLibNull/BaseResetSystemLibNull.c 
b/MdeModulePkg/Library/BaseResetSystemLibNull/BaseResetSystemLibNull.c
index 59d720895b..875f839175 100644
--- a/MdeModulePkg/Library/BaseResetSystemLibNull/BaseResetSystemLibNull.c
+++ b/MdeModulePkg/Library/BaseResetSystemLibNull/BaseResetSystemLibNull.c
@@ -98,3 +98,30 @@ ResetPlatformSpecific (
 {
   ResetCold ();
 }
+
+/**
+  The ResetSystem function resets the entire platform.
+
+  @param[in] ResetType  The type of reset to perform.
+  @param[in] ResetStatusThe status code for the reset.
+  @param[in] DataSize   The size, in bytes, of ResetData.
+  @param[in] ResetData  For a ResetType of EfiResetCold, EfiResetWarm, or 
EfiResetShutdown
+the data buffer starts with a Null-terminated 
string, optionally
+followed by additional binary data. The string is 
a description
+that the caller may use to further indicate the 
reason for the
+system reset. ResetData is only valid if 
ResetStatus is something
+other than EFI_SUCCESS unless the ResetType is 
EfiResetPlatformSpecific
+where a minimum amount of ResetData is always 
required.
+**/
+VOID
+EFIAPI
+ResetSystem (
+  IN EFI_RESET_TYPE   ResetType,
+  IN EFI_STATUS   ResetStatus,
+  IN UINTNDataSize,
+  IN VOID *ResetData OPTIONAL
+  )
+{
+  ASSERT (FALSE);
+}
+
-- 
2.16.2.windows.1

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

[edk2] [PATCH v4 0/7] ResetSystemLib changings

[Zhichao Gao]

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1460
Add a new API ResetSystem in ResetSystemLib.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1461
Implement a runtime library instance of ResetSystemLib base on the new changing.

V2: Add some required data type header file

V3: Resolve a case-typing error.

V4: Change the ResetSystemRuntimeDxe/ResetSystem.c name to 
RuntimeServiceResetSystem.
Add a new interface for PEI version ResetSystemLib.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhichao Gao 
Cc: Ray Ni 
Cc: Liming Gao 

Zhichao Gao (7):
  MdeModulePkg: change the function name ResetSystem
  MdeModulePkg: Add the new API ResetSystem in the head file
  MdeModulePkg: Add a new API ResetSystem for DXE ResetSystemLib
  MdeModulePkg: Add a new API ResetSystem for Null version
  MdeModulePkg: Add a new API ResetSystem for PEI ResetSystemLib
  MdeModulePkg: Add a runtime library instance of ResetSystemLib
  MdeModulePkg: Add the runtime ResetSystemLib in MdeModulePkg.dsc

 MdeModulePkg/Include/Library/ResetSystemLib.h  |  28 ++-
 .../BaseResetSystemLibNull.c   |  27 +++
 .../Library/DxeResetSystemLib/DxeResetSystemLib.c  |  28 ++-
 .../Library/PeiResetSystemLib/PeiResetSystemLib.c  |  28 ++-
 .../RuntimeResetSystemLib/RuntimeResetSystemLib.c  | 216 +
 .../RuntimeResetSystemLib.inf  |  50 +
 .../RuntimeResetSystemLib.uni  |  21 ++
 MdeModulePkg/MdeModulePkg.dsc  |   1 +
 .../Universal/ResetSystemRuntimeDxe/ResetSystem.c  |   8 +-
 .../Universal/ResetSystemRuntimeDxe/ResetSystem.h  |   4 +-
 10 files changed, 402 insertions(+), 9 deletions(-)
 create mode 100644 
MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.c
 create mode 100644 
MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.inf
 create mode 100644 
MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.uni

-- 
2.16.2.windows.1

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

[edk2] [PATCH v2 2/2] MdeModulePkg/ScsiDiskDxe: Support Storage Security Command Protocol

[Christopher J Zurcher]

This patch implements the EFI_STORAGE_SECURITY_COMMAND_PROTOCOL in the
ScsiDiskDxe driver.

Support is currently limited to the RPMB Well-known LUN for UFS devices.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Christopher J Zurcher 
---
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf |   3 +-
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h  | 171 +++-
 MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c|   5 +-
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ComponentName.c |  14 +-
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c  | 510 +-
 MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c |  19 +-
 6 files changed, 698 insertions(+), 24 deletions(-)

diff --git a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf 
b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
index 14010802a8..2122aa4b01 100644
--- a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
+++ b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
@@ -3,7 +3,7 @@
 #  It detects the SCSI disk media and installs Block I/O and Block I/O2 
Protocol on
 #  the device handle.
 #
-#  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
 #  which accompanies this distribution.  The full text of the license may be 
found at
@@ -58,6 +58,7 @@
   gEfiBlockIoProtocolGuid   ## BY_START
   gEfiBlockIo2ProtocolGuid  ## BY_START
   gEfiEraseBlockProtocolGuid## BY_START
+  gEfiStorageSecurityCommandProtocolGuid## BY_START
   gEfiScsiIoProtocolGuid## TO_START
   gEfiScsiPassThruProtocolGuid  ## TO_START
   gEfiExtScsiPassThruProtocolGuid   ## TO_START
diff --git a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h 
b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h
index bb6232676d..4731258018 100644
--- a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h
+++ b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h
@@ -1,7 +1,7 @@
 /** @file
   Header file for SCSI Disk Driver.
 
-Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2004 - 2019, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -28,6 +28,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
+#include 
 
 
 #include 
@@ -44,6 +45,10 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 #define IS_DEVICE_FIXED(a)(a)->FixedDevice ? 1 : 0
 
+#define IS_ALIGNED(addr, size)(((UINTN) (addr) & (size - 1)) == 0)
+
+#define UFS_WLUN_RPMB 0xC4
+
 typedef struct {
   UINT32MaxLbaCnt;
   UINT32MaxBlkDespCnt;
@@ -57,6 +62,8 @@ typedef struct {
 
   EFI_HANDLEHandle;
 
+  EFI_STORAGE_SECURITY_COMMAND_PROTOCOL   StorageSecurity;
+
   EFI_BLOCK_IO_PROTOCOL BlkIo;
   EFI_BLOCK_IO2_PROTOCOLBlkIo2;
   EFI_BLOCK_IO_MEDIABlkIoMedia;
@@ -101,6 +108,7 @@ typedef struct {
 #define SCSI_DISK_DEV_FROM_BLKIO(a)  CR (a, SCSI_DISK_DEV, BlkIo, 
SCSI_DISK_DEV_SIGNATURE)
 #define SCSI_DISK_DEV_FROM_BLKIO2(a)  CR (a, SCSI_DISK_DEV, BlkIo2, 
SCSI_DISK_DEV_SIGNATURE)
 #define SCSI_DISK_DEV_FROM_ERASEBLK(a)  CR (a, SCSI_DISK_DEV, EraseBlock, 
SCSI_DISK_DEV_SIGNATURE)
+#define SCSI_DISK_DEV_FROM_STORSEC(a)  CR (a, SCSI_DISK_DEV, StorageSecurity, 
SCSI_DISK_DEV_SIGNATURE)
 
 #define SCSI_DISK_DEV_FROM_DISKINFO(a) CR (a, SCSI_DISK_DEV, DiskInfo, 
SCSI_DISK_DEV_SIGNATURE)
 
@@ -644,6 +652,151 @@ ScsiDiskEraseBlocks (
   );
 
 
+/**
+  Send a security protocol command to a device that receives data and/or the 
result
+  of one or more commands sent by SendData.
+
+  The ReceiveData function sends a security protocol command to the given 
MediaId.
+  The security protocol command sent is defined by SecurityProtocolId and 
contains
+  the security protocol specific data SecurityProtocolSpecificData. The 
function
+  returns the data from the security protocol command in PayloadBuffer.
+
+  For devices supporting the SCSI command set, the security protocol command 
is sent
+  using the SECURITY PROTOCOL IN command defined in SPC-4.
+
+  If PayloadBufferSize is too small to store the available data from the 
security
+  protocol command, the function shall copy PayloadBufferSize bytes into the
+  PayloadBuffer and return EFI_WARN_BUFFER_TOO_SMALL.
+
+  If PayloadBuffer or PayloadTransferSize is NULL and PayloadBufferSize is 
non-zero,
+  the function shall return EFI_INVALID_PARAMETER.
+
+  If the given MediaId does not support 

[edk2] [PATCH v2 0/2] Add SCSI Support for Storage Security

[Christopher J Zurcher]

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

V2 changes: Split the patch into separate commits for separate packages.

To support RPMB access on UFS devices, support must be added to
the ScsiDiskDxe driver for the Storage Security Command Protocol.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Liming Gao 

Christopher J Zurcher (2):
  MdePkg: Implement SCSI commands for Security Protocol In/Out
  MdeModulePkg/ScsiDiskDxe: Support Storage Security Command Protocol

 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf |   3 +-
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h  | 171 +++-
 MdePkg/Include/IndustryStandard/Scsi.h|  48 +-
 MdePkg/Include/Library/UefiScsiLib.h  | 126 +-
 MdePkg/Include/Protocol/ScsiIo.h  |   9 +-
 MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c|   5 +-
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ComponentName.c |  14 +-
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c  | 510 +-
 MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c |  19 +-
 MdePkg/Library/UefiScsiLib/UefiScsiLib.c  | 205 -
 10 files changed, 1064 insertions(+), 46 deletions(-)

-- 
2.16.2.windows.1

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

[edk2] [PATCH v2 1/2] MdePkg: Implement SCSI commands for Security Protocol In/Out

[Christopher J Zurcher]

This patch implements the Security Protocol In and Security Protocol Out
commands in UefiScsiLib to prepare support for the Storage Security
Command Protocol.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Christopher J Zurcher 
---
 MdePkg/Include/IndustryStandard/Scsi.h   |  48 +---
 MdePkg/Include/Library/UefiScsiLib.h | 126 ++-
 MdePkg/Include/Protocol/ScsiIo.h |   9 +-
 MdePkg/Library/UefiScsiLib/UefiScsiLib.c | 205 ++-
 4 files changed, 366 insertions(+), 22 deletions(-)

diff --git a/MdePkg/Include/IndustryStandard/Scsi.h 
b/MdePkg/Include/IndustryStandard/Scsi.h
index 213d8acc2d..59509a0256 100644
--- a/MdePkg/Include/IndustryStandard/Scsi.h
+++ b/MdePkg/Include/IndustryStandard/Scsi.h
@@ -1,7 +1,7 @@
 /** @file
   Support for SCSI-2 standard
 
-  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -169,6 +169,12 @@
 #define EFI_SCSI_OP_SEND_MESSAGE10  0x2a
 #define EFI_SCSI_OP_SEND_MESSAGE12  0xaa
 
+//
+// Additional commands for Secure Transactions
+//
+#define EFI_SCSI_OP_SECURITY_PROTOCOL_IN  0xa2
+#define EFI_SCSI_OP_SECURITY_PROTOCOL_OUT 0xb5
+
 //
 // SCSI Data Transfer Direction
 //
@@ -178,22 +184,30 @@
 //
 // Peripheral Device Type Definitions
 //
-#define EFI_SCSI_TYPE_DISK  0x00  ///< Direct-access device (e.g. 
magnetic disk)
-#define EFI_SCSI_TYPE_TAPE  0x01  ///< Sequential-access device (e.g. 
magnetic tape)
-#define EFI_SCSI_TYPE_PRINTER   0x02  ///< Printer device
-#define EFI_SCSI_TYPE_PROCESSOR 0x03  ///< Processor device
-#define EFI_SCSI_TYPE_WORM  0x04  ///< Write-once device (e.g. some 
optical disks)
-#define EFI_SCSI_TYPE_CDROM 0x05  ///< CD-ROM device
-#define EFI_SCSI_TYPE_SCANNER   0x06  ///< Scanner device
-#define EFI_SCSI_TYPE_OPTICAL   0x07  ///< Optical memory device (e.g. 
some optical disks)
-#define EFI_SCSI_TYPE_MEDIUMCHANGER 0x08  ///< Medium changer device (e.g. 
jukeboxes)
-#define EFI_SCSI_TYPE_COMMUNICATION 0x09  ///< Communications device
-#define EFI_SCSI_TYPE_ASCIT8_1  0x0A  ///< Defined by ASC IT8 (Graphic 
arts pre-press devices)
-#define EFI_SCSI_TYPE_ASCIT8_2  0x0B  ///< Defined by ASC IT8 (Graphic 
arts pre-press devices)
-//
-// 0Ch - 1Eh are reserved
-//
-#define EFI_SCSI_TYPE_UNKNOWN   0x1F  ///< Unknown or no device type
+#define EFI_SCSI_TYPE_DISK0x00  ///< Direct-access device (e.g. 
magnetic disk)
+#define EFI_SCSI_TYPE_TAPE0x01  ///< Sequential-access device 
(e.g. magnetic tape)
+#define EFI_SCSI_TYPE_PRINTER 0x02  ///< Printer device
+#define EFI_SCSI_TYPE_PROCESSOR   0x03  ///< Processor device
+#define EFI_SCSI_TYPE_WORM0x04  ///< Write-once device (e.g. some 
optical disks)
+#define EFI_SCSI_TYPE_CDROM   0x05  ///< CD/DVD device
+#define EFI_SCSI_TYPE_SCANNER 0x06  ///< Scanner device (obsolete)
+#define EFI_SCSI_TYPE_OPTICAL 0x07  ///< Optical memory device (e.g. 
some optical disks)
+#define EFI_SCSI_TYPE_MEDIUMCHANGER   0x08  ///< Medium changer device (e.g. 
jukeboxes)
+#define EFI_SCSI_TYPE_COMMUNICATION   0x09  ///< Communications device 
(obsolete)
+#define EFI_SCSI_TYPE_A   0x0A  ///< Obsolete
+#define EFI_SCSI_TYPE_B   0x0B  ///< Obsolete
+#define EFI_SCSI_TYPE_RAID0x0C  ///< Storage array controller 
device (e.g., RAID)
+#define EFI_SCSI_TYPE_SES 0x0D  ///< Enclosure services device
+#define EFI_SCSI_TYPE_RBC 0x0E  ///< Simplified direct-access 
device (e.g., magnetic disk)
+#define EFI_SCSI_TYPE_OCRW0x0F  ///< Optical card reader/writer 
device
+#define EFI_SCSI_TYPE_BRIDGE  0x10  ///< Bridge Controller Commands
+#define EFI_SCSI_TYPE_OSD 0x11  ///< Object-based Storage Device
+#define EFI_SCSI_TYPE_AUTOMATION  0x12  ///< Automation/Drive Interface
+#define EFI_SCSI_TYPE_SECURITYMANAGER 0x13  ///< Security manager device
+#define EFI_SCSI_TYPE_RESERVED_LOW0x14  ///< Reserved (low)
+#define EFI_SCSI_TYPE_RESERVED_HIGH   0x1D  ///< Reserved (high)
+#define EFI_SCSI_TYPE_WLUN0x1E  ///< Well known logical unit
+#define EFI_SCSI_TYPE_UNKNOWN 0x1F  ///< Unknown or no device type
 
 //
 // Page Codes for INQUIRY command
diff --git a/MdePkg/Include/Library/UefiScsiLib.h 
b/MdePkg/Include/Library/UefiScsiLib.h
index dbb248972b..594f495d7d 100644
--- a/MdePkg/Include/Library/UefiScsiLib.h
+++ b/MdePkg/Include/Library/UefiScsiLib.h
@@ -5,7 +5,7 @@
   for hard drive, CD and DVD devices that are the most common SCSI boot 
targets used by UEFI platforms.
 

Re: [edk2] [PATCH] BaseTool/GenC: Fix build error when type is BASE or USER_DEFINED.

[Yao, Jiewen]

Thanks.
Yes, I agree. I will add more filter for that.

Thank you
Yao Jiewen

> -Original Message-
> From: Gao, Liming
> Sent: Wednesday, February 20, 2019 10:14 PM
> To: Yao, Jiewen ; edk2-devel@lists.01.org
> Subject: RE: [edk2] [PATCH] BaseTool/GenC: Fix build error when type is
> BASE or USER_DEFINED.
> 
> Jiewen:
>   This change causes NT32 SecMain build failure. For USER_DEFINED and
> BASE type, they only consumes Constructor() from the library instance with
> BASE type. They don't use PEIM or DXE type Constructor(), because they
> have no PeiService pointer or ImageHandle.
> 
> Thanks
> Liming
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jiewen Yao
> > Sent: Wednesday, February 20, 2019 7:55 PM
> > To: edk2-devel@lists.01.org
> > Cc: Gao, Liming 
> > Subject: [edk2] [PATCH] BaseTool/GenC: Fix build error when type is BASE
> or USER_DEFINED.
> >
> > https://bugzilla.tianocore.org/show_bug.cgi?id=1544
> >
> > 1) The GenC tool does not include the constructor/destructor for
> > USER_DEFINED module. It should be included.
> >
> > 2) The GenC tool includes the UnloadImage code for BASE module.
> > It should NOT be included.
> >
> > 3) The GenC tool uses EFI_STATUS and ASSERT_EFI_ERROR for BASE type.
> > It should use RETURN_STATUS and ASSERT_RETURN_ERROR.
> >
> > 4) The GenC tool miss DebugLib.h for BASE or USER_DEFINED module
> > AutoGen.c. Only Base.h is there. It should add Library/DebugLib.h.
> >
> > Cc: Bob Feng 
> > Cc: Liming Gao 
> > Cc: Yonghong Zhu 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jiewen Yao 
> > ---
> >  BaseTools/Source/Python/AutoGen/GenC.py | 14 +++---
> >  1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/BaseTools/Source/Python/AutoGen/GenC.py
> b/BaseTools/Source/Python/AutoGen/GenC.py
> > index 9700bf8527..c4bba8da17 100644
> > --- a/BaseTools/Source/Python/AutoGen/GenC.py
> > +++ b/BaseTools/Source/Python/AutoGen/GenC.py
> > @@ -684,7 +684,7 @@ ${Function} (
> >  gLibraryStructorCall = {
> >  SUP_MODULE_BASE  : TemplateString("""${BEGIN}
> >Status = ${Function} ();
> > -  ASSERT_EFI_ERROR (Status);${END}
> > +  ASSERT_RETURN_ERROR (Status);${END}
> >  """),
> >
> >  'PEI'   : TemplateString("""${BEGIN}
> > @@ -714,7 +714,7 @@ ProcessLibrary${Type}List (
> >VOID
> >)
> >  {
> > -${BEGIN}  EFI_STATUS  Status;
> > +${BEGIN}  RETURN_STATUS  Status;
> >  ${FunctionCall}${END}
> >  }
> >  """),
> > @@ -768,7 +768,7 @@ ${FunctionCall}${END}
> >  gBasicHeaderFile = "Base.h"
> >
> >  gModuleTypeHeaderFile = {
> > -SUP_MODULE_BASE  :   [gBasicHeaderFile],
> > +SUP_MODULE_BASE  :   [gBasicHeaderFile,
> "Library/DebugLib.h"],
> >  SUP_MODULE_SEC   :   ["PiPei.h",
> "Library/DebugLib.h"],
> >  SUP_MODULE_PEI_CORE  :   ["PiPei.h",
> "Library/DebugLib.h", "Library/PeiCoreEntryPoint.h"],
> >  SUP_MODULE_PEIM  :   ["PiPei.h",
> "Library/DebugLib.h", "Library/PeimEntryPoint.h"],
> > @@ -782,7 +782,7 @@ gModuleTypeHeaderFile = {
> >  SUP_MODULE_SMM_CORE  :   ["PiDxe.h",
> "Library/BaseLib.h", "Library/DebugLib.h", "Library/UefiDriverEntryPoint.h"],
> >  SUP_MODULE_MM_STANDALONE :   ["PiMm.h",
> "Library/BaseLib.h", "Library/DebugLib.h",
> > "Library/StandaloneMmDriverEntryPoint.h"],
> >  SUP_MODULE_MM_CORE_STANDALONE :  ["PiMm.h",
> "Library/BaseLib.h", "Library/DebugLib.h",
> > "Library/StandaloneMmCoreEntryPoint.h"],
> > -SUP_MODULE_USER_DEFINED  :   [gBasicHeaderFile]
> > +SUP_MODULE_USER_DEFINED  :   [gBasicHeaderFile,
> "Library/DebugLib.h"]
> >  }
> >
> >  ## Autogen internal worker macro to define DynamicEx PCD name
> includes both the TokenSpaceGuidName
> > @@ -1373,7 +1373,7 @@ def CreateLibraryConstructorCode(Info,
> AutoGenC, AutoGenH):
> >  if Info.IsLibrary:
> >  AutoGenH.Append("${BEGIN}${FunctionPrototype}${END}",
> Dict)
> >  else:
> > -if Info.ModuleType in [SUP_MODULE_BASE,
> SUP_MODULE_SEC]:
> > +if Info.ModuleType in [SUP_MODULE_BASE,
> SUP_MODULE_SEC, SUP_MODULE_USER_DEFINED]:
> >
> AutoGenC.Append(gLibraryString[SUP_MODULE_BASE].Replace(Dict))
> >  elif Info.ModuleType in SUP_MODULE_SET_PEI:
> >  AutoGenC.Append(gLibraryString['PEI'].Replace(Dict))
> > @@ -1435,7 +1435,7 @@ def CreateLibraryDestructorCode(Info,
> AutoGenC, AutoGenH):
> >  if Info.IsLibrary:
> >  AutoGenH.Append("${BEGIN}${FunctionPrototype}${END}",
> Dict)
> >  else:
> > -if Info.ModuleType in [SUP_MODULE_BASE,
> SUP_MODULE_SEC]:
> > +if Info.ModuleType in [SUP_MODULE_BASE,
> SUP_MODULE_SEC, SUP_MODULE_USER_DEFINED]:
> >
> AutoGenC.Append(gLibraryString[SUP_MODULE_BASE].Replace(Dict))
> >  elif Info.ModuleType in SUP_MODULE_SET_PEI:
> >  AutoGenC.Append(gLibraryString['PEI'].Replace(Dict))
> > @@ -1533,7 +1533,7 @@ def 

[edk2] [PATCH v2 1/1] SecurityPkg/HddPassword: Add Security feature set support for ATA dev

[Hao Wu]

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

This commit will add the 'Security feature set' support for ATA devices.

According to the AT Attachment 8 - ATA/ATAPI Command Set (ATA8-ACS)
specification, the Security feature set is an optional feature. In
summary, the feature is a password system that restricts access to user
data stored on an ATA device. A more detailed introduction of this feature
can be referred from the ATA8-ACS spec.

The HddPassword driver is composed of 2 parts:
* A DXE driver and
* A PEI driver

The DXE driver consumes EFI_ATA_PASS_THRU_PROTOCOL instances and installs
an HII GUI to manage the devices. If the managing device supports Security
feature set, the HII page will provide the user with the ability to
set/update/disable the password for this device. Also, if a password is
being set via the Security feature set, a popup window will show during
boot requesting the user to input password.

Another feature supported by this driver is that for those managing
devices with password set, they will be automatically unlocked during the
S3 resume. This is done by the co-work of the DXE driver and the PEI
driver:

The DXE driver will save the password and the identification information
for these devices into a LockBox, which is only allowed to restore during
S3 resume.

The PEI driver, during S3 resume, will restore the content in the LockBox
and will consume EDKII_PEI_ATA_PASS_THRU_PPI instances to unlock devices.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Chao Zhang 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 SecurityPkg/SecurityPkg.dsc   |6 +
 SecurityPkg/HddPassword/HddPasswordDxe.inf|   75 +
 SecurityPkg/HddPassword/HddPasswordPei.inf|   54 +
 SecurityPkg/HddPassword/HddPasswordCommon.h   |   61 +
 SecurityPkg/HddPassword/HddPasswordDxe.h  |  148 +
 SecurityPkg/HddPassword/HddPasswordHiiDataStruc.h |   63 +
 SecurityPkg/HddPassword/HddPasswordPei.h  |   42 +
 SecurityPkg/HddPassword/HddPassword.vfr   |  188 ++
 SecurityPkg/HddPassword/HddPasswordDxe.c  | 2814 
 SecurityPkg/HddPassword/HddPasswordPei.c  |  374 +++
 SecurityPkg/HddPassword/HddPasswordStrings.uni|   48 +
 11 files changed, 3873 insertions(+)

diff --git a/SecurityPkg/SecurityPkg.dsc b/SecurityPkg/SecurityPkg.dsc
index ab887e8c4d..5577ff0687 100644
--- a/SecurityPkg/SecurityPkg.dsc
+++ b/SecurityPkg/SecurityPkg.dsc
@@ -287,6 +287,12 @@
   SecurityPkg/Tcg/Opal/OpalPassword/OpalPasswordDxe.inf
   SecurityPkg/Tcg/Opal/OpalPassword/OpalPasswordPei.inf
 
+  #
+  # HDD Password solution
+  #
+  SecurityPkg/HddPassword/HddPasswordDxe.inf
+  SecurityPkg/HddPassword/HddPasswordPei.inf
+
 [BuildOptions]
MSFT:*_*_IA32_DLINK_FLAGS = /ALIGN:256
   INTEL:*_*_IA32_DLINK_FLAGS = /ALIGN:256
diff --git a/SecurityPkg/HddPassword/HddPasswordDxe.inf 
b/SecurityPkg/HddPassword/HddPasswordDxe.inf
new file mode 100644
index 00..7a3fc2f88c
--- /dev/null
+++ b/SecurityPkg/HddPassword/HddPasswordDxe.inf
@@ -0,0 +1,75 @@
+## @file
+#  HddPasswordDxe driver which is used to set/clear hdd password at attached 
harddisk
+#  devices.
+#
+#  Copyright (c) 2019, Intel Corporation. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  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]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = HddPasswordDxe
+  FILE_GUID  = 9BD549CD-86D1-4925-9F7D-3686DDD876FC
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+  ENTRY_POINT= HddPasswordDxeInit
+
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+#  VALID_ARCHITECTURES   = IA32 X64 IPF EBC
+#
+
+[Sources]
+  HddPasswordDxe.c
+  HddPasswordDxe.h
+  HddPasswordHiiDataStruc.h
+  HddPassword.vfr
+  HddPasswordStrings.uni
+  HddPasswordCommon.h
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  CryptoPkg/CryptoPkg.dec
+
+[LibraryClasses]
+  BaseLib
+  MemoryAllocationLib
+  UefiBootServicesTableLib
+  UefiDriverEntryPoint
+  UefiHiiServicesLib
+  UefiRuntimeServicesTableLib
+  DxeServicesTableLib
+  BaseMemoryLib
+  DebugLib
+  HiiLib
+  PrintLib
+  UefiLib
+  LockBoxLib
+  S3BootScriptLib
+  PciLib
+  BaseCryptLib
+
+[Guids]
+  gEfiIfrTianoGuid  ## CONSUMES ## GUID
+  gEfiEndOfDxeEventGroupGuid## CONSUMES ## Event
+  gS3StorageDeviceInitListGuid  ## SOMETIMES_PRODUCES ## 
UNDEFINED
+

[edk2] [PATCH v2 0/1] Add Security feature set support for ATA devices

[Hao Wu]

This patch actually depends on a series that is currently under review:
https://www.mail-archive.com/edk2-devel@lists.01.org/msg51681.html

One can get this patch together with the above-mentioned series at:
https://github.com/hwu25/edk2/tree/hddpassword_v2

V2 changes:
As suggested by Ray, simplifies the logic within PPI notification callback
to directly use the PPI instance provided by the input parameter of
callback function.


V1 history:

Uni-tests performed for the patch:
* Password can be set/update/disabled to an ATA device via the HII page;
* A popup windows will show up if a device is set with password. And after
  inputting the correct password, the data can be accessed. Otherwise,
  data cannot be accessed;
* A device with password set can be auto-unlocked during the S3 resume.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Chao Zhang 
Cc: Jiewen Yao 

Hao Wu (1):
  SecurityPkg/HddPassword: Add Security feature set support for ATA dev

 SecurityPkg/SecurityPkg.dsc   |6 +
 SecurityPkg/HddPassword/HddPasswordDxe.inf|   75 +
 SecurityPkg/HddPassword/HddPasswordPei.inf|   54 +
 SecurityPkg/HddPassword/HddPasswordCommon.h   |   61 +
 SecurityPkg/HddPassword/HddPasswordDxe.h  |  148 +
 SecurityPkg/HddPassword/HddPasswordHiiDataStruc.h |   63 +
 SecurityPkg/HddPassword/HddPasswordPei.h  |   42 +
 SecurityPkg/HddPassword/HddPassword.vfr   |  188 ++
 SecurityPkg/HddPassword/HddPasswordDxe.c  | 2814 
 SecurityPkg/HddPassword/HddPasswordPei.c  |  374 +++
 SecurityPkg/HddPassword/HddPasswordStrings.uni|   48 +
 11 files changed, 3873 insertions(+)
 create mode 100644 SecurityPkg/HddPassword/HddPasswordDxe.inf
 create mode 100644 SecurityPkg/HddPassword/HddPasswordPei.inf
 create mode 100644 SecurityPkg/HddPassword/HddPasswordCommon.h
 create mode 100644 SecurityPkg/HddPassword/HddPasswordDxe.h
 create mode 100644 SecurityPkg/HddPassword/HddPasswordHiiDataStruc.h
 create mode 100644 SecurityPkg/HddPassword/HddPasswordPei.h
 create mode 100644 SecurityPkg/HddPassword/HddPassword.vfr
 create mode 100644 SecurityPkg/HddPassword/HddPasswordDxe.c
 create mode 100644 SecurityPkg/HddPassword/HddPasswordPei.c
 create mode 100644 SecurityPkg/HddPassword/HddPasswordStrings.uni

-- 
2.12.0.windows.1

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

[edk2] [PATCH v6 11/13] MdeModulePkg/SmmLockBoxLib: Support LockBox enlarge in UpdateLockBox()

[Hao Wu]

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

This commit will add the support to enlarge a LockBox when using the
LockBoxLib API UpdateLockBox().

Please note that the new support will ONLY work for LockBox with attribute
LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY set.

The functional uni-test for the commit is available at:
https://github.com/hwu25/edk2/tree/lockbox_unitest

Cc: Jian J Wang 
Cc: Ray Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
Reviewed-by: Ray Ni 
Acked-by: Laszlo Ersek 
Reviewed-by: Star Zeng 
---
 MdeModulePkg/Include/Library/LockBoxLib.h |  7 +-
 MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.c  |  7 +-
 MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c |  5 +-
 MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c |  5 +-
 MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.c | 72 ++--
 5 files changed, 86 insertions(+), 10 deletions(-)

diff --git a/MdeModulePkg/Include/Library/LockBoxLib.h 
b/MdeModulePkg/Include/Library/LockBoxLib.h
index 5921731419..b457bd4241 100644
--- a/MdeModulePkg/Include/Library/LockBoxLib.h
+++ b/MdeModulePkg/Include/Library/LockBoxLib.h
@@ -2,7 +2,7 @@
   This library is only intended to be used by DXE modules that need save
   confidential information to LockBox and get it by PEI modules in S3 phase.
 
-Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.
 
 This program and the accompanying materials
 are licensed and made available under the terms and conditions
@@ -85,7 +85,10 @@ SetLockBoxAttributes (
   @retval RETURN_SUCCESSthe information is saved successfully.
   @retval RETURN_INVALID_PARAMETER  the Guid is NULL, or Buffer is NULL, or 
Length is 0.
   @retval RETURN_NOT_FOUND  the requested GUID not found.
-  @retval RETURN_BUFFER_TOO_SMALL   the original buffer to too small to hold 
new information.
+  @retval RETURN_BUFFER_TOO_SMALL   for lockbox without attribute 
LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY,
+the original buffer to too small to hold 
new information.
+  @retval RETURN_OUT_OF_RESOURCES   for lockbox with attribute 
LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY,
+no enough resource to save the information.
   @retval RETURN_ACCESS_DENIED  it is too late to invoke this interface
   @retval RETURN_NOT_STARTEDit is too early to invoke this interface
   @retval RETURN_UNSUPPORTEDthe service is not supported by 
implementaion.
diff --git a/MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.c 
b/MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.c
index c40dfea398..0c3a762a6f 100644
--- a/MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.c
+++ b/MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.c
@@ -1,6 +1,6 @@
 /** @file
 
-Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.
 
 This program and the accompanying materials
 are licensed and made available under the terms and conditions
@@ -76,7 +76,10 @@ SetLockBoxAttributes (
   @retval RETURN_SUCCESSthe information is saved successfully.
   @retval RETURN_INVALID_PARAMETER  the Guid is NULL, or Buffer is NULL, or 
Length is 0.
   @retval RETURN_NOT_FOUND  the requested GUID not found.
-  @retval RETURN_BUFFER_TOO_SMALL   the original buffer to too small to hold 
new information.
+  @retval RETURN_BUFFER_TOO_SMALL   for lockbox without attribute 
LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY,
+the original buffer to too small to hold 
new information.
+  @retval RETURN_OUT_OF_RESOURCES   for lockbox with attribute 
LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY,
+no enough resource to save the information.
   @retval RETURN_ACCESS_DENIED  it is too late to invoke this interface
   @retval RETURN_NOT_STARTEDit is too early to invoke this interface
   @retval RETURN_UNSUPPORTEDthe service is not supported by 
implementaion.
diff --git a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c 
b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c
index 0428decbac..db8322631c 100644
--- a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c
+++ b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c
@@ -300,7 +300,10 @@ SetLockBoxAttributes (
   @retval RETURN_SUCCESSthe information is saved successfully.
   @retval RETURN_INVALID_PARAMETER  the Guid is NULL, or Buffer is NULL, or 
Length is 0.
   @retval RETURN_NOT_FOUND  the requested GUID not found.
-  @retval RETURN_BUFFER_TOO_SMALL   the original buffer to too small to hold 
new information.
+  @retval RETURN_BUFFER_TOO_SMALL   for lockbox without attribute 
LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY,
+the original buffer to too small to hold 
new 

[edk2] [PATCH v6 12/13] OvmfPkg/LockBoxLib: Update the comments for API UpdateLockBox()

[Hao Wu]

The previous commit:
MdeModulePkg/SmmLockBoxLib: Support LockBox enlarge in UpdateLockBox()

adds the support to enlarge a LockBox when using the LockBoxLib API
UpdateLockBox().

This commit is to sync the API description comment of UpdateLockBox() with
its counterparts in MdeModulePkg.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
Reviewed-by: Laszlo Ersek 
Reviewed-by: Ray Ni 
---
 OvmfPkg/Library/LockBoxLib/LockBoxLib.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/Library/LockBoxLib/LockBoxLib.c 
b/OvmfPkg/Library/LockBoxLib/LockBoxLib.c
index 45481b9230..04233059f1 100644
--- a/OvmfPkg/Library/LockBoxLib/LockBoxLib.c
+++ b/OvmfPkg/Library/LockBoxLib/LockBoxLib.c
@@ -3,7 +3,7 @@
   Library implementing the LockBox interface for OVMF
 
   Copyright (C) 2013, Red Hat, Inc.
-  Copyright (c) 2010 - 2014, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials are licensed and made available
   under the terms and conditions of the BSD License which accompanies this
@@ -224,8 +224,13 @@ SetLockBoxAttributes (
   @retval RETURN_INVALID_PARAMETER  the Guid is NULL, or Buffer is NULL, or
 Length is 0.
   @retval RETURN_NOT_FOUND  the requested GUID not found.
-  @retval RETURN_BUFFER_TOO_SMALL   the original buffer to too small to hold
-new information.
+  @retval RETURN_BUFFER_TOO_SMALL   for lockbox without attribute
+LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY, the
+original buffer to too small to hold new
+information.
+  @retval RETURN_OUT_OF_RESOURCES   for lockbox with attribute
+LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY, no
+enough resource to save the information.
   @retval RETURN_ACCESS_DENIED  it is too late to invoke this interface
   @retval RETURN_NOT_STARTEDit is too early to invoke this interface
   @retval RETURN_UNSUPPORTEDthe service is not supported by
-- 
2.12.0.windows.1

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

[edk2] [PATCH v6 07/13] MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList LockBox

[Hao Wu]

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

For the NvmExpressPei driver, this commit will update the driver to
consume the S3StorageDeviceInitList LockBox in S3 phase. The purpose is to
perform an on-demand (partial) NVM Express device
enumeration/initialization to benefit the S3 resume performance.

Cc: Jian J Wang 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
Reviewed-by: Eric Dong 
Reviewed-by: Ray Ni 
---
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf |   8 +-
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h   |  36 +++
 MdeModulePkg/Bus/Pci/NvmExpressPei/DevicePath.c  |  53 +
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c   |  26 +
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiS3.c | 114 
 5 files changed, 236 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf 
b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
index 0666e5892b..22b703e971 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
+++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
@@ -40,6 +40,7 @@
   NvmExpressPeiHci.h
   NvmExpressPeiPassThru.c
   NvmExpressPeiPassThru.h
+  NvmExpressPeiS3.c
   NvmExpressPeiStorageSecurity.c
   NvmExpressPeiStorageSecurity.h
 
@@ -54,6 +55,7 @@
   BaseMemoryLib
   IoLib
   TimerLib
+  LockBoxLib
   PeimEntryPoint
 
 [Ppis]
@@ -64,9 +66,13 @@
   gEfiPeiVirtualBlockIo2PpiGuid  ## SOMETIMES_PRODUCES
   gEdkiiPeiStorageSecurityCommandPpiGuid ## SOMETIMES_PRODUCES
 
+[Guids]
+  gS3StorageDeviceInitListGuid   ## SOMETIMES_CONSUMES ## 
UNDEFINED
+
 [Depex]
   gEfiPeiMemoryDiscoveredPpiGuid AND
-  gEdkiiPeiNvmExpressHostControllerPpiGuid
+  gEdkiiPeiNvmExpressHostControllerPpiGuid AND
+  gEfiPeiMasterBootModePpiGuid
 
 [UserExtensions.TianoCore."ExtraFiles"]
   NvmExpressPeiExtra.uni
diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h 
b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
index 89666160a1..74e2daf511 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
+++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
@@ -267,6 +267,26 @@ NvmePeimEndOfPei (
   );
 
 /**
+  Get the size of the current device path instance.
+
+  @param[in]  DevicePath A pointer to the EFI_DEVICE_PATH_PROTOCOL
+ structure.
+  @param[out] InstanceSize   The size of the current device path 
instance.
+  @param[out] EntireDevicePathEndIndicate whether the instance is the last
+ one in the device path strucure.
+
+  @retval EFI_SUCCESSThe size of the current device path instance is 
fetched.
+  @retval Others Fails to get the size of the current device path 
instance.
+
+**/
+EFI_STATUS
+GetDevicePathInstanceSize (
+  IN  EFI_DEVICE_PATH_PROTOCOL*DevicePath,
+  OUT UINTN   *InstanceSize,
+  OUT BOOLEAN *EntireDevicePathEnd
+  );
+
+/**
   Check the validity of the device path of a NVM Express host controller.
 
   @param[in] DevicePath  A pointer to the EFI_DEVICE_PATH_PROTOCOL
@@ -309,4 +329,20 @@ NvmeBuildDevicePath (
   OUT EFI_DEVICE_PATH_PROTOCOL**DevicePath
   );
 
+/**
+  Determine if a specific NVM Express controller can be skipped for S3 phase.
+
+  @param[in]  HcDevicePath  Device path of the controller.
+  @param[in]  HcDevicePathLengthLength of the device path specified by
+HcDevicePath.
+
+  @retvalThe number of ports that need to be enumerated.
+
+**/
+BOOLEAN
+NvmeS3SkipThisController (
+  IN  EFI_DEVICE_PATH_PROTOCOL*HcDevicePath,
+  IN  UINTN   HcDevicePathLength
+  );
+
 #endif
diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/DevicePath.c 
b/MdeModulePkg/Bus/Pci/NvmExpressPei/DevicePath.c
index fd30ad519f..ff95f20329 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressPei/DevicePath.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/DevicePath.c
@@ -89,6 +89,59 @@ NextDevicePathNode (
 }
 
 /**
+  Get the size of the current device path instance.
+
+  @param[in]  DevicePath A pointer to the EFI_DEVICE_PATH_PROTOCOL
+ structure.
+  @param[out] InstanceSize   The size of the current device path 
instance.
+  @param[out] EntireDevicePathEndIndicate whether the instance is the last
+ one in the device path strucure.
+
+  @retval EFI_SUCCESSThe size of the current device path instance is 
fetched.
+  @retval Others Fails to get the size of the current device path 
instance.
+
+**/
+EFI_STATUS
+GetDevicePathInstanceSize (
+  IN  EFI_DEVICE_PATH_PROTOCOL*DevicePath,
+  OUT UINTN   *InstanceSize,
+  OUT BOOLEAN *EntireDevicePathEnd
+  )
+{
+  EFI_DEVICE_PATH_PROTOCOL*Walker;
+
+  if (DevicePath == NULL || 

[edk2] [PATCH v6 09/13] MdeModulePkg/SmmLockBoxLib: Use 'DEBUG_' prefix instead of 'EFI_D_'

[Hao Wu]

This commit is out of the scope for BZ-1409. It is a coding style
refinement for the SmmLockBoxLib.

More specifically, the commit will remove all the debug message display
level macros starting with 'EFI_D_' and replace them with macros starting
with 'DEBUG_'.

Cc: Jian J Wang 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
Reviewed-by: Ray Ni 
Reviewed-by: Laszlo Ersek 
Reviewed-by: Star Zeng 
---
 MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c | 22 +++---
 MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c | 26 +++
 MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.c | 78 ++--
 3 files changed, 63 insertions(+), 63 deletions(-)

diff --git a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c 
b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c
index ac8bcd2ff7..0428decbac 100644
--- a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c
+++ b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c
@@ -1,6 +1,6 @@
 /** @file
 
-Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.
 
 This program and the accompanying materials
 are licensed and made available under the terms and conditions
@@ -153,7 +153,7 @@ SaveLockBox (
   UINT8   *CommBuffer;
   UINTN   CommSize;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib SaveLockBox - Enter\n"));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib SaveLockBox - Enter\n"));
 
   //
   // Basic check
@@ -199,7 +199,7 @@ SaveLockBox (
 
   Status = (EFI_STATUS)LockBoxParameterSave->Header.ReturnStatus;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib SaveLockBox - Exit (%r)\n", Status));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib SaveLockBox - Exit (%r)\n", Status));
 
   //
   // Done
@@ -235,7 +235,7 @@ SetLockBoxAttributes (
   UINT8 *CommBuffer;
   UINTN CommSize;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib SetLockBoxAttributes - Enter\n"));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib SetLockBoxAttributes - Enter\n"));
 
   //
   // Basic check
@@ -281,7 +281,7 @@ SetLockBoxAttributes (
 
   Status = (EFI_STATUS)LockBoxParameterSetAttributes->Header.ReturnStatus;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib SetLockBoxAttributes - Exit (%r)\n", 
Status));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib SetLockBoxAttributes - Exit (%r)\n", 
Status));
 
   //
   // Done
@@ -322,7 +322,7 @@ UpdateLockBox (
   UINT8 *CommBuffer;
   UINTN CommSize;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib UpdateLockBox - Enter\n"));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib UpdateLockBox - Enter\n"));
 
   //
   // Basic check
@@ -369,7 +369,7 @@ UpdateLockBox (
 
   Status = (EFI_STATUS)LockBoxParameterUpdate->Header.ReturnStatus;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib UpdateLockBox - Exit (%r)\n", Status));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib UpdateLockBox - Exit (%r)\n", Status));
 
   //
   // Done
@@ -411,7 +411,7 @@ RestoreLockBox (
   UINT8  *CommBuffer;
   UINTN  CommSize;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib RestoreLockBox - Enter\n"));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib RestoreLockBox - Enter\n"));
 
   //
   // Basic check
@@ -467,7 +467,7 @@ RestoreLockBox (
 
   Status = (EFI_STATUS)LockBoxParameterRestore->Header.ReturnStatus;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib RestoreLockBox - Exit (%r)\n", 
Status));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib RestoreLockBox - Exit (%r)\n", 
Status));
 
   //
   // Done
@@ -496,7 +496,7 @@ RestoreAllLockBoxInPlace (
   UINT8   *CommBuffer;
   UINTN   CommSize;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib RestoreAllLockBoxInPlace - Enter\n"));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib RestoreAllLockBoxInPlace - Enter\n"));
 
   SmmCommunication = LockBoxGetSmmCommProtocol ();
   if (SmmCommunication == NULL) {
@@ -532,7 +532,7 @@ RestoreAllLockBoxInPlace (
 
   Status = (EFI_STATUS)LockBoxParameterRestoreAllInPlace->Header.ReturnStatus;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib RestoreAllLockBoxInPlace - Exit 
(%r)\n", Status));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib RestoreAllLockBoxInPlace - Exit 
(%r)\n", Status));
 
   //
   // Done
diff --git a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c 
b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
index 8a168663c4..9f73480070 100644
--- a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
+++ b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
@@ -1,6 +1,6 @@
 /** @file
 
-Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.
 
 This program and the accompanying materials
 are licensed and made available under the terms and conditions
@@ 

[edk2] [PATCH v6 01/13] MdeModulePkg: Add definitions for ATA AHCI host controller PPI

[Hao Wu]

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

This commit will add the definitions for ATA AHCI host controller PPI. The
purpose of the PPI in to provide:

* MMIO base address
* Controller identification information (DevicePath)

for ATA host controllers working under AHCI mode.

Cc: Jian J Wang 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
Reviewed-by: Ray Ni 
Reviewed-by: Eric Dong 
---
 MdeModulePkg/MdeModulePkg.dec|  3 +
 MdeModulePkg/Include/Ppi/AtaAhciController.h | 89 
 2 files changed, 92 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index e5c32d15ed..4411185073 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -480,6 +480,9 @@
   ## Include/Ppi/NvmExpressHostController.h
   gEdkiiPeiNvmExpressHostControllerPpiGuid  = { 0xcae3aa63, 0x676f, 0x4da3, { 
0xbd, 0x50, 0x6c, 0xc5, 0xed, 0xde, 0x9a, 0xad } }
 
+  ## Include/Ppi/AtaAhciController.h
+  gEdkiiPeiAtaAhciHostControllerPpiGuid = { 0x61dd33ea, 0x421f, 0x4cc0, { 
0x89, 0x29, 0xff, 0xee, 0xa9, 0xa1, 0xa2, 0x61 } }
+
 [Protocols]
   ## Load File protocol provides capability to load and unload EFI image into 
memory and execute it.
   #  Include/Protocol/LoadPe32Image.h
diff --git a/MdeModulePkg/Include/Ppi/AtaAhciController.h 
b/MdeModulePkg/Include/Ppi/AtaAhciController.h
new file mode 100644
index 00..2bdd53ff36
--- /dev/null
+++ b/MdeModulePkg/Include/Ppi/AtaAhciController.h
@@ -0,0 +1,89 @@
+/** @file
+
+  Copyright (c) 2019, Intel Corporation. All rights reserved.
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  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 _EDKII_ATA_AHCI_HOST_CONTROLLER_PPI_H_
+#define _EDKII_ATA_AHCI_HOST_CONTROLLER_PPI_H_
+
+#include 
+
+///
+/// Global ID for the EDKII_ATA_AHCI_HOST_CONTROLLER_PPI.
+///
+#define EDKII_ATA_AHCI_HOST_CONTROLLER_PPI_GUID \
+  { \
+0x61dd33ea, 0x421f, 0x4cc0, { 0x89, 0x29, 0xff, 0xee, 0xa9, 0xa1, 0xa2, 
0x61 } \
+  }
+
+//
+// Forward declaration for the EDKII_ATA_AHCI_HOST_CONTROLLER_PPI.
+//
+typedef struct _EDKII_ATA_AHCI_HOST_CONTROLLER_PPI  
EDKII_ATA_AHCI_HOST_CONTROLLER_PPI;
+
+/**
+  Get the MMIO base address of ATA AHCI host controller.
+
+  @param[in]  This The PPI instance pointer.
+  @param[in]  ControllerId The ID of the ATA AHCI host controller.
+  @param[out] MmioBar  The MMIO base address of the controller.
+
+  @retval EFI_SUCCESS  The operation succeeds.
+  @retval EFI_INVALID_PARAMETERThe parameters are invalid.
+  @retval EFI_NOT_FOUNDThe specified ATA AHCI host controller not 
found.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EDKII_ATA_AHCI_HC_GET_MMIO_BAR) (
+  IN  EDKII_ATA_AHCI_HOST_CONTROLLER_PPI*This,
+  IN  UINT8 ControllerId,
+  OUT UINTN *MmioBar
+  );
+
+/**
+  Get the device path of ATA AHCI host controller.
+
+  @param[in]  This The PPI instance pointer.
+  @param[in]  ControllerId The ID of the ATA AHCI host controller.
+  @param[out] DevicePathLength The length of the device path in bytes 
specified
+   by DevicePath.
+  @param[out] DevicePath   The device path of ATA AHCI host controller.
+   This field re-uses EFI Device Path Protocol 
as
+   defined by Section 10.2 EFI Device Path 
Protocol
+   of UEFI 2.7 Specification.
+
+  @retval EFI_SUCCESS  The operation succeeds.
+  @retval EFI_INVALID_PARAMETERThe parameters are invalid.
+  @retval EFI_NOT_FOUNDThe specified ATA AHCI host controller not 
found.
+  @retval EFI_OUT_OF_RESOURCES The operation fails due to lack of 
resources.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EDKII_ATA_AHCI_HC_GET_DEVICE_PATH) (
+  IN  EDKII_ATA_AHCI_HOST_CONTROLLER_PPI*This,
+  IN  UINT8 ControllerId,
+  OUT UINTN *DevicePathLength,
+  OUT EFI_DEVICE_PATH_PROTOCOL  **DevicePath
+  );
+
+//
+// This PPI contains a set of services to interact with the ATA AHCI host 
controller.
+//
+struct _EDKII_ATA_AHCI_HOST_CONTROLLER_PPI {
+  EDKII_ATA_AHCI_HC_GET_MMIO_BAR   GetAhciHcMmioBar;
+  EDKII_ATA_AHCI_HC_GET_DEVICE_PATHGetAhciHcDevicePath;
+};
+
+extern EFI_GUID gEdkiiPeiAtaAhciHostControllerPpiGuid;
+
+#endif
-- 
2.12.0.windows.1

___
edk2-devel mailing list

[edk2] [PATCH v6 00/13] Split the S3 PEI phase HW init codes from Opal driver

[Hao Wu]

The series is also available at:
https://github.com/hwu25/edk2/tree/opal_remodel_v6

V6 changes:
For patch 6, rename driver internal function NvmeCheckHcDevicePath() to
NvmeIsHcDevicePathValid().

For patch 7, add more comments for purpose of selective NVM Express
controller initialization during S3 resume.

For patch 8:
* Rename driver internal function AhciCheckHcDevicePath() to
  AhciIsHcDevicePathValid();
* Add more comments for purpose of selective port enumeration/
  initialization on a ATA AHCI controller during S3 resume.

For patch 6~8, since no functional impact, I still keep the 'Reviewed-by'
from Eric.

For patch 13, as suggested by Ray, simplifies the logic within PPI
notification callback to directly use the PPI instance provided by the
input parameter of callback function.


V5 history:
For patch 11, as suggested by Star:
* Refine the UpdateLockBox() API description comment to be more precise;
* Ensure the parameter for macro 'EFI_SIZE_TO_PAGES' is of type 'UINTN';

Since the changes are minor, I still keep the origin 'Reviewed-by' from
Ray and the 'Acked-by' tag from Laszlo.

For patch 12, sync the UpdateLockBox() API description comment with the
change made in patch 11.

Since the changes are minor, I still keep the origin 'Reviewed-by' from
Laszlo an Ray.

For patch 13, additional handling logic to prevent NULL pointer
de-reference, just as what has been done in commit
d72d8561fbe03a64e01c2ad57a93777de4b9ae2f.


V4 history:

As suggested by Laszlo, add a new patch to sync the API description
comment for UpdateLockBox() in file
"OvmfPkg/Library/LockBoxLib/LockBoxLib.c" with its counterparts in
MdeModulePkg.

For patch 13 (compared with patch 12 in V3), minor type refinement in
structure definition 'OPAL_DEVICE_LOCKBOX_DATA'.

V3 history:

For patch 2, reuse the definitions within AtaPassThru protocol header file
to reduce code duplication.

For patch 4, add detailed comments to illustrate the content that will be
stored in the newly introduced LockBox.

For patch 6, device path validity check refinement within function
NvmeCheckHcDevicePath().

For patch 7:
* Remove a redundant check within function NvmeS3SkipThisController();
* Replace internal implementation of GetNextDevicePathInstance() with
  GetDevicePathInstanceSize(), which avoids unnecessary memory allocation.

For patch 8:
* Device path validity check refinement within function
  AhciCheckHcDevicePath();
* Remove a redundant check within function AhciS3GetEumeratePorts();
* Replace internal implementation of GetNextDevicePathInstance() with
  GetDevicePathInstanceSize(), which avoids unnecessary memory allocation.

For patch 11:
* Remove the ASSERT() for memory allocation failure. Since error handling
  codes already exist, no new code is added for this;
* Refine the codes to only allocate new SMM buffer when the required
  LockBox size is greater than the size of origin pages allocated;
* Add additional parameter check for 'Offset' & 'Length' to prevent
  potential numeric overflow.


V2 history:

For patch 8, the new series removes the codes to produce the Block IO PPIs
from the AhciPei driver.

The task to produce the Block IO services is out of the scope of BZ-1409
(actually covered by BZ-1483). And we will later propose seperate patch(s)
to address this.

V1 history:

For the below 2 types of storage device:

1. NVM Express devices;
2. ATA hard disk devices working under AHCI mode.

the OpalPassword driver supports auto-unlocking those devices during S3
resume.

Current implementation of the OpalPassword driver is handling the device
initialization (using boot script to restore the host controller PCI
configuration space also counts) in the PEI phase during S3 resume by
itself.

Meanwhile, the NvmExpressPei driver in MdeModulePkg also handles the NVME
device initialization during the PEI phase in order to produce the Block
IO PPI.

Moreover, there is a Bugzilla request (BZ-1483) for adding the Block IO
PPI support for ATA device as well. So there is likely to be an PEI driver
for ATA device that will handle the ATA device initialization.

In order to remove code duplication, the series will split the S3 phase
device initialization related codes out from the OpalPassword driver. And
let the existing NvmExpressPei driver and the new AhciPei driver to handle
the task.

After this remodel, NvmExpressPei and AhciPei drivers will produce a PPI
called Storage Security Command PPI. And the OpalPassword driver will
consume this PPI to perform the device auto-unlock in S3 resume.


Patch   1~4: Add the definitions of PPIs and GUIDs;
Patch 5: Refinement for the NvmExpressPei driver;
Patch   6~7: Update the NvmExpressPei driver to produce the PPI needed by
 OpalPassword;
Patch 8: Add the Ahci mode ATA device support in the PEI phase, it
 will produce the PPI needed by OpalPassword;
Patch  9~10: Refinements for the SmmLockBoxLib;
Patch11: Support LockBox enlarge for LockBoxLib API UpdateLockBox();

[edk2] [PATCH v6 02/13] MdeModulePkg: Add definitions for EDKII PEI ATA PassThru PPI

[Hao Wu]

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

This commit will add the definitions for EDKII PEI ATA PassThru PPI. This
PPI will provide services that allow ATA commands to be sent to ATA
devices attached to an ATA controller in the PEI phase.

More specifically, the PPI will provide services to:

* Send ATA commands to an ATA device (by service 'PassThru');
* Get the list of the attached ATA device on a controller (by services
  'GetNextPort' and 'GetNextDevice');
* Get the identification information (DevicePath) of the underlying ATA
  host controller (by service 'GetDevicePath').

Cc: Jian J Wang 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
Reviewed-by: Ray Ni 
Reviewed-by: Eric Dong 
---
 MdeModulePkg/MdeModulePkg.dec  |   3 +
 MdeModulePkg/Include/Ppi/AtaPassThru.h | 219 
 2 files changed, 222 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 4411185073..8efb19e626 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -483,6 +483,9 @@
   ## Include/Ppi/AtaAhciController.h
   gEdkiiPeiAtaAhciHostControllerPpiGuid = { 0x61dd33ea, 0x421f, 0x4cc0, { 
0x89, 0x29, 0xff, 0xee, 0xa9, 0xa1, 0xa2, 0x61 } }
 
+  ## Include/Ppi/AtaPassThru.h
+  gEdkiiPeiAtaPassThruPpiGuid   = { 0xa16473fd, 0xd474, 0x4c89, { 
0xae, 0xc7, 0x90, 0xb8, 0x3c, 0x73, 0x86, 0x9  } }
+
 [Protocols]
   ## Load File protocol provides capability to load and unload EFI image into 
memory and execute it.
   #  Include/Protocol/LoadPe32Image.h
diff --git a/MdeModulePkg/Include/Ppi/AtaPassThru.h 
b/MdeModulePkg/Include/Ppi/AtaPassThru.h
new file mode 100644
index 00..78bdaef9e2
--- /dev/null
+++ b/MdeModulePkg/Include/Ppi/AtaPassThru.h
@@ -0,0 +1,219 @@
+/** @file
+
+  Copyright (c) 2019, Intel Corporation. All rights reserved.
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  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 _EDKII_ATA_PASS_THRU_PPI_H_
+#define _EDKII_ATA_PASS_THRU_PPI_H_
+
+#include 
+#include 
+
+///
+/// Global ID for the EDKII_PEI_ATA_PASS_THRU_PPI.
+///
+#define EDKII_PEI_ATA_PASS_THRU_PPI_GUID \
+  { \
+0xa16473fd, 0xd474, 0x4c89, { 0xae, 0xc7, 0x90, 0xb8, 0x3c, 0x73, 0x86, 
0x9 } \
+  }
+
+//
+// Forward declaration for the EDKII_PEI_ATA_PASS_THRU_PPI.
+//
+typedef struct _EDKII_PEI_ATA_PASS_THRU_PPI  EDKII_PEI_ATA_PASS_THRU_PPI;
+
+//
+// Revision The revision to which the ATA Pass Thru PPI interface adheres.
+//  All future revisions must be backwards compatible.
+//  If a future version is not back wards compatible it is not the 
same GUID.
+//
+#define EDKII_PEI_ATA_PASS_THRU_PPI_REVISION0x0001
+
+
+/**
+  Sends an ATA command to an ATA device that is attached to the ATA controller.
+
+  @param[in] This  The PPI instance pointer.
+  @param[in] Port  The port number of the ATA device to 
send
+   the command.
+  @param[in] PortMultiplierPortThe port multiplier port number of the 
ATA
+   device to send the command.
+   If there is no port multiplier, then 
specify
+   0x.
+  @param[in,out] PacketA pointer to the ATA command to send to
+   the ATA device specified by Port and
+   PortMultiplierPort.
+
+  @retval EFI_SUCCESS  The ATA command was sent by the host. For
+   bi-directional commands, InTransferLength 
bytes
+   were transferred from InDataBuffer. For 
write
+   and bi-directional commands, 
OutTransferLength
+   bytes were transferred by OutDataBuffer.
+  @retval EFI_NOT_FOUNDThe specified ATA device is not found.
+  @retval EFI_INVALID_PARAMETERThe contents of Acb are invalid. The ATA 
command
+   was not sent, so no additional status 
information
+   is available.
+  @retval EFI_BAD_BUFFER_SIZE  The ATA command was not executed. The number
+   of bytes that could be transferred is 
returned
+   in InTransferLength. For write and 
bi-directional
+   commands, OutTransferLength bytes were 
transferred
+   by OutDataBuffer.
+  @retval EFI_NOT_READY

[edk2] [PATCH v6 03/13] MdeModulePkg: Add definitions for Storage Security Command PPI

[Hao Wu]

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

This commit will add the definitions for Storage Security Command (SSC)
PPI. This PPI will be be used to abstract mass storage devices to allow
code running in the PEI phase to send security protocol commands to mass
storage devices without specific knowledge of the type of device or
controller that manages the device.

More specifically, the PPI will provide services to:

* Get the number of mass storage devices managed by a instance of the SSC
  PPI (by service 'GetNumberofDevices');
* Get the identification information (DevicePath) of a managing mass
  storage devices (by service 'GetDevicePath');
* Send security protocol commands to mass storage devices (by services
  'ReceiveData' and 'SendData').

Cc: Jian J Wang 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
Reviewed-by: Ray Ni 
Reviewed-by: Eric Dong 
---
 MdeModulePkg/MdeModulePkg.dec |   3 +
 MdeModulePkg/Include/Ppi/StorageSecurityCommand.h | 283 
 2 files changed, 286 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 8efb19e626..7f646d7702 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -483,6 +483,9 @@
   ## Include/Ppi/AtaAhciController.h
   gEdkiiPeiAtaAhciHostControllerPpiGuid = { 0x61dd33ea, 0x421f, 0x4cc0, { 
0x89, 0x29, 0xff, 0xee, 0xa9, 0xa1, 0xa2, 0x61 } }
 
+  ## Include/Ppi/StorageSecurityCommand.h
+  gEdkiiPeiStorageSecurityCommandPpiGuid= { 0x35de0b4e, 0x30fb, 0x46c3, { 
0xbd, 0x84, 0x1f, 0xdb, 0xa1, 0x58, 0xbb, 0x56 } }
+
   ## Include/Ppi/AtaPassThru.h
   gEdkiiPeiAtaPassThruPpiGuid   = { 0xa16473fd, 0xd474, 0x4c89, { 
0xae, 0xc7, 0x90, 0xb8, 0x3c, 0x73, 0x86, 0x9  } }
 
diff --git a/MdeModulePkg/Include/Ppi/StorageSecurityCommand.h 
b/MdeModulePkg/Include/Ppi/StorageSecurityCommand.h
new file mode 100644
index 00..cc1688dabb
--- /dev/null
+++ b/MdeModulePkg/Include/Ppi/StorageSecurityCommand.h
@@ -0,0 +1,283 @@
+/** @file
+
+  Copyright (c) 2019, Intel Corporation. All rights reserved.
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  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 _EDKII_STORAGE_SECURITY_COMMAND_PPI_H_
+#define _EDKII_STORAGE_SECURITY_COMMAND_PPI_H_
+
+#include 
+
+///
+/// Global ID for the EDKII_PEI_STORAGE_SECURITY_CMD_PPI.
+///
+#define EDKII_PEI_STORAGE_SECURITY_CMD_PPI_GUID \
+  { \
+0x35de0b4e, 0x30fb, 0x46c3, { 0xbd, 0x84, 0x1f, 0xdb, 0xa1, 0x58, 0xbb, 
0x56 } \
+  }
+
+//
+// Forward declaration for the EDKII_PEI_STORAGE_SECURITY_CMD_PPI.
+//
+typedef struct _EDKII_PEI_STORAGE_SECURITY_CMD_PPI  
EDKII_PEI_STORAGE_SECURITY_CMD_PPI;
+
+//
+// Revision The revision to which the Storage Security Command interface 
adheres.
+//  All future revisions must be backwards compatible.
+//  If a future version is not back wards compatible it is not the 
same GUID.
+//
+#define EDKII_STORAGE_SECURITY_PPI_REVISION  0x0001
+
+
+/**
+  Gets the count of storage security devices that one specific driver detects.
+
+  @param[in]  This   The PPI instance pointer.
+  @param[out] NumberofDevicesThe number of storage security devices 
discovered.
+
+  @retval EFI_SUCCESS  The operation performed successfully.
+  @retval EFI_INVALID_PARAMETERThe parameters are invalid.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EDKII_PEI_STORAGE_SECURITY_GET_NUMBER_DEVICES) (
+  IN  EDKII_PEI_STORAGE_SECURITY_CMD_PPI*This,
+  OUT UINTN *NumberofDevices
+  );
+
+/**
+  Gets the device path of a specific storage security device.
+
+  @param[in]  This The PPI instance pointer.
+  @param[in]  DeviceIndex  Specifies the storage security device to 
which
+   the function wants to talk. Because the 
driver
+   that implements Storage Security Command 
PPIs
+   will manage multiple storage devices, the 
PPIs
+   that want to talk to a single device must 
specify
+   the device index that was assigned during 
the
+   enumeration process. This index is a number 
from
+   one to NumberofDevices.
+  @param[out] DevicePathLength The length of the device path in bytes 
specified
+   by DevicePath.
+  @param[out] DevicePath   The device path of storage security device.
+   This 

[edk2] [PATCH v6 10/13] MdeModulePkg/SmmLockBox(PEI): Remove an ASSERT in RestoreLockBox()

[Hao Wu]

This commit is out of the scope for BZ-1409. It is a refinement for the
PEI library instance within SmmLockBoxLib.

For the below ASSERT statement within function RestoreLockBox():
  Status = SmmCommunicationPpi->Communicate (
  SmmCommunicationPpi,
  [0],
  
  );
  if (Status == EFI_NOT_STARTED) {
//
// Pei SMM communication not ready yet, so we access SMRAM directly
//
DEBUG ((DEBUG_INFO, "SmmLockBoxPeiLib Communicate - (%r)\n", Status));
Status = InternalRestoreLockBoxFromSmram (Guid, Buffer, Length);
LockBoxParameterRestore->Header.ReturnStatus = (UINT64)Status;
if (Length != NULL) {
  LockBoxParameterRestore->Length = (UINT64)*Length;
}
  }
  ASSERT_EFI_ERROR (Status);

It is possible for previous codes to return an error status that is
possible for happen. One example is that, when the 'if' statement
'if (Status == EFI_NOT_STARTED) {' is entered, function
InternalRestoreLockBoxFromSmram() is possible to return 'BUFFER_TOO_SMALL'
if the caller of RestoreLockBox() provides a buffer that is too small to
hold the content of LockBox.

Thus, this commit will remove the ASSERT here.

Please note that the current implementation of RestoreLockBox() is
handling the above-mentioned error case properly, so no additional error
handling codes are needed here.

Cc: Jian J Wang 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
Reviewed-by: Ray Ni 
Reviewed-by: Laszlo Ersek 
Reviewed-by: Star Zeng 
---
 MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c 
b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
index 9f73480070..8c3e65bc96 100644
--- a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
+++ b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
@@ -623,7 +623,6 @@ RestoreLockBox (
   LockBoxParameterRestore->Length = (UINT64)*Length;
 }
   }
-  ASSERT_EFI_ERROR (Status);
 
   if (Length != NULL) {
 *Length = (UINTN)LockBoxParameterRestore->Length;
-- 
2.12.0.windows.1

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

[edk2] [PATCH v6 06/13] MdeModulePkg/NvmExpressPei: Add logic to produce SSC PPI

[Hao Wu]

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

For the NvmExpressPei driver, this commit will add codes to produce the
Storage Security Command PPI if the underlying NVM Express controller
supports the Security Send and Security Receive commands.

Cc: Jian J Wang 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
Reviewed-by: Eric Dong 
Reviewed-by: Ray Ni 
---
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf  |  10 +-
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h|  58 ++-
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiHci.h |  20 +-
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiStorageSecurity.h | 247 

 MdeModulePkg/Bus/Pci/NvmExpressPei/DevicePath.c   | 231 
+++
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c| 143 +--
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiHci.c |  32 +-
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiStorageSecurity.c | 423 

 8 files changed, 1075 insertions(+), 89 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf 
b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
index 9591572fec..0666e5892b 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
+++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
@@ -2,7 +2,7 @@
 #  The NvmExpressPei driver is used to manage non-volatile memory subsystem
 #  which follows NVM Express specification at PEI phase.
 #
-#  Copyright (c) 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2018 - 2019, Intel Corporation. All rights reserved.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
@@ -30,6 +30,7 @@
 #
 
 [Sources]
+  DevicePath.c
   DmaMem.c
   NvmExpressPei.c
   NvmExpressPei.h
@@ -39,6 +40,8 @@
   NvmExpressPeiHci.h
   NvmExpressPeiPassThru.c
   NvmExpressPeiPassThru.h
+  NvmExpressPeiStorageSecurity.c
+  NvmExpressPeiStorageSecurity.h
 
 [Packages]
   MdePkg/MdePkg.dec
@@ -54,11 +57,12 @@
   PeimEntryPoint
 
 [Ppis]
-  gEfiPeiVirtualBlockIoPpiGuid   ## PRODUCES
-  gEfiPeiVirtualBlockIo2PpiGuid  ## PRODUCES
   gEdkiiPeiNvmExpressHostControllerPpiGuid   ## CONSUMES
   gEdkiiIoMmuPpiGuid ## CONSUMES
   gEfiEndOfPeiSignalPpiGuid  ## CONSUMES
+  gEfiPeiVirtualBlockIoPpiGuid   ## SOMETIMES_PRODUCES
+  gEfiPeiVirtualBlockIo2PpiGuid  ## SOMETIMES_PRODUCES
+  gEdkiiPeiStorageSecurityCommandPpiGuid ## SOMETIMES_PRODUCES
 
 [Depex]
   gEfiPeiMemoryDiscoveredPpiGuid AND
diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h 
b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
index 0135eca6f0..89666160a1 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
+++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -44,6 +45,7 @@ typedef struct _PEI_NVME_CONTROLLER_PRIVATE_DATA  
PEI_NVME_CONTROLLER_PRIVATE_DA
 #include "NvmExpressPeiHci.h"
 #include "NvmExpressPeiPassThru.h"
 #include "NvmExpressPeiBlockIo.h"
+#include "NvmExpressPeiStorageSecurity.h"
 
 //
 // NVME PEI driver implementation related definitions
@@ -90,10 +92,15 @@ struct _PEI_NVME_NAMESPACE_INFO {
 struct _PEI_NVME_CONTROLLER_PRIVATE_DATA {
   UINT32Signature;
   UINTN MmioBase;
+  UINTN DevicePathLength;
+  EFI_DEVICE_PATH_PROTOCOL  *DevicePath;
+
   EFI_PEI_RECOVERY_BLOCK_IO_PPI BlkIoPpi;
   EFI_PEI_RECOVERY_BLOCK_IO2_PPIBlkIo2Ppi;
+  EDKII_PEI_STORAGE_SECURITY_CMD_PPIStorageSecurityPpi;
   EFI_PEI_PPI_DESCRIPTORBlkIoPpiList;
   EFI_PEI_PPI_DESCRIPTORBlkIo2PpiList;
+  EFI_PEI_PPI_DESCRIPTORStorageSecurityPpiList;
   EFI_PEI_NOTIFY_DESCRIPTOR EndOfPeiNotifyList;
 
   //
@@ -139,11 +146,13 @@ struct _PEI_NVME_CONTROLLER_PRIVATE_DATA {
   PEI_NVME_NAMESPACE_INFO   *NamespaceInfo;
 };
 
-#define GET_NVME_PEIM_HC_PRIVATE_DATA_FROM_THIS_BLKIO(a) \
+#define GET_NVME_PEIM_HC_PRIVATE_DATA_FROM_THIS_BLKIO(a)   \
   CR (a, PEI_NVME_CONTROLLER_PRIVATE_DATA, BlkIoPpi, 
NVME_PEI_CONTROLLER_PRIVATE_DATA_SIGNATURE)
-#define GET_NVME_PEIM_HC_PRIVATE_DATA_FROM_THIS_BLKIO2(a)\
+#define GET_NVME_PEIM_HC_PRIVATE_DATA_FROM_THIS_BLKIO2(a)  \
   CR (a, PEI_NVME_CONTROLLER_PRIVATE_DATA, BlkIo2Ppi, 
NVME_PEI_CONTROLLER_PRIVATE_DATA_SIGNATURE)
-#define GET_NVME_PEIM_HC_PRIVATE_DATA_FROM_THIS_NOTIFY(a)\
+#define GET_NVME_PEIM_HC_PRIVATE_DATA_FROM_THIS_STROAGE_SECURITY(a)\
+  CR (a, PEI_NVME_CONTROLLER_PRIVATE_DATA, StorageSecurityPpi, 

[edk2] [PATCH v6 04/13] MdeModulePkg: Add GUID for LockBox to save storage dev to init in S3

[Hao Wu]

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

This commit will add the GUID definitions for LockBox which is used to
save a list of storage devices that need to get initialized during the S3
resume.

The content of the LockBox will be a DevicePath structure that contains
zero or more DevicePath instances. Each instance denotes a storage device
that needs to get initialized during the S3 resume.

The producers of the content of this LockBox will be drivers like
OpalPassword DXE driver. This kind of drivers requires some specific
storage devices to be initialized during the PEI phase of in S3 resume.
(For the OpalPassword case, it requires the managing devices to be
automatically unlocked during the S3 resume).

The attribute of the LockBox should be set to
LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY.

The consumers of the content of this LockBox will be PEI storage device
controller/bus drivers (e.g. NvmExpressPei) during S3 resume. This kind of
drivers can use the DevicePath instances stored in the LockBox to get a
list of devices that need to get initialized. In such way, an on-demand
(partial) device enumeration/initialization can be performed to benefit
the S3 resume performance.

Cc: Jian J Wang 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
Reviewed-by: Ray Ni 
Reviewed-by: Eric Dong 
---
 MdeModulePkg/MdeModulePkg.dec   |  3 +
 MdeModulePkg/Include/Guid/S3StorageDeviceInitList.h | 64 
 2 files changed, 67 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 7f646d7702..a2130bc439 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -422,6 +422,9 @@
   ## Include/Guid/S3SmmInitDone.h
   gEdkiiS3SmmInitDoneGuid = { 0x8f9d4825, 0x797d, 0x48fc, { 0x84, 0x71, 0x84, 
0x50, 0x25, 0x79, 0x2e, 0xf6 } }
 
+  ## Include/Guid/S3StorageDeviceInitList.h
+  gS3StorageDeviceInitListGuid = { 0x310e9b8c, 0xcf90, 0x421e, { 0x8e, 0x9b, 
0x9e, 0xef, 0xb6, 0x17, 0xc8, 0xef } }
+
 [Ppis]
   ## Include/Ppi/AtaController.h
   gPeiAtaControllerPpiGuid   = { 0xa45e60d1, 0xc719, 0x44aa, { 0xb0, 0x7a, 
0xaa, 0x77, 0x7f, 0x85, 0x90, 0x6d }}
diff --git a/MdeModulePkg/Include/Guid/S3StorageDeviceInitList.h 
b/MdeModulePkg/Include/Guid/S3StorageDeviceInitList.h
new file mode 100644
index 00..bd300b2696
--- /dev/null
+++ b/MdeModulePkg/Include/Guid/S3StorageDeviceInitList.h
@@ -0,0 +1,64 @@
+/** @file
+  Define the LockBox GUID for list of storage devices need to be initialized in
+  S3.
+
+  Copyright (c) 2019, Intel Corporation. All rights reserved.
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions
+  of the BSD License 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 __S3_STORAGE_DEVICE_INIT_LIST_H__
+#define __S3_STORAGE_DEVICE_INIT_LIST_H__
+
+#define S3_STORAGE_DEVICE_INIT_LIST \
+  { \
+0x310e9b8c, 0xcf90, 0x421e, { 0x8e, 0x9b, 0x9e, 0xef, 0xb6, 0x17, 0xc8, 
0xef } \
+  }
+
+//
+// The LockBox will store a DevicePath structure that contains one or more
+// DevicePath instances. Each instance denotes a storage device that needs to
+// get initialized during the S3 resume.
+//
+// For example, if there is only one storage device stored in the list, the
+// content of this LockBox will be:
+//
+// +---+
+// | DevPath Instance #1   |
+// | (Terminated by an End of Hardware Device Path node|
+// |  with an End Entire Device Path sub-type) |
+// +---+
+//
+// If there are n (n > 1) storage devices in the list, the content of this
+// LockBox will be:
+//
+// +---+
+// | DevPath Instance #1   |
+// | (Terminated by an End of Hardware Device Path node|
+// |  with an End This Instance of a Device Path sub-type) |
+// +---+
+// | DevPath Instance #2   |
+// | (Terminated by an End of Hardware Device Path node|
+// |  with an End This Instance of a Device Path sub-type) |
+// +---+
+// |...|
+// +---+
+// | DevPath Instance #n   |
+// | (Terminated by an End of Hardware Device Path node|
+// |  with an End Entire Device Path sub-type) |
+// +---+
+//
+// The 

[edk2] [PATCH v6 05/13] MdeModulePkg/NvmExpressPei: Avoid updating the module-level variable

[Hao Wu]

This commit is out of the scope for BZ-1409. The commit will remove the
call of RegisterForShadow() at the entry point of the driver. By doing so,
the driver is now possible to be executed without being re-loaded into
permanent memory.

Thus, this commit will update the NvmExpressPei driver to avoid updating
the content of a global variable.

Cc: Jian J Wang 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
Reviewed-by: Ray Ni 
---
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h |  12 +-
 MdeModulePkg/Bus/Pci/NvmExpressPei/DmaMem.c| 153 +++-
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c |  11 +-
 3 files changed, 92 insertions(+), 84 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h 
b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
index 0bd62c2459..0135eca6f0 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
+++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
@@ -2,7 +2,7 @@
   The NvmExpressPei driver is used to manage non-volatile memory subsystem
   which follows NVM Express specification at PEI phase.
 
-  Copyright (c) 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2018 - 2019, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions
@@ -147,13 +147,9 @@ struct _PEI_NVME_CONTROLLER_PRIVATE_DATA {
   CR (a, PEI_NVME_CONTROLLER_PRIVATE_DATA, EndOfPeiNotifyList, 
NVME_PEI_CONTROLLER_PRIVATE_DATA_SIGNATURE)
 
 
-/**
-  Initialize IOMMU.
-**/
-VOID
-IoMmuInit (
-  VOID
-  );
+//
+// Internal functions
+//
 
 /**
   Allocates pages that are suitable for an OperationBusMasterCommonBuffer or
diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/DmaMem.c 
b/MdeModulePkg/Bus/Pci/NvmExpressPei/DmaMem.c
index 51b48d38dd..cb629c16b0 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressPei/DmaMem.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/DmaMem.c
@@ -1,7 +1,7 @@
 /** @file
   The DMA memory help function.
 
-  Copyright (c) 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2018 - 2019, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions
@@ -16,7 +16,33 @@
 
 #include "NvmExpressPei.h"
 
-EDKII_IOMMU_PPI  *mIoMmu;
+/**
+  Get IOMMU PPI.
+
+  @return Pointer to IOMMU PPI.
+
+**/
+EDKII_IOMMU_PPI *
+GetIoMmu (
+  VOID
+  )
+{
+  EFI_STATUS Status;
+  EDKII_IOMMU_PPI*IoMmu;
+
+  IoMmu  = NULL;
+  Status = PeiServicesLocatePpi (
+ ,
+ 0,
+ NULL,
+ (VOID **) 
+ );
+  if (!EFI_ERROR (Status) && (IoMmu != NULL)) {
+return IoMmu;
+  }
+
+  return NULL;
+}
 
 /**
   Provides the controller-specific addresses required to access system memory 
from a
@@ -46,18 +72,21 @@ IoMmuMap (
   OUT VOID  **Mapping
   )
 {
-  EFI_STATUS  Status;
-  UINT64  Attribute;
-
-  if (mIoMmu != NULL) {
-Status = mIoMmu->Map (
-   mIoMmu,
-   Operation,
-   HostAddress,
-   NumberOfBytes,
-   DeviceAddress,
-   Mapping
-   );
+  EFI_STATUS Status;
+  UINT64 Attribute;
+  EDKII_IOMMU_PPI*IoMmu;
+
+  IoMmu = GetIoMmu ();
+
+  if (IoMmu != NULL) {
+Status = IoMmu->Map (
+ IoMmu,
+ Operation,
+ HostAddress,
+ NumberOfBytes,
+ DeviceAddress,
+ Mapping
+ );
 if (EFI_ERROR (Status)) {
   return EFI_OUT_OF_RESOURCES;
 }
@@ -78,11 +107,11 @@ IoMmuMap (
   ASSERT(FALSE);
   return EFI_INVALID_PARAMETER;
 }
-Status = mIoMmu->SetAttribute (
-   mIoMmu,
-   *Mapping,
-   Attribute
-   );
+Status = IoMmu->SetAttribute (
+  IoMmu,
+  *Mapping,
+  Attribute
+  );
 if (EFI_ERROR (Status)) {
   return Status;
 }
@@ -108,11 +137,14 @@ IoMmuUnmap (
   IN VOID  *Mapping
   )
 {
-  EFI_STATUS  Status;
+  EFI_STATUS Status;
+  EDKII_IOMMU_PPI*IoMmu;
+
+  IoMmu = GetIoMmu ();
 
-  if (mIoMmu != NULL) {
-Status = mIoMmu->SetAttribute (mIoMmu, Mapping, 0);
-Status = mIoMmu->Unmap (mIoMmu, Mapping);
+  if (IoMmu != NULL) {
+Status = IoMmu->SetAttribute (IoMmu, Mapping, 0);
+Status = IoMmu->Unmap (IoMmu, Mapping);
   } else {
 Status = EFI_SUCCESS;
   }
@@ -148,39 +180,42 @@ IoMmuAllocateBuffer (
   EFI_STATUSStatus;
   UINTN NumberOfBytes;
   EFI_PHYSICAL_ADDRESS  HostPhyAddress;
+  EDKII_IOMMU_PPI   *IoMmu;
 
   *HostAddress = NULL;
   *DeviceAddress = 0;
 
-  if 

Re: [edk2] [PATCH 00/10] Fix PEI Core issue during TemporaryRamMigration

[Ni, Ray]

> -Original Message-
> From: Justen, Jordan L 
> Sent: Thursday, February 21, 2019 1:44 AM
> To: Gao, Liming ; Ni, Ray ; edk2-
> de...@lists.01.org
> Cc: Wu, Hao A ; Anthony Perard
> ; Laszlo Ersek ; Zeng,
> Star 
> Subject: Re: [PATCH 00/10] Fix PEI Core issue during TemporaryRamMigration
> 
> On 2019-02-20 05:27:21, Ni, Ray wrote:
> > On 2/19/2019 9:25 PM, Gao, Liming wrote:
> > > Ray:
> > >
> > >  Now, real platform has no side effect. So, only TempRamDone
> > >  PPI is produced. For emulator platform, is there any side
> > >  effect when both Temporary RAM and Permanent RAM are enabled?
> > >
> >
> > No side effect when both of T-RAM and P-RAM are enabled.
> > Which means no side effect when neither of the PPIs is produced.
> > But for demo purpose, I think producing TemporaryRamDone PPI makes
> sense.
> 
> In addition to being a demo/sample, it also provides a check that no modules
> are accessing temp-ram after temp-ram should no longer be used.
> 
> > I will work out patches for EmulatorPkg to produce TemoraryRamDone.
> 
> I think we should first fix TemporaryRamSupport usage. Otherwise, we are
> just hiding the bug.
> 
> Have you tried these patches to verify that they fix the issue in your setup?
> Have you taken a look at the patches to see what problem is being fixed?

I feel the change to PeiCore is a bit complex and introduce additional deps 
(assembly).
Behavior of ARM and x86 becomes different. (The patch only fixes x86 issue.)
Given there is no real requirement on this, I prefer to not change PeiCore.

> 
> -Jordan
> 
> >
> > >> -Original Message-
> > >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> > >> Of Ni, Ray
> > >> Sent: Tuesday, February 19, 2019 10:46 AM
> > >> To: Justen, Jordan L ;
> > >> edk2-devel@lists.01.org
> > >> Cc: Wu, Hao A ; Anthony Perard
> > >> ; Laszlo Ersek ;
> > >> Zeng, Star 
> > >> Subject: Re: [edk2] [PATCH 00/10] Fix PEI Core issue during
> > >> TemporaryRamMigration
> > >>
> > >> Jordan,
> > >> I find many real platforms do not implement the temporary ram
> > >> migration PPI and rely on the PeiCore migration  logic.
> > >> So perhaps TemporaryRamMigration PPI was added to help platform to
> > >> destroy the temporary RAM (CAR in x86 platform).
> > >> But with the introduction of TemporaryRamDone PPI, maybe the
> > >> TemporaryRamMigration PPI can be retired.
> > >> The logic in PeiCore to call TemporaryRamMigration is just for
> > >> backward compatibility.
> > >> If that's true, do you still need to enhance PeiCore?
> > >>
> > >> For the Emulator case, I already found without
> > >> TemporaryRamMigration the platform can still boot.
> > >>
> > >> Does OVMF hard-depend on TemporaryRamMigration? Or it can reply
> on
> > >> the PeiCore migration logic + TemporaryDone PPI?
> > >>
> > >> Thanks,
> > >> Ray
> > >>
> > >>> -Original Message-
> > >>> From: Justen, Jordan L 
> > >>> Sent: Monday, February 18, 2019 12:12 PM
> > >>> To: edk2-devel@lists.01.org
> > >>> Cc: Justen, Jordan L ; Liu Yu
> > >>> ; Andrew Fish ;
> Anthony
> > >>> Perard ; Ard Biesheuvel
> > >>> ; Wu, Hao A ;
> Wang,
> > >>> Jian J ; Julien Grall
> > >>> ; Laszlo Ersek ; Ni,
> > >>> Ray ; Zeng, Star 
> > >>> Subject: [PATCH 00/10] Fix PEI Core issue during
> > >>> TemporaryRamMigration
> > >>>
> > >>> https://github.com/jljusten/edk2.git temp-ram-support
> > >>>
> > >>> This series fixes an issue that, while rare, is possible based on
> > >>> the way the TemporaryRamSupport PPI is defined along with how it
> > >>> is used by the PEI Core.
> > >>>
> > >>> Liu Yu reported a boot issue with EmulatorPkg, which I believe was
> > >>> caused by this issue.
> > >>>
> > >>> The details of the issue are described in the commit message of
> > >>> the
> > >>> "MdeModePkg/Core/Pei: Add code path to allow assembly temp-ram
> > >>> migration" patch.
> > >>>
> > >>> Along with this, I added a few Temporary RAM patches for
> > >>> EmulatorPkg and OvmfPkg.
> > >>>
> > >>> Cc: Liu Yu 
> > >>> Cc: Andrew Fish 
> > >>> Cc: Anthony Perard 
> > >>> Cc: Ard Biesheuvel 
> > >>> Cc: Hao Wu 
> > >>> Cc: Jian J Wang 
> > >>> Cc: Julien Grall 
> > >>> Cc: Laszlo Ersek 
> > >>> Cc: Ray Ni 
> > >>> Cc: Star Zeng 
> > >>>
> > >>> Jordan Justen (10):
> > >>>EmulatorPkg/build.sh: Fix missing usage of -b BUILDTARGET
> parameter
> > >>>EmulatorPkg/Unix/Host: Use PcdInitValueInTempStack to init temp-
> ram
> > >>>EmulatorPkg/Sec: Replace assembly temp-ram support with C code
> > >>>EmulatorPkg/Sec: Disable optimizations for TemporaryRamMigration
> > >>>  function
> > >>>OvmfPkg/Sec: Swap TemporaryRam Stack and Heap locations
> > >>>OvmfPkg/Sec: Disable optimizations for TemporaryRamMigration
> > >>>MdeModePkg/Core/Pei: Add code path to allow assembly temp-ram
> > >>>  migration
> > >>>MdeModulePkg/Core/Pei: Use assembly for X64
> TemporaryRamMigration
> > >>>MdeModulePkg/Core/Pei: Use assembly for IA32
> TemporaryRamMigration
> 

Re: [edk2] [PATCH] MdeModulePkg/ScsiDiskDxe: Support Storage Security Command Protocol

[Gao, Liming]

Christopher:
  Please separate the patch per package. The patch can't cross the different 
packages. 

Thanks
Liming
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Zurcher, Christopher J
>Sent: Thursday, February 21, 2019 7:56 AM
>To: edk2-devel@lists.01.org
>Subject: [edk2] [PATCH] MdeModulePkg/ScsiDiskDxe: Support Storage
>Security Command Protocol
>
>BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1546
>
>This patch implements the EFI_STORAGE_SECURITY_COMMAND_PROTOCOL
>in the
>ScsiDiskDxe driver (and supporting library, UefiScsiLib).
>
>Support is currently limited to the RPMB Well-known LUN for UFS devices.
>
>Cc: Jiewen Yao 
>Cc: Jian J Wang 
>Cc: Liming Gao 
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Christopher J Zurcher 
>---
> MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c|   5 +-
> MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ComponentName.c |  14 +-
> MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c  | 510
>+-
> MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h  | 171 +++-
> MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf |   3 +-
> MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c |  19 +-
> MdePkg/Include/IndustryStandard/Scsi.h|  48 +-
> MdePkg/Include/Library/UefiScsiLib.h  | 126 +-
> MdePkg/Include/Protocol/ScsiIo.h  |   9 +-
> MdePkg/Library/UefiScsiLib/UefiScsiLib.c  | 205 -
> 10 files changed, 1064 insertions(+), 46 deletions(-)
>
>diff --git a/MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c
>b/MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c
>index 11a7f2a927..0b4c51764e 100644
>--- a/MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c
>+++ b/MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c
>@@ -2,7 +2,7 @@
>   SCSI Bus driver that layers on every SCSI Pass Thru and
>   Extended SCSI Pass Thru protocol in the system.
>
>-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
>+Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
>License
> which accompanies this distribution.  The full text of the license may be 
> found
>at
>@@ -1374,7 +1374,8 @@ DiscoverScsiDevice (
> goto Done;
>   }
>
>-  if (0x1e >= InquiryData->Peripheral_Type && InquiryData-
>>Peripheral_Type >= 0xa) {
>+  if ((InquiryData->Peripheral_Type >= EFI_SCSI_TYPE_RESERVED_LOW) &&
>+  (InquiryData->Peripheral_Type <= EFI_SCSI_TYPE_RESERVED_HIGH)) {
> ScsiDeviceFound = FALSE;
> goto Done;
>   }
>diff --git a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ComponentName.c
>b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ComponentName.c
>index f2da7af8fb..cba833d4ca 100644
>--- a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ComponentName.c
>+++ b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ComponentName.c
>@@ -1,7 +1,7 @@
> /** @file
>   UEFI Component Name(2) protocol implementation for SCSI disk driver.
>
>-Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
>+Copyright (c) 2004 - 2019, Intel Corporation. All rights reserved.
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
>License
> which accompanies this distribution.  The full text of the license may be 
> found
>at
>@@ -173,9 +173,9 @@ ScsiDiskComponentNameGetControllerName (
>   OUT CHAR16  **ControllerName
>   )
> {
>-  EFI_STATUSStatus;
>-  SCSI_DISK_DEV *ScsiDiskDevice;
>-  EFI_BLOCK_IO_PROTOCOL *BlockIo;
>+  EFI_STATUS  Status;
>+  SCSI_DISK_DEV   *ScsiDiskDevice;
>+  EFI_DISK_INFO_PROTOCOL  *DiskInfo;
>
>   //
>   // This is a device driver, so ChildHandle must be NULL.
>@@ -200,8 +200,8 @@ ScsiDiskComponentNameGetControllerName (
>   //
>   Status = gBS->OpenProtocol (
>   ControllerHandle,
>-  ,
>-  (VOID **) ,
>+  ,
>+  (VOID **) ,
>   gScsiDiskDriverBinding.DriverBindingHandle,
>   ControllerHandle,
>   EFI_OPEN_PROTOCOL_GET_PROTOCOL
>@@ -211,7 +211,7 @@ ScsiDiskComponentNameGetControllerName (
> return Status;
>   }
>
>-  ScsiDiskDevice = SCSI_DISK_DEV_FROM_BLKIO (BlockIo);
>+  ScsiDiskDevice = SCSI_DISK_DEV_FROM_DISKINFO (DiskInfo);
>
>   return LookupUnicodeString2 (
>Language,
>diff --git a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
>b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
>index 0d63c85e44..75eb13ca20 100644
>--- a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
>+++ b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
>@@ -1,7 +1,7 @@
> /** @file
>   SCSI disk driver that layers on every SCSI IO protocol in the system.
>
>-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
>+Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> This program and the accompanying 

[edk2] [PATCH] MdeModulePkg/ScsiDiskDxe: Support Storage Security Command Protocol

[Zurcher, Christopher J]

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

This patch implements the EFI_STORAGE_SECURITY_COMMAND_PROTOCOL in the
ScsiDiskDxe driver (and supporting library, UefiScsiLib).

Support is currently limited to the RPMB Well-known LUN for UFS devices.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Christopher J Zurcher 
---
 MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c|   5 +-
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ComponentName.c |  14 +-
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c  | 510 +-
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h  | 171 +++-
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf |   3 +-
 MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c |  19 +-
 MdePkg/Include/IndustryStandard/Scsi.h|  48 +-
 MdePkg/Include/Library/UefiScsiLib.h  | 126 +-
 MdePkg/Include/Protocol/ScsiIo.h  |   9 +-
 MdePkg/Library/UefiScsiLib/UefiScsiLib.c  | 205 -
 10 files changed, 1064 insertions(+), 46 deletions(-)

diff --git a/MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c 
b/MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c
index 11a7f2a927..0b4c51764e 100644
--- a/MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c
+++ b/MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c
@@ -2,7 +2,7 @@
   SCSI Bus driver that layers on every SCSI Pass Thru and
   Extended SCSI Pass Thru protocol in the system.
 
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -1374,7 +1374,8 @@ DiscoverScsiDevice (
 goto Done;
   }
 
-  if (0x1e >= InquiryData->Peripheral_Type && InquiryData->Peripheral_Type >= 
0xa) {
+  if ((InquiryData->Peripheral_Type >= EFI_SCSI_TYPE_RESERVED_LOW) &&
+  (InquiryData->Peripheral_Type <= EFI_SCSI_TYPE_RESERVED_HIGH)) {
 ScsiDeviceFound = FALSE;
 goto Done;
   }
diff --git a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ComponentName.c 
b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ComponentName.c
index f2da7af8fb..cba833d4ca 100644
--- a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ComponentName.c
+++ b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ComponentName.c
@@ -1,7 +1,7 @@
 /** @file
   UEFI Component Name(2) protocol implementation for SCSI disk driver.
 
-Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2004 - 2019, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -173,9 +173,9 @@ ScsiDiskComponentNameGetControllerName (
   OUT CHAR16  **ControllerName
   )
 {
-  EFI_STATUSStatus;
-  SCSI_DISK_DEV *ScsiDiskDevice;
-  EFI_BLOCK_IO_PROTOCOL *BlockIo;
+  EFI_STATUS  Status;
+  SCSI_DISK_DEV   *ScsiDiskDevice;
+  EFI_DISK_INFO_PROTOCOL  *DiskInfo;
 
   //
   // This is a device driver, so ChildHandle must be NULL.
@@ -200,8 +200,8 @@ ScsiDiskComponentNameGetControllerName (
   //
   Status = gBS->OpenProtocol (
   ControllerHandle,
-  ,
-  (VOID **) ,
+  ,
+  (VOID **) ,
   gScsiDiskDriverBinding.DriverBindingHandle,
   ControllerHandle,
   EFI_OPEN_PROTOCOL_GET_PROTOCOL
@@ -211,7 +211,7 @@ ScsiDiskComponentNameGetControllerName (
 return Status;
   }
 
-  ScsiDiskDevice = SCSI_DISK_DEV_FROM_BLKIO (BlockIo);
+  ScsiDiskDevice = SCSI_DISK_DEV_FROM_DISKINFO (DiskInfo);
 
   return LookupUnicodeString2 (
Language,
diff --git a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c 
b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
index 0d63c85e44..75eb13ca20 100644
--- a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
+++ b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
@@ -1,7 +1,7 @@
 /** @file
   SCSI disk driver that layers on every SCSI IO protocol in the system.
 
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -157,7 +157,9 @@ ScsiDiskDriverBindingSupported (
 
   Status = ScsiIo->GetDeviceType (ScsiIo, );
   if (!EFI_ERROR (Status)) {
-if ((DeviceType == EFI_SCSI_TYPE_DISK) || (DeviceType == 
EFI_SCSI_TYPE_CDROM)) {
+if ((DeviceType == EFI_SCSI_TYPE_DISK) ||
+(DeviceType == EFI_SCSI_TYPE_CDROM) ||
+(DeviceType == 

Re: [edk2] Intel Platforms in Bugzilla

[Kinney, Michael D]

Hi Michael,

Done.  Some of these new components need more detailed descriptions.
Please follow up with how you want those filled in.

Thanks,

Mike

> -Original Message-
> From: Kubacki, Michael A
> Sent: Tuesday, February 19, 2019 5:31 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D 
> Subject: Intel Platforms in Bugzilla
> 
> Hi Mike,
> 
> The devel-MinPlatform branch in the edk2-platforms repo
> is being used to develop Intel platform code. We plan
> to move this work to the master branch in edk2-
> platforms after a refactor in the MinPlatformPkg.
> 
> There's a need to submit feature requests and bugs
> against this code now. Do you think we could add the
> AdvancedFeaturePkg, ClevoOpenBoardPkg,
> KabylakeOpenBoardPkg, MinPlatformPkg, and
> PurleyOpenBoardPkg to the EDK2 Platforms product on
> Bugzilla?
> 
> Regards,
> Michael

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

Re: [edk2] [PATCH 00/10] Fix PEI Core issue during TemporaryRamMigration

[Jordan Justen]

On 2019-02-20 05:27:21, Ni, Ray wrote:
> On 2/19/2019 9:25 PM, Gao, Liming wrote:
> > Ray:
> > 
> >  Now, real platform has no side effect. So, only TempRamDone
> >  PPI is produced. For emulator platform, is there any side
> >  effect when both Temporary RAM and Permanent RAM are enabled?
> > 
> 
> No side effect when both of T-RAM and P-RAM are enabled.
> Which means no side effect when neither of the PPIs is produced.
> But for demo purpose, I think producing TemporaryRamDone PPI makes sense.

In addition to being a demo/sample, it also provides a check that no
modules are accessing temp-ram after temp-ram should no longer be
used.

> I will work out patches for EmulatorPkg to produce TemoraryRamDone.

I think we should first fix TemporaryRamSupport usage. Otherwise, we
are just hiding the bug.

Have you tried these patches to verify that they fix the issue in your
setup? Have you taken a look at the patches to see what problem is
being fixed?

-Jordan

> 
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ni, 
> >> Ray
> >> Sent: Tuesday, February 19, 2019 10:46 AM
> >> To: Justen, Jordan L ; edk2-devel@lists.01.org
> >> Cc: Wu, Hao A ; Anthony Perard 
> >> ; Laszlo Ersek ; Zeng, Star
> >> 
> >> Subject: Re: [edk2] [PATCH 00/10] Fix PEI Core issue during 
> >> TemporaryRamMigration
> >>
> >> Jordan,
> >> I find many real platforms do not implement the temporary ram migration
> >> PPI and rely on the PeiCore migration  logic.
> >> So perhaps TemporaryRamMigration PPI was added to help platform to
> >> destroy the temporary RAM (CAR in x86 platform).
> >> But with the introduction of TemporaryRamDone PPI, maybe the
> >> TemporaryRamMigration PPI can be retired.
> >> The logic in PeiCore to call TemporaryRamMigration is just for backward
> >> compatibility.
> >> If that's true, do you still need to enhance PeiCore?
> >>
> >> For the Emulator case, I already found without TemporaryRamMigration
> >> the platform can still boot.
> >>
> >> Does OVMF hard-depend on TemporaryRamMigration? Or it can reply on
> >> the PeiCore migration logic + TemporaryDone PPI?
> >>
> >> Thanks,
> >> Ray
> >>
> >>> -Original Message-
> >>> From: Justen, Jordan L 
> >>> Sent: Monday, February 18, 2019 12:12 PM
> >>> To: edk2-devel@lists.01.org
> >>> Cc: Justen, Jordan L ; Liu Yu
> >>> ; Andrew Fish ; Anthony
> >>> Perard ; Ard Biesheuvel
> >>> ; Wu, Hao A ; Wang, Jian
> >>> J ; Julien Grall ; Laszlo 
> >>> Ersek
> >>> ; Ni, Ray ; Zeng, Star
> >>> 
> >>> Subject: [PATCH 00/10] Fix PEI Core issue during TemporaryRamMigration
> >>>
> >>> https://github.com/jljusten/edk2.git temp-ram-support
> >>>
> >>> This series fixes an issue that, while rare, is possible based on the way 
> >>> the
> >>> TemporaryRamSupport PPI is defined along with how it is used by the PEI
> >>> Core.
> >>>
> >>> Liu Yu reported a boot issue with EmulatorPkg, which I believe was caused 
> >>> by
> >>> this issue.
> >>>
> >>> The details of the issue are described in the commit message of the
> >>> "MdeModePkg/Core/Pei: Add code path to allow assembly temp-ram
> >>> migration" patch.
> >>>
> >>> Along with this, I added a few Temporary RAM patches for EmulatorPkg and
> >>> OvmfPkg.
> >>>
> >>> Cc: Liu Yu 
> >>> Cc: Andrew Fish 
> >>> Cc: Anthony Perard 
> >>> Cc: Ard Biesheuvel 
> >>> Cc: Hao Wu 
> >>> Cc: Jian J Wang 
> >>> Cc: Julien Grall 
> >>> Cc: Laszlo Ersek 
> >>> Cc: Ray Ni 
> >>> Cc: Star Zeng 
> >>>
> >>> Jordan Justen (10):
> >>>EmulatorPkg/build.sh: Fix missing usage of -b BUILDTARGET parameter
> >>>EmulatorPkg/Unix/Host: Use PcdInitValueInTempStack to init temp-ram
> >>>EmulatorPkg/Sec: Replace assembly temp-ram support with C code
> >>>EmulatorPkg/Sec: Disable optimizations for TemporaryRamMigration
> >>>  function
> >>>OvmfPkg/Sec: Swap TemporaryRam Stack and Heap locations
> >>>OvmfPkg/Sec: Disable optimizations for TemporaryRamMigration
> >>>MdeModePkg/Core/Pei: Add code path to allow assembly temp-ram
> >>>  migration
> >>>MdeModulePkg/Core/Pei: Use assembly for X64 TemporaryRamMigration
> >>>MdeModulePkg/Core/Pei: Use assembly for IA32 TemporaryRamMigration
> >>>OvmfPkg/Sec: Fill Temp Ram after TemporaryRamMigration
> >>>
> >>>   EmulatorPkg/Sec/Ia32/SwitchRam.S  | 95 ---
> >>>   EmulatorPkg/Sec/Ia32/SwitchRam.asm| 94 --
> >>>   EmulatorPkg/Sec/Ia32/TempRam.c| 65 -
> >>>   EmulatorPkg/Sec/Sec.c | 76 ++-
> >>>   EmulatorPkg/Sec/Sec.inf   | 13 +--
> >>>   EmulatorPkg/Sec/X64/SwitchRam.S   | 72 --
> >>>   EmulatorPkg/Sec/X64/SwitchRam.asm | 76 ---
> >>>   EmulatorPkg/Unix/Host/Host.c  |  2 +-
> >>>   EmulatorPkg/Unix/Host/Host.inf|  1 +
> >>>   EmulatorPkg/build.sh  | 10 +-
> >>>   

Re: [edk2] [PATCH edk2-platforms v2 17/18] Hisilicon/D0x: Delete some header files

[Leif Lindholm]

Hi Ming,

Thank you for this rework.

However, can you move it first in the series, so that it's obvious
this series contains no changes to these headers (because they have
all happened in edk2-non-osi)?

Regards,

Leif

On Wed, Feb 20, 2019 at 03:28:36PM +0800, Ming Huang wrote:
> As some interfaces exposed only by implementations in edk2-non-osi,
> so delete corresponding header files and modify code to make build.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang 
> ---
>  Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.inf
>   |   1 +
>  Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf   
>   |   2 +-
>  Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.inf
>   |   1 +
>  Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf   
>   |   1 +
>  Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.inf
>   |   1 +
>  Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.inf   
>   |   1 +
>  Silicon/Hisilicon/Drivers/Smbios/MemorySubClassDxe/MemorySubClassDxe.inf 
>   |   1 +
>  
> Silicon/Hisilicon/Drivers/Smbios/ProcessorSubClassDxe/ProcessorSubClassDxe.inf
>  |   1 +
>  Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf 
>   |   2 +-
>  Silicon/Hisilicon/Drivers/VirtualEhciPciIo/VirtualEhciPciIo.inf  
>   |   1 +
>  Silicon/Hisilicon/Hi1610/Drivers/IoInitDxe/IoInitDxe.inf 
>   |   1 +
>  Silicon/Hisilicon/Library/BmcConfigBootLib/BmcConfigBootLib.inf  
>   |   1 +
>  Silicon/Hisilicon/Library/I2CLib/I2CLib.inf  
>   |   1 +
>  Silicon/Hisilicon/Library/I2CLib/I2CLibRuntime.inf   
>   |   1 +
>  Silicon/Hisilicon/Hi1610/Include/Library/SerdesLib.h 
>   |  22 
>  Silicon/Hisilicon/Hi1616/Include/Library/SerdesLib.h 
>   |  22 
>  Silicon/Hisilicon/Include/Library/IpmiCmdLib.h   
>   | 110 ---
>  Silicon/Hisilicon/Include/Library/LpcLib.h   
>   | 113 
>  Silicon/Hisilicon/Include/Library/OemAddressMapLib.h 
>   |  45 
>  Silicon/Hisilicon/Include/Library/PlatformSysCtrlLib.h   
>   | 112 ---
>  20 files changed, 14 insertions(+), 426 deletions(-)
> 
> diff --git a/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.inf 
> b/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.inf
> index c65cf7b6dd9f..90e40ae2b393 100644
> --- a/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.inf
> +++ b/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.inf
> @@ -30,6 +30,7 @@ [Packages]
>MdeModulePkg/MdeModulePkg.dec
>  
>ArmPkg/ArmPkg.dec
> +  Silicon/Hisilicon/HisiliconNonOsi.dec
>Silicon/Hisilicon/HisiPkg.dec
>  
>  [LibraryClasses]
> diff --git 
> a/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf 
> b/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf
> index 0fa7fdf80fa8..c0195b2fa9cf 100644
> --- a/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf
> +++ b/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf
> @@ -30,7 +30,7 @@ [Packages]
>MdePkg/MdePkg.dec
>MdeModulePkg/MdeModulePkg.dec
>ArmPkg/ArmPkg.dec
> -
> +  Silicon/Hisilicon/HisiliconNonOsi.dec
>Silicon/Hisilicon/HisiPkg.dec
>  
>  [LibraryClasses]
> diff --git a/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.inf 
> b/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.inf
> index 0f6b68d4c88d..e82c9204d5d6 100644
> --- a/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.inf
> +++ b/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.inf
> @@ -29,6 +29,7 @@ [Packages]
>ArmPkg/ArmPkg.dec
>MdePkg/MdePkg.dec
>MdeModulePkg/MdeModulePkg.dec
> +  Silicon/Hisilicon/HisiliconNonOsi.dec
>Silicon/Hisilicon/HisiPkg.dec
>  
>  [LibraryClasses]
> diff --git a/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf 
> b/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf
> index 022c3e940a31..7ec577530610 100644
> --- a/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf
> +++ b/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf
> @@ -30,6 +30,7 @@ [Packages]
>ArmPkg/ArmPkg.dec
>MdeModulePkg/MdeModulePkg.dec
>MdePkg/MdePkg.dec
> +  Silicon/Hisilicon/HisiliconNonOsi.dec
>Silicon/Hisilicon/HisiPkg.dec
>  
>  [LibraryClasses]
> diff --git a/Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.inf 
> b/Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.inf
> index 8296ee02de4e..715a4efadde8 100644
> --- a/Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.inf
> +++ 

Re: [edk2] [patch 2/2] MdeModulePkg/BmBoot: Report status when fail to load/start boot option

[Doran, Mark]

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, February 20, 2019 1:25 AM
> To: Ni, Ray ; Bi, Dandan 
> Cc: edk2-devel@lists.01.org; Wu, Hao A ; Doran, Mark
> 
> Subject: Re: [edk2] [patch 2/2] MdeModulePkg/BmBoot: Report status when
> fail to load/start boot option
> 
> +Mark, for my comments on the process

Thank you :)
 
> On 02/20/19 03:21, Ni, Ray wrote:
> > Laszlo,
> > Thanks for catching this.
> >
> > GenPerformMemoryTest() in
> > MdeModulePkg\Universal\MemoryTest\GenericMemoryTestDxe\LightMemoryTest
> > .c uses the same technics as you suggested.
> >
> > I give up to propose another option: having pack(1) for the new status
> structure.
> 
> I think that byte-packing EFI_RETURN_STATUS_EXTENDED_DATA in the PI-1.7
> spec would have been viable, but we should have thought about that in
> advance. The PI and UEFI specs require natural alignment for structure
> members, unless stated otherwise. There *are* a number of examples of
> "stated otherwise" (the term that the specs use is frequently "byte-packed
> structure"). Again, we should have thought of that in advance, before PI-
> 1.7 was released, so now we can only fix the way the object is populated.

Agreed.
 
> More generally, I think this demonstrates a flaw in the standardization
> process. PIWG and USWG should only standardize existing practice; that is,
> features that have at least one functional implementation. (Not necessarily
> open source, but the interfaces should be battle-hardened
> *first*.) The restriction where we can't even propose patches for edk2
> before the standards are updated is very counter-productive. There's
> practically zero chance for getting an actual implementation peer-reviewed
> and peer-tested before proposing the API for the standard.
> 
> Personally I have suggested in the past to implement some new features as
> edk2 extensions first, and once they work, to upstream them to the
> standards. This idea is usually rejected by maintainers, because
> maintainers worry about becoming stuck with more and more edk2 extensions
> to core code (i.e., they worry about the feature proponents not making good
> on their promise to standardize). Unfortunately, the alternative (= the
> current practice) is that we standardize speculative interfaces, which then
> prove suboptimal once we implement them.

So personally I'm a big believer in having working code for things we write 
down in the standards.  When EFI was first drafted that's how we did it: what 
was then known as "the sample implementation" and the actual spec content were 
more or less developed in parallel and the spec wasn't done until the code was 
working satisfactorily.  We got away from that largely because when the UEFI 
Forum was formed, there was nominal interest in promoting more than one 
implementation and keeping spec and code requirements separate was a part of 
that.

Recent changes, particularly inside Intel, present an opportunity for us to 
revisit this issue.  I'm advocating for the approach of spec-follows-code for 
new Contributions that Intel will make to the open source project going 
forward.  I'll have more to say about this at upcoming industry events.

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

[edk2] [Patch V2] BaseTool: Fixed incremental rebuild issue.

[Feng, Bob C]

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

This issue in introduced by commit
d943b0c339fe3d35ffdf9f580ccb7a55915c6854

To convert bytes to string, we need to use bytes.decode()
instead of using str(bytes). 

If the source file is not a txt file, ignore that file. 

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng 
Cc: Liming Gao 
---
 BaseTools/Source/Python/AutoGen/GenMake.py  | 16 
 .../Source/Python/Workspace/DscBuildData.py | 17 -
 2 files changed, 16 insertions(+), 17 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/GenMake.py 
b/BaseTools/Source/Python/AutoGen/GenMake.py
index 53c5b8577d..b441817b52 100644
--- a/BaseTools/Source/Python/AutoGen/GenMake.py
+++ b/BaseTools/Source/Python/AutoGen/GenMake.py
@@ -1043,18 +1043,18 @@ cleanlib:
 Fd.close()
 except BaseException as X:
 EdkLogger.error("build", FILE_OPEN_FAILURE, 
ExtraData=F.Path + "\n\t" + str(X))
 if len(FileContent) == 0:
 continue
-
-if FileContent[0] == 0xff or FileContent[0] == 0xfe:
-FileContent = FileContent.decode('utf-16')
-else:
-try:
-FileContent = str(FileContent)
-except:
-pass
+try:
+if FileContent[0] == 0xff or FileContent[0] == 0xfe:
+FileContent = FileContent.decode('utf-16')
+else:
+FileContent = FileContent.decode()
+except:
+# The file is not txt file. for example .mcb file
+continue
 IncludedFileList = gIncludePattern.findall(FileContent)
 
 for Inc in IncludedFileList:
 Inc = Inc.strip()
 # if there's macro used to reference header file, expand it
diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py 
b/BaseTools/Source/Python/Workspace/DscBuildData.py
index 1ffefe6e7e..7221946062 100644
--- a/BaseTools/Source/Python/Workspace/DscBuildData.py
+++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
@@ -153,19 +153,18 @@ def GetDependencyList(FileStack, SearchPathList):
 Fd.close()
 
 if len(FileContent) == 0:
 continue
 
-if FileContent[0] == 0xff or FileContent[0] == 0xfe:
-FileContent = FileContent.decode('utf-16')
-IncludedFileList = gIncludePattern.findall(FileContent)
-else:
-try:
-FileContent = str(FileContent)
-IncludedFileList = gIncludePattern.findall(FileContent)
-except:
-pass
+try:
+if FileContent[0] == 0xff or FileContent[0] == 0xfe:
+FileContent = FileContent.decode('utf-16')
+else:
+FileContent = FileContent.decode()
+except:
+# The file is not txt file. for example .mcb file
+continue
 IncludedFileList = gIncludePattern.findall(FileContent)
 
 for Inc in IncludedFileList:
 Inc = Inc.strip()
 Inc = os.path.normpath(Inc)
-- 
2.18.0.windows.1

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

Re: [edk2] Issues with EDK-II-Debugging wiki page, and how to submit a pull request for wiki pages

[Gao, Liming]

Laszlo:
  I mostly use local editor to edit wiki and send the patch. This way can't see 
the preview wiki page in web. It may cause the mistake. 

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
> Ersek
> Sent: Wednesday, February 20, 2019 5:52 PM
> To: Rebecca Cran ; Kinney, Michael D 
> 
> Cc: edk2-devel 
> Subject: Re: [edk2] Issues with EDK-II-Debugging wiki page, and how to submit 
> a pull request for wiki pages
> 
> On 02/20/19 08:45, Rebecca Cran wrote:
> > On Thursday, 14 February 2019 12:23:05 MST Laszlo Ersek wrote:
> >
> >> The wikis on github are non-intuitive, if you intend to edit them in a
> >> normal text editor, locally. I struggled a lot until I came up with the
> >> list on top. (It's possible I relied on others' advice in that; I no
> >> longer remember.) I hope it helps.
> >
> > Yeah, thanks but no thanks. I'm not _that_ keen on making my changes if it's
> > going to involve all that work!
> >
> 
> Totally understandable. I *think* it should be possible to simply edit
> the wiki articles with github's built-in wiki editor too, but I have no
> clue about the credentials needed. Perhaps being a member of the
>  organization suffices; I'm not certain.
> 
> Mike, can you please comment? What's the best process for wiki edits?
> 
> Thanks,
> Laszlo
> ___
> 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 edk2-platforms] Silicon/AMD/Styx/Drivers/AcpiPlatformDxe: use correct object ref in DBG2

[Ard Biesheuvel]

On Wed, 20 Feb 2019 at 15:38, Leif Lindholm  wrote:
>
> On Wed, Feb 20, 2019 at 03:27:41PM +0100, Ard Biesheuvel wrote:
> > The NamespaceString[] field in the DBG2 table should contain a fully
> > qualified ACPI namespace object reference. This was found by fwts.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel 
>
> Reviewed-by: Leif Lindholm 
>

Thanks.

Pushed as 76d9e9a5da9e..54f98cb1789a

> > ---
> >  Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc 
> > b/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc
> > index 07635aa9dd8e..e55119258bac 100644
> > --- a/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc
> > +++ b/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc
> > @@ -25,7 +25,7 @@
> >  #define EFI_ACPI_DBG2_REVISION 0
> >  #define DBG2_NUM_DEBUG_PORTS   1
> >  #define DBG2_NUMBER_OF_GENERIC_ADDRESS_REGISTERS   1
> > -#define DBG2_NAMESPACESTRING_FIELD_SIZE8
> > +#define DBG2_NAMESPACESTRING_FIELD_SIZE9
> >  #define DBG2_OEM_DATA_FIELD_SIZE   0
> >  #define DBG2_OEM_DATA_FIELD_OFFSET 0
> >
> > @@ -33,7 +33,7 @@
> >  #define DBG2_DEBUG_PORT_SUBTYPE_UEFI   0x0007// Sub 
> > type for UEFI Debug Port
> >  #define PL011_UART_LENGTH  0x1000
> >
> > -#define NAME_STR_UART1 {'C', 'O', 'M', '1', '\0', '\0', '\0', '\0'}
> > +#define NAME_STR_UART1 "\\SB.COM1"
> >  #define NAME_STR_UEFI  {'U', 'E', 'F', 'I', '\0', '\0', '\0', '\0'}
> >
> >
> > --
> > 2.20.1
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 0/6] ResetSystemLib changings

[Gao, Liming]

Zhichao:
  For patch2~5, my comment is to move patch 4 as patch 2. Normally, we add API 
definition in library class header file first, then update the library instance 
implementation. I have no comments for the code change. Reviewed-by: Liming Gao 


Thanks
Liming
> -Original Message-
> From: Gao, Zhichao
> Sent: Wednesday, February 20, 2019 4:39 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ray ; Gao, Liming 
> Subject: [PATCH v3 0/6] ResetSystemLib changings
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1460
> Add a new API ResetSystem in ResetSystemLib.
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1461
> Implement a runtime library instance of ResetSystemLib base on the new 
> changing.
> 
> V2: Add some required data type header file
> 
> V3: Resolve a case-typing error.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao 
> Cc: Ray Ni 
> Cc: Liming Gao 
> 
> Zhichao Gao (6):
>   MdeModulePkg: change the function name ResetSystem
>   MdeModulePkg: Add a new API ResetSystem for DXE ResetSystemLib
>   MdeModulePkg: Add a new API ResetSystem for Null version
>   MdeModulePkg: Add the new API ResetSystem in the head file
>   MdeModulePkg: Add a runtime library instance of ResetSystemLib
>   MdeModulePkg: Add the runtime ResetSystemLib in MdeModulePkg.dsc
> 
>  MdeModulePkg/Include/Library/ResetSystemLib.h  |  28 ++-
>  .../BaseResetSystemLibNull.c   |  27 +++
>  .../Library/DxeResetSystemLib/DxeResetSystemLib.c  |  28 ++-
>  .../RuntimeResetSystemLib/RuntimeResetSystemLib.c  | 216 
> +
>  .../RuntimeResetSystemLib.inf  |  50 +
>  .../RuntimeResetSystemLib.uni  |  21 ++
>  MdeModulePkg/MdeModulePkg.dsc  |   1 +
>  .../Universal/ResetSystemRuntimeDxe/ResetSystem.c  |   8 +-
>  .../Universal/ResetSystemRuntimeDxe/ResetSystem.h  |   4 +-
>  9 files changed, 375 insertions(+), 8 deletions(-)
>  create mode 100644 
> MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.c
>  create mode 100644 
> MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.inf
>  create mode 100644 
> MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.uni
> 
> --
> 2.16.2.windows.1

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

Re: [edk2] [PATCH edk2-platforms] Silicon/AMD/Styx/Drivers/AcpiPlatformDxe: use correct object ref in DBG2

[Leif Lindholm]

On Wed, Feb 20, 2019 at 03:27:41PM +0100, Ard Biesheuvel wrote:
> The NamespaceString[] field in the DBG2 table should contain a fully
> qualified ACPI namespace object reference. This was found by fwts.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Leif Lindholm 

> ---
>  Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc 
> b/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc
> index 07635aa9dd8e..e55119258bac 100644
> --- a/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc
> +++ b/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc
> @@ -25,7 +25,7 @@
>  #define EFI_ACPI_DBG2_REVISION 0
>  #define DBG2_NUM_DEBUG_PORTS   1
>  #define DBG2_NUMBER_OF_GENERIC_ADDRESS_REGISTERS   1
> -#define DBG2_NAMESPACESTRING_FIELD_SIZE8
> +#define DBG2_NAMESPACESTRING_FIELD_SIZE9
>  #define DBG2_OEM_DATA_FIELD_SIZE   0
>  #define DBG2_OEM_DATA_FIELD_OFFSET 0
>  
> @@ -33,7 +33,7 @@
>  #define DBG2_DEBUG_PORT_SUBTYPE_UEFI   0x0007// Sub type 
> for UEFI Debug Port
>  #define PL011_UART_LENGTH  0x1000
>  
> -#define NAME_STR_UART1 {'C', 'O', 'M', '1', '\0', '\0', '\0', '\0'}
> +#define NAME_STR_UART1 "\\SB.COM1"
>  #define NAME_STR_UEFI  {'U', 'E', 'F', 'I', '\0', '\0', '\0', '\0'}
>  
>  
> -- 
> 2.20.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 1/6] MdeModulePkg: change the function name ResetSystem

[Gao, Liming]

Zhichao:
  My comment is to change function name as RuntimeServiceResetSystem. This is 
the similar name in RuntimeServiceSetVariable of Variable driver. I don't 
suggest to use Efi as function prefix. 

Thanks
Liming
> -Original Message-
> From: Gao, Zhichao
> Sent: Wednesday, February 20, 2019 4:39 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ray ; Gao, Liming 
> Subject: [PATCH v3 1/6] MdeModulePkg: change the function name ResetSystem
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1460
> 
> Change the function name form ResetSystem to EfiRuntimeResetSystem.
> Because ResetSystem and EfiResetSystem would be used in ResetSystemLib
> and RuntimeLib.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao 
> Cc: Ray Ni 
> Cc: Liming Gao 
> ---
>  MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c | 8 
>  MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.h | 4 ++--
>  2 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c
> b/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c
> index afc35587fc..e16b0cda7b 100644
> --- a/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c
> +++ b/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c
> @@ -1,7 +1,7 @@
>  /** @file
>Reset Architectural and Reset Notification protocols implementation.
> 
> -  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> 
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD 
> License
> @@ -187,7 +187,7 @@ InitializeResetSystem (
>//
>// Hook the runtime service table
>//
> -  gRT->ResetSystem = ResetSystem;
> +  gRT->ResetSystem = EfiRuntimeResetSystem;
> 
>//
>// Now install the Reset RT AP on a new handle
> @@ -242,7 +242,7 @@ DoS3 (
>  **/
>  VOID
>  EFIAPI
> -ResetSystem (
> +EfiRuntimeResetSystem (
>IN EFI_RESET_TYPE   ResetType,
>IN EFI_STATUS   ResetStatus,
>IN UINTNDataSize,
> @@ -256,7 +256,7 @@ ResetSystem (
>RESET_NOTIFY_ENTRY  *Entry;
> 
>//
> -  // Only do REPORT_STATUS_CODE() on first call to ResetSystem()
> +  // Only do REPORT_STATUS_CODE() on first call to EfiRuntimeResetSystem()
>//
>if (mResetNotifyDepth == 0) {
>  //
> diff --git a/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.h
> b/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.h
> index 8529de675c..448e30f079 100644
> --- a/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.h
> +++ b/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.h
> @@ -1,6 +1,6 @@
>  /** @file
> 
> -  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> 
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD 
> License
> @@ -97,7 +97,7 @@ InitializeResetSystem (
>  **/
>  VOID
>  EFIAPI
> -ResetSystem (
> +EfiRuntimeResetSystem (
>IN EFI_RESET_TYPE   ResetType,
>IN EFI_STATUS   ResetStatus,
>IN UINTNDataSize,
> --
> 2.16.2.windows.1

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

Re: [edk2] [PATCH] ShellPkg: add array index check for shell delay option

[Gao, Liming]

Reviewed-by: Liming Gao 

> -Original Message-
> From: Gao, Zhichao
> Sent: Monday, February 18, 2019 4:28 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming ; Ni, Ray 
> Subject: [PATCH] ShellPkg: add array index check for shell delay option
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1528
> 
> Shell delay option without parameters do not check the
> index of shell parameter argv. Add index check to avoid
> invalid pointer references.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao 
> 
> Cc: Liming Gao 
> Cc: Ray Ni 
> ---
>  ShellPkg/Application/Shell/Shell.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/ShellPkg/Application/Shell/Shell.c 
> b/ShellPkg/Application/Shell/Shell.c
> index 104f4c8961..ec344137d3 100644
> --- a/ShellPkg/Application/Shell/Shell.c
> +++ b/ShellPkg/Application/Shell/Shell.c
> @@ -1,7 +1,7 @@
>  /** @file
>This is THE shell (application)
> 
> -  Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
> +  Copyright (c) 2009 - 2019, Intel Corporation. All rights reserved.
>(C) Copyright 2013-2014 Hewlett-Packard Development Company, L.P.
>Copyright 2015-2018 Dell Technologies.
>This program and the accompanying materials
> @@ -1002,7 +1002,11 @@ ProcessCommandLine(
>   ) == 0) {
>ShellInfoObject.ShellInitSettings.BitUnion.Bits.Delay= TRUE;
>// Check for optional delay value following "-delay"
> -  DelayValueStr = gEfiShellParametersProtocol->Argv[LoopVar + 1];
> +  if ((LoopVar + 1) >= gEfiShellParametersProtocol->Argc) {
> +DelayValueStr = NULL;
> +  } else {
> +DelayValueStr = gEfiShellParametersProtocol->Argv[LoopVar + 1];
> +  }
>if (DelayValueStr != NULL){
>  if (*DelayValueStr == L':') {
>DelayValueStr++;
> --
> 2.16.2.windows.1

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

[edk2] [PATCH edk2-platforms] Silicon/AMD/Styx/Drivers/AcpiPlatformDxe: use correct object ref in DBG2

[Ard Biesheuvel]

The NamespaceString[] field in the DBG2 table should contain a fully
qualified ACPI namespace object reference. This was found by fwts.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc 
b/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc
index 07635aa9dd8e..e55119258bac 100644
--- a/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc
+++ b/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc
@@ -25,7 +25,7 @@
 #define EFI_ACPI_DBG2_REVISION 0
 #define DBG2_NUM_DEBUG_PORTS   1
 #define DBG2_NUMBER_OF_GENERIC_ADDRESS_REGISTERS   1
-#define DBG2_NAMESPACESTRING_FIELD_SIZE8
+#define DBG2_NAMESPACESTRING_FIELD_SIZE9
 #define DBG2_OEM_DATA_FIELD_SIZE   0
 #define DBG2_OEM_DATA_FIELD_OFFSET 0
 
@@ -33,7 +33,7 @@
 #define DBG2_DEBUG_PORT_SUBTYPE_UEFI   0x0007// Sub type 
for UEFI Debug Port
 #define PL011_UART_LENGTH  0x1000
 
-#define NAME_STR_UART1 {'C', 'O', 'M', '1', '\0', '\0', '\0', '\0'}
+#define NAME_STR_UART1 "\\SB.COM1"
 #define NAME_STR_UEFI  {'U', 'E', 'F', 'I', '\0', '\0', '\0', '\0'}
 
 
-- 
2.20.1

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

Re: [edk2] [PATCH] BaseTool/GenC: Fix build error when type is BASE or USER_DEFINED.

[Gao, Liming]

Jiewen:
  This change causes NT32 SecMain build failure. For USER_DEFINED and BASE 
type, they only consumes Constructor() from the library instance with BASE 
type. They don't use PEIM or DXE type Constructor(), because they have no 
PeiService pointer or ImageHandle. 

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiewen 
> Yao
> Sent: Wednesday, February 20, 2019 7:55 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: [edk2] [PATCH] BaseTool/GenC: Fix build error when type is BASE or 
> USER_DEFINED.
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=1544
> 
> 1) The GenC tool does not include the constructor/destructor for
> USER_DEFINED module. It should be included.
> 
> 2) The GenC tool includes the UnloadImage code for BASE module.
> It should NOT be included.
> 
> 3) The GenC tool uses EFI_STATUS and ASSERT_EFI_ERROR for BASE type.
> It should use RETURN_STATUS and ASSERT_RETURN_ERROR.
> 
> 4) The GenC tool miss DebugLib.h for BASE or USER_DEFINED module
> AutoGen.c. Only Base.h is there. It should add Library/DebugLib.h.
> 
> Cc: Bob Feng 
> Cc: Liming Gao 
> Cc: Yonghong Zhu 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jiewen Yao 
> ---
>  BaseTools/Source/Python/AutoGen/GenC.py | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/AutoGen/GenC.py 
> b/BaseTools/Source/Python/AutoGen/GenC.py
> index 9700bf8527..c4bba8da17 100644
> --- a/BaseTools/Source/Python/AutoGen/GenC.py
> +++ b/BaseTools/Source/Python/AutoGen/GenC.py
> @@ -684,7 +684,7 @@ ${Function} (
>  gLibraryStructorCall = {
>  SUP_MODULE_BASE  : TemplateString("""${BEGIN}
>Status = ${Function} ();
> -  ASSERT_EFI_ERROR (Status);${END}
> +  ASSERT_RETURN_ERROR (Status);${END}
>  """),
> 
>  'PEI'   : TemplateString("""${BEGIN}
> @@ -714,7 +714,7 @@ ProcessLibrary${Type}List (
>VOID
>)
>  {
> -${BEGIN}  EFI_STATUS  Status;
> +${BEGIN}  RETURN_STATUS  Status;
>  ${FunctionCall}${END}
>  }
>  """),
> @@ -768,7 +768,7 @@ ${FunctionCall}${END}
>  gBasicHeaderFile = "Base.h"
> 
>  gModuleTypeHeaderFile = {
> -SUP_MODULE_BASE  :   [gBasicHeaderFile],
> +SUP_MODULE_BASE  :   [gBasicHeaderFile, 
> "Library/DebugLib.h"],
>  SUP_MODULE_SEC   :   ["PiPei.h", "Library/DebugLib.h"],
>  SUP_MODULE_PEI_CORE  :   ["PiPei.h", "Library/DebugLib.h", 
> "Library/PeiCoreEntryPoint.h"],
>  SUP_MODULE_PEIM  :   ["PiPei.h", "Library/DebugLib.h", 
> "Library/PeimEntryPoint.h"],
> @@ -782,7 +782,7 @@ gModuleTypeHeaderFile = {
>  SUP_MODULE_SMM_CORE  :   ["PiDxe.h", "Library/BaseLib.h", 
> "Library/DebugLib.h", "Library/UefiDriverEntryPoint.h"],
>  SUP_MODULE_MM_STANDALONE :   ["PiMm.h", "Library/BaseLib.h", 
> "Library/DebugLib.h",
> "Library/StandaloneMmDriverEntryPoint.h"],
>  SUP_MODULE_MM_CORE_STANDALONE :  ["PiMm.h", "Library/BaseLib.h", 
> "Library/DebugLib.h",
> "Library/StandaloneMmCoreEntryPoint.h"],
> -SUP_MODULE_USER_DEFINED  :   [gBasicHeaderFile]
> +SUP_MODULE_USER_DEFINED  :   [gBasicHeaderFile, "Library/DebugLib.h"]
>  }
> 
>  ## Autogen internal worker macro to define DynamicEx PCD name includes both 
> the TokenSpaceGuidName
> @@ -1373,7 +1373,7 @@ def CreateLibraryConstructorCode(Info, AutoGenC, 
> AutoGenH):
>  if Info.IsLibrary:
>  AutoGenH.Append("${BEGIN}${FunctionPrototype}${END}", Dict)
>  else:
> -if Info.ModuleType in [SUP_MODULE_BASE, SUP_MODULE_SEC]:
> +if Info.ModuleType in [SUP_MODULE_BASE, SUP_MODULE_SEC, 
> SUP_MODULE_USER_DEFINED]:
>  AutoGenC.Append(gLibraryString[SUP_MODULE_BASE].Replace(Dict))
>  elif Info.ModuleType in SUP_MODULE_SET_PEI:
>  AutoGenC.Append(gLibraryString['PEI'].Replace(Dict))
> @@ -1435,7 +1435,7 @@ def CreateLibraryDestructorCode(Info, AutoGenC, 
> AutoGenH):
>  if Info.IsLibrary:
>  AutoGenH.Append("${BEGIN}${FunctionPrototype}${END}", Dict)
>  else:
> -if Info.ModuleType in [SUP_MODULE_BASE, SUP_MODULE_SEC]:
> +if Info.ModuleType in [SUP_MODULE_BASE, SUP_MODULE_SEC, 
> SUP_MODULE_USER_DEFINED]:
>  AutoGenC.Append(gLibraryString[SUP_MODULE_BASE].Replace(Dict))
>  elif Info.ModuleType in SUP_MODULE_SET_PEI:
>  AutoGenC.Append(gLibraryString['PEI'].Replace(Dict))
> @@ -1533,7 +1533,7 @@ def CreateModuleEntryPointCode(Info, AutoGenC, 
> AutoGenH):
>  #   @param  AutoGenHThe TemplateString object for header file
>  #
>  def CreateModuleUnloadImageCode(Info, AutoGenC, AutoGenH):
> -if Info.IsLibrary or Info.ModuleType in [SUP_MODULE_USER_DEFINED, 
> SUP_MODULE_SEC]:
> +if Info.IsLibrary or Info.ModuleType in [SUP_MODULE_USER_DEFINED, 
> SUP_MODULE_BASE, SUP_MODULE_SEC]:
>  return
>  #
>  # Unload Image Handlers
> --
> 2.19.2.windows.1
> 
> 

Re: [edk2] [Patch] BaseTool: Fixed incremental rebuild issue.

[Gao, Liming]

Reviewed-by: Liming Gao 

> -Original Message-
> From: Feng, Bob C
> Sent: Wednesday, February 20, 2019 6:09 PM
> To: edk2-devel@lists.01.org
> Cc: Feng, Bob C ; Gao, Liming 
> Subject: [Patch] BaseTool: Fixed incremental rebuild issue.
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1540
> 
> This issue in introduced by commit
> d943b0c339fe3d35ffdf9f580ccb7a55915c6854
> 
> To convert bytes to string, we need to use bytes.decode()
> instead of using str(bytes)
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Bob Feng 
> Cc: Liming Gao 
> ---
>  BaseTools/Source/Python/AutoGen/GenMake.py| 2 +-
>  BaseTools/Source/Python/Workspace/DscBuildData.py | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/AutoGen/GenMake.py 
> b/BaseTools/Source/Python/AutoGen/GenMake.py
> index 53c5b8577d..641ed8305f 100644
> --- a/BaseTools/Source/Python/AutoGen/GenMake.py
> +++ b/BaseTools/Source/Python/AutoGen/GenMake.py
> @@ -1048,11 +1048,11 @@ cleanlib:
> 
>  if FileContent[0] == 0xff or FileContent[0] == 0xfe:
>  FileContent = FileContent.decode('utf-16')
>  else:
>  try:
> -FileContent = str(FileContent)
> +FileContent = FileContent.decode()
>  except:
>  pass
>  IncludedFileList = gIncludePattern.findall(FileContent)
> 
>  for Inc in IncludedFileList:
> diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py 
> b/BaseTools/Source/Python/Workspace/DscBuildData.py
> index 1ffefe6e7e..74bc333144 100644
> --- a/BaseTools/Source/Python/Workspace/DscBuildData.py
> +++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
> @@ -158,11 +158,11 @@ def GetDependencyList(FileStack, SearchPathList):
>  if FileContent[0] == 0xff or FileContent[0] == 0xfe:
>  FileContent = FileContent.decode('utf-16')
>  IncludedFileList = gIncludePattern.findall(FileContent)
>  else:
>  try:
> -FileContent = str(FileContent)
> +FileContent = FileContent.decode()
>  IncludedFileList = gIncludePattern.findall(FileContent)
>  except:
>  pass
>  IncludedFileList = gIncludePattern.findall(FileContent)
> 
> --
> 2.20.1.windows.1

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

Re: [edk2] [PATCH 00/10] Fix PEI Core issue during TemporaryRamMigration

[Ni, Ray]

On 2/19/2019 9:25 PM, Gao, Liming wrote:

Ray:
In PI spec, TEMPORARY_RAM_SUPPORT_PPI is described as an optional PPI 
that is only required for platforms that may have side effects when both 
Temporary RAM and Permanent RAM are enabled. If a platform does not have any 
side effects when both Temporary RAM and Permanent RAM are enabled, and the 
platform is required to disable the use of Temporary RAM, then 
EFI_PEI_TEMPORARY_RAM_DONE should be produced. If a platform does not have any 
side effects when both Temporary RAM and Permanent RAM are enabled, and the 
platform is not required to disable the use of Temporary RAM, then neither 
EFI_PEI_TEMPORARY_RAM_DONE nor EFI_PEI_TEMPORARY_RAM_SUPPORT_PPI should be 
produced.

 Now, real platform has no side effect. So, only TempRamDone PPI is 
produced. For emulator platform, is there any side effect when both Temporary 
RAM and Permanent RAM are enabled?



No side effect when both of T-RAM and P-RAM are enabled.
Which means no side effect when neither of the PPIs is produced.
But for demo purpose, I think producing TemporaryRamDone PPI makes sense.

I will work out patches for EmulatorPkg to produce TemoraryRamDone.



Thanks
Liming

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ni, Ray
Sent: Tuesday, February 19, 2019 10:46 AM
To: Justen, Jordan L ; edk2-devel@lists.01.org
Cc: Wu, Hao A ; Anthony Perard ; 
Laszlo Ersek ; Zeng, Star

Subject: Re: [edk2] [PATCH 00/10] Fix PEI Core issue during 
TemporaryRamMigration

Jordan,
I find many real platforms do not implement the temporary ram migration
PPI and rely on the PeiCore migration  logic.
So perhaps TemporaryRamMigration PPI was added to help platform to
destroy the temporary RAM (CAR in x86 platform).
But with the introduction of TemporaryRamDone PPI, maybe the
TemporaryRamMigration PPI can be retired.
The logic in PeiCore to call TemporaryRamMigration is just for backward
compatibility.
If that's true, do you still need to enhance PeiCore?

For the Emulator case, I already found without TemporaryRamMigration
the platform can still boot.

Does OVMF hard-depend on TemporaryRamMigration? Or it can reply on
the PeiCore migration logic + TemporaryDone PPI?

Thanks,
Ray


-Original Message-
From: Justen, Jordan L 
Sent: Monday, February 18, 2019 12:12 PM
To: edk2-devel@lists.01.org
Cc: Justen, Jordan L ; Liu Yu
; Andrew Fish ; Anthony
Perard ; Ard Biesheuvel
; Wu, Hao A ; Wang, Jian
J ; Julien Grall ; Laszlo Ersek
; Ni, Ray ; Zeng, Star

Subject: [PATCH 00/10] Fix PEI Core issue during TemporaryRamMigration

https://github.com/jljusten/edk2.git temp-ram-support

This series fixes an issue that, while rare, is possible based on the way the
TemporaryRamSupport PPI is defined along with how it is used by the PEI
Core.

Liu Yu reported a boot issue with EmulatorPkg, which I believe was caused by
this issue.

The details of the issue are described in the commit message of the
"MdeModePkg/Core/Pei: Add code path to allow assembly temp-ram
migration" patch.

Along with this, I added a few Temporary RAM patches for EmulatorPkg and
OvmfPkg.

Cc: Liu Yu 
Cc: Andrew Fish 
Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Hao Wu 
Cc: Jian J Wang 
Cc: Julien Grall 
Cc: Laszlo Ersek 
Cc: Ray Ni 
Cc: Star Zeng 

Jordan Justen (10):
   EmulatorPkg/build.sh: Fix missing usage of -b BUILDTARGET parameter
   EmulatorPkg/Unix/Host: Use PcdInitValueInTempStack to init temp-ram
   EmulatorPkg/Sec: Replace assembly temp-ram support with C code
   EmulatorPkg/Sec: Disable optimizations for TemporaryRamMigration
 function
   OvmfPkg/Sec: Swap TemporaryRam Stack and Heap locations
   OvmfPkg/Sec: Disable optimizations for TemporaryRamMigration
   MdeModePkg/Core/Pei: Add code path to allow assembly temp-ram
 migration
   MdeModulePkg/Core/Pei: Use assembly for X64 TemporaryRamMigration
   MdeModulePkg/Core/Pei: Use assembly for IA32 TemporaryRamMigration
   OvmfPkg/Sec: Fill Temp Ram after TemporaryRamMigration

  EmulatorPkg/Sec/Ia32/SwitchRam.S  | 95 ---
  EmulatorPkg/Sec/Ia32/SwitchRam.asm| 94 --
  EmulatorPkg/Sec/Ia32/TempRam.c| 65 -
  EmulatorPkg/Sec/Sec.c | 76 ++-
  EmulatorPkg/Sec/Sec.inf   | 13 +--
  EmulatorPkg/Sec/X64/SwitchRam.S   | 72 --
  EmulatorPkg/Sec/X64/SwitchRam.asm | 76 ---
  EmulatorPkg/Unix/Host/Host.c  |  2 +-
  EmulatorPkg/Unix/Host/Host.inf|  1 +
  EmulatorPkg/build.sh  | 10 +-
  MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c | 59 
  .../Dispatcher/Ia32/TemporaryRamMigration.S   | 72 ++
  .../Ia32/TemporaryRamMigration.nasm   | 78 +++
  .../Pei/Dispatcher/TemporaryRamMigration.c| 52 ++
  .../Dispatcher/X64/TemporaryRamMigration.S| 69 

Re: [edk2] [PATCH v2 1/5] MdeModulePkg/UefiBootManagerLib: fix LoadImage/StartImage status code rep.

[Ni, Ray]

On 2/20/2019 4:16 PM, Laszlo Ersek wrote:

In the EFI_RETURN_STATUS_EXTENDED_DATA structure from PI-1.7, there may be
padding between the DataHeader and ReturnStatus members. The
REPORT_STATUS_CODE_EX() macro starts populating the structure immediately
after DataHeader, therefore the source data must provide for the padding.

Extract the BmReportImageFailure() function from EfiBootManagerBoot(),
prepare a zero padding (if any) in a temporary
EFI_RETURN_STATUS_EXTENDED_DATA object, and fix the
REPORT_STATUS_CODE_EX() macro invocation.

Cc: Dandan Bi 
Cc: Hao Wu 
Cc: Jian J Wang 
Cc: Ray Ni 
Cc: Sean Brogan 
Cc: Star Zeng 
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1539
Fixes: c2cf8720a5aad74230767a1f11bade2d86de3745
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---

Notes:
 v2:
 - new in v2

  MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h |  1 +
  MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 69 +++-
  2 files changed, 52 insertions(+), 18 deletions(-)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h 
b/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
index 978fbff966f6..0fef63fceedf 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
+++ b/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
@@ -51,6 +51,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
  #include 
  #include 
  #include 
+#include 
  #include 
  
  #include 

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
index 9be1633b7480..ffb98c6c9b83 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
@@ -1667,6 +1667,55 @@ BmIsBootManagerMenuFilePath (
return FALSE;
  }
  
+/**

+  Report status code with EFI_RETURN_STATUS_EXTENDED_DATA about LoadImage() or
+  StartImage() failure.
+
+  @param[in] ErrorCode  An Error Code in the Software Class, DXE Boot
+Service Driver Subclass. ErrorCode will be used to
+compose the Value parameter for status code
+reporting. Must be one of
+EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR and
+EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED.
+
+  @param[in] FailureStatus  The failure status returned by the boot service
+that should be reported.
+**/
+VOID
+BmReportImageFailure (

Laszlo,
Thanks for quick fixing this issue.
To match the status code it reports, how about rename the function as 
"BmReportLoadFailure"?

Another minor comments in below.

+  IN UINT32 ErrorCode,
+  IN EFI_STATUS FailureStatus
+  )
+{
+  EFI_RETURN_STATUS_EXTENDED_DATA ExtendedData;
+  VOID*PaddingStart;
+  UINTN   PaddingSize;
+
+  if (!ReportErrorCodeEnabled ()) {
+return;
+  }
+
+  ASSERT (
+(ErrorCode == EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR) ||
+(ErrorCode == EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED)
+);
+
+  PaddingStart =  + 1;
+  PaddingSize = (UINTN)  - (UINTN) PaddingStart;
+  ZeroMem (PaddingStart, PaddingSize);


I prefer "ZeroMem (, sizeof (ExtendedData))" instead of 
introducing local variables such as PaddingStart/PaddingSize.

This makes code more good-looking:).


+  ExtendedData.ReturnStatus = FailureStatus;
+
+  REPORT_STATUS_CODE_EX (
+(EFI_ERROR_CODE | EFI_ERROR_MINOR),
+(EFI_SOFTWARE_DXE_BS_DRIVER | ErrorCode),
+0,
+NULL,
+NULL,
+PaddingStart,

 + 1


+PaddingSize + sizeof (ExtendedData.ReturnStatus)

sizeof (ExtendedData) - sizeof (ExtendedData.DataHeader)

+);
+}
+
  /**
Attempt to boot the EFI boot option. This routine sets L"BootCurent" and
also signals the EFI ready to boot event. If the device path for the option
@@ -1822,15 +1871,7 @@ EfiBootManagerBoot (
//
// Report Status Code with the failure status to indicate that the 
failure to load boot option
//
-  REPORT_STATUS_CODE_EX (
-EFI_ERROR_CODE | EFI_ERROR_MINOR,
-(EFI_SOFTWARE_DXE_BS_DRIVER | EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR),
-0,
-NULL,
-NULL,
-,
-sizeof (EFI_STATUS)
-);
+  BmReportImageFailure (EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR, Status);
BootOption->Status = Status;
//
// Destroy the RAM disk
@@ -1911,15 +1952,7 @@ EfiBootManagerBoot (
  //
  // Report Status Code with the failure status to indicate that boot 
failure
  //
-REPORT_STATUS_CODE_EX (
-  EFI_ERROR_CODE | EFI_ERROR_MINOR,
-  (EFI_SOFTWARE_DXE_BS_DRIVER | EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED),
-  0,
-  NULL,
-  NULL,
-  ,
-  sizeof (EFI_STATUS)
-  );
+BmReportImageFailure (EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED, Status);
}
PERF_END_EX (gImageHandle, 

Re: [edk2] [PATCH v1 1/1] SecurityPkg/HddPassword: Add Security feature set support for ATA dev

[Ni, Ray]

+
+/**
+  Entry point of the notification callback function itself within the PEIM.
+  It is to unlock HDD password for S3.
+
+  @param  PeiServices  Indirect reference to the PEI Services Table.
+  @param  NotifyDescriptor Address of the notification descriptor data 
structure.
+  @param  Ppi  Address of the PPI that was installed.
+
+  @return Status of the notification.
+  The status code returned from this function is ignored.
+**/
+EFI_STATUS
+EFIAPI
+HddPasswordAtaPassThruNotify (
+  IN EFI_PEI_SERVICES  **PeiServices,
+  IN EFI_PEI_NOTIFY_DESCRIPTOR *NotifyDesc,
+  IN VOID  *Ppi
+  )
+{
+  HDD_PASSWORD_PEI_DRIVER_PRIVATE_DATA*Private;
+
+  DEBUG ((DEBUG_INFO, "%a() - enter at S3 resume\n", __FUNCTION__));
+
+  Private = HDD_PASSWORD_PEI_PRIVATE_DATA_FROM_THIS_NOTIFY (NotifyDesc);
+  UnlockHddPassword (Private);


Similar comments as that I gave to 13/13 OpalPasswordPei change,
we could use the 3rd parameter "Ppi" to simplify the code.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v5 13/13] SecurityPkg/OpalPassword: Remove HW init codes and consume SSC PPI

[Ni, Ray]

+OpalPasswordStorageSecurityPpiNotify (
+  IN EFI_PEI_SERVICES **PeiServices,
+  IN EFI_PEI_NOTIFY_DESCRIPTOR*NotifyDesc,
+  IN VOID *Ppi
)
  {
-  EFI_STATUSStatus;
-  EFI_BOOT_MODE BootMode;
+  OPAL_PEI_DRIVER_PRIVATE_DATA*Private;
  
-  Status = PeiServicesGetBootMode ();

-  ASSERT_EFI_ERROR (Status);
-  if (BootMode != BOOT_ON_S3_RESUME) {
-return EFI_UNSUPPORTED;
-  }
+  DEBUG ((DEBUG_INFO, "%a entered at S3 resume!\n", __FUNCTION__));
  
-  DEBUG ((DEBUG_INFO, "%a() - enter at S3 resume\n", __FUNCTION__));

+  Private = OPAL_PEI_PRIVATE_DATA_FROM_THIS_NOTIFY (NotifyDesc);
+  UnlockOpalPasswordDevices (Private);
  
In this Notify callback, we could use the 3rd parameter "Ppi" to get the 
Ssc PPI instance to perform unlock operation.
With this change, the OPAL_PEI_DRIVER_PRIVATE_DATA is not needed any 
more and IsSscInstanceHandled() is not needed as well.


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

Re: [edk2] [PATCH] MdeModulePkg/VariableSmmRuntimeDxe: Refactor locating Variable Arch Protocol

[Ard Biesheuvel]

On Wed, 20 Feb 2019 at 06:53, Jagadeesh Ujja  wrote:
>
> hi Ard,
> On Tue, Feb 19, 2019 at 6:55 PM Ard Biesheuvel
>  wrote:
> >
> > Hello Jagadeesh,
> >
> > On Tue, 19 Feb 2019 at 11:47, Jagadeesh Ujja  wrote:
> > >
> > > In preparation for providing a standalone MM based non-secure variable
> > > runtime driver, factor out some portions that are specific to the
> > > traditional driver, mainly related to locating variable arch protocol
> > > and variable write arch protocol, which are not required to be located
> > > when using standalone MM based secure variable implementation.
> > >
> >
> > While i think this change is correct from a technical perspective, I
> > don't think this is the right approach.
> >
> these changes are mandatory, this is one of the possible solution.
>
> > It was a deliberate decision to expose the MM services in a way that
> > only the producer of the communication protocol is aware of the
> > implementation details, i.e., whether it is backed by tradtional MM or
> > standalone MM.
> >
> can you please provide more details on how "exposing the MM services"
> will help to resolve the issue here. if this helps, definitely i will use 
> that.
>

Let me rephrase this for the benefit of the MdeModulePkg maintainers,
and ask them their opinion.

Currently, the DXE runtime driver that produces the architectural
varstore protocols that are based on communication with MM components
living elsewhere, rely on the EFI protocol database for sequencing.
I.e., after dispatch, they wait for certain protocols to be installed
into the DXE protocol database by the SMM drivers before proceeding to
install the variable arch protocols.

This does not work for standalone MM, since it has no access to the
DXE protocol database, nor is it needed, since it may be assumed that
the MM execution context is fully configured by the time the DXE phase
starts.

Jagadeesh's proposal is to factor this out, and create two different
.INFs to build the same DXE runtime driver in two different ways. This
defeats the purpose of having an abstract MM communication protocol,
so it is something I would like to avoid. On the other hand, is it not
obvious how to parameterize this requirement in another way.

For the moment, I could live with putting this into a library, and
leave it up to the platform to ensure the combination of the library
resolution with the driver that produces the MM communicate protocol
is a sane one.

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

Re: [edk2] [PATCH v2 2/5] OvmfPkg: add library to track boot option loading/starting on the console

[Laszlo Ersek]

On 02/20/19 10:21, Ard Biesheuvel wrote:
> On Wed, 20 Feb 2019 at 09:16, Laszlo Ersek  wrote:
>>
>> Introduce the Platform Boot Manager Print Status Code Library (for short,
>> PlatformBmPrintScLib) class for catching and printing the LoadImage() /
>> StartImage() preparations, and return statuses, that are reported by
>> UefiBootManagerLib.
>>
>> In the primary library instance, catch only such status codes that
>> UefiBootManagerLib reports from the same module that contains
>> PlatformBmPrintScLib. The intent is to establish a reporting-printing
>> channel within BdsDxe, between UefiBootManagerLib and
>> PlatformBmPrintScLib. Ignore status codes originating elsewhence, e.g.
>> from UiApp's copy of UefiBootManagerLib.
>>
>> Cc: Anthony Perard 
>> Cc: Ard Biesheuvel 
>> Cc: Jordan Justen 
>> Cc: Julien Grall 
>> Cc: Ray Ni 
>> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Laszlo Ersek 
>> ---
>>
>> Notes:
>> v2:
>>
>> - Split the status code handling to a separate library, so that it's
>>   easy to reuse in ArmVirtPkg.
>>
>> - Rework the logic based on
>>    and
>>   , and follow Ray's
>>   advice in
>>   
>> :
>>
>>   - The boot option details are fetched via BootCurrent.
>>
>>   - For reporting LoadImage() and StartImage() preparations, replace the
>> originally proposed PcdDebugCodeOsLoaderDetail status code with the
>> existent (edk2-specific) PcdProgressCodeOsLoaderLoad and
>> PcdProgressCodeOsLoaderStart status codes.
>>
>>   - For reporting LoadImage() and StartImage() return values, replace
>> the originally proposed PcdDebugCodeOsLoaderDetail status code with
>> the standard EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR and
>> EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED status codes.
>>
>>   - For all four kinds of reports, replace the originally proposed "OS
>> Loader Detail" structure (and GUID) with the recently standardized
>> EFI_RETURN_STATUS_EXTENDED_DATA structure.
>>
>>  OvmfPkg/OvmfPkg.dec   |   5 +
>>  OvmfPkg/OvmfPkgIa32.dsc   |   1 +
>>  OvmfPkg/OvmfPkgIa32X64.dsc|   1 +
>>  OvmfPkg/OvmfPkgX64.dsc|   1 +
>>  OvmfPkg/Include/Library/PlatformBmPrintScLib.h|  41 +++
>>  OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf |  66 +
>>  OvmfPkg/Library/PlatformBmPrintScLib/StatusCodeHandler.c  | 310 
>> 
>>  7 files changed, 425 insertions(+)
>>

[...]

>> +  //
>> +  // Set the EFI_STATUS_CODE_VALUE convenience variables.
>> +  //
>> +  mLoadPrep  = PcdGet32 (PcdProgressCodeOsLoaderLoad);
>> +  mLoadFail  = (EFI_SOFTWARE_DXE_BS_DRIVER |
>> +EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR);
>> +  mStartPrep = PcdGet32 (PcdProgressCodeOsLoaderStart);
>> +  mStartFail = (EFI_SOFTWARE_DXE_BS_DRIVER |
>> +EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED);
>> +
>
> This bit looks somewhat dodgy to me, but I suppose the asymmetry is
> 'prior art' from EDK2, no?

Yes, that's the case. All four status code values are taken verbatim
from EfiBootManagerBoot()
[MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c], where they are
reported / produced.

I use module-global variables here because (a) I need no generality wrt.
status codes values in this module (I really only care for these four),
and (b) the original expressions are simply unbearably long; considering
the frequent use of these status code values in the patch.


Regarding the reporting in EfiBootManagerBoot(): the status code values

- (EFI_SOFTWARE_DXE_BS_DRIVER | EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR)
- (EFI_SOFTWARE_DXE_BS_DRIVER | EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED)

are from the PI spec. If we expand the macros a bit, we get,
respectively:

- EFI_SOFTWARE | 0x0005 | EFI_SUBCLASS_SPECIFIC | 0x0002
- EFI_SOFTWARE | 0x0005 | EFI_SUBCLASS_SPECIFIC | 0x0003

So we are in the "software class", the "DXE Boot Service Driver"
subclass, and we report values 2 and 3, which are meant to be unique
only within that subclass.

Conversely, the "prep" status code values are edk2 extensions. The PCDs
allow a platform, in theory anyway, to tweak the exact values. But in
practice, that should never be necessary. Let's check their default
values, in "MdeModulePkg/MdeModulePkg.dec":

>   ## Progress Code for OS Loader LoadImage start.
>   #  PROGRESS_CODE_OS_LOADER_LOAD   = (EFI_SOFTWARE_DXE_BS_DRIVER | 
> (EFI_OEM_SPECIFIC | 0x)) = 0x03058000
>   # @Prompt Progress Code for OS Loader LoadImage start.
>   # @ValidList  0x8003 | 

[edk2] [PATCH] BaseTool/GenC: Fix build error when type is BASE or USER_DEFINED.

[Jiewen Yao]

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

1) The GenC tool does not include the constructor/destructor for
USER_DEFINED module. It should be included.

2) The GenC tool includes the UnloadImage code for BASE module.
It should NOT be included.

3) The GenC tool uses EFI_STATUS and ASSERT_EFI_ERROR for BASE type.
It should use RETURN_STATUS and ASSERT_RETURN_ERROR.

4) The GenC tool miss DebugLib.h for BASE or USER_DEFINED module
AutoGen.c. Only Base.h is there. It should add Library/DebugLib.h.

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao 
---
 BaseTools/Source/Python/AutoGen/GenC.py | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/GenC.py 
b/BaseTools/Source/Python/AutoGen/GenC.py
index 9700bf8527..c4bba8da17 100644
--- a/BaseTools/Source/Python/AutoGen/GenC.py
+++ b/BaseTools/Source/Python/AutoGen/GenC.py
@@ -684,7 +684,7 @@ ${Function} (
 gLibraryStructorCall = {
 SUP_MODULE_BASE  : TemplateString("""${BEGIN}
   Status = ${Function} ();
-  ASSERT_EFI_ERROR (Status);${END}
+  ASSERT_RETURN_ERROR (Status);${END}
 """),
 
 'PEI'   : TemplateString("""${BEGIN}
@@ -714,7 +714,7 @@ ProcessLibrary${Type}List (
   VOID
   )
 {
-${BEGIN}  EFI_STATUS  Status;
+${BEGIN}  RETURN_STATUS  Status;
 ${FunctionCall}${END}
 }
 """),
@@ -768,7 +768,7 @@ ${FunctionCall}${END}
 gBasicHeaderFile = "Base.h"
 
 gModuleTypeHeaderFile = {
-SUP_MODULE_BASE  :   [gBasicHeaderFile],
+SUP_MODULE_BASE  :   [gBasicHeaderFile, "Library/DebugLib.h"],
 SUP_MODULE_SEC   :   ["PiPei.h", "Library/DebugLib.h"],
 SUP_MODULE_PEI_CORE  :   ["PiPei.h", "Library/DebugLib.h", 
"Library/PeiCoreEntryPoint.h"],
 SUP_MODULE_PEIM  :   ["PiPei.h", "Library/DebugLib.h", 
"Library/PeimEntryPoint.h"],
@@ -782,7 +782,7 @@ gModuleTypeHeaderFile = {
 SUP_MODULE_SMM_CORE  :   ["PiDxe.h", "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/UefiDriverEntryPoint.h"],
 SUP_MODULE_MM_STANDALONE :   ["PiMm.h", "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/StandaloneMmDriverEntryPoint.h"],
 SUP_MODULE_MM_CORE_STANDALONE :  ["PiMm.h", "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/StandaloneMmCoreEntryPoint.h"],
-SUP_MODULE_USER_DEFINED  :   [gBasicHeaderFile]
+SUP_MODULE_USER_DEFINED  :   [gBasicHeaderFile, "Library/DebugLib.h"]
 }
 
 ## Autogen internal worker macro to define DynamicEx PCD name includes both 
the TokenSpaceGuidName
@@ -1373,7 +1373,7 @@ def CreateLibraryConstructorCode(Info, AutoGenC, 
AutoGenH):
 if Info.IsLibrary:
 AutoGenH.Append("${BEGIN}${FunctionPrototype}${END}", Dict)
 else:
-if Info.ModuleType in [SUP_MODULE_BASE, SUP_MODULE_SEC]:
+if Info.ModuleType in [SUP_MODULE_BASE, SUP_MODULE_SEC, 
SUP_MODULE_USER_DEFINED]:
 AutoGenC.Append(gLibraryString[SUP_MODULE_BASE].Replace(Dict))
 elif Info.ModuleType in SUP_MODULE_SET_PEI:
 AutoGenC.Append(gLibraryString['PEI'].Replace(Dict))
@@ -1435,7 +1435,7 @@ def CreateLibraryDestructorCode(Info, AutoGenC, AutoGenH):
 if Info.IsLibrary:
 AutoGenH.Append("${BEGIN}${FunctionPrototype}${END}", Dict)
 else:
-if Info.ModuleType in [SUP_MODULE_BASE, SUP_MODULE_SEC]:
+if Info.ModuleType in [SUP_MODULE_BASE, SUP_MODULE_SEC, 
SUP_MODULE_USER_DEFINED]:
 AutoGenC.Append(gLibraryString[SUP_MODULE_BASE].Replace(Dict))
 elif Info.ModuleType in SUP_MODULE_SET_PEI:
 AutoGenC.Append(gLibraryString['PEI'].Replace(Dict))
@@ -1533,7 +1533,7 @@ def CreateModuleEntryPointCode(Info, AutoGenC, AutoGenH):
 #   @param  AutoGenHThe TemplateString object for header file
 #
 def CreateModuleUnloadImageCode(Info, AutoGenC, AutoGenH):
-if Info.IsLibrary or Info.ModuleType in [SUP_MODULE_USER_DEFINED, 
SUP_MODULE_SEC]:
+if Info.IsLibrary or Info.ModuleType in [SUP_MODULE_USER_DEFINED, 
SUP_MODULE_BASE, SUP_MODULE_SEC]:
 return
 #
 # Unload Image Handlers
-- 
2.19.2.windows.1

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

Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO widths

[Ard Biesheuvel]

On Wed, 20 Feb 2019 at 02:19, Wu, Hao A  wrote:
>
> > -Original Message-
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: Sunday, February 03, 2019 8:39 PM
> > To: Wu, Hao A
> > Cc: Jeff Brasen; edk2-devel@lists.01.org; Edgar Handal; Marcin Wojtas
> > Subject: Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit
> > IO widths
> >
> > On Fri, 1 Feb 2019 at 06:55, Wu, Hao A  wrote:
> > >
> > > > -Original Message-
> > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Jeff
> > > > Brasen
> > > > Sent: Thursday, January 31, 2019 7:59 AM
> > > > To: edk2-devel@lists.01.org
> > > > Cc: Edgar Handal; Jeff Brasen
> > > > Subject: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit
> > IO
> > > > widths
> > > >
> > > > From: Edgar Handal 
> > > >
> > > > Use 16-bit and 32-bit IO widths for SDMMC MMIO to prevent all register
> > > > accesses from being split up into 8-bit accesses.
> > > >
> > > > The SDHCI specification states that the registers shall be accessable in
> > > > byte, word, and double word accesses.
> > >
> >
> > Acked-by: Ard Biesheuvel 
>
> Ard,
>
> Really sorry for missing your 'Acked-by' tag.
> It came to me after I pushed the commit.
>
> Sorry again for this.
>

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

[edk2] [Patch] BaseTool: Fixed incremental rebuild issue.

[Feng, Bob C]

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

This issue in introduced by commit
d943b0c339fe3d35ffdf9f580ccb7a55915c6854

To convert bytes to string, we need to use bytes.decode()
instead of using str(bytes)

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng 
Cc: Liming Gao 
---
 BaseTools/Source/Python/AutoGen/GenMake.py| 2 +-
 BaseTools/Source/Python/Workspace/DscBuildData.py | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/GenMake.py 
b/BaseTools/Source/Python/AutoGen/GenMake.py
index 53c5b8577d..641ed8305f 100644
--- a/BaseTools/Source/Python/AutoGen/GenMake.py
+++ b/BaseTools/Source/Python/AutoGen/GenMake.py
@@ -1048,11 +1048,11 @@ cleanlib:
 
 if FileContent[0] == 0xff or FileContent[0] == 0xfe:
 FileContent = FileContent.decode('utf-16')
 else:
 try:
-FileContent = str(FileContent)
+FileContent = FileContent.decode()
 except:
 pass
 IncludedFileList = gIncludePattern.findall(FileContent)
 
 for Inc in IncludedFileList:
diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py 
b/BaseTools/Source/Python/Workspace/DscBuildData.py
index 1ffefe6e7e..74bc333144 100644
--- a/BaseTools/Source/Python/Workspace/DscBuildData.py
+++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
@@ -158,11 +158,11 @@ def GetDependencyList(FileStack, SearchPathList):
 if FileContent[0] == 0xff or FileContent[0] == 0xfe:
 FileContent = FileContent.decode('utf-16')
 IncludedFileList = gIncludePattern.findall(FileContent)
 else:
 try:
-FileContent = str(FileContent)
+FileContent = FileContent.decode()
 IncludedFileList = gIncludePattern.findall(FileContent)
 except:
 pass
 IncludedFileList = gIncludePattern.findall(FileContent)
 
-- 
2.20.1.windows.1

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

Re: [edk2] [PATCH v2 2/5] OvmfPkg: add library to track boot option loading/starting on the console

[Ard Biesheuvel]

On Wed, 20 Feb 2019 at 11:04, Laszlo Ersek  wrote:
>
> On 02/20/19 09:16, Laszlo Ersek wrote:
> > Introduce the Platform Boot Manager Print Status Code Library (for short,
> > PlatformBmPrintScLib) class for catching and printing the LoadImage() /
> > StartImage() preparations, and return statuses, that are reported by
> > UefiBootManagerLib.
> >
> > In the primary library instance, catch only such status codes that
> > UefiBootManagerLib reports from the same module that contains
> > PlatformBmPrintScLib. The intent is to establish a reporting-printing
> > channel within BdsDxe, between UefiBootManagerLib and
> > PlatformBmPrintScLib. Ignore status codes originating elsewhence, e.g.
> > from UiApp's copy of UefiBootManagerLib.
> >
> > Cc: Anthony Perard 
> > Cc: Ard Biesheuvel 
> > Cc: Jordan Justen 
> > Cc: Julien Grall 
> > Cc: Ray Ni 
> > Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Laszlo Ersek 
> > ---
> >
> > Notes:
> > v2:
> >
> > - Split the status code handling to a separate library, so that it's
> >   easy to reuse in ArmVirtPkg.
> >
> > - Rework the logic based on
> >    and
> >   , and follow Ray's
> >   advice in
> >   
> > :
> >
> >   - The boot option details are fetched via BootCurrent.
> >
> >   - For reporting LoadImage() and StartImage() preparations, replace the
> > originally proposed PcdDebugCodeOsLoaderDetail status code with the
> > existent (edk2-specific) PcdProgressCodeOsLoaderLoad and
> > PcdProgressCodeOsLoaderStart status codes.
> >
> >   - For reporting LoadImage() and StartImage() return values, replace
> > the originally proposed PcdDebugCodeOsLoaderDetail status code with
> > the standard EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR and
> > EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED status codes.
> >
> >   - For all four kinds of reports, replace the originally proposed "OS
> > Loader Detail" structure (and GUID) with the recently standardized
> > EFI_RETURN_STATUS_EXTENDED_DATA structure.
> >
> >  OvmfPkg/OvmfPkg.dec   |   5 +
> >  OvmfPkg/OvmfPkgIa32.dsc   |   1 +
> >  OvmfPkg/OvmfPkgIa32X64.dsc|   1 +
> >  OvmfPkg/OvmfPkgX64.dsc|   1 +
> >  OvmfPkg/Include/Library/PlatformBmPrintScLib.h|  41 +++
> >  OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf |  66 +
> >  OvmfPkg/Library/PlatformBmPrintScLib/StatusCodeHandler.c  | 310 
> > 
> >  7 files changed, 425 insertions(+)
> >
> > diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> > index 7666297cf8f1..e50c6179a249 100644
> > --- a/OvmfPkg/OvmfPkg.dec
> > +++ b/OvmfPkg/OvmfPkg.dec
> > @@ -45,6 +45,11 @@ [LibraryClasses]
> >#  access.
> >PciCapPciSegmentLib|Include/Library/PciCapPciSegmentLib.h
> >
> > +  ##  @libraryclass  Register a status code handler for printing the Boot
> > +  #  Manager's LoadImage() and StartImage() preparations, 
> > and
> > +  #  return codes, to the UEFI console.
> > +  PlatformBmPrintScLib|Include/Library/PlatformBmPrintScLib.h
> > +
> >##  @libraryclass  Access QEMU's firmware configuration interface
> >#
> >QemuFwCfgLib|Include/Library/QemuFwCfgLib.h
> > diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> > index f9216af479f4..5b885590b275 100644
> > --- a/OvmfPkg/OvmfPkgIa32.dsc
> > +++ b/OvmfPkg/OvmfPkgIa32.dsc
> > @@ -348,6 +348,7 @@ [LibraryClasses.common.DXE_DRIVER]
> >UdpIoLib|MdeModulePkg/Library/DxeUdpIoLib/DxeUdpIoLib.inf
> >DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
> >
> > PlatformBootManagerLib|OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> > +  
> > PlatformBmPrintScLib|OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf
> >QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
> >
> > CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
> >  !if $(SMM_REQUIRE) == TRUE
> > diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> > index 1e470de74434..bbf0853ee6b9 100644
> > --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> > +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> > @@ -353,6 +353,7 @@ [LibraryClasses.common.DXE_DRIVER]
> >UdpIoLib|MdeModulePkg/Library/DxeUdpIoLib/DxeUdpIoLib.inf
> >DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
> >
> > PlatformBootManagerLib|OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> > +  
> > 

Re: [edk2] [PATCH v2 2/5] OvmfPkg: add library to track boot option loading/starting on the console

[Laszlo Ersek]

On 02/20/19 09:16, Laszlo Ersek wrote:
> Introduce the Platform Boot Manager Print Status Code Library (for short,
> PlatformBmPrintScLib) class for catching and printing the LoadImage() /
> StartImage() preparations, and return statuses, that are reported by
> UefiBootManagerLib.
> 
> In the primary library instance, catch only such status codes that
> UefiBootManagerLib reports from the same module that contains
> PlatformBmPrintScLib. The intent is to establish a reporting-printing
> channel within BdsDxe, between UefiBootManagerLib and
> PlatformBmPrintScLib. Ignore status codes originating elsewhence, e.g.
> from UiApp's copy of UefiBootManagerLib.
> 
> Cc: Anthony Perard 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Julien Grall 
> Cc: Ray Ni 
> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> v2:
> 
> - Split the status code handling to a separate library, so that it's
>   easy to reuse in ArmVirtPkg.
> 
> - Rework the logic based on
>    and
>   , and follow Ray's
>   advice in
>   
> :
> 
>   - The boot option details are fetched via BootCurrent.
> 
>   - For reporting LoadImage() and StartImage() preparations, replace the
> originally proposed PcdDebugCodeOsLoaderDetail status code with the
> existent (edk2-specific) PcdProgressCodeOsLoaderLoad and
> PcdProgressCodeOsLoaderStart status codes.
> 
>   - For reporting LoadImage() and StartImage() return values, replace
> the originally proposed PcdDebugCodeOsLoaderDetail status code with
> the standard EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR and
> EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED status codes.
> 
>   - For all four kinds of reports, replace the originally proposed "OS
> Loader Detail" structure (and GUID) with the recently standardized
> EFI_RETURN_STATUS_EXTENDED_DATA structure.
> 
>  OvmfPkg/OvmfPkg.dec   |   5 +
>  OvmfPkg/OvmfPkgIa32.dsc   |   1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc|   1 +
>  OvmfPkg/OvmfPkgX64.dsc|   1 +
>  OvmfPkg/Include/Library/PlatformBmPrintScLib.h|  41 +++
>  OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf |  66 +
>  OvmfPkg/Library/PlatformBmPrintScLib/StatusCodeHandler.c  | 310 
> 
>  7 files changed, 425 insertions(+)
> 
> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index 7666297cf8f1..e50c6179a249 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -45,6 +45,11 @@ [LibraryClasses]
>#  access.
>PciCapPciSegmentLib|Include/Library/PciCapPciSegmentLib.h
>  
> +  ##  @libraryclass  Register a status code handler for printing the Boot
> +  #  Manager's LoadImage() and StartImage() preparations, and
> +  #  return codes, to the UEFI console.
> +  PlatformBmPrintScLib|Include/Library/PlatformBmPrintScLib.h
> +
>##  @libraryclass  Access QEMU's firmware configuration interface
>#
>QemuFwCfgLib|Include/Library/QemuFwCfgLib.h
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index f9216af479f4..5b885590b275 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -348,6 +348,7 @@ [LibraryClasses.common.DXE_DRIVER]
>UdpIoLib|MdeModulePkg/Library/DxeUdpIoLib/DxeUdpIoLib.inf
>DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
>
> PlatformBootManagerLib|OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> +  
> PlatformBmPrintScLib|OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf
>QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
>
> CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
>  !if $(SMM_REQUIRE) == TRUE
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 1e470de74434..bbf0853ee6b9 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -353,6 +353,7 @@ [LibraryClasses.common.DXE_DRIVER]
>UdpIoLib|MdeModulePkg/Library/DxeUdpIoLib/DxeUdpIoLib.inf
>DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
>
> PlatformBootManagerLib|OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> +  
> PlatformBmPrintScLib|OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf
>QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
>
> CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
>  !if 

Re: [edk2] Issues with EDK-II-Debugging wiki page, and how to submit a pull request for wiki pages

[Laszlo Ersek]

On 02/20/19 08:45, Rebecca Cran wrote:
> On Thursday, 14 February 2019 12:23:05 MST Laszlo Ersek wrote:
> 
>> The wikis on github are non-intuitive, if you intend to edit them in a
>> normal text editor, locally. I struggled a lot until I came up with the
>> list on top. (It's possible I relied on others' advice in that; I no
>> longer remember.) I hope it helps.
> 
> Yeah, thanks but no thanks. I'm not _that_ keen on making my changes if it's 
> going to involve all that work!
> 

Totally understandable. I *think* it should be possible to simply edit
the wiki articles with github's built-in wiki editor too, but I have no
clue about the credentials needed. Perhaps being a member of the
 organization suffices; I'm not certain.

Mike, can you please comment? What's the best process for wiki edits?

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

Re: [edk2] [PATCH v5 08/13] MdeModulePkg/AhciPei: Add AHCI mode ATA device support in PEI

[Ni, Ray]

+//
+// Check validity of the device path of the ATA AHCI controller.
+//
+Status = AhciCheckHcDevicePath (DevicePath, DevicePathLength);


1. Please avoid using "Check".


+if (EFI_ERROR (Status)) {
+  DEBUG ((
+DEBUG_ERROR, "%a: The device path is invalid for Controller %d.\n",
+__FUNCTION__, Controller
+));
+  Controller++;
+  continue;
+}
+


2. Please add more comments here.


+if (BootMode == BOOT_ON_S3_RESUME) {
+  NumberOfPorts = AhciS3GetEumeratePorts (DevicePath, DevicePathLength, 
);
+  if (NumberOfPorts == 0) {
+//
+// No ports need to be enumerated for this controller.
+//
+Controller++;
+continue;
+  }
+} else {
+  PortBitMap = MAX_UINT32;
+}
+
+//

With the above comments addressed, Reviewed-by: Ray Ni 

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

Re: [edk2] [PATCH] OvmfPkg/Sec: Clear the Cache Disable flag in the CR0 register

[Laszlo Ersek]

On 02/19/19 20:51, Andrew Fish wrote:
> 
> 
>> On Feb 18, 2019, at 5:23 AM, Laszlo Ersek  wrote:
>>
>> generic comment (applies to all NASM usage I guess):
>>
>> On 02/18/19 11:10, Jordan Justen wrote:
>>
>>> +mov eax, cr0
>>> +and eax, ~(1 << 30)
>>> +mov cr0, eax
>>
>>> +mov rax, cr0
>>> +and eax, ~(1 << 30)
>>> +mov cr0, rax
>>
>> I've read up on the << and ~ operators in the NASM documentation, and I
>> think the above build-time calculations of the masks are well-defined
>> and correct.
>>
>> - bit shifts are always unsigned
>> - given bit position 30, ~(1 << 30) will be a value with 32 bits
>> - bit-neg simply flips bits (one's complement)
>>
>> On the other hand, I find these NASM specifics counter-intuitive. The
>> expression ~(1 << 30) looks like valid C, but in C, it means a quite
>> different thing.
>>
>> I think calculating the mask with "strict dword" somehow (not exactly
>> sure how) would make this more readable; or else the BTR instruction would.
>>
>> Opinions? (Again, pertaining to all NASM usage in edk2.)
>>
> 
> Lazlo,
> 
> I guess comments, or #defines, are other options?

Good point! They are.

Thanks,
Laszlo

> Thanks,
> 
> Andrew Fish
> 
>> Thanks
>> Laszlo
>> ___
>> 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] OvmfPkg/Sec: Clear the Cache Disable flag in the CR0 register

[Laszlo Ersek]

On 02/19/19 20:59, Jordan Justen wrote:
> On 2019-02-18 05:23:28, Laszlo Ersek wrote:
>> generic comment (applies to all NASM usage I guess):
>>
>> On 02/18/19 11:10, Jordan Justen wrote:
>>
>>> +mov eax, cr0
>>> +and eax, ~(1 << 30)
>>> +mov cr0, eax
>>
>>> +mov rax, cr0
>>> +and eax, ~(1 << 30)
>>> +mov cr0, rax
>>
>> I've read up on the << and ~ operators in the NASM documentation, and I
>> think the above build-time calculations of the masks are well-defined
>> and correct.
>>
>> - bit shifts are always unsigned
>> - given bit position 30, ~(1 << 30) will be a value with 32 bits
>> - bit-neg simply flips bits (one's complement)
>>
>> On the other hand, I find these NASM specifics counter-intuitive. The
>> expression ~(1 << 30) looks like valid C, but in C, it means a quite
>> different thing.
> 
> Can you elaborate? I guess there might be something subtly different,
> but for the most part it means the same thing, right?
> 
>> I think calculating the mask with "strict dword" somehow (not exactly
>> sure how) would make this more readable;
> 
> Oh, are you saying that (1 << 30) doesn't necessarily mean we are
> operating on a 32-bit value?

I think the code is fine as-is, in the technical sense; it is just
confusing/concerning to read for someone with a background in C. The
expression *looks* like C, but doesn't *behave* like in C. Ultimately,
the actual behavior is *right* for the assembly, but the code is still
difficult to read. (To me anyway.)

>> or else the BTR instruction would.
> 
> Yeah, I guess this works.
> 
>> Opinions? (Again, pertaining to all NASM usage in edk2.)
> 
> As always, my opinion is to avoid writing assembly code. :)
> 
> We actually had a version that set this just before the decompress in
> SecMain.c. Then I noted that we were initializing temp-ram here, so I
> moved it, even though the memory init doesn't take a significant
> amount of time compared to the decompress. Maybe we should just do
> that instead?

I think I would prefer that, yes, if the performance on ACRN remains
tolerable like that.

In fact... can you identify ACRN through AsmCpuidEx() or similar, and
restrict the CR0.CD manipulation to ACRN?

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

Re: [edk2] [PATCH v5 07/13] MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList LockBox

[Ni, Ray]

Please add some comments above "if" to explain why the it's only skipped 
in S3 boot.

With the updated comments, Reviewed-by: Ray Ni 

> +if ((BootMode == BOOT_ON_S3_RESUME) &&
> +(NvmeS3SkipThisController (DevicePath, DevicePathLength))) {
> +  DEBUG ((
> +DEBUG_ERROR, "%a: Controller %d is skipped during S3.\n",
> +__FUNCTION__, Controller
> +));
> +  Controller++;
> +  continue;
> +}
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] OvmfPkg/Sec: Clear the Cache Disable flag in the CR0 register

[Laszlo Ersek]

On 02/20/19 03:43, Fang, Peter wrote:
> When CR0.CD is set, KVM *might* emulate it by setting MTRR_TYPE_UNCACHABLE in 
> its EPTE if non-coherent DMA is detected, because VT-d does not provide 
> snooping in this case.

I think this was precisely the use case that I had to tweak with Linux
commit 879ae1880449. (Which complemented earlier tweak fb279950ba02.)
The original commit fb279950ba02 -- i.e., the kernel regression --
mentions "noncoherent_dma guests".

> AFAIK, leaving the bit on can have a performance impact for Xen as well.

I can't comment on that; haven't seen it reported.

> This issue was found when we tried to boot OVMF on ACRN.

Ah, yet another "small footprint" VMM. :)

> ACRN emulates CR0.CD through guest IPAT and memory decompression took a very 
> long time to finish (tens of seconds).

OK. Please include this description of the use case in the commit
message. If we have a specific use case that triggers a symptom, the
commit message shouldn't be general only. It can be general too, but the
specifics should be mentioned.

I consider this patch easy to revert (if necessary) for a long time to
come. So I'm not too worried about regressing other setups. If we do, we
can revert the patch.

I'm OK with the patch once the commit message is cleaned up, and we
figure out what we want to do about "~(1 << 30)" vs. BTR in the assembly.

Thanks,
Laszlo


>> -Original Message-
>> From: Justen, Jordan L
>> Sent: Tuesday, February 19, 2019 11:45 AM
>> To: Laszlo Ersek ; edk2-devel@lists.01.org
>> Cc: Fang, Peter ; Ma, Maurice
>> ; Ard Biesheuvel ;
>> Anthony Perard ; Julien Grall
>> 
>> Subject: Re: [PATCH] OvmfPkg/Sec: Clear the Cache Disable flag in the CR0
>> register
>>
>> On 2019-02-18 04:17:26, Laszlo Ersek wrote:
>>> On 02/18/19 11:10, Jordan Justen wrote:
 Clear the CD (Cache Disable) flag in the CR0 register. When the VM
 implements the CD flag, this can substantially decrease the time it
 takes to decompress the firmware volumes.

 Contributed-under: TianoCore Contribution Agreement 1.1
 Signed-off-by: Jordan Justen 
 Tested-by: Peter Fang 
 Cc: Peter Fang 
 Cc: Maurice Ma 
 Cc: Laszlo Ersek 
 Cc: Ard Biesheuvel 
 Cc: Anthony Perard 
 Cc: Julien Grall 
 ---
  OvmfPkg/Sec/Ia32/SecEntry.nasm | 8 +++-
 OvmfPkg/Sec/X64/SecEntry.nasm  | 8 +++-
  2 files changed, 14 insertions(+), 2 deletions(-)

 diff --git a/OvmfPkg/Sec/Ia32/SecEntry.nasm
 b/OvmfPkg/Sec/Ia32/SecEntry.nasm index 03501969eb..fc7f47385a
>> 100644
 --- a/OvmfPkg/Sec/Ia32/SecEntry.nasm
 +++ b/OvmfPkg/Sec/Ia32/SecEntry.nasm
 @@ -40,6 +40,13 @@ extern ASM_PFX(SecCoreStartupWithStack)  global
 ASM_PFX(_ModuleEntryPoint)
  ASM_PFX(_ModuleEntryPoint):

 +;
 +; Clear the CD (Cache Disable) flag in the CR0 register.
 +;
 +mov eax, cr0
 +and eax, ~(1 << 30)
 +mov cr0, eax
 +
  ;
  ; Fill the temporary RAM with the initial stack value.
  ; The loop below will seed the heap as well, but that's harmless.
 @@ -71,4 +78,3 @@ ASM_PFX(_ModuleEntryPoint):
  pusheax
  pushebp
  callASM_PFX(SecCoreStartupWithStack)
 -
 diff --git a/OvmfPkg/Sec/X64/SecEntry.nasm
 b/OvmfPkg/Sec/X64/SecEntry.nasm index d76adcffd8..7471b3a3e3
>> 100644
 --- a/OvmfPkg/Sec/X64/SecEntry.nasm
 +++ b/OvmfPkg/Sec/X64/SecEntry.nasm
 @@ -41,6 +41,13 @@ extern ASM_PFX(SecCoreStartupWithStack)  global
 ASM_PFX(_ModuleEntryPoint)
  ASM_PFX(_ModuleEntryPoint):

 +;
 +; Clear the CD (Cache Disable) flag in the CR0 register.
 +;
 +mov rax, cr0
 +and eax, ~(1 << 30)
 +mov cr0, rax
 +
  ;
  ; Fill the temporary RAM with the initial stack value.
  ; The loop below will seed the heap as well, but that's harmless.
 @@ -72,4 +79,3 @@ ASM_PFX(_ModuleEntryPoint):
  mov rdx, rsp
  sub rsp, 0x20
  callASM_PFX(SecCoreStartupWithStack)
 -

>>>
>>> In commit 98f378a7be12 ("OvmfPkg/ResetVector: enable caching in
>>> initial page tables", 2013-09-24), we said
>>>
>>> In UEFI X64 we use other mechanisms to disable caching.
>>> (CD/NW in CR0 and MTRRs.)
>>>
>>> That suggests that having caching disabled in SEC is a good thing.
>>
>> I think there can be good reasons to disable caching on a platform, such as
>> during memory initialization, but I'm not sure any apply to OVMF.
>>
>> As far as I know, kvm still doesn't attempt to disable caching via the CR0.CD
>> bit or the MTRRs. This kind of backs up the previous statement about there
>> not being a reason to disable caching in OVMF.
>>
>>> What has changed? I assume Peter reported a problem.
>>>
>>> ... Is this by any chance related to Linux commit 879ae1880449 ("KVM:
>>> x86: obey KVM_X86_QUIRK_CD_NW_CLEARED in kvm_set_cr0()", 

Re: [edk2] [patch 2/2] MdeModulePkg/BmBoot: Report status when fail to load/start boot option

[Laszlo Ersek]

+Mark, for my comments on the process

On 02/20/19 03:21, Ni, Ray wrote:
> Laszlo,
> Thanks for catching this.
> 
> GenPerformMemoryTest() in
> MdeModulePkg\Universal\MemoryTest\GenericMemoryTestDxe\LightMemoryTest.c
> uses the same technics as you suggested.
> 
> I give up to propose another option: having pack(1) for the new status 
> structure.

I think that byte-packing EFI_RETURN_STATUS_EXTENDED_DATA in the PI-1.7
spec would have been viable, but we should have thought about that in
advance. The PI and UEFI specs require natural alignment for structure
members, unless stated otherwise. There *are* a number of examples of
"stated otherwise" (the term that the specs use is frequently
"byte-packed structure"). Again, we should have thought of that in
advance, before PI-1.7 was released, so now we can only fix the way the
object is populated.

More generally, I think this demonstrates a flaw in the standardization
process. PIWG and USWG should only standardize existing practice; that
is, features that have at least one functional implementation. (Not
necessarily open source, but the interfaces should be battle-hardened
*first*.) The restriction where we can't even propose patches for edk2
before the standards are updated is very counter-productive. There's
practically zero chance for getting an actual implementation
peer-reviewed and peer-tested before proposing the API for the standard.

Personally I have suggested in the past to implement some new features
as edk2 extensions first, and once they work, to upstream them to the
standards. This idea is usually rejected by maintainers, because
maintainers worry about becoming stuck with more and more edk2
extensions to core code (i.e., they worry about the feature proponents
not making good on their promise to standardize). Unfortunately, the
alternative (= the current practice) is that we standardize speculative
interfaces, which then prove suboptimal once we implement them.

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

Re: [edk2] [PATCH v2 2/5] OvmfPkg: add library to track boot option loading/starting on the console

[Ard Biesheuvel]

On Wed, 20 Feb 2019 at 09:16, Laszlo Ersek  wrote:
>
> Introduce the Platform Boot Manager Print Status Code Library (for short,
> PlatformBmPrintScLib) class for catching and printing the LoadImage() /
> StartImage() preparations, and return statuses, that are reported by
> UefiBootManagerLib.
>
> In the primary library instance, catch only such status codes that
> UefiBootManagerLib reports from the same module that contains
> PlatformBmPrintScLib. The intent is to establish a reporting-printing
> channel within BdsDxe, between UefiBootManagerLib and
> PlatformBmPrintScLib. Ignore status codes originating elsewhence, e.g.
> from UiApp's copy of UefiBootManagerLib.
>
> Cc: Anthony Perard 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Julien Grall 
> Cc: Ray Ni 
> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek 
> ---
>
> Notes:
> v2:
>
> - Split the status code handling to a separate library, so that it's
>   easy to reuse in ArmVirtPkg.
>
> - Rework the logic based on
>    and
>   , and follow Ray's
>   advice in
>   
> :
>
>   - The boot option details are fetched via BootCurrent.
>
>   - For reporting LoadImage() and StartImage() preparations, replace the
> originally proposed PcdDebugCodeOsLoaderDetail status code with the
> existent (edk2-specific) PcdProgressCodeOsLoaderLoad and
> PcdProgressCodeOsLoaderStart status codes.
>
>   - For reporting LoadImage() and StartImage() return values, replace
> the originally proposed PcdDebugCodeOsLoaderDetail status code with
> the standard EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR and
> EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED status codes.
>
>   - For all four kinds of reports, replace the originally proposed "OS
> Loader Detail" structure (and GUID) with the recently standardized
> EFI_RETURN_STATUS_EXTENDED_DATA structure.
>
>  OvmfPkg/OvmfPkg.dec   |   5 +
>  OvmfPkg/OvmfPkgIa32.dsc   |   1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc|   1 +
>  OvmfPkg/OvmfPkgX64.dsc|   1 +
>  OvmfPkg/Include/Library/PlatformBmPrintScLib.h|  41 +++
>  OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf |  66 +
>  OvmfPkg/Library/PlatformBmPrintScLib/StatusCodeHandler.c  | 310 
> 
>  7 files changed, 425 insertions(+)
>
...
> diff --git a/OvmfPkg/Library/PlatformBmPrintScLib/StatusCodeHandler.c 
> b/OvmfPkg/Library/PlatformBmPrintScLib/StatusCodeHandler.c
> new file mode 100644
> index ..9806d3c7411e
> --- /dev/null
> +++ b/OvmfPkg/Library/PlatformBmPrintScLib/StatusCodeHandler.c
> @@ -0,0 +1,310 @@
> +/** @file
> +  Register a status code handler for printing the Boot Manager's LoadImage()
> +  and StartImage() preparations, and return codes, to the UEFI console.
> +
> +  This feature enables users that are not accustomed to analyzing the 
> firmware
> +  log to glean some information about UEFI boot option processing (loading 
> and
> +  starting).
> +
> +  This library instance filters out (ignores) status codes that are not
> +  reported by the containing firmware module. The intent is to link this
> +  library instance into BdsDxe via PlatformBootManagerLib (which BdsDxe 
> depends
> +  upon), then catch only those status codes that BdsDxe reports (which 
> happens
> +  via UefiBootManagerLib). Status codes reported by other modules (such as
> +  UiApp), via UefiBootManagerLib or otherwise, are meant to be ignored.
> +
> +  Copyright (C) 2019, 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 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +
> +#include 
> +
> +
> +//
> +// Convenience variables for the status codes that are relevant for 
> LoadImage()
> +// and StartImage() preparations and return codes.
> +//
> +STATIC EFI_STATUS_CODE_VALUE mLoadPrep;
> +STATIC EFI_STATUS_CODE_VALUE mLoadFail;
> +STATIC EFI_STATUS_CODE_VALUE mStartPrep;
> +STATIC EFI_STATUS_CODE_VALUE mStartFail;
> +
> +
> +/**
> +  Handle status codes 

Re: [edk2] [PATCH 06/10] OvmfPkg/Sec: Disable optimizations for TemporaryRamMigration

[Ard Biesheuvel]

On Wed, 20 Feb 2019 at 09:52, Jordan Justen  wrote:
>
> On 2019-02-18 01:32:53, Ard Biesheuvel wrote:
> > On Mon, 18 Feb 2019 at 10:08, Jordan Justen  
> > wrote:
> > >
> > > On 2019-02-17 23:53:01, Ard Biesheuvel wrote:
> > > > On Mon, 18 Feb 2019 at 05:12, Jordan Justen  
> > > > wrote:
> > > > >
> > > >
> > > > This needs an explanation why optimization needs to be disabled.
> > >
> > > I'm not sure this is required. The reason I added these patches is to
> > > hopefully prevent the compiler from removing the frame pointer. We
> > > adjust the frame pointer in the code, and that is a little sketchy if
> > > the frame pointer isn't being used.
> > >
> > > Unfortunately, it can reasonably be argued that the
> > > TemporaryRamSupport PPI definition ultimately makes it unsafe to write
> > > the migration code in C.
> > >
> > > I tried reverting both the EmulatorPkg and OvmfPkg patches for
> > > disabling the optimizations, and with my setup there was no impact. I
> > > think there is a good change that we'd be pretty safe to just drop
> > > these two patches to wait and see if someone encounters a situation
> > > that requires it.
> > >
> > > Ok, so based on this explanation, do you think I should add info to
> > > the commit message and keep the patches, or just drop them?
> > >
> >
> > I think 'little sketchy' is an understatement here (as is
> > setjmp/longjmp in general), but it is the reality we have to deal with
> > when writing startup code in C. Looking at the code, I agree that the
> > fact that [re]bp is assigned directly implies that we should not
> > permit it to be used as a general purpose register, especially when
> > you throw LTO into the mix, which could produce all kinds of
> > surprising results when it decides to inline functions being called
> > from here.
> >
> > For GCC/Clang, I don't think it is correct to assume that changing the
> > optimization level will result in -fno-omit-frame-pointer to be set,
> > so I'd prefer setting that option directly, either via the pragma, or
> > for the whole file.
>
> Based on: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
>
> It appears that -O0 will not have -fomit-frame-pointer, since that is
> added in -O1.
>

For current versions of GCC, perhaps. But what about older versions?
What about future versions? What about Clang?

> For both gcc and MSVC, I think we could be more targeted:
>
>  #ifdef __GNUC__
>  #pragma GCC push_options
>  #pragma GCC optimize ("no-omit-frame-pointer")
>  #else
>  #pragma optimize ("y", off)
>  #endif
>
> Do you prefer this version?
>

Assuming that "y" affects frame pointer generation, yes.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 06/10] OvmfPkg/Sec: Disable optimizations for TemporaryRamMigration

[Jordan Justen]

On 2019-02-18 01:32:53, Ard Biesheuvel wrote:
> On Mon, 18 Feb 2019 at 10:08, Jordan Justen  wrote:
> >
> > On 2019-02-17 23:53:01, Ard Biesheuvel wrote:
> > > On Mon, 18 Feb 2019 at 05:12, Jordan Justen  
> > > wrote:
> > > >
> > >
> > > This needs an explanation why optimization needs to be disabled.
> >
> > I'm not sure this is required. The reason I added these patches is to
> > hopefully prevent the compiler from removing the frame pointer. We
> > adjust the frame pointer in the code, and that is a little sketchy if
> > the frame pointer isn't being used.
> >
> > Unfortunately, it can reasonably be argued that the
> > TemporaryRamSupport PPI definition ultimately makes it unsafe to write
> > the migration code in C.
> >
> > I tried reverting both the EmulatorPkg and OvmfPkg patches for
> > disabling the optimizations, and with my setup there was no impact. I
> > think there is a good change that we'd be pretty safe to just drop
> > these two patches to wait and see if someone encounters a situation
> > that requires it.
> >
> > Ok, so based on this explanation, do you think I should add info to
> > the commit message and keep the patches, or just drop them?
> >
> 
> I think 'little sketchy' is an understatement here (as is
> setjmp/longjmp in general), but it is the reality we have to deal with
> when writing startup code in C. Looking at the code, I agree that the
> fact that [re]bp is assigned directly implies that we should not
> permit it to be used as a general purpose register, especially when
> you throw LTO into the mix, which could produce all kinds of
> surprising results when it decides to inline functions being called
> from here.
> 
> For GCC/Clang, I don't think it is correct to assume that changing the
> optimization level will result in -fno-omit-frame-pointer to be set,
> so I'd prefer setting that option directly, either via the pragma, or
> for the whole file.

Based on: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

It appears that -O0 will not have -fomit-frame-pointer, since that is
added in -O1.

For both gcc and MSVC, I think we could be more targeted:

 #ifdef __GNUC__
 #pragma GCC push_options
 #pragma GCC optimize ("no-omit-frame-pointer")
 #else
 #pragma optimize ("y", off)
 #endif

Do you prefer this version?

-Jordan

> For MSVC, I have no idea how to tweak the compiler to force it to emit
> frame pointers.
> 
> 
> > >
> > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > Signed-off-by: Jordan Justen 
> > > > Cc: Laszlo Ersek 
> > > > Cc: Ard Biesheuvel 
> > > > Cc: Anthony Perard 
> > > > Cc: Julien Grall 
> > > > ---
> > > >  OvmfPkg/Sec/SecMain.c | 12 
> > > >  1 file changed, 12 insertions(+)
> > > >
> > > > diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c
> > > > index 46ac739862..86c22a2ac9 100644
> > > > --- a/OvmfPkg/Sec/SecMain.c
> > > > +++ b/OvmfPkg/Sec/SecMain.c
> > > > @@ -873,6 +873,13 @@ SecStartupPhase2(
> > > >CpuDeadLoop ();
> > > >  }
> > > >
> > > > +#ifdef __GNUC__
> > > > +#pragma GCC push_options
> > > > +#pragma GCC optimize ("O0")
> > > > +#else
> > > > +#pragma optimize ("", off)
> > > > +#endif
> > > > +
> > > >  EFI_STATUS
> > > >  EFIAPI
> > > >  TemporaryRamMigration (
> > > > @@ -946,3 +953,8 @@ TemporaryRamMigration (
> > > >return EFI_SUCCESS;
> > > >  }
> > > >
> > > > +#ifdef __GNUC__
> > > > +#pragma GCC pop_options
> > > > +#else
> > > > +#pragma optimize ("", on)
> > > > +#endif
> > >
> > > I can't tell from the context if this is the end of the file, but if
> > > it is not, aren't you turning on optimization here for non-GCC even if
> > > it was not enabled on the command line to begin with?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 5/6] MdeModulePkg: Add a runtime library instance of ResetSystemLib

[Zhichao Gao]

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

Implement a runtime library instance of ResetSystemLib. It would
use a internal point instead of gRT and convert it depend on
gEfiEventVirtualAddressChangeGuid.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhichao Gao 
Cc: Ray Ni 
Cc: Liming Gao 
---
 .../RuntimeResetSystemLib/RuntimeResetSystemLib.c  | 216 +
 .../RuntimeResetSystemLib.inf  |  50 +
 .../RuntimeResetSystemLib.uni  |  21 ++
 3 files changed, 287 insertions(+)
 create mode 100644 
MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.c
 create mode 100644 
MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.inf
 create mode 100644 
MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.uni

diff --git a/MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.c 
b/MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.c
new file mode 100644
index 00..17826cd6a9
--- /dev/null
+++ b/MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.c
@@ -0,0 +1,216 @@
+/** @file
+  DXE Reset System Library instance that calls gRT->ResetSystem().
+
+  Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  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 
+#include 
+#include 
+#include 
+
+EFI_EVENT mRuntimeResetSystemLibVirtualAddressChangeEvent;
+EFI_RUNTIME_SERVICES  *mInternalRT;
+
+/**
+  This function causes a system-wide reset (cold reset), in which
+  all circuitry within the system returns to its initial state. This type of 
reset
+  is asynchronous to system operation and operates without regard to
+  cycle boundaries.
+
+  If this function returns, it means that the system does not support cold 
reset.
+**/
+VOID
+EFIAPI
+ResetCold (
+  VOID
+  )
+{
+  mInternalRT->ResetSystem (EfiResetCold, EFI_SUCCESS, 0, NULL);
+}
+
+/**
+  This function causes a system-wide initialization (warm reset), in which all 
processors
+  are set to their initial state. Pending cycles are not corrupted.
+
+  If this function returns, it means that the system does not support warm 
reset.
+**/
+VOID
+EFIAPI
+ResetWarm (
+  VOID
+  )
+{
+  mInternalRT->ResetSystem (EfiResetWarm, EFI_SUCCESS, 0, NULL);
+}
+
+/**
+  This function causes the system to enter a power state equivalent
+  to the ACPI G2/S5 or G3 states.
+
+  If this function returns, it means that the system does not support shut 
down reset.
+**/
+VOID
+EFIAPI
+ResetShutdown (
+  VOID
+  )
+{
+  mInternalRT->ResetSystem (EfiResetShutdown, EFI_SUCCESS, 0, NULL);
+}
+
+/**
+  This function causes the system to enter S3 and then wake up immediately.
+
+  If this function returns, it means that the system does not support S3 
feature.
+**/
+VOID
+EFIAPI
+EnterS3WithImmediateWake (
+  VOID
+  )
+{
+}
+
+/**
+  This function causes a systemwide reset. The exact type of the reset is
+  defined by the EFI_GUID that follows the Null-terminated Unicode string 
passed
+  into ResetData. If the platform does not recognize the EFI_GUID in ResetData
+  the platform must pick a supported reset type to perform.The platform may
+  optionally log the parameters from any non-normal reset that occurs.
+
+  @param[in]  DataSize   The size, in bytes, of ResetData.
+  @param[in]  ResetData  The data buffer starts with a Null-terminated string,
+ followed by the EFI_GUID.
+**/
+VOID
+EFIAPI
+ResetPlatformSpecific (
+  IN UINTN   DataSize,
+  IN VOID*ResetData
+  )
+{
+  mInternalRT->ResetSystem (EfiResetPlatformSpecific, EFI_SUCCESS, DataSize, 
ResetData);
+}
+
+/**
+  The ResetSystem function resets the entire platform.
+
+  @param[in] ResetType  The type of reset to perform.
+  @param[in] ResetStatusThe status code for the reset.
+  @param[in] DataSize   The size, in bytes, of ResetData.
+  @param[in] ResetData  For a ResetType of EfiResetCold, EfiResetWarm, or 
EfiResetShutdown
+the data buffer starts with a Null-terminated 
string, optionally
+followed by additional binary data. The string is 
a description
+that the caller may use to further indicate the 
reason for the
+system reset. ResetData is only valid if 
ResetStatus is something
+other than EFI_SUCCESS unless the ResetType is 
EfiResetPlatformSpecific
+where a minimum amount of ResetData is always 
required.

[edk2] [PATCH v3 4/6] MdeModulePkg: Add the new API ResetSystem in the head file

[Zhichao Gao]

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

Add the new API ResetSystem in the related head file so that
the consumer can use it through the combination of library
instance and head file.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhichao Gao 
Cc: Ray Ni 
Cc: Liming Gao 
---
 MdeModulePkg/Include/Library/ResetSystemLib.h | 28 ++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Include/Library/ResetSystemLib.h 
b/MdeModulePkg/Include/Library/ResetSystemLib.h
index 55d1923ae1..e438a0a90e 100644
--- a/MdeModulePkg/Include/Library/ResetSystemLib.h
+++ b/MdeModulePkg/Include/Library/ResetSystemLib.h
@@ -2,7 +2,7 @@
   System reset Library Services.  This library class defines a set of
   methods that reset the whole system.
 
-Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2005 - 2019, Intel Corporation. All rights reserved.
 This program and the accompanying materials are licensed and made available 
under
 the terms and conditions of the BSD License that accompanies this distribution.
 The full text of the license may be found at
@@ -16,6 +16,9 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #ifndef __RESET_SYSTEM_LIB_H__
 #define __RESET_SYSTEM_LIB_H__
 
+#include 
+#include 
+
 /**
   This function causes a system-wide reset (cold reset), in which
   all circuitry within the system returns to its initial state. This type of 
reset
@@ -83,4 +86,27 @@ ResetPlatformSpecific (
   IN VOID*ResetData
   );
 
+/**
+  The ResetSystem function resets the entire platform.
+
+  @param[in] ResetType  The type of reset to perform.
+  @param[in] ResetStatusThe status code for the reset.
+  @param[in] DataSize   The size, in bytes, of ResetData.
+  @param[in] ResetData  For a ResetType of EfiResetCold, EfiResetWarm, or 
EfiResetShutdown
+the data buffer starts with a Null-terminated 
string, optionally
+followed by additional binary data. The string is 
a description
+that the caller may use to further indicate the 
reason for the
+system reset. ResetData is only valid if 
ResetStatus is something
+other than EFI_SUCCESS unless the ResetType is 
EfiResetPlatformSpecific
+where a minimum amount of ResetData is always 
required.
+**/
+VOID
+EFIAPI
+ResetSystem (
+  IN EFI_RESET_TYPE   ResetType,
+  IN EFI_STATUS   ResetStatus,
+  IN UINTNDataSize,
+  IN VOID *ResetData OPTIONAL
+  );
+
 #endif
-- 
2.16.2.windows.1

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

[edk2] [PATCH v3 0/6] ResetSystemLib changings

[Zhichao Gao]

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1460
Add a new API ResetSystem in ResetSystemLib.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1461
Implement a runtime library instance of ResetSystemLib base on the new changing.

V2: Add some required data type header file

V3: Resolve a case-typing error.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhichao Gao 
Cc: Ray Ni 
Cc: Liming Gao 

Zhichao Gao (6):
  MdeModulePkg: change the function name ResetSystem
  MdeModulePkg: Add a new API ResetSystem for DXE ResetSystemLib
  MdeModulePkg: Add a new API ResetSystem for Null version
  MdeModulePkg: Add the new API ResetSystem in the head file
  MdeModulePkg: Add a runtime library instance of ResetSystemLib
  MdeModulePkg: Add the runtime ResetSystemLib in MdeModulePkg.dsc

 MdeModulePkg/Include/Library/ResetSystemLib.h  |  28 ++-
 .../BaseResetSystemLibNull.c   |  27 +++
 .../Library/DxeResetSystemLib/DxeResetSystemLib.c  |  28 ++-
 .../RuntimeResetSystemLib/RuntimeResetSystemLib.c  | 216 +
 .../RuntimeResetSystemLib.inf  |  50 +
 .../RuntimeResetSystemLib.uni  |  21 ++
 MdeModulePkg/MdeModulePkg.dsc  |   1 +
 .../Universal/ResetSystemRuntimeDxe/ResetSystem.c  |   8 +-
 .../Universal/ResetSystemRuntimeDxe/ResetSystem.h  |   4 +-
 9 files changed, 375 insertions(+), 8 deletions(-)
 create mode 100644 
MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.c
 create mode 100644 
MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.inf
 create mode 100644 
MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.uni

-- 
2.16.2.windows.1

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

[edk2] [PATCH v3 2/6] MdeModulePkg: Add a new API ResetSystem for DXE ResetSystemLib

[Zhichao Gao]

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

Add a new API ResetSystem for DXE ResetSystemLib. So the consumer of
ResetSystemLib can use this API to reset system with additional reset
data.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhichao Gao 
Cc: Ray Ni 
Cc: Liming Gao 
---
 .../Library/DxeResetSystemLib/DxeResetSystemLib.c  | 28 +-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/DxeResetSystemLib/DxeResetSystemLib.c 
b/MdeModulePkg/Library/DxeResetSystemLib/DxeResetSystemLib.c
index ea4878cab1..f5c7386c9a 100644
--- a/MdeModulePkg/Library/DxeResetSystemLib/DxeResetSystemLib.c
+++ b/MdeModulePkg/Library/DxeResetSystemLib/DxeResetSystemLib.c
@@ -1,7 +1,7 @@
 /** @file
   DXE Reset System Library instance that calls gRT->ResetSystem().
 
-  Copyright (c) 2017 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -96,3 +96,29 @@ ResetPlatformSpecific (
 {
   gRT->ResetSystem (EfiResetPlatformSpecific, EFI_SUCCESS, DataSize, 
ResetData);
 }
+
+/**
+  The ResetSystem function resets the entire platform.
+
+  @param[in] ResetType  The type of reset to perform.
+  @param[in] ResetStatusThe status code for the reset.
+  @param[in] DataSize   The size, in bytes, of ResetData.
+  @param[in] ResetData  For a ResetType of EfiResetCold, EfiResetWarm, or 
EfiResetShutdown
+the data buffer starts with a Null-terminated 
string, optionally
+followed by additional binary data. The string is 
a description
+that the caller may use to further indicate the 
reason for the
+system reset. ResetData is only valid if 
ResetStatus is something
+other than EFI_SUCCESS unless the ResetType is 
EfiResetPlatformSpecific
+where a minimum amount of ResetData is always 
required.
+**/
+VOID
+EFIAPI
+ResetSystem (
+  IN EFI_RESET_TYPE   ResetType,
+  IN EFI_STATUS   ResetStatus,
+  IN UINTNDataSize,
+  IN VOID *ResetData OPTIONAL
+  )
+{
+  gRT->ResetSystem (ResetType, ResetStatus, DataSize, ResetData);
+}
-- 
2.16.2.windows.1

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

[edk2] [PATCH v3 1/6] MdeModulePkg: change the function name ResetSystem

[Zhichao Gao]

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

Change the function name form ResetSystem to EfiRuntimeResetSystem.
Because ResetSystem and EfiResetSystem would be used in ResetSystemLib
and RuntimeLib.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhichao Gao 
Cc: Ray Ni 
Cc: Liming Gao 
---
 MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c | 8 
 MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.h | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c 
b/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c
index afc35587fc..e16b0cda7b 100644
--- a/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c
+++ b/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c
@@ -1,7 +1,7 @@
 /** @file
   Reset Architectural and Reset Notification protocols implementation.
 
-  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -187,7 +187,7 @@ InitializeResetSystem (
   //
   // Hook the runtime service table
   //
-  gRT->ResetSystem = ResetSystem;
+  gRT->ResetSystem = EfiRuntimeResetSystem;
 
   //
   // Now install the Reset RT AP on a new handle
@@ -242,7 +242,7 @@ DoS3 (
 **/
 VOID
 EFIAPI
-ResetSystem (
+EfiRuntimeResetSystem (
   IN EFI_RESET_TYPE   ResetType,
   IN EFI_STATUS   ResetStatus,
   IN UINTNDataSize,
@@ -256,7 +256,7 @@ ResetSystem (
   RESET_NOTIFY_ENTRY  *Entry;
 
   //
-  // Only do REPORT_STATUS_CODE() on first call to ResetSystem()
+  // Only do REPORT_STATUS_CODE() on first call to EfiRuntimeResetSystem()
   //
   if (mResetNotifyDepth == 0) {
 //
diff --git a/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.h 
b/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.h
index 8529de675c..448e30f079 100644
--- a/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.h
+++ b/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.h
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -97,7 +97,7 @@ InitializeResetSystem (
 **/
 VOID
 EFIAPI
-ResetSystem (
+EfiRuntimeResetSystem (
   IN EFI_RESET_TYPE   ResetType,
   IN EFI_STATUS   ResetStatus,
   IN UINTNDataSize,
-- 
2.16.2.windows.1

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

[edk2] [PATCH v3 3/6] MdeModulePkg: Add a new API ResetSystem for Null version

[Zhichao Gao]

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

Add a new API ResetSystem for BaseResetSystemLibNull to be
in accord with other instances.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhichao Gao 
Cc: Ray Ni 
Cc: Liming Gao 
---
 .../BaseResetSystemLibNull.c   | 27 ++
 1 file changed, 27 insertions(+)

diff --git 
a/MdeModulePkg/Library/BaseResetSystemLibNull/BaseResetSystemLibNull.c 
b/MdeModulePkg/Library/BaseResetSystemLibNull/BaseResetSystemLibNull.c
index 59d720895b..875f839175 100644
--- a/MdeModulePkg/Library/BaseResetSystemLibNull/BaseResetSystemLibNull.c
+++ b/MdeModulePkg/Library/BaseResetSystemLibNull/BaseResetSystemLibNull.c
@@ -98,3 +98,30 @@ ResetPlatformSpecific (
 {
   ResetCold ();
 }
+
+/**
+  The ResetSystem function resets the entire platform.
+
+  @param[in] ResetType  The type of reset to perform.
+  @param[in] ResetStatusThe status code for the reset.
+  @param[in] DataSize   The size, in bytes, of ResetData.
+  @param[in] ResetData  For a ResetType of EfiResetCold, EfiResetWarm, or 
EfiResetShutdown
+the data buffer starts with a Null-terminated 
string, optionally
+followed by additional binary data. The string is 
a description
+that the caller may use to further indicate the 
reason for the
+system reset. ResetData is only valid if 
ResetStatus is something
+other than EFI_SUCCESS unless the ResetType is 
EfiResetPlatformSpecific
+where a minimum amount of ResetData is always 
required.
+**/
+VOID
+EFIAPI
+ResetSystem (
+  IN EFI_RESET_TYPE   ResetType,
+  IN EFI_STATUS   ResetStatus,
+  IN UINTNDataSize,
+  IN VOID *ResetData OPTIONAL
+  )
+{
+  ASSERT (FALSE);
+}
+
-- 
2.16.2.windows.1

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

[edk2] [PATCH v3 6/6] MdeModulePkg: Add the runtime ResetSystemLib in MdeModulePkg.dsc

[Zhichao Gao]

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

Add the runtime library instance of ResetSystemLib in
MdeModulePkg.dsc to make sure it can build pass.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhichao Gao 
Cc: Ray Ni 
Cc: Liming Gao 
---
 MdeModulePkg/MdeModulePkg.dsc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index 3b315fca5a..790a5fa05d 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -286,6 +286,7 @@
   MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf
   MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
   
MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/RuntimeDxeReportStatusCodeLib.inf
+  MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.inf
   MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
   MdeModulePkg/Library/BasePlatformHookLibNull/BasePlatformHookLibNull.inf
   
MdeModulePkg/Library/DxeDebugPrintErrorLevelLib/DxeDebugPrintErrorLevelLib.inf
-- 
2.16.2.windows.1

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

Re: [edk2] [PATCH v5 06/13] MdeModulePkg/NvmExpressPei: Add logic to produce SSC PPI

[Ni, Ray]

How about changing to "NvmeIsHcDevicePathValid"? "Check" in function 
name cannot tell what the return status means.


With the change, Reviewed-by: Ray Ni 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] UefiCpuPkg/Microcode: Fix incorrect checksum issue for extended table

[Ni, Ray]

Reviewed-by: Ray Ni 

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

[edk2] [PATCH v2 0/5] MdeModulePkg, OvmfPkg, ArmVirtPkg: more visible boot progress reporting

[Laszlo Ersek]

Repo:   https://github.com/lersek/edk2.git
Branch: boot_diags_v2

This is version 2 of the series

  [edk2] [PATCH 0/5] MdeModulePkg, OvmfPkg: more easily visible boot progress 
reporting

which was originally posted at

  http://mid.mail-archive.com/20171122235849.4177-1-lersek@redhat.com
  https://lists.01.org/pipermail/edk2-devel/2017-November/017850.html

The most important changes are listed on the v2 patches individually.
(It doesn't make much sense to compare v1 and v2 code-wise, because core
infrastructure has changed significantly since v1.)

The first patch is a bugfix for MdeModulePkg/UefiBootManagerLib; the
rest enables the feature in OvmfPkg, and in ArmVirtPkg/ArmVirtQemu*.

Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Dandan Bi 
Cc: Hao Wu 
Cc: Jian J Wang 
Cc: Jordan Justen 
Cc: Julien Grall 
Cc: Ray Ni 
Cc: Sean Brogan 
Cc: Star Zeng 

Thanks,
Laszlo

Laszlo Ersek (5):
  MdeModulePkg/UefiBootManagerLib: fix LoadImage/StartImage status code
rep.
  OvmfPkg: add library to track boot option loading/starting on the
console
  OvmfPkg/PlatformBootManagerLib: display boot option loading/starting
  ArmVirtPkg/ArmVirtQemu*: enable minimal Status Code Routing in DXE
  ArmVirtPkg/PlatformBootManagerLib: display boot option
loading/starting

 ArmVirtPkg/ArmVirtQemu.dsc   |  11 +
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc |   5 +
 ArmVirtPkg/ArmVirtQemuKernel.dsc |  11 +
 ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c   |   3 +
 ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |   1 +
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c |  69 
+++--
 MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h |   1 +
 OvmfPkg/Include/Library/PlatformBmPrintScLib.h   |  41 +++
 OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf|  66 
+
 OvmfPkg/Library/PlatformBmPrintScLib/StatusCodeHandler.c | 310 

 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c |   3 +
 OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf|   1 +
 OvmfPkg/OvmfPkg.dec  |   5 +
 OvmfPkg/OvmfPkgIa32.dsc  |   1 +
 OvmfPkg/OvmfPkgIa32X64.dsc   |   1 +
 OvmfPkg/OvmfPkgX64.dsc   |   1 +
 16 files changed, 512 insertions(+), 18 deletions(-)
 create mode 100644 OvmfPkg/Include/Library/PlatformBmPrintScLib.h
 create mode 100644 
OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf
 create mode 100644 OvmfPkg/Library/PlatformBmPrintScLib/StatusCodeHandler.c

-- 
2.19.1.3.g30247aa5d201

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

[edk2] [PATCH v2 4/5] ArmVirtPkg/ArmVirtQemu*: enable minimal Status Code Routing in DXE

[Laszlo Ersek]

The EFI_RETURN_STATUS_EXTENDED_DATA feature from PI-1.7
() enables platform code
to learn about boot option failures (loading and launching) via status
codes reported by the UEFI Boot Manager.

In commit 59541d41633c, we removed all status code support from
ArmVirtPkg. Reenable that support now, minimally, just to the extent so we
can benefit from the PI-1.7 feature mentioned above:

(1) Include the ReportStatusCodeRouterRuntimeDxe driver.

This driver produces two protocols, EFI_STATUS_CODE_PROTOCOL and
EFI_RSC_HANDLER_PROTOCOL. The former allows DXE phase modules and
runtime modules to report (produce) status codes. The latter allows
the same types of modules to register callbacks for status code
handling (consumption).

(Handler registration  occurs only at boot time. Status codes are
delivered to each handler at runtime as well, unless the handler is
unregistered at ExitBootServices().)

(2) Resolve ReportStatusCodeLib to a non-Null instance, for DXE_DRIVER
modules only. This way DXE_DRIVER modules that use the
REPORT_STATUS_CODE_EX() macro and friends will reach
EFI_STATUS_CODE_PROTOCOL from point (1).

(3) Set PcdReportStatusCodePropertyMask to 3 (the default value is 0).
This causes the REPORT_STATUS_CODE_EX() macro and friends to let
Progress Codes (bit#0) and Error Codes (bit#1) through to point (1).
Debug Codes (bit#2) are filtered out.

(4) Include no driver, for now, that registers any status code handler via
EFI_RSC_HANDLER_PROTOCOL, from point (1). Status codes that reach
ReportStatusCodeRouterRuntimeDxe will be thrown away.

(5) Modify only the ArmVirtQemu* platforms. A status code handler will
be added to "ArmVirtPkg/Library/PlatformBootManagerLib" in the next patch,
and this library instance is not consumed by ArmVirtXen.

Cc: Ard Biesheuvel 
Cc: Julien Grall 
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- new in v2

 ArmVirtPkg/ArmVirtQemu.dsc   | 10 ++
 ArmVirtPkg/ArmVirtQemuKernel.dsc | 10 ++
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc |  5 +
 3 files changed, 25 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 8cc31fda7a37..ec97d5a14b3a 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -69,6 +69,9 @@ [LibraryClasses.common]
 [LibraryClasses.common.PEIM]
   
ArmVirtMemInfoLib|ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf
 
+[LibraryClasses.common.DXE_DRIVER]
+  
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
+
 [LibraryClasses.common.UEFI_DRIVER]
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
 
@@ -155,6 +158,8 @@ [PcdsFixedAtBuild.common]
   gEfiSecurityPkgTokenSpaceGuid.PcdRemovableMediaImageVerificationPolicy|0x04
 !endif
 
+  gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|3
+
 [PcdsFixedAtBuild.AARCH64]
   # Clearing BIT0 in this PCD prevents installing a 32-bit SMBIOS entry point,
   # if the entry point version is >= 3.0. AARCH64 OSes cannot assume the
@@ -304,6 +309,11 @@ [Components.common]
   ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
 
+  #
+  # Status Code Routing
+  #
+  
MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRouterRuntimeDxe.inf
+
   #
   # Platform Driver
   #
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index c3e0c9bf2549..e8c065229b21 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -66,6 +66,9 @@ [LibraryClasses.common]
   PciSegmentLib|MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibPci.inf
   
PciHostBridgeLib|ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
 
+[LibraryClasses.common.DXE_DRIVER]
+  
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
+
 [LibraryClasses.common.UEFI_DRIVER]
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
 
@@ -149,6 +152,8 @@ [PcdsFixedAtBuild.common]
   gEfiSecurityPkgTokenSpaceGuid.PcdRemovableMediaImageVerificationPolicy|0x04
 !endif
 
+  gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|3
+
 [PcdsPatchableInModule.common]
   #
   # This will be overridden in the code
@@ -288,6 +293,11 @@ [Components.common]
   ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
 
+  #
+  # Status Code Routing
+  #
+  
MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRouterRuntimeDxe.inf
+
   #
   # Platform Driver
   #
diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc 
b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
index dc6a0a2bcdc7..098d40b61b15 100644
--- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
+++ 

[edk2] [PATCH v2 5/5] ArmVirtPkg/PlatformBootManagerLib: display boot option loading/starting

[Laszlo Ersek]

Consume PlatformBmPrintScLib, added earlier in this series. When
BdsDxe+UefiBootManagerLib report LoadImage() / StartImage() preparations
and return statuses, print the reports to the UEFI console. This allows
end-users better visibility into the boot process.

Cc: Ard Biesheuvel 
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- new in v2

 ArmVirtPkg/ArmVirtQemu.dsc   | 1 +
 ArmVirtPkg/ArmVirtQemuKernel.dsc | 1 +
 ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf | 1 +
 ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c   | 3 +++
 4 files changed, 6 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index ec97d5a14b3a..a77d71bcea36 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -58,6 +58,7 @@ [LibraryClasses.common]
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
   BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
   
PlatformBootManagerLib|ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+  
PlatformBmPrintScLib|OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
   
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
   QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index e8c065229b21..1e5388ae708f 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -58,6 +58,7 @@ [LibraryClasses.common]
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
   BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
   
PlatformBootManagerLib|ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+  
PlatformBmPrintScLib|OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
   
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
   QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
diff --git 
a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index 0cbc82f5d27d..9a8a70379e67 100644
--- a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -50,6 +50,7 @@ [LibraryClasses]
   DevicePathLib
   MemoryAllocationLib
   PcdLib
+  PlatformBmPrintScLib
   PrintLib
   QemuBootOrderLib
   QemuFwCfgLib
diff --git a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c 
b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
index 534357eff46b..0e8d7501fb1d 100644
--- a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
+++ b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -833,6 +834,8 @@ PlatformBootManagerAfterConsole (
 
   RemoveStaleFvFileOptions ();
   SetBootOrderFromQemu ();
+
+  PlatformBmPrintScRegisterHandler ();
 }
 
 /**
-- 
2.19.1.3.g30247aa5d201

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

[edk2] [PATCH v2 2/5] OvmfPkg: add library to track boot option loading/starting on the console

[Laszlo Ersek]

Introduce the Platform Boot Manager Print Status Code Library (for short,
PlatformBmPrintScLib) class for catching and printing the LoadImage() /
StartImage() preparations, and return statuses, that are reported by
UefiBootManagerLib.

In the primary library instance, catch only such status codes that
UefiBootManagerLib reports from the same module that contains
PlatformBmPrintScLib. The intent is to establish a reporting-printing
channel within BdsDxe, between UefiBootManagerLib and
PlatformBmPrintScLib. Ignore status codes originating elsewhence, e.g.
from UiApp's copy of UefiBootManagerLib.

Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Julien Grall 
Cc: Ray Ni 
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:

- Split the status code handling to a separate library, so that it's
  easy to reuse in ArmVirtPkg.

- Rework the logic based on
   and
  , and follow Ray's
  advice in
  
:

  - The boot option details are fetched via BootCurrent.

  - For reporting LoadImage() and StartImage() preparations, replace the
originally proposed PcdDebugCodeOsLoaderDetail status code with the
existent (edk2-specific) PcdProgressCodeOsLoaderLoad and
PcdProgressCodeOsLoaderStart status codes.

  - For reporting LoadImage() and StartImage() return values, replace
the originally proposed PcdDebugCodeOsLoaderDetail status code with
the standard EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR and
EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED status codes.

  - For all four kinds of reports, replace the originally proposed "OS
Loader Detail" structure (and GUID) with the recently standardized
EFI_RETURN_STATUS_EXTENDED_DATA structure.

 OvmfPkg/OvmfPkg.dec   |   5 +
 OvmfPkg/OvmfPkgIa32.dsc   |   1 +
 OvmfPkg/OvmfPkgIa32X64.dsc|   1 +
 OvmfPkg/OvmfPkgX64.dsc|   1 +
 OvmfPkg/Include/Library/PlatformBmPrintScLib.h|  41 +++
 OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf |  66 +
 OvmfPkg/Library/PlatformBmPrintScLib/StatusCodeHandler.c  | 310 

 7 files changed, 425 insertions(+)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 7666297cf8f1..e50c6179a249 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -45,6 +45,11 @@ [LibraryClasses]
   #  access.
   PciCapPciSegmentLib|Include/Library/PciCapPciSegmentLib.h
 
+  ##  @libraryclass  Register a status code handler for printing the Boot
+  #  Manager's LoadImage() and StartImage() preparations, and
+  #  return codes, to the UEFI console.
+  PlatformBmPrintScLib|Include/Library/PlatformBmPrintScLib.h
+
   ##  @libraryclass  Access QEMU's firmware configuration interface
   #
   QemuFwCfgLib|Include/Library/QemuFwCfgLib.h
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index f9216af479f4..5b885590b275 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -348,6 +348,7 @@ [LibraryClasses.common.DXE_DRIVER]
   UdpIoLib|MdeModulePkg/Library/DxeUdpIoLib/DxeUdpIoLib.inf
   DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
   
PlatformBootManagerLib|OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+  
PlatformBmPrintScLib|OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf
   QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
 !if $(SMM_REQUIRE) == TRUE
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 1e470de74434..bbf0853ee6b9 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -353,6 +353,7 @@ [LibraryClasses.common.DXE_DRIVER]
   UdpIoLib|MdeModulePkg/Library/DxeUdpIoLib/DxeUdpIoLib.inf
   DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
   
PlatformBootManagerLib|OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+  
PlatformBmPrintScLib|OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf
   QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
 !if $(SMM_REQUIRE) == TRUE
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index e4929d8cf4a8..d81460f52041 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -353,6 +353,7 @@ [LibraryClasses.common.DXE_DRIVER]
   

[edk2] [PATCH v2 3/5] OvmfPkg/PlatformBootManagerLib: display boot option loading/starting

[Laszlo Ersek]

Consume PlatformBmPrintScLib, added earlier in this series. When
BdsDxe+UefiBootManagerLib report LoadImage() / StartImage() preparations
and return statuses, print the reports to the UEFI console. This allows
end-users better visibility into the boot process.

Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Julien Grall 
Cc: Ray Ni 
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:

- Split the OvmfPkg/PlatformBootManagerLib change to a separate patch.

- Drop general messages from PlatformBootManagerAfterConsole(), which
  would report calls of EfiBootManagerRefreshAllBootOption(),
  RemoveStaleFvFileOptions(), and SetBootOrderFromQemu(). Those messages
  weren't really helpful for diagnosing boot problems.

 OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf | 1 +
 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c  | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index 5d9b53bf2d1e..c41aaeef3fc3 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -58,6 +58,7 @@ [LibraryClasses]
   QemuBootOrderLib
   ReportStatusCodeLib
   UefiLib
+  PlatformBmPrintScLib
   Tcg2PhysicalPresenceLib
 
 [Pcd]
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
index b2faa797c61b..12303fb0f1f3 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 
@@ -1542,6 +1543,8 @@ PlatformBootManagerAfterConsole (
 
   RemoveStaleFvFileOptions ();
   SetBootOrderFromQemu ();
+
+  PlatformBmPrintScRegisterHandler ();
 }
 
 /**
-- 
2.19.1.3.g30247aa5d201


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

[edk2] [PATCH v2 1/5] MdeModulePkg/UefiBootManagerLib: fix LoadImage/StartImage status code rep.

[Laszlo Ersek]

In the EFI_RETURN_STATUS_EXTENDED_DATA structure from PI-1.7, there may be
padding between the DataHeader and ReturnStatus members. The
REPORT_STATUS_CODE_EX() macro starts populating the structure immediately
after DataHeader, therefore the source data must provide for the padding.

Extract the BmReportImageFailure() function from EfiBootManagerBoot(),
prepare a zero padding (if any) in a temporary
EFI_RETURN_STATUS_EXTENDED_DATA object, and fix the
REPORT_STATUS_CODE_EX() macro invocation.

Cc: Dandan Bi 
Cc: Hao Wu 
Cc: Jian J Wang 
Cc: Ray Ni 
Cc: Sean Brogan 
Cc: Star Zeng 
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1539
Fixes: c2cf8720a5aad74230767a1f11bade2d86de3745
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- new in v2

 MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h |  1 +
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 69 +++-
 2 files changed, 52 insertions(+), 18 deletions(-)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h 
b/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
index 978fbff966f6..0fef63fceedf 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
+++ b/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
@@ -51,6 +51,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
index 9be1633b7480..ffb98c6c9b83 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
@@ -1667,6 +1667,55 @@ BmIsBootManagerMenuFilePath (
   return FALSE;
 }
 
+/**
+  Report status code with EFI_RETURN_STATUS_EXTENDED_DATA about LoadImage() or
+  StartImage() failure.
+
+  @param[in] ErrorCode  An Error Code in the Software Class, DXE Boot
+Service Driver Subclass. ErrorCode will be used to
+compose the Value parameter for status code
+reporting. Must be one of
+EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR and
+EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED.
+
+  @param[in] FailureStatus  The failure status returned by the boot service
+that should be reported.
+**/
+VOID
+BmReportImageFailure (
+  IN UINT32 ErrorCode,
+  IN EFI_STATUS FailureStatus
+  )
+{
+  EFI_RETURN_STATUS_EXTENDED_DATA ExtendedData;
+  VOID*PaddingStart;
+  UINTN   PaddingSize;
+
+  if (!ReportErrorCodeEnabled ()) {
+return;
+  }
+
+  ASSERT (
+(ErrorCode == EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR) ||
+(ErrorCode == EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED)
+);
+
+  PaddingStart =  + 1;
+  PaddingSize = (UINTN)  - (UINTN) PaddingStart;
+  ZeroMem (PaddingStart, PaddingSize);
+  ExtendedData.ReturnStatus = FailureStatus;
+
+  REPORT_STATUS_CODE_EX (
+(EFI_ERROR_CODE | EFI_ERROR_MINOR),
+(EFI_SOFTWARE_DXE_BS_DRIVER | ErrorCode),
+0,
+NULL,
+NULL,
+PaddingStart,
+PaddingSize + sizeof (ExtendedData.ReturnStatus)
+);
+}
+
 /**
   Attempt to boot the EFI boot option. This routine sets L"BootCurent" and
   also signals the EFI ready to boot event. If the device path for the option
@@ -1822,15 +1871,7 @@ EfiBootManagerBoot (
   //
   // Report Status Code with the failure status to indicate that the 
failure to load boot option
   //
-  REPORT_STATUS_CODE_EX (
-EFI_ERROR_CODE | EFI_ERROR_MINOR,
-(EFI_SOFTWARE_DXE_BS_DRIVER | EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR),
-0,
-NULL,
-NULL,
-,
-sizeof (EFI_STATUS)
-);
+  BmReportImageFailure (EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR, Status);
   BootOption->Status = Status;
   //
   // Destroy the RAM disk
@@ -1911,15 +1952,7 @@ EfiBootManagerBoot (
 //
 // Report Status Code with the failure status to indicate that boot failure
 //
-REPORT_STATUS_CODE_EX (
-  EFI_ERROR_CODE | EFI_ERROR_MINOR,
-  (EFI_SOFTWARE_DXE_BS_DRIVER | EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED),
-  0,
-  NULL,
-  NULL,
-  ,
-  sizeof (EFI_STATUS)
-  );
+BmReportImageFailure (EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED, Status);
   }
   PERF_END_EX (gImageHandle, "BdsAttempt", NULL, 0, (UINT32) OptionNumber);
 
-- 
2.19.1.3.g30247aa5d201


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