[edk2-devel] [edk2-test][Patch 1/1] uefi-sct/SctPkg: Fix the gBlackBoxEfiSimplePointerProtocolGuid value

2019-08-19 Thread Eric Jin
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1571
Besides, EOL is converted to CRLF.

Cc: Supreeth Venkatesh 
Signed-off-by: Eric Jin 
---
 uefi-sct/SctPkg/UEFI/UEFI.dec | 206 +-
 1 file changed, 103 insertions(+), 103 deletions(-)

diff --git a/uefi-sct/SctPkg/UEFI/UEFI.dec b/uefi-sct/SctPkg/UEFI/UEFI.dec
index bdf3323fc2da..e8f04e96f520 100644
--- a/uefi-sct/SctPkg/UEFI/UEFI.dec
+++ b/uefi-sct/SctPkg/UEFI/UEFI.dec
@@ -1,8 +1,8 @@
 ## @file
 #
 #  Copyright 2004 - 2017 Unified EFI, Inc.
-#  Copyright (c) 2014 - 2019, ARM Limited. All rights reserved.
-#  Copyright (c) 2016 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2014 - 2019, ARM Limited. All rights reserved.
+#  Copyright (c) 2016 - 2019, Intel Corporation. All rights reserved.
 #  (C) Copyright 2017 Hewlett Packard Enterprise Development LP
 #
 #  This program and the accompanying materials
@@ -44,25 +44,25 @@
   
 
 [Guids.common]
-  gBlackBoxEfiFileInfoGuid = { 0x9576e92, 0x6d3f, 0x11d2, { 0x8e, 0x39, 0x0, 
0xa0, 0xc9, 0x69, 0x72, 0x3b }}
-  gBlackBoxEfiFileInfoIdGuid = { 0x9576e93, 0x6d3f, 0x11d2, { 0x8e, 0x39, 0x0, 
0xa0, 0xc9, 0x69, 0x72, 0x3b }}
+  gBlackBoxEfiFileInfoGuid = { 0x9576e92, 0x6d3f, 0x11d2, { 0x8e, 0x39, 0x0, 
0xa0, 0xc9, 0x69, 0x72, 0x3b }}
+  gBlackBoxEfiFileInfoIdGuid = { 0x9576e93, 0x6d3f, 0x11d2, { 0x8e, 0x39, 0x0, 
0xa0, 0xc9, 0x69, 0x72, 0x3b }}
   gBlackBoxEfiFileSystemInfoGuid = { 0x09576E93, 0x6D3F, 0x11D2, { 0x8E, 0x39, 
0x00, 0xA0, 0xC9, 0x69, 0x72, 0x3B }}
-  gBlackBoxEfiFileSystemVolumeLabelInfoIdGuid = { 0xDB47D7D3, 0xFE81, 0x11d3, 
{ 0x9A, 0x35, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D }}
-  gBlackBoxEfiTcp4RegistryDataGuid = { 0x755B4303, 0xCAA5, 0x4481, { 0xB1, 
0x3D, 0x07, 0xBE, 0x14, 0xD5, 0x4D, 0x3F }}
-  gBlackBoxEfiTcp6RegistryDataGuid = { 0x80623540, 0x7B41, 0x4306, { 0x99, 
0x87, 0x1B, 0xF6, 0xE5, 0xAD, 0x15, 0x3E }}
+  gBlackBoxEfiFileSystemVolumeLabelInfoIdGuid = { 0xDB47D7D3, 0xFE81, 0x11d3, 
{ 0x9A, 0x35, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D }}
+  gBlackBoxEfiTcp4RegistryDataGuid = { 0x755B4303, 0xCAA5, 0x4481, { 0xB1, 
0x3D, 0x07, 0xBE, 0x14, 0xD5, 0x4D, 0x3F }}
+  gBlackBoxEfiTcp6RegistryDataGuid = { 0x80623540, 0x7B41, 0x4306, { 0x99, 
0x87, 0x1B, 0xF6, 0xE5, 0xAD, 0x15, 0x3E }}
   gBlackBoxEfiPcAnsiGuid = { 0xE0C14753, 0xF9BE, 0x11D2, { 0x9A, 0x0C, 0x00, 
0x90, 0x27, 0x3F, 0xC1, 0x4D }}
   gBlackBoxEfiVT100Guid = { 0xDFA66065, 0xB419, 0x11D3, { 0x9A, 0x2D, 0x00, 
0x90, 0x27, 0x3F, 0xC1, 0x4D }}
   gBlackBoxEfiVT100PlusGuid = { 0x7BAEC70B, 0x57E0, 0x4C76, { 0x8E, 0x87, 
0x2F, 0x9E, 0x28, 0x08, 0x83, 0x43 }}
   gBlackBoxEfiVTUTF8Guid = { 0xAD15A0D6, 0x8BEC, 0x4ACF, { 0xA0, 0x73, 0xD0, 
0x1D, 0xE7, 0x7E, 0x2D, 0x88 }}
 
-  gBlackBoxEfiHash2AlgorithmSha1Guid = { 0x2ae9d80f, 0x3fb2, 0x4095, { 0xb7, 
0xb1, 0xe9, 0x31, 0x57, 0xb9, 0x46, 0xb6 }}
-  gBlackBoxEfiHash2AlgorithmSha224Guid = { 0x8df01a06, 0x9bd5, 0x4bf7, { 0xb0, 
0x21, 0xdb, 0x4f, 0xd9, 0xcc, 0xf4, 0x5b }}
-  gBlackBoxEfiHash2AlgorithmSha256Guid = { 0x51aa59de, 0xfdf2, 0x4ea3, { 0xbc, 
0x63, 0x87, 0x5f, 0xb7, 0x84, 0x2e, 0xe9 }}
-  gBlackBoxEfiHash2AlgorithmSha384Guid = { 0xefa96432, 0xde33, 0x4dd2, { 0xae, 
0xe6, 0x32, 0x8c, 0x33, 0xdf, 0x77, 0x7a }}
-  gBlackBoxEfiHash2AlgorithmSha512Guid = { 0xcaa4381e, 0x750c, 0x4770, { 0xb8, 
0x70, 0x7a, 0x23, 0xb4, 0xe4, 0x21, 0x30 }}
-  gBlackBoxEfiHash2AlgorithmMD5Guid = { 0xaf7c79c, 0x65b5, 0x4319, { 0xb0, 
0xae, 0x44, 0xec, 0x48, 0x4e, 0x4a, 0xd7 }}
-  gBlackBoxEfiHash2AlgorithmSha1NoPadGuid = { 0x24c5dc2f, 0x53e2, 0x40ca, { 
0x9e, 0xd6, 0xa5, 0xd9, 0xa4, 0x9f, 0x46, 0x3b }}
-  gBlackBoxEfiHash2AlgorithmSha256NoPadGuid = { 0x8628752a, 0x6cb7, 0x4814, { 
0x96, 0xfc, 0x24, 0xa8, 0x15, 0xac, 0x22, 0x26 }}
+  gBlackBoxEfiHash2AlgorithmSha1Guid = { 0x2ae9d80f, 0x3fb2, 0x4095, { 0xb7, 
0xb1, 0xe9, 0x31, 0x57, 0xb9, 0x46, 0xb6 }}
+  gBlackBoxEfiHash2AlgorithmSha224Guid = { 0x8df01a06, 0x9bd5, 0x4bf7, { 0xb0, 
0x21, 0xdb, 0x4f, 0xd9, 0xcc, 0xf4, 0x5b }}
+  gBlackBoxEfiHash2AlgorithmSha256Guid = { 0x51aa59de, 0xfdf2, 0x4ea3, { 0xbc, 
0x63, 0x87, 0x5f, 0xb7, 0x84, 0x2e, 0xe9 }}
+  gBlackBoxEfiHash2AlgorithmSha384Guid = { 0xefa96432, 0xde33, 0x4dd2, { 0xae, 
0xe6, 0x32, 0x8c, 0x33, 0xdf, 0x77, 0x7a }}
+  gBlackBoxEfiHash2AlgorithmSha512Guid = { 0xcaa4381e, 0x750c, 0x4770, { 0xb8, 
0x70, 0x7a, 0x23, 0xb4, 0xe4, 0x21, 0x30 }}
+  gBlackBoxEfiHash2AlgorithmMD5Guid = { 0xaf7c79c, 0x65b5, 0x4319, { 0xb0, 
0xae, 0x44, 0xec, 0x48, 0x4e, 0x4a, 0xd7 }}
+  gBlackBoxEfiHash2AlgorithmSha1NoPadGuid = { 0x24c5dc2f, 0x53e2, 0x40ca, { 
0x9e, 0xd6, 0xa5, 0xd9, 0xa4, 0x9f, 0x46, 0x3b }}
+  gBlackBoxEfiHash2AlgorithmSha256NoPadGuid = { 0x8628752a, 0x6cb7, 0x4814, { 
0x96, 0xfc, 0x24, 0xa8, 0x15, 0xac, 0x22, 0x26 }}
 
   
   gBlackBoxEfiCertSha256Guid = { 0xc1c41626, 0x504c, 0x4092, 
{0xac, 0xa9, 0x41, 0xf9, 0x36, 0x93, 0x43, 0x28 }} 
@@ -79,55 +79,55 @@
   gBlackBoxEfiPersistentVirtualCdGuid = { 0x08018188, 0x42CD, 0xBB48, {0x10, 
0x0F, 0x53, 0x87, 0xD5, 0x3D, 0xED, 

答复: [edk2-devel] [edk2] If use prebuild tools, not need install python 2.7 anymore?

2019-08-19 Thread Tiger Liu(BJ-RD)
Hi, Liming:
Based on the below web info:
https://github.com/tianocore/tianocore.github.io/wiki/Edk2-buildtools

The python tools are used to compile the building tools written by python.

https://github.com/tianocore/tianocore.github.io/wiki/BuildTool-Setup-Guide
in the above web, it said:
“The tools in this section are NOT required to build the EDK II project; they 
are needed to compile the BaseTools used to build the EDK II project.”

If I used the Prebuilt Windows tools (Win32 binaries), then I don’t need 
install python package anymore?

Or, current UDK source code doesn’t support prebuilt tools binary, it always 
need installing Python to compile python build tools every time.

Thanks
发件人: devel@edk2.groups.io  代表 Liming Gao
发送时间: 2019年8月19日 22:46
收件人: devel@edk2.groups.io; Tiger Liu(BJ-RD) 
主题: Re: [edk2-devel] [edk2] If use prebuild tools, not need install python 2.7 
anymore?

Now, edk2 stable tag release is 
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning

After edk2-stable201903 tag, edk2 supports Python3. User needs to install 
Python3.x, doesn’t need to set PYTHON path.

Thanks
Liming
From: devel@edk2.groups.io 
[mailto:devel@edk2.groups.io] On Behalf Of Tiger Liu(BJ-RD)
Sent: Monday, August 19, 2019 4:56 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] [edk2] If use prebuild tools, not need install python 2.7 
anymore?

Hello,
I have a question about needing install python 2.7

If user wants to setup udk compiling environment, he needs install python 2.7.
When running build command every time, it always check python tool path.
Why?

If I compiled basetools before, and use the prebuilt basetools package, then I 
don’t need install python 2.7 package?

Thanks


保密声明:
本邮件含有保密或专有信息,仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for 
the sole use of its intended recipient. Any unauthorized review, use, copying 
or forwarding of this email or the content of this email is strictly prohibited.



保密声明:
本邮件含有保密或专有信息,仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for 
the sole use of its intended recipient. Any unauthorized review, use, copying 
or forwarding of this email or the content of this email is strictly prohibited.

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

View/Reply Online (#46077): https://edk2.groups.io/g/devel/message/46077
Mute This Topic: https://groups.io/mt/32964418/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] BaseTools/BinWrappers question?

2019-08-19 Thread Liming Gao
Andrew:

>-Original Message-
>From: af...@apple.com [mailto:af...@apple.com]
>Sent: Tuesday, August 20, 2019 2:17 AM
>To: devel@edk2.groups.io; Gao, Liming 
>Subject: Re: [edk2-devel] BaseTools/BinWrappers question?
>
>
>
>> On Aug 19, 2019, at 6:09 AM, Liming Gao  wrote:
>>
>> Andrew:
>>  This is the history reason. Before, Edk2 BaseTools included the binary
>Windows tools in BaseTools\Bin\Win32. There is no
>BaseTools/BinWrappers/WindowsLike directory.
>>
>>  When migrate BaseTools Windows tools from binary to source build, Edk2
>BaseTools C source is still compiled to BaseTools\Bin\Win32 directory. Because
>BaseTools\Bin\Win32 is set into system PATH env, there is no requirement to
>add their wrapper scripts in BaseTools/BinWrappers/WindowsLike directory.
>>
>
>Liming,
>
>Thanks for the answer, I was guessing it was related to the history difference
>with the tools.
>
>I ran some experiments years ago and calling the C function through the bash
>script seemed to take up 5% of the build time. Would it make sense to use a
>path for Unix builds too vs. the wrappers?
>
Thanks for your comments. I will try this way. If it could improve the build 
performance, 
it is valuable to make this change. 

>Thanks,
>
>Andrew Fish
>
>> Thanks
>> Liming
>>> -Original Message-
>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>Andrew Fish via Groups.Io
>>> Sent: Saturday, August 17, 2019 1:01 AM
>>> To: devel@edk2.groups.io
>>> Subject: [edk2-devel] BaseTools/BinWrappers question?
>>>
>>> Why does BaseTools/BinWrappers/WindowsLike only have wrappers for
>Python commands, while  BaseTools/BinWrappers/PosixLike has
>>> wrappers for C based tools too?
>>>
>>> Thanks,
>>>
>>> Andrew Fish
>>>
>>
>>
>> 
>>


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

View/Reply Online (#46076): https://edk2.groups.io/g/devel/message/46076
Mute This Topic: https://groups.io/mt/32900805/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [edk2-platforms: PATCH v2] Python run fail if env variable PYTHON_HOME is not set

2019-08-19 Thread Chiu, Chasel


Pushed: 
https://github.com/tianocore/edk2-platforms/commit/05e9ca3abfcf89795d90e31415bac28a9f350299

> -Original Message-
> From: Cheng, Ching JenX
> Sent: Monday, August 19, 2019 5:24 PM
> To: devel@edk2.groups.io
> Cc: Chan, Amy ; Kubacki, Michael A
> ; Chiu, Chasel ;
> Desimone, Nathaniel L ; Gao, Liming
> 
> Subject: [edk2-platforms: PATCH v2] Python run fail if env variable
> PYTHON_HOME is not set
> 
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2041
> 
> [PATCH v2] Update related files
> 
> In Platform\Intel\MinPlatformPkg\Tools\Fsp\RebaseFspBinBaseAddress.py
> It will run another python code.
> But if the environment variable "PYTHON_HOME" is not exist and we didn't
> add any python's path to "PATH".
> It will cause error because python command not found.
> 
> the error message as below:
> 'python' is not recognized as an internal or external command, operable
> program or batch file.
> 
> So we set the python's path from which execute the python code if
> PYTHON_HOME was not exist.
> 
> Cc: Amy Chan 
> Cc: Michael Kubacki 
> Cc: Chasel Chiu 
> Cc: Nate DeSimone 
> Cc: Liming Gao 
> Signed-off-by: Ching JenX Cheng 
> ---
>  Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseFspBinBaseAddress.py | 2
> ++
>  1 file changed, 2 insertions(+)
> 
> diff --git
> a/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseFspBinBaseAddress.py
> b/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseFspBinBaseAddress.py
> index a8165b08e6..fb4cf4f9b7 100644
> --- a/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseFspBinBaseAddress.py
> +++
> b/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseFspBinBaseAddress.py
> @@ -68,6 +68,8 @@ file.close()
>  pythontool = 'python'
>  if 'PYTHON_HOME' in os.environ:
>  pythontool = os.environ['PYTHON_HOME'] + os.sep + 'python'
> +else:
> +pythontool = sys.executable
>  Process = subprocess.Popen([pythontool, splitFspBinPath,
> "info","-f",fspBinFilePath], stdout=subprocess.PIPE)  Output =
> Process.communicate()[0]  FsptInfo = Output.rsplit(b"FSP_M", 1);
> --
> 2.21.0.windows.1


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

View/Reply Online (#46075): https://edk2.groups.io/g/devel/message/46075
Mute This Topic: https://groups.io/mt/32942124/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by using CPUID(0x15) TSC leaf

2019-08-19 Thread Donald Kuo
Thanks Laszlo help to review and great feedbacks. That we did miss to fulfil 
BZ. 

I had updated Bugzilla https://bugzilla.tianocore.org/show_bug.cgi?id=1909 for 
more documentation.

As I know for the edk2-platforms should be consumed as KBL (7th Generation) 
platform in Client, and this feature based on SDM is supported on SKL (6th 
Generation, Family 06h) onwards. So it's ok to use as TimerLib instances for 
edk2-platforms.

And I think the library is new instances for TimerLib for supported CPU, and 
those non-supported CPU will still keep using AcpiTimerlib as TimerLib 
instances.

Thanks,
Donald

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Laszlo Ersek
> Sent: Saturday, August 17, 2019 4:40 AM
> To: Gao, Liming ; Kuo, Donald
> ; Dong, Eric ;
> devel@edk2.groups.io
> Cc: Ni, Ray ; Zeng, Star ; Chan,
> Amy ; Chaganty, Rangasai V
> ; Lai, Luke ; Li, Kevin
> Y ; leif.lindh...@linaro.org; af...@apple.com; Kinney,
> Michael D 
> Subject: Re: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by
> using CPUID(0x15) TSC leaf
> 
> On 08/16/19 18:16, Laszlo Ersek wrote:
> > On 08/15/19 06:02, Gao, Liming wrote:
> >> Donald: This change is a new feature. Now, it is not in edk2 feature
> >> planning list. If you want to catch it into 201908 stable tag, please
> >> get approve from Stewards first. I have cc this mail to all Stewards.
> > - I don't mind adding a new feature, as long as it gets properly
> > reviewed by package owners before we enter the soft feature freeze.
> >
> > - Looking at the BZ
> > , a bit more
> > documentation would be nice.
> >
> > - On the negative side, I'm very much *not* a fan of adding features
> > to the open source edk2 tree without actually *consuming* the feature
> > in an open source tree. Are the new library instances going to be put
> > to use in edk2-platforms, perhaps?
> >
> > We discussed this topic earlier on some of the stewards' calls. On one
> > hand, it's not uncommon to see library instances from Intel enter core
> > edk2 packages without any dependent platform code, or even a detailed
> > problem statement / purpose description (see e.g. commit 5c9bb86f171c
> > and its surrounding commits). On the other hand, attempts in the past,
> > to add libraries with well demonstrated and direct in-tree use cases,
> > to
> > edk2 core, have been rejected, from other submitters. (Here's one
> > example: .) I'm
> > not prying at proprietary platform information, but a new library
> > added to
> > edk2 core *should* be well-justified.
> >
> > The commit message on this patch is empty. It only references
> > . And if I open
> > the BZ, this is all I get:
> >
> > Need a new TSC library to check the CPUID leaf (EAX=0x15) for TSC.
> > For new platform (start from SKL) can use CPUID and retire/remove
> > the current override from AcpiTimerLib.
> >
> > Does this read like an actual feature request? (TimerLib is an MdePkg
> > library class, so not exactly "niche".)
> 
> In comparison, the following email does read like a feature request:
> 
> [edk2-devel] Determining TSC frequency programmatically
> https://edk2.groups.io/g/devel/message/45750
> http://mid.mail-archive.com/8EC14D0D-DFA5-412D-A4E1-
> 4d641576d...@protonmail.com
> 
> If the posting is related to TianoCore#1909, then I urge the BZ assignee to
> please reference the message in the TianoCore BZ.
> 
> Thanks
> Laszlo
> 
> 


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

View/Reply Online (#46074): https://edk2.groups.io/g/devel/message/46074
Mute This Topic: https://groups.io/mt/32839184/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [edk2-platforms][PATCH V1 1/1] Platform/Intel/Readme.md: Content update

2019-08-19 Thread Chiu, Chasel


Reviewed-by: Chasel Chiu 

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Kubacki, Michael A
> Sent: Tuesday, August 20, 2019 10:03 AM
> To: devel@edk2.groups.io
> Cc: Chaganty, Rangasai V ; Chiu, Chasel
> ; Gao, Liming ; Desimone,
> Nathaniel L ; Kinney, Michael D
> ; Sinha, Ankit 
> Subject: [edk2-devel] [edk2-platforms][PATCH V1 1/1]
> Platform/Intel/Readme.md: Content update
> 
> This change makes the following updates:
>  1. Indicate that build via batch scripts is no longer allowed.
>  2. Remove ClevoOpenBoardPkg batch build instructions since
> the batch build scripts no longer exist in the package.
>  3. Move firmware image flashing instructions to a clearly labeled
> section.
>  4. Elaborate the firmware image flashing instructions.
> 
> Cc: Sai Chaganty 
> Cc: Chasel Chiu 
> Cc: Liming Gao 
> Cc: Nate DeSimone 
> Cc: Michael D Kinney 
> Cc: Ankit Sinha 
> Signed-off-by: Michael Kubacki 
> ---
>  Platform/Intel/Readme.md | 28 ++--
>  1 file changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/Platform/Intel/Readme.md b/Platform/Intel/Readme.md index
> aaf6ef4d3e..3caf362983 100644
> --- a/Platform/Intel/Readme.md
> +++ b/Platform/Intel/Readme.md
> @@ -1,4 +1,4 @@
> -# **EDK II Minimum Platform Firmware for Intel(R) Platforms**
> +# **EDK II Minimum Platform Firmware for Intel Platforms**
> 
>  The Minimum Platform is a software architecture that guides uniform delivery
> of Intel platforms enabling firmware  solutions for basic boot functionality
> with extensibility built-in. Please see the @@ -200,7 +200,8 @@ return back to
> the minimum platform caller.
>
> 
>  **Building with the batch scripts**
> -KabylakeOpenBoardPkg does not support batch scripts, please use
> build_bios.py.
> +Only PurleyOpenBoardPkg still supports batch script build. Future board
> +packages must only use the Python build infrastructure.
> 
>  For PurleyOpenBoardPkg
>  1. Open command window, go to the workspace directory, e.g. c:\Purley.
> @@ -214,18 +215,6 @@ For PurleyOpenBoardPkg  The validated version of
> iasl compiler that can build MinPurley is 20180629. Older version may generate
> ACPI build  errors.
> 
> -For ClevoOpenBoardPkg
> -1. Open command window, go to the workspace directory, e.g. c:\Clevo.
> -2. Type "cd edk2-platforms\Platform\Intel\ClevoOpenBoardPkg\N1xxWU".
> -3. Type "GitEdk2Clevo.bat" to setup GIT environment.
> -4. Type "bld" to build Clevo UEFI firmware image, "bld release" for release
> build, "bld clean" to remove intermediate -files.
> -
> -Users with access to the Intel proprietary FITC tool and ME ingredients can
> build full images for flash  (BIOS + ME + -DESC).
> -
> -Users can also flash the UEFI firmware image to the highest area of the flash
> region directly.
> -
>  ### **Known limitations**
> 
>  **ClevoOpenBoardPkg**
> @@ -258,6 +247,17 @@ Users can also flash the UEFI firmware image to the
> highest area of the flash re  4. The Linux build was tested on Ubuntu 16.04.5
> LTS with GCC version 5.4.0.
>  5. The build was tested with NASM version 2.11.08.
> 
> +### **Firmware Image Flashing**
> +
> +The full Intel firmware image on a flash device is called the
> +Integrated Firmware Image (IFWI). Users with access to the Intel proprietary
> FITC tool and ME ingredients can build full IFWI images that may be flashed
> (Descriptor, UEFI FW, ME FW, etc.).
> +
> +Users without such access can directly flash a custom built UEFI FW image
> over the highest area of the flash region directly.
> +It is always recommended to have a hardware flash programmer accessible
> +to recover the firmware image. The original full flash image should
> +always be backed up so it may be flashed again for recovery. Please be
> +aware that if a system supports a technology that authenticates the initial
> firmware boot image such as Boot Guard, it will fail to boot with a custom
> firmware image that is not signed properly.
> +
>  ### **Planned Activities**
>  * Replace the batch build scripts with cross-platform Python build scripts.
>  * Publish a Minimum Platform specification to describe the architecture and
> interfaces in more detail.
> --
> 2.16.2.windows.1
> 
> 
> 


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

View/Reply Online (#46073): https://edk2.groups.io/g/devel/message/46073
Mute This Topic: https://groups.io/mt/32963085/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH V3] [edk2-stable201908] BaseTools: Update incorrect variable name 'DataPile'

2019-08-19 Thread Bob Feng
Reviewed-by: Bob Feng 

-Original Message-
From: Fan, ZhijuX 
Sent: Tuesday, August 20, 2019 8:49 AM
To: devel@edk2.groups.io
Cc: Gao, Liming ; Feng, Bob C 
Subject: [PATCH V3] [edk2-stable201908] BaseTools: Update incorrect variable 
name 'DataPile'

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

The PlatformAutoGen object has a DataPipe property but no DataPile property So 
change the variable name 'DataPile' to 'DataPipe' in BuildReport.py

This patch is going to fix that issue.

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Zhiju.Fan 
---
 BaseTools/Source/Python/build/BuildReport.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/build/BuildReport.py 
b/BaseTools/Source/Python/build/BuildReport.py
index 9c12c01d2a..6b26f1c3b0 100644
--- a/BaseTools/Source/Python/build/BuildReport.py
+++ b/BaseTools/Source/Python/build/BuildReport.py
@@ -2142,7 +2142,7 @@ class PlatformReport(object):
 INFList = 
GlobalData.gFdfParser.Profile.InfDict[Pa.Arch]
 for InfName in INFList:
 InfClass = PathClass(NormPath(InfName), 
Wa.WorkspaceDir, Pa.Arch)
-Ma = ModuleAutoGen(Wa, InfClass, Pa.BuildTarget, 
Pa.ToolChain, Pa.Arch, Wa.MetaFile,Pa.DataPile)
+Ma = ModuleAutoGen(Wa, InfClass, 
+ Pa.BuildTarget, Pa.ToolChain, Pa.Arch, Wa.MetaFile, Pa.DataPipe)
 if Ma is None:
 continue
 if Ma not in ModuleAutoGenList:
--
2.14.1.windows.1


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

View/Reply Online (#46072): https://edk2.groups.io/g/devel/message/46072
Mute This Topic: https://groups.io/mt/32962507/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [edk2-platforms][PATCH V1 1/1] Platform/Intel/Readme.md: Content update

2019-08-19 Thread Kubacki, Michael A
This change makes the following updates:
 1. Indicate that build via batch scripts is no longer allowed.
 2. Remove ClevoOpenBoardPkg batch build instructions since
the batch build scripts no longer exist in the package.
 3. Move firmware image flashing instructions to a clearly labeled
section.
 4. Elaborate the firmware image flashing instructions.

Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Liming Gao 
Cc: Nate DeSimone 
Cc: Michael D Kinney 
Cc: Ankit Sinha 
Signed-off-by: Michael Kubacki 
---
 Platform/Intel/Readme.md | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/Platform/Intel/Readme.md b/Platform/Intel/Readme.md
index aaf6ef4d3e..3caf362983 100644
--- a/Platform/Intel/Readme.md
+++ b/Platform/Intel/Readme.md
@@ -1,4 +1,4 @@
-# **EDK II Minimum Platform Firmware for Intel(R) Platforms**
+# **EDK II Minimum Platform Firmware for Intel Platforms**
 
 The Minimum Platform is a software architecture that guides uniform delivery 
of Intel platforms enabling firmware
 solutions for basic boot functionality with extensibility built-in. Please see 
the
@@ -200,7 +200,8 @@ return back to the minimum platform caller.
   
 
 **Building with the batch scripts**
-KabylakeOpenBoardPkg does not support batch scripts, please use build_bios.py.
+Only PurleyOpenBoardPkg still supports batch script build. Future board 
packages must only use the Python build
+infrastructure.
 
 For PurleyOpenBoardPkg
 1. Open command window, go to the workspace directory, e.g. c:\Purley.
@@ -214,18 +215,6 @@ For PurleyOpenBoardPkg
 The validated version of iasl compiler that can build MinPurley is 20180629. 
Older version may generate ACPI build
 errors.
 
-For ClevoOpenBoardPkg
-1. Open command window, go to the workspace directory, e.g. c:\Clevo.
-2. Type "cd edk2-platforms\Platform\Intel\ClevoOpenBoardPkg\N1xxWU".
-3. Type "GitEdk2Clevo.bat" to setup GIT environment.
-4. Type "bld" to build Clevo UEFI firmware image, "bld release" for release 
build, "bld clean" to remove intermediate
-files.
-
-Users with access to the Intel proprietary FITC tool and ME ingredients can 
build full images for flash  (BIOS + ME +
-DESC).
-
-Users can also flash the UEFI firmware image to the highest area of the flash 
region directly.
-
 ### **Known limitations**
 
 **ClevoOpenBoardPkg**
@@ -258,6 +247,17 @@ Users can also flash the UEFI firmware image to the 
highest area of the flash re
 4. The Linux build was tested on Ubuntu 16.04.5 LTS with GCC version 5.4.0.
 5. The build was tested with NASM version 2.11.08.
 
+### **Firmware Image Flashing**
+
+The full Intel firmware image on a flash device is called the Integrated 
Firmware Image (IFWI). Users with access to the Intel
+proprietary FITC tool and ME ingredients can build full IFWI images that may 
be flashed (Descriptor, UEFI FW, ME FW, etc.).
+
+Users without such access can directly flash a custom built UEFI FW image over 
the highest area of the flash region directly.
+It is always recommended to have a hardware flash programmer accessible to 
recover the firmware image. The original full flash
+image should always be backed up so it may be flashed again for recovery. 
Please be aware that if a system supports a technology
+that authenticates the initial firmware boot image such as Boot Guard, it will 
fail to boot with a custom firmware image
+that is not signed properly.
+
 ### **Planned Activities**
 * Replace the batch build scripts with cross-platform Python build scripts.
 * Publish a Minimum Platform specification to describe the architecture and 
interfaces in more detail.
-- 
2.16.2.windows.1


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

View/Reply Online (#46071): https://edk2.groups.io/g/devel/message/46071
Mute This Topic: https://groups.io/mt/32963085/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [edk2-platform patch 7/7] Platform/Intel: Add build option for SIMICS QSP Platform

2019-08-19 Thread Kubacki, Michael A
You will need to resolve a conflict in build.cfg. When you do so, please keep 
the boards under
[PLATFORMS] in lexicographically ascending order for ease of maintenance.

> -Original Message-
> From: Wei, David Y
> Sent: Friday, August 9, 2019 3:47 PM
> To: devel@edk2.groups.io
> Cc: Wu, Hao A ; Gao, Liming ;
> Sinha, Ankit ; Agyeman, Prince
> ; Kubacki, Michael A
> ; Desimone, Nathaniel L
> ; Kinney, Michael D
> 
> Subject: [edk2-platform patch 7/7] Platform/Intel: Add build option for SIMICS
> QSP Platform
> 
> Add build option in build script for SIMICS QSP Platform
> 
> Cc: Hao Wu 
> Cc: Liming Gao 
> Cc: Ankit Sinha 
> Cc: Agyeman Prince 
> Cc: Kubacki Michael A 
> Cc: Nate DeSimone 
> Cc: Michael D Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.0
> 
> Signed-off-by: David Wei 
> ---
>  Platform/Intel/build.cfg | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Platform/Intel/build.cfg b/Platform/Intel/build.cfg index
> fc6e4fe824..2ebe09a632 100644
> --- a/Platform/Intel/build.cfg
> +++ b/Platform/Intel/build.cfg
> @@ -54,3 +54,5 @@ NUMBER_OF_PROCESSORS = 0
>  KabylakeRvp3 = KabylakeOpenBoardPkg/KabylakeRvp3/build_config.cfg
>  N1xxWU = ClevoOpenBoardPkg/N1xxWU/build_config.cfg
>  BoardMtOlympus = PurleyOpenBoardPkg/BoardMtOlympus/build_config.cfg
> +WhiskeylakeURvp =
> +WhiskeylakeOpenBoardPkg/WhiskeylakeURvp/build_config.cfg
> +BoardX58ICH10 = SimicsOpenBoardPkg/BoardX58ICH10/build_config.cfg
> --
> 2.16.2.windows.1


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

View/Reply Online (#46069): https://edk2.groups.io/g/devel/message/46069
Mute This Topic: https://groups.io/mt/32816101/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [edk2-platform patch 6/7] SimicsOpenBoardPkg: Add board module for QSP Build tip

2019-08-19 Thread Kubacki, Michael A
Feedback I could not find already noted elsewhere:

1. Remove the batch build files:
 - GitEdk2X58ICH10.bat
 - bld.bat
 - prebuild.bat

The changes must be built with the Python scripts.

2. General comment that applies to multiple files:
 Files such as "PlatformPkgBuildOption.dsc" should follow the pre-existing 
open board package
 naming convention. For example, "OpenBoardPkgBuildOption.dsc" in 
KabylakeOpenBoardPkg.
3. The first commit line should be "SimicsOpenBoardPkg/BoardX58Ich10 to 
indicate the files relative
 to their location in that board directory.
4. Some build option macros in here seem unnecessary. For example, 
"PURLEY_FLAG". Can you please
 check and clean this up?
5. PlatformPkgConfig.dsc: The following PCDs should not always be TRUE as they 
originate in the
 AdvancedFeaturePkg and should only be enabled for an advanced feature boot.
 - gAdvancedFeaturePkgTokenSpaceGuid.PcdNetworkEnable
 - gAdvancedFeaturePkgTokenSpaceGuid.PcdSmbiosEnable

> -Original Message-
> From: Wei, David Y
> Sent: Friday, August 9, 2019 3:47 PM
> To: devel@edk2.groups.io
> Cc: Wu, Hao A ; Gao, Liming ;
> Sinha, Ankit ; Agyeman, Prince
> ; Kubacki, Michael A
> ; Desimone, Nathaniel L
> ; Kinney, Michael D
> 
> Subject: [edk2-platform patch 6/7] SimicsOpenBoardPkg: Add board module
> for QSP Build tip
> 
> Add BoardX58ICH10 module for QSP Build tip
> 
> Cc: Hao Wu 
> Cc: Liming Gao 
> Cc: Ankit Sinha 
> Cc: Agyeman Prince 
> Cc: Kubacki Michael A 
> Cc: Nate DeSimone 
> Cc: Michael D Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.0
> 
> Signed-off-by: David Wei 
> ---
>  .../Library/BoardInitLib/PeiBoardInitPostMemLib.c  |  44 +++
>  .../Library/BoardInitLib/PeiBoardInitPreMemLib.c   | 110 
>  .../Library/BoardInitLib/PeiX58ICH10Detect.c   |  26 ++
>  .../BoardInitLib/PeiX58ICH10InitPostMemLib.c   |  34 +++
>  .../BoardInitLib/PeiX58ICH10InitPreMemLib.c| 111 
>  .../BoardX58ICH10/DecomprScratchEnd.fdf.inc|  66 +
>  .../BoardX58ICH10/GitEdk2X58ICH10.bat  |  75 +
>  .../BoardInitLib/PeiBoardInitPostMemLib.inf|  36 +++
>  .../Library/BoardInitLib/PeiBoardInitPreMemLib.inf |  38 +++
>  .../Library/BoardInitLib/PeiX58ICH10InitLib.h  |  16 ++
>  .../BoardX58ICH10/PlatformPkgBuildOption.dsc   |  89 ++
>  .../BoardX58ICH10/PlatformPkgConfig.dsc|  56 
>  .../BoardX58ICH10/PlatformPkgPcd.dsc   | 283 +++
>  .../BoardX58ICH10/SimicsX58Pkg.fdf.inc |  48 
>  .../BoardX58ICH10/SimicsX58PkgIa32X64.dsc  | 244 +
>  .../BoardX58ICH10/SimicsX58PkgIa32X64.fdf  | 303
> +
>  .../BoardX58ICH10/VarStore.fdf.inc |  53 
>  .../Intel/SimicsOpenBoardPkg/BoardX58ICH10/bld.bat | 139 ++
>  .../BoardX58ICH10/build_config.cfg |  31 +++
>  .../SimicsOpenBoardPkg/BoardX58ICH10/prebuild.bat  | 198
> ++
>  20 files changed, 2000 insertions(+)
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/BoardX58ICH10/Library/BoardInitLib/PeiB
> oardInitPostMemLib.c
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/BoardX58ICH10/Library/BoardInitLib/PeiB
> oardInitPreMemLib.c
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/BoardX58ICH10/Library/BoardInitLib/PeiX
> 58ICH10Detect.c
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/BoardX58ICH10/Library/BoardInitLib/PeiX
> 58ICH10InitPostMemLib.c
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/BoardX58ICH10/Library/BoardInitLib/PeiX
> 58ICH10InitPreMemLib.c
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/BoardX58ICH10/DecomprScratchEnd.fdf.i
> nc
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/BoardX58ICH10/GitEdk2X58ICH10.bat
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/BoardX58ICH10/Library/BoardInitLib/PeiB
> oardInitPostMemLib.inf
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/BoardX58ICH10/Library/BoardInitLib/PeiB
> oardInitPreMemLib.inf
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/BoardX58ICH10/Library/BoardInitLib/PeiX
> 58ICH10InitLib.h
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/BoardX58ICH10/PlatformPkgBuildOption.
> dsc
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/BoardX58ICH10/PlatformPkgConfig.dsc
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/BoardX58ICH10/PlatformPkgPcd.dsc
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/BoardX58ICH10/SimicsX58Pkg.fdf.inc
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/BoardX58ICH10/SimicsX58PkgIa32X64.ds
> c
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/BoardX58ICH10/SimicsX58PkgIa32X64.fdf
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/BoardX58ICH10/VarStore.fdf.inc
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/BoardX58ICH10/bld.bat
>  create mode 100644
> 

Re: [edk2-devel] [edk2-platform patch 4/7] SimicsOpenBoardPkg: Add DXE driver for Legacy Sio

2019-08-19 Thread Kubacki, Michael A
My code review comments are already noted elsewhere.

> -Original Message-
> From: Wei, David Y
> Sent: Friday, August 9, 2019 3:47 PM
> To: devel@edk2.groups.io
> Cc: Wu, Hao A ; Gao, Liming ;
> Sinha, Ankit ; Agyeman, Prince
> ; Kubacki, Michael A
> ; Desimone, Nathaniel L
> ; Kinney, Michael D
> 
> Subject: [edk2-platform patch 4/7] SimicsOpenBoardPkg: Add DXE driver for
> Legacy Sio
> 
> Add DXE driver for Legacy Sio support
> 
> Cc: Hao Wu 
> Cc: Liming Gao 
> Cc: Ankit Sinha 
> Cc: Agyeman Prince 
> Cc: Kubacki Michael A 
> Cc: Nate DeSimone 
> Cc: Michael D Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.0
> 
> Signed-off-by: David Wei 
> ---
>  .../LegacySioDxe/ComponentName.c   | 173 ++
>  .../SimicsOpenBoardPkg/LegacySioDxe/SioChip.c  | 272 ++
>  .../SimicsOpenBoardPkg/LegacySioDxe/SioDriver.c| 600
> +
>  .../SimicsOpenBoardPkg/LegacySioDxe/SioService.c   | 249 +
>  .../LegacySioDxe/ComponentName.h   |  87 +++
>  .../LegacySioDxe/LegacySioDxe.inf  |  54 ++
>  .../SimicsOpenBoardPkg/LegacySioDxe/Register.h |  15 +
>  .../SimicsOpenBoardPkg/LegacySioDxe/SioChip.h  | 195 +++
>  .../SimicsOpenBoardPkg/LegacySioDxe/SioDriver.h| 134 +
>  .../SimicsOpenBoardPkg/LegacySioDxe/SioService.h   | 143 +
>  10 files changed, 1922 insertions(+)
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/ComponentName.c
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioChip.c
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioDriver.c
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioService.c
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/ComponentName.h
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/LegacySioDxe.inf
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/Register.h
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioChip.h
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioDriver.h
>  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioService.h
> 
> diff --git
> a/Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/ComponentName.c
> b/Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/ComponentName.c
> new file mode 100644
> index 00..93e8cefe6c
> --- /dev/null
> +++ b/Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/ComponentName.c
> @@ -0,0 +1,173 @@
> +/** @file
> +  Install Base and Size Info Ppi for Firmware Volume Recovery.
> +
> +  Copyright (c) 2013 - 2016 Intel Corporation. All rights reserved. 
> +
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +**/
> +
> +#include "SioDriver.h"
> +
> +///
> +/// Component Name Protocol instance
> +///
> +GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME_PROTOCOL
> mSioComponentName = {
> +  SioComponentNameGetDriverName,
> +  SioComponentNameGetControllerName,
> +  "eng"
> +};
> +
> +///
> +/// Component Name 2 Protocol instance
> +///
> +GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME2_PROTOCOL
> mSioComponentName2 = {
> +  (EFI_COMPONENT_NAME2_GET_DRIVER_NAME)
> SioComponentNameGetDriverName,
> +
> (EFI_COMPONENT_NAME2_GET_CONTROLLER_NAME)SioComponentNameGet
> ControllerName,
> +  "en"
> +};
> +
> +///
> +/// Table of driver names
> +///
> +GLOBAL_REMOVE_IF_UNREFERENCED EFI_UNICODE_STRING_TABLE
> mSioDriverNameTable[] = {
> +  {
> +"eng;en",
> +L"Super I/O Driver"
> +  },
> +  {
> +NULL,
> +NULL
> +  }
> +};
> +
> +///
> +/// Table of Controller names
> +///
> +GLOBAL_REMOVE_IF_UNREFERENCED EFI_UNICODE_STRING_TABLE
> mSioControllerNameTable[] = {
> +  {
> +"eng;en",
> +L"Super I/O Controller"
> +  },
> +  {
> +NULL,
> +NULL
> +  }
> +};
> +
> +/**
> +  Retrieves a Unicode string that is the user-readable name of the EFI 
> Driver.
> +
> +  @param  This   A pointer to the EFI_COMPONENT_NAME_PROTOCOL
> instance.
> +  @param  Language   A pointer to a three-character ISO 639-2 language
> identifier.
> + This is the language of the driver name that that the 
> caller
> + is requesting, and it must match one of the languages 
> specified
> + in SupportedLanguages.  The number of languages 
> supported by a
> + driver is up to the driver writer.
> +  @param  DriverName A pointer to the Unicode string to return.  This Unicode
> string
> + is the name of the driver specified by This in the 
> language
> + specified by Language.
> +
> +  @retval EFI_SUCCESS   The Unicode string for the Driver specified 
> by This
> +and the language specified by Language was 
> returned
> +in DriverName.
> +  @retval EFI_INVALID_PARAMETER Language is NULL.
> +  @retval EFI_INVALID_PARAMETER 

Re: [edk2-devel] [edk2-platform patch 1/7] SimicsX58SktPkg: Add CPU Pkg for SimicsX58

2019-08-19 Thread Kubacki, Michael A
Feedback I could not find already noted elsewhere:

1. Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccessPei.c:
 There's some style issues throughout the file related to a missing space 
before opening parenthesis and parameters than span multiple lines.
 Some of these are pre-existing in OvmfPkg source. I don't think this is a 
must have.
2. Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccessPei.c - Line 265:
 "Confirm if QEMU supports SMRAM." to "Confirm if Simics supports SMRAM."
3. Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccessPei.c - Line 275:
 "DEBUG((EFI_D_ERROR, "TopOfLowRam =0x%x; TopOfLowRamMb =0x%x \n", 
TopOfLowRam, TopOfLowRamMb));"
 Should be an informational message.
3. Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccessPei.c - Line 283:
 "DEBUG((EFI_D_ERROR, "MCH_TOLUD =0x%x; \n", 
PciRead32(DRAMC_REGISTER_X58(MCH_TOLUD;"
 Should be an informational message.
4. Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccessPei.c - Line 300 & Line 
301 - Should be informational messages as well.
5. Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccessPei.inf: Is a dependency 
on OvmfPkg/OvmfPkg.dec required? This dependency should be avoided.
6. Silicon/Intel/SimicsX58SktPkg/Override/UefiCpuPkg/SecCore: I don't think 
this should be an override but should exist in a similar manner
 as edk2/OvmfPkg/Sec. The code cannot be upstreamed as-is.
7. /Silicon/Intel/SimicsX58SktPkg/Override/UefiCpuPkg/SecCore/SecMain.c: Some 
of this messages should probably be verbose not informational.
8. /Silicon/Intel/SimicsX58SktPkg/SktPei.dsc: This file naming convention is 
unusual. SktPkgPei.dsc is more consistent. 

> -Original Message-
> From: Wei, David Y
> Sent: Friday, August 9, 2019 3:47 PM
> To: devel@edk2.groups.io
> Cc: Wu, Hao A ; Gao, Liming ;
> Sinha, Ankit ; Agyeman, Prince
> ; Kubacki, Michael A
> ; Desimone, Nathaniel L
> ; Kinney, Michael D
> 
> Subject: [edk2-platform patch 1/7] SimicsX58SktPkg: Add CPU Pkg for
> SimicsX58
> 
> Add CPU Pkg for SimicsX58. It is added for simics QSP project support
> 
> Cc: Hao Wu 
> Cc: Liming Gao 
> Cc: Ankit Sinha 
> Cc: Agyeman Prince 
> Cc: Kubacki Michael A 
> Cc: Nate DeSimone 
> Cc: Michael D Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.0
> 
> Signed-off-by: David Wei 
> ---
>  .../Override/UefiCpuPkg/SecCore/SecMain.c  | 956
> +
>  .../SimicsX58SktPkg/Smm/Access/SmmAccess2Dxe.c | 148 
>  .../SimicsX58SktPkg/Smm/Access/SmmAccessPei.c  | 353 
>  .../SimicsX58SktPkg/Smm/Access/SmramInternal.c | 199 +
>  .../Override/UefiCpuPkg/SecCore/Ia32/SecEntry.nasm |  45 +
>  .../Override/UefiCpuPkg/SecCore/SecMain.inf|  71 ++
>  .../Override/UefiCpuPkg/SecCore/X64/SecEntry.nasm  |  45 +
>  Silicon/Intel/SimicsX58SktPkg/SktPei.dsc   |  18 +
>  .../Intel/SimicsX58SktPkg/SktPostMemoryInclude.fdf |   9 +
>  .../Intel/SimicsX58SktPkg/SktPreMemoryInclude.fdf  |  10 +
>  Silicon/Intel/SimicsX58SktPkg/SktSecInclude.fdf|  17 +
>  .../Intel/SimicsX58SktPkg/SktUefiBootInclude.fdf   |  16 +
>  .../SimicsX58SktPkg/Smm/Access/SmmAccess2Dxe.inf   |  52 ++
>  .../SimicsX58SktPkg/Smm/Access/SmmAccessPei.inf|  64 ++
>  .../SimicsX58SktPkg/Smm/Access/SmramInternal.h |  81 ++
>  15 files changed, 2084 insertions(+)
>  create mode 100644
> Silicon/Intel/SimicsX58SktPkg/Override/UefiCpuPkg/SecCore/SecMain.c
>  create mode 100644
> Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccess2Dxe.c
>  create mode 100644
> Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccessPei.c
>  create mode 100644
> Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmramInternal.c
>  create mode 100644
> Silicon/Intel/SimicsX58SktPkg/Override/UefiCpuPkg/SecCore/Ia32/SecEntry.nas
> m
>  create mode 100644
> Silicon/Intel/SimicsX58SktPkg/Override/UefiCpuPkg/SecCore/SecMain.inf
>  create mode 100644
> Silicon/Intel/SimicsX58SktPkg/Override/UefiCpuPkg/SecCore/X64/SecEntry.nas
> m
>  create mode 100644 Silicon/Intel/SimicsX58SktPkg/SktPei.dsc
>  create mode 100644 Silicon/Intel/SimicsX58SktPkg/SktPostMemoryInclude.fdf
>  create mode 100644 Silicon/Intel/SimicsX58SktPkg/SktPreMemoryInclude.fdf
>  create mode 100644 Silicon/Intel/SimicsX58SktPkg/SktSecInclude.fdf
>  create mode 100644 Silicon/Intel/SimicsX58SktPkg/SktUefiBootInclude.fdf
>  create mode 100644
> Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccess2Dxe.inf
>  create mode 100644
> Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccessPei.inf
>  create mode 100644
> Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmramInternal.h
> 
> diff --git
> a/Silicon/Intel/SimicsX58SktPkg/Override/UefiCpuPkg/SecCore/SecMain.c
> b/Silicon/Intel/SimicsX58SktPkg/Override/UefiCpuPkg/SecCore/SecMain.c
> new file mode 100644
> index 00..c52d459ef2
> --- /dev/null
> +++ b/Silicon/Intel/SimicsX58SktPkg/Override/UefiCpuPkg/SecCore/SecMain.c
> @@ -0,0 +1,956 @@
> +/** @file
> +  Main SEC phase code.  Transitions to PEI.
> +
> +  Copyright (c) 2008 - 2015, Intel 

[edk2-devel] [PATCH V3] [edk2-stable201908] BaseTools: Update incorrect variable name 'DataPile'

2019-08-19 Thread Fan, ZhijuX
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2093

The PlatformAutoGen object has a DataPipe property but no DataPile property
So change the variable name 'DataPile' to 'DataPipe' in BuildReport.py

This patch is going to fix that issue.

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Zhiju.Fan 
---
 BaseTools/Source/Python/build/BuildReport.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/build/BuildReport.py 
b/BaseTools/Source/Python/build/BuildReport.py
index 9c12c01d2a..6b26f1c3b0 100644
--- a/BaseTools/Source/Python/build/BuildReport.py
+++ b/BaseTools/Source/Python/build/BuildReport.py
@@ -2142,7 +2142,7 @@ class PlatformReport(object):
 INFList = 
GlobalData.gFdfParser.Profile.InfDict[Pa.Arch]
 for InfName in INFList:
 InfClass = PathClass(NormPath(InfName), 
Wa.WorkspaceDir, Pa.Arch)
-Ma = ModuleAutoGen(Wa, InfClass, Pa.BuildTarget, 
Pa.ToolChain, Pa.Arch, Wa.MetaFile,Pa.DataPile)
+Ma = ModuleAutoGen(Wa, InfClass, Pa.BuildTarget, 
Pa.ToolChain, Pa.Arch, Wa.MetaFile, Pa.DataPipe)
 if Ma is None:
 continue
 if Ma not in ModuleAutoGenList:
-- 
2.14.1.windows.1


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

View/Reply Online (#46063): https://edk2.groups.io/g/devel/message/46063
Mute This Topic: https://groups.io/mt/32962507/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

<>

Re: [edk2-devel] Patch List for 201908 stable tag

2019-08-19 Thread Liming Gao
Ray:
  It follows current soft feature freeze process. I am OK to fix it for this 
stable tag.

Thanks
Liming
From: Ni, Ray [mailto:ray...@intel.com]
Sent: Tuesday, August 20, 2019 2:05 AM
To: Gao; Gao, Liming ; devel@edk2.groups.io
Subject: Re: [edk2-devel] Patch List for 201908 stable tag


Liming, Below patch already got the reviewed-by tag before the freezing point. 
Can I push it now?

https://edk2.groups.io/g/devel/topic/32737146 UefiCpuPkg/PiSmmCpuDxeSmm: don't 
free page table pages that are required to handle current page fault

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

View/Reply Online (#46062): https://edk2.groups.io/g/devel/message/46062
Mute This Topic: https://groups.io/mt/32896302/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] Patch List for 201908 stable tag

2019-08-19 Thread Michael D Kinney
Ray,

With your review, my vote is yes.

Mike

From: Ni, Ray
Sent: Monday, August 19, 2019 4:06 PM
To: devel@edk2.groups.io; Gao, Liming ; Laszlo Ersek 
(ler...@redhat.com) ; leif.lindh...@linaro.org; Kinney, 
Michael D ; af...@apple.com; Cetola, Stephano 

Subject: RE: [edk2-devel] Patch List for 201908 stable tag

All stewards,
Though it was already listed by Liming, I would like explicitly ask for 
including below changes in the coming stable tag:
https://edk2.groups.io/g/devel/message/45773 [Patch v4 0/6] Add "test then 
write" mechanism

The whole patches had gone through 4 rounds of review process while I was away.
I had a deep look at the whole changes and all look very good. (except a minor 
copyright year issue in the 6/6 patch.)


Thanks,
Ray

From: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>> On Behalf Of Liming Gao
Sent: Friday, August 16, 2019 1:01 AM
To: Gao, Liming mailto:liming@intel.com>>; Laszlo 
Ersek (ler...@redhat.com) 
mailto:ler...@redhat.com>>; 
leif.lindh...@linaro.org; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>; 
af...@apple.com; Cetola, Stephano 
mailto:stephano.cet...@intel.com>>
Cc: devel@edk2.groups.io
Subject: Re: [edk2-devel] Patch List for 201908 stable tag


From: Gao, Liming [mailto:liming@intel.com]
Sent: Friday, August 16, 2019 3:59 PM
To: Laszlo Ersek (ler...@redhat.com) 
mailto:ler...@redhat.com>>; 
leif.lindh...@linaro.org; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>; 
af...@apple.com; Cetola, Stephano 
mailto:stephano.cet...@intel.com>>
Cc: edk2-de...@lists.01.org
Subject: Patch List for 201908 stable tag

Hi Stewards and all:
  I collect current patch lists in devel mail list. Those patch contributors 
request to add them for 201908 stable tag. Because the time is very close to 
Soft Feature Freeze, I want to collect your feedback for below patches.

Feature List (those all have pass code review):
https://edk2.groups.io/g/devel/message/45734 [PATCH v6 0/5] Build cache 
enhancement
https://edk2.groups.io/g/devel/message/45707 [PATCH] UefiCpuPkg: Adding a new 
TSC library by using CPUID(0x15) TSC leaf
https://edk2.groups.io/g/devel/message/45503 [PATCH v2 1/1] MdePkg: Add 
STATIC_ASSERT macro

Bug List:
https://edk2.groups.io/g/devel/message/45794  [PATCH 1/1] CryptoPkg: Fix coding 
style
https://edk2.groups.io/g/devel/message/45791 [PATCH v2 1/1] 
ShellPkg/UefiShellAcpiViewCommandLib: Replace shift logical left
https://edk2.groups.io/g/devel/message/45793 [Patch 1/1] BaseTools: Fixed issue 
of incorrect Module Unique Name
https://edk2.groups.io/g/devel/message/45773 [Patch v4 0/6] Add "test then 
write" mechanism
https://edk2.groups.io/g/devel/message/45317 [Patch] MdeModulePkg DxeCore: Fix 
for missing MAT update

Thanks
Liming


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

View/Reply Online (#46061): https://edk2.groups.io/g/devel/message/46061
Mute This Topic: https://groups.io/mt/32896302/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] Patch List for 201908 stable tag

2019-08-19 Thread Michael D Kinney



> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, August 16, 2019 11:38 AM
> To: Gao, Liming ;
> leif.lindh...@linaro.org; Kinney, Michael D
> ; af...@apple.com; Cetola,
> Stephano 
> Cc: devel@edk2.groups.io; Shi, Steven
> ; Kuo, Donald
> ; Vitaly Cheptsov
> ; Dong, Eric
> 
> Subject: Re: Patch List for 201908 stable tag
> 
> On 08/16/19 10:00, Gao, Liming wrote:
> >
> > From: Gao, Liming [mailto:liming@intel.com]
> > Sent: Friday, August 16, 2019 3:59 PM
> > To: Laszlo Ersek (ler...@redhat.com)
> ;
> > leif.lindh...@linaro.org; Kinney, Michael D
> > ; af...@apple.com; Cetola,
> Stephano
> > 
> > Cc: edk2-de...@lists.01.org
> > Subject: Patch List for 201908 stable tag
> >
> > Hi Stewards and all:
> >   I collect current patch lists in devel mail list.
> Those patch contributors request to add them for 201908
> stable tag. Because the time is very close to Soft
> Feature Freeze, I want to collect your feedback for
> below patches.
> >
> > Feature List (those all have pass code review):
> > https://edk2.groups.io/g/devel/message/45734 [PATCH v6
> 0/5] Build
> > cache enhancement
> 
> Seems to be well documented (both in commit messages and
> in the BZ), and the series was approved by a BaseTools
> maintainer [1] before the soft feature freeze [2].
> 
> [1] https://edk2.groups.io/g/devel/message/45783
> [2] https://edk2.groups.io/g/devel/message/45806
> 
> The series can be pushed during the soft feature freeze,
> according to the current SFF definition.
> 
> Some requests regarding the bugzilla:
> 
> - Comment 0 in the bugzilla says "redesign the platform
> hash algorithm".
> I feel that would be better reflected if we changed the
> Product field to TianoCore Feature Requests.
> 
> - Please capture the v1..v6 cover letters, with mailing
> list archive links, in the bugzilla.
> 
> > https://edk2.groups.io/g/devel/message/45707 [PATCH]
> UefiCpuPkg:
> > Adding a new TSC library by using CPUID(0x15) TSC leaf
> 
> Accepted by a UefiCpuPkg maintainer [3] before the SFF
> [2].
> 
> [3] https://edk2.groups.io/g/devel/message/45787
> 
> Can be pushed during the soft feature freeze, according
> to the current SFF definition.
> 
> According to my comments sent earlier today for this
> series, the documentation and the bugzilla status are
> extremely lacking. I'm OK with pushing the series, but
> those aspects should be fixed in the bugzilla.
> Please see
> .
> 
> In addition, it appears multiple versions of the patch
> have been sent, without using "vN" identifiers in the
> subject prefix. Please collect all versions of the patch
> series from the mailing list archive, in chronological
> order, and link them all into the bugzilla ticket.
> 
> > https://edk2.groups.io/g/devel/message/45503 [PATCH v2
> 1/1] MdePkg:
> > Add STATIC_ASSERT macro
> 
> I commented on this today, as well:
> 
> 
> I disagree with the maintainer approval for this patch,
> from a reviewer perspective. I think the submission
> isn't complete enough / mature enough at this stage. The
> first version of the patch was posted on 12 Aug
> , as far
> as I can see.
> Why are we in a mortal hurry to add a central macro
> without any call sites in edk2 proper?
> 
> Anyway I'm not going to NACK the patch. If Mike is fine
> with the patch as-is, I'll live with that, with my
> disagreement noted.

I see there is another version sent out on Friday that includes
the usage.  We do need to make sure all the compiler we use
are compatible with this macro.  The one that may be a challenge
is EBC.

I think this is a valuable new feature, but I have not see 
The critical reason why this has to go in for the 201908
stable tag.  I would rather see it as one of the first 
item after the stable tag so it can get lots of flight 
time.

> 
> > Bug List:
> > https://edk2.groups.io/g/devel/message/45794  [PATCH
> 1/1] CryptoPkg:
> > Fix coding style
> 
> Purely from the subject line, looks like a bugfix, so no
> conflict with the *soft* feature freeze.

I agree.  Bug fix for 201908 stable tag.

> 
> > https://edk2.groups.io/g/devel/message/45791 [PATCH v2
> 1/1]
> > ShellPkg/UefiShellAcpiViewCommandLib: Replace shift
> logical left
> 
> Clearly a bugfix, so ditto.

I agree.  Bug fix for 201908 stable tag.

> 
> > https://edk2.groups.io/g/devel/message/45793 [Patch
> 1/1] BaseTools:
> > Fixed issue of incorrect Module Unique Name
> 
> Ditto.

I agree.  Bug fix for 201908 stable tag.

> 
> > https://edk2.groups.io/g/devel/message/45773 [Patch v4
> 0/6] Add "test
> > then write" mechanism
> 
> Sigh, this is a messy question.
> 
> To my eyes, this introduces a feature. The cover letter
> says "add ...
> mechanism". Even though it is used to fix a bug, it
> still introduces a new facility, in my opinion. So here
> I disagree with
> .
> 
> For 

Re: [edk2-devel] [edk2-platform patch 7/7] Platform/Intel: Add build option for SIMICS QSP Platform

2019-08-19 Thread Nate DeSimone
Hi David,

This patch no longer applies cleanly on the latest edk2-platforms master 
branch. In addition to addressing the review feedback I previously sent, please 
rebase your patch.

Thanks,
Nate

-Original Message-
From: Wei, David Y 
Sent: Friday, August 9, 2019 3:47 PM
To: devel@edk2.groups.io
Cc: Wu, Hao A ; Gao, Liming ; Sinha, 
Ankit ; Agyeman, Prince ; 
Kubacki, Michael A ; Desimone, Nathaniel L 
; Kinney, Michael D 
Subject: [edk2-platform patch 7/7] Platform/Intel: Add build option for SIMICS 
QSP Platform

Add build option in build script for SIMICS QSP Platform

Cc: Hao Wu 
Cc: Liming Gao 
Cc: Ankit Sinha 
Cc: Agyeman Prince 
Cc: Kubacki Michael A 
Cc: Nate DeSimone 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: David Wei 
---
 Platform/Intel/build.cfg | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Platform/Intel/build.cfg b/Platform/Intel/build.cfg index 
fc6e4fe824..2ebe09a632 100644
--- a/Platform/Intel/build.cfg
+++ b/Platform/Intel/build.cfg
@@ -54,3 +54,5 @@ NUMBER_OF_PROCESSORS = 0
 KabylakeRvp3 = KabylakeOpenBoardPkg/KabylakeRvp3/build_config.cfg
 N1xxWU = ClevoOpenBoardPkg/N1xxWU/build_config.cfg
 BoardMtOlympus = PurleyOpenBoardPkg/BoardMtOlympus/build_config.cfg
+WhiskeylakeURvp = 
+WhiskeylakeOpenBoardPkg/WhiskeylakeURvp/build_config.cfg
+BoardX58ICH10 = SimicsOpenBoardPkg/BoardX58ICH10/build_config.cfg
--
2.16.2.windows.1


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

View/Reply Online (#46059): https://edk2.groups.io/g/devel/message/46059
Mute This Topic: https://groups.io/mt/32816101/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] Patch List for 201908 stable tag

2019-08-19 Thread Ni, Ray
All stewards,
Though it was already listed by Liming, I would like explicitly ask for 
including below changes in the coming stable tag:
https://edk2.groups.io/g/devel/message/45773 [Patch v4 0/6] Add "test then 
write" mechanism

The whole patches had gone through 4 rounds of review process while I was away.
I had a deep look at the whole changes and all look very good. (except a minor 
copyright year issue in the 6/6 patch.)


Thanks,
Ray

From: devel@edk2.groups.io  On Behalf Of Liming Gao
Sent: Friday, August 16, 2019 1:01 AM
To: Gao, Liming ; Laszlo Ersek (ler...@redhat.com) 
; leif.lindh...@linaro.org; Kinney, Michael D 
; af...@apple.com; Cetola, Stephano 

Cc: devel@edk2.groups.io
Subject: Re: [edk2-devel] Patch List for 201908 stable tag


From: Gao, Liming [mailto:liming@intel.com]
Sent: Friday, August 16, 2019 3:59 PM
To: Laszlo Ersek (ler...@redhat.com) 
mailto:ler...@redhat.com>>; 
leif.lindh...@linaro.org; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>; 
af...@apple.com; Cetola, Stephano 
mailto:stephano.cet...@intel.com>>
Cc: edk2-de...@lists.01.org
Subject: Patch List for 201908 stable tag

Hi Stewards and all:
  I collect current patch lists in devel mail list. Those patch contributors 
request to add them for 201908 stable tag. Because the time is very close to 
Soft Feature Freeze, I want to collect your feedback for below patches.

Feature List (those all have pass code review):
https://edk2.groups.io/g/devel/message/45734 [PATCH v6 0/5] Build cache 
enhancement
https://edk2.groups.io/g/devel/message/45707 [PATCH] UefiCpuPkg: Adding a new 
TSC library by using CPUID(0x15) TSC leaf
https://edk2.groups.io/g/devel/message/45503 [PATCH v2 1/1] MdePkg: Add 
STATIC_ASSERT macro

Bug List:
https://edk2.groups.io/g/devel/message/45794  [PATCH 1/1] CryptoPkg: Fix coding 
style
https://edk2.groups.io/g/devel/message/45791 [PATCH v2 1/1] 
ShellPkg/UefiShellAcpiViewCommandLib: Replace shift logical left
https://edk2.groups.io/g/devel/message/45793 [Patch 1/1] BaseTools: Fixed issue 
of incorrect Module Unique Name
https://edk2.groups.io/g/devel/message/45773 [Patch v4 0/6] Add "test then 
write" mechanism
https://edk2.groups.io/g/devel/message/45317 [Patch] MdeModulePkg DxeCore: Fix 
for missing MAT update

Thanks
Liming


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

View/Reply Online (#46058): https://edk2.groups.io/g/devel/message/46058
Mute This Topic: https://groups.io/mt/32896302/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [Patch v4 0/6] Add "test then write" mechanism

2019-08-19 Thread Ni, Ray
Eric,
The whole patch series are very clean and easy to understand.

Reviewed-by: Ray Ni 


> -Original Message-
> From: Dong, Eric
> Sent: Thursday, August 15, 2019 8:57 PM
> To: devel@edk2.groups.io
> Cc: Ni, Ray ; Laszlo Ersek 
> Subject: [Patch v4 0/6] Add "test then write" mechanism
> 
> v4 changes:
> 1. Split Reserved field and use one byte as TestThenWrite field.
> 
> v3 changes:
> 1. Avoid changing exist API CpuRegisterTableWrite, add new API 
> CpuRegisterTableTestThenWrite which align new adds macros.
> Only 1/6 patch been changed in v3.
> 
> V2 changes:
> 1. Split CR read/write action in to one discrete patch 2. Keep the old logic 
> which continue the process if error found.
> 
> Below code is current implementation:
>   if (MsrRegister[ProcessorNumber].Bits.Lock == 0) {
> CPU_REGISTER_TABLE_WRITE_FIELD (
>   ProcessorNumber,
>   Msr,
>   MSR_IA32_FEATURE_CONTROL,
>   MSR_IA32_FEATURE_CONTROL_REGISTER,
>   Bits.Lock,
>   1
> );
>   }
> 
> With below steps, the Bits.Lock bit will lose its value:
> 1. Trig normal boot, the Bits.Lock is 0. 1 will be added
>into the register table and then will set to the MSR.
> 2. Trig warm reboot, MSR value preserves. After normal boot phase,
>the Bits.Lock is 1, so it will not be added into the register
>table during the warm reboot phase.
> 3. Trig S3 then resume, the Bits.Lock change to 0 and Bits.Lock is
>not added in register table during normal boot phase. so it's
>still 0 after resume.
> This is not an expect behavior. The expect result is the value should always 
> 1 after booting or resuming from S3.
> 
> The root cause for this issue is
> 1. driver bases on current value to insert the "set value action" to
>the register table.
> 2. Some MSRs may reserve their value during warm reboot. So the insert
>action may be skip after warm reboot.
> 
> The solution for this issue is:
> 1. Always add "Test then Set" action for above referred MSRs.
> 2. Detect current value before set new value. Only set new value when
>current value not same as new value.
> 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> 
> 
> Eric Dong (6):
>   UefiCpuPkg/RegisterCpuFeaturesLib: Add "Test Then Write" Macros.
>   UefiCpuPkg/PiSmmCpuDxeSmm: Combine CR read/write action.
>   UefiCpuPkg/PiSmmCpuDxeSmm: Supports test then write new value logic.
>   UefiCpuPkg/RegisterCpuFeaturesLib: Combine CR read/write action.
>   UefiCpuPkg/RegisterCpuFeaturesLib: Supports test then write new value
> logic.
>   UefiCpuPkg/CpuCommonFeaturesLib: Use new macros.
> 
>  UefiCpuPkg/Include/AcpiCpuData.h  |   1 +
>  .../Include/Library/RegisterCpuFeaturesLib.h  |  91 +++
>  .../CpuCommonFeaturesLib/CpuCommonFeatures.h  |  15 --
>  .../CpuCommonFeaturesLib.c|   8 +-
>  .../CpuCommonFeaturesLib/FeatureControl.c | 141 ++
>  .../CpuCommonFeaturesLib/MachineCheck.c   |  23 ++-
>  .../CpuFeaturesInitialize.c   | 139 +++--
>  .../RegisterCpuFeaturesLib.c  |  45 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c | 133 +++--
>  9 files changed, 375 insertions(+), 221 deletions(-)
> 
> --
> 2.21.0.windows.1


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

View/Reply Online (#46057): https://edk2.groups.io/g/devel/message/46057
Mute This Topic: https://groups.io/mt/32894957/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [edk2-platforms] Update Intel Packages on Bugzilla

2019-08-19 Thread Michael D Kinney
Done.

Mike

> -Original Message-
> From: Kinney, Michael D
> Sent: Monday, August 19, 2019 3:39 PM
> To: Kubacki, Michael A ;
> devel@edk2.groups.io; Kinney, Michael D
> 
> Cc: Dong, Eric ; Gao, Liming
> ; Bi, Dandan ;
> Chiu, Chasel ; Desimone, Nathaniel
> L ; Chaganty, Rangasai V
> ; Piwko, Maciej
> ; Bu, Daocheng
> ; Oram, Isaac W
> ; Gillispie, Thad
> 
> Subject: RE: [edk2-platforms] Update Intel Packages on
> Bugzilla
> 
> Michael,
> 
> I agree.  I will add these packages that have already
> been approved and added to edk2-platforms/master.
> 
> Mike
> 
> > -Original Message-
> > From: Kubacki, Michael A
> > Sent: Monday, August 19, 2019 2:57 PM
> > To: devel@edk2.groups.io
> > Cc: Kinney, Michael D ;
> Dong, Eric
> > ; Gao, Liming
> ; Bi, Dandan
> > ; Chiu, Chasel
> ; Desimone,
> > Nathaniel L ; Chaganty,
> Rangasai V
> > ; Piwko, Maciej
> > ; Bu, Daocheng
> ; Oram,
> > Isaac W ; Gillispie, Thad
> > 
> > Subject: [edk2-platforms] Update Intel Packages on
> Bugzilla
> >
> > Hi Mike,
> >
> > Within the "EDK2 Platforms" product on Bugzilla, the
> following Intel
> > packages are missing:
> >   * BoardModulePkg (edk2-
> > platforms/Platform/Intel/BoardModulePkg)
> >   * DebugFeaturePkg (edk2-
> > platforms/Platform/Intel/DebugFeaturePkg)
> >   * UserInterfaceFeaturePkg (edk2-
> > platforms/Platform/Intel/UserInterfaceFeaturePkg)
> >   * WhiskeylakeOpenBoardPkg (edk2-
> > platforms/Platform/Intel/WhiskeylakeOpenBoardPkg)
> >
> >   * CoffelakeSiliconPkg (edk2-
> > platforms/Silicon/Intel/CoffeelakeSiliconPkg)
> >   * KabylakeSiliconPkg (edk2-
> > platforms/Silicon/Intel/KabylakeSiliconPkg)
> >   * LewisburgPkg (edk2-
> > platforms/Silicon/Intel/LewisburgPkg)
> >   * PurleyRcPkg (edk2-
> > platforms/Silicon/Intel/PurleyRcPkg)
> >   * PurleySktPkg (edk2-
> > platforms/Silicon/Intel/PurleySktPkg)
> >
> > These packages need the ability to have feature
> requests and bugs
> > submitted against the package.
> >
> > I'd like to propose these packages be added to the EDK2
> Platforms
> > product on Bugzilla.
> >
> > Thanks,
> > Michael


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

View/Reply Online (#46056): https://edk2.groups.io/g/devel/message/46056
Mute This Topic: https://groups.io/mt/32960925/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [edk2-platforms] Update Intel Packages on Bugzilla

2019-08-19 Thread Michael D Kinney
Michael,

I agree.  I will add these packages that have already been approved and added 
to edk2-platforms/master.

Mike

> -Original Message-
> From: Kubacki, Michael A
> Sent: Monday, August 19, 2019 2:57 PM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ;
> Dong, Eric ; Gao, Liming
> ; Bi, Dandan
> ; Chiu, Chasel
> ; Desimone, Nathaniel L
> ; Chaganty, Rangasai V
> ; Piwko, Maciej
> ; Bu, Daocheng
> ; Oram, Isaac W
> ; Gillispie, Thad
> 
> Subject: [edk2-platforms] Update Intel Packages on
> Bugzilla
> 
> Hi Mike,
> 
> Within the "EDK2 Platforms" product on Bugzilla, the
> following Intel packages are missing:
>   * BoardModulePkg (edk2-
> platforms/Platform/Intel/BoardModulePkg)
>   * DebugFeaturePkg (edk2-
> platforms/Platform/Intel/DebugFeaturePkg)
>   * UserInterfaceFeaturePkg (edk2-
> platforms/Platform/Intel/UserInterfaceFeaturePkg)
>   * WhiskeylakeOpenBoardPkg (edk2-
> platforms/Platform/Intel/WhiskeylakeOpenBoardPkg)
> 
>   * CoffelakeSiliconPkg (edk2-
> platforms/Silicon/Intel/CoffeelakeSiliconPkg)
>   * KabylakeSiliconPkg (edk2-
> platforms/Silicon/Intel/KabylakeSiliconPkg)
>   * LewisburgPkg (edk2-
> platforms/Silicon/Intel/LewisburgPkg)
>   * PurleyRcPkg (edk2-
> platforms/Silicon/Intel/PurleyRcPkg)
>   * PurleySktPkg (edk2-
> platforms/Silicon/Intel/PurleySktPkg)
> 
> These packages need the ability to have feature
> requests and bugs submitted against the package.
> 
> I'd like to propose these packages be added to the EDK2
> Platforms product on Bugzilla.
> 
> Thanks,
> Michael


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

View/Reply Online (#46055): https://edk2.groups.io/g/devel/message/46055
Mute This Topic: https://groups.io/mt/32960925/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [edk2-platforms: PATCH v2] Python run fail if env variable PYTHON_HOME is not set

2019-08-19 Thread Kubacki, Michael A
Reviewed-by: Michael Kubacki 

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Cheng, Ching JenX
> Sent: Monday, August 19, 2019 2:24 AM
> To: devel@edk2.groups.io
> Cc: Chan, Amy ; Kubacki, Michael A
> ; Chiu, Chasel ;
> Desimone, Nathaniel L ; Gao, Liming
> 
> Subject: [edk2-devel] [edk2-platforms: PATCH v2] Python run fail if env 
> variable
> PYTHON_HOME is not set
> 
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2041
> 
> [PATCH v2] Update related files
> 
> In Platform\Intel\MinPlatformPkg\Tools\Fsp\RebaseFspBinBaseAddress.py
> It will run another python code.
> But if the environment variable "PYTHON_HOME" is not exist and we didn't add
> any python's path to "PATH".
> It will cause error because python command not found.
> 
> the error message as below:
> 'python' is not recognized as an internal or external command, operable
> program or batch file.
> 
> So we set the python's path from which execute the python code if
> PYTHON_HOME was not exist.
> 
> Cc: Amy Chan 
> Cc: Michael Kubacki 
> Cc: Chasel Chiu 
> Cc: Nate DeSimone 
> Cc: Liming Gao 
> Signed-off-by: Ching JenX Cheng 
> ---
>  Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseFspBinBaseAddress.py | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git
> a/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseFspBinBaseAddress.py
> b/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseFspBinBaseAddress.py
> index a8165b08e6..fb4cf4f9b7 100644
> --- a/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseFspBinBaseAddress.py
> +++ b/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseFspBinBaseAddress.py
> @@ -68,6 +68,8 @@ file.close()
>  pythontool = 'python'
>  if 'PYTHON_HOME' in os.environ:
>  pythontool = os.environ['PYTHON_HOME'] + os.sep + 'python'
> +else:
> +pythontool = sys.executable
>  Process = subprocess.Popen([pythontool, splitFspBinPath, "info","-
> f",fspBinFilePath], stdout=subprocess.PIPE)  Output =
> Process.communicate()[0]  FsptInfo = Output.rsplit(b"FSP_M", 1);
> --
> 2.21.0.windows.1
> 
> 
> 


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

View/Reply Online (#46054): https://edk2.groups.io/g/devel/message/46054
Mute This Topic: https://groups.io/mt/32942124/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [edk2-platforms] Update Intel Packages on Bugzilla

2019-08-19 Thread Kubacki, Michael A
Hi Mike,

Within the "EDK2 Platforms" product on Bugzilla, the following Intel packages 
are missing:
  * BoardModulePkg (edk2-platforms/Platform/Intel/BoardModulePkg)
  * DebugFeaturePkg (edk2-platforms/Platform/Intel/DebugFeaturePkg)
  * UserInterfaceFeaturePkg 
(edk2-platforms/Platform/Intel/UserInterfaceFeaturePkg)
  * WhiskeylakeOpenBoardPkg 
(edk2-platforms/Platform/Intel/WhiskeylakeOpenBoardPkg)

  * CoffelakeSiliconPkg (edk2-platforms/Silicon/Intel/CoffeelakeSiliconPkg)
  * KabylakeSiliconPkg (edk2-platforms/Silicon/Intel/KabylakeSiliconPkg)
  * LewisburgPkg (edk2-platforms/Silicon/Intel/LewisburgPkg)
  * PurleyRcPkg (edk2-platforms/Silicon/Intel/PurleyRcPkg)
  * PurleySktPkg (edk2-platforms/Silicon/Intel/PurleySktPkg)

These packages need the ability to have feature requests and bugs submitted 
against the package.

I'd like to propose these packages be added to the EDK2 Platforms product on 
Bugzilla.

Thanks,
Michael


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

View/Reply Online (#46053): https://edk2.groups.io/g/devel/message/46053
Mute This Topic: https://groups.io/mt/32960925/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [RFC PATCH 08/28] MdePkg/BaseLib: Implement the VMGEXIT support

2019-08-19 Thread Ni, Ray
Tom,
1. It's not a common practice to have static inline functions defined in header 
file. Who is going to call them?
2. Recently I made a change to move the AMD registers definitions to 
MdePkg/Include/Register/Amd from UefiCpuPkg. Do you think that's a good idea 
and can you please put your new register definitions to MdePkg as well?
3. What happens if the "rep; vmmcall" is executed in Intel processor?

Thanks,
Ray

> -Original Message-
> From: Lendacky, Thomas 
> Sent: Monday, August 19, 2019 2:36 PM
> To: devel@edk2.groups.io
> Cc: Justen, Jordan L ; Laszlo Ersek 
> ; Ard Biesheuvel
> ; Kinney, Michael D ; 
> Gao, Liming ; Dong,
> Eric ; Ni, Ray ; Singh, Brijesh 
> 
> Subject: [RFC PATCH 08/28] MdePkg/BaseLib: Implement the VMGEXIT support
> 
> From: Tom Lendacky 
> 
> VMGEXIT is a new instruction used for Hypervisor/Guest communication when
> running as an SEV-ES guest. A VMGEXIT will cause an automatic exit (AE)
> to occur, resulting in a #VMEXIT with an exit code value of 0x403.
> 
> To support VMGEXIT, define the VMGEXIT assember routine to issue the
> instruction (rep; vmmcall), the GHCB structure and some helper functions
> for communicating register information to and from the hypervisor and the
> guest.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  MdePkg/Library/BaseLib/BaseLib.inf  |   1 +
>  MdePkg/Include/Library/BaseLib.h|  14 ++
>  UefiCpuPkg/Include/Register/Amd/Ghcb.h  | 197 
>  MdePkg/Library/BaseLib/X64/GccInline.c  |  17 ++
>  MdePkg/Library/BaseLib/X64/VmgExit.nasm |  38 +
>  5 files changed, 267 insertions(+)
>  create mode 100644 UefiCpuPkg/Include/Register/Amd/Ghcb.h
>  create mode 100644 MdePkg/Library/BaseLib/X64/VmgExit.nasm
> 
> diff --git a/MdePkg/Library/BaseLib/BaseLib.inf 
> b/MdePkg/Library/BaseLib/BaseLib.inf
> index 3586beb0ab5c..a41401340f95 100644
> --- a/MdePkg/Library/BaseLib/BaseLib.inf
> +++ b/MdePkg/Library/BaseLib/BaseLib.inf
> @@ -286,6 +286,7 @@ [Sources.X64]
>X64/ReadCr2.nasm| MSFT
>X64/ReadCr0.nasm| MSFT
>X64/ReadEflags.nasm| MSFT
> +  X64/VmgExit.nasm | MSFT
> 
> 
>X64/Non-existing.c
> diff --git a/MdePkg/Include/Library/BaseLib.h 
> b/MdePkg/Include/Library/BaseLib.h
> index 2a75bc023f56..80bd5cf57a72 100644
> --- a/MdePkg/Include/Library/BaseLib.h
> +++ b/MdePkg/Include/Library/BaseLib.h
> @@ -7880,6 +7880,20 @@ AsmLfence (
>VOID
>);
> 
> +/**
> +  Executes a VMGEXIT instruction (VMMCALL with a REP prefix)
> +
> +  Executes a VMGEXIT instruction. This function is only available on IA-32 
> and
> +  x64.
> +
> +**/
> +VOID
> +EFIAPI
> +AsmVmgExit (
> +  VOID
> +  );
> +
> +
>  /**
>Patch the immediate operand of an IA32 or X64 instruction such that the 
> byte,
>word, dword or qword operand is encoded at the end of the instruction's
> diff --git a/UefiCpuPkg/Include/Register/Amd/Ghcb.h 
> b/UefiCpuPkg/Include/Register/Amd/Ghcb.h
> new file mode 100644
> index ..e9fd116fac25
> --- /dev/null
> +++ b/UefiCpuPkg/Include/Register/Amd/Ghcb.h
> @@ -0,0 +1,197 @@
> +
> +#ifndef __GHCB_H__
> +#define __GHCB_H__
> +
> +#include 
> +#include 
> +#include 
> +
> +#define UD_EXCEPTION  6
> +#define GP_EXCEPTION 13
> +
> +#define GHCB_VERSION_MIN 1
> +#define GHCB_VERSION_MAX 1
> +
> +#define GHCB_STANDARD_USAGE  0
> +
> +typedef enum {
> +  SvmExitDr7Read   = 0x27,
> +  SvmExitDr7Write  = 0x37,
> +  SvmExitRdtsc = 0x6E,
> +  SvmExitRdpmc,
> +  SvmExitCpuid = 0x72,
> +  SvmExitInvd  = 0x76,
> +  SvmExitIoioProt  = 0x7B,
> +  SvmExitMsr,
> +  SvmExitVmmCall   = 0x81,
> +  SvmExitRdtscp= 0x87,
> +  SvmExitWbinvd= 0x89,
> +  SvmExitMonitor,
> +  SvmExitMwait,
> +  SvmExitNpf   = 0x400,
> +
> +  // VMG special exits
> +  SvmExitMmioRead  = 0x8001,
> +  SvmExitMmioWrite,
> +  SvmExitNmiComplete,
> +  SvmExitApResetHold,
> +
> +  SvmExitUnsupported   = 0x8000,
> +} SVM_EXITCODE;
> +
> +typedef enum {
> +  GhcbCpl  = 25,
> +  GhcbRflags   = 46,
> +  GhcbRip,
> +  GhcbRsp  = 59,
> +  GhcbRax  = 63,
> +  GhcbRcx  = 97,
> +  GhcbRdx,
> +  GhcbRbx,
> +  GhcbRbp  = 101,
> +  GhcbRsi,
> +  GhcbRdi,
> +  GhcbR8,
> +  GhcbR9,
> +  GhcbR10,
> +  GhcbR11,
> +  GhcbR12,
> +  GhcbR13,
> +  GhcbR14,
> +  GhcbR15,
> +  GhcbXCr0 = 125,
> +} GHCB_REGISTER;
> +
> +typedef struct {
> +  UINT8  Reserved1[203];
> +  UINT8  Cpl;
> +  UINT8  Reserved2[148];
> +  UINT64 Dr7;
> +  UINT8  Reserved3[144];
> +  UINT64 Rax;
> +  UINT8  Reserved4[264];
> +  UINT64 Rcx;
> +  UINT64 Rdx;
> +  UINT64 Rbx;
> +  UINT8  Reserved5[112];
> +  UINT64 SwExitCode;
> +  UINT64 SwExitInfo1;
> +  UINT64 SwExitInfo2;
> +  UINT64 

Re: [edk2-devel] [edk2-platforms: PATCH v2] Python run fail if env variable PYTHON_HOME is not set

2019-08-19 Thread Nate DeSimone
Reviewed-by: Nate DeSimone 

-Original Message-
From: Cheng, Ching JenX 
Sent: Monday, August 19, 2019 2:24 AM
To: devel@edk2.groups.io
Cc: Chan, Amy ; Kubacki, Michael A 
; Chiu, Chasel ; Desimone, 
Nathaniel L ; Gao, Liming 
Subject: [edk2-platforms: PATCH v2] Python run fail if env variable PYTHON_HOME 
is not set

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

[PATCH v2] Update related files

In Platform\Intel\MinPlatformPkg\Tools\Fsp\RebaseFspBinBaseAddress.py
It will run another python code.
But if the environment variable "PYTHON_HOME" is not exist and we didn't add 
any python's path to "PATH".
It will cause error because python command not found.

the error message as below:
'python' is not recognized as an internal or external command, operable program 
or batch file.

So we set the python's path from which execute the python code if PYTHON_HOME 
was not exist.

Cc: Amy Chan 
Cc: Michael Kubacki 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Signed-off-by: Ching JenX Cheng 
---
 Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseFspBinBaseAddress.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseFspBinBaseAddress.py 
b/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseFspBinBaseAddress.py
index a8165b08e6..fb4cf4f9b7 100644
--- a/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseFspBinBaseAddress.py
+++ b/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseFspBinBaseAddress.py
@@ -68,6 +68,8 @@ file.close()
 pythontool = 'python'
 if 'PYTHON_HOME' in os.environ:
 pythontool = os.environ['PYTHON_HOME'] + os.sep + 'python'
+else:
+pythontool = sys.executable
 Process = subprocess.Popen([pythontool, splitFspBinPath, 
"info","-f",fspBinFilePath], stdout=subprocess.PIPE)  Output = 
Process.communicate()[0]  FsptInfo = Output.rsplit(b"FSP_M", 1);
--
2.21.0.windows.1


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

View/Reply Online (#46051): https://edk2.groups.io/g/devel/message/46051
Mute This Topic: https://groups.io/mt/32942124/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] BaseTools/BinWrappers question?

2019-08-19 Thread Andrew Fish via Groups.Io



> On Aug 19, 2019, at 6:09 AM, Liming Gao  wrote:
> 
> Andrew:
>  This is the history reason. Before, Edk2 BaseTools included the binary 
> Windows tools in BaseTools\Bin\Win32. There is no 
> BaseTools/BinWrappers/WindowsLike directory. 
> 
>  When migrate BaseTools Windows tools from binary to source build, Edk2 
> BaseTools C source is still compiled to BaseTools\Bin\Win32 directory. 
> Because BaseTools\Bin\Win32 is set into system PATH env, there is no 
> requirement to add their wrapper scripts in BaseTools/BinWrappers/WindowsLike 
> directory.
> 

Liming,

Thanks for the answer, I was guessing it was related to the history difference 
with the tools. 

I ran some experiments years ago and calling the C function through the bash 
script seemed to take up 5% of the build time. Would it make sense to use a 
path for Unix builds too vs. the wrappers? 

Thanks,

Andrew Fish

> Thanks
> Liming
>> -Original Message-
>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Andrew 
>> Fish via Groups.Io
>> Sent: Saturday, August 17, 2019 1:01 AM
>> To: devel@edk2.groups.io
>> Subject: [edk2-devel] BaseTools/BinWrappers question?
>> 
>> Why does BaseTools/BinWrappers/WindowsLike only have wrappers for Python 
>> commands, while  BaseTools/BinWrappers/PosixLike has
>> wrappers for C based tools too?
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
> 
> 
> 
> 


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

View/Reply Online (#46050): https://edk2.groups.io/g/devel/message/46050
Mute This Topic: https://groups.io/mt/32900805/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] Patch List for 201908 stable tag

2019-08-19 Thread Ni, Ray
Liming,
Below patch already got the reviewed-by tag before the freezing point. Can I 
push it now?

https://edk2.groups.io/g/devel/topic/32737146 UefiCpuPkg/PiSmmCpuDxeSmm: don't 
free page table pages that are required to handle current page fault

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

View/Reply Online (#46047): https://edk2.groups.io/g/devel/message/46047
Mute This Topic: https://groups.io/mt/32896302/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [edk2-platforms: PATCH v2 03/10] Marvell/Cn9130Db: Add DeviceTree

2019-08-19 Thread Leif Lindholm
+Stewards (don't panic!)

On Fri, Aug 16, 2019 at 11:03:42PM +0200, Marcin Wojtas wrote:
> Hi Leif,
> 
> pt., 16 sie 2019 o 19:10 Leif Lindholm  napisał(a):
> >
> > On Thu, Aug 15, 2019 at 04:54:07AM +0200, Marcin Wojtas wrote:
> > > This patch adds device tree sources which are common for Cn913x SoCs
> > > and the CN9130 development board (variant A). Wiring up of support
> > > will be done in the follow-up commits.
> > >
> > > Signed-off-by: Marcin Wojtas 
> >
> > Again, I've not reviewed the contents extensively, *but* this patch
> > cannot go into edk2-platforms - it has GPL licensed content.
> > Was it meant for edk2-non-osi? Because we could take it there.
> 
> Thanks for catching this - my oversight. The top-level DT files should
> also be dual licenced (GPL2.0/MIT), same as recently submitted to
> Linux. So IMO no need to go for edk2-non-osi.

Right. MIT *is* an acceptable license, but no other licenses than
BSD+Patent are blanket approved - it's a case by case basis.

We still have a gap with regards to the explicit patent grant since
the dropping of the TianoCore Contribution Agreement. While this is
less problematic for something like .dts files, I don't think it can
be argued that the problem does not exist for them.

My preference for resolving this would be that anything merged into
!edk2-non-osi (and, yes, we really ought to create an
edk2-other-license or whatever) needs to use a license compatible with
BSD+Patent (MIT is) and is registered as:

SPDX-License-Identifier: BSD-2-Clause-Patent AND 

TL;DR: if you want to get the set merged quickly, edk2-non-osi is the
best route for these files.

Best Regards,

Leif


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

View/Reply Online (#46046): https://edk2.groups.io/g/devel/message/46046
Mute This Topic: https://groups.io/mt/32882735/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [edk2-platforms: PATCH v2 10/10] Marvell/Drivers: SmbiosPlatformDxe: Use more generic board name

2019-08-19 Thread Leif Lindholm
On Fri, Aug 16, 2019 at 10:57:22PM +0200, Marcin Wojtas wrote:
> Hi Leif,
> 
> pt., 16 sie 2019 o 19:41 Leif Lindholm  napisał(a):
> >
> > On Thu, Aug 15, 2019 at 04:54:14AM +0200, Marcin Wojtas wrote:
> > > SmbiosPlatformDxe is used both by Armada 7k8k and CN913x platforms.
> > > Replace board name placeholder in order to avoid confusion.
> >
> > Stupid/lazy question - do we already specify the actual platform name
> > elsewhere?
> 
> No. My plan is to enable SMBIOS customization via board description
> library / protocol. I just came up on an easy idea to use PCD for
> platform name. If that's ok for you, I'll refactor to it in v2.

Yes, that sounds ideal, thanks!

Best Regards,

Leif

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

View/Reply Online (#46045): https://edk2.groups.io/g/devel/message/46045
Mute This Topic: https://groups.io/mt/32882743/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [Patch V5 00/11] EmulatorPkg: Fix VS20xx IA32 boot and simplify build config

2019-08-19 Thread Michael D Kinney
Hi Jordan,

Thank you for the reviews.  I have addressed the two issues 
you raised in my local branch and I verified that the lldbefi.py
script behaves the same after breaking up the long line.

Best regards,

Mike


> -Original Message-
> From: Justen, Jordan L
> Sent: Sunday, August 18, 2019 7:43 PM
> To: Kinney, Michael D ;
> devel@edk2.groups.io
> Cc: Andrew Fish ; Ni, Ray
> 
> Subject: Re: [Patch V5 00/11] EmulatorPkg: Fix VS20xx
> IA32 boot and simplify build config
> 
> On 2019-08-16 17:57:04, Michael D Kinney wrote:
> >
> > Andrew Fish (7):
> >   EmulatorPkg/Unix/Host: Disable inline/optimizations
> 
> Maybe add XCODE5 in commit message subject?
> 
> Acked-by: Jordan Justen 
> 
> >   EmulatorPkg: Fix XCODE5 lldb issues
> 
> There was another long line in the
> EmulatorPkg/Unix/lldbefi.py change.
> 
> Acked-by: Jordan Justen 
> 
> >   EmulatorPkg/Unix/Host: Initialize field in
> BerkeleyPacketFilter.c
> 
> Reviewed-by: Jordan Justen 
> 
> >   EmulatorPkg/Unix/Host: Remove debug code from
> BerkeleyPacketFilter.c
> 
> Reviewed-by: Jordan Justen 
> 
> >   EmulatorPkg: Disable TftpDynamicCommand and LogoDxe
> for XCODE5
> 
> Acked-by: Jordan Justen 
> 
> >   EmulatorPkg/Sec: Change scope of PpiArray[10]
> 
> Reviewed-by: Jordan Justen 
> 
> >   BaseTools/tools_def.template: Add -gdwarf to XCODE5
> X64
> 
> Acked-by: Jordan Justen 

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

View/Reply Online (#46044): https://edk2.groups.io/g/devel/message/46044
Mute This Topic: https://groups.io/mt/32918474/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

2019-08-19 Thread Paolo Bonzini
On 19/08/19 01:00, Yao, Jiewen wrote:
> in real world, we deprecate AB-seg usage because they are vulnerable
> to smm cache poison attack. I assume cache poison is out of scope in
> the virtual world, or there is a way to prevent ABseg cache poison.

Indeed the SMRR would not cover the A-seg on real hardware.  However, if
the chipset allowed aliasing A-seg SMRAM to 0x3, it would only be
used for SMBASE relocation of hotplugged CPU.  The firmware would still
keep low SMRAM disabled, *except around SMBASE relocation of hotplugged
CPUs*.  To avoid cache poisoning attacks, you only have to issue a
WBINVD before enabling low SMRAM and before disabling it.  Hotplug SMI
is not a performance-sensitive path, so it's not a big deal.

So I guess you agree that PCI DMA attacks are a potential vector also on
real hardware.  As Alex pointed out, VT-d is not a solution because
there could be legitimate DMA happening during CPU hotplug.  For OVMF
we'll probably go with Igor's idea, it would be nice if Intel chipsets
supported it too. :)

Paolo

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

View/Reply Online (#46043): https://edk2.groups.io/g/devel/message/46043
Mute This Topic: https://groups.io/mt/32852911/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [edk2] If use prebuild tools, not need install python 2.7 anymore?

2019-08-19 Thread Liming Gao
Now, edk2 stable tag release is 
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning

After edk2-stable201903 tag, edk2 supports Python3. User needs to install 
Python3.x, doesn’t need to set PYTHON path.

Thanks
Liming
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Tiger 
Liu(BJ-RD)
Sent: Monday, August 19, 2019 4:56 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] [edk2] If use prebuild tools, not need install python 2.7 
anymore?

Hello,
I have a question about needing install python 2.7

If user wants to setup udk compiling environment, he needs install python 2.7.
When running build command every time, it always check python tool path.
Why?

If I compiled basetools before, and use the prebuilt basetools package, then I 
don’t need install python 2.7 package?

Thanks


保密声明:
本邮件含有保密或专有信息,仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for 
the sole use of its intended recipient. Any unauthorized review, use, copying 
or forwarding of this email or the content of this email is strictly prohibited.


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

View/Reply Online (#46042): https://edk2.groups.io/g/devel/message/46042
Mute This Topic: https://groups.io/mt/32943095/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] BaseTools/BinWrappers question?

2019-08-19 Thread Liming Gao
Andrew:
  This is the history reason. Before, Edk2 BaseTools included the binary 
Windows tools in BaseTools\Bin\Win32. There is no 
BaseTools/BinWrappers/WindowsLike directory. 

  When migrate BaseTools Windows tools from binary to source build, Edk2 
BaseTools C source is still compiled to BaseTools\Bin\Win32 directory. Because 
BaseTools\Bin\Win32 is set into system PATH env, there is no requirement to add 
their wrapper scripts in BaseTools/BinWrappers/WindowsLike directory.

Thanks
Liming
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Andrew 
> Fish via Groups.Io
> Sent: Saturday, August 17, 2019 1:01 AM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] BaseTools/BinWrappers question?
> 
> Why does BaseTools/BinWrappers/WindowsLike only have wrappers for Python 
> commands, while  BaseTools/BinWrappers/PosixLike has
> wrappers for C based tools too?
> 
> Thanks,
> 
> Andrew Fish
> 


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

View/Reply Online (#46041): https://edk2.groups.io/g/devel/message/46041
Mute This Topic: https://groups.io/mt/32900805/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [edk2-platforms: PATCH v2] Python run fail if env variable PYTHON_HOME is not set

2019-08-19 Thread Chiu, Chasel


Reviewed-by: Chasel Chiu 

> -Original Message-
> From: Cheng, Ching JenX
> Sent: Monday, August 19, 2019 5:24 PM
> To: devel@edk2.groups.io
> Cc: Chan, Amy ; Kubacki, Michael A
> ; Chiu, Chasel ;
> Desimone, Nathaniel L ; Gao, Liming
> 
> Subject: [edk2-platforms: PATCH v2] Python run fail if env variable
> PYTHON_HOME is not set
> 
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2041
> 
> [PATCH v2] Update related files
> 
> In Platform\Intel\MinPlatformPkg\Tools\Fsp\RebaseFspBinBaseAddress.py
> It will run another python code.
> But if the environment variable "PYTHON_HOME" is not exist and we didn't
> add any python's path to "PATH".
> It will cause error because python command not found.
> 
> the error message as below:
> 'python' is not recognized as an internal or external command, operable
> program or batch file.
> 
> So we set the python's path from which execute the python code if
> PYTHON_HOME was not exist.
> 
> Cc: Amy Chan 
> Cc: Michael Kubacki 
> Cc: Chasel Chiu 
> Cc: Nate DeSimone 
> Cc: Liming Gao 
> Signed-off-by: Ching JenX Cheng 
> ---
>  Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseFspBinBaseAddress.py | 2
> ++
>  1 file changed, 2 insertions(+)
> 
> diff --git
> a/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseFspBinBaseAddress.py
> b/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseFspBinBaseAddress.py
> index a8165b08e6..fb4cf4f9b7 100644
> --- a/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseFspBinBaseAddress.py
> +++
> b/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseFspBinBaseAddress.py
> @@ -68,6 +68,8 @@ file.close()
>  pythontool = 'python'
>  if 'PYTHON_HOME' in os.environ:
>  pythontool = os.environ['PYTHON_HOME'] + os.sep + 'python'
> +else:
> +pythontool = sys.executable
>  Process = subprocess.Popen([pythontool, splitFspBinPath,
> "info","-f",fspBinFilePath], stdout=subprocess.PIPE)  Output =
> Process.communicate()[0]  FsptInfo = Output.rsplit(b"FSP_M", 1);
> --
> 2.21.0.windows.1


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

View/Reply Online (#46040): https://edk2.groups.io/g/devel/message/46040
Mute This Topic: https://groups.io/mt/32942124/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

2019-08-19 Thread Paolo Bonzini
On 17/08/19 02:20, Yao, Jiewen wrote:
> [Jiewen] That is OK. Then we MUST add the third adversary.
> -- Adversary: Simple hardware attacker, who can use device to perform DMA 
> attack in the virtual world.
> NOTE: The DMA attack in the real world is out of scope. That is be handled by 
> IOMMU in the real world, such as VTd. -- Please do clarify if this is TRUE.
> 
> In the real world:
> #1: the SMM MUST be non-DMA capable region.
> #2: the MMIO MUST be non-DMA capable region.
> #3: the stolen memory MIGHT be DMA capable region or non-DMA capable
> region. It depends upon the silicon design.
> #4: the normal OS accessible memory - including ACPI reclaim, ACPI
> NVS, and reserved memory not included by #3 - MUST be DMA capable region.
> As such, IOMMU protection is NOT required for #1 and #2. IOMMU
> protection MIGHT be required for #3 and MUST be required for #4.
> I assume the virtual environment is designed in the same way. Please
> correct me if I am wrong.
> 

Correct.  The 0x3...0x3 area is the only problematic one;
Igor's idea (or a variant, for example optionally remapping
0xa..0xa SMRAM to 0x3) is becoming more and more attractive.

Paolo

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

View/Reply Online (#46039): https://edk2.groups.io/g/devel/message/46039
Mute This Topic: https://groups.io/mt/32852911/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

2019-08-19 Thread Alex Williamson
On Fri, 16 Aug 2019 22:15:15 +0200
Laszlo Ersek  wrote:

> +Alex (direct question at the bottom)
> 
> On 08/16/19 09:49, Yao, Jiewen wrote:
> > below
> >   
> >> -Original Message-
> >> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> >> Sent: Friday, August 16, 2019 3:20 PM
> >> To: Yao, Jiewen ; Laszlo Ersek
> >> ; devel@edk2.groups.io
> >> Cc: edk2-rfc-groups-io ; qemu devel list
> >> ; Igor Mammedov ;
> >> Chen, Yingwen ; Nakajima, Jun
> >> ; Boris Ostrovsky ;
> >> Joao Marcal Lemos Martins ; Phillip Goerl
> >> 
> >> Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
> >>
> >> On 16/08/19 04:46, Yao, Jiewen wrote:
> >>> Comment below:
> >>>
> >>>
>  -Original Message-
>  From: Paolo Bonzini [mailto:pbonz...@redhat.com]
>  Sent: Friday, August 16, 2019 12:21 AM
>  To: Laszlo Ersek ; devel@edk2.groups.io; Yao,
> >> Jiewen
>  
>  Cc: edk2-rfc-groups-io ; qemu devel list
>  ; Igor Mammedov
> >> ;
>  Chen, Yingwen ; Nakajima, Jun
>  ; Boris Ostrovsky
> >> ;
>  Joao Marcal Lemos Martins ; Phillip Goerl
>  
>  Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
> 
>  On 15/08/19 17:00, Laszlo Ersek wrote:
> > On 08/14/19 16:04, Paolo Bonzini wrote:
> >> 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 :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.
> >
> > I was going through the steps Jiewen and Yingwen recommended.
> >
> > In step (02), the new CPU is expected to set up RAM access. In step
> > (03), the new CPU, executing code from flash, is expected to "send
> >> board
> > message to tell host CPU (GPIO->SCI) -- I am waiting for hot-add
> > message." For that action, the new CPU may need a stack (minimally if
> >> we
> > want to use C function calls).
> >
> > Until step (03), there had been no word about any other (= pre-plugged)
> > CPUs (more precisely, Jiewen even confirmed "No impact to other
> > processors"), so I didn't assume that other CPUs had entered SMM.
> >
> > Paolo, I've attempted to read Jiewen's response, and yours, as carefully
> > as I can. I'm still very confused. If you have a better understanding,
> > could you please write up the 15-step process from the thread starter
> > again, with all QEMU customizations applied? Such as, unnecessary 
> >> steps
> > removed, and platform specifics filled in.
> 
>  Sure.
> 
>  (01a) QEMU: create new CPU.  The CPU already exists, but it does not
>   start running code until unparked by the CPU hotplug controller.
> 
>  (01b) QEMU: trigger SCI
> 
>  (02-03) no equivalent
> 
>  (04) Host CPU: (OS) execute GPE handler from DSDT
> 
>  (05) Host CPU: (OS) Port 0xB2 write, all CPUs enter SMM (NOTE: New CPU
>   will not enter CPU because SMI is disabled)
> 
>  (06) Host CPU: (SMM) Save 38000, Update 38000 -- fill simple SMM
>   rebase code.
> 
>  (07a) Host CPU: (SMM) Write to CPU hotplug controller to enable
>   new CPU
> 
>  (07b) Host CPU: (SMM) Send INIT/SIPI/SIPI to new CPU.
> >>> [Jiewen] NOTE: INIT/SIPI/SIPI can be sent by a malicious CPU. There is no
> >>> restriction that INIT/SIPI/SIPI can only be sent in SMM.
> >>
> >> All of the CPUs are now in SMM, and INIT/SIPI/SIPI will be discarded
> >> before 07a, so this is 

Re: [edk2-devel] [POC Seabios PATCH] seabios: use isolated SMM address space for relocation

2019-08-19 Thread Boris Ostrovsky
On 8/16/19 7:24 AM, Igor Mammedov wrote:
> for purpose of demo SMRAM (at 0x3) is aliased at a in system address 
> space
> for easy initialization of SMI entry point.
> Here is resulting debug output showing that RAM at 0x3 is not affected
> by SMM and only RAM in SMM adderss space is modified:
>
> init smm
> smm_relocate: before relocaten
> smm_relocate: RAM codeentry 0
> smm_relocate: RAM  cpu.i64.smm_base  0
> smm_relocate: SMRAM  codeentry f000c831eac88c
> smm_relocate: SMRAM  cpu.i64.smm_base  0
> handle_smi cmd=0 smbase=0x0003
> smm_relocate: after relocaten
> smm_relocate: RAM codeentry 0
> smm_relocate: RAM  cpu.i64.smm_base  0
> smm_relocate: SMRAM  codeentry f000c831eac88c
> smm_relocate: SMRAM  cpu.i64.smm_base  a


I most likely don't understand how this is supposed to work but aren't
we here successfully reading SMRAM from non-SMM context, something we
are not supposed to be able to do?


-boris


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

View/Reply Online (#46038): https://edk2.groups.io/g/devel/message/46038
Mute This Topic: https://groups.io/mt/32899784/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [edk2] If use prebuild tools, not need install python 2.7 anymore?

2019-08-19 Thread Tiger Liu(BJ-RD)
Hello,
I have a question about needing install python 2.7

If user wants to setup udk compiling environment, he needs install python 2.7.
When running build command every time, it always check python tool path.
Why?

If I compiled basetools before, and use the prebuilt basetools package, then I 
don't need install python 2.7 package?

Thanks



?
?
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for 
the sole use of its intended recipient. Any unauthorized review, use, copying 
or forwarding of this email or the content of this email is strictly prohibited.

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

View/Reply Online (#46036): https://edk2.groups.io/g/devel/message/46036
Mute This Topic: https://groups.io/mt/32943095/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [edk2-platforms: PATCH 1/1] DisplayLinkPkg: DisplayLinkGOP: Added GOP driver for DisplayLink based USB docking stations.

2019-08-19 Thread Leif Lindholm
Hi Andy,

Something is fishy here - these (non-identical) patches *delete* code,
they don't add it.

On Mon, Aug 19, 2019 at 12:18:20PM +0100, Andy Hayes wrote:
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Signed-off-by: Andy Hayes 
> ---
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkPkg.dsc|   
> 61 --
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/DisplayLinkGopDxe.inf  |   
> 65 --
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Edid.h |  
> 129 ---
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDescriptors.h   |  
> 109 --
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDisplayLink.h   |  
> 278 -
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/CapabilityDescriptor.c |  
> 137 ---
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/ComponentName.c|  
> 235 -
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Edid.c |  
> 598 ---
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Gop.c  |  
> 578 ---
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDescriptors.c   |  
> 145 ---
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDisplayLink.c   | 
> 1082 
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c  |  
> 180 
>  Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/VideoModes.c   |  
> 254 -
>  Drivers/DisplayLink/DisplayLinkPkg/ReadMe.md |   
> 77 --
>  Maintainers.txt  |   
>  5 -
>  15 files changed, 3933 deletions(-)

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

View/Reply Online (#46035): https://edk2.groups.io/g/devel/message/46035
Mute This Topic: https://groups.io/mt/32943076/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [PATCH V2] BaseTools: Update incorrect variable name 'DataPile'

2019-08-19 Thread Fan, ZhijuX
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2093

The PlatformAutoGen object has a DataPipe property but no DataPile property
So change the variable name 'DataPile' to 'DataPipe' in BuildReport.py

This patch is going to fix that issue.

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Zhiju.Fan 
---
 BaseTools/Source/Python/build/BuildReport.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/build/BuildReport.py 
b/BaseTools/Source/Python/build/BuildReport.py
index 9c12c01d2a..6b26f1c3b0 100644
--- a/BaseTools/Source/Python/build/BuildReport.py
+++ b/BaseTools/Source/Python/build/BuildReport.py
@@ -2142,7 +2142,7 @@ class PlatformReport(object):
 INFList = 
GlobalData.gFdfParser.Profile.InfDict[Pa.Arch]
 for InfName in INFList:
 InfClass = PathClass(NormPath(InfName), 
Wa.WorkspaceDir, Pa.Arch)
-Ma = ModuleAutoGen(Wa, InfClass, Pa.BuildTarget, 
Pa.ToolChain, Pa.Arch, Wa.MetaFile,Pa.DataPile)
+Ma = ModuleAutoGen(Wa, InfClass, Pa.BuildTarget, 
Pa.ToolChain, Pa.Arch, Wa.MetaFile, Pa.DataPipe)
 if Ma is None:
 continue
 if Ma not in ModuleAutoGenList:
-- 
2.14.1.windows.1


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

View/Reply Online (#46034): https://edk2.groups.io/g/devel/message/46034
Mute This Topic: https://groups.io/mt/32942271/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

<>

[edk2-devel] [PATCH] BaseTools: Update incorrect variable name 'DataPile'

2019-08-19 Thread Fan, ZhijuX
The PlatformAutoGen object has a DataPipe property but no DataPile property
So change the variable name 'DataPile' to 'DataPipe' in BuildReport.py

This patch is going to fix that issue.

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Zhiju.Fan 
---
 BaseTools/Source/Python/build/BuildReport.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/build/BuildReport.py 
b/BaseTools/Source/Python/build/BuildReport.py
index 9c12c01d2a..6b26f1c3b0 100644
--- a/BaseTools/Source/Python/build/BuildReport.py
+++ b/BaseTools/Source/Python/build/BuildReport.py
@@ -2142,7 +2142,7 @@ class PlatformReport(object):
 INFList = 
GlobalData.gFdfParser.Profile.InfDict[Pa.Arch]
 for InfName in INFList:
 InfClass = PathClass(NormPath(InfName), 
Wa.WorkspaceDir, Pa.Arch)
-Ma = ModuleAutoGen(Wa, InfClass, Pa.BuildTarget, 
Pa.ToolChain, Pa.Arch, Wa.MetaFile,Pa.DataPile)
+Ma = ModuleAutoGen(Wa, InfClass, Pa.BuildTarget, 
Pa.ToolChain, Pa.Arch, Wa.MetaFile, Pa.DataPipe)
 if Ma is None:
 continue
 if Ma not in ModuleAutoGenList:
-- 
2.14.1.windows.1


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

View/Reply Online (#46033): https://edk2.groups.io/g/devel/message/46033
Mute This Topic: https://groups.io/mt/32942213/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

<>

Re: [edk2-devel] [PATCH v1 05/11] ShellPkg: acpiview: SLIT: Validate System Locality count

2019-08-19 Thread Sami Mujawar
Reviewed-by: Sami Mujawar 

Regards,

Sami Mujawar

-Original Message-
From: Krzysztof Koch  
Sent: 15 August 2019 02:11 PM
To: devel@edk2.groups.io
Cc: jaben.car...@intel.com; ray...@intel.com; zhichao@intel.com; Sami 
Mujawar ; Matteo Carlini ; nd 

Subject: [PATCH v1 05/11] ShellPkg: acpiview: SLIT: Validate System Locality 
count

1. Check if the 'Number of System Localities' provided can be represented in 
the SLIT table. The table 'Length' field is a 32-bit value while the 'Number of 
System Localities' field is 64-bit long.

2. Check if the SLIT matrix fits in the table buffer. If N is the SLIT locality 
count, then the matrix used to represent the localities is N*N bytes long. The 
ACPI table length must be big enough to fit the matrix.

3. Remove (now) redundant 64x64 bit multiplication.

Signed-off-by: Krzysztof Koch 
---

Notes:
v1:
- Validate the 'Number of System Localities' Field [Krzysztof]
- Remove redundant 64x64 bit multiplication [Krzysztof]

 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser.c | 47 
+---
 1 file changed, 42 insertions(+), 5 deletions(-)

diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser.c
index 
17e2166a09d8615b714e0c51d4d93d293fcdf601..e4625ee8b13907893a9b6990ecb956baf91cc3b9
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitPars
+++ er.c
@@ -30,7 +30,7 @@ STATIC CONST ACPI_PARSER SlitParser[] = {
 /**
   Macro to get the value of a System Locality  **/ -#define SLIT_ELEMENT(Ptr, 
i, j) *(Ptr + (MultU64x64 (i, LocalityCount)) + j)
+#define SLIT_ELEMENT(Ptr, i, j) *(Ptr + (i * LocalityCount) + j)
 
 /**
   This function parses the ACPI SLIT table.
@@ -57,9 +57,9 @@ ParseAcpiSlit (
   )
 {
   UINT32 Offset;
-  UINT64 Count;
-  UINT64 Index;
-  UINT64 LocalityCount;
+  UINT32 Count;
+  UINT32 Index;
+  UINT32 LocalityCount;
   UINT8* LocalityPtr;
   CHAR16 Buffer[80];  // Used for AsciiName param of ParseAcpi
 
@@ -87,8 +87,45 @@ ParseAcpiSlit (
 return;
   }
 
+  /*
+Despite the 'Number of System Localities' being a 64-bit field in SLIT,
+the maximum number of localities that can be represented in SLIT is limited
+by the 'Length' field of the ACPI table.
+
+Since the ACPI table length field is 32-bit wide. The maximum number of
+localities that can be represented in SLIT can be calculated as:
+
+MaxLocality = sqrt (MAX_UINT32 - sizeof 
(EFI_ACPI_6_3_SYSTEM_LOCALITY_DISTANCE_INFORMATION_TABLE_HEADER))
+= 65535
+= MAX_UINT16
+  */
+  if (*SlitSystemLocalityCount > MAX_UINT16) {
+IncrementErrorCount ();
+Print (
+  L"ERROR: The Number of System Localities provided can't be represented " 
\
+L"in the SLIT table. SlitSystemLocalityCount = %ld. " \
+L"MaxLocalityCountAllowed = %d.\n",
+  *SlitSystemLocalityCount,
+  MAX_UINT16
+  );
+return;
+  }
+
+  LocalityCount = (UINT32)*SlitSystemLocalityCount;
+
+  // Make sure system localities fit in the table buffer provided  if 
+ (Offset + (LocalityCount * LocalityCount) > AcpiTableLength) {
+IncrementErrorCount ();
+Print (
+  L"ERROR: Invalid Number of System Localities. " \
+L"SlitSystemLocalityCount = %ld. AcpiTableLength = %d.\n",
+  *SlitSystemLocalityCount,
+  AcpiTableLength
+  );
+return;
+  }
+
   LocalityPtr = Ptr + Offset;
-  LocalityCount = *SlitSystemLocalityCount;
 
   // We only print the Localities if the count is less than 16
   // If the locality count is more than 16 then refer to the
--
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'



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

View/Reply Online (#46032): https://edk2.groups.io/g/devel/message/46032
Mute This Topic: https://groups.io/mt/32886579/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH v1 00/11] Test against invalid pointers in acpiview

2019-08-19 Thread Sami Mujawar
Reviewed-by: Sami Mujawar 

Regards,

Sami Mujawar

-Original Message-
From: Krzysztof Koch  
Sent: 15 August 2019 02:11 PM
To: devel@edk2.groups.io
Cc: jaben.car...@intel.com; ray...@intel.com; zhichao@intel.com; Sami 
Mujawar ; Matteo Carlini ; nd 

Subject: [PATCH v1 00/11] Test against invalid pointers in acpiview

Prevent the use of invalid pointers when parsing ACPI tables in the UEFI shell 
acpiview tool.

The parsing of ACPI tables is often controlled with the values read earlier 
from the same table. For example, the 'Offset' or 'Count' fields found in a 
structure are later used to parse the substructures. If such fields lie outside 
the structure's buffer length provided, then there is a possibility for a wild 
or dangling pointer.

Currently, if the ParseAcpi() function terminates early because the end of the 
input table data buffer has been reached, then the pointers which were supposed 
to be updated by this function are left untouched.
This is a security issue as the values pointed to by these pointers are later 
used for flow control.

This patch series aims to solve this security issue by explicitly initializing 
any pointers lying outside the input ACPI data buffer to NULL and testing for 
NULL whenever these pointers are dereferenced.

Changes can be seet at: 
https://github.com/KrzysztofKoch1/edk2/tree/612_add_pointer_validation_v1

Krzysztof Koch (11):
  ShellPkg: acpiview: Set ItemPtr to NULL for unprocessed table fields
  ShellPkg: acpiview: RSDP: Validate global pointer before use
  ShellPkg: acpiview: FADT: Validate global pointer before use
  ShellPkg: acpiview: SLIT: Validate global pointer before use
  ShellPkg: acpiview: SLIT: Validate System Locality count
  ShellPkg: acpiview: SRAT: Validate global pointers before use
  ShellPkg: acpiview: MADT: Validate global pointers before use
  ShellPkg: acpiview: PPTT: Validate global pointers before use
  ShellPkg: acpiview: IORT: Validate global pointers before use
  ShellPkg: acpiview: GTDT: Validate global pointers before use
  ShellPkg: acpiview: DBG2: Validate global pointers before use

 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c  |  9 ++-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Dbg2/Dbg2Parser.c | 43 
++  
ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.c | 14 
+  ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Gtdt/GtdtParser.c | 
37   
ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Iort/IortParser.c | 52 
+  
ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtParser.c | 13 
+  ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pptt/PpttParser.c | 
25   
ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Rsdp/RsdpParser.c | 12 
  ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser.c | 
61 ++--  
ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c | 13 
+
 10 files changed, 272 insertions(+), 7 deletions(-)

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



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

View/Reply Online (#46031): https://edk2.groups.io/g/devel/message/46031
Mute This Topic: https://groups.io/mt/32886564/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [edk2-platforms: PATCH v2] Python run fail if env variable PYTHON_HOME is not set

2019-08-19 Thread Cheng, Ching JenX
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2041

[PATCH v2] Update related files

In Platform\Intel\MinPlatformPkg\Tools\Fsp\RebaseFspBinBaseAddress.py
It will run another python code.
But if the environment variable "PYTHON_HOME" is not exist
and we didn't add any python's path to "PATH".
It will cause error because python command not found.

the error message as below:
'python' is not recognized as an internal or external command,
operable program or batch file.

So we set the python's path from which execute the python code
if PYTHON_HOME was not exist.

Cc: Amy Chan 
Cc: Michael Kubacki 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Signed-off-by: Ching JenX Cheng 
---
 Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseFspBinBaseAddress.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseFspBinBaseAddress.py 
b/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseFspBinBaseAddress.py
index a8165b08e6..fb4cf4f9b7 100644
--- a/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseFspBinBaseAddress.py
+++ b/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseFspBinBaseAddress.py
@@ -68,6 +68,8 @@ file.close()
 pythontool = 'python'
 if 'PYTHON_HOME' in os.environ:
 pythontool = os.environ['PYTHON_HOME'] + os.sep + 'python'
+else:
+pythontool = sys.executable
 Process = subprocess.Popen([pythontool, splitFspBinPath, 
"info","-f",fspBinFilePath], stdout=subprocess.PIPE)
 Output = Process.communicate()[0]
 FsptInfo = Output.rsplit(b"FSP_M", 1);
-- 
2.21.0.windows.1


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

View/Reply Online (#46030): https://edk2.groups.io/g/devel/message/46030
Mute This Topic: https://groups.io/mt/32942124/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH] Python run fail if env variable PYTHON_HOME is not set

2019-08-19 Thread Chiu, Chasel


Please correct subject as you are modifying edk2-platform files:  
--subject-prefix="edk2-platforms: PATCH"
Also the RebaseAndPatchFspBinBaseAddress.py should be obsolete soon, so please 
focus on RebaseFspBinBaseAddress.py.

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Cheng, Ching JenX
> Sent: Monday, August 19, 2019 3:21 PM
> To: devel@edk2.groups.io
> Cc: Chan, Amy ; Kubacki, Michael A
> ; Chiu, Chasel ;
> Desimone, Nathaniel L ; Gao, Liming
> 
> Subject: [edk2-devel] [PATCH] Python run fail if env variable PYTHON_HOME is
> not set
> 
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2041
> 
> In Platform\Intel\MinPlatformPkg\Tools\Fsp\RebaseFspBinBaseAddress.py
> It will run another python code.
> But if the environment variable "PYTHON_HOME" is not exist and we didn't
> add any python's path to "PATH".
> It will cause error because python command not found.
> 
> the error message as below:
> 'python' is not recognized as an internal or external command, operable
> program or batch file.
> 
> So we set the python's path from which execute the python code if
> PYTHON_HOME was not exist.
> 
> Cc: Amy Chan 
> Cc: Michael Kubacki 
> Cc: Chasel Chiu 
> Cc: Nate DeSimone 
> Cc: Liming Gao 
> Signed-off-by: Ching JenX Cheng 
> ---
> 
> Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseAndPatchFspBinBaseAddre
> ss.py | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git
> a/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseAndPatchFspBinBaseAdd
> ress.py
> b/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseAndPatchFspBinBaseAd
> dress.py
> index 406e5ec130..1d72b4112f 100644
> ---
> a/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseAndPatchFspBinBaseAdd
> ress.py
> +++
> b/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseAndPatchFspBinBaseAd
> +++ dress.py
> @@ -76,6 +76,8 @@ file.close()
>  pythontool = 'python'
>  if 'PYTHON_HOME' in os.environ:
>  pythontool = os.environ['PYTHON_HOME'] + os.sep + 'python'
> +else:
> +pythontool = sys.executable
>  Process = subprocess.Popen([pythontool, splitFspBinPath,
> "info","-f",fspBinFilePath], stdout=subprocess.PIPE)  Output =
> Process.communicate()[0]  FsptInfo = Output.rsplit(b"FSP_M", 1);
> --
> 2.21.0.windows.1
> 
> 
> 


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

View/Reply Online (#46029): https://edk2.groups.io/g/devel/message/46029
Mute This Topic: https://groups.io/mt/32941571/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH v2 03/11] ShellPkg: acpiview: FADT: Validate global pointer before use

2019-08-19 Thread Alexei Fedorov
Reviewed-by: Alexei Fedorov 

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

View/Reply Online (#46028): https://edk2.groups.io/g/devel/message/46028
Mute This Topic: https://groups.io/mt/32941781/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[edk2-devel] [PATCH v2 03/11] ShellPkg: acpiview: FADT: Validate global pointer before use

2019-08-19 Thread Krzysztof Koch
Check if global pointers have been successfully updated before they
are used for further table parsing.

Signed-off-by: Krzysztof Koch 
---

Changes can be seen at: 
https://github.com/KrzysztofKoch1/edk2/tree/612_add_pointer_validation_v2

Notes:
v1:
- Test against NULL pointers [Krzysztof]

v2:
- Do not require FadtMinorRevision and X_DsdtAddress pointers to be
  valid in order to process the remaining ACPI tables [Zhichao]

 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.c | 19 
++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.c
index 
e40c9ef8ee4b3285faf8c6edf3cb6236ee367397..6859c4824c2866fd3eb9a789a8dfc950724b27ca
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.c
@@ -204,9 +204,11 @@ ParseAcpiFadt (
 );
 
   if (Trace) {
-Print (L"\nSummary:\n");
-PrintFieldName (2, L"FADT Version");
-Print (L"%d.%d\n",  *AcpiHdrInfo.Revision, *FadtMinorRevision);
+if (FadtMinorRevision != NULL) {
+  Print (L"\nSummary:\n");
+  PrintFieldName (2, L"FADT Version");
+  Print (L"%d.%d\n",  *AcpiHdrInfo.Revision, *FadtMinorRevision);
+}
 
 if (*GetAcpiXsdtHeaderInfo ()->OemTableId != *AcpiHdrInfo.OemTableId) {
   IncrementErrorCount ();
@@ -214,21 +216,20 @@ ParseAcpiFadt (
 }
   }
 
-  // If X_DSDT is not zero then use X_DSDT and ignore DSDT,
-  // else use DSDT.
-  if (*X_DsdtAddress != 0) {
+  // If X_DSDT is valid then use X_DSDT and ignore DSDT, else use DSDT.
+  if ((X_DsdtAddress != NULL) && (*X_DsdtAddress != 0)) {
 DsdtPtr = (UINT8*)(UINTN)(*X_DsdtAddress);
-  } else if (*DsdtAddress != 0) {
+  } else if ((DsdtAddress != NULL) && (*DsdtAddress != 0)) {
 DsdtPtr = (UINT8*)(UINTN)(*DsdtAddress);
   } else {
-// Both DSDT and X_DSDT cannot be zero.
+// Both DSDT and X_DSDT cannot be invalid.
 #if defined (MDE_CPU_ARM) || defined (MDE_CPU_AARCH64)
 if (Trace) {
   // The DSDT Table is mandatory for ARM systems
   // as the CPU information MUST be presented in
   // the DSDT.
   IncrementErrorCount ();
-  Print (L"ERROR: Both X_DSDT and DSDT are NULL.\n");
+  Print (L"ERROR: Both X_DSDT and DSDT are invalid.\n");
 }
 #endif
 return;
--
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'



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

View/Reply Online (#46027): https://edk2.groups.io/g/devel/message/46027
Mute This Topic: https://groups.io/mt/32941781/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH v4 2/2] MdeModulePkg/ScsiDiskDxe: Support Storage Security Command Protocol

2019-08-19 Thread Wu, Hao A
> -Original Message-
> From: Zurcher, Christopher J
> Sent: Saturday, August 17, 2019 4:22 AM
> To: Wu, Hao A; devel@edk2.groups.io
> Cc: Kinney, Michael D; Yao, Jiewen; Wang, Jian J; Gao, Liming
> Subject: RE: [edk2-devel] [PATCH v4 2/2] MdeModulePkg/ScsiDiskDxe:
> Support Storage Security Command Protocol
> 
> Hao,
> Why will this cause CDROM devices to fail to be recognized? If they require a


Hello,

My observation is that after the patch, the below assignment:
"ScsiDiskDevice->BlkIo.Media->MediaPresent = TRUE;"
is moved from GetMediaInfo() to ScsiDiskTestUnitReady().

The flow for CD-ROM devices is that:
ScsiDiskDriverBindingStart()
|
└-> ScsiDiskDetectMedia()
|
└-> ScsiDiskTestUnitReady()
|
└-> DetectMediaParsingSenseKeys() - Outputs 'Action'
|
└-> If Action is READ_CAPACITY, ScsiDiskReadCapacity()

Now, 'MediaPresent' is set to TRUE in ScsiDiskTestUnitReady(), which leads to
DetectMediaParsingSenseKeys() returning NO_ACTION:

  *Action = ACTION_NO_ACTION;

  ...

  if (!ScsiDiskHaveSenseKey (SenseData, NumberOfSenseKeys)) {
//
// No Sense Key returned from last submitted command
//
if (ScsiDiskDevice->BlkIo.Media->MediaPresent == TRUE) {
}
return EFI_SUCCESS;
  }


> capacity read, I can change the MustReadCapacity flag to TRUE. On
> subsequent media change, the sense key parsing will set Action to
> ACTION_READ_CAPACITY so that case is covered as well. Is there a reason
> the MustReadCapacity flag was originally set to FALSE for CDROM devices?


I think setting 'MustReadCapacity' to FALSE for CD-ROM devices is for the
performance consideration.

Before the patch, logic in DetectMediaParsingSenseKeys():

  if (ScsiDiskIsNoMedia (SenseData, NumberOfSenseKeys)) {
ScsiDiskDevice->BlkIo.Media->MediaPresent = FALSE;
ScsiDiskDevice->BlkIo.Media->LastBlock= 0;
*Action = ACTION_NO_ACTION;
DEBUG ((EFI_D_VERBOSE, "ScsiDisk: ScsiDiskIsNoMedia\n"));
return EFI_SUCCESS;
  }

will decide whether there is media within the CD-ROM devices after parsing the
sense data returned from the device. If the media does not exist, the
Read Capacity command will not be sent.

Setting 'MustReadCapacity' to TRUE will then always require a Read Capacity
command be sent.

Best Regards,
Hao Wu


> With the default action being to read capacity anyway, the existing
> implementation seems to make the flag mostly useless.
> 
> I have implemented the rest of the suggestions.
> 
> Thanks,
> Christopher Zurcher
> 
> -Original Message-
> From: Wu, Hao A
> Sent: Monday, June 17, 2019 19:12
> To: devel@edk2.groups.io; Zurcher, Christopher J
> 
> Cc: Kinney, Michael D ; Yao, Jiewen
> ; Wang, Jian J ; Gao, Liming
> 
> Subject: RE: [edk2-devel] [PATCH v4 2/2] MdeModulePkg/ScsiDiskDxe:
> Support Storage Security Command Protocol
> 
> > -Original Message-
> > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > Zurcher, Christopher J
> > Sent: Thursday, June 13, 2019 10:05 AM
> > To: devel@edk2.groups.io
> > Cc: Kinney, Michael D; Yao, Jiewen; Wang, Jian J; Gao, Liming
> > Subject: [edk2-devel] [PATCH v4 2/2] MdeModulePkg/ScsiDiskDxe:
> Support
> > Storage Security Command Protocol
> >
> > 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.
> 
> 
> Hello,
> 
> Some general level comments:
> 1. CDROM device issue
> This patch will bring an issue to the CDROM devices that CD/DVD will not
> be recognized properly.
> 
> I think the cause of the issue is the relocation of the below logic:
>   ScsiDiskDevice->BlkIo.Media->MediaPresent = TRUE;
> from GetMediaInfo() to ScsiDiskTestUnitReady(). It will lead to the read
> capacity command being skipped for CDROM devices, which results into the
> LastBlock for the device equals to 0.
> 
> We may need to find out a better approach to handle the case for UFS RPMB.
> 
> 2. Split this patch into three commits
> Besides adding the Storage Security Command Protocol support in ScsiDisk
> driver, the patch also:
> * Updates the ScsiBus driver to recognize the Well known logical unit
> * Updates the UfsPassThruDxe driver to expose the RPMB WLUN
> 
> Please help to split the patch into 3 separate commits.
> 
> 3. Updates for the BlockIO(2) services
> For functions ScsiDiskReadBlocks(Ex) & ScsiDiskWriteBlocks(Ex), below codes
> are added for the dummy BlockIO(2) protocol instance on the UFS RPMB Lun:
> 
>   if (BlockSize == 0) {
> Status = EFI_UNSUPPORTED;
> goto Done;
>   }
> 
> I suggest to use status 'EFI_DEVICE_ERROR' for such case, since
> 'EFI_UNSUPPORTED' is not listed as an expected return status in the UEFI
> spec.
> 
> 4. Reinstallation of the EFI_STORAGE_SECURITY_COMMAND_PROTOCOL
> For the reinstallation of the SSC protocol to handle media change, I saw
> this is only handled within ScsiDiskReceiveData() & ScsiDiskSendData().
> The below functions should 

[edk2-devel] [PATCH] Python run fail if env variable PYTHON_HOME is not set

2019-08-19 Thread Cheng, Ching JenX
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2041

In Platform\Intel\MinPlatformPkg\Tools\Fsp\RebaseFspBinBaseAddress.py
It will run another python code.
But if the environment variable "PYTHON_HOME" is not exist
and we didn't add any python's path to "PATH".
It will cause error because python command not found.

the error message as below:
'python' is not recognized as an internal or external command,
operable program or batch file.

So we set the python's path from which execute the python code
if PYTHON_HOME was not exist.

Cc: Amy Chan 
Cc: Michael Kubacki 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Signed-off-by: Ching JenX Cheng 
---
 Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseAndPatchFspBinBaseAddress.py | 2 
++
 1 file changed, 2 insertions(+)

diff --git 
a/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseAndPatchFspBinBaseAddress.py 
b/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseAndPatchFspBinBaseAddress.py
index 406e5ec130..1d72b4112f 100644
--- a/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseAndPatchFspBinBaseAddress.py
+++ b/Platform/Intel/MinPlatformPkg/Tools/Fsp/RebaseAndPatchFspBinBaseAddress.py
@@ -76,6 +76,8 @@ file.close()
 pythontool = 'python'
 if 'PYTHON_HOME' in os.environ:
 pythontool = os.environ['PYTHON_HOME'] + os.sep + 'python'
+else:
+pythontool = sys.executable
 Process = subprocess.Popen([pythontool, splitFspBinPath, 
"info","-f",fspBinFilePath], stdout=subprocess.PIPE)
 Output = Process.communicate()[0]
 FsptInfo = Output.rsplit(b"FSP_M", 1);
-- 
2.21.0.windows.1


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

View/Reply Online (#46025): https://edk2.groups.io/g/devel/message/46025
Mute This Topic: https://groups.io/mt/32941571/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [edk2-devel] [PATCH v1 05/11] ShellPkg: acpiview: SLIT: Validate System Locality count

2019-08-19 Thread Gao, Zhichao
Sorry for missing consider of the commit message #1 and #2.
I got your point. SlitSystemLocalityCount's high 32 bit (actually high 48 bit) 
data is useless.
On my opinion, this field should be 2 bytes length and the spec should be 
updated. Then our code can be updated to match the spec.
For now, I think the checking (*SlitSystemLocalityCount > MAX_UINT16) before it 
is enough.

Thanks,
Zhichao

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Krzysztof Koch
> Sent: Monday, August 19, 2019 2:28 PM
> To: Gao, Zhichao ; devel@edk2.groups.io
> Cc: Carsey, Jaben ; Ni, Ray ;
> Sami Mujawar ; Matteo Carlini
> ; nd 
> Subject: Re: [edk2-devel] [PATCH v1 05/11] ShellPkg: acpiview: SLIT: Validate
> System Locality count
> 
> 
> Hi Zhichao,
> 
> Please find my comments inline marked as [Krzysztof].
> 
> Kind regards,
> 
> Krzysztof
> 
> 
> -Original Message-
> From: Gao, Zhichao 
> Sent: Monday, August 19, 2019 2:19
> To: devel@edk2.groups.io; Krzysztof Koch 
> Cc: Carsey, Jaben ; Ni, Ray ;
> Sami Mujawar ; Matteo Carlini
> ; nd 
> Subject: RE: [edk2-devel] [PATCH v1 05/11] ShellPkg: acpiview: SLIT: Validate
> System Locality count
> 
> 
> 
> > -Original Message-
> > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > Krzysztof Koch
> > Sent: Thursday, August 15, 2019 9:11 PM
> > To: devel@edk2.groups.io
> > Cc: Carsey, Jaben ; Ni, Ray
> > ; Gao, Zhichao ;
> > sami.muja...@arm.com; matteo.carl...@arm.com; n...@arm.com
> > Subject: [edk2-devel] [PATCH v1 05/11] ShellPkg: acpiview: SLIT:
> > Validate System Locality count
> >
> > 1. Check if the 'Number of System Localities' provided can be
> > represented in the SLIT table. The table 'Length' field is a 32-bit
> > value while the 'Number of System Localities' field is 64-bit long.
> >
> > 2. Check if the SLIT matrix fits in the table buffer. If N is the SLIT
> > locality count, then the matrix used to represent the localities is
> > N*N bytes long. The ACPI table length must be big enough to fit the matrix.
> >
> > 3. Remove (now) redundant 64x64 bit multiplication.
> 
> Why removing? This change is added to fixed the issue build error with IA32
> multiplication of two 64 bits data.
> The change of #3 should be removed from the patch.
> Keeping the variable size as UINT64 wouldn't affect the result.
> 
> Thanks,
> Zhichao
> 
> [Krzysztof] If you look closely, in this patch I have removed the need to 
> 64x64
> bit multiplication. As I explain in the commit message, the specification of 
> the
> SLIT table has an error. The System Locality Count is a 64-bit value while the
> ACPI table length field is 32-bit long.
> 
> Consequently, after the right checks are implemented (in this patch), it is
> possible to operate on 32-bit values only. I believe that now MultU64x64() is
> no longer needed so I reverted back to the '*' multiplication operator.
> 
> Please let me know what you think.
> 
> >
> > Signed-off-by: Krzysztof Koch 
> > ---
> >
> > Notes:
> > v1:
> > - Validate the 'Number of System Localities' Field [Krzysztof]
> > - Remove redundant 64x64 bit multiplication [Krzysztof]
> >
> >
> > ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser.c
> > |
> > 47 +---
> >  1 file changed, 42 insertions(+), 5 deletions(-)
> >
> > diff --git
> > a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser
> > .c
> > b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser
> > .c
> > index
> >
> 17e2166a09d8615b714e0c51d4d93d293fcdf601..e4625ee8b13907893a9b6990
> > ecb956baf91cc3b9 100644
> > ---
> > a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser
> > .c
> > +++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitPa
> > +++ rs
> > +++ er.c
> > @@ -30,7 +30,7 @@ STATIC CONST ACPI_PARSER SlitParser[] = {
> >  /**
> >Macro to get the value of a System Locality  **/ -#define
> > SLIT_ELEMENT(Ptr, i, j) *(Ptr + (MultU64x64 (i, LocalityCount)) + j)
> > +#define SLIT_ELEMENT(Ptr, i, j) *(Ptr + (i * LocalityCount) + j)
> >
> >  /**
> >This function parses the ACPI SLIT table.
> > @@ -57,9 +57,9 @@ ParseAcpiSlit (
> >)
> >  {
> >UINT32 Offset;
> > -  UINT64 Count;
> > -  UINT64 Index;
> > -  UINT64 LocalityCount;
> > +  UINT32 Count;
> > +  UINT32 Index;
> > +  UINT32 LocalityCount;
> >UINT8* LocalityPtr;
> >CHAR16 Buffer[80];  // Used for AsciiName param of ParseAcpi
> >
> > @@ -87,8 +87,45 @@ ParseAcpiSlit (
> >  return;
> >}
> >
> > +  /*
> > +Despite the 'Number of System Localities' being a 64-bit field in SLIT,
> > +the maximum number of localities that can be represented in SLIT
> > + is
> > limited
> > +by the 'Length' field of the ACPI table.
> > +
> > +Since the ACPI table length field is 32-bit wide. The maximum number of
> > +localities that can be represented in SLIT can be calculated as:
> > +
> > +MaxLocality = sqrt 

Re: [edk2-devel] [PATCH v1 05/11] ShellPkg: acpiview: SLIT: Validate System Locality count

2019-08-19 Thread Krzysztof Koch


Hi Zhichao,

Please find my comments inline marked as [Krzysztof].

Kind regards,

Krzysztof


-Original Message-
From: Gao, Zhichao  
Sent: Monday, August 19, 2019 2:19
To: devel@edk2.groups.io; Krzysztof Koch 
Cc: Carsey, Jaben ; Ni, Ray ; Sami 
Mujawar ; Matteo Carlini ; nd 

Subject: RE: [edk2-devel] [PATCH v1 05/11] ShellPkg: acpiview: SLIT: Validate 
System Locality count



> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of 
> Krzysztof Koch
> Sent: Thursday, August 15, 2019 9:11 PM
> To: devel@edk2.groups.io
> Cc: Carsey, Jaben ; Ni, Ray 
> ; Gao, Zhichao ; 
> sami.muja...@arm.com; matteo.carl...@arm.com; n...@arm.com
> Subject: [edk2-devel] [PATCH v1 05/11] ShellPkg: acpiview: SLIT: 
> Validate System Locality count
> 
> 1. Check if the 'Number of System Localities' provided can be 
> represented in the SLIT table. The table 'Length' field is a 32-bit 
> value while the 'Number of System Localities' field is 64-bit long.
> 
> 2. Check if the SLIT matrix fits in the table buffer. If N is the SLIT 
> locality count, then the matrix used to represent the localities is 
> N*N bytes long. The ACPI table length must be big enough to fit the matrix.
> 
> 3. Remove (now) redundant 64x64 bit multiplication.

Why removing? This change is added to fixed the issue build error with IA32 
multiplication of two 64 bits data.
The change of #3 should be removed from the patch.
Keeping the variable size as UINT64 wouldn't affect the result.

Thanks,
Zhichao

[Krzysztof] If you look closely, in this patch I have removed the need to 64x64 
bit multiplication. As I explain in the commit message, the specification of 
the SLIT table has an error. The System Locality Count is a 64-bit value while 
the ACPI table length field is 32-bit long. 

Consequently, after the right checks are implemented (in this patch), it is 
possible to operate on 32-bit values only. I believe that now MultU64x64() is 
no longer needed so I reverted back to the '*' multiplication operator.

Please let me know what you think.

> 
> Signed-off-by: Krzysztof Koch 
> ---
> 
> Notes:
> v1:
> - Validate the 'Number of System Localities' Field [Krzysztof]
> - Remove redundant 64x64 bit multiplication [Krzysztof]
> 
>
> ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser.c 
> |
> 47 +---
>  1 file changed, 42 insertions(+), 5 deletions(-)
> 
> diff --git
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser
> .c 
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser
> .c
> index
> 17e2166a09d8615b714e0c51d4d93d293fcdf601..e4625ee8b13907893a9b6990
> ecb956baf91cc3b9 100644
> ---
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser
> .c
> +++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitPa
> +++ rs
> +++ er.c
> @@ -30,7 +30,7 @@ STATIC CONST ACPI_PARSER SlitParser[] = {
>  /**
>Macro to get the value of a System Locality  **/ -#define 
> SLIT_ELEMENT(Ptr, i, j) *(Ptr + (MultU64x64 (i, LocalityCount)) + j)
> +#define SLIT_ELEMENT(Ptr, i, j) *(Ptr + (i * LocalityCount) + j)
> 
>  /**
>This function parses the ACPI SLIT table.
> @@ -57,9 +57,9 @@ ParseAcpiSlit (
>)
>  {
>UINT32 Offset;
> -  UINT64 Count;
> -  UINT64 Index;
> -  UINT64 LocalityCount;
> +  UINT32 Count;
> +  UINT32 Index;
> +  UINT32 LocalityCount;
>UINT8* LocalityPtr;
>CHAR16 Buffer[80];  // Used for AsciiName param of ParseAcpi
> 
> @@ -87,8 +87,45 @@ ParseAcpiSlit (
>  return;
>}
> 
> +  /*
> +Despite the 'Number of System Localities' being a 64-bit field in SLIT,
> +the maximum number of localities that can be represented in SLIT 
> + is
> limited
> +by the 'Length' field of the ACPI table.
> +
> +Since the ACPI table length field is 32-bit wide. The maximum number of
> +localities that can be represented in SLIT can be calculated as:
> +
> +MaxLocality = sqrt (MAX_UINT32 - sizeof
> (EFI_ACPI_6_3_SYSTEM_LOCALITY_DISTANCE_INFORMATION_TABLE_HEAD
> ER))
> += 65535
> += MAX_UINT16
> +  */
> +  if (*SlitSystemLocalityCount > MAX_UINT16) {
> +IncrementErrorCount ();
> +Print (
> +  L"ERROR: The Number of System Localities provided can't be
> represented " \
> +L"in the SLIT table. SlitSystemLocalityCount = %ld. " \
> +L"MaxLocalityCountAllowed = %d.\n",
> +  *SlitSystemLocalityCount,
> +  MAX_UINT16
> +  );
> +return;
> +  }
> +
> +  LocalityCount = (UINT32)*SlitSystemLocalityCount;
> +
> +  // Make sure system localities fit in the table buffer provided  if 
> + (Offset + (LocalityCount * LocalityCount) > AcpiTableLength) {
> +IncrementErrorCount ();
> +Print (
> +  L"ERROR: Invalid Number of System Localities. " \
> +L"SlitSystemLocalityCount = %ld. AcpiTableLength = %d.\n",
> +  *SlitSystemLocalityCount,
> +  AcpiTableLength
> +  );
> +return;
>