Date   
[PATCH 1/1] MdeModulePkg/DxeIplPeim: Initialize pointer PageMapLevel5Entry

Zhang, Shenglei
 

Initialize PageMapLevel5Entry at the beginning of the function.

This commit will fix a GCC 4.8.5 build failure introduced by commit
b3527dedc3951f061c5a73cb4fb2b0f95f47e08b.

OvmfPkg build failure wtih gcc 4.8.5 still exists at latest edk2 version.
The commit 46f8a6891606746ca8b1e684ac379ce271306dc0 seems not to fix
the build failure completely.

Cc: Dandan Bi <dandan.bi@...>
Cc: Liming Gao <liming.gao@...>
Cc: Hao A Wu <hao.a.wu@...>
Signed-off-by: Shenglei Zhang <shenglei.zhang@...>
---
MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
index 2389f3eb485b..aae80536ac3d 100644
--- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
+++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
@@ -652,6 +652,8 @@ CreateIdentityMappingPageTables (
UINT64 AddressEncMask;
IA32_CR4 Cr4;

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

[PATCH v3 0/2] Add edk2 submodule policy

Wang, Jian J
 

v3 change
[1/2] a. change wording about submodule per Liming's comment.
b. add more steps to do submodule update per Mike's comment.
c. add commands for update of submodule
[2/2] no changes.
https://bugzilla.tianocore.org/show_bug.cgi?id=1910

Cc: Leif Lindholm <leif.lindholm@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <liming.gao@...>

Jian J Wang (2):
Readme.md: add submodule policy and clone commands
CryptoPkg/OpensslLib: remove clone commands

.../Library/OpensslLib/OpenSSL-HOWTO.txt | 18 +--------
Readme.md | 39 +++++++++++++++++++
2 files changed, 41 insertions(+), 16 deletions(-)

--
2.17.1.windows.2

[PATCH v3 1/2] Readme.md: add submodule policy and clone commands

Wang, Jian J
 

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

A section 'Submodules' is added to clarify the submodule policy
in edk2 repo. Git commands are also added to show the correct
way to clone submodule repos, in which '--recursive' is removed
because it's not needed but recommended in other document.

Related commits:
Openssl-1.1.1b upgrade: acfb90911840c38a0beb9bcfe0065668244d2b4d
berkeley-softfloat-3: 3cc57695df5a6e8c65fb46b993836c315cabf49d

Cc: Leif Lindholm <leif.lindholm@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <liming.gao@...>
Signed-off-by: Jian J Wang <jian.j.wang@...>
Reviewed-by: Leif Lindholm <leif.lindholm@...>
---
Readme.md | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)

diff --git a/Readme.md b/Readme.md
index 7c873759a5..27e4ce0771 100644
--- a/Readme.md
+++ b/Readme.md
@@ -140,3 +140,42 @@ Signed-off-by: Contributor Name <contributor@...>
the change. Each line should be less than ~70 characters.
* `Signed-off-by` is the contributor's signature identifying them
by their real/legal name and their email address.
+
+# Submodules
+
+Submodule in EDK II is allowed but submodule chain should be avoided
+as possible as we can. Currently EDK II contains two submodules
+
+- CryptoPkg/Library/OpensslLib/openssl
+- ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3
+
+The latter one is actually required by previous one. It's inevitable
+in openssl-1.1.1 (since stable201905) for floating point parameter
+conversion, but should be dropped once there's no such need in future
+release of openssl.
+
+To get a full, buildable EDK II repository, use following steps of git
+command
+
+```
+$ git clone https://github.com/tianocore/edk2.git
+$ cd edk2
+$ git submodule update --init
+$ cd ..
+```
+
+If there's update for submodules, use following git commands to get the
+latest submodules code.
+
+```
+$ cd edk2
+$ git pull
+$ git submodule update
+```
+
+Note: When cloning submodule repos, '--recursive' option is not
+recommended. EDK II itself will not use any code/feature from
+submodules in above submodules. So using '--recursive' adds a
+dependency on being able to reach servers we do not actually want
+any code from, as well as needlessly downloading code we will not
+use.
--
2.17.1.windows.2

[PATCH v3 2/2] CryptoPkg/OpensslLib: remove clone commands

Wang, Jian J
 

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

edk2/Readme.md has added a section to explain the correct clone
commands for submodules. Detailed steps in the OpenSSL-HOWTO.txt
are removed to avoid any inconsistency.

Cc: Leif Lindholm <leif.lindholm@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <liming.gao@...>
Signed-off-by: Jian J Wang <jian.j.wang@...>
Reviewed-by: Leif Lindholm <leif.lindholm@...>
---
CryptoPkg/Library/OpensslLib/OpenSSL-HOWTO.txt | 18 ++----------------
1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/CryptoPkg/Library/OpensslLib/OpenSSL-HOWTO.txt b/CryptoPkg/Library/OpensslLib/OpenSSL-HOWTO.txt
index db45eb88d1..e52ee27b49 100644
--- a/CryptoPkg/Library/OpensslLib/OpenSSL-HOWTO.txt
+++ b/CryptoPkg/Library/OpensslLib/OpenSSL-HOWTO.txt
@@ -24,22 +24,8 @@ on the cryptography.
=============================================================================
HOW to Install OpenSSL for UEFI Building
=============================================================================
- OpenSSL repository was added as one submodule of EDKII project.
-
- The user can use the following commands to clone both main EDKII repo and
-openssl submodule:
- 1) Add the "--recursive" flag to the git clone command:
- $ git clone --recursive https://github.com/tianocore/edk2
-or
- 2) Manually initialize and update the submodules after the clone operation
- on main project:
- $ git clone https://github.com/tianocore/edk2
- $ git submodule update --init --recursive
-
- And use the following combined commands to pull the remote submodule updates
-(e.g. Updating the new supported OpenSSL release tag):
- $ git pull --recurse-submodules && \
- git submodule update --recursive
+ OpenSSL repository was added as one submodule of EDKII project. Please
+refer to edk2/Readme.md for how to clone the code.

=============================================================================
About process_files.pl
--
2.17.1.windows.2

Re: [PATCH v3 0/2] Add edk2 submodule policy

Wang, Jian J
 

Sorry for the late update for this patch series. Please find v2 review at
https://edk2.groups.io/g/devel/topic/32413655#43457

Regards,
Jian

-----Original Message-----
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
Wang, Jian J
Sent: Wednesday, August 14, 2019 4:15 PM
To: devel@edk2.groups.io
Cc: Leif Lindholm <leif.lindholm@...>; Kinney, Michael D
<michael.d.kinney@...>; Gao, Liming <liming.gao@...>
Subject: [edk2-devel] [PATCH v3 0/2] Add edk2 submodule policy

v3 change
[1/2] a. change wording about submodule per Liming's comment.
b. add more steps to do submodule update per Mike's comment.
c. add commands for update of submodule
[2/2] no changes.
https://bugzilla.tianocore.org/show_bug.cgi?id=1910

Cc: Leif Lindholm <leif.lindholm@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <liming.gao@...>

Jian J Wang (2):
Readme.md: add submodule policy and clone commands
CryptoPkg/OpensslLib: remove clone commands

.../Library/OpensslLib/OpenSSL-HOWTO.txt | 18 +--------
Readme.md | 39 +++++++++++++++++++
2 files changed, 41 insertions(+), 16 deletions(-)

--
2.17.1.windows.2


Re: [PATCH V2] ShellPkg/UefiShellDriver1CommandsLib: Make array big enough

Gao, Zhichao
 

Ping again.

Thanks,
Zhichao

-----Original Message-----
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
Gao, Zhichao
Sent: Friday, July 26, 2019 3:47 PM
To: devel@edk2.groups.io
Cc: Carsey, Jaben <jaben.carsey@...>; Ni, Ray <ray.ni@...>;
oleksiyy@...
Subject: FW: [edk2-devel] [PATCH V2]
ShellPkg/UefiShellDriver1CommandsLib: Make array big enough

Ping. Please help to review it.

Thanks,
Zhichao

-----Original Message-----
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
Gao, Zhichao
Sent: Monday, July 22, 2019 2:58 PM
To: devel@edk2.groups.io
Cc: Carsey, Jaben <jaben.carsey@...>; Ni, Ray <ray.ni@...>;
Oleksiy <oleksiyy@...>
Subject: [edk2-devel] [PATCH V2] ShellPkg/UefiShellDriver1CommandsLib:
Make array big enough

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

The two CHAR16 array ChildCountStr and DeviceCountStr is defined to hold
the decimal string data of UINTN. The max of UINTN is
18446744073709551615 and it contain 20 characters.
So make their size to 21 CHAR16s to hold the string data with a null-
terminate.
UnicodeValueToStringS regard the value input as INT64, and
21 CHARs is enough to hold the lowest value with minus '-'.
Although the value shouldn't be such big.

Cc: Jaben Carsey <jaben.carsey@...>
Cc: Ray Ni <ray.ni@...>
Cc: Oleksiy <oleksiyy@...>
Signed-off-by: Zhichao Gao <zhichao.gao@...>
---

V2:
Update the copyright.

ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
b/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
index 794b737bd1..27cd278cf0 100644
--- a/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
+++ b/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
@@ -2,7 +2,7 @@
Main file for Drivers shell Driver1 function.

(C) Copyright 2012-2015 Hewlett-Packard Development Company, L.P.<BR>
- Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2010 - 2019, Intel Corporation. All rights
+ reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent

**/
@@ -263,8 +263,8 @@ ShellCommandRunDrivers (
EFI_HANDLE *HandleWalker;
UINTN ChildCount;
UINTN DeviceCount;
- CHAR16 ChildCountStr[3];
- CHAR16 DeviceCountStr[3];
+ CHAR16 ChildCountStr[21];
+ CHAR16 DeviceCountStr[21];
CHAR16 *Temp2;
CONST CHAR16 *FullDriverName;
CHAR16 *TruncatedDriverName;
--
2.21.0.windows.1





[PATCH] SecurityPkg/SecurityPkg.uni: Add missing strings for new PCDs

Wang, Jian J
 

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

Cc: Jiewen Yao <jiewen.yao@...>
Cc: Chao Zhang <chao.b.zhang@...>
Cc: Shenglei Zhang <shenglei.zhang@...>
Signed-off-by: Jian J Wang <jian.j.wang@...>
---
SecurityPkg/SecurityPkg.uni | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)

diff --git a/SecurityPkg/SecurityPkg.uni b/SecurityPkg/SecurityPkg.uni
index 9c0c008f9c..14077fbc28 100644
--- a/SecurityPkg/SecurityPkg.uni
+++ b/SecurityPkg/SecurityPkg.uni
@@ -263,3 +263,26 @@
"0x01 - Do not support IdleByPass.<BR>\n"
"0x02 - Support IdleByPass.<BR>\n"
"0xFF - IdleByPass State is not synced with TPM hardware.<BR>"
+
+#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdStatusCodeFvVerificationPass_PROMPT #language en-US "Status Code for FV verification pass."
+
+#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdStatusCodeFvVerificationPass_HELP #language en-US "Progress Code for FV verification result.\n"
+ " (EFI_SOFTWARE_PEI_MODULE | EFI_SUBCLASS_SPECIFIC | 00A).\n"
+
+#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdStatusCodeFvVerificationFail_PROMPT #language en-US "Status Code for FV verification failure."
+
+#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdStatusCodeFvVerificationFail_HELP #language en-US "Progress Code for FV verification result.\n"
+ " (EFI_SOFTWARE_PEI_MODULE | EFI_SUBCLASS_SPECIFIC | 00B).\n"
+
+#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdSkipOpalPasswordPrompt_PROMPT #language en-US "Skip Opal DXE driver password prompt."
+
+#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdSkipOpalPasswordPrompt_HELP #language en-US "Indicates if Opal DXE driver skip password prompt.\n\n"
+ " TRUE - Skip password prompt.\n"
+ " FALSE - Does not skip password prompt.\n"
+
+#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdSkipHddPasswordPrompt_PROMPT #language en-US "Skip Hdd Password prompt."
+
+#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdSkipHddPasswordPrompt_HELP #language en-US "Indicates if Hdd Password driver skip password prompt.\n\n"
+ " TRUE - Skip password prompt.\n"
+ " FALSE - Does not skip password prompt.\n"
+
--
2.17.1.windows.2

Re: [PATCH] MdePkg: Add MmAccess and MmControl definition.

Marc W Chen
 

Thanks Liming for pushing the code.

Can we have a conclusion for the SmmAccess.h removal from MdeModulePkg? Who can make the decision? Or do we need any further discussion?

Thanks,
Marc

-----Original Message-----
From: Gao, Liming
Sent: Tuesday, August 13, 2019 5:20 PM
To: devel@edk2.groups.io; Gao, Liming <liming.gao@...>; Chen, Marc
W <marc.w.chen@...>; lersek@...; Ni, Ray
<ray.ni@...>
Cc: Kinney, Michael D <michael.d.kinney@...>
Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
definition.

Push @6f33f7a262314af35e2b99c849e08928ea49aa55

-----Original Message-----
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
Liming Gao
Sent: Saturday, August 10, 2019 11:34 AM
To: Chen, Marc W <marc.w.chen@...>; devel@edk2.groups.io;
lersek@...; Ni, Ray <ray.ni@...>
Cc: Kinney, Michael D <michael.d.kinney@...>
Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
definition.

I agree. The patch to add them in MdePkg is clear. I will push it next Monday.

Thanks
Liming
-----Original Message-----
From: Chen, Marc W
Sent: Saturday, August 10, 2019 11:33 AM
To: devel@edk2.groups.io; lersek@...; Ni, Ray
<ray.ni@...>;
Gao, Liming <liming.gao@...>
Cc: Kinney, Michael D <michael.d.kinney@...>
Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
MmControl
definition.

Hi Liming

Since the SmmAccess.h of MdeModulePkg removal is still under discussion,
can we push the MmAccess.h and MmControl.h to MdePkg
first? I have other tasks pending by this.
We can keep discussing the SmmAccess after push the code.

Thanks,
Marc

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
Laszlo
Ersek
Sent: Thursday, August 8, 2019 12:11 AM
To: Ni, Ray <ray.ni@...>; Chen, Marc W
<marc.w.chen@...>;
devel@edk2.groups.io; Gao, Liming <liming.gao@...>
Cc: Kinney, Michael D <michael.d.kinney@...>
Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
MmControl
definition.

On 08/06/19 12:08, Ni, Ray wrote:
Laszlo,
Do you want to avoid touching the OvmfPkg due the file removal in
MdeModulePkg?

My main problem with this *specific* update proposal is that the
identifiers (type names and such) that would be subject to removal were
publicly specified in earlier PI spec releases.

I don't suggest that we maintain two parallel sets of typedefs and such
in edk2. It's fine to keep the new "MM" nomenclature the main one. But
we should keep the "SMM" set of terms too, as a thin wrapper, if that's
technically feasible.

If we remove "SMM", that will not only affect OvmfPkg unpleasantly, but
a bunch of other, out-of-tree code. And the reason I suddenly care
about
out-of-tree code is that such code was written against a public industry
spec (= earlier versions of the PI spec).

I don't think that the simplicity that would come from removing "SMM"
altogether, is well-balanced against the pain that it would cause for
platforms.

Earlier this was solved in the following commits:
- 07c6a47e70ba ("MdePkg: Add new definitions for Management
Mode.",
2017-08-29)
- 2f208e59e4b9 ("MdePkg: Reference new definitions for Management
Mode.", 2017-08-29)

Thanks
Laszlo

I prefer to remove the files in MdeModulePkg to avoid future
confusion.

Thanks,
Ray

-----Original Message-----
From: Chen, Marc W
Sent: Tuesday, August 6, 2019 4:57 PM
To: devel@edk2.groups.io; lersek@...; Ni, Ray
<ray.ni@...>;
Gao, Liming <liming.gao@...>
Cc: Kinney, Michael D <michael.d.kinney@...>
Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
MmControl
definition.

Hi Liming and Ray

Do you also agree?

Thanks,
Marc

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
Laszlo
Ersek
Sent: Friday, August 2, 2019 10:14 AM
To: devel@edk2.groups.io; Chen, Marc W
<marc.w.chen@...>;
Ni,
Ray <ray.ni@...>; Gao, Liming <liming.gao@...>
Cc: Kinney, Michael D <michael.d.kinney@...>
Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
MmControl
definition.

On 08/01/19 12:15, Marc W Chen wrote:
Yes, my purpose is to avoid platform code update if the package is
allowed
to use MdeModulePkg like OvmfPkg.
For those packages that cannot depend on MdeModulePkg must
change
to
use new definition.

Agreed.

Thanks!
Laszlo

-----Original Message-----
From: Ni, Ray
Sent: Thursday, August 1, 2019 6:04 PM
To: Chen, Marc W <marc.w.chen@...>; Gao, Liming
<liming.gao@...>; devel@edk2.groups.io
Cc: Kinney, Michael D <michael.d.kinney@...>
Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
MmControl
definition.

Marc,
Is the purpose to avoid platform code update with the wrapper
header
file in
MdeModulePkg?
Certain platforms they may require to not depend on
MdeModulePkg
but just depend on MdePkg.
Having SmmAccess.h in MdeModulePkg doesn't help.

It also bring confusing.

Thanks,
Ray

-----Original Message-----
From: Chen, Marc W
Sent: Thursday, August 1, 2019 4:53 PM
To: Gao, Liming <liming.gao@...>; devel@edk2.groups.io
Cc: Kinney, Michael D <michael.d.kinney@...>; Ni, Ray
<ray.ni@...>
Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
MmControl
definition.

Hi Liming

Another thought, do you think it is ok to keep SmmAccess.h in
MdeModulePkg? We can use #define and typedef to convert
MmAccess
to
SmmAccess, just like current SmmAccess Protocol in MdePkg.

Thanks,
Marc

-----Original Message-----
From: Chen, Marc W
Sent: Thursday, August 1, 2019 4:48 PM
To: Gao, Liming <liming.gao@...>;
devel@edk2.groups.io
Cc: Kinney, Michael D <michael.d.kinney@...>; Ni, Ray
<ray.ni@...>
Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
MmControl
definition.

Hi Liming

Since there are multiple packages are still using SmmAccess.h,
we
need to change all packages to use MmAccess.h instead of
SmmAccess.h first, then clean up SmmAccess.h from
MdeModulePkg
will be the last step.
Below are the packages that has "include <Ppi/SmmAccess.h>"
for
your reference.
* Edk2 repo:
o MdeModulePkg
o OvmfPkg
o UefiCpuPkg
* Edk2Platform repo:
o MinPlatformPkg
o QuarkSocPkg

Thanks,
Marc

-----Original Message-----
From: Gao, Liming
Sent: Thursday, August 1, 2019 4:42 PM
To: devel@edk2.groups.io; Chen, Marc W
<marc.w.chen@...>
Cc: Kinney, Michael D <michael.d.kinney@...>; Ni, Ray
<ray.ni@...>
Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess
and
MmControl
definition.

Marc:
The change is good. Reviewed-by: Liming Gao
<liming.gao@...>

Besides, I see BZ also mention to remove the one in
MdeModulePkg.
Have you the following patches for the change in
MdeModulePkg?

Thanks
Liming
-----Original Message-----
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io]
On
Behalf
Of Marc W Chen
Sent: Monday, July 29, 2019 12:26 PM
To: devel@edk2.groups.io
Cc: Kinney, Michael D <michael.d.kinney@...>; Gao,
Liming
<liming.gao@...>; Ni, Ray <ray.ni@...>
Subject: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
MmControl
definition.

EFI MmAccess and MmControl PPIs are defined in the PI 1.5
specification.

Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <liming.gao@...>
Cc: Ray Ni <ray.ni@...>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2023
Signed-off-by: Marc W Chen <marc.w.chen@...>
---
MdePkg/Include/Ppi/MmAccess.h | 155
+++++++++++++++++++++++++++++++++++++++++
MdePkg/Include/Ppi/MmControl.h | 90
++++++++++++++++++++++++
MdePkg/MdePkg.dec | 6 ++
3 files changed, 251 insertions(+) create mode 100644
MdePkg/Include/Ppi/MmAccess.h create mode 100644
MdePkg/Include/Ppi/MmControl.h

diff --git a/MdePkg/Include/Ppi/MmAccess.h
b/MdePkg/Include/Ppi/MmAccess.h new file mode 100644
index
0000000000..636e7288a0
--- /dev/null
+++ b/MdePkg/Include/Ppi/MmAccess.h
@@ -0,0 +1,155 @@
+/** @file
+ EFI MM Access PPI definition.
+
+ This PPI is used to control the visibility of the MMRAM on
+ the
platform.
+ The EFI_PEI_MM_ACCESS_PPI abstracts the location and
+ characteristics
of
MMRAM. The
+ principal functionality found in the memory controller
+ includes the
following:
+ - Exposing the MMRAM to all non-MM agents, or the
"open"
+ state
+ - Shrouding the MMRAM to all but the MM agents, or the
"closed"
+ state
+ - Preserving the system integrity, or "locking" the MMRAM,
+ such that
the
settings cannot be
+ perturbed by either boot service or runtime agents
+
+ Copyright (c) 2019, Intel Corporation. All rights
+ reserved.<BR>
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+ @par Revision Reference:
+ This PPI is introduced in PI Version 1.5.
+
+**/
+
+#ifndef _MM_ACCESS_PPI_H_
+#define _MM_ACCESS_PPI_H_
+
+#define EFI_PEI_MM_ACCESS_PPI_GUID \
+ { 0x268f33a9, 0xcccd, 0x48be, { 0x88, 0x17, 0x86, 0x5, 0x3a,
+0xc3, 0x2e,
0xd6 }}
+
+typedef struct _EFI_PEI_MM_ACCESS_PPI
EFI_PEI_MM_ACCESS_PPI;
+
+/**
+ Opens the MMRAM area to be accessible by a PEIM.
+
+ This function "opens" MMRAM so that it is visible while
not
+ inside of
MM.
The function should
+ return EFI_UNSUPPORTED if the hardware does not
support
+ hiding of
MMRAM. The function
+ should return EFI_DEVICE_ERROR if the MMRAM
configuration
is
locked.
+
+ @param PeiServices An indirect pointer to the PEI
Services
Table
published by the PEI Foundation.
+ @param This The EFI_PEI_MM_ACCESS_PPI
instance.
+ @param DescriptorIndex The region of MMRAM to
Open.
+
+ @retval EFI_SUCCESS The operation was successful.
+ @retval EFI_UNSUPPORTED The system does not
support
opening
and
closing of MMRAM.
+ @retval EFI_DEVICE_ERROR MMRAM cannot be
opened,
perhaps
because it is locked.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_PEI_MM_OPEN)(
+ IN EFI_PEI_SERVICES **PeiServices,
+ IN EFI_PEI_MM_ACCESS_PPI *This,
+ IN UINTN DescriptorIndex
+ );
+
+/**
+ Inhibits access to the MMRAM.
+
+ This function "closes" MMRAM so that it is not visible
while
+ outside of
MM.
The function should
+ return EFI_UNSUPPORTED if the hardware does not
support
+ hiding of
MMRAM.
+
+ @param PeiServices An indirect pointer to the PEI
Services
Table
published by the PEI Foundation.
+ @param This The EFI_PEI_MM_ACCESS_PPI
instance.
+ @param DescriptorIndex The region of MMRAM to
Close.
+
+ @retval EFI_SUCCESS The operation was successful.
+ @retval EFI_UNSUPPORTED The system does not
support
opening
and
closing of MMRAM.
+ @retval EFI_DEVICE_ERROR MMRAM cannot be closed.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_PEI_MM_CLOSE)(
+ IN EFI_PEI_SERVICES **PeiServices,
+ IN EFI_PEI_MM_ACCESS_PPI *This,
+ IN UINTN DescriptorIndex
+ );
+
+/**
+ This function prohibits access to the MMRAM region. This
+function is
usually
implemented such
+ that it is a write-once operation.
+
+ @param PeiServices An indirect pointer to the PEI
Services
Table
published by the PEI Foundation.
+ @param This The EFI_PEI_MM_ACCESS_PPI
instance.
+ @param DescriptorIndex The region of MMRAM to
Lock.
+
+ @retval EFI_SUCCESS The operation was successful.
+ @retval EFI_UNSUPPORTED The system does not
support
opening
and
closing of MMRAM.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_PEI_MM_LOCK)(
+ IN EFI_PEI_SERVICES **PeiServices,
+ IN EFI_PEI_MM_ACCESS_PPI *This,
+ IN UINTN DescriptorIndex
+ );
+
+/**
+ Queries the memory controller for the possible regions
that
+will support
MMRAM.
+
+ This function describes the MMRAM regions.
+ This data structure forms the contract between the
MM_ACCESS
and
MM_IPL drivers. There is an
+ ambiguity when any MMRAM region is remapped. For
example,
on
some
chipsets, some MMRAM
+ regions can be initialized at one physical address but is
+ later accessed at
another processor address.
+ There is currently no way for the MM IPL driver to know
that
+ it must use
two different addresses
+ depending on what it is trying to do. As a result, initial
+ configuration and
loading can use the
+ physical address PhysicalStart while MMRAM is open.
However,
+ once
the
region has been
+ closed and needs to be accessed by agents in MM, the
+ CpuStart address
must be used.
+ This PPI publishes the available memory that the chipset
can
+ shroud for
the
use of installing code.
+ These regions serve the dual purpose of describing which
+ regions have
been open, closed, or locked.
+ In addition, these regions may include overlapping
memory
+ ranges,
depending on the chipset
+ implementation. The latter might include a chipset that
+ supports T-SEG,
where memory near the top
+ of the physical DRAM can be allocated for MMRAM too.
+ The key thing to note is that the regions that are described
+ by the PPI
are
a
subset of the capabilities
+ of the hardware.
+
+ @param PeiServices An indirect pointer to the PEI
Services
Table
published by the PEI Foundation.
+ @param This The EFI_PEI_MM_ACCESS_PPI
instance.
+ @param MmramMapSize A pointer to the size, in
bytes,
of
the
MmramMemoryMap buffer. On input, this value is
+ the size of the buffer that
+ is allocated by the caller. On
output, it is the size of the
+ buffer that was returned by
+ the firmware if the buffer
was
large enough, or, if the
+ buffer was too small, the
+ size of the buffer that is
needed to
contain the map.
+ @param MmramMap A pointer to the buffer in
which
firmware
places the current memory map. The map is
+ an array of
+ EFI_MMRAM_DESCRIPTORs
+
+ @retval EFI_SUCCESS The chipset supported the
given
resource.
+ @retval EFI_BUFFER_TOO_SMALL The MmramMap
parameter
was
too
small. The current
+ buffer size needed to hold
+ the memory map is
returned
in
+ MmramMapSize.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_PEI_MM_CAPABILITIES)(
+ IN EFI_PEI_SERVICES **PeiServices,
+ IN EFI_PEI_MM_ACCESS_PPI *This,
+ IN OUT UINTN *MmramMapSize,
+ IN OUT EFI_MMRAM_DESCRIPTOR *MmramMap
+ );
+
+///
+/// EFI MM Access PPI is used to control the visibility of
+the MMRAM on
the
platform.
+/// It abstracts the location and characteristics of MMRAM.
+The platform
should report
+/// all MMRAM via EFI_PEI_MM_ACCESS_PPI. The
expectation
is
that
+the
north bridge or
+/// memory controller would publish this PPI.
+///
+struct _EFI_PEI_MM_ACCESS_PPI {
+ EFI_PEI_MM_OPEN Open;
+ EFI_PEI_MM_CLOSE Close;
+ EFI_PEI_MM_LOCK Lock;
+ EFI_PEI_MM_CAPABILITIES GetCapabilities;
+ BOOLEAN LockState;
+ BOOLEAN OpenState;
+};
+
+extern EFI_GUID gEfiPeiMmAccessPpiGuid;
+
+#endif
diff --git a/MdePkg/Include/Ppi/MmControl.h
b/MdePkg/Include/Ppi/MmControl.h new file mode 100644
index
0000000000..983ed95cd5
--- /dev/null
+++ b/MdePkg/Include/Ppi/MmControl.h
@@ -0,0 +1,90 @@
+/** @file
+ EFI MM Control PPI definition.
+
+ This PPI is used initiate synchronous MMI activations. This
+ PPI could be
published by a processor
+ driver to abstract the MMI IPI or a driver which abstracts
+ the ASIC that
is
supporting the APM port.
+ Because of the possibility of performing MMI IPI
+ transactions, the ability
to
generate this event
+ from a platform chipset agent is an optional capability for
+ both
+ IA-32
and
x64-based systems.
+
+ Copyright (c) 2019, Intel Corporation. All rights
+ reserved.<BR>
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+ @par Revision Reference:
+ This PPI is introduced in PI Version 1.5.
+
+**/
+
+
+#ifndef _MM_CONTROL_PPI_H_
+#define _MM_CONTROL_PPI_H_
+
+#define EFI_PEI_MM_CONTROL_PPI_GUID \
+ { 0x61c68702, 0x4d7e, 0x4f43, 0x8d, 0xef, 0xa7, 0x43, 0x5,
+0xce, 0x74,
0xc5 }
+
+typedef struct _EFI_PEI_MM_CONTROL_PPI
EFI_PEI_MM_CONTROL_PPI;
+
+/**
+ Invokes PPI activation from the PI PEI environment.
+
+ @param PeiServices An indirect pointer to the PEI
Services
Table
published by the PEI Foundation.
+ @param This The PEI_MM_CONTROL_PPI
instance.
+ @param ArgumentBuffer The value passed to the
MMI
handler.
This
value corresponds to the
+ SwMmiInputValue in the
+ RegisterContext parameter
for
the
Register()
+ function in the
+ EFI_MM_SW_DISPATCH_PROTOCOL
and
in
the Context parameter
+ in the call to the DispatchFunction
+ @param ArgumentBufferSize The size of the data
passed
in
ArgumentBuffer or NULL if ArgumentBuffer is NULL.
+ @param Periodic An optional mechanism to
periodically
repeat
activation.
+ @param ActivationInterval An optional parameter to
repeat
at
this
period
one
+ time or, if the Periodic Boolean is set,
periodically.
+
+ @retval EFI_SUCCESS The MMI has been engendered.
+ @retval EFI_DEVICE_ERROR The timing is unsupported.
+ @retval EFI_INVALID_PARAMETER The activation period is
unsupported.
+ @retval EFI_NOT_STARTED The MM base service has
not
been
initialized.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_PEI_MM_ACTIVATE) (
+ IN EFI_PEI_SERVICES **PeiServices,
+ IN EFI_PEI_MM_CONTROL_PPI * This,
+ IN OUT INT8 *ArgumentBuffer
OPTIONAL,
+ IN OUT UINTN *ArgumentBufferSize
OPTIONAL,
+ IN BOOLEAN Periodic OPTIONAL,
+ IN UINTN ActivationInterval
OPTIONAL
+ );
+
+/**
+ Clears any system state that was created in response to
the
Trigger()
call.
+
+ @param PeiServices General purpose services
available
to
every
PEIM.
+ @param This The PEI_MM_CONTROL_PPI
instance.
+ @param Periodic Optional parameter to repeat at
this
period
one
+ time or, if the Periodic Boolean is set,
periodically.
+
+ @retval EFI_SUCCESS The MMI has been engendered.
+ @retval EFI_DEVICE_ERROR The source could not be
cleared.
+ @retval EFI_INVALID_PARAMETER The service did not
support
+ the
Periodic
input argument.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *PEI_MM_DEACTIVATE) (
+ IN EFI_PEI_SERVICES **PeiServices,
+ IN EFI_PEI_MM_CONTROL_PPI * This,
+ IN BOOLEAN Periodic OPTIONAL
+ );
+
+///
+/// The EFI_PEI_MM_CONTROL_PPI is produced by a PEIM.
It
provides
an
abstraction of the
+/// platform hardware that generates an MMI. There are
often
+I/O ports
that, when accessed, will
+/// generate the MMI. Also, the hardware optionally
supports
+the
periodic
generation of these signals.
+///
+struct _PEI_MM_CONTROL_PPI {
+ PEI_MM_ACTIVATE Trigger;
+ PEI_MM_DEACTIVATE Clear;
+};
+
+extern EFI_GUID gEfiPeiMmControlPpiGuid;
+
+#endif
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index
b382efd578..34e0f39395 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -925,6 +925,12 @@
## Include/Ppi/SecHobData.h
gEfiSecHobDataPpiGuid = { 0x3ebdaf20, 0x6667, 0x40d8,
{0xb4,
0xee,
0xf5,
0x99, 0x9a, 0xc1, 0xb7, 0x1f } }

+ ## Include/Ppi/MmAccess.h
+ gEfiPeiMmAccessPpiGuid = { 0x268f33a9, 0xcccd,
0x48be,
{ 0x88,
0x17,
0x86, 0x5, 0x3a, 0xc3, 0x2e, 0xd6 }}
+
+ ## Include/Ppi/MmControl.h
+ gEfiPeiMmControlPpiGuid = { 0x61c68702, 0x4d7e,
0x4f43,
{ 0x8d,
0xef,
0xa7, 0x43, 0x5, 0xce, 0x74, 0xc5 }}
+
#
# PPIs defined in PI 1.7.
#
--
2.16.2.windows.1







Re: [Patch v1] ShellPkg: update drivers command for more children

Augustine, Linson <linson.augustine@...>
 

Reviewed-by: Linson Augustine <Linson.augustine@...>

Regards,
-Linson

-----Original Message-----
From: Carsey, Jaben
Sent: Tuesday, August 13, 2019 8:12 PM
To: devel@edk2.groups.io
Cc: Ni, Ray <ray.ni@...>; Augustine, Linson <linson.augustine@...>; Gao, Zhichao <zhichao.gao@...>
Subject: [Patch v1] ShellPkg: update drivers command for more children

this allows for > 99 children

Cc: ray ni <ray.ni@...>
Cc: linson augustine <linson.augustine@...>
Cc: zhichao gao <zhichao.gao@...>
Signed-off-by: Jaben Carsey <jaben.carsey@...>
---
ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c b/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
index 794b737bd1..7d45f2fc40 100644
--- a/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
+++ b/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
@@ -2,7 +2,7 @@
Main file for Drivers shell Driver1 function.

(C) Copyright 2012-2015 Hewlett-Packard Development Company, L.P.<BR>
- Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent

**/
@@ -263,8 +263,8 @@ ShellCommandRunDrivers (
EFI_HANDLE *HandleWalker;
UINTN ChildCount;
UINTN DeviceCount;
- CHAR16 ChildCountStr[3];
- CHAR16 DeviceCountStr[3];
+ CHAR16 ChildCountStr[7];
+ CHAR16 DeviceCountStr[7];
CHAR16 *Temp2;
CONST CHAR16 *FullDriverName;
CHAR16 *TruncatedDriverName;
--
2.16.2.windows.1

Re: [PATCH V2] ShellPkg/UefiShellDriver1CommandsLib: Make array big enough

Augustine, Linson <linson.augustine@...>
 

Reviewed-by: Linson Augustine <Linson.augustine@...>

Regards,
-Linson

-----Original Message-----
From: Gao, Zhichao
Sent: Wednesday, August 14, 2019 2:03 PM
To: devel@edk2.groups.io; Gao, Zhichao <zhichao.gao@...>
Cc: Carsey, Jaben <jaben.carsey@...>; Ni, Ray <ray.ni@...>; oleksiyy@...; Augustine, Linson <linson.augustine@...>
Subject: RE: [edk2-devel] [PATCH V2] ShellPkg/UefiShellDriver1CommandsLib: Make array big enough

Ping again.

Thanks,
Zhichao

-----Original Message-----
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
Gao, Zhichao
Sent: Friday, July 26, 2019 3:47 PM
To: devel@edk2.groups.io
Cc: Carsey, Jaben <jaben.carsey@...>; Ni, Ray
<ray.ni@...>; oleksiyy@...
Subject: FW: [edk2-devel] [PATCH V2]
ShellPkg/UefiShellDriver1CommandsLib: Make array big enough

Ping. Please help to review it.

Thanks,
Zhichao

-----Original Message-----
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
Gao, Zhichao
Sent: Monday, July 22, 2019 2:58 PM
To: devel@edk2.groups.io
Cc: Carsey, Jaben <jaben.carsey@...>; Ni, Ray
<ray.ni@...>; Oleksiy <oleksiyy@...>
Subject: [edk2-devel] [PATCH V2] ShellPkg/UefiShellDriver1CommandsLib:
Make array big enough

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

The two CHAR16 array ChildCountStr and DeviceCountStr is defined to
hold the decimal string data of UINTN. The max of UINTN is
18446744073709551615 and it contain 20 characters.
So make their size to 21 CHAR16s to hold the string data with a null-
terminate.
UnicodeValueToStringS regard the value input as INT64, and
21 CHARs is enough to hold the lowest value with minus '-'.
Although the value shouldn't be such big.

Cc: Jaben Carsey <jaben.carsey@...>
Cc: Ray Ni <ray.ni@...>
Cc: Oleksiy <oleksiyy@...>
Signed-off-by: Zhichao Gao <zhichao.gao@...>
---

V2:
Update the copyright.

ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
b/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
index 794b737bd1..27cd278cf0 100644
--- a/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
+++ b/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
@@ -2,7 +2,7 @@
Main file for Drivers shell Driver1 function.

(C) Copyright 2012-2015 Hewlett-Packard Development Company,
L.P.<BR>
- Copyright (c) 2010 - 2018, Intel Corporation. All rights
reserved.<BR>
+ Copyright (c) 2010 - 2019, Intel Corporation. All rights
+ reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent

**/
@@ -263,8 +263,8 @@ ShellCommandRunDrivers (
EFI_HANDLE *HandleWalker;
UINTN ChildCount;
UINTN DeviceCount;
- CHAR16 ChildCountStr[3];
- CHAR16 DeviceCountStr[3];
+ CHAR16 ChildCountStr[21];
+ CHAR16 DeviceCountStr[21];
CHAR16 *Temp2;
CONST CHAR16 *FullDriverName;
CHAR16 *TruncatedDriverName;
--
2.21.0.windows.1





[PATCH v2] BaseTools/Scripts: Add GetUtcDateTime script.

Chiu, Chasel
 

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

A script that can return UTC date and time in ascii
format which is convenient for patching build time
information in any binary.

Cc: Bob Feng <bob.c.feng@...>
Cc: Liming Gao <liming.gao@...>
Cc: Leif Lindholm <leif.lindholm@...>
Signed-off-by: Chasel Chiu <chasel.chiu@...>
---
BaseTools/Scripts/GetUtcDateTime.py | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)

diff --git a/BaseTools/Scripts/GetUtcDateTime.py b/BaseTools/Scripts/GetUtcDateTime.py
new file mode 100644
index 0000000000..3cfb6ac2ae
--- /dev/null
+++ b/BaseTools/Scripts/GetUtcDateTime.py
@@ -0,0 +1,44 @@
+## @file
+# Get current UTC date and time information and output as ascii code.
+#
+# Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+
+VersionNumber = '0.1'
+import sys
+import datetime
+import argparse
+
+def Main():
+ PARSER = argparse.ArgumentParser(
+ description='Retrieves UTC date and time information (output ordering: year, date, time) - Version ' + VersionNumber)
+ PARSER.add_argument('--year',
+ action='store_true',
+ help='Return UTC year of now. [Example output (2019): 39313032]')
+ PARSER.add_argument('--date',
+ action='store_true',
+ help='Return UTC date MMDD of now. [Example output (7th August): 37303830]')
+ PARSER.add_argument('--time',
+ action='store_true',
+ help='Return 24-hour-format UTC time HHMM of now. [Example output (14:25): 35323431]')
+
+ ARGS = PARSER.parse_args()
+ if len(sys.argv) == 1:
+ print ("ERROR: At least one argument is required!\n")
+ PARSER.print_help()
+
+ today = datetime.datetime.utcnow()
+ if ARGS.year:
+ ReversedNumber = str(today.year)[::-1]
+ print (''.join(hex(ord(HexString))[2:] for HexString in ReversedNumber))
+ if ARGS.date:
+ ReversedNumber = str(today.strftime("%m%d"))[::-1]
+ print (''.join(hex(ord(HexString))[2:] for HexString in ReversedNumber))
+ if ARGS.time:
+ ReversedNumber = str(today.strftime("%H%M"))[::-1]
+ print (''.join(hex(ord(HexString))[2:] for HexString in ReversedNumber))
+
+if __name__ == '__main__':
+ Main()
--
2.13.3.windows.1

Re: [PATCH v2] BaseTools/Scripts: Add GetUtcDateTime script.

Chiu, Chasel
 

V2 re-wrote the script to use ArgumentParser and remove sys.exit().

Regards,
Chasel

-----Original Message-----
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
Chiu, Chasel
Sent: Wednesday, August 14, 2019 6:21 PM
To: devel@edk2.groups.io
Cc: Feng, Bob C <bob.c.feng@...>; Gao, Liming <liming.gao@...>;
Leif Lindholm <leif.lindholm@...>
Subject: [edk2-devel] [PATCH v2] BaseTools/Scripts: Add GetUtcDateTime
script.

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

A script that can return UTC date and time in ascii format which is convenient
for patching build time information in any binary.

Cc: Bob Feng <bob.c.feng@...>
Cc: Liming Gao <liming.gao@...>
Cc: Leif Lindholm <leif.lindholm@...>
Signed-off-by: Chasel Chiu <chasel.chiu@...>
---
BaseTools/Scripts/GetUtcDateTime.py | 44
++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)

diff --git a/BaseTools/Scripts/GetUtcDateTime.py
b/BaseTools/Scripts/GetUtcDateTime.py
new file mode 100644
index 0000000000..3cfb6ac2ae
--- /dev/null
+++ b/BaseTools/Scripts/GetUtcDateTime.py
@@ -0,0 +1,44 @@
+## @file
+# Get current UTC date and time information and output as ascii code.
+#
+# Copyright (c) 2019, Intel Corporation. All rights reserved.<BR> # #
+SPDX-License-Identifier: BSD-2-Clause-Patent #
+
+VersionNumber = '0.1'
+import sys
+import datetime
+import argparse
+
+def Main():
+ PARSER = argparse.ArgumentParser(
+ description='Retrieves UTC date and time information (output ordering:
year, date, time) - Version ' + VersionNumber)
+ PARSER.add_argument('--year',
+ action='store_true',
+ help='Return UTC year of now. [Example output (2019):
39313032]')
+ PARSER.add_argument('--date',
+ action='store_true',
+ help='Return UTC date MMDD of now. [Example output
(7th August): 37303830]')
+ PARSER.add_argument('--time',
+ action='store_true',
+ help='Return 24-hour-format UTC time HHMM of
+now. [Example output (14:25): 35323431]')
+
+ ARGS = PARSER.parse_args()
+ if len(sys.argv) == 1:
+ print ("ERROR: At least one argument is required!\n")
+ PARSER.print_help()
+
+ today = datetime.datetime.utcnow()
+ if ARGS.year:
+ ReversedNumber = str(today.year)[::-1]
+ print (''.join(hex(ord(HexString))[2:] for HexString in ReversedNumber))
+ if ARGS.date:
+ ReversedNumber = str(today.strftime("%m%d"))[::-1]
+ print (''.join(hex(ord(HexString))[2:] for HexString in ReversedNumber))
+ if ARGS.time:
+ ReversedNumber = str(today.strftime("%H%M"))[::-1]
+ print (''.join(hex(ord(HexString))[2:] for HexString in
+ ReversedNumber))
+
+if __name__ == '__main__':
+ Main()
--
2.13.3.windows.1


Re: [PATCH v2] BaseTools/Scripts: Add GetUtcDateTime script.

Leif Lindholm
 

On Wed, Aug 14, 2019 at 06:21:06PM +0800, Chasel Chiu wrote:
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2067

A script that can return UTC date and time in ascii
format which is convenient for patching build time
information in any binary.

Cc: Bob Feng <bob.c.feng@...>
Cc: Liming Gao <liming.gao@...>
Cc: Leif Lindholm <leif.lindholm@...>
Signed-off-by: Chasel Chiu <chasel.chiu@...>
Yeah, this looks a lot better, thanks.
Acked-by: Leif Lindholm <leif.lindholm@...>

---
BaseTools/Scripts/GetUtcDateTime.py | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)

diff --git a/BaseTools/Scripts/GetUtcDateTime.py b/BaseTools/Scripts/GetUtcDateTime.py
new file mode 100644
index 0000000000..3cfb6ac2ae
--- /dev/null
+++ b/BaseTools/Scripts/GetUtcDateTime.py
@@ -0,0 +1,44 @@
+## @file
+# Get current UTC date and time information and output as ascii code.
+#
+# Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+
+VersionNumber = '0.1'
+import sys
+import datetime
+import argparse
+
+def Main():
+ PARSER = argparse.ArgumentParser(
+ description='Retrieves UTC date and time information (output ordering: year, date, time) - Version ' + VersionNumber)
+ PARSER.add_argument('--year',
+ action='store_true',
+ help='Return UTC year of now. [Example output (2019): 39313032]')
+ PARSER.add_argument('--date',
+ action='store_true',
+ help='Return UTC date MMDD of now. [Example output (7th August): 37303830]')
+ PARSER.add_argument('--time',
+ action='store_true',
+ help='Return 24-hour-format UTC time HHMM of now. [Example output (14:25): 35323431]')
+
+ ARGS = PARSER.parse_args()
+ if len(sys.argv) == 1:
+ print ("ERROR: At least one argument is required!\n")
+ PARSER.print_help()
+
+ today = datetime.datetime.utcnow()
+ if ARGS.year:
+ ReversedNumber = str(today.year)[::-1]
+ print (''.join(hex(ord(HexString))[2:] for HexString in ReversedNumber))
+ if ARGS.date:
+ ReversedNumber = str(today.strftime("%m%d"))[::-1]
+ print (''.join(hex(ord(HexString))[2:] for HexString in ReversedNumber))
+ if ARGS.time:
+ ReversedNumber = str(today.strftime("%H%M"))[::-1]
+ print (''.join(hex(ord(HexString))[2:] for HexString in ReversedNumber))
+
+if __name__ == '__main__':
+ Main()
--
2.13.3.windows.1

Re: [PATCH v2] BaseTools/Scripts: Add GetUtcDateTime script.

rebecca@...
 

On 2019-08-14 04:21, Chiu, Chasel wrote:
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2067

A script that can return UTC date and time in ascii
format which is convenient for patching build time
information in any binary.

I know it's not a required tool to be run before committing, but could
you consider the following issues pylama reported, please?

BaseTools/Scripts/GetUtcDateTime.py:1:1: E266 too many leading '#' for
block comment [pycodestyle]
BaseTools/Scripts/GetUtcDateTime.py:10:1: E402 module level import not
at top of file [pycodestyle]
BaseTools/Scripts/GetUtcDateTime.py:11:1: E402 module level import not
at top of file [pycodestyle]
BaseTools/Scripts/GetUtcDateTime.py:12:1: E402 module level import not
at top of file [pycodestyle]
BaseTools/Scripts/GetUtcDateTime.py:14:1: E302 expected 2 blank lines,
found 1 [pycodestyle]
BaseTools/Scripts/GetUtcDateTime.py:29:14: E211 whitespace before '('
[pycodestyle]
BaseTools/Scripts/GetUtcDateTime.py:35:14: E211 whitespace before '('
[pycodestyle]
BaseTools/Scripts/GetUtcDateTime.py:38:14: E211 whitespace before '('
[pycodestyle]
BaseTools/Scripts/GetUtcDateTime.py:41:14: E211 whitespace before '('
[pycodestyle]
BaseTools/Scripts/GetUtcDateTime.py:43:1: E305 expected 2 blank lines
after class or function definition, found 1 [pycodestyle]

--
Rebecca Cran

Re: CPU hotplug using SMM with QEMU+OVMF

Yao, Jiewen
 

My comments below.

-----Original Message-----
From: Laszlo Ersek [mailto:lersek@...]
Sent: Wednesday, August 14, 2019 12:09 AM
To: edk2-devel-groups-io <devel@edk2.groups.io>
Cc: edk2-rfc-groups-io <rfc@edk2.groups.io>; qemu devel list
<qemu-devel@...>; Igor Mammedov <imammedo@...>;
Paolo Bonzini <pbonzini@...>; Yao, Jiewen
<jiewen.yao@...>; Chen, Yingwen <yingwen.chen@...>;
Nakajima, Jun <jun.nakajima@...>; Boris Ostrovsky
<boris.ostrovsky@...>; Joao Marcal Lemos Martins
<joao.m.martins@...>; Phillip Goerl <phillip.goerl@...>
Subject: Re: CPU hotplug using SMM with QEMU+OVMF

On 08/13/19 16:16, Laszlo Ersek wrote:

Yingwen and Jiewen suggested the following process.

Legend:

- "New CPU": CPU being hot-added
- "Host CPU": existing CPU
- (Flash): code running from flash
- (SMM): code running from SMRAM

Steps:

(01) New CPU: (Flash) enter reset vector, Global SMI disabled by
default.
- What does "Global SMI disabled by default" mean? In particular, what
is "global" here?
[Jiewen] OK. Let's don’t use the term "global".


Do you mean that the CPU being hot-plugged should mask (by default)
broadcast SMIs? What about directed SMIs? (An attacker could try that
too.)
[Jiewen] I mean all SMIs are blocked for this specific hot-added CPU.


And what about other processors? (I'd assume step (01)) is not
relevant for other processors, but "global" is quite confusing here.)
[Jiewen] No impact to other processors.


- Does this part require a new branch somewhere in the OVMF SEC code?
How do we determine whether the CPU executing SEC is BSP or
hot-plugged AP?
[Jiewen] I think this is blocked from hardware perspective, since the first instruction.
There are some hardware specific registers can be used to determine if the CPU is new added.
I don’t think this must be same as the real hardware.
You are free to invent some registers in device model to be used in OVMF hot plug driver.


- How do we tell the hot-plugged AP where to start execution? (I.e. that
it should execute code at a particular pflash location.)
[Jiewen] Same real mode reset vector at FFFF:FFF0.


For example, in MpInitLib, we start a specific AP with INIT-SIPI-SIPI,
where "SIPI" stores the startup address in the "Interrupt Command
Register" (which is memory-mapped in xAPIC mode, and an MSR in x2APIC
mode, apparently). That doesn't apply here -- should QEMU auto-start
the new CPU?
[Jiewen] You can send INIT-SIPI-SIPI to new CPU only after it can access memory.
SIPI need give AP an below 1M memory address as waking vector.


- What memory is used as stack by the new CPU, when it runs code from
flash?
[Jiewen] Same as other CPU in normal boot. You can use special reserved memory.


QEMU does not emulate CAR (Cache As RAM). The new CPU doesn't have
access to SMRAM. And we cannot use AcpiNVS or Reserved memory,
because
a malicious OS could use other CPUs -- or PCI device DMA -- to attack
the stack (unless QEMU forcibly paused other CPUs upon hotplug; I'm
not sure).
[Jiewen] Excellent point!
I don’t think there is problem for real hardware, who always has CAR.
Can QEMU provide some CPU specific space, such as MMIO region?


- If an attempt is made to hotplug multiple CPUs in quick succession,
does something serialize those attempts?
[Jiewen] The BIOS need consider this as availability requirement.
I don’t have strong opinion.
You can design a system that required hotplug must be one-by-one, or fail the hot-add.
Or you can design a system that did not have such restriction.
Again, all we need to do is to maintain the integrity of SMM.
The availability should be considered as separate requirement.


Again, stack usage could be a concern, even with Cache-As-RAM --
HyperThreads (logical processors) on a single core don't have
dedicated cache.
[Jiewen] Agree with you on the virtual environment.
For real hardware, we do socket level hot-add only. So HT is not the concern.
But if you want to do that in virtual environment, a processor specific memory
should be considered.


Does CPU hotplug apply only at the socket level? If the CPU is
multi-core, what is responsible for hot-plugging all cores present in
the socket?
[Jiewen] Ditto.


(02) New CPU: (Flash) configure memory control to let it access global
host memory.
In QEMU/KVM guests, we don't have to enable memory explicitly, it just
exists and works.

In OVMF X64 SEC, we can't access RAM above 4GB, but that shouldn't be an
issue per se.
[Jiewen] Agree. I do not see the issue.


(03) New CPU: (Flash) send board message to tell host CPU (GPIO->SCI)
-- I am waiting for hot-add message.
Maybe we can simplify this in QEMU by broadcasting an SMI to existent
processors immediately upon plugging the new CPU.


(NOTE: Host CPU can only
send
instruction in SMM mode. -- The register is SMM only)
Sorry, I don't follow -- what register are we talking about here, and
why is the BSP needed to send anything at all? What "instruction" do you
have in mind?
[Jiewen] The new CPU does not enable SMI at reset.
At some point of time later, the CPU need enable SMI, right?
The "instruction" here means, the host CPUs need tell to CPU to enable SMI.


(04) Host CPU: (OS) get message from board that a new CPU is added.
(GPIO -> SCI)

(05) Host CPU: (OS) All CPUs enter SMM (SCI->SWSMI) (NOTE: New CPU
will not enter CPU because SMI is disabled)
I don't understand the OS involvement here. But, again, perhaps QEMU can
force all existent CPUs into SMM immediately upon adding the new CPU.
[Jiewen] OS here means the Host CPU running code in OS environment, not in SMM environment.


(06) Host CPU: (SMM) Save 38000, Update 38000 -- fill simple SMM
rebase code.

(07) Host CPU: (SMM) Send message to New CPU to Enable SMI.
Aha, so this is the SMM-only register you mention in step (03). Is the
register specified in the Intel SDM?
[Jiewen] Right. That is the register to let host CPU tell new CPU to enable SMI.
It is platform specific register. Not defined in SDM.
You may invent one in device model.


(08) New CPU: (Flash) Get message - Enable SMI.

(09) Host CPU: (SMM) Send SMI to the new CPU only.

(10) New CPU: (SMM) Response first SMI at 38000, and rebase SMBASE to
TSEG.
What code does the new CPU execute after it completes step (10)? Does it
halt?
[Jiewen] The new CPU exits SMM and return to original place - where it is
interrupted to enter SMM - running code on the flash.


(11) Host CPU: (SMM) Restore 38000.
These steps (i.e., (06) through (11)) don't appear RAS-specific. The
only platform-specific feature seems to be SMI masking register, which
could be extracted into a new SmmCpuFeaturesLib API.

Thus, would you please consider open sourcing firmware code for steps
(06) through (11)?

Alternatively -- and in particular because the stack for step (01)
concerns me --, we could approach this from a high-level, functional
perspective. The states that really matter are the relocated SMBASE for
the new CPU, and the state of the full system, right at the end of step
(11).

When the SMM setup quiesces during normal firmware boot, OVMF could
use
existent (finalized) SMBASE infomation to *pre-program* some virtual
QEMU hardware, with such state that would be expected, as "final" state,
of any new hotplugged CPU. Afterwards, if / when the hotplug actually
happens, QEMU could blanket-apply this state to the new CPU, and
broadcast a hardware SMI to all CPUs except the new one.

The hardware SMI should tell the firmware that the rest of the process
-- step (12) below, and onward -- is being requested.

If I understand right, this approach would produce an firmware & system
state that's identical to what's expected right after step (11):

- all SMBASEs relocated
- all preexistent CPUs in SMM
- new CPU halted / blocked from launch
- DRAM at 0x30000 / 0x38000 contains OS-owned data

Is my understanding correct that this is the expected state after step
(11)?
[Jiewen] I think you are correct.


Three more comments on the "SMBASE pre-config" approach:

- the virtual hardware providing this feature should become locked after
the configuration, until next platform reset

- the pre-config should occur via simple hardware accesses, so that it
can be replayed at S3 resume, i.e. as part of the S3 boot script

- from the pre-configured state, and the APIC ID, QEMU itself could
perhaps calculate the SMI stack location for the new processor.


(12) Host CPU: (SMM) Update located data structure to add the new CPU
information. (This step will involve CPU_SERVICE protocol)
I commented on EFI_SMM_CPU_SERVICE_PROTOCOL in upon bullet (4) of
<https://bugzilla.tianocore.org/show_bug.cgi?id=1512#c4>.

Calling EFI_SMM_ADD_PROCESSOR looks justified.
[Jiewen] I think you are correct.
Also REMOVE_PROCESSOR will be used for hot-remove action.


What are some of the other member functions used for? The scary one is
EFI_SMM_REGISTER_EXCEPTION_HANDLER.
[Jiewen] This is to register a new exception handler in SMM.
I don’t think this API is involved in hot-add.


===================== (now, the next SMI will bring all CPU into TSEG)
OK... but what component injects that SMI, and when?
[Jiewen] Any SMI event. It could be synchronized SMI or asynchronized SMI.
It could from software such as IO write, or hardware such as thermal event.


(13) New CPU: (Flash) run MRC code, to init its own memory.
Why is this needed esp. after step (10)? The new CPU has accessed DRAM
already. And why are we executing code from pflash, rather than from
SMRAM, given that we're past SMBASE relocation?
[Jiewen] On real hardware, it is needed because different CPU may have different capability to access different DIMM.
I do not think your virtual platform need it.


(14) New CPU: (Flash) Deadloop, and wait for INIT-SIPI-SIPI.

(15) Host CPU: (OS) Send INIT-SIPI-SIPI to pull new CPU in.
I'm confused by these steps. I thought that step (12) would complete the
hotplug, by updating the administrative data structures internally. And
the next SMI -- raised for the usual purposes, such as a software SMI
for variable access -- would be handled like it always is, except it
would also pull the new CPU into SMM too.
[Jiewen] The OS need use the new CPU at some point of time, right?
As such, the OS need pull the new CPU into its own environment by INIT-SIPI-SIPI.


Thanks!
Laszlo

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

Liming Gao
 

Can you add the sample usage of new macro STATIC_ASSERT?

Or, give the link of static_assert or _Static_assert.

If so, the developer knows how to use them in source code.

Thanks
Liming

-----Original Message-----
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of vit9696 via Groups.Io
Sent: Tuesday, August 13, 2019 4:17 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

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

Provide a macro for compile time assertions.
Equivalent to C11 static_assert macro from assert.h.

Signed-off-by: Vitaly Cheptsov <vit9696@...>
---
MdePkg/Include/Base.h | 11 +++++++++++
1 file changed, 11 insertions(+)

diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
index ce20b5f01dce..f85f7028a262 100644
--- a/MdePkg/Include/Base.h
+++ b/MdePkg/Include/Base.h
@@ -843,6 +843,17 @@ typedef UINTN *BASE_LIST;
#define OFFSET_OF(TYPE, Field) ((UINTN) &(((TYPE *)0)->Field))
#endif

+///
+/// Portable definition for compile time assertions.
+/// Equivalent to C11 static_assert macro from assert.h.
+/// Takes condtion and error message as its arguments.
+///
+#ifdef _MSC_EXTENSIONS
+ #define STATIC_ASSERT static_assert
+#else
+ #define STATIC_ASSERT _Static_assert
+#endif
+
/**
Macro that returns a pointer to the data structure that contains a specified field of
that data structure. This is a lightweight method to hide information by placing a
--
2.20.1 (Apple Git-117)


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

View/Reply Online (#45503): https://edk2.groups.io/g/devel/message/45503
Mute This Topic: https://groups.io/mt/32850582/1759384
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [liming.gao@...]
-=-=-=-=-=-=

Re: [Patch] MdeModulePkg DxeCore: Fix for missing MAT update

Liming Gao
 

Laszlo:

-----Original Message-----
From: Laszlo Ersek [mailto:lersek@...]
Sent: Tuesday, August 13, 2019 5:48 PM
To: Kinney, Michael D <michael.d.kinney@...>; devel@edk2.groups.io; Gao, Liming <liming.gao@...>
Cc: Mike Turner <miketur@...>; Wang, Jian J <jian.j.wang@...>; Wu, Hao A <hao.a.wu@...>; Bi, Dandan
<dandan.bi@...>
Subject: Re: [edk2-devel] [Patch] MdeModulePkg DxeCore: Fix for missing MAT update

On 08/13/19 01:22, Kinney, Michael D wrote:


-----Original Message-----
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io]
On Behalf Of Laszlo Ersek
Sent: Monday, August 12, 2019 9:24 AM
To: devel@edk2.groups.io; Gao, Liming
<liming.gao@...>
Cc: Mike Turner <miketur@...>; Wang, Jian J
<jian.j.wang@...>; Wu, Hao A <hao.a.wu@...>;
Bi, Dandan <dandan.bi@...>
Subject: Re: [edk2-devel] [Patch] MdeModulePkg DxeCore:
Fix for missing MAT update

On 08/10/19 16:10, Liming Gao wrote:
From: Mike Turner <miketur@...>

The Fpdt driver (FirmwarePerformanceDxe) saves a memory
address across
reboots, and then does an AllocatePage for that memory
address.
If, on this boot, that memory comes from a Runtime
memory bucket, the
MAT table is not updated. This causes Windows to boot
into Recovery.

(1) What is "MAT"?
Memory Attributes Table (EFI_MEMORY_ATTRIBUTES_TABLE)


This patch blocks the memory manager from changing the
page from a
special bucket to a different memory type. Once the
buckets are
allocated, we freeze the memory ranges for the OS, and
fragmenting the
special buckets will cause errors resuming from
hibernate.

(2) My understanding is that CoreConvertPages() will only
hand out the requested pages if those pages are currently
free. I suggest clarifying the commit message that the
intent is to prevent the allocation of otherwise *free*
pages, if the allocation would fragment special buckets.

(3) I don't understand the conjunction "and". I would
understand if the statement were:

Once the buckets are allocated, we freeze the memory
ranges for the
OS, *because* fragmenting the special buckets *would*
cause errors
resuming from hibernate.

Is this the intent?


This patch is cherry pick from Project Mu:
https://github.com/microsoft/mu_basecore/commit/a9be767d9
be96af94016eb
d391ea6f340920735a
With the minor change,
1. Update commit message format to keep the message in
80 characters one line.
2. Remove // MU_CHANGE comments in source code.

Cc: Jian J Wang <jian.j.wang@...>
Cc: Hao A Wu <hao.a.wu@...>
Cc: Dandan Bi <dandan.bi@...>
Signed-off-by: Liming Gao <liming.gao@...>
---
MdeModulePkg/Core/Dxe/Mem/Page.c | 43
++++++++++++++++++++++++++++++++++------
1 file changed, 37 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c
b/MdeModulePkg/Core/Dxe/Mem/Page.c
index bd9e116aa5..637518889d 100644
--- a/MdeModulePkg/Core/Dxe/Mem/Page.c
+++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
@@ -1265,12 +1265,13 @@ CoreInternalAllocatePages (
IN BOOLEAN NeedGuard
)
{
- EFI_STATUS Status;
- UINT64 Start;
- UINT64 NumberOfBytes;
- UINT64 End;
- UINT64 MaxAddress;
- UINTN Alignment;
+ EFI_STATUS Status;
+ UINT64 Start;
+ UINT64 NumberOfBytes;
+ UINT64 End;
+ UINT64 MaxAddress;
+ UINTN Alignment;
+ EFI_MEMORY_TYPE CheckType;

if ((UINT32)Type >= MaxAllocateType) {
return EFI_INVALID_PARAMETER;
@@ -1321,6 +1322,7 @@ CoreInternalAllocatePages (
// if (Start + NumberOfBytes) rolls over 0 or
// if Start is above MAX_ALLOC_ADDRESS or
// if End is above MAX_ALLOC_ADDRESS,
+ // if Start..End overlaps any tracked
MemoryTypeStatistics range
// return EFI_NOT_FOUND.
//
if (Type == AllocateAddress) {
@@ -1336,6 +1338,35 @@ CoreInternalAllocatePages (
(End > MaxAddress)) {
return EFI_NOT_FOUND;
}
+
+ // Problem summary
+
+ /*
+ A driver is allowed to call AllocatePages using an
AllocateAddress type. This type of
+ AllocatePage request the exact physical address if
it is not used. The existing code
+ will allow this request even in 'special' pages.
The problem with this is that the
+ reason to have 'special' pages for OS
hibernate/resume is defeated as memory is
+ fragmented.
+ */
(4) This comment style is not native to edk2.

I think the "problem summary" line should be removed, and
the actual problem statement should use the following
comment style:

//
// blah
//
I cherry pick this patch from Mu project with the minimal change.
I can update the comment style.



+
+ for (CheckType = (EFI_MEMORY_TYPE) 0; CheckType <
EfiMaxMemoryType; CheckType++) {
+ if (MemoryType != CheckType &&
+ mMemoryTypeStatistics[CheckType].Special &&
+
mMemoryTypeStatistics[CheckType].NumberOfPages > 0) {
+ if (Start >=
mMemoryTypeStatistics[CheckType].BaseAddress &&
+ Start <=
mMemoryTypeStatistics[CheckType].MaximumAddress) {
+ return EFI_NOT_FOUND;
+ }
+ if (End >=
mMemoryTypeStatistics[CheckType].BaseAddress &&
+ End <=
mMemoryTypeStatistics[CheckType].MaximumAddress) {
+ return EFI_NOT_FOUND;
+ }
+ if (Start <
mMemoryTypeStatistics[CheckType].BaseAddress &&
+ End >
mMemoryTypeStatistics[CheckType].MaximumAddress) {
+ return EFI_NOT_FOUND;
+ }
+ }
+ }
}
(5) Checking for overlap (i.e., whether the intersection
is non-empty) can be done more simply (i.e., with fewer
comparisons in the worst case, and with less code):

if (MAX (Start,
mMemoryTypeStatistics[CheckType].BaseAddress) <=
MIN (End,
mMemoryTypeStatistics[CheckType].MaximumAddress)) {
return EFI_NOT_FOUND;
}

but the proposed intersection check is technically right
already, IMO, so there's no strong need to update it.

(Somewhat unusually for this kind of comparison, all four
boundaries are inclusive here.)

(6) Both the commit message and the code comment state
that this problem is specific to S4. Therefore, we can
distinguish three cases:

(6a) Platform doesn't support (or doesn't enable) S4 at
all.

(6b) Platform supports & enables S4, and this is a normal
boot.

(6c) Platform supports & enables S4, and this is actually
an S4 resume.

The code being proposed applies to all three cases. Is
that the intent?
Shouldn't the new check be made conditional on (6c) --
from the boot mode HOB --, or at least on (6b)||(6c) --
i.e. the check should be disabled if S4 is absent
entirely?
Hi Laszlo,

I think this check should be added for all cases. Without
this change, memory allocations using type AllocateAddress
Is allowed to allocate in the unused portion of a bin. This
means the memory allocations are not consist with the memory
map returned by GetMemoryMap() that shows the entire bin as
allocated. The only exception that is allowed is if an
AllocateAddress request is made to the unused portion of a
bin where the request and the bin have the same MemoryType.
Thanks for the explanation. It helps! I understand now.

The references to S4 here are the use case that fails. This
failure is root caused to an inconsistent behavior of the
core memory services themselves when type AllocateAddress is
used.
Can the commit message be framed accordingly, please?

The main issue is apparently with the UEFI memory map -- the UEFI memory
map reflects the pre-allocated bins, but the actual allocations at fixed
addresses may go out of sync with that. Everything else, such as:

- EFI_MEMORY_ATTRIBUTES_TABLE (page protections) being out of sync,

- S4 failing

are just symptoms / consequences.

The only time these types of check can be disabled is if the
Memory Type Information feature is disabled.
The gEfiMemoryTypeInformationGuid HOB is supposed to be built -- if it
is built at all -- no later than in the DXE IPL PEIM (if VariablePei is
included in the platform, and the underlying UEFI variable exists). Is
that correct?
gEfiMemoryTypeInformationGuid HOB is installed by platform PEI.
If the platform PEI doesn't install this HOB, it means this feature is disabled.

Thanks
Liming
Becase if it is correct, then I think the check could be based (in the
DXE core) on the presence of this HOB.

Thank you!
Laszlo

Re: CPU hotplug using SMM with QEMU+OVMF

Paolo Bonzini <pbonzini@...>
 

On 14/08/19 15:20, Yao, Jiewen wrote:
- Does this part require a new branch somewhere in the OVMF SEC code?
How do we determine whether the CPU executing SEC is BSP or
hot-plugged AP?
[Jiewen] I think this is blocked from hardware perspective, since the first instruction.
There are some hardware specific registers can be used to determine if the CPU is new added.
I don’t think this must be same as the real hardware.
You are free to invent some registers in device model to be used in OVMF hot plug driver.
Yes, this would be a new operation mode for QEMU, that only applies to
hot-plugged CPUs. In this mode the AP doesn't reply to INIT or SMI, in
fact it doesn't reply to anything at all.

- How do we tell the hot-plugged AP where to start execution? (I.e. that
it should execute code at a particular pflash location.)
[Jiewen] Same real mode reset vector at FFFF:FFF0.
You do not need a reset vector or INIT/SIPI/SIPI sequence at all in
QEMU. The AP does not start execution at all when it is unplugged, so
no cache-as-RAM etc.

We only need to modify QEMU so that hot-plugged APIs do not reply to
INIT/SIPI/SMI.

I don’t think there is problem for real hardware, who always has CAR.
Can QEMU provide some CPU specific space, such as MMIO region?
Why is a CPU-specific region needed if every other processor is in SMM
and thus trusted.

Does CPU hotplug apply only at the socket level? If the CPU is
multi-core, what is responsible for hot-plugging all cores present in
the socket?
I can answer this: the SMM handler would interact with the hotplug
controller in the same way that ACPI DSDT does normally. This supports
multiple hotplugs already.

Writes to the hotplug controller from outside SMM would be ignored.

(03) New CPU: (Flash) send board message to tell host CPU (GPIO->SCI)
-- I am waiting for hot-add message.
Maybe we can simplify this in QEMU by broadcasting an SMI to existent
processors immediately upon plugging the new CPU.
The QEMU DSDT could be modified (when secure boot is in effect) to OUT
to 0xB2 when hotplug happens. It could write a well-known value to
0xB2, to be read by an SMI handler in edk2.



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

(04) Host CPU: (OS) get message from board that a new CPU is added.
(GPIO -> SCI)

(05) Host CPU: (OS) All CPUs enter SMM (SCI->SWSMI) (NOTE: New CPU
will not enter CPU because SMI is disabled)
I don't understand the OS involvement here. But, again, perhaps QEMU can
force all existent CPUs into SMM immediately upon adding the new CPU.
[Jiewen] OS here means the Host CPU running code in OS environment, not in SMM environment.
See above.

(06) Host CPU: (SMM) Save 38000, Update 38000 -- fill simple SMM
rebase code.

(07) Host CPU: (SMM) Send message to New CPU to Enable SMI.
Aha, so this is the SMM-only register you mention in step (03). Is the
register specified in the Intel SDM?
[Jiewen] Right. That is the register to let host CPU tell new CPU to enable SMI.
It is platform specific register. Not defined in SDM.
You may invent one in device model.
See above.

(10) New CPU: (SMM) Response first SMI at 38000, and rebase SMBASE to
TSEG.
What code does the new CPU execute after it completes step (10)? Does it
halt?
[Jiewen] The new CPU exits SMM and return to original place - where it is
interrupted to enter SMM - running code on the flash.
So in our case we'd need an INIT/SIPI/SIPI sequence between (06) and (07).

(11) Host CPU: (SMM) Restore 38000.
These steps (i.e., (06) through (11)) don't appear RAS-specific. The
only platform-specific feature seems to be SMI masking register, which
could be extracted into a new SmmCpuFeaturesLib API.

Thus, would you please consider open sourcing firmware code for steps
(06) through (11)?

Alternatively -- and in particular because the stack for step (01)
concerns me --, we could approach this from a high-level, functional
perspective. The states that really matter are the relocated SMBASE for
the new CPU, and the state of the full system, right at the end of step
(11).

When the SMM setup quiesces during normal firmware boot, OVMF could
use
existent (finalized) SMBASE infomation to *pre-program* some virtual
QEMU hardware, with such state that would be expected, as "final" state,
of any new hotplugged CPU. Afterwards, if / when the hotplug actually
happens, QEMU could blanket-apply this state to the new CPU, and
broadcast a hardware SMI to all CPUs except the new one.
I'd rather avoid this and stay as close as possible to real hardware.

Paolo

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

Andy Hayes
 

From 4a42eb997aeb3699217b40bf3bc47dec56458847 Mon Sep 17 00:00:00 2001

From: "Andy Hayes" < andy.hayes@... >

Date: Wed, 14 Aug 2019 15:30:20 +0100

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

 

andy.hayes@... (1):

  Added GOP driver for USB Docks which use DisplayLink chips.

 

.../DisplayLinkPkg/DisplayLinkPkg.dsc         |   61 +

.../DisplayLinkGop/DisplayLinkGopDxe.inf      |   63 +

.../DisplayLinkPkg/DisplayLinkGop/Edid.h      |  129 ++

.../DisplayLinkGop/UsbDescriptors.h           |  109 ++

.../DisplayLinkGop/UsbDisplayLink.h           |  284 +++++

.../DisplayLinkGop/CapabilityDescriptor.c     |  137 ++

.../DisplayLinkGop/ComponentName.c            |  235 ++++

.../DisplayLinkPkg/DisplayLinkGop/Edid.c      |  598 +++++++++

.../DisplayLinkPkg/DisplayLinkGop/Gop.c       |  587 +++++++++

.../DisplayLinkGop/UsbDescriptors.c           |  144 +++

.../DisplayLinkGop/UsbDisplayLink.c           | 1109 +++++++++++++++++

.../DisplayLinkGop/UsbTransfer.c              |  180 +++

.../DisplayLinkGop/VideoModes.c               |  254 ++++

Drivers/DisplayLink/DisplayLinkPkg/ReadMe.md  |   77 ++

Maintainers.txt                               |    5 +

15 files changed, 3972 insertions(+)

create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkPkg.dsc

create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/DisplayLinkGopDxe.inf

create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Edid.h

create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDescriptors.h

create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDisplayLink.h

create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/CapabilityDescriptor.c

create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/ComponentName.c

create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Edid.c

create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Gop.c

create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDescriptors.c

create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDisplayLink.c

create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c

create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/VideoModes.c

create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/ReadMe.md

 

--

2.17.1

Cancelled Event: TianoCore Design / Bug Triage - EMEA - Wednesday, 14 August 2019 #cal-cancelled

devel@edk2.groups.io Calendar <devel@...>
 

Cancelled: TianoCore Design / Bug Triage - EMEA

This event has been cancelled.

When:
Wednesday, 14 August 2019
8:00am to 9:00am
(UTC-07:00) America/Los Angeles

Where:
https://zoom.us/j/695893389

Organizer:
stephano.cetola@...

Description:

Join Zoom Meeting

https://zoom.us/j/695893389

 

One tap mobile

+17207072699,,695893389# US

+16465588656,,695893389# US (New York)

 

Dial by your location

        +1 720 707 2699 US

        +1 646 558 8656 US (New York)

Meeting ID: 695 893 389

Find your local number: https://zoom.us/u/abOtdJckxL