[edk2-devel] [PATCH] Intel/* clean up duplicated files in Edk2Platforms

[Marc W Chen]

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

SmramMemoryReserve.h has been added into
Edk2\MdePkg\Include\Guid\SmramMemoryReserve.h.

The following duplicated header file can be clean up.
Edk2Platforms\Platform\Intel\MinPlatformPkg\Include\Guid\SmramMemoryReserve.h
Edk2Platforms\Silicon\Intel\KabylakeSiliconPkg\SampleCode\IntelFrameworkPkg\Include\Guid\SmramMemoryReserve.h
Edk2Platforms\Silicon\Intel\PurleySktPkg\Include\Guid\SmramMemoryReserve.h
Edk2Platforms\Silicon\Intel\QuarkSocPkg\QuarkNorthCluster\Include\Guid\SmramMemoryReserve.h
Edk2Platforms\Silicon\Intel\CoffeelakeSiliconPkg\SampleCode\IntelFrameworkPkg\Include\Guid\SmramMemoryReserve.h

Signed-off-by: Marc W Chen 
Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Liming Gao 
Cc: Nate DeSimone 
Cc: Kelly Steele 
Cc: Thad Gillispie 
Cc: Daocheng Bu 
Cc: Isaac W Oram 
---
 .../Include/Guid/SmramMemoryReserve.h  | 54 --
 Platform/Intel/MinPlatformPkg/MinPlatformPkg.dec   |  5 --
 .../PlatformInitPei/PlatformInitPostMem.c  |  4 +-
 .../PlatformInitPei/PlatformInitPostMem.inf|  4 +-
 .../Library/TestPointCheckLib/PeiCheckSmmInfo.c|  6 +--
 .../Acpi/DxeSmm/AcpiSmm/AcpiSmmPlatform.c  |  4 +-
 .../Acpi/DxeSmm/AcpiSmm/AcpiSmmPlatform.inf|  2 +-
 .../Platform/Pei/PlatformInit/MrcWrapper.c |  8 ++--
 .../Pei/PlatformInit/PlatformEarlyInit.inf |  2 +-
 .../Include/Guid/SmramMemoryReserve.h  | 51 
 Silicon/Intel/CoffeelakeSiliconPkg/SiPkg.dec   |  5 --
 .../SystemAgent/SmmAccess/Dxe/SmmAccess.inf|  2 +-
 .../SystemAgent/SmmAccess/Dxe/SmmAccessDriver.c|  2 +-
 .../Include/Guid/SmramMemoryReserve.h  | 54 --
 Silicon/Intel/KabylakeSiliconPkg/SiPkg.dec |  4 --
 .../SystemAgent/SmmAccess/Dxe/SmmAccess.inf|  4 +-
 .../SystemAgent/SmmAccess/Dxe/SmmAccessDriver.c|  4 +-
 .../PurleySktPkg/Include/Guid/SmramMemoryReserve.h | 43 -
 Silicon/Intel/PurleySktPkg/SocketPkg.dec   |  3 +-
 .../Include/Guid/SmramMemoryReserve.h  | 54 --
 .../Smm/Dxe/SmmAccessDxe/SmmAccess.inf |  2 +-
 .../Smm/Dxe/SmmAccessDxe/SmmAccessDriver.c |  2 +-
 .../Smm/Pei/SmmAccessPei/SmmAccessPei.c|  4 +-
 .../Smm/Pei/SmmAccessPei/SmmAccessPei.inf  |  2 +-
 Silicon/Intel/QuarkSocPkg/QuarkSocPkg.dec  |  1 -
 25 files changed, 27 insertions(+), 299 deletions(-)
 delete mode 100644 
Platform/Intel/MinPlatformPkg/Include/Guid/SmramMemoryReserve.h
 delete mode 100644 
Silicon/Intel/CoffeelakeSiliconPkg/SampleCode/IntelFrameworkPkg/Include/Guid/SmramMemoryReserve.h
 delete mode 100644 
Silicon/Intel/KabylakeSiliconPkg/SampleCode/IntelFrameworkPkg/Include/Guid/SmramMemoryReserve.h
 delete mode 100644 Silicon/Intel/PurleySktPkg/Include/Guid/SmramMemoryReserve.h
 delete mode 100644 
Silicon/Intel/QuarkSocPkg/QuarkNorthCluster/Include/Guid/SmramMemoryReserve.h

diff --git a/Platform/Intel/MinPlatformPkg/Include/Guid/SmramMemoryReserve.h 
b/Platform/Intel/MinPlatformPkg/Include/Guid/SmramMemoryReserve.h
deleted file mode 100644
index 9918c768ba..00
--- a/Platform/Intel/MinPlatformPkg/Include/Guid/SmramMemoryReserve.h
+++ /dev/null
@@ -1,54 +0,0 @@
-/** @file
-  Definition of GUIDed HOB for reserving SMRAM regions.
-
-  This file defines:
-  * the GUID used to identify the GUID HOB for reserving SMRAM regions.
-  * the data structure of SMRAM descriptor to describe SMRAM candidate regions
-  * values of state of SMRAM candidate regions
-  * the GUID specific data structure of HOB for reserving SMRAM regions.
-  This GUIDed HOB can be used to convey the existence of the T-SEG reservation 
and H-SEG usage
-
-Copyright (c) 2007 - 2010, Intel Corporation. All rights reserved.
-SPDX-License-Identifier: BSD-2-Clause-Patent
-
-  @par Revision Reference:
-  GUIDs defined in SmmCis spec version 0.9.
-
-**/
-
-#ifndef _EFI_SMM_PEI_SMRAM_MEMORY_RESERVE_H_
-#define _EFI_SMM_PEI_SMRAM_MEMORY_RESERVE_H_
-
-#define EFI_SMM_PEI_SMRAM_MEMORY_RESERVE \
-  { \
-0x6dadf1d1, 0xd4cc, 0x4910, {0xbb, 0x6e, 0x82, 0xb1, 0xfd, 0x80, 0xff, 
0x3d } \
-  }
-
-/**
-* GUID specific data structure of HOB for reserving SMRAM regions.
-*
-* Inconsistent with specification here: 
-* EFI_HOB_SMRAM_DESCRIPTOR_BLOCK has been changed to 
EFI_SMRAM_HOB_DESCRIPTOR_BLOCK.
-* This inconsistency is kept in code in order for backward compatibility.
-**/
-typedef struct {
-  ///
-  /// Designates the number of possible regions in the system
-  /// that can be usable for SMRAM. 
-  ///
-  /// Inconsistent with specification here:  
-  /// In Framework SMM CIS 0.91 specification, it defines the field type as 
UINTN.
-  /// However, HOBs are supposed to be CPU neutral, so UINT32 should be used 
instead.
-  ///
-  UINT32NumberOfSmmReservedRegions;
-  ///
-  /// Used throughout this protocol to describe the candidate
-  /// regions for SMRAM that are 

[edk2-devel] [Patch V2][edk2-stable201908] BaseTools: Incorrect error message for library instance not found

[Bob Feng]

BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2099
This is a regression issue introduced by commit e8449e.

This patch is to fix this issue.

Signed-off-by: Bob Feng 
Cc: Liming Gao 
---
V2: We need to check if a inf is a Library or a Module.
 BaseTools/Source/Python/AutoGen/DataPipe.py |  2 +-
 BaseTools/Source/Python/AutoGen/PlatformAutoGen.py  |  2 +-
 BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py |  4 +++-
 .../Source/Python/Workspace/WorkspaceCommon.py  | 13 +++--
 4 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/DataPipe.py 
b/BaseTools/Source/Python/AutoGen/DataPipe.py
index 2ca4f9ff4a..8b8cfd1c51 100755
--- a/BaseTools/Source/Python/AutoGen/DataPipe.py
+++ b/BaseTools/Source/Python/AutoGen/DataPipe.py
@@ -87,11 +87,11 @@ class MemoryDataPipe(DataPipe):
 #Module's Library Instance
 ModuleLibs = {}
 libModules = {}
 for m in PlatformInfo.Platform.Modules:
 module_obj = 
BuildDB.BuildObject[m,PlatformInfo.Arch,PlatformInfo.BuildTarget,PlatformInfo.ToolChain]
-Libs = GetModuleLibInstances(module_obj, PlatformInfo.Platform, 
BuildDB.BuildObject, 
PlatformInfo.Arch,PlatformInfo.BuildTarget,PlatformInfo.ToolChain)
+Libs = GetModuleLibInstances(module_obj, PlatformInfo.Platform, 
BuildDB.BuildObject, 
PlatformInfo.Arch,PlatformInfo.BuildTarget,PlatformInfo.ToolChain,PlatformInfo.MetaFile,EdkLogger)
 for lib in Libs:
 try:
 
libModules[(lib.MetaFile.File,lib.MetaFile.Root,lib.Arch,lib.MetaFile.Path)].append((m.File,m.Root,module_obj.Arch,m.Path))
 except:
 
libModules[(lib.MetaFile.File,lib.MetaFile.Root,lib.Arch,lib.MetaFile.Path)] = 
[(m.File,m.Root,module_obj.Arch,m.Path)]
diff --git a/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py 
b/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
index dd629ba2fa..565424a95e 100644
--- a/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
@@ -1087,11 +1087,11 @@ class PlatformAutoGen(AutoGen):
 def GetAllModuleInfo(self,WithoutPcd=True):
 ModuleLibs = set()
 for m in self.Platform.Modules:
 module_obj = 
self.BuildDatabase[m,self.Arch,self.BuildTarget,self.ToolChain]
 if not bool(module_obj.LibraryClass):
-Libs = GetModuleLibInstances(module_obj, self.Platform, 
self.BuildDatabase, self.Arch,self.BuildTarget,self.ToolChain)
+Libs = GetModuleLibInstances(module_obj, self.Platform, 
self.BuildDatabase, 
self.Arch,self.BuildTarget,self.ToolChain,self.MetaFile,EdkLogger)
 else:
 Libs = []
 ModuleLibs.update( 
set([(l.MetaFile.File,l.MetaFile.Root,l.MetaFile.Path,l.MetaFile.BaseName,l.MetaFile.OriginalPath,l.Arch,True)
 for l in Libs]))
 if WithoutPcd and module_obj.PcdIsDriver:
 continue
diff --git a/BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py 
b/BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py
index ea0d8f8bfb..2494267472 100644
--- a/BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py
@@ -246,11 +246,13 @@ class WorkspaceAutoGen(AutoGen):
 if BuildData.MetaFile.Ext == '.inf' and str(BuildData) in 
Platform.Modules :
 Libs.extend(GetModuleLibInstances(BuildData, Platform,
  self.BuildDatabase,
  Arch,
  self.BuildTarget,
- self.ToolChain
+ self.ToolChain,
+ self.Platform.MetaFile,
+ EdkLogger
  ))
 for BuildData in list(self.BuildDatabase._CACHE_.values()):
 if BuildData.Arch != Arch:
 continue
 if BuildData.MetaFile.Ext == '.inf':
diff --git a/BaseTools/Source/Python/Workspace/WorkspaceCommon.py 
b/BaseTools/Source/Python/Workspace/WorkspaceCommon.py
index 76583f46e5..0b11ec2d59 100644
--- a/BaseTools/Source/Python/Workspace/WorkspaceCommon.py
+++ b/BaseTools/Source/Python/Workspace/WorkspaceCommon.py
@@ -13,10 +13,11 @@ from .BuildClassObject import LibraryClassObject
 import Common.GlobalData as GlobalData
 from Workspace.BuildClassObject import StructurePcd
 from Common.BuildToolError import RESOURCE_NOT_AVAILABLE
 from Common.BuildToolError import OPTION_MISSING
 from Common.BuildToolError import BUILD_ERROR
+import Common.EdkLogger as EdkLogger
 
 class OrderedListDict(OrderedDict):
 def __init__(self, *args, **kwargs):
 super(OrderedListDict, self).__init__(*args, **kwargs)
 self.default_factory = list
@@ -83,11 +84,11 @@ def GetDeclaredPcd(Platform, BuildDatabase, 

Re: [edk2-devel] [PATCH] [edk2-stable201908] BaseTools: Support long file path in windows for misc functions

[Bob Feng]

Patch looks good.

Reviewed-by: Bob Feng 


-Original Message-
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Steven Shi
Sent: Thursday, August 22, 2019 10:44 AM
To: devel@edk2.groups.io
Cc: Gao, Liming ; Feng, Bob C ; 
Shi, Steven 
Subject: [edk2-devel] [PATCH] [edk2-stable201908] BaseTools: Support long file 
path in windows for misc functions

From: "Shi, Steven" 

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

Current CopyFileOnChange() and SaveFileOnChange() in 
BaseTools\Source\Python\Common\Misc.py don't use the dedicated long file path 
API to handle the file path strings and cannot support the long file path copy 
and save in windows. This patch enhances them to support the long file path 
copy and save correctly.

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Steven Shi 
---
 BaseTools/Source/Python/Common/Misc.py | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/Common/Misc.py 
b/BaseTools/Source/Python/Common/Misc.py
index 4799635cc4..15ae6a9e40 100755
--- a/BaseTools/Source/Python/Common/Misc.py
+++ b/BaseTools/Source/Python/Common/Misc.py
@@ -34,6 +34,8 @@ from Common.BuildToolError import *  from 
CommonDataClass.DataClass import *  from Common.Parsing import 
GetSplitValueList  from Common.LongFilePathSupport import OpenLongFilePath as 
open
+from Common.LongFilePathSupport import CopyLongFilePath as CopyLong 
+from Common.LongFilePathSupport import LongFilePath as LongFilePath
 from Common.MultipleWorkspace import MultipleWorkspace as mws  from 
CommonDataClass.Exceptions import BadExpression  from Common.caching import 
cached_property @@ -450,6 +452,9 @@ def RemoveDirectory(Directory, 
Recursively=False):
 #
 def SaveFileOnChange(File, Content, IsBinaryFile=True, FileLock=None):
 
+# Convert to long file path format
+File = LongFilePath(File)
+
 if os.path.exists(File):
 if IsBinaryFile:
 try:
@@ -530,6 +535,11 @@ def SaveFileOnChange(File, Content, IsBinaryFile=True, 
FileLock=None):
 #   @retval False No copy really happen
 #
 def CopyFileOnChange(SrcFile, Dst, FileLock=None):
+
+# Convert to long file path format
+SrcFile = LongFilePath(SrcFile)
+Dst = LongFilePath(Dst)
+
 if not os.path.exists(SrcFile):
 return False
 
@@ -561,7 +571,7 @@ def CopyFileOnChange(SrcFile, Dst, FileLock=None):
 # copy the src to a temp file in the dst same folder firstly, then
 # replace or rename the temp file to the destination file.
 with tempfile.NamedTemporaryFile(dir=DirName, delete=False) as tf:
-shutil.copy(SrcFile, tf.name)
+CopyLong(SrcFile, tf.name)
 tempname = tf.name
 try:
 if hasattr(os, 'replace'):
--
2.17.1





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

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

[edk2-devel] [PATCH] [edk2-stable201908] BaseTools: Support long file path in windows for misc functions

[Steven Shi]

From: "Shi, Steven" 

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

Current CopyFileOnChange() and SaveFileOnChange() in
BaseTools\Source\Python\Common\Misc.py don't use the dedicated
long file path API to handle the file path strings and cannot
support the long file path copy and save in windows. This patch
enhances them to support the long file path copy and save
correctly.

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Steven Shi 
---
 BaseTools/Source/Python/Common/Misc.py | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/Common/Misc.py 
b/BaseTools/Source/Python/Common/Misc.py
index 4799635cc4..15ae6a9e40 100755
--- a/BaseTools/Source/Python/Common/Misc.py
+++ b/BaseTools/Source/Python/Common/Misc.py
@@ -34,6 +34,8 @@ from Common.BuildToolError import *
 from CommonDataClass.DataClass import *
 from Common.Parsing import GetSplitValueList
 from Common.LongFilePathSupport import OpenLongFilePath as open
+from Common.LongFilePathSupport import CopyLongFilePath as CopyLong
+from Common.LongFilePathSupport import LongFilePath as LongFilePath
 from Common.MultipleWorkspace import MultipleWorkspace as mws
 from CommonDataClass.Exceptions import BadExpression
 from Common.caching import cached_property
@@ -450,6 +452,9 @@ def RemoveDirectory(Directory, Recursively=False):
 #
 def SaveFileOnChange(File, Content, IsBinaryFile=True, FileLock=None):
 
+# Convert to long file path format
+File = LongFilePath(File)
+
 if os.path.exists(File):
 if IsBinaryFile:
 try:
@@ -530,6 +535,11 @@ def SaveFileOnChange(File, Content, IsBinaryFile=True, 
FileLock=None):
 #   @retval False No copy really happen
 #
 def CopyFileOnChange(SrcFile, Dst, FileLock=None):
+
+# Convert to long file path format
+SrcFile = LongFilePath(SrcFile)
+Dst = LongFilePath(Dst)
+
 if not os.path.exists(SrcFile):
 return False
 
@@ -561,7 +571,7 @@ def CopyFileOnChange(SrcFile, Dst, FileLock=None):
 # copy the src to a temp file in the dst same folder firstly, then
 # replace or rename the temp file to the destination file.
 with tempfile.NamedTemporaryFile(dir=DirName, delete=False) as tf:
-shutil.copy(SrcFile, tf.name)
+CopyLong(SrcFile, tf.name)
 tempname = tf.name
 try:
 if hasattr(os, 'replace'):
-- 
2.17.1


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

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

[edk2-devel] [Patch][edk2-stable201908 2/2] EmulatorPkg/Win/Host: Fix SecPrint() log line endings

[Michael D Kinney]

Update use of SecPrint() to consistently use \n\r for
line endings to fix formatting issues in the debug log.

Cc: Jordan Justen 
Cc: Ray Ni 
Cc: Andrew Fish 
Cc: Tim Lewis 
Signed-off-by: Michael D Kinney 
---
 EmulatorPkg/Win/Host/WinHost.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/EmulatorPkg/Win/Host/WinHost.c b/EmulatorPkg/Win/Host/WinHost.c
index 9c6acac279..9aba3c8959 100644
--- a/EmulatorPkg/Win/Host/WinHost.c
+++ b/EmulatorPkg/Win/Host/WinHost.c
@@ -408,7 +408,7 @@ Returns:
   MemorySizeStr  = (CHAR16 *) PcdGetPtr (PcdEmuMemorySize);
   FirmwareVolumesStr = (CHAR16 *) PcdGetPtr (PcdEmuFirmwareVolume);
 
-  SecPrint ("\nEDK II WIN Host Emulation Environment from 
http://www.tianocore.org/edk2/\n;);
+  SecPrint ("\n\rEDK II WIN Host Emulation Environment from 
http://www.tianocore.org/edk2/\n\r;);
 
   //
   // Determine the first thread available to this process.
@@ -450,7 +450,7 @@ Returns:
   gSystemMemoryCount  = CountSeparatorsInString (MemorySizeStr, '!') + 1;
   gSystemMemory   = calloc (gSystemMemoryCount, sizeof (NT_SYSTEM_MEMORY));
   if (gSystemMemory == NULL) {
-SecPrint ("ERROR : Can not allocate memory for %S.  Exiting.\n", 
MemorySizeStr);
+SecPrint ("ERROR : Can not allocate memory for %S.  Exiting.\n\r", 
MemorySizeStr);
 exit (1);
   }
 
@@ -460,13 +460,13 @@ Returns:
   gFdInfoCount  = CountSeparatorsInString (FirmwareVolumesStr, '!') + 1;
   gFdInfo   = calloc (gFdInfoCount, sizeof (NT_FD_INFO));
   if (gFdInfo == NULL) {
-SecPrint ("ERROR : Can not allocate memory for %S.  Exiting.\n", 
FirmwareVolumesStr);
+SecPrint ("ERROR : Can not allocate memory for %S.  Exiting.\n\r", 
FirmwareVolumesStr);
 exit (1);
   }
   //
   // Setup Boot Mode.
   //
-  SecPrint ("  BootMode 0x%02x\n", PcdGet32 (PcdEmuBootMode));
+  SecPrint ("  BootMode 0x%02x\n\r", PcdGet32 (PcdEmuBootMode));
 
   //
   //  Allocate 128K memory to emulate temp memory for PEI.
@@ -476,12 +476,12 @@ Returns:
   TemporaryRamSize = TEMPORARY_RAM_SIZE;
   TemporaryRam = VirtualAlloc (NULL, (SIZE_T) (TemporaryRamSize), 
MEM_COMMIT, PAGE_EXECUTE_READWRITE);
   if (TemporaryRam == NULL) {
-SecPrint ("ERROR : Can not allocate enough space for SecStack\n");
+SecPrint ("ERROR : Can not allocate enough space for SecStack\n\r");
 exit (1);
   }
   SetMem32 (TemporaryRam, TemporaryRamSize, PcdGet32 
(PcdInitValueInTempStack));
 
-  SecPrint ("  OS Emulator passing in %u KB of temp RAM at 0x%08lx to SEC\n",
+  SecPrint ("  OS Emulator passing in %u KB of temp RAM at 0x%08lx to SEC\n\r",
 TemporaryRamSize / SIZE_1KB,
 TemporaryRam
 );
@@ -503,7 +503,7 @@ Returns:
   
   );
 if (EFI_ERROR (Status)) {
-  SecPrint ("ERROR : Could not allocate PeiServicesTablePage @ %p\n", 
EmuMagicPage);
+  SecPrint ("ERROR : Could not allocate PeiServicesTablePage @ %p\n\r", 
EmuMagicPage);
   return EFI_DEVICE_ERROR;
 }
   }
@@ -514,7 +514,7 @@ Returns:
   //
   FileNamePtr = AllocateCopyPool (StrSize (FirmwareVolumesStr), 
FirmwareVolumesStr);
   if (FileNamePtr == NULL) {
-SecPrint ("ERROR : Can not allocate memory for firmware volume string\n");
+SecPrint ("ERROR : Can not allocate memory for firmware volume 
string\n\r");
 exit (1);
   }
 
@@ -540,11 +540,11 @@ Returns:
   [Index].Size
   );
 if (EFI_ERROR (Status)) {
-  SecPrint ("ERROR : Can not open Firmware Device File %S (0x%X).  
Exiting.\n", FileName, Status);
+  SecPrint ("ERROR : Can not open Firmware Device File %S (0x%X).  
Exiting.\n\r", FileName, Status);
   exit (1);
 }
 
-SecPrint ("  FD loaded from %S\n", FileName);
+SecPrint ("  FD loaded from %S", FileName);
 
 if (SecFile == NULL) {
   //
@@ -565,7 +565,7 @@ Returns:
   }
 }
 
-SecPrint ("\n");
+SecPrint ("\n\r");
   }
   //
   // Calculate memory regions and store the information in the gSystemMemory
@@ -590,7 +590,7 @@ Returns:
 MemorySizeStr = MemorySizeStr + Index1 + 1;
   }
 
-  SecPrint ("\n");
+  SecPrint ("\n\r");
 
   //
   // Hand off to SEC Core
@@ -601,7 +601,7 @@ Returns:
   // If we get here, then the SEC Core returned. This is an error as SEC should
   //  always hand off to PEI Core and then on to DXE Core.
   //
-  SecPrint ("ERROR : SEC returned\n");
+  SecPrint ("ERROR : SEC returned\n\r");
   exit (1);
 }
 
-- 
2.21.0.windows.1


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

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

[edk2-devel] [Patch][edk2-stable201908 0/2] EmulatorPkg/Win/Host: Fix image unload regression

[Michael D Kinney]

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

When UEFI Applications or UEFI Drivers are unloaded,
the PeCoffLoaderUnloadImageExtraAction() needs to unload
the image using FreeLibrary() if the image was successfully
loaded using LoadLibrrayEx().

This is a regression from the Nt32Pkg that supported
unloading applications and drivers as well as loading
the same application or driver multiple times.

Cc: Jordan Justen 
Cc: Ray Ni 
Cc: Andrew Fish 
Cc: Tim Lewis 
Signed-off-by: Michael D Kinney 

Michael D Kinney (2):
  EmulatorPkg/Win/Host: Fix image unload regression
  EmulatorPkg/Win/Host: Fix SecPrint() log line endings

 EmulatorPkg/Win/Host/WinHost.c | 193 +
 1 file changed, 174 insertions(+), 19 deletions(-)

-- 
2.21.0.windows.1


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

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

[edk2-devel] [Patch][edk2-stable201908 1/2] EmulatorPkg/Win/Host: Fix image unload regression

[Michael D Kinney]

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

When UEFI Applications or UEFI Drivers are unloaded,
the PeCoffLoaderUnloadImageExtraAction() needs to unload
the image using FreeLibrary() if the image was successfully
loaded using LoadLibrrayEx().

This is a regression from the Nt32Pkg that supported
unloading applications and drivers as well as loading
the same application or driver multiple times.

Cc: Jordan Justen 
Cc: Ray Ni 
Cc: Andrew Fish 
Cc: Tim Lewis 
Signed-off-by: Michael D Kinney 
---
 EmulatorPkg/Win/Host/WinHost.c | 167 +++--
 1 file changed, 161 insertions(+), 6 deletions(-)

diff --git a/EmulatorPkg/Win/Host/WinHost.c b/EmulatorPkg/Win/Host/WinHost.c
index dd52075f98..9c6acac279 100644
--- a/EmulatorPkg/Win/Host/WinHost.c
+++ b/EmulatorPkg/Win/Host/WinHost.c
@@ -19,6 +19,25 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #define SE_TIME_ZONE_NAME TEXT("SeTimeZonePrivilege")
 #endif
 
+//
+// The growth size for array of module handle entries
+//
+#define MAX_PDB_NAME_TO_MOD_HANDLE_ARRAY_SIZE 0x100
+
+//
+// Module handle entry structure
+//
+typedef struct {
+  CHAR8   *PdbPointer;
+  VOID*ModHandle;
+} PDB_NAME_TO_MOD_HANDLE;
+
+//
+// An Array to hold the module handles
+//
+PDB_NAME_TO_MOD_HANDLE  *mPdbNameModHandleArray = NULL;
+UINTN   mPdbNameModHandleArraySize = 0;
+
 //
 // Default information about where the FD is located.
 //  This array gets filled in with information from PcdWinNtFirmwareVolume
@@ -840,6 +859,120 @@ Returns:
   return Count;
 }
 
+/**
+  Store the ModHandle in an array indexed by the Pdb File name.
+  The ModHandle is needed to unload the image.
+  @param ImageContext - Input data returned from PE Laoder Library. Used to 
find the
+ .PDB file name of the PE Image.
+  @param ModHandle- Returned from LoadLibraryEx() and stored for call to
+ FreeLibrary().
+  @return   return EFI_SUCCESS when ModHandle was stored.
+--*/
+EFI_STATUS
+AddModHandle (
+  IN  PE_COFF_LOADER_IMAGE_CONTEXT *ImageContext,
+  IN  VOID *ModHandle
+  )
+
+{
+  UINTN   Index;
+  PDB_NAME_TO_MOD_HANDLE  *Array;
+  UINTN   PreviousSize;
+  PDB_NAME_TO_MOD_HANDLE  *TempArray;
+  HANDLE  Handle;
+  UINTN   Size;
+
+  //
+  // Return EFI_ALREADY_STARTED if this DLL has already been loaded
+  //
+  Array = mPdbNameModHandleArray;
+  for (Index = 0; Index < mPdbNameModHandleArraySize; Index++, Array++) {
+if (Array->PdbPointer != NULL && Array->ModHandle == ModHandle) {
+  return EFI_ALREADY_STARTED;
+}
+  }
+
+  Array = mPdbNameModHandleArray;
+  for (Index = 0; Index < mPdbNameModHandleArraySize; Index++, Array++) {
+if (Array->PdbPointer == NULL) {
+  //
+  // Make a copy of the stirng and store the ModHandle
+  //
+  Handle = GetProcessHeap ();
+  Size = AsciiStrLen (ImageContext->PdbPointer) + 1;
+  Array->PdbPointer = HeapAlloc ( Handle, HEAP_ZERO_MEMORY, Size);
+  ASSERT (Array->PdbPointer != NULL);
+
+  AsciiStrCpyS (Array->PdbPointer, Size, ImageContext->PdbPointer);
+  Array->ModHandle = ModHandle;
+  return EFI_SUCCESS;
+}
+  }
+
+  //
+  // No free space in mPdbNameModHandleArray so grow it by
+  // MAX_PDB_NAME_TO_MOD_HANDLE_ARRAY_SIZE entires.
+  //
+  PreviousSize = mPdbNameModHandleArraySize * sizeof (PDB_NAME_TO_MOD_HANDLE);
+  mPdbNameModHandleArraySize += MAX_PDB_NAME_TO_MOD_HANDLE_ARRAY_SIZE;
+  //
+  // re-allocate a new buffer and copy the old values to the new locaiton.
+  //
+  TempArray = HeapAlloc (GetProcessHeap (),
+HEAP_ZERO_MEMORY,
+mPdbNameModHandleArraySize * sizeof 
(PDB_NAME_TO_MOD_HANDLE)
+   );
+
+  CopyMem ((VOID *) (UINTN) TempArray, (VOID *) (UINTN)mPdbNameModHandleArray, 
PreviousSize);
+
+  HeapFree (GetProcessHeap (), 0, mPdbNameModHandleArray);
+
+  mPdbNameModHandleArray = TempArray;
+  if (mPdbNameModHandleArray == NULL) {
+ASSERT (FALSE);
+return EFI_OUT_OF_RESOURCES;
+  }
+
+  return AddModHandle (ImageContext, ModHandle);
+}
+
+/**
+  Return the ModHandle and delete the entry in the array.
+   @param  ImageContext - Input data returned from PE Laoder Library. Used to 
find the
+ .PDB file name of the PE Image.
+  @return
+ModHandle - ModHandle assoicated with ImageContext is returned
+NULL  - No ModHandle associated with ImageContext
+**/
+VOID *
+RemoveModHandle (
+  IN  PE_COFF_LOADER_IMAGE_CONTEXT *ImageContext
+  )
+{
+  UINTN   Index;
+  PDB_NAME_TO_MOD_HANDLE  *Array;
+
+  if (ImageContext->PdbPointer == NULL) {
+//
+// If no PDB pointer there is no ModHandle so return NULL
+//
+return NULL;
+  }
+
+  Array = mPdbNameModHandleArray;
+  for (Index = 0; Index < mPdbNameModHandleArraySize; Index++, Array++) {
+if 

Re: [edk2-devel] [PATCH] Update edksetup.bat etc. to support building BaseTools with VS2008 and VS2010

[Liming Gao]

Rebecca:
  I am glad that you add this support. But, I want to confirm whether someone 
still uses VS2008 or VS2010. 

Thanks
Liming
>-Original Message-
>From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>rebe...@bsdio.com
>Sent: Thursday, August 22, 2019 8:17 AM
>To: devel@edk2.groups.io; Gao, Liming ; Feng, Bob C
>
>Cc: Rebecca Cran 
>Subject: [edk2-devel] [PATCH] Update edksetup.bat etc. to support building
>BaseTools with VS2008 and VS2010
>
>The parameter to select which version of Visual Studio to use when
>building BaseTools only goes back to VS2012. Add support for VS2008 and
>VS2010 and fix the code to avoid selecting a newer version if the user
>has requested a specific version.
>
>Signed-off-by: Rebecca Cran 
>---
> BaseTools/get_vsvars.bat| 10 --
> BaseTools/set_vsprefix_envs.bat |  2 ++
> BaseTools/toolsetup.bat | 24 +++-
> edksetup.bat|  6 +-
> 4 files changed, 38 insertions(+), 4 deletions(-)
>
>diff --git a/BaseTools/get_vsvars.bat b/BaseTools/get_vsvars.bat
>index 9f3759b2a9..de8ba79c8b 100644
>--- a/BaseTools/get_vsvars.bat
>+++ b/BaseTools/get_vsvars.bat
>@@ -14,6 +14,8 @@ if /I "%1"=="VS2017" goto VS2017Vars
> if /I "%1"=="VS2015" goto VS2015Vars
>
> if /I "%1"=="VS2013" goto VS2013Vars
>
> if /I "%1"=="VS2012" goto VS2012Vars
>
>+if /I "%1"=="VS2010" goto VS2010Vars
>
>+if /I "%1"=="VS2008" goto VS2008Vars
>
>
>
> :set_vsvars
>
> for /f "usebackq tokens=1* delims=: " %%i in (`%*`) do (
>
>@@ -68,8 +70,12 @@ if defined VCINSTALLDIR goto :done
>   :VS2012Vars
>
>   if defined VS110COMNTOOLS (call :read_vsvars  "%VS110COMNTOOLS%")
>else (if /I "%1"=="VS2012" goto ToolNotInstall)
>
>
>
>-  if defined VS100COMNTOOLS  call :read_vsvars  "%VS100COMNTOOLS%"
>
>-  if defined VS90COMNTOOLS   call :read_vsvars  "%VS90COMNTOOLS%"
>
>+  :VS2010Vars
>
>+  if defined VS100COMNTOOLS (call :read_vsvars  "%VS100COMNTOOLS%")
>else (if /I "%1"=="VS2010" goto ToolNotInstall)
>
>+
>
>+  :VS2008Vars
>
>+  if defined VS90COMNTOOLS  (call :read_vsvars  "%VS90COMNTOOLS%")
>else (if /I "%1"=="VS2008" goto ToolNotInstall)
>
>+
>
>   if defined VS80COMNTOOLS   call :read_vsvars  "%VS80COMNTOOLS%"
>
>   if defined VS71COMNTOOLS   call :read_vsvars  "%VS71COMNTOOLS%"
>
>
>
>diff --git a/BaseTools/set_vsprefix_envs.bat
>b/BaseTools/set_vsprefix_envs.bat
>index 81686f5b63..9165883d95 100644
>--- a/BaseTools/set_vsprefix_envs.bat
>+++ b/BaseTools/set_vsprefix_envs.bat
>@@ -46,6 +46,7 @@ if defined VS90COMNTOOLS (
> set "WINSDKx86_PREFIX=c:\Program Files (x86)\Microsoft
>SDKs\Windows\v6.0A\bin\"
>
>   )
>
> )
>
>+if /I "%1"=="VS2008" goto SetWinDDK
>
>
>
> if defined VS100COMNTOOLS (
>
>   if not defined VS2010_PREFIX (
>
>@@ -58,6 +59,7 @@ if defined VS100COMNTOOLS (
> set "WINSDK7x86_PREFIX=c:\Program Files (x86)\Microsoft
>SDKs\Windows\v7.0A\Bin\"
>
>   )
>
> )
>
>+if /I "%1"=="VS2010" goto SetWinDDK
>
>
>
> :SetVS2012
>
> if defined VS110COMNTOOLS (
>
>diff --git a/BaseTools/toolsetup.bat b/BaseTools/toolsetup.bat
>index 395694fa09..26060c947d 100755
>--- a/BaseTools/toolsetup.bat
>+++ b/BaseTools/toolsetup.bat
>@@ -66,6 +66,18 @@ if /I "%1"=="/?" goto Usage
> set VSTool=VS2012
>
> goto loop
>
>   )
>
>+  if /I "%1"=="VS2010" (
>
>+shift
>
>+set VS2010=TRUE
>
>+set VSTool=VS2010
>
>+goto loop
>
>+  )
>
>+  if /I "%1"=="VS2008" (
>
>+shift
>
>+set VS2008=TRUE
>
>+set VSTool=VS2008
>
>+goto loop
>
>+  )
>
>   if "%1"=="" goto setup_workspace
>
>   if exist %1 (
>
> if not defined BASE_TOOLS_PATH (
>
>@@ -187,6 +199,12 @@ if defined VS2017 (
> ) else if defined VS2012 (
>
>   call %EDK_TOOLS_PATH%\set_vsprefix_envs.bat VS2012
>
>   call %EDK_TOOLS_PATH%\get_vsvars.bat VS2012
>
>+) else if defined VS2010 (
>
>+  call %EDK_TOOLS_PATH%\set_vsprefix_envs.bat VS2010
>
>+  call %EDK_TOOLS_PATH%\get_vsvars.bat VS2010
>
>+) else if defined VS2008 (
>
>+  call %EDK_TOOLS_PATH%\set_vsprefix_envs.bat VS2008
>
>+  call %EDK_TOOLS_PATH%\get_vsvars.bat VS2008
>
> ) else (
>
>   call %EDK_TOOLS_PATH%\set_vsprefix_envs.bat
>
>   call %EDK_TOOLS_PATH%\get_vsvars.bat
>
>@@ -444,7 +462,7 @@ goto end
>
>
> :Usage
>
>   @echo.
>
>-  echo  Usage: "%0 [-h | -help | --help | /h | /help | /?] [ Rebuild |
>ForceRebuild ] [Reconfig] [base_tools_path [edk_tools_path]] [VS2017]
>[VS2015] [VS2013] [VS2012]"
>
>+  echo  Usage: "%0 [-h | -help | --help | /h | /help | /?] [ Rebuild |
>ForceRebuild ] [Reconfig] [base_tools_path [edk_tools_path]] [VS2017]
>[VS2015] [VS2013] [VS2012] [VS2010] [VS2008]"
>
>   @echo.
>
>   @echo base_tools_path   BaseTools project path, BASE_TOOLS_PATH
>will be set to this path.
>
>   @echo edk_tools_pathEDK_TOOLS_PATH will be set to this path.
>
>@@ -453,6 +471,8 @@ goto end
>   @echo ForceRebuild  If sources are available, rebuild all tools
>regardless of
>
>   @echo   whether they have been updated or not.
>
>   @echo  

Re: [edk2-devel] [edk2-test][Patch 1/1] uefi-sct/SctPkg: Eliminate 2nd execution of ExitBootServices Test

[Eric Jin]

Hij Supreeth,

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Supreeth Venkatesh
> Sent: Thursday, August 22, 2019 12:43 AM
> To: Jin, Eric ; devel@edk2.groups.io
> Subject: Re: [edk2-devel] [edk2-test][Patch 1/1] uefi-sct/SctPkg: Eliminate
> 2nd execution of ExitBootServices Test
> 
> On Wed, 2019-08-21 at 01:24 -0500, Eric Jin wrote:
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2098
> Please add the details of the patch to the commit message.
> "In the ExitBootServices() test, after ExitBootServices() call, all boot 
> services
> are forbidden. The original design is to save the return status value of
> ExitBootServices() in variable using variable service and reset, but this 
> needs
> multiple execution of the test to retrieve the value from variable and this
> design was not straightforward from end user perspective.
> 
I would like to change "multiple execution" to "one additional execution" 

> This patch enhances the test by leveraging RecoveryLib to restore execution
> after reset automatically, thus requiring only one execution"
> 
I am ok with this suggestion when I push the code to repo

> More comments inline...
> 
> >
> > Cc: Supreeth Venkatesh 
> > Signed-off-by: Eric Jin 
> > ---
> >  uefi-
> > sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> > ImageBBTest.inf  |  3 ++-
> >  uefi-
> > sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> > ImageBBTest.h|  9 -
> >  uefi-
> > sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> > ImageBBTestConformance.c | 98
> >
> ++
> +++
> > ++---
> >  3 files changed, 93 insertions(+), 17 deletions(-)
> >
> > diff --git a/uefi-
> > sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> > ImageBBTest.inf b/uefi-
> > sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> > ImageBBTest.inf
> > index 49ad79915934..3de43a20e8a4 100644
> > --- a/uefi-
> > sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> > ImageBBTest.inf
> > +++ b/uefi-
> > sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> > ImageBBTest.inf
> > @@ -1,7 +1,7 @@
> >  ## @file
> >  #
> >  #  Copyright 2006 - 2012 Unified EFI, Inc. -#  Copyright (c) 2010
> > - 2012, Intel Corporation. All rights reserved.
> > +#  Copyright (c) 2010 - 2019, Intel Corporation. All rights
> > reserved.
> >  #
> >  #  This program and the accompanying materials  #  are licensed and
> > made available under the terms and conditions of the BSD License @@
> > -53,4 +53,5 @@
> >
> >  [Protocols]
> >gEfiTestProfileLibraryGuid
> > +  gEfiTestRecoveryLibraryGuid
> >gBlackBoxEfiHIIPackageListProtocolGuid
> > diff --git a/uefi-
> > sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> > ImageBBTest.h b/uefi-
> > sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> > ImageBBTest.h
> > index b1c35fee7435..008584577ed1 100644
> > --- a/uefi-
> > sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> > ImageBBTest.h
> > +++ b/uefi-
> > sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> > ImageBBTest.h
> > @@ -1,7 +1,7 @@
> >  /** @file
> >
> >Copyright 2006 - 2017 Unified EFI, Inc.
> > -  Copyright (c) 2010 - 2017, Intel Corporation. All rights
> > reserved.
> > +  Copyright (c) 2010 - 2019, Intel Corporation. All rights
> > reserved.
> >
> >This program and the accompanying materials
> >are licensed and made available under the terms and conditions of
> > the BSD License @@ -35,6 +35,13 @@ Abstract:
> >  #include EFI_PROTOCOL_DEFINITION (LoadFile)
> >
> >  #include EFI_TEST_PROTOCOL_DEFINITION (TestProfileLibrary)
> > +#include EFI_TEST_PROTOCOL_DEFINITION (TestRecoveryLibrary)
> > +
> > +typedef struct _RESET_DATA {
> > +  UINTN   Step;
> > +  UINTN   TplIndex;
> > +  UINT32  RepeatTimes;
> > +} RESET_DATA;
> >
> >  #if (EFI_SPECIFICATION_VERSION >= 0x0002000A)
> >
> > diff --git a/uefi-
> > sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> > ImageBBTestConformance.c b/uefi-
> > sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> > ImageBBTestConformance.c
> > index 0a26d46847da..e90afe7ecae0 100644
> > --- a/uefi-
> > sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> > ImageBBTestConformance.c
> > +++ b/uefi-
> > sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> > ImageBBTestConformance.c
> > @@ -1,7 +1,7 @@
> >  /** @file
> >
> >Copyright 2006 - 2016 Unified EFI, Inc.
> > -  Copyright (c) 2010 - 2016, Intel Corporation. All rights
> > reserved.
> > +  Copyright (c) 2010 - 2019, Intel Corporation. All rights
> > reserved.
> >
> >This program and the accompanying materials
> >are licensed and made 

Re: [edk2-devel] [PATCH v4] IntelSiliconPkg-Vtd: A new PMR interface

[Yao, Jiewen]

Reviewed-by: Jiewen Yao 

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Evelyn Wang
> Sent: Wednesday, August 21, 2019 1:50 AM
> To: devel@edk2.groups.io
> Cc: Huang, Jenny ; Shih, More
> ; Ni, Ray ; Chaganty, Rangasai V
> 
> Subject: [edk2-devel] [PATCH v4] IntelSiliconPkg-Vtd: A new PMR interface
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1770
> 
> 1) IOMMU PMR feature should be generic to support different hardware
> architecture. Platforms may request no overlap between PMR regions
> and system reserve memory. Create an interface to control PLMR/PHMR
> regions. It allows silicon code to adjust PLMR/PHMR region base on
> the project needs.
> 
> 2) DisableDMAr Function Code Optimization
> Optimize the flow to follow the VT-d spec requirements.
> 
> 3) Renamed InitDmar() to InitGlobalVtd()
> The oringal function name is misleading
> 
> 4) A new GetVtdPmrAlignmentLib for silicon code to get
> PMR alignment values.
> 
> Signed-off-by: Evelyn Wang 
> Cc: Jenny Huang 
> Cc: More Shih 
> Cc: Ray Ni 
> Cc: Rangasai V Chaganty 
> 
> ---
> In V2:
> 1) Fixed the EFIAPI is missing in library API issue
> 2) Logs will be provided to make sure the backwards compatibility
> 3) Replaced BIT0 with EFI_ACPI_DMAR_DRHD_FLAGS_INCLUDE_PCI_ALL
> 4) Renamed GetVtdPmrAlignmentLib to PeiGetVtdPmrAlignmentLib
> 5) Fixed the indent in IntelVTdPmrPei.c
> 6) Follow VTd spec to define the data type of the SYSTEM_MEM_INFO_HOB
>Applied few changes coordinately
> 
> ---
> In V3:
> 1) Fixed the EFIAPI is missing in library API issue
> 2) Fixed the S3 resume assert
> 
> ---
> In V4:
> Fixed the missing EFIAPI in .h file and added few more comments
> ---
>  Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/VtdReg.c
> |  30 +++---
>  Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmr.c
> |   4 ++--
>  Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.c
> |  71
> +
> --
>  Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/VtdReg.c
> |  29 ++---
> 
> Silicon/Intel/IntelSiliconPkg/Feature/VTd/PlatformVTdInfoSamplePei/Platfor
> mVTdInfoSamplePei.c |   9 +
> 
> Silicon/Intel/IntelSiliconPkg/Library/PeiGetVtdPmrAlignmentLib/PeiGetVtdP
> mrAlignmentLib.c | 166
> ++
> ++
> ++
> 
> Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.inf
> |   5 -
>  Silicon/Intel/IntelSiliconPkg/Include/Library/PeiGetVtdPmrAlignmentLib.h
> |  22 ++
>  Silicon/Intel/IntelSiliconPkg/Include/SysMemInfoHob.h
> |  25 +
>  Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> |  11 +--
>  Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc
> |   3 ++-
> 
> Silicon/Intel/IntelSiliconPkg/Library/PeiGetVtdPmrAlignmentLib/PeiGetVtdP
> mrAlignmentLib.inf   |  32 
>  12 files changed, 369 insertions(+), 38 deletions(-)
> 
> diff --git a/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/VtdReg.c
> b/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/VtdReg.c
> index 22bf821d2b..699639ba88 100644
> --- a/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/VtdReg.c
> +++ b/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/VtdReg.c
> @@ -1,6 +1,6 @@
>  /** @file
> 
> -  Copyright (c) 2017 - 2018, Intel Corporation. All rights reserved.
> +  Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> @@ -309,6 +309,8 @@ DisableDmar (
>UINTN Index;
>UINTN SubIndex;
>UINT32Reg32;
> +  UINT32Status;
> +  UINT32Command;
> 
>for (Index = 0; Index < mVtdUnitNumber; Index++) {
>  DEBUG((DEBUG_INFO, ">>DisableDmar() for engine [%d] \n",
> Index));
> @@ -319,9 +321,31 @@ DisableDmar (
>  FlushWriteBuffer (Index);
> 
>  //
> -// Disable VTd
> +// Disable Dmar
>  //
> -MmioWrite32 (mVtdUnitInformation[Index].VtdUnitBaseAddress +
> R_GCMD_REG, B_GMCD_REG_SRTP);
> +//
> +// Set TE (Translation Enable: BIT31) of Global command register to
> zero
> +//
> +Reg32 = MmioRead32
> (mVtdUnitInformation[Index].VtdUnitBaseAddress + R_GSTS_REG);
> +Status = (Reg32 & 0x96FF);   // Reset the one-shot bits
> +Command = (Status & ~B_GMCD_REG_TE);
> +MmioWrite32 (mVtdUnitInformation[Index].VtdUnitBaseAddress +
> R_GCMD_REG, Command);
> +
> +//
> +// Poll on TE Status bit of Global status register to become zero
> +//
> +do {
> +  Reg32 = MmioRead32
> (mVtdUnitInformation[Index].VtdUnitBaseAddress + R_GSTS_REG);
> +} while ((Reg32 & B_GSTS_REG_TE) == B_GSTS_REG_TE);
> +
> +//
> +// Set SRTP 

Re: [edk2-devel] EmulatorPkg does not unload DLL after exit

[Michael D Kinney]

Tim,

Thanks.  We must have been typing at same time.  J

I will mark my 2105 as a dup of your 2104.

I have a patch I will send in a minute.  I have tested unload and load multiple.

Mike

From: tim.le...@insyde.com [mailto:tim.le...@insyde.com]
Sent: Wednesday, August 21, 2019 5:47 PM
To: devel@edk2.groups.io; Kinney, Michael D ; 
af...@apple.com
Subject: RE: [edk2-devel] EmulatorPkg does not unload DLL after exit

Mike –
Ok, it is bug 2104.

From: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>> On Behalf Of Michael D 
Kinney
Sent: Wednesday, August 21, 2019 3:08 PM
To: devel@edk2.groups.io; 
af...@apple.com; 
tim.le...@insyde.com; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Subject: Re: [edk2-devel] EmulatorPkg does not unload DLL after exit

Tim,

Thanks for the analysis.

Looks like we need to fix PeCoffLoaderUnloadImageExtraAction()
for winhost to unload the DLL to keep compatibility with Nt32.  This is 
important
for both apps and unloadable drivers.

Please enter a BZ.  This looks like a critical enough regression bug that we 
may want to
consider fixing it before stable tag release.

There are some limitations to the DLL approach.  It is good for source level 
debug
using VS.  The limitation is when the same driver is loaded more than once.  The
first one is loaded as a DLL and can be debugged.  The 2nd one is loaded into
UEFI memory, but is not registered so all you get is assembly code debug.

The method that Andrew describes supports multiple instances of the same driver.

Thanks,

Mike

From: devel@edk2.groups.io 
[mailto:devel@edk2.groups.io] On Behalf Of Andrew Fish via Groups.Io
Sent: Wednesday, August 21, 2019 2:45 PM
To: devel@edk2.groups.io; 
tim.le...@insyde.com
Subject: Re: [edk2-devel] EmulatorPkg does not unload DLL after exit

Tim,

Sounds like you are on to something

The Unix side [1] does a dlclose() to undo a dlsym().

I seem to remember this code flow is very very old, I wonder if it is possible 
to do better? For lldb (Xcode) I skipped the LoadLibraryEx()/dlsym() action and 
wrote a debugger script to load symbols. So for Xcode all the code is running 
from the emulator memory, not in an OS context. For lldb I added a breakpoint 
script on SecGdbScriptBreak() that loads symbols. Since the SecGdbScriptBreak() 
is part of the App you get symbols for free, and the break point function can 
access the arguments to SecGdbScriptBreak() to load symbols [3]. Seems like 
this would easily work for gdb too? I'm not sure how easy this is to do in 
VC++, but it seems like we can leverage what ever scripts folks use to load 
symbols on real hardware.

I'm not 100% sure what is happening on Linux as if you build the code as EFIAPI 
it seems like the dlopen would fail since it is not x86_64 Sys V ABI, and I 
guess it could be falling back to the use the gdb script to load symbols. This 
would Imply for X64 Windows is the odd person out.

The only downside to "making it real" is you may need to launch pointing at a 
debugger script to get source level debug.

I know the lldb symbol loading is working as I help Mike test his recent 
patches.

[1] 
https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/Host/Host.c#L1263
[2] 
https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/Host/Host.c#L1120
[3] 
https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/lldbefi.py#L357

Thanks,

Andrew Fish

On Aug 21, 2019, at 2:13 PM, Tim Lewis 
mailto:tim.le...@insyde.com>> wrote:

When running a shell app twice, I ran into an interesting problem: global 
variables that had initializers were not initialized to the defaults specified 
in the source. Running the same shell app under the old NT32 seems to work. It 
turns out that the shell app was not being reloaded, but rather being 
relaunched. I deduced this from the following behavior:


  1.  The value of the global variables was the same as the last known value 
from the previous invocation.
  2.  The following line in WinHost.c was returning the exact same value for 
the DLL being loaded
Library = LoadLibraryEx (DllFileName, NULL, DONT_RESOLVE_DLL_REFERENCES); 
(around line 901)

  1.  The corresponding code in Nt32’s PeCoffExtractionLib had the following 
lines in PeCoffLoaderUnloadImageExtraAction
  VOID *ModHandle;

  ASSERT (ImageContext != NULL);
  ModHandle = RemoveModeHandle (ImageContext);
  if (ModHandle != NULL) {
mWinNt->FreeLibrary (ModHandle);
  }

However, the same function in EmulatorPkg’s WinHost.c has:

ASSERT (ImageContext != NULL);

So it appears that the DLL is never being unloaded and the subsequent 
invocation of the shell app uses the same instance of the DLL, leaving the 
global variables with the previous values. There are two related functions: 
AddModHandle and RemoveModHandle.

Am I 

Re: [edk2-devel] EmulatorPkg does not unload DLL after exit

[Tim Lewis]

Mike –

Ok, it is bug 2104.

 

From: devel@edk2.groups.io  On Behalf Of Michael D Kinney
Sent: Wednesday, August 21, 2019 3:08 PM
To: devel@edk2.groups.io; af...@apple.com; tim.le...@insyde.com; Kinney, 
Michael D 
Subject: Re: [edk2-devel] EmulatorPkg does not unload DLL after exit

 

Tim,

 

Thanks for the analysis.

 

Looks like we need to fix PeCoffLoaderUnloadImageExtraAction()

for winhost to unload the DLL to keep compatibility with Nt32.  This is 
important

for both apps and unloadable drivers.

 

Please enter a BZ.  This looks like a critical enough regression bug that we 
may want to 

consider fixing it before stable tag release.

 

There are some limitations to the DLL approach.  It is good for source level 
debug

using VS.  The limitation is when the same driver is loaded more than once.  The

first one is loaded as a DLL and can be debugged.  The 2nd one is loaded into

UEFI memory, but is not registered so all you get is assembly code debug.

 

The method that Andrew describes supports multiple instances of the same driver.

 

Thanks,

 

Mike

 

From: devel@edk2.groups.io   
[mailto:devel@edk2.groups.io] On Behalf Of Andrew Fish via Groups.Io
Sent: Wednesday, August 21, 2019 2:45 PM
To: devel@edk2.groups.io  ; tim.le...@insyde.com 
 
Subject: Re: [edk2-devel] EmulatorPkg does not unload DLL after exit

 

Tim,

 

Sounds like you are on to something

 

The Unix side [1] does a dlclose() to undo a dlsym(). 

 

I seem to remember this code flow is very very old, I wonder if it is possible 
to do better? For lldb (Xcode) I skipped the LoadLibraryEx()/dlsym() action and 
wrote a debugger script to load symbols. So for Xcode all the code is running 
from the emulator memory, not in an OS context. For lldb I added a breakpoint 
script on SecGdbScriptBreak() that loads symbols. Since the SecGdbScriptBreak() 
is part of the App you get symbols for free, and the break point function can 
access the arguments to SecGdbScriptBreak() to load symbols [3]. Seems like 
this would easily work for gdb too? I'm not sure how easy this is to do in 
VC++, but it seems like we can leverage what ever scripts folks use to load 
symbols on real hardware. 

 

I'm not 100% sure what is happening on Linux as if you build the code as EFIAPI 
it seems like the dlopen would fail since it is not x86_64 Sys V ABI, and I 
guess it could be falling back to the use the gdb script to load symbols. This 
would Imply for X64 Windows is the odd person out. 

 

The only downside to "making it real" is you may need to launch pointing at a 
debugger script to get source level debug. 

 

I know the lldb symbol loading is working as I help Mike test his recent 
patches. 

 

[1] 
https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/Host/Host.c#L1263

[2] 
https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/Host/Host.c#L1120

[3] 
https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/lldbefi.py#L357

 

Thanks,

 

Andrew Fish





On Aug 21, 2019, at 2:13 PM, Tim Lewis mailto:tim.le...@insyde.com> > wrote:

 

When running a shell app twice, I ran into an interesting problem: global 
variables that had initializers were not initialized to the defaults specified 
in the source. Running the same shell app under the old NT32 seems to work. It 
turns out that the shell app was not being reloaded, but rather being 
relaunched. I deduced this from the following behavior:

 

1.  The value of the global variables was the same as the last known value 
from the previous invocation.
2.  The following line in WinHost.c was returning the exact same value for 
the DLL being loaded

Library = LoadLibraryEx (DllFileName, NULL, DONT_RESOLVE_DLL_REFERENCES); 
(around line 901)

3.  The corresponding code in Nt32’s PeCoffExtractionLib had the following 
lines in PeCoffLoaderUnloadImageExtraAction

  VOID *ModHandle;

 

  ASSERT (ImageContext != NULL);

  ModHandle = RemoveModeHandle (ImageContext);

  if (ModHandle != NULL) {

mWinNt->FreeLibrary (ModHandle);

  }

 

However, the same function in EmulatorPkg’s WinHost.c has:

 

ASSERT (ImageContext != NULL);

 

So it appears that the DLL is never being unloaded and the subsequent 
invocation of the shell app uses the same instance of the DLL, leaving the 
global variables with the previous values. There are two related functions: 
AddModHandle and RemoveModHandle.

 

Am I missing something? Or heading in the right direction? 

 

Thanks,

Tim

 

From:   devel@edk2.groups.io < 
 devel@edk2.groups.io> 
Sent: Saturday, August 17, 2019 6:30 PM
To:   devel@edk2.groups.io
Subject: [edk2-devel] Upcoming Event: TianoCore Design Meeting - APAC/NAMO - 
Thu, 08/22/2019 6:30pm-7:30pm #cal-reminder

 

Reminder: TianoCore Design Meeting - APAC/NAMO

When: Thursday, 22 

[edk2-devel] [PATCH] Update edksetup.bat etc. to support building BaseTools with VS2008 and VS2010

[rebecca]

The parameter to select which version of Visual Studio to use when
building BaseTools only goes back to VS2012. Add support for VS2008 and
VS2010 and fix the code to avoid selecting a newer version if the user
has requested a specific version.

Signed-off-by: Rebecca Cran 
---
 BaseTools/get_vsvars.bat| 10 --
 BaseTools/set_vsprefix_envs.bat |  2 ++
 BaseTools/toolsetup.bat | 24 +++-
 edksetup.bat|  6 +-
 4 files changed, 38 insertions(+), 4 deletions(-)

diff --git a/BaseTools/get_vsvars.bat b/BaseTools/get_vsvars.bat
index 9f3759b2a9..de8ba79c8b 100644
--- a/BaseTools/get_vsvars.bat
+++ b/BaseTools/get_vsvars.bat
@@ -14,6 +14,8 @@ if /I "%1"=="VS2017" goto VS2017Vars
 if /I "%1"=="VS2015" goto VS2015Vars
 if /I "%1"=="VS2013" goto VS2013Vars
 if /I "%1"=="VS2012" goto VS2012Vars
+if /I "%1"=="VS2010" goto VS2010Vars
+if /I "%1"=="VS2008" goto VS2008Vars
 
 :set_vsvars
 for /f "usebackq tokens=1* delims=: " %%i in (`%*`) do (
@@ -68,8 +70,12 @@ if defined VCINSTALLDIR goto :done
   :VS2012Vars
   if defined VS110COMNTOOLS (call :read_vsvars  "%VS110COMNTOOLS%") else (if 
/I "%1"=="VS2012" goto ToolNotInstall)
 
-  if defined VS100COMNTOOLS  call :read_vsvars  "%VS100COMNTOOLS%"
-  if defined VS90COMNTOOLS   call :read_vsvars  "%VS90COMNTOOLS%"
+  :VS2010Vars
+  if defined VS100COMNTOOLS (call :read_vsvars  "%VS100COMNTOOLS%") else (if 
/I "%1"=="VS2010" goto ToolNotInstall)
+
+  :VS2008Vars
+  if defined VS90COMNTOOLS  (call :read_vsvars  "%VS90COMNTOOLS%") else (if /I 
"%1"=="VS2008" goto ToolNotInstall)
+
   if defined VS80COMNTOOLS   call :read_vsvars  "%VS80COMNTOOLS%"
   if defined VS71COMNTOOLS   call :read_vsvars  "%VS71COMNTOOLS%"
 
diff --git a/BaseTools/set_vsprefix_envs.bat b/BaseTools/set_vsprefix_envs.bat
index 81686f5b63..9165883d95 100644
--- a/BaseTools/set_vsprefix_envs.bat
+++ b/BaseTools/set_vsprefix_envs.bat
@@ -46,6 +46,7 @@ if defined VS90COMNTOOLS (
 set "WINSDKx86_PREFIX=c:\Program Files (x86)\Microsoft 
SDKs\Windows\v6.0A\bin\"
   )
 )
+if /I "%1"=="VS2008" goto SetWinDDK
 
 if defined VS100COMNTOOLS (
   if not defined VS2010_PREFIX (
@@ -58,6 +59,7 @@ if defined VS100COMNTOOLS (
 set "WINSDK7x86_PREFIX=c:\Program Files (x86)\Microsoft 
SDKs\Windows\v7.0A\Bin\"
   )
 )
+if /I "%1"=="VS2010" goto SetWinDDK
 
 :SetVS2012
 if defined VS110COMNTOOLS (
diff --git a/BaseTools/toolsetup.bat b/BaseTools/toolsetup.bat
index 395694fa09..26060c947d 100755
--- a/BaseTools/toolsetup.bat
+++ b/BaseTools/toolsetup.bat
@@ -66,6 +66,18 @@ if /I "%1"=="/?" goto Usage
 set VSTool=VS2012
 goto loop
   )
+  if /I "%1"=="VS2010" (
+shift
+set VS2010=TRUE
+set VSTool=VS2010
+goto loop
+  )
+  if /I "%1"=="VS2008" (
+shift
+set VS2008=TRUE
+set VSTool=VS2008
+goto loop
+  )
   if "%1"=="" goto setup_workspace
   if exist %1 (
 if not defined BASE_TOOLS_PATH (
@@ -187,6 +199,12 @@ if defined VS2017 (
 ) else if defined VS2012 (
   call %EDK_TOOLS_PATH%\set_vsprefix_envs.bat VS2012
   call %EDK_TOOLS_PATH%\get_vsvars.bat VS2012
+) else if defined VS2010 (
+  call %EDK_TOOLS_PATH%\set_vsprefix_envs.bat VS2010
+  call %EDK_TOOLS_PATH%\get_vsvars.bat VS2010
+) else if defined VS2008 (
+  call %EDK_TOOLS_PATH%\set_vsprefix_envs.bat VS2008
+  call %EDK_TOOLS_PATH%\get_vsvars.bat VS2008
 ) else (
   call %EDK_TOOLS_PATH%\set_vsprefix_envs.bat
   call %EDK_TOOLS_PATH%\get_vsvars.bat
@@ -444,7 +462,7 @@ goto end
 
 :Usage
   @echo.
-  echo  Usage: "%0 [-h | -help | --help | /h | /help | /?] [ Rebuild | 
ForceRebuild ] [Reconfig] [base_tools_path [edk_tools_path]] [VS2017] [VS2015] 
[VS2013] [VS2012]"
+  echo  Usage: "%0 [-h | -help | --help | /h | /help | /?] [ Rebuild | 
ForceRebuild ] [Reconfig] [base_tools_path [edk_tools_path]] [VS2017] [VS2015] 
[VS2013] [VS2012] [VS2010] [VS2008]"
   @echo.
   @echo base_tools_path   BaseTools project path, BASE_TOOLS_PATH will 
be set to this path.
   @echo edk_tools_pathEDK_TOOLS_PATH will be set to this path.
@@ -453,6 +471,8 @@ goto end
   @echo ForceRebuild  If sources are available, rebuild all tools 
regardless of
   @echo   whether they have been updated or not.
   @echo Reconfig  Reinstall target.txt, tools_def.txt and 
build_rule.txt.
+  @echo VS2008Set the env for VS2008 build.
+  @echo VS2010Set the env for VS2010 build.
   @echo VS2012Set the env for VS2012 build.
   @echo VS2013Set the env for VS2013 build.
   @echo VS2015Set the env for VS2015 build.
@@ -467,6 +487,8 @@ set VS2017=
 set VS2015=
 set VS2013=
 set VS2012=
+set VS2010=
+set VS2008=
 set VSTool=
 popd
 
diff --git a/edksetup.bat b/edksetup.bat
index 5f6028deff..fba19485bf 100755
--- a/edksetup.bat
+++ b/edksetup.bat
@@ -137,15 +137,19 @@ if /I "%1"=="VS2017" shift
 if /I "%1"=="VS2015" shift
 if /I 

Re: [edk2-devel] EmulatorPkg does not unload DLL after exit

[Michael D Kinney]

Tim,

Thanks for the analysis.

Looks like we need to fix PeCoffLoaderUnloadImageExtraAction()
for winhost to unload the DLL to keep compatibility with Nt32.  This is 
important
for both apps and unloadable drivers.

Please enter a BZ.  This looks like a critical enough regression bug that we 
may want to
consider fixing it before stable tag release.

There are some limitations to the DLL approach.  It is good for source level 
debug
using VS.  The limitation is when the same driver is loaded more than once.  The
first one is loaded as a DLL and can be debugged.  The 2nd one is loaded into
UEFI memory, but is not registered so all you get is assembly code debug.

The method that Andrew describes supports multiple instances of the same driver.

Thanks,

Mike

From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Andrew 
Fish via Groups.Io
Sent: Wednesday, August 21, 2019 2:45 PM
To: devel@edk2.groups.io; tim.le...@insyde.com
Subject: Re: [edk2-devel] EmulatorPkg does not unload DLL after exit

Tim,

Sounds like you are on to something

The Unix side [1] does a dlclose() to undo a dlsym().

I seem to remember this code flow is very very old, I wonder if it is possible 
to do better? For lldb (Xcode) I skipped the LoadLibraryEx()/dlsym() action and 
wrote a debugger script to load symbols. So for Xcode all the code is running 
from the emulator memory, not in an OS context. For lldb I added a breakpoint 
script on SecGdbScriptBreak() that loads symbols. Since the SecGdbScriptBreak() 
is part of the App you get symbols for free, and the break point function can 
access the arguments to SecGdbScriptBreak() to load symbols [3]. Seems like 
this would easily work for gdb too? I'm not sure how easy this is to do in 
VC++, but it seems like we can leverage what ever scripts folks use to load 
symbols on real hardware.

I'm not 100% sure what is happening on Linux as if you build the code as EFIAPI 
it seems like the dlopen would fail since it is not x86_64 Sys V ABI, and I 
guess it could be falling back to the use the gdb script to load symbols. This 
would Imply for X64 Windows is the odd person out.

The only downside to "making it real" is you may need to launch pointing at a 
debugger script to get source level debug.

I know the lldb symbol loading is working as I help Mike test his recent 
patches.

[1] 
https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/Host/Host.c#L1263
[2] 
https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/Host/Host.c#L1120
[3] 
https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/lldbefi.py#L357

Thanks,

Andrew Fish


On Aug 21, 2019, at 2:13 PM, Tim Lewis 
mailto:tim.le...@insyde.com>> wrote:

When running a shell app twice, I ran into an interesting problem: global 
variables that had initializers were not initialized to the defaults specified 
in the source. Running the same shell app under the old NT32 seems to work. It 
turns out that the shell app was not being reloaded, but rather being 
relaunched. I deduced this from the following behavior:


  1.  The value of the global variables was the same as the last known value 
from the previous invocation.
  2.  The following line in WinHost.c was returning the exact same value for 
the DLL being loaded
Library = LoadLibraryEx (DllFileName, NULL, DONT_RESOLVE_DLL_REFERENCES); 
(around line 901)

  1.  The corresponding code in Nt32’s PeCoffExtractionLib had the following 
lines in PeCoffLoaderUnloadImageExtraAction
  VOID *ModHandle;

  ASSERT (ImageContext != NULL);
  ModHandle = RemoveModeHandle (ImageContext);
  if (ModHandle != NULL) {
mWinNt->FreeLibrary (ModHandle);
  }

However, the same function in EmulatorPkg’s WinHost.c has:

ASSERT (ImageContext != NULL);

So it appears that the DLL is never being unloaded and the subsequent 
invocation of the shell app uses the same instance of the DLL, leaving the 
global variables with the previous values. There are two related functions: 
AddModHandle and RemoveModHandle.

Am I missing something? Or heading in the right direction?

Thanks,
Tim

From: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>>
Sent: Saturday, August 17, 2019 6:30 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] Upcoming Event: TianoCore Design Meeting - APAC/NAMO - 
Thu, 08/22/2019 6:30pm-7:30pm #cal-reminder

Reminder: TianoCore Design Meeting - APAC/NAMO
When: Thursday, 22 August 2019, 6:30pm to 7:30pm, (GMT-07:00) America/Los 
Angeles
Where:https://zoom.us/j/969264410
View Event
Organizer: Stephano Cetola 
stephano.cet...@intel.com
Description:
Join Zoom Meeting
https://zoom.us/j/969264410

One tap mobile
+16465588656,,969264410# US (New York)
+17207072699,,969264410# US

Dial by your location
+1 646 558 8656 US (New York)
 

Re: [edk2-devel] [RFC PATCH 01/28] OvmfPkg/Sec: Enable cache early to speed up booting

[Jordan Justen]

On 2019-08-21 07:21:25, Laszlo Ersek wrote:
> On 08/19/19 23:35, Lendacky, Thomas wrote:
> > From: Tom Lendacky 
> > 
> > Currently, the OVMF code relies on the hypervisor to enable the cache
> > support on the processor in order to improve the boot speed. However,
> > with SEV-ES, the hypervisor is not allowed to change the CR0 register
> > to enable caching.
> > 
> > Update the OVMF Sec support to enable caching in order to improve the
> > boot speed.
> > 
> > Signed-off-by: Tom Lendacky 
> > ---
> >  OvmfPkg/Sec/SecMain.c | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c
> > index 3914355cd17b..2448be0cd408 100644
> > --- a/OvmfPkg/Sec/SecMain.c
> > +++ b/OvmfPkg/Sec/SecMain.c
> > @@ -739,6 +739,11 @@ SecCoreStartupWithStack (
> >
> >ProcessLibraryConstructorList (NULL, NULL);
> >
> > +  //
> > +  // Enable caching
> > +  //
> > +  AsmEnableCache ();
> > +
> >DEBUG ((EFI_D_INFO,
> >  "SecCoreStartupWithStack(0x%x, 0x%x)\n",
> >  (UINT32)(UINTN)BootFv,
> > 
> 
> This makes me uncomfortable. There used to be problems related to
> caching when VFIO device assignment were used. My concern is admittedly
> vague, but this is a very brittle area of OVMF-on-KVM. If you asked me
> "well what could break here", I'd answer "you never know, and the burden
> of proof is not on me". :) Can we make this change conditional on SEV-ES?

This was also raised as an issue by Peter for the ACRN hypervisor and
Scott for the bhyve hypervisor.

I think it is rare for a platform to enable cache at this early of a
stage, but it is also rare to decompress a firmware volume at this
point.

It appears that it could be helpful to figure out how to safely enable
cache by default here, since it does seem to be impacting several
hypervisors.

-Jordan

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

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

Re: [edk2-devel] EmulatorPkg does not unload DLL after exit

[Andrew Fish via Groups.Io]

Tim,

Sounds like you are on to something

The Unix side [1] does a dlclose() to undo a dlsym(). 

I seem to remember this code flow is very very old, I wonder if it is possible 
to do better? For lldb (Xcode) I skipped the LoadLibraryEx()/dlsym() action and 
wrote a debugger script to load symbols. So for Xcode all the code is running 
from the emulator memory, not in an OS context. For lldb I added a breakpoint 
script on SecGdbScriptBreak() that loads symbols. Since the SecGdbScriptBreak() 
is part of the App you get symbols for free, and the break point function can 
access the arguments to SecGdbScriptBreak() to load symbols [3]. Seems like 
this would easily work for gdb too? I'm not sure how easy this is to do in 
VC++, but it seems like we can leverage what ever scripts folks use to load 
symbols on real hardware. 

I'm not 100% sure what is happening on Linux as if you build the code as EFIAPI 
it seems like the dlopen would fail since it is not x86_64 Sys V ABI, and I 
guess it could be falling back to the use the gdb script to load symbols. This 
would Imply for X64 Windows is the odd person out. 

The only downside to "making it real" is you may need to launch pointing at a 
debugger script to get source level debug. 

I know the lldb symbol loading is working as I help Mike test his recent 
patches. 

[1] 
https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/Host/Host.c#L1263
[2] 
https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/Host/Host.c#L1120
[3] 
https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/lldbefi.py#L357

Thanks,

Andrew Fish

> On Aug 21, 2019, at 2:13 PM, Tim Lewis  wrote:
> 
> When running a shell app twice, I ran into an interesting problem: global 
> variables that had initializers were not initialized to the defaults 
> specified in the source. Running the same shell app under the old NT32 seems 
> to work. It turns out that the shell app was not being reloaded, but rather 
> being relaunched. I deduced this from the following behavior:
>
> The value of the global variables was the same as the last known value from 
> the previous invocation.
> The following line in WinHost.c was returning the exact same value for the 
> DLL being loaded
> Library = LoadLibraryEx (DllFileName, NULL, DONT_RESOLVE_DLL_REFERENCES); 
> (around line 901)
> The corresponding code in Nt32’s PeCoffExtractionLib had the following lines 
> in PeCoffLoaderUnloadImageExtraAction
>   VOID *ModHandle;
>
>   ASSERT (ImageContext != NULL);
>   ModHandle = RemoveModeHandle (ImageContext);
>   if (ModHandle != NULL) {
> mWinNt->FreeLibrary (ModHandle);
>   }
>
> However, the same function in EmulatorPkg’s WinHost.c has:
>
> ASSERT (ImageContext != NULL);
>
> So it appears that the DLL is never being unloaded and the subsequent 
> invocation of the shell app uses the same instance of the DLL, leaving the 
> global variables with the previous values. There are two related functions: 
> AddModHandle and RemoveModHandle.
>
> Am I missing something? Or heading in the right direction? 
>
> Thanks,
> Tim
>
> From: devel@edk2.groups.io  
> mailto:devel@edk2.groups.io>> 
> Sent: Saturday, August 17, 2019 6:30 PM
> To: devel@edk2.groups.io 
> Subject: [edk2-devel] Upcoming Event: TianoCore Design Meeting - APAC/NAMO - 
> Thu, 08/22/2019 6:30pm-7:30pm #cal-reminder
>
> Reminder: TianoCore Design Meeting - APAC/NAMO
> 
> When: Thursday, 22 August 2019, 6:30pm to 7:30pm, (GMT-07:00) America/Los 
> Angeles 
> 
> Where:https://zoom.us/j/969264410 
> View Event 
> Organizer: Stephano Cetola stephano.cet...@intel.com 
> 
> Description:
> 
> Join Zoom Meeting
> https://zoom.us/j/969264410 
>
> One tap mobile
> +16465588656,,969264410# US (New York)
> +17207072699,,969264410# US
>
> Dial by your location
> +1 646 558 8656 US (New York)
> +1 720 707 2699 US
> Meeting ID: 969 264 410
> Find your local number: https://zoom.us/u/abOtdJckxL 
> 
> 


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

View/Reply Online (#46182): https://edk2.groups.io/g/devel/message/46182
Mute This Topic: https://groups.io/mt/32983160/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 05/28] OvmfPkg: Create GHCB pages for use during Pei and Dxe phase

[Lendacky, Thomas]

On 8/21/19 9:31 AM, Laszlo Ersek wrote:
> On 08/19/19 23:35, Lendacky, Thomas wrote:
>> From: Tom Lendacky 
>>
>> Allocate memory for the GHCB pages during SEV initialization for use
>> during Pei and Dxe phases. Since the GHCB pages must be mapped as shared
>> pages, modify CreateIdentityMappingPageTables() so that pagetable entries
>> are created without the encryption bit set.
>>
>> Signed-off-by: Tom Lendacky 
>> ---
>>  UefiCpuPkg/UefiCpuPkg.dec |  4 ++
>>  OvmfPkg/OvmfPkgX64.dsc|  4 ++
>>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf   |  3 +
>>  OvmfPkg/PlatformPei/PlatformPei.inf   |  2 +
>>  .../Core/DxeIplPeim/X64/VirtualMemory.h   | 12 +++-
>>  .../Core/DxeIplPeim/Ia32/DxeLoadFunc.c|  4 +-
>>  .../Core/DxeIplPeim/X64/DxeLoadFunc.c | 11 +++-
>>  .../Core/DxeIplPeim/X64/VirtualMemory.c   | 49 ++
>>  .../MemEncryptSevLibInternal.c|  1 -
>>  .../BaseMemEncryptSevLib/X64/VirtualMemory.c  | 33 --
>>  OvmfPkg/PlatformPei/AmdSev.c  | 64 +++
>>  11 files changed, 164 insertions(+), 23 deletions(-)
> 
> Should be split to at least four patches (UefiCpuPkg, MdeModulePkg,
> OvmfPkg/BaseMemEncryptSevLib, OvmfPkg/PlatformPei).
> 
> In addition, MdeModulePkg content must not depend on UefiCpuPkg content
> -- if modules under both packages need to consume a new PCD, then the
> PCD should be declared under MdeModulePkg. The rough dependency order is:
> 
> - MdePkg (must be self-contained)
> - MdeModulePkg (may consume MdePkg)
> - UefiCpuPkg (may consume everything above, to my knowledge)
> - OvmfPkg (may consume everything above)
> 

Ok, thanks for the guidance.

Ideally, I just would like to modify the newly created page tables after
the call to CreateIdentityMappingPageTables() in MdeModulePkg/Core/
DxeIplPeim/Ia32/DxeLoadFunc.c. Is there a preferred way to add a listener
or callback or notification service so that the main changes would be
limited to the OvmfPkg files and would that be acceptable?

Thanks,
Tom

> Thanks
> Laszlo
> 
>>
>> diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
>> index 6ddf0cd22466..4d5a2593cf13 100644
>> --- a/UefiCpuPkg/UefiCpuPkg.dec
>> +++ b/UefiCpuPkg/UefiCpuPkg.dec
>> @@ -323,5 +323,9 @@ [PcdsDynamic, PcdsDynamicEx]
>># @ValidRange  0x8001 | 0 - 1
>>gUefiCpuPkgTokenSpaceGuid.PcdCpuProcTraceOutputScheme|0x0|UINT8|0x6015
>>  
>> +  ## Contains the GHCB page allocation information.
>> +  gUefiCpuPkgTokenSpaceGuid.PcdGhcbBase|0x0|UINT64|0x6016
>> +  gUefiCpuPkgTokenSpaceGuid.PcdGhcbSize|0x0|UINT64|0x6017
>> +
>>  [UserExtensions.TianoCore."ExtraFiles"]
>>UefiCpuPkgExtra.uni
>> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
>> index dda8dac18441..d6fc7cdf7da8 100644
>> --- a/OvmfPkg/OvmfPkgX64.dsc
>> +++ b/OvmfPkg/OvmfPkgX64.dsc
>> @@ -569,6 +569,10 @@ [PcdsDynamicDefault]
>># Set memory encryption mask
>>gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
>>  
>> +  # Set GHCB base address for SEV-ES
>> +  gUefiCpuPkgTokenSpaceGuid.PcdGhcbBase|0x0
>> +  gUefiCpuPkgTokenSpaceGuid.PcdGhcbSize|0x0
>> +
>>  !if $(SMM_REQUIRE) == TRUE
>>gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8
>>gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
>> diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf 
>> b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
>> index abc3217b0179..b994398633e3 100644
>> --- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
>> +++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
>> @@ -52,6 +52,7 @@ [Sources.ARM, Sources.AARCH64]
>>  [Packages]
>>MdePkg/MdePkg.dec
>>MdeModulePkg/MdeModulePkg.dec
>> +  UefiCpuPkg/UefiCpuPkg.dec
>>  
>>  [Packages.ARM, Packages.AARCH64]
>>ArmPkg/ArmPkg.dec
>> @@ -110,6 +111,8 @@ [Pcd.IA32,Pcd.X64]
>>gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask## 
>> CONSUMES
>>gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask   ## 
>> CONSUMES
>>gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard   ## 
>> CONSUMES
>> +  gUefiCpuPkgTokenSpaceGuid.PcdGhcbBase ## 
>> CONSUMES
>> +  gUefiCpuPkgTokenSpaceGuid.PcdGhcbSize ## 
>> CONSUMES
>>  
>>  [Pcd.IA32,Pcd.X64,Pcd.ARM,Pcd.AARCH64]
>>gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack   ## 
>> SOMETIMES_CONSUMES
>> diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
>> b/OvmfPkg/PlatformPei/PlatformPei.inf
>> index aed1f64b7c93..f53195e6dda5 100644
>> --- a/OvmfPkg/PlatformPei/PlatformPei.inf
>> +++ b/OvmfPkg/PlatformPei/PlatformPei.inf
>> @@ -102,6 +102,8 @@ [Pcd]
>>gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber
>>gUefiCpuPkgTokenSpaceGuid.PcdCpuApInitTimeOutInMicroSeconds
>>gUefiCpuPkgTokenSpaceGuid.PcdCpuApStackSize
>> +  gUefiCpuPkgTokenSpaceGuid.PcdGhcbBase
>> +  gUefiCpuPkgTokenSpaceGuid.PcdGhcbSize
>>  
>>  

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

[rebecca]

On 2019-08-16 18:09, rebe...@bsdio.com wrote:
> Yes, that's going to be important. Given
> https://docs.microsoft.com/en-us/cpp/porting/visual-cpp-change-history-2003-2015?view=vs-2019,
> I suspect support for VS2008 might already have been broken, since it
> reports that "static_assert" was introduced in Visual Studio 2010 - and
> we use it in BaseTools/Source/C/Common/PcdValueCommon.h (the
> _STATIC_ASSERT was added in September 2018):

I just checked, and VS2008 SP1 _can_ build OVMF, though it looks like
support has been removed for building _BaseTools_ with anything older
than VS2012. From "edksetup.bat -h"


...

ForceRebuild    Force a full rebuild of BaseTools binaries.

VS2012            Set the env for VS2012 build.

VS2013            Set the env for VS2013 build.

VS2015            Set the env for VS2015 build.

VS2017            Set the env for VS2017 build.


-- 

Rebecca Cran


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

View/Reply Online (#46180): https://edk2.groups.io/g/devel/message/46180
Mute This Topic: https://groups.io/mt/32850582/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 04/28] OvmfPkg: Create a GHCB page for use during Sec phase

[Lendacky, Thomas]

On 8/21/19 9:25 AM, Laszlo Ersek via Groups.Io wrote:
> On 08/19/19 23:35, Lendacky, Thomas wrote:
>> From: Tom Lendacky 
>>
>> A GHCB page is needed during the Sec phase, so this new page must be
>> created.  Since the GHCB must be marked as an un-encrypted, or shared,
>> page, an additional pagetable page is required so break down the 2MB
>> region where the GHCB page lives into 4K pagetable entries.
>>
>> Signed-off-by: Tom Lendacky 
>> ---
>>  OvmfPkg/OvmfPkg.dec|  5 +++
>>  OvmfPkg/OvmfPkgX64.fdf | 11 ---
>>  OvmfPkg/PlatformPei/PlatformPei.inf|  2 ++
>>  OvmfPkg/ResetVector/ResetVector.inf|  2 ++
>>  UefiCpuPkg/Include/Register/Amd/Fam17Msr.h | 28 
>>  OvmfPkg/ResetVector/Ia32/PageTables64.asm  | 37 +-
>>  OvmfPkg/ResetVector/ResetVector.nasmb  |  2 +-
>>  7 files changed, 81 insertions(+), 6 deletions(-)
> 
> I've skipped patches 02 and 03 for now, because I'll have to go through
> them with a fine toothed comb -- in a subsequent submission, most
> probably. I'm just trying to provide formal comments, so that I do the
> actual review more easily, later.
> 
> As I requested under the blurb, this patch should be split in at least
> three parts, if possible -- OvmfPkg/PlatformPei, OvmfPkg/ResetVector,
> UefiCpuPkg. (The DEC and FDF changes can be kept squashed with the
> OvmfPkg patch that seems more suitable for that.)

Ok.

> 
> ... Having said that, why do you add PCDs to the PlatformPei INF file?
> The code in PlatformPei doesn't change. Could be a leftover from an
> earlier (abandoned) approach.

Yeah, most likely. I'll remove that.

Thanks,
Tom

> 
> Thanks
> Laszlo
> 
>>
>> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
>> index 9640360f6245..2ead9a944af4 100644
>> --- a/OvmfPkg/OvmfPkg.dec
>> +++ b/OvmfPkg/OvmfPkg.dec
>> @@ -218,6 +218,11 @@ [PcdsFixedAtBuild]
>>#  The value should be a multiple of 4KB.
>>gUefiOvmfPkgTokenSpaceGuid.PcdHighPmmMemorySize|0x40|UINT32|0x31
>>  
>> +  ## Specify the GHCB base address and size.
>> +  #  The value should be a multiple of 4KB for each.
>> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase|0x0|UINT32|0x32
>> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize|0x0|UINT32|0x33
>> +
>>  [PcdsDynamic, PcdsDynamicEx]
>>gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
>> diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
>> index 74407072563b..2a2427092382 100644
>> --- a/OvmfPkg/OvmfPkgX64.fdf
>> +++ b/OvmfPkg/OvmfPkgX64.fdf
>> @@ -67,13 +67,16 @@ [FD.MEMFD]
>>  BlockSize = 0x1
>>  NumBlocks = 0xC0
>>  
>> -0x00|0x006000
>> +0x00|0x007000
>>  
>> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
>>  
>> -0x006000|0x001000
>> -gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
>> -
>>  0x007000|0x001000
>> +gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize
>> +
>> +0x008000|0x001000
>> +gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
>> +
>> +0x009000|0x001000
>>  
>> gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
>>  
>>  0x01|0x01
>> diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
>> b/OvmfPkg/PlatformPei/PlatformPei.inf
>> index d9fd9c8f05b3..aed1f64b7c93 100644
>> --- a/OvmfPkg/PlatformPei/PlatformPei.inf
>> +++ b/OvmfPkg/PlatformPei/PlatformPei.inf
>> @@ -72,6 +72,8 @@ [Pcd]
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
>> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase
>> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
>>gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
>> diff --git a/OvmfPkg/ResetVector/ResetVector.inf 
>> b/OvmfPkg/ResetVector/ResetVector.inf
>> index 960b47cd0797..d66f4dc29737 100644
>> --- a/OvmfPkg/ResetVector/ResetVector.inf
>> +++ b/OvmfPkg/ResetVector/ResetVector.inf
>> @@ -37,3 +37,5 @@ [Pcd]
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
>> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase
>> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize
>> diff --git a/UefiCpuPkg/Include/Register/Amd/Fam17Msr.h 
>> b/UefiCpuPkg/Include/Register/Amd/Fam17Msr.h
>> index 37b935dcdb30..55a5723e164e 100644
>> --- a/UefiCpuPkg/Include/Register/Amd/Fam17Msr.h
>> +++ b/UefiCpuPkg/Include/Register/Amd/Fam17Msr.h
>> @@ -17,6 +17,34 @@
>>  

Re: [edk2-devel] [RFC PATCH 01/28] OvmfPkg/Sec: Enable cache early to speed up booting

[Lendacky, Thomas]

On 8/21/19 9:21 AM, Laszlo Ersek wrote:
> On 08/19/19 23:35, Lendacky, Thomas wrote:
>> From: Tom Lendacky 
>>
>> Currently, the OVMF code relies on the hypervisor to enable the cache
>> support on the processor in order to improve the boot speed. However,
>> with SEV-ES, the hypervisor is not allowed to change the CR0 register
>> to enable caching.
>>
>> Update the OVMF Sec support to enable caching in order to improve the
>> boot speed.
>>
>> Signed-off-by: Tom Lendacky 
>> ---
>>  OvmfPkg/Sec/SecMain.c | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c
>> index 3914355cd17b..2448be0cd408 100644
>> --- a/OvmfPkg/Sec/SecMain.c
>> +++ b/OvmfPkg/Sec/SecMain.c
>> @@ -739,6 +739,11 @@ SecCoreStartupWithStack (
>>  
>>ProcessLibraryConstructorList (NULL, NULL);
>>  
>> +  //
>> +  // Enable caching
>> +  //
>> +  AsmEnableCache ();
>> +
>>DEBUG ((EFI_D_INFO,
>>  "SecCoreStartupWithStack(0x%x, 0x%x)\n",
>>  (UINT32)(UINTN)BootFv,
>>
> 
> This makes me uncomfortable. There used to be problems related to
> caching when VFIO device assignment were used. My concern is admittedly
> vague, but this is a very brittle area of OVMF-on-KVM. If you asked me
> "well what could break here", I'd answer "you never know, and the burden
> of proof is not on me". :) Can we make this change conditional on SEV-ES?
> 

I'll look into that. Anything is possible, just might have to read an MSR
at this stage.

Thanks,
Tom

> Thanks
> Laszlo
> 

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

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

[edk2-devel] EmulatorPkg does not unload DLL after exit

[Tim Lewis]

When running a shell app twice, I ran into an interesting problem: global 
variables that had initializers were not initialized to the defaults specified 
in the source. Running the same shell app under the old NT32 seems to work. It 
turns out that the shell app was not being reloaded, but rather being 
relaunched. I deduced this from the following behavior:

 

1.  The value of the global variables was the same as the last known value 
from the previous invocation.
2.  The following line in WinHost.c was returning the exact same value for 
the DLL being loaded

Library = LoadLibraryEx (DllFileName, NULL, DONT_RESOLVE_DLL_REFERENCES); 
(around line 901)

3.  The corresponding code in Nt32’s PeCoffExtractionLib had the following 
lines in PeCoffLoaderUnloadImageExtraAction

  VOID *ModHandle;

 

  ASSERT (ImageContext != NULL);

  ModHandle = RemoveModeHandle (ImageContext);

  if (ModHandle != NULL) {

mWinNt->FreeLibrary (ModHandle);

  }

 

However, the same function in EmulatorPkg’s WinHost.c has:

 

ASSERT (ImageContext != NULL);

 

So it appears that the DLL is never being unloaded and the subsequent 
invocation of the shell app uses the same instance of the DLL, leaving the 
global variables with the previous values. There are two related functions: 
AddModHandle and RemoveModHandle.

 

Am I missing something? Or heading in the right direction? 

 

Thanks,

Tim

 

From: devel@edk2.groups.io  
Sent: Saturday, August 17, 2019 6:30 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] Upcoming Event: TianoCore Design Meeting - APAC/NAMO - 
Thu, 08/22/2019 6:30pm-7:30pm #cal-reminder

 

Reminder: TianoCore Design Meeting - APAC/NAMO

When: Thursday, 22 August 2019, 6:30pm to 7:30pm, (GMT-07:00) America/Los 
Angeles 

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

View Event  

Organizer: Stephano Cetola stephano.cet...@intel.com 


Description: 

Join Zoom Meeting

https://zoom.us/j/969264410

 

One tap mobile

+16465588656,,969264410# US (New York)

+17207072699,,969264410# US

 

Dial by your location

+1 646 558 8656 US (New York)

+1 720 707 2699 US

Meeting ID: 969 264 410

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




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

View/Reply Online (#46177): https://edk2.groups.io/g/devel/message/46177
Mute This Topic: https://groups.io/mt/32983160/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] Maintainers.txt update for ShellPkg

[Ni, Ray]

Jaben,
We will miss you from community.

Reviewed-by: Ray Ni 

> -Original Message-
> From: Carsey, Jaben
> Sent: Wednesday, August 21, 2019 1:40 PM
> To: devel@edk2.groups.io
> Cc: Ni, Ray ; Gao, Zhichao ; Kinney, 
> Michael D 
> Subject: [Patch v1] Maintainers.txt update for ShellPkg
> 
> removing myself from maintainer
> promoting Zhichao
> 
> Cc: Ray Ni 
> Cc: Zhichao Gao 
> Cc: Mike Kinney 
> Signed-off-by: Jaben Carsey 
> ---
>  Maintainers.txt | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 919baccc56..1dcc6c64ed 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -418,14 +418,13 @@ R: Chao Zhang 
>  ShellPkg
>  F: ShellPkg/
>  W: https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg
> -M: Jaben Carsey 
>  M: Ray Ni 
> -R: Zhichao Gao 
> +M: Zhichao Gao 
> 
>  Maintainers for stable Shell binaries generation
>  when need to publish Shell binaries with edk2 release:
> -M: Jaben Carsey   (Ia32/X64)
>  M: Ray Ni   (Ia32/X64)
> +M: Zhichao Gao (Ia32/X64)
>  M: Leif Lindholm(ARM/AArch64)
>  M: Ard Biesheuvel  (ARM/AArch64)
> 
> --
> 2.16.2.windows.1


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

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

[edk2-devel] [Patch v1] Maintainers.txt update for ShellPkg

[Carsey, Jaben]

removing myself from maintainer
promoting Zhichao

Cc: Ray Ni 
Cc: Zhichao Gao 
Cc: Mike Kinney 
Signed-off-by: Jaben Carsey 
---
 Maintainers.txt | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index 919baccc56..1dcc6c64ed 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -418,14 +418,13 @@ R: Chao Zhang 
 ShellPkg
 F: ShellPkg/
 W: https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg
-M: Jaben Carsey 
 M: Ray Ni 
-R: Zhichao Gao 
+M: Zhichao Gao 
 
 Maintainers for stable Shell binaries generation
 when need to publish Shell binaries with edk2 release:
-M: Jaben Carsey   (Ia32/X64)
 M: Ray Ni   (Ia32/X64)
+M: Zhichao Gao (Ia32/X64)
 M: Leif Lindholm(ARM/AArch64)
 M: Ard Biesheuvel  (ARM/AArch64)
 
-- 
2.16.2.windows.1


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

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

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

[Michael D Kinney]

Paolo,

It makes sense to match real HW.  That puts us back to
the reset vector and handling the initial SMI at
3000:8000.  That is all workable from a FW implementation
perspective.  It look like the only issue left is DMA.

DMA protection of memory ranges is a chipset feature.
For the current QEMU implementation, what ranges of
memory are guaranteed to be protected from DMA?  Is
it only A/B seg and TSEG?

Thanks,

Mike

> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Wednesday, August 21, 2019 10:40 AM
> To: Kinney, Michael D ;
> r...@edk2.groups.io; Yao, Jiewen 
> Cc: Alex Williamson ; Laszlo
> Ersek ; devel@edk2.groups.io; qemu
> devel list ; Igor Mammedov
> ; Chen, Yingwen
> ; Nakajima, Jun
> ; Boris Ostrovsky
> ; Joao Marcal Lemos Martins
> ; Phillip Goerl
> 
> Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug using
> SMM with QEMU+OVMF
> 
> On 21/08/19 19:25, Kinney, Michael D wrote:
> > Could we have an initial SMBASE that is within TSEG.
> >
> > If we bring in hot plug CPUs one at a time, then
> initial SMBASE in
> > TSEG can reprogram the SMBASE to the correct value for
> that CPU.
> >
> > Can we add a register to the hot plug controller that
> allows the BSP
> > to set the initial SMBASE value for a hot added CPU?
> The default can
> > be 3000:8000 for compatibility.
> >
> > Another idea is when the SMI handler runs for a hot
> add CPU event, the
> > SMM monarch programs the hot plug controller register
> with the SMBASE
> > to use for the CPU that is being added.  As each CPU
> is added, a
> > different SMBASE value can be programmed by the SMM
> Monarch.
> 
> Yes, all of these would work.  Again, I'm interested in
> having something that has a hope of being implemented in
> real hardware.
> 
> Another, far easier to implement possibility could be a
> lockable MSR (could be the existing
> MSR_SMM_FEATURE_CONTROL) that allows programming the
> SMBASE outside SMM.  It would be nice if such a bit
> could be defined by Intel.
> 
> Paolo

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

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

Re: [edk2-devel] Memory Operation Mode

[Andrew Fish via Groups.Io]

> On Aug 21, 2019, at 11:55 AM, Rafael Machado 
>  wrote:
> 
> Hi everyone
> 
> I would like to ask for some help regarding one question.
> How do I know how the memory communication was set by the BIOS/MRC/FSP during 
> the initialization process?
> For example, I would like to know if the memory controller is working with 
> the memories in single channel or dual channel mode.
> 
> Didn't find anything related to this at the uefi spec.
> And seems the registers that may have this information are platform 
> dependent, so no generic solution seems to be currently available.
> 
> Any idea about how to have this information?
> 

Rafael,

This is probably more of a PI kind of spec question, but the PI spec only 
really deals in how memory is discovered and registered with the PEI/DXE Core 
etc. There is not any infrastructure that abstracts this level of detail in PI. 

In general the kind of info you are looking for would only exist in SMBIOS 
records. You could start with the Type 16, 17, 18, and 19 SMBIOS records. The 
code that configure the memory knows a lot, but the only standard way to 
communicate this info is via SMBIOS. 

Thanks,

Andrew Fish

> Thanks and Regards
> Rafael R. Machado
> 


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

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

[edk2-devel] Memory Operation Mode

[Rafael Machado]

Hi everyone

I would like to ask for some help regarding one question.
How do I know how the memory communication was set by the BIOS/MRC/FSP
during the initialization process?
For example, I would like to know if the memory controller is working with
the memories in single channel or dual channel mode.

Didn't find anything related to this at the uefi spec.
And seems the registers that may have this information are platform
dependent, so no generic solution seems to be currently available.

Any idea about how to have this information?

Thanks and Regards
Rafael R. Machado

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

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

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

[Paolo Bonzini]

On 21/08/19 17:48, Kinney, Michael D wrote:
> Perhaps there is a way to avoid the 3000:8000 startup
> vector.
> 
> If a CPU is added after a cold reset, it is already in a
> different state because one of the active CPUs needs to
> release it by interacting with the hot plug controller.
> 
> Can the SMRR for CPUs in that state be pre-programmed to
> match the SMRR in the rest of the active CPUs?
> 
> For OVMF we expect all the active CPUs to use the same
> SMRR value, so a check can be made to verify that all 
> the active CPUs have the same SMRR value.  If they do,
> then any CPU released through the hot plug controller 
> can have its SMRR pre-programmed and the initial SMI
> will start within TSEG.
> 
> We just need to decide what to do in the unexpected 
> case where all the active CPUs do not have the same
> SMRR value.
> 
> This should also reduce the total number of steps.

The problem is not the SMRR but the SMBASE.  If the SMBASE area is
outside TSEG, it is vulnerable to DMA attacks independent of the SMRR.
SMBASE is also different for all CPUs, so it cannot be preprogrammed.

(As an aside, virt platforms are also immune to cache poisoning so they
don't have SMRR yet - we could use them for SMM_CODE_CHK_EN and block
execution outside SMRR but we never got round to it).

An even simpler alternative would be to make Ah the initial SMBASE.
 However, I would like to understand what hardware platforms plan to do,
if anything.

Paolo

> Mike
> 
>> -Original Message-
>> From: r...@edk2.groups.io [mailto:r...@edk2.groups.io] On
>> Behalf Of Yao, Jiewen
>> Sent: Sunday, August 18, 2019 4:01 PM
>> To: Paolo Bonzini 
>> Cc: Alex Williamson ; Laszlo
>> Ersek ; devel@edk2.groups.io; edk2-
>> rfc-groups-io ; qemu devel list
>> ; Igor Mammedov
>> ; Chen, Yingwen
>> ; Nakajima, Jun
>> ; Boris Ostrovsky
>> ; Joao Marcal Lemos Martins
>> ; Phillip Goerl
>> 
>> Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug using
>> SMM with QEMU+OVMF
>>
>> 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.
>>
>> thank you!
>> Yao, Jiewen
>>
>>
>>> 在 2019年8月19日，上午3:50，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 (#46171): https://edk2.groups.io/g/devel/message/46171
Mute This Topic: https://groups.io/mt/32979681/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH] BaseTools: Support long file path in windows for misc functions

[Steven Shi]

From: "Shi, Steven" 

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

Current CopyFileOnChange() and SaveFileOnChange() in
BaseTools\Source\Python\Common\Misc.py don't use the dedicated
long file path API to handle the file path strings and cannot
support the long file path copy and save in windows. This patch
enhances them to support the long file path copy and save
correctly.

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Steven Shi 
---
 BaseTools/Source/Python/Common/Misc.py | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/Common/Misc.py 
b/BaseTools/Source/Python/Common/Misc.py
index 4799635cc4..15ae6a9e40 100755
--- a/BaseTools/Source/Python/Common/Misc.py
+++ b/BaseTools/Source/Python/Common/Misc.py
@@ -34,6 +34,8 @@ from Common.BuildToolError import *
 from CommonDataClass.DataClass import *
 from Common.Parsing import GetSplitValueList
 from Common.LongFilePathSupport import OpenLongFilePath as open
+from Common.LongFilePathSupport import CopyLongFilePath as CopyLong
+from Common.LongFilePathSupport import LongFilePath as LongFilePath
 from Common.MultipleWorkspace import MultipleWorkspace as mws
 from CommonDataClass.Exceptions import BadExpression
 from Common.caching import cached_property
@@ -450,6 +452,9 @@ def RemoveDirectory(Directory, Recursively=False):
 #
 def SaveFileOnChange(File, Content, IsBinaryFile=True, FileLock=None):
 
+# Convert to long file path format
+File = LongFilePath(File)
+
 if os.path.exists(File):
 if IsBinaryFile:
 try:
@@ -530,6 +535,11 @@ def SaveFileOnChange(File, Content, IsBinaryFile=True, 
FileLock=None):
 #   @retval False No copy really happen
 #
 def CopyFileOnChange(SrcFile, Dst, FileLock=None):
+
+# Convert to long file path format
+SrcFile = LongFilePath(SrcFile)
+Dst = LongFilePath(Dst)
+
 if not os.path.exists(SrcFile):
 return False
 
@@ -561,7 +571,7 @@ def CopyFileOnChange(SrcFile, Dst, FileLock=None):
 # copy the src to a temp file in the dst same folder firstly, then
 # replace or rename the temp file to the destination file.
 with tempfile.NamedTemporaryFile(dir=DirName, delete=False) as tf:
-shutil.copy(SrcFile, tf.name)
+CopyLong(SrcFile, tf.name)
 tempname = tf.name
 try:
 if hasattr(os, 'replace'):
-- 
2.17.1


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

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

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

[Michael D Kinney]

Could we have an initial SMBASE that is within TSEG.

If we bring in hot plug CPUs one at a time, then initial
SMBASE in TSEG can reprogram the SMBASE to the correct 
value for that CPU.

Can we add a register to the hot plug controller that
allows the BSP to set the initial SMBASE value for 
a hot added CPU?  The default can be 3000:8000 for
compatibility.

Another idea is when the SMI handler runs for a hot add
CPU event, the SMM monarch programs the hot plug controller
register with the SMBASE to use for the CPU that is being
added.  As each CPU is added, a different SMBASE value can
be programmed by the SMM Monarch.

Mike

> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Wednesday, August 21, 2019 10:06 AM
> To: Kinney, Michael D ;
> r...@edk2.groups.io; Yao, Jiewen 
> Cc: Alex Williamson ; Laszlo
> Ersek ; devel@edk2.groups.io; qemu
> devel list ; Igor Mammedov
> ; Chen, Yingwen
> ; Nakajima, Jun
> ; Boris Ostrovsky
> ; Joao Marcal Lemos Martins
> ; Phillip Goerl
> 
> Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug using
> SMM with QEMU+OVMF
> 
> On 21/08/19 17:48, Kinney, Michael D wrote:
> > Perhaps there is a way to avoid the 3000:8000 startup
> vector.
> >
> > If a CPU is added after a cold reset, it is already in
> a different
> > state because one of the active CPUs needs to release
> it by
> > interacting with the hot plug controller.
> >
> > Can the SMRR for CPUs in that state be pre-programmed
> to match the
> > SMRR in the rest of the active CPUs?
> >
> > For OVMF we expect all the active CPUs to use the same
> SMRR value, so
> > a check can be made to verify that all the active CPUs
> have the same
> > SMRR value.  If they do, then any CPU released through
> the hot plug
> > controller can have its SMRR pre-programmed and the
> initial SMI will
> > start within TSEG.
> >
> > We just need to decide what to do in the unexpected
> case where all the
> > active CPUs do not have the same SMRR value.
> >
> > This should also reduce the total number of steps.
> 
> The problem is not the SMRR but the SMBASE.  If the
> SMBASE area is outside TSEG, it is vulnerable to DMA
> attacks independent of the SMRR.
> SMBASE is also different for all CPUs, so it cannot be
> preprogrammed.
> 
> (As an aside, virt platforms are also immune to cache
> poisoning so they don't have SMRR yet - we could use
> them for SMM_CODE_CHK_EN and block execution outside
> SMRR but we never got round to it).
> 
> An even simpler alternative would be to make Ah the
> initial SMBASE.
>  However, I would like to understand what hardware
> platforms plan to do, if anything.
> 
> Paolo
> 
> > Mike
> >
> >> -Original Message-
> >> From: r...@edk2.groups.io [mailto:r...@edk2.groups.io]
> On Behalf Of
> >> Yao, Jiewen
> >> Sent: Sunday, August 18, 2019 4:01 PM
> >> To: Paolo Bonzini 
> >> Cc: Alex Williamson ;
> Laszlo Ersek
> >> ; devel@edk2.groups.io; edk2- rfc-
> groups-io
> >> ; qemu devel list  de...@nongnu.org>; Igor
> >> Mammedov ; Chen, Yingwen
> >> ; Nakajima, Jun
> ;
> >> Boris Ostrovsky ; Joao
> Marcal Lemos
> >> Martins ; Phillip Goerl
> >> 
> >> Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug
> using SMM with
> >> QEMU+OVMF
> >>
> >> 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.
> >>
> >> thank you!
> >> Yao, Jiewen
> >>
> >>
> >>> 在 2019年8月19日，上午3:50，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 

Re: [edk2-devel] [edk2-test][Patch 1/1] uefi-sct/SctPkg: Eliminate 2nd execution of ExitBootServices Test

[Supreeth Venkatesh]

On Wed, 2019-08-21 at 01:24 -0500, Eric Jin wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2098
Please add the details of the patch to the commit message.
"In the ExitBootServices() test, after ExitBootServices() call, all
boot services are forbidden. The original design is to save the return
status value of ExitBootServices() in variable using variable service
and reset, but this needs multiple execution of the test to retrieve
the value from variable and this design was not straightforward from
end user perspective.

This patch enhances the test by leveraging RecoveryLib to restore
execution after reset automatically, thus requiring only one execution"

More comments inline...

> 
> Cc: Supreeth Venkatesh 
> Signed-off-by: Eric Jin 
> ---
>  uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> ImageBBTest.inf  |  3 ++-
>  uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> ImageBBTest.h|  9 -
>  uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> ImageBBTestConformance.c | 98
> +
> ++---
>  3 files changed, 93 insertions(+), 17 deletions(-)
> 
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> ImageBBTest.inf b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> ImageBBTest.inf
> index 49ad79915934..3de43a20e8a4 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> ImageBBTest.inf
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> ImageBBTest.inf
> @@ -1,7 +1,7 @@
>  ## @file
>  #
>  #  Copyright 2006 - 2012 Unified EFI, Inc.
> -#  Copyright (c) 2010 - 2012, Intel Corporation. All rights
> reserved.
> +#  Copyright (c) 2010 - 2019, Intel Corporation. All rights
> reserved.
>  #
>  #  This program and the accompanying materials
>  #  are licensed and made available under the terms and conditions of
> the BSD License
> @@ -53,4 +53,5 @@
>  
>  [Protocols]
>gEfiTestProfileLibraryGuid
> +  gEfiTestRecoveryLibraryGuid
>gBlackBoxEfiHIIPackageListProtocolGuid
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> ImageBBTest.h b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> ImageBBTest.h
> index b1c35fee7435..008584577ed1 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> ImageBBTest.h
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> ImageBBTest.h
> @@ -1,7 +1,7 @@
>  /** @file
>  
>Copyright 2006 - 2017 Unified EFI, Inc.
> -  Copyright (c) 2010 - 2017, Intel Corporation. All rights
> reserved.
> +  Copyright (c) 2010 - 2019, Intel Corporation. All rights
> reserved.
>  
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of
> the BSD License
> @@ -35,6 +35,13 @@ Abstract:
>  #include EFI_PROTOCOL_DEFINITION (LoadFile)
>  
>  #include EFI_TEST_PROTOCOL_DEFINITION (TestProfileLibrary)
> +#include EFI_TEST_PROTOCOL_DEFINITION (TestRecoveryLibrary)
> +
> +typedef struct _RESET_DATA {
> +  UINTN   Step;
> +  UINTN   TplIndex;
> +  UINT32  RepeatTimes;
> +} RESET_DATA;
>  
>  #if (EFI_SPECIFICATION_VERSION >= 0x0002000A)
>  
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> ImageBBTestConformance.c b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> ImageBBTestConformance.c
> index 0a26d46847da..e90afe7ecae0 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> ImageBBTestConformance.c
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/
> ImageBBTestConformance.c
> @@ -1,7 +1,7 @@
>  /** @file
>  
>Copyright 2006 - 2016 Unified EFI, Inc.
> -  Copyright (c) 2010 - 2016, Intel Corporation. All rights
> reserved.
> +  Copyright (c) 2010 - 2019, Intel Corporation. All rights
> reserved.
>  
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of
> the BSD License
> @@ -30,7 +30,8 @@ Abstract:
>  #define TEST_VENDOR1_GUID \
>{ 0xF6FAB04F, 0xACAF, 0x4af3, { 0xB9, 0xFA, 0xDC, 0xF9, 0x7F,
> 0xB4, 0x42, 0x6F } }
>  
> -#define MAX_BUFFER_SIZE  10
> +#define STATUS_BUFFER_SIZE   8
Why is the size being reduced by 2 bytes?
Was the earlier size not optimal?

> +#define RECOVER_BUFFER_SIZE  1024
>  
>  EFI_GUID gTestVendor1Guid = TEST_VENDOR1_GUID;
>  
> @@ -778,19 +779,23 @@ BBTestExitBootServicesConsistencyTest (
>)
>  {
>EFI_STANDARD_TEST_LIBRARY_PROTOCOL   *StandardLib;
> +  EFI_TEST_RECOVERY_LIBRARY_PROTOCOL   *RecoveryLib;
>EFI_STATUS   

Re: [edk2-devel] [PATCH v5 08/35] OvmfPkg/XenResetVector: Allow jumpstart from either hvmloader or PVH

[Laszlo Ersek]

Hi Anthony,

On 08/13/19 13:30, Anthony PERARD wrote:
> This patch allows the ResetVector to be run indenpendently from build
> time addresses.
> 
> The goal of the patch is to avoid having to create RAM just below 4G
> when creating a Xen PVH guest while being compatible with the way
> hvmloader currently load OVMF, just below 4G.
> 
> Only the new PVH entry point will do the calculation.
> 
> The ResetVector will figure out its current running address by creating
> a temporary stack, make a call and calculate the difference between the
> build time address and the address at run time.
> 
> This patch copies and make the necessary modification to some other asm
> files:
> - copy of UefiCpuPkg/.../Flat32ToFlat64.asm:
>   Allow Transition32FlatTo64Flat to be run from anywhere in memory
> - copy of UefiCpuPkg/../SearchForBfvBase.asm:
>   Add a extra parameter to indicate where to start the search for the
>   boot firmware volume.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
> Signed-off-by: Anthony PERARD 
> Acked-by: Laszlo Ersek 
> ---
> 
> Notes:
> v3:
> - rebased, SPDX
> - fix commit message
> 
>  .../XenResetVector/Ia16/Real16ToFlat32.asm|  3 +
>  .../XenResetVector/Ia32/Flat32ToFlat64.asm| 68 +++
>  .../XenResetVector/Ia32/SearchForBfvBase.asm  | 87 +++
>  OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm| 43 +++--
>  4 files changed, 194 insertions(+), 7 deletions(-)
>  create mode 100644 OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm
>  create mode 100644 OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm
> 
> diff --git a/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm 
> b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
> index 5c329bfaea..36ea74f7fe 100644
> --- a/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
> +++ b/OvmfPkg/XenResetVector/Ia16/Real16ToFlat32.asm
> @@ -54,6 +54,9 @@ jumpTo32BitAndLandHere:
>  mov gs, ax
>  mov ss, ax
>  
> +; parameter for Flat32SearchForBfvBase
> +xor eax, eax ; Start searching from top of 4GB for BfvBase
> +
>  OneTimeCallRet TransitionFromReal16To32BitFlat
>  
>  ALIGN   2
> diff --git a/OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm 
> b/OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm
> new file mode 100644
> index 00..661a8e7028
> --- /dev/null
> +++ b/OvmfPkg/XenResetVector/Ia32/Flat32ToFlat64.asm
> @@ -0,0 +1,68 @@
> +;--
> +; @file
> +; Transition from 32 bit flat protected mode into 64 bit flat protected mode
> +;
> +; Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.
> +; Copyright (c) 2019, Citrix Systems, Inc.
> +;
> +; SPDX-License-Identifier: BSD-2-Clause-Patent
> +;
> +;--
> +
> +BITS32
> +
> +;
> +; Modified:  EAX, EBX, ECX, EDX, ESP
> +;
> +Transition32FlatTo64Flat:
> +
> +OneTimeCall SetCr3ForPageTables64
> +
> +mov eax, cr4
> +bts eax, 5  ; enable PAE
> +mov cr4, eax
> +
> +mov ecx, 0xc080
> +rdmsr
> +bts eax, 8  ; set LME
> +wrmsr
> +
> +mov eax, cr0
> +bts eax, 31 ; set PG
> +mov cr0, eax; enable paging
> +
> +;
> +; backup ESP
> +;
> +mov ebx, esp
> +
> +;
> +; recalculate delta
> +;
> +mov esp, PVH_SPACE(16)
> +call.delta
> +.delta:
> +pop edx
> +sub edx, ADDR_OF(.delta)
> +
> +;
> +; push return addr and seg to the stack, then return far
> +;
> +pushdword LINEAR_CODE64_SEL
> +mov eax, ADDR_OF(jumpTo64BitAndLandHere)
> +add eax, edx ; add delta
> +pusheax
> +retf
> +
> +BITS64
> +jumpTo64BitAndLandHere:
> +
> +;
> +; restore ESP
> +;
> +mov esp, ebx
> +
> +debugShowPostCode POSTCODE_64BIT_MODE
> +
> +OneTimeCallRet Transition32FlatTo64Flat
> +
> diff --git a/OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm 
> b/OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm
> new file mode 100644
> index 00..190389c46f
> --- /dev/null
> +++ b/OvmfPkg/XenResetVector/Ia32/SearchForBfvBase.asm
> @@ -0,0 +1,87 @@
> +;--
> +; @file
> +; Search for the Boot Firmware Volume (BFV) base address
> +;
> +; Copyright (c) 2008 - 2009, Intel Corporation. All rights reserved.
> +; Copyright (c) 2019, Citrix Systems, Inc.
> +;
> +; SPDX-License-Identifier: BSD-2-Clause-Patent
> +;
> +;--
> +
> +;#define EFI_FIRMWARE_FILE_SYSTEM2_GUID \
> +;  { 0x8c8ce578, 0x8a3d, 0x4f1c, { 0x99, 0x35, 0x89, 0x61, 0x85, 0xc3, 0x2d, 
> 0xd3 } }
> +%define FFS_GUID_DWORD0 0x8c8ce578
> +%define FFS_GUID_DWORD1 0x4f1c8a3d
> +%define 

Re: [edk2-devel] [PATCH v5 00/35] Specific platform to run OVMF in Xen PVH and HVM guests

[Laszlo Ersek]

On 08/15/19 13:03, Laszlo Ersek wrote:
> On 08/13/19 13:30, Anthony PERARD wrote:
>> Patch series available in this git branch:
>> https://xenbits.xen.org/git-http/people/aperard/ovmf.git 
>> br.platform-xen-pvh-v5
>>
>> Changes in v5:
>> - patch 23 got a rework of the lapic range skipping
>> - small fixups in patch 20, 22, 23, 31, 32, 33.
>>   see notes for detail.
> 
> This series is now fully covered with maintainer R-b's and A-b's.
> 
> I've also done some regression-tests, after applying the set in a topic
> branch on top of commit caa7d3a896f6 ("BaseTools/Scripts: Add
> GetUtcDateTime script.", 2019-08-15). Including build tests and my usual
> boot & S3 tests.
> 
> Building for DEBUG (with GCC48) requires the independent fix
> 
>   [edk2-devel] [PATCH 1/1]
>   MdeModulePkg/DxeIplPeim: Initialize pointer PageMapLevel5Entry
> 
> which was posted at
> 
>   20190814073741.16080-1-shenglei.zhang@intel.com">http://mid.mail-archive.com/20190814073741.16080-1-shenglei.zhang@intel.com
>   https://edk2.groups.io/g/devel/message/45591
> 
> (again, that issue is independent of this series). With that independent
> fix, RELEASE builds fine too.
> 
> Given that this v5 feature series has now been fully reviewed before
> entering the Soft Feature Freeze for edk2-stable201908 -- which will
> commence on 2019-08-16 at 00:00:00 UTC-8) --, the set is eligible for
> pushing during the Soft Feature Freeze:
> 
>   
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
>   https://github.com/tianocore/tianocore.github.io/wiki/SoftFeatureFreeze
> 
> Therefore I'll push v5 no later than 2019-Aug-21, unless a NACK arrives
> before that date, from xen-devel or elsewhere.

Pushed as commit range 30781febe210..1237517b2130.

Thanks!
Laszlo

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

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

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

[Michael D Kinney]

Perhaps there is a way to avoid the 3000:8000 startup
vector.

If a CPU is added after a cold reset, it is already in a
different state because one of the active CPUs needs to
release it by interacting with the hot plug controller.

Can the SMRR for CPUs in that state be pre-programmed to
match the SMRR in the rest of the active CPUs?

For OVMF we expect all the active CPUs to use the same
SMRR value, so a check can be made to verify that all 
the active CPUs have the same SMRR value.  If they do,
then any CPU released through the hot plug controller 
can have its SMRR pre-programmed and the initial SMI
will start within TSEG.

We just need to decide what to do in the unexpected 
case where all the active CPUs do not have the same
SMRR value.

This should also reduce the total number of steps.

Mike

> -Original Message-
> From: r...@edk2.groups.io [mailto:r...@edk2.groups.io] On
> Behalf Of Yao, Jiewen
> Sent: Sunday, August 18, 2019 4:01 PM
> To: Paolo Bonzini 
> Cc: Alex Williamson ; Laszlo
> Ersek ; devel@edk2.groups.io; edk2-
> rfc-groups-io ; qemu devel list
> ; Igor Mammedov
> ; Chen, Yingwen
> ; Nakajima, Jun
> ; Boris Ostrovsky
> ; Joao Marcal Lemos Martins
> ; Phillip Goerl
> 
> Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug using
> SMM with QEMU+OVMF
> 
> 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.
> 
> thank you!
> Yao, Jiewen
> 
> 
> > 在 2019年8月19日，上午3:50，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 (#46165): https://edk2.groups.io/g/devel/message/46165
Mute This Topic: https://groups.io/mt/32979681/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 07/28] OvmfPkg/PlatformPei: Move early GDT into ram when SEV-ES is enabled

[Laszlo Ersek]

On 08/19/19 23:35, Lendacky, Thomas wrote:
> From: Tom Lendacky 
> 
> The SEV support will clear the C-bit from non-RAM areas.  The early GDT
> lives in a non-RAM area, so when an exception occurs (like a #VC) the GDT
> will be read as un-encrypted even though it is encrypted. This will result
> in a failure to be able to handle the exception.
> 
> Move the GDT into RAM so it can be accessed without error when running as
> an SEV-ES guest.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  OvmfPkg/PlatformPei/AmdSev.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/OvmfPkg/PlatformPei/AmdSev.c b/OvmfPkg/PlatformPei/AmdSev.c
> index 87ac842a1590..5f4983fd36d8 100644
> --- a/OvmfPkg/PlatformPei/AmdSev.c
> +++ b/OvmfPkg/PlatformPei/AmdSev.c
> @@ -37,6 +37,8 @@ AmdSevEsInitialize (
>PHYSICAL_ADDRESS  GhcbBasePa;
>UINTN GhcbPageCount;
>RETURN_STATUS DecryptStatus, PcdStatus;
> +  IA32_DESCRIPTOR   Gdtr;
> +  VOID  *Gdt;
>  
>if (!MemEncryptSevEsIsEnabled ()) {
>  return;
> @@ -76,6 +78,20 @@ AmdSevEsInitialize (
>DEBUG ((DEBUG_INFO, "SEV-ES is enabled, %u GHCB pages allocated starting 
> at 0x%lx\n", GhcbPageCount, GhcbBase));
>  
>AsmWriteMsr64 (MSR_SEV_ES_GHCB, (UINT64)GhcbBasePa);
> +
> +  //
> +  // The SEV support will clear the C-bit from the non-RAM areas. Since
> +  // the GDT initially lives in that area and it will be read when a #VC
> +  // exception happens, it needs to be moved to RAM for an SEV-ES guest.
> +  //
> +  AsmReadGdtr ();
> +
> +  Gdt = AllocatePool (Gdtr.Limit + 1);
> +  ASSERT (Gdt);
> +
> +  CopyMem (Gdt, (VOID *) Gdtr.Base, Gdtr.Limit + 1);
> +  Gdtr.Base = (UINTN) Gdt;
> +  AsmWriteGdtr ();
>  }
>  
>  /**
> 

This doesn't look safe enough to me.

AllocatePool() in the PEI phase means the creation of an
EFI_HOB_TYPE_MEMORY_POOL HOB. The data allocated lives inside the HOB.
According to the PI spec v1.7, volume 3, section "4.5.2 HOB Construction
Rules":

  3. HOBs may be relocated in system memory by the HOB consumer phase.
 HOBs must not contain pointers to other data in the HOB list,
 including that in other HOBs. The table must be able to be copied
 without requiring internal pointer adjustment.

Additionally, in section "5.9 Memory Pool HOB",

  [...] The HOB consumer phase should be able to ignore these HOBs [...]

which seems to imply that the HOB might not survive into DXE at all (the
memory could be released and repurposed).

I don't feel good about pointing the GDTR into such a possibly ephemeral
HOB, even if we reload the GDTR with a different GDT address at a later
time.

Instead, I suggest AllocatePages().

AmdSevEsInitialize() is invoked as part of AmdSevInitialize(), which in
turn is invoked after PublishPeiMemory() returns. Therefore, using
AllocatePages() instead of AllocatePool() should be safe -- the address
produced by AllocatePages() should be stable.

Namely, in PI v1.7, volume 1, section "4.6 PEI Memory Services",
AllocatePages() is specified as:

  [...] Allocation made prior to permanent memory will be migrated to
  permanent memory [...] After InstallPeiMemory() is called, PEI will
  allocate pages within the region of memory provided by
  InstallPeiMemory() service [...]

The edk2 code agrees -- PublishPeiMemory() in OVMF's PlatformPei
exercises PeiInstallPeiMemory()
[MdeModulePkg/Core/Pei/Memory/MemoryServices.c], which sets
"SwitchStackSignal". Although actual RAM migration doesn't happen until
after PlatformPei exits, PeiAllocatePages() explicitly looks for

  (!PrivateData->PeiMemoryInstalled && PrivateData->SwitchStackSignal)

so it will do the right thing. As a result, AllocatePages() *before*
actual RAM migration (from temporary to permanent), but *after*
PeiInstallPeiMemory(), will allocate permanent memory.

Thanks
Laszlo

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

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

Re: [edk2-devel] [edk2-test][Patch V2 2/2] uefi-sct/SctPkg: Fix gBlackBoxEfiSimplePointerProtocolGuid value

[Supreeth Venkatesh]

On Tue, 2019-08-20 at 20:36 -0500, Eric Jin wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1571
> 
> Cc: Supreeth Venkatesh 
> Signed-off-by: Eric Jin 

  Matches UEFI v2.7 Specification.
  Reviewed-by: Supreeth Venkatesh 
> ---
>  uefi-sct/SctPkg/UEFI/UEFI.dec | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/uefi-sct/SctPkg/UEFI/UEFI.dec b/uefi-
> sct/SctPkg/UEFI/UEFI.dec
> index c05fccdd9c10..e8f04e96f520 100644
> --- a/uefi-sct/SctPkg/UEFI/UEFI.dec
> +++ b/uefi-sct/SctPkg/UEFI/UEFI.dec
> @@ -164,7 +164,7 @@
>gBlackBoxEfiSerialIoProtocolGuid = { 0xBB25CF6F, 0xF1D4, 0x11D2, {
> 0x9A, 0x0C, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0xFD }}
>gBlackBoxEfiSimpleFileSystemProtocolGuid = { 0x964e5b22, 0x6459,
> 0x11d2, { 0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b }}
>gBlackBoxEfiSimpleNetworkProtocolGuid = { 0xA19832B9, 0xAC25,
> 0x11D3, { 0x9A, 0x2D, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D }}
> -  gBlackBoxEfiSimplePointerProtocolGuid = { 0xA19832B9, 0xAC25,
> 0x11D3, { 0x9A, 0x2D, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D }}
> +  gBlackBoxEfiSimplePointerProtocolGuid = { 0x31878c87, 0xb75,
> 0x11d5, { 0x9a, 0x4f, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d }}
>gBlackBoxEfiSimpleTextInProtocolGuid = { 0x387477c1, 0x69c7,
> 0x11d2, {0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b }}
>gBlackBoxEfiSimpleTextInputExProtocolGuid = { 0xdd9e7534, 0x7762,
> 0x4698, { 0x8c, 0x14, 0xf5, 0x85, 0x17, 0xa6, 0x25, 0xaa }}
>gBlackBoxEfiSimpleTextOutProtocolGuid = { 0x387477C2, 0x69C7,
> 0x11D2, { 0x8E, 0x39, 0x00, 0xA0, 0xC9, 0x69, 0x72, 0x3B }}


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

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

Re: [edk2-devel] [edk2-test][Patch V2 1/2] uefi-sct/SctPkg: Convert EOL of UEFI.dec to CRLF

[Supreeth Venkatesh]

On Tue, 2019-08-20 at 20:36 -0500, Eric Jin wrote:
> Cc: Supreeth Venkatesh 
> Signed-off-by: Eric Jin 
Reviewed-by: Supreeth Venkatesh 

> ---
>  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..c05fccdd9c10 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, 

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

[Donald Kuo]

Thanks Liming help :)

Donald
> -Original Message-
> From: Gao, Liming
> Sent: Wednesday, August 21, 2019 9:46 PM
> To: Zeng, Star ; Kuo, Donald ;
> devel@edk2.groups.io; ler...@redhat.com; Dong, Eric
> 
> Cc: Ni, Ray ; 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
> 
> Done. And, push @30781febe2106cc0d7186e70136120353cd67df2
> 
> Thanks
> Liming
> > -Original Message-
> > From: Zeng, Star
> > Sent: Tuesday, August 20, 2019 10:00 PM
> > To: Gao, Liming ; Kuo, Donald
> > ; devel@edk2.groups.io; ler...@redhat.com;
> Dong,
> > Eric 
> > Cc: Ni, Ray ; Chan, Amy ;
> > Chaganty, Rangasai V ; Lai, Luke
> > ; Li, Kevin Y ;
> > leif.lindh...@linaro.org; af...@apple.com; Kinney, Michael D
> > ; Zeng, Star 
> > Subject: RE: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library
> > by using CPUID(0x15) TSC leaf
> >
> > Remember to add entry for it at
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-
> Planning.
> >
> > > -Original Message-
> > > From: Gao, Liming
> > > Sent: Tuesday, August 20, 2019 7:56 PM
> > > To: Kuo, Donald ; devel@edk2.groups.io;
> > > ler...@redhat.com; Dong, Eric 
> > > 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
> > >
> > > Donald:
> > >   Thanks for your update. If no other comment, I will help push this
> > > patch tomorrow.
> > >
> > > Thanks
> > > Liming
> > > > -Original Message-
> > > > From: Kuo, Donald
> > > > Sent: Tuesday, August 20, 2019 3:22 PM
> > > > To: Gao, Liming ; devel@edk2.groups.io;
> > > > ler...@redhat.com; Dong, Eric 
> > > > 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
> > > >
> > > > Hi Liming,
> > > >
> > > > Done.
> > > >
> > > > Patch is attached to
> > > > https://bugzilla.tianocore.org/show_bug.cgi?id=1909
> > > >
> > > > Another BZ to apply CpuTimerLib will be tracking on:
> > > > https://bugzilla.tianocore.org/show_bug.cgi?id=2096
> > > >
> > > > Thanks,
> > > > Donald
> > > >
> > > > > -Original Message-
> > > > > From: Gao, Liming
> > > > > Sent: Tuesday, August 20, 2019 2:51 PM
> > > > > To: Kuo, Donald ; devel@edk2.groups.io;
> > > > > ler...@redhat.com; Dong, Eric 
> > > > > 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
> > > > >
> > > > > Donald:
> > > > >   Please also attach the patch linker in BZs.
> > > > >
> > > > >   And, please submit another BZ for edk2-
> > > > > platforms\Platform\Intel\KabylakeOpenBoardPkg to apply this new
> > > > > library instance.
> > > > >
> > > > > Thanks
> > > > > Liming
> > > > > >-Original Message-
> > > > > >From: Kuo, Donald
> > > > > >Sent: Tuesday, August 20, 2019 10:44 AM
> > > > > >To: devel@edk2.groups.io; ler...@redhat.com; Gao, Liming
> > > > > >; Dong, Eric 
> > > > > >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
> > > > > >
> > > > > >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, 

[edk2-devel] [PATCH v1 1/1] MdePkg: UefiLib: Add a function to check if a language is supported

[Tom Zhao]

Add a function that checks if a target language is in the supported
languages list. Add some calls to this function where appropriate in
UefiLib.c

Cc: Michael D Kinney 
Cc: Liming Gao 
Signed-off-by: Tom Zhao 
---
 MdePkg/Include/Library/UefiLib.h | 16 ++
 MdePkg/Library/UefiLib/UefiLib.c | 59 +---
 2 files changed, 54 insertions(+), 21 deletions(-)

diff --git a/MdePkg/Include/Library/UefiLib.h
b/MdePkg/Include/Library/UefiLib.h
index 1650f30ddbc6..9dd170cbe2bf 100644
--- a/MdePkg/Include/Library/UefiLib.h
+++ b/MdePkg/Include/Library/UefiLib.h
@@ -461,6 +461,22 @@ EfiTestChildHandle (
   IN CONST EFI_GUID *ProtocolGuid
   );
 +/**
+ * This function checks the supported languages list for a target language
+ *
+ * @param  SupportedLanguages  The supported languages
+ * @param  TargetLanguage  The target language
+ *
+ * @return Returns EFI_SUCCESS if the language is supported,
+ * EFI_UNSUPPORTED otherwise
+ */
+EFI_STATUS
+EFIAPI
+IsLanguageSupported (
+  IN CONST CHAR8 *SupportedLanguages,
+  IN CONST CHAR8 *TargetLanguage
+  );
+
 /**
   This function looks up a Unicode string in UnicodeStringTable.
 diff --git a/MdePkg/Library/UefiLib/UefiLib.c
b/MdePkg/Library/UefiLib/UefiLib.c
index daa4af762e62..56281d25fd99 100644
--- a/MdePkg/Library/UefiLib/UefiLib.c
+++ b/MdePkg/Library/UefiLib/UefiLib.c
@@ -640,6 +640,35 @@ EfiTestChildHandle (
   return Status;
 }
 +/**
+ * This function checks the supported languages list for a target language
+ *
+ * @param  SupportedLanguages  The supported languages
+ * @param  TargetLanguage  The target language
+ *
+ * @return Returns EFI_SUCCESS if the language is supported,
+ * EFI_UNSUPPORTED otherwise
+ */
+EFI_STATUS
+EFIAPI
+IsLanguageSupported (
+  IN CONST CHAR8 *SupportedLanguages,
+  IN CONST CHAR8 *TargetLanguage
+  )
+{
+  UINTN Index;
+  while (*SupportedLanguages != 0) {
+for (Index = 0; SupportedLanguages[Index] != 0 &&
SupportedLanguages[Index] != ';'; Index++);
+if ((AsciiStrnCmp(SupportedLanguages, TargetLanguage, Index) == 0)
&& (TargetLanguage[Index] == 0)) {
+  return EFI_SUCCESS;
+}
+SupportedLanguages += Index;
+for (; *SupportedLanguages != 0 && *SupportedLanguages == ';';
SupportedLanguages++);
+  }
+
+  return EFI_UNSUPPORTED;
+}
+
 /**
   This function looks up a Unicode string in UnicodeStringTable.
 @@ -800,24 +829,19 @@ LookupUnicodeString2 (
   // Make sure Language is in the set of Supported Languages
   //
   Found = FALSE;
-  while (*SupportedLanguages != 0) {
-if (Iso639Language) {
+  if (Iso639Language) {
+while (*SupportedLanguages != 0) {
   if (CompareIso639LanguageCode (Language, SupportedLanguages)) {
 Found = TRUE;
 break;
   }
   SupportedLanguages += 3;
-} else {
-  for (Index = 0; SupportedLanguages[Index] != 0 &&
SupportedLanguages[Index] != ';'; Index++);
-  if ((AsciiStrnCmp(SupportedLanguages, Language, Index) == 0) &&
(Language[Index] == 0)) {
-Found = TRUE;
-break;
-  }
-  SupportedLanguages += Index;
-  for (; *SupportedLanguages != 0 && *SupportedLanguages == ';';
SupportedLanguages++);
 }
+  } else {
+Found = !IsLanguageSupported(Language, SupportedLanguages);
   }
 +
   //
   // If Language is not a member of SupportedLanguages, then return
EFI_UNSUPPORTED
   //
@@ -1099,24 +1123,17 @@ AddUnicodeString2 (
   // Make sure Language is a member of SupportedLanguages
   //
   Found = FALSE;
-  while (*SupportedLanguages != 0) {
-if (Iso639Language) {
+  if (Iso639Language) {
+while (*SupportedLanguages != 0) {
   if (CompareIso639LanguageCode (Language, SupportedLanguages)) {
 Found = TRUE;
 break;
   }
   SupportedLanguages += 3;
-} else {
-  for (Index = 0; SupportedLanguages[Index] != 0 &&
SupportedLanguages[Index] != ';'; Index++);
-  if (AsciiStrnCmp(SupportedLanguages, Language, Index) == 0) {
-Found = TRUE;
-break;
-  }
-  SupportedLanguages += Index;
-  for (; *SupportedLanguages != 0 && *SupportedLanguages == ';';
SupportedLanguages++);
 }
+  } else {
+Found = !IsLanguageSupported(Language, SupportedLanguages);
   }
-
   //
   // If Language is not a member of SupportedLanguages, then return
EFI_UNSUPPORTED
   //
-- 
2.21.0


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

View/Reply Online (#46160): https://edk2.groups.io/g/devel/message/46160
Mute This Topic: https://groups.io/mt/32977616/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 05/28] OvmfPkg: Create GHCB pages for use during Pei and Dxe phase

[Laszlo Ersek]

On 08/19/19 23:35, Lendacky, Thomas wrote:
> From: Tom Lendacky 
> 
> Allocate memory for the GHCB pages during SEV initialization for use
> during Pei and Dxe phases. Since the GHCB pages must be mapped as shared
> pages, modify CreateIdentityMappingPageTables() so that pagetable entries
> are created without the encryption bit set.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  UefiCpuPkg/UefiCpuPkg.dec |  4 ++
>  OvmfPkg/OvmfPkgX64.dsc|  4 ++
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf   |  3 +
>  OvmfPkg/PlatformPei/PlatformPei.inf   |  2 +
>  .../Core/DxeIplPeim/X64/VirtualMemory.h   | 12 +++-
>  .../Core/DxeIplPeim/Ia32/DxeLoadFunc.c|  4 +-
>  .../Core/DxeIplPeim/X64/DxeLoadFunc.c | 11 +++-
>  .../Core/DxeIplPeim/X64/VirtualMemory.c   | 49 ++
>  .../MemEncryptSevLibInternal.c|  1 -
>  .../BaseMemEncryptSevLib/X64/VirtualMemory.c  | 33 --
>  OvmfPkg/PlatformPei/AmdSev.c  | 64 +++
>  11 files changed, 164 insertions(+), 23 deletions(-)

Should be split to at least four patches (UefiCpuPkg, MdeModulePkg,
OvmfPkg/BaseMemEncryptSevLib, OvmfPkg/PlatformPei).

In addition, MdeModulePkg content must not depend on UefiCpuPkg content
-- if modules under both packages need to consume a new PCD, then the
PCD should be declared under MdeModulePkg. The rough dependency order is:

- MdePkg (must be self-contained)
- MdeModulePkg (may consume MdePkg)
- UefiCpuPkg (may consume everything above, to my knowledge)
- OvmfPkg (may consume everything above)

Thanks
Laszlo

> 
> diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
> index 6ddf0cd22466..4d5a2593cf13 100644
> --- a/UefiCpuPkg/UefiCpuPkg.dec
> +++ b/UefiCpuPkg/UefiCpuPkg.dec
> @@ -323,5 +323,9 @@ [PcdsDynamic, PcdsDynamicEx]
># @ValidRange  0x8001 | 0 - 1
>gUefiCpuPkgTokenSpaceGuid.PcdCpuProcTraceOutputScheme|0x0|UINT8|0x6015
>  
> +  ## Contains the GHCB page allocation information.
> +  gUefiCpuPkgTokenSpaceGuid.PcdGhcbBase|0x0|UINT64|0x6016
> +  gUefiCpuPkgTokenSpaceGuid.PcdGhcbSize|0x0|UINT64|0x6017
> +
>  [UserExtensions.TianoCore."ExtraFiles"]
>UefiCpuPkgExtra.uni
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index dda8dac18441..d6fc7cdf7da8 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -569,6 +569,10 @@ [PcdsDynamicDefault]
># Set memory encryption mask
>gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
>  
> +  # Set GHCB base address for SEV-ES
> +  gUefiCpuPkgTokenSpaceGuid.PcdGhcbBase|0x0
> +  gUefiCpuPkgTokenSpaceGuid.PcdGhcbSize|0x0
> +
>  !if $(SMM_REQUIRE) == TRUE
>gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8
>gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
> diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf 
> b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> index abc3217b0179..b994398633e3 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> +++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> @@ -52,6 +52,7 @@ [Sources.ARM, Sources.AARCH64]
>  [Packages]
>MdePkg/MdePkg.dec
>MdeModulePkg/MdeModulePkg.dec
> +  UefiCpuPkg/UefiCpuPkg.dec
>  
>  [Packages.ARM, Packages.AARCH64]
>ArmPkg/ArmPkg.dec
> @@ -110,6 +111,8 @@ [Pcd.IA32,Pcd.X64]
>gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask## 
> CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask   ## 
> CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard   ## 
> CONSUMES
> +  gUefiCpuPkgTokenSpaceGuid.PcdGhcbBase ## 
> CONSUMES
> +  gUefiCpuPkgTokenSpaceGuid.PcdGhcbSize ## 
> CONSUMES
>  
>  [Pcd.IA32,Pcd.X64,Pcd.ARM,Pcd.AARCH64]
>gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack   ## 
> SOMETIMES_CONSUMES
> diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
> b/OvmfPkg/PlatformPei/PlatformPei.inf
> index aed1f64b7c93..f53195e6dda5 100644
> --- a/OvmfPkg/PlatformPei/PlatformPei.inf
> +++ b/OvmfPkg/PlatformPei/PlatformPei.inf
> @@ -102,6 +102,8 @@ [Pcd]
>gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber
>gUefiCpuPkgTokenSpaceGuid.PcdCpuApInitTimeOutInMicroSeconds
>gUefiCpuPkgTokenSpaceGuid.PcdCpuApStackSize
> +  gUefiCpuPkgTokenSpaceGuid.PcdGhcbBase
> +  gUefiCpuPkgTokenSpaceGuid.PcdGhcbSize
>  
>  [FixedPcd]
>gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
> diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h 
> b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
> index 2d0493f109e8..6b7c38a441d6 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
> +++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
> @@ -201,6 +201,8 @@ EnableExecuteDisableBit (
>@param[in, out] PageEntry2M   Pointer to 2M page entry.
>@param[in]  StackBase Stack base address.
>@param[in]  StackSize  

Re: [edk2-devel] [PATCH v1 1/1] MdePkg: UefiLib: Add a function to check if a language is supported

[Tom Zhao]

Hi Liming

The function is only used inside UefiLib in the edk2 package, however, 
the intent was to use this in our UEFI implementation. I figured that 
others might find this functionality useful. The functions inside 
UefiLib were only modified for consistency.


Tom

On 21/08/2019 14:34, Liming Gao wrote:


Tom:

  Can you send the patch by the command ‘git send-email xxx.patch’? If 
so, I can extract the patch from the mail.


  If this function is only used in UefiLib, how about define it as the 
internal function?


Thanks

Liming

*From:*devel@edk2.groups.io [mailto:devel@edk2.groups.io] *On Behalf 
Of *Tom Zhao

*Sent:* Wednesday, August 21, 2019 6:23 PM
*To:* devel@edk2.groups.io
*Subject:* [edk2-devel] [PATCH v1 1/1] MdePkg: UefiLib: Add a function 
to check if a language is supported




 Forwarded Message 

*Subject: *



[PATCH v1 1/1] MdePkg: UefiLib: Add a function to check if a language 
is supported


*Date: *



Tue, 20 Aug 2019 17:13:19 +0100

*From: *



Tom Zhao  

*To: *



edk2-de...@lists.01.org 

*CC: *



michael.d.kin...@intel.com , 
liming@intel.com 




Add a function that checks if a target language is in the supported
languages list. Add some calls to this function where appropriate in
UefiLib.c

Cc: Michael D Kinney  


Cc: Liming Gao  
Signed-off-by: Tom Zhao  


---
MdePkg/Include/Library/UefiLib.h | 16 ++
MdePkg/Library/UefiLib/UefiLib.c | 59 +---
2 files changed, 54 insertions(+), 21 deletions(-)

diff --git a/MdePkg/Include/Library/UefiLib.h 
b/MdePkg/Include/Library/UefiLib.h

index 1650f30ddbc6..9dd170cbe2bf 100644
--- a/MdePkg/Include/Library/UefiLib.h
+++ b/MdePkg/Include/Library/UefiLib.h
@@ -461,6 +461,22 @@ EfiTestChildHandle (
IN CONST EFI_GUID *ProtocolGuid
);
+/**
+ * This function checks the supported languages list for a target 
language

+ *
+ * @param SupportedLanguages The supported languages
+ * @param TargetLanguage The target language
+ *
+ * @return Returns EFI_SUCCESS if the language is supported,
+ * EFI_UNSUPPORTED otherwise
+ */
+EFI_STATUS
+EFIAPI
+IsLanguageSupported (
+ IN CONST CHAR8 *SupportedLanguages,
+ IN CONST CHAR8 *TargetLanguage
+ );
+
/**
This function looks up a Unicode string in UnicodeStringTable.
diff --git a/MdePkg/Library/UefiLib/UefiLib.c 
b/MdePkg/Library/UefiLib/UefiLib.c

index daa4af762e62..56281d25fd99 100644
--- a/MdePkg/Library/UefiLib/UefiLib.c
+++ b/MdePkg/Library/UefiLib/UefiLib.c
@@ -640,6 +640,35 @@ EfiTestChildHandle (
return Status;
}
+/**
+ * This function checks the supported languages list for a target 
language

+ *
+ * @param SupportedLanguages The supported languages
+ * @param TargetLanguage The target language
+ *
+ * @return Returns EFI_SUCCESS if the language is supported,
+ * EFI_UNSUPPORTED otherwise
+ */
+EFI_STATUS
+EFIAPI
+IsLanguageSupported (
+ IN CONST CHAR8 *SupportedLanguages,
+ IN CONST CHAR8 *TargetLanguage
+ )
+{
+ UINTN Index;
+ while (*SupportedLanguages != 0) {
+ for (Index = 0; SupportedLanguages[Index] != 0 && 
SupportedLanguages[Index] != ';'; Index++);
+ if ((AsciiStrnCmp(SupportedLanguages, TargetLanguage, Index) == 0) 
&& (TargetLanguage[Index] == 0)) {

+ return EFI_SUCCESS;
+ }
+ SupportedLanguages += Index;
+ for (; *SupportedLanguages != 0 && *SupportedLanguages == ';'; 
SupportedLanguages++);

+ }
+
+ return EFI_UNSUPPORTED;
+}
+
/**
This function looks up a Unicode string in UnicodeStringTable.
@@ -800,24 +829,19 @@ LookupUnicodeString2 (
// Make sure Language is in the set of Supported Languages
//
Found = FALSE;
- while (*SupportedLanguages != 0) {
- if (Iso639Language) {
+ if (Iso639Language) {
+ while (*SupportedLanguages != 0) {
if (CompareIso639LanguageCode (Language, SupportedLanguages)) {
Found = TRUE;
break;
}
SupportedLanguages += 3;
- } else {
- for (Index = 0; SupportedLanguages[Index] != 0 && 
SupportedLanguages[Index] != ';'; Index++);
- if ((AsciiStrnCmp(SupportedLanguages, Language, Index) == 0) && 
(Language[Index] == 0)) {

- Found = TRUE;
- break;
- }
- SupportedLanguages += Index;
- for (; *SupportedLanguages != 0 && *SupportedLanguages == ';'; 
SupportedLanguages++);

}
+ } else {
+ Found = !IsLanguageSupported(Language, SupportedLanguages);
}
+
//
// If Language is not a member of SupportedLanguages, then return 
EFI_UNSUPPORTED

//
@@ -1099,24 +1123,17 @@ AddUnicodeString2 (
// Make sure Language is a member of SupportedLanguages
//
Found = FALSE;
- while (*SupportedLanguages != 0) {
- if (Iso639Language) {
+ if (Iso639Language) {
+ while (*SupportedLanguages != 0) {
if (CompareIso639LanguageCode (Language, SupportedLanguages)) {
Found = TRUE;
break;
}
SupportedLanguages += 3;
- } else {
- for (Index = 0; SupportedLanguages[Index] != 0 && 

Re: [edk2-devel] [RFC PATCH 04/28] OvmfPkg: Create a GHCB page for use during Sec phase

[Laszlo Ersek]

On 08/19/19 23:35, Lendacky, Thomas wrote:
> From: Tom Lendacky 
> 
> A GHCB page is needed during the Sec phase, so this new page must be
> created.  Since the GHCB must be marked as an un-encrypted, or shared,
> page, an additional pagetable page is required so break down the 2MB
> region where the GHCB page lives into 4K pagetable entries.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  OvmfPkg/OvmfPkg.dec|  5 +++
>  OvmfPkg/OvmfPkgX64.fdf | 11 ---
>  OvmfPkg/PlatformPei/PlatformPei.inf|  2 ++
>  OvmfPkg/ResetVector/ResetVector.inf|  2 ++
>  UefiCpuPkg/Include/Register/Amd/Fam17Msr.h | 28 
>  OvmfPkg/ResetVector/Ia32/PageTables64.asm  | 37 +-
>  OvmfPkg/ResetVector/ResetVector.nasmb  |  2 +-
>  7 files changed, 81 insertions(+), 6 deletions(-)

I've skipped patches 02 and 03 for now, because I'll have to go through
them with a fine toothed comb -- in a subsequent submission, most
probably. I'm just trying to provide formal comments, so that I do the
actual review more easily, later.

As I requested under the blurb, this patch should be split in at least
three parts, if possible -- OvmfPkg/PlatformPei, OvmfPkg/ResetVector,
UefiCpuPkg. (The DEC and FDF changes can be kept squashed with the
OvmfPkg patch that seems more suitable for that.)

... Having said that, why do you add PCDs to the PlatformPei INF file?
The code in PlatformPei doesn't change. Could be a leftover from an
earlier (abandoned) approach.

Thanks
Laszlo

> 
> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index 9640360f6245..2ead9a944af4 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -218,6 +218,11 @@ [PcdsFixedAtBuild]
>#  The value should be a multiple of 4KB.
>gUefiOvmfPkgTokenSpaceGuid.PcdHighPmmMemorySize|0x40|UINT32|0x31
>  
> +  ## Specify the GHCB base address and size.
> +  #  The value should be a multiple of 4KB for each.
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase|0x0|UINT32|0x32
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize|0x0|UINT32|0x33
> +
>  [PcdsDynamic, PcdsDynamicEx]
>gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
> diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
> index 74407072563b..2a2427092382 100644
> --- a/OvmfPkg/OvmfPkgX64.fdf
> +++ b/OvmfPkg/OvmfPkgX64.fdf
> @@ -67,13 +67,16 @@ [FD.MEMFD]
>  BlockSize = 0x1
>  NumBlocks = 0xC0
>  
> -0x00|0x006000
> +0x00|0x007000
>  
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
>  
> -0x006000|0x001000
> -gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
> -
>  0x007000|0x001000
> +gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize
> +
> +0x008000|0x001000
> +gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
> +
> +0x009000|0x001000
>  
> gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
>  
>  0x01|0x01
> diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
> b/OvmfPkg/PlatformPei/PlatformPei.inf
> index d9fd9c8f05b3..aed1f64b7c93 100644
> --- a/OvmfPkg/PlatformPei/PlatformPei.inf
> +++ b/OvmfPkg/PlatformPei/PlatformPei.inf
> @@ -72,6 +72,8 @@ [Pcd]
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
>gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
> diff --git a/OvmfPkg/ResetVector/ResetVector.inf 
> b/OvmfPkg/ResetVector/ResetVector.inf
> index 960b47cd0797..d66f4dc29737 100644
> --- a/OvmfPkg/ResetVector/ResetVector.inf
> +++ b/OvmfPkg/ResetVector/ResetVector.inf
> @@ -37,3 +37,5 @@ [Pcd]
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize
> diff --git a/UefiCpuPkg/Include/Register/Amd/Fam17Msr.h 
> b/UefiCpuPkg/Include/Register/Amd/Fam17Msr.h
> index 37b935dcdb30..55a5723e164e 100644
> --- a/UefiCpuPkg/Include/Register/Amd/Fam17Msr.h
> +++ b/UefiCpuPkg/Include/Register/Amd/Fam17Msr.h
> @@ -17,6 +17,34 @@
>  #ifndef __FAM17_MSR_H__
>  #define __FAM17_MSR_H__
>  
> +/**
> +  Secure Encrypted Virtualization - Encrypted State (SEV-ES) GHCB register
> +
> +**/
> +#define MSR_SEV_ES_GHCB0xc0010130
> +
> +/**
> +  MSR information 

Re: [edk2-devel] [RFC PATCH 01/28] OvmfPkg/Sec: Enable cache early to speed up booting

[Laszlo Ersek]

On 08/19/19 23:35, Lendacky, Thomas wrote:
> From: Tom Lendacky 
> 
> Currently, the OVMF code relies on the hypervisor to enable the cache
> support on the processor in order to improve the boot speed. However,
> with SEV-ES, the hypervisor is not allowed to change the CR0 register
> to enable caching.
> 
> Update the OVMF Sec support to enable caching in order to improve the
> boot speed.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  OvmfPkg/Sec/SecMain.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c
> index 3914355cd17b..2448be0cd408 100644
> --- a/OvmfPkg/Sec/SecMain.c
> +++ b/OvmfPkg/Sec/SecMain.c
> @@ -739,6 +739,11 @@ SecCoreStartupWithStack (
>  
>ProcessLibraryConstructorList (NULL, NULL);
>  
> +  //
> +  // Enable caching
> +  //
> +  AsmEnableCache ();
> +
>DEBUG ((EFI_D_INFO,
>  "SecCoreStartupWithStack(0x%x, 0x%x)\n",
>  (UINT32)(UINTN)BootFv,
> 

This makes me uncomfortable. There used to be problems related to
caching when VFIO device assignment were used. My concern is admittedly
vague, but this is a very brittle area of OVMF-on-KVM. If you asked me
"well what could break here", I'd answer "you never know, and the burden
of proof is not on me". :) Can we make this change conditional on SEV-ES?

Thanks
Laszlo

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

View/Reply Online (#46156): https://edk2.groups.io/g/devel/message/46156
Mute This Topic: https://groups.io/mt/32966275/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 00/28] SEV-ES guest support

[Laszlo Ersek]

Hi Tom,

On 08/19/19 23:35, Lendacky, Thomas wrote:
> From: Tom Lendacky 
> 
> This patch series provides support for running EDK2/OVMF under SEV-ES.
> 
> Secure Encrypted Virtualization - Encrypted State (SEV-ES) expands on the
> SEV support to protect the guest register state from the hypervisor. See
> "AMD64 Architecture Programmer's Manual Volume 2: System Programming",
> section "15.35 Encrypted State (SEV-ES)" [1].
> 
> In order to allow a hypervisor to perform functions on behalf of a guest,
> there is architectural support for notifying a guest's operating system
> when certain types of VMEXITs are about to occur. This allows the guest to
> selectively share information with the hypervisor to satisfy the requested
> function. The notification is performed using a new exception, the VMM
> Communication exception (#VC). The information is shared through the
> Guest-Hypervisor Communication Block (GHCB) using the VMGEXIT instruction.
> The GHCB format and the protocol for using it is documented in "SEV-ES
> Guest-Hypervisor Communication Block Standardization" [2].
> 
> The main areas of the EDK2 code that are updated to support SEV-ES are
> around the exception handling support and the AP boot support.
> 
> Exception support is required starting in Sec, continuing through Pei
> and into Dxe in order to handle #VC exceptions that are generated.  Each
> AP requires it's own GHCB page as well as a page to hold values specific
> to that AP.
> 
> AP booting poses some interesting challenges. The INIT-SIPI-SIPI sequence
> is typically used to boot the APs. However, the hypervisor is not allowed
> to update the guest registers. The GHCB document [2] talks about how SMP
> booting under SEV-ES is performed.
> 
> Since the GHCB page must be a shared (unencrypted) page, the processor
> must be running in long mode in order for the guest and hypervisor to
> communicate with each other. As a result, SEV-ES is only supported under
> the X64 architecture.
> 
> [1] https://www.amd.com/system/files/TechDocs/24593.pdf
> [2] https://developer.amd.com/wp-content/resources/56421.pdf
> [3] https://github.com/AMDESE/ovmf/tree/sev-es-v6

some very high level comments first.

(1) If there is any way, please avoid modifying multiple top-level
directories in a single patch. For example, a patch that currently
modifies both OvmfPkg and UefiCpuPkg, should be split in at least two,
but possibly three, parts. Otherwise, it becomes very difficult to
isolate reviewer responsibilities.

Furthermore, if you can split changes even inside a top-level package
directory, along module boundaries (such that a patch only modify a
single library instance or a driver module, if possible), that's
appreciated.

Clearly this would result in an even larger number of patches in the
series -- for which reason it's usually good to split the series into
"waves" (smaller series). Of course whenever you post a wave, you should
have a functional "whole" (a full stack of waves) in your local tree.
But posting smaller waves is helpful for reviewers (speaking generally),
and the tail of the full work might undergo quite significant updates
due to changes requested for the front.


(2) Please pass "--stat=1000" to git-format-patch. (The additional
"--stat-graph-width=20" option should already be present in your config,
persistently, from running SetupGit.py.) Otherwise, pathnames will be
truncated on the left in the diffstat sections, and that's quite
distracting.


(3) Please consider using "BaseTools/Scripts/GetMaintainer.py", for
determining the set of reviewers for each patch in isolation. Please use
explicit "Cc:" tags in the commit messages. The cover letter should
contain a unified "Cc:" list, also explicitly.


(4) As a general rule, any new memory areas that you access during SEC
and PEI by constant addresses (PCDs) must be considered for S3 resume.
These areas should be reserved from the OS, so that the OS not store
data there, which we'd overwrite during S3. It is also necessary to
guarantee that we never read data from such an area before writing to it
-- in S3, we must not consume any data planted by the OS. So, we should
protect a well-meaning OS during S3, and thwart a malicious OS.

This applies to the new ranges you introduce in [FD.MEMFD]. The current
areas are all covered by PlatformPei explicitly. For details, please
refer to the following document (it could be somewhat out of date, but
the general point stands):

http://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt

section "A comprehensive memory map of OVMF" -- look for the part saying
"With regard to RAM that is statically used by OVMF, ...".

It's OK if S3 support is out of scope for this work. Even in that case,
the life cycles of the new memory ranges should be investigated and
documented explicitly. If S3 is not to be supported with SEV-ES, then
the S3Verification() function should catch that.


(5) Specifically for the SEC GHCB range: can it be carved out of the

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

[Liming Gao]

Laszlo:

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Laszlo 
> Ersek
> Sent: Wednesday, August 21, 2019 4:46 PM
> To: Gao, Liming ; devel@edk2.groups.io; Kinney, Michael 
> D 
> Cc: Mike Turner ; Wang, Jian J 
> ; Wu, Hao A ; Bi, Dandan
> 
> Subject: Re: [edk2-devel] [Patch] MdeModulePkg DxeCore: Fix for missing MAT 
> update
> 
> Hi Liming,
> 
> On 08/19/19 02:40, Gao, Liming wrote:
> 
> >> ... Ugh, wait. I've actually implemented this for OVMF almost 2 years
> >> ago! And the answer to my question is "yes":
> >>
> >>  https://bugzilla.tianocore.org/show_bug.cgi?id=386
> >>  https://lists.01.org/pipermail/edk2-devel/2017-November/018312.html
> >>
> >> See the OnReadOnlyVariable2Available() function:
> >>
> >> +  //
> >> +  // Check if the "MemoryTypeInformation" variable exists, in the
> >> +  // gEfiMemoryTypeInformationGuid namespace.
> >> +  //
> >> +  ReadOnlyVariable2 = Ppi;
> >> +  DataSize = 0;
> >> +  Status = ReadOnlyVariable2->GetVariable (
> >> +ReadOnlyVariable2,
> >> +EFI_MEMORY_TYPE_INFORMATION_VARIABLE_NAME,
> >> +,
> >> +NULL,
> >> +,
> >> +NULL
> >> +);
> >> +  if (Status == EFI_BUFFER_TOO_SMALL) {
> >> +//
> >> +// The variable exists; the DXE IPL PEIM will build the HOB from it.
> >> +//
> >> +return EFI_SUCCESS;
> >> +  }
> >> +  //
> >> +  // Install the default memory type information HOB.
> >> +  //
> >> +  BuildMemTypeInfoHob ();
> >>
> >> Apologies for forgetting about this; you are right.
> >>
> >> Too bad my work for TianoCore#386 was rejected. :(
> >>
> >
> > So, this is one value to add PEI variable support in OVMF.
> > Do you consider to approve this feature request?
> 
> Sorry, I don't understand your question.
> 
> Are you asking me if, in my opinion, we should fix TianoCore#386 (= add
> PEI variable support to OVMF)?

Yes. Fix TianoCore#386 is my suggestion.

> 
> If that is your question, then my answer is -- trivially -- "yes". If
> you read through TianoCore#386, you will see that I submitted patches
> for solving the BZ, twice (comment 6, comment 9).

I see your patch link in BZ. 

> 
> Jordan rejected my patches both times, because he thought that the same
> feature should be implemented in OVMF for Xen as well. I disagreed (and
> still disagree) -- my patches depend on a build-time flag that produces
> an OVMF binary that is only compatible with QEMU, and not Xen. The
> reason for that is that the feature (PEI variable support) cannot be
> implemented *sensibly* on Xen. (Xen offers no spec-conformant variable
> storage, and in the PEI phase, the variable store would always appear
> empty.) Later, Jordan tried to add dynamic pflash detection to PEI, but
> it didn't work in all cases, because OVMF's PEI phase doesn't run in
> SMM, while QEMU restricts pflash access to SMM. (In other words, pflash
> protection in QEMU is less flexible than SMRAM protection -- SMRAM is
> unlocked in PEI, but pflash is always locked.) Please see the threads
> linked in the BZ for the discussion.

Thanks for you detail information. I miss them before. 

> 
> With TianoCore#1689, Anthony has started separating OVMF into different
> firmware platforms for Xen and QEMU. In a year or so, "OVMF for QEMU"
> will likely have nothing Xen-related in it (because "OVMF for Xen" will
> exist separately). Then we can reopen TianoCore#386 just for "OVMF for
> QEMU", and solve this feature.

TianoCore#1689 is in edk2 stable tag 201908 feature planning. 
Dose it still catch 201808 stable tag?

> 
> In summary, I have had patches for TianoCore#386 ready for 2+ years,
> they've been blocked because they only target QEMU (with a build-time
> flag), and I expect to upstream them finally as soon as OvmfPkg offers
> dedicated firmware platforms for Xen and QEMU separately.

How about add BZ386 for 201911 stable tag?

Thanks
Liming
> 
> Thanks
> Laszlo
> 
> 


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

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

Re: [edk2-devel] [Patch][edk2-stable201908] BaseTools: Incorrect error message for library instance not found

[Bob Feng]

Yes. I'll double check this patch.

Thanks,
Bob

-Original Message-
From: Gao, Liming 
Sent: Wednesday, August 21, 2019 9:59 PM
To: Feng, Bob C ; devel@edk2.groups.io
Subject: RE: [Patch][edk2-stable201908] BaseTools: Incorrect error message for 
library instance not found

Bob:
  After I apply this patch, I will meet with build failure to build -p 
MdePkg\MdePkg.dsc. Can you help check it?

Thanks
Liming
> -Original Message-
> From: Feng, Bob C
> Sent: Wednesday, August 21, 2019 2:27 PM
> To: devel@edk2.groups.io
> Cc: Feng, Bob C ; Gao, Liming 
> 
> Subject: [Patch][edk2-stable201908] BaseTools: Incorrect error message 
> for library instance not found
> 
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2099
> This is a regression issue introduced by commit e8449e.
> 
> This patch is to fix this issue.
> 
> Signed-off-by: Bob Feng 
> Cc: Liming Gao 
> ---
>  BaseTools/Source/Python/AutoGen/DataPipe.py  | 2 +-
>  BaseTools/Source/Python/AutoGen/PlatformAutoGen.py   | 2 +-
>  BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py  | 4 +++-
> BaseTools/Source/Python/Workspace/WorkspaceCommon.py | 3 ++-
>  4 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/AutoGen/DataPipe.py 
> b/BaseTools/Source/Python/AutoGen/DataPipe.py
> index 2ca4f9ff4a..8b8cfd1c51 100755
> --- a/BaseTools/Source/Python/AutoGen/DataPipe.py
> +++ b/BaseTools/Source/Python/AutoGen/DataPipe.py
> @@ -87,11 +87,11 @@ class MemoryDataPipe(DataPipe):
>  #Module's Library Instance
>  ModuleLibs = {}
>  libModules = {}
>  for m in PlatformInfo.Platform.Modules:
>  module_obj = 
> BuildDB.BuildObject[m,PlatformInfo.Arch,PlatformInfo.BuildTarget,PlatformInfo.ToolChain]
> -Libs = GetModuleLibInstances(module_obj, PlatformInfo.Platform, 
> BuildDB.BuildObject,
> PlatformInfo.Arch,PlatformInfo.BuildTarget,PlatformInfo.ToolChain)
> +Libs = GetModuleLibInstances(module_obj, 
> + PlatformInfo.Platform, BuildDB.BuildObject,
> PlatformInfo.Arch,PlatformInfo.BuildTarget,PlatformInfo.ToolChain,PlatformInfo.MetaFile,EdkLogger)
>  for lib in Libs:
>  try:
> 
> libModules[(lib.MetaFile.File,lib.MetaFile.Root,lib.Arch,lib.MetaFile.Path)].append((m.File,m.Root,module_obj.Arch,m.Path))
>  except:
>
> libModules[(lib.MetaFile.File,lib.MetaFile.Root,lib.Arch,lib.MetaFile.
> Path)] = [(m.File,m.Root,module_obj.Arch,m.Path)]
> diff --git a/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py 
> b/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
> index dd629ba2fa..565424a95e 100644
> --- a/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
> +++ b/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
> @@ -1087,11 +1087,11 @@ class PlatformAutoGen(AutoGen):
>  def GetAllModuleInfo(self,WithoutPcd=True):
>  ModuleLibs = set()
>  for m in self.Platform.Modules:
>  module_obj = 
> self.BuildDatabase[m,self.Arch,self.BuildTarget,self.ToolChain]
>  if not bool(module_obj.LibraryClass):
> -Libs = GetModuleLibInstances(module_obj, self.Platform, 
> self.BuildDatabase, self.Arch,self.BuildTarget,self.ToolChain)
> +Libs = GetModuleLibInstances(module_obj, 
> + self.Platform, self.BuildDatabase,
> self.Arch,self.BuildTarget,self.ToolChain,self.MetaFile,EdkLogger)
>  else:
>  Libs = []
> 
> ModuleLibs.update( 
> set([(l.MetaFile.File,l.MetaFile.Root,l.MetaFile.Path,l.MetaFile.BaseN
> ame,l.MetaFile.OriginalPath,l.Arch,True) for l in
> Libs]))
>  if WithoutPcd and module_obj.PcdIsDriver:
>  continue
> diff --git a/BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py 
> b/BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py
> index ea0d8f8bfb..2494267472 100644
> --- a/BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py
> +++ b/BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py
> @@ -246,11 +246,13 @@ class WorkspaceAutoGen(AutoGen):
>  if BuildData.MetaFile.Ext == '.inf' and str(BuildData) in 
> Platform.Modules :
>  Libs.extend(GetModuleLibInstances(BuildData, Platform,
>   self.BuildDatabase,
>   Arch,
>   self.BuildTarget,
> - self.ToolChain
> + self.ToolChain,
> + self.Platform.MetaFile,
> + EdkLogger
>   ))
>  for BuildData in list(self.BuildDatabase._CACHE_.values()):
>  if BuildData.Arch != Arch:
>  continue
>  if BuildData.MetaFile.Ext == '.inf':
> diff --git a/BaseTools/Source/Python/Workspace/WorkspaceCommon.py 
> b/BaseTools/Source/Python/Workspace/WorkspaceCommon.py
> index 

Re: [edk2-devel] [Patch][edk2-stable201908] BaseTools: Incorrect error message for library instance not found

[Liming Gao]

Bob:
  After I apply this patch, I will meet with build failure to build -p 
MdePkg\MdePkg.dsc. Can you help check it?

Thanks
Liming
> -Original Message-
> From: Feng, Bob C
> Sent: Wednesday, August 21, 2019 2:27 PM
> To: devel@edk2.groups.io
> Cc: Feng, Bob C ; Gao, Liming 
> Subject: [Patch][edk2-stable201908] BaseTools: Incorrect error message for 
> library instance not found
> 
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2099
> This is a regression issue introduced by commit e8449e.
> 
> This patch is to fix this issue.
> 
> Signed-off-by: Bob Feng 
> Cc: Liming Gao 
> ---
>  BaseTools/Source/Python/AutoGen/DataPipe.py  | 2 +-
>  BaseTools/Source/Python/AutoGen/PlatformAutoGen.py   | 2 +-
>  BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py  | 4 +++-
>  BaseTools/Source/Python/Workspace/WorkspaceCommon.py | 3 ++-
>  4 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/AutoGen/DataPipe.py 
> b/BaseTools/Source/Python/AutoGen/DataPipe.py
> index 2ca4f9ff4a..8b8cfd1c51 100755
> --- a/BaseTools/Source/Python/AutoGen/DataPipe.py
> +++ b/BaseTools/Source/Python/AutoGen/DataPipe.py
> @@ -87,11 +87,11 @@ class MemoryDataPipe(DataPipe):
>  #Module's Library Instance
>  ModuleLibs = {}
>  libModules = {}
>  for m in PlatformInfo.Platform.Modules:
>  module_obj = 
> BuildDB.BuildObject[m,PlatformInfo.Arch,PlatformInfo.BuildTarget,PlatformInfo.ToolChain]
> -Libs = GetModuleLibInstances(module_obj, PlatformInfo.Platform, 
> BuildDB.BuildObject,
> PlatformInfo.Arch,PlatformInfo.BuildTarget,PlatformInfo.ToolChain)
> +Libs = GetModuleLibInstances(module_obj, PlatformInfo.Platform, 
> BuildDB.BuildObject,
> PlatformInfo.Arch,PlatformInfo.BuildTarget,PlatformInfo.ToolChain,PlatformInfo.MetaFile,EdkLogger)
>  for lib in Libs:
>  try:
> 
> libModules[(lib.MetaFile.File,lib.MetaFile.Root,lib.Arch,lib.MetaFile.Path)].append((m.File,m.Root,module_obj.Arch,m.Path))
>  except:
>  
> libModules[(lib.MetaFile.File,lib.MetaFile.Root,lib.Arch,lib.MetaFile.Path)] =
> [(m.File,m.Root,module_obj.Arch,m.Path)]
> diff --git a/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py 
> b/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
> index dd629ba2fa..565424a95e 100644
> --- a/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
> +++ b/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
> @@ -1087,11 +1087,11 @@ class PlatformAutoGen(AutoGen):
>  def GetAllModuleInfo(self,WithoutPcd=True):
>  ModuleLibs = set()
>  for m in self.Platform.Modules:
>  module_obj = 
> self.BuildDatabase[m,self.Arch,self.BuildTarget,self.ToolChain]
>  if not bool(module_obj.LibraryClass):
> -Libs = GetModuleLibInstances(module_obj, self.Platform, 
> self.BuildDatabase, self.Arch,self.BuildTarget,self.ToolChain)
> +Libs = GetModuleLibInstances(module_obj, self.Platform, 
> self.BuildDatabase,
> self.Arch,self.BuildTarget,self.ToolChain,self.MetaFile,EdkLogger)
>  else:
>  Libs = []
> 
> ModuleLibs.update( 
> set([(l.MetaFile.File,l.MetaFile.Root,l.MetaFile.Path,l.MetaFile.BaseName,l.MetaFile.OriginalPath,l.Arch,True)
>  for l in
> Libs]))
>  if WithoutPcd and module_obj.PcdIsDriver:
>  continue
> diff --git a/BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py 
> b/BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py
> index ea0d8f8bfb..2494267472 100644
> --- a/BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py
> +++ b/BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py
> @@ -246,11 +246,13 @@ class WorkspaceAutoGen(AutoGen):
>  if BuildData.MetaFile.Ext == '.inf' and str(BuildData) in 
> Platform.Modules :
>  Libs.extend(GetModuleLibInstances(BuildData, Platform,
>   self.BuildDatabase,
>   Arch,
>   self.BuildTarget,
> - self.ToolChain
> + self.ToolChain,
> + self.Platform.MetaFile,
> + EdkLogger
>   ))
>  for BuildData in list(self.BuildDatabase._CACHE_.values()):
>  if BuildData.Arch != Arch:
>  continue
>  if BuildData.MetaFile.Ext == '.inf':
> diff --git a/BaseTools/Source/Python/Workspace/WorkspaceCommon.py 
> b/BaseTools/Source/Python/Workspace/WorkspaceCommon.py
> index 76583f46e5..cbbd550dbd 100644
> --- a/BaseTools/Source/Python/Workspace/WorkspaceCommon.py
> +++ b/BaseTools/Source/Python/Workspace/WorkspaceCommon.py
> @@ -13,10 +13,11 @@ from .BuildClassObject import LibraryClassObject
>  import Common.GlobalData as GlobalData
>  from 

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

[Liming Gao]

Done. And, push @30781febe2106cc0d7186e70136120353cd67df2

Thanks
Liming
> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, August 20, 2019 10:00 PM
> To: Gao, Liming ; Kuo, Donald ; 
> devel@edk2.groups.io; ler...@redhat.com; Dong, Eric
> 
> Cc: Ni, Ray ; Chan, Amy ; Chaganty, 
> Rangasai V ; Lai, Luke
> ; Li, Kevin Y ; 
> leif.lindh...@linaro.org; af...@apple.com; Kinney, Michael D
> ; Zeng, Star 
> Subject: RE: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by 
> using CPUID(0x15) TSC leaf
> 
> Remember to add entry for it at 
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning.
> 
> > -Original Message-
> > From: Gao, Liming
> > Sent: Tuesday, August 20, 2019 7:56 PM
> > To: Kuo, Donald ; devel@edk2.groups.io;
> > ler...@redhat.com; Dong, Eric 
> > 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
> >
> > Donald:
> >   Thanks for your update. If no other comment, I will help push this patch
> > tomorrow.
> >
> > Thanks
> > Liming
> > > -Original Message-
> > > From: Kuo, Donald
> > > Sent: Tuesday, August 20, 2019 3:22 PM
> > > To: Gao, Liming ; devel@edk2.groups.io;
> > > ler...@redhat.com; Dong, Eric 
> > > 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
> > >
> > > Hi Liming,
> > >
> > > Done.
> > >
> > > Patch is attached to
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=1909
> > >
> > > Another BZ to apply CpuTimerLib will be tracking on:
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=2096
> > >
> > > Thanks,
> > > Donald
> > >
> > > > -Original Message-
> > > > From: Gao, Liming
> > > > Sent: Tuesday, August 20, 2019 2:51 PM
> > > > To: Kuo, Donald ; devel@edk2.groups.io;
> > > > ler...@redhat.com; Dong, Eric 
> > > > 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
> > > >
> > > > Donald:
> > > >   Please also attach the patch linker in BZs.
> > > >
> > > >   And, please submit another BZ for edk2-
> > > > platforms\Platform\Intel\KabylakeOpenBoardPkg to apply this new
> > > > library instance.
> > > >
> > > > Thanks
> > > > Liming
> > > > >-Original Message-
> > > > >From: Kuo, Donald
> > > > >Sent: Tuesday, August 20, 2019 10:44 AM
> > > > >To: devel@edk2.groups.io; ler...@redhat.com; Gao, Liming
> > > > >; Dong, Eric 
> > > > >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
> > > > >
> > > > >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
> > > > >> 

Re: [edk2-devel] [Patch][edk2-stable201908] BaseTools: Fix incremental build genmake issue

[Liming Gao]

Reviewed-by: Liming Gao 

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Bob Feng
> Sent: Wednesday, August 21, 2019 5:57 PM
> To: devel@edk2.groups.io
> Cc: Gao, Liming ; Feng, Bob C 
> Subject: [edk2-devel] [Patch][edk2-stable201908] BaseTools: Fix incremental 
> build genmake issue
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2090
> 
> This is a regression issue introduced by commit e8449e.
> This patch is going to fix this issue.
> 
> Cc: Liming Gao 
> Signed-off-by: Bob Feng 
> ---
>  BaseTools/Source/Python/build/build.py | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/BaseTools/Source/Python/build/build.py 
> b/BaseTools/Source/Python/build/build.py
> index 2c10670a69..0406ac314b 100755
> --- a/BaseTools/Source/Python/build/build.py
> +++ b/BaseTools/Source/Python/build/build.py
> @@ -1217,11 +1217,10 @@ class Build():
>  # for target which must generate AutoGen code and makefile
>  mqueue = mp.Queue()
>  for m in AutoGenObject.GetAllModuleInfo:
>  mqueue.put(m)
> 
> -AutoGenObject.DataPipe.DataContainer = {"FfsCommand":FfsCommand}
>  AutoGenObject.DataPipe.DataContainer = {"CommandTarget": 
> self.Target}
>  self.Progress.Start("Generating makefile and code")
>  data_pipe_file = os.path.join(AutoGenObject.BuildDir, 
> "GlobalVar_%s_%s.bin" %
> (str(AutoGenObject.Guid),AutoGenObject.Arch))
>  AutoGenObject.DataPipe.dump(data_pipe_file)
>  autogen_rt,errorcode = self.StartAutoGen(mqueue, 
> AutoGenObject.DataPipe, self.SkipAutoGen, PcdMaList,
> GlobalData.gCacheIR)
> @@ -1736,10 +1735,12 @@ class Build():
>  if Ma.PcdIsDriver:
>  Ma.PlatformInfo = Pa
>  Ma.Workspace = Wa
>  PcdMaList.append(Ma)
>  self.BuildModules.append(Ma)
> +Pa.DataPipe.DataContainer = {"FfsCommand":CmdListDict}
> +Pa.DataPipe.DataContainer = {"Workspace_timestamp": 
> Wa._SrcTimeStamp}
>  self._BuildPa(self.Target, Pa, 
> FfsCommand=CmdListDict,PcdMaList=PcdMaList)
> 
>  # Create MAP file when Load Fix Address is enabled.
>  if self.Target in ["", "all", "fds"]:
>  for Arch in Wa.ArchList:
> --
> 2.20.1.windows.1
> 
> 
> 


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

View/Reply Online (#46150): https://edk2.groups.io/g/devel/message/46150
Mute This Topic: https://groups.io/mt/32976745/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 1/1] MdePkg: UefiLib: Add a function to check if a language is supported

[Liming Gao]

Tom:
  Can you send the patch by the command 'git send-email xxx.patch'? If so, I 
can extract the patch from the mail.

  If this function is only used in UefiLib, how about define it as the internal 
function?

Thanks
Liming
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Tom Zhao
Sent: Wednesday, August 21, 2019 6:23 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] [PATCH v1 1/1] MdePkg: UefiLib: Add a function to check 
if a language is supported





 Forwarded Message 
Subject:

[PATCH v1 1/1] MdePkg: UefiLib: Add a function to check if a language is 
supported

Date:

Tue, 20 Aug 2019 17:13:19 +0100

From:

Tom Zhao 

To:

edk2-de...@lists.01.org

CC:

michael.d.kin...@intel.com, 
liming@intel.com



Add a function that checks if a target language is in the supported
languages list. Add some calls to this function where appropriate in
UefiLib.c

Cc: Michael D Kinney 

Cc: Liming Gao 
Signed-off-by: Tom Zhao 
---
MdePkg/Include/Library/UefiLib.h | 16 ++
MdePkg/Library/UefiLib/UefiLib.c | 59 +---
2 files changed, 54 insertions(+), 21 deletions(-)

diff --git a/MdePkg/Include/Library/UefiLib.h b/MdePkg/Include/Library/UefiLib.h
index 1650f30ddbc6..9dd170cbe2bf 100644
--- a/MdePkg/Include/Library/UefiLib.h
+++ b/MdePkg/Include/Library/UefiLib.h
@@ -461,6 +461,22 @@ EfiTestChildHandle (
IN CONST EFI_GUID *ProtocolGuid
);
+/**
+ * This function checks the supported languages list for a target language
+ *
+ * @param SupportedLanguages The supported languages
+ * @param TargetLanguage The target language
+ *
+ * @return Returns EFI_SUCCESS if the language is supported,
+ * EFI_UNSUPPORTED otherwise
+ */
+EFI_STATUS
+EFIAPI
+IsLanguageSupported (
+ IN CONST CHAR8 *SupportedLanguages,
+ IN CONST CHAR8 *TargetLanguage
+ );
+
/**
This function looks up a Unicode string in UnicodeStringTable.
diff --git a/MdePkg/Library/UefiLib/UefiLib.c b/MdePkg/Library/UefiLib/UefiLib.c
index daa4af762e62..56281d25fd99 100644
--- a/MdePkg/Library/UefiLib/UefiLib.c
+++ b/MdePkg/Library/UefiLib/UefiLib.c
@@ -640,6 +640,35 @@ EfiTestChildHandle (
return Status;
}
+/**
+ * This function checks the supported languages list for a target language
+ *
+ * @param SupportedLanguages The supported languages
+ * @param TargetLanguage The target language
+ *
+ * @return Returns EFI_SUCCESS if the language is supported,
+ * EFI_UNSUPPORTED otherwise
+ */
+EFI_STATUS
+EFIAPI
+IsLanguageSupported (
+ IN CONST CHAR8 *SupportedLanguages,
+ IN CONST CHAR8 *TargetLanguage
+ )
+{
+ UINTN Index;
+ while (*SupportedLanguages != 0) {
+ for (Index = 0; SupportedLanguages[Index] != 0 && SupportedLanguages[Index] 
!= ';'; Index++);
+ if ((AsciiStrnCmp(SupportedLanguages, TargetLanguage, Index) == 0) && 
(TargetLanguage[Index] == 0)) {
+ return EFI_SUCCESS;
+ }
+ SupportedLanguages += Index;
+ for (; *SupportedLanguages != 0 && *SupportedLanguages == ';'; 
SupportedLanguages++);
+ }
+
+ return EFI_UNSUPPORTED;
+}
+
/**
This function looks up a Unicode string in UnicodeStringTable.
@@ -800,24 +829,19 @@ LookupUnicodeString2 (
// Make sure Language is in the set of Supported Languages
//
Found = FALSE;
- while (*SupportedLanguages != 0) {
- if (Iso639Language) {
+ if (Iso639Language) {
+ while (*SupportedLanguages != 0) {
if (CompareIso639LanguageCode (Language, SupportedLanguages)) {
Found = TRUE;
break;
}
SupportedLanguages += 3;
- } else {
- for (Index = 0; SupportedLanguages[Index] != 0 && SupportedLanguages[Index] 
!= ';'; Index++);
- if ((AsciiStrnCmp(SupportedLanguages, Language, Index) == 0) && 
(Language[Index] == 0)) {
- Found = TRUE;
- break;
- }
- SupportedLanguages += Index;
- for (; *SupportedLanguages != 0 && *SupportedLanguages == ';'; 
SupportedLanguages++);
}
+ } else {
+ Found = !IsLanguageSupported(Language, SupportedLanguages);
}
+
//
// If Language is not a member of SupportedLanguages, then return 
EFI_UNSUPPORTED
//
@@ -1099,24 +1123,17 @@ AddUnicodeString2 (
// Make sure Language is a member of SupportedLanguages
//
Found = FALSE;
- while (*SupportedLanguages != 0) {
- if (Iso639Language) {
+ if (Iso639Language) {
+ while (*SupportedLanguages != 0) {
if (CompareIso639LanguageCode (Language, SupportedLanguages)) {
Found = TRUE;
break;
}
SupportedLanguages += 3;
- } else {
- for (Index = 0; SupportedLanguages[Index] != 0 && SupportedLanguages[Index] 
!= ';'; Index++);
- if (AsciiStrnCmp(SupportedLanguages, Language, Index) == 0) {
- Found = TRUE;
- break;
- }
- SupportedLanguages += Index;
- for (; *SupportedLanguages != 0 && *SupportedLanguages == ';'; 
SupportedLanguages++);
}
+ } else {
+ Found = !IsLanguageSupported(Language, SupportedLanguages);
}
-
//
// If Language is not a member of SupportedLanguages, then return 
EFI_UNSUPPORTED
//

--

2.21.0

[edk2-devel] [PATCH v1 0/1] MdePkg: UefiLib: Add a function to check if a language is supported

[Tom Zhao]

 Forwarded Message 
Subject: 	[PATCH v1 0/1] MdePkg: UefiLib: Add a function to check if a 
language is supported

Date:   Tue, 20 Aug 2019 17:13:09 +0100
From:   Tom Zhao 
To: edk2-de...@lists.01.org
CC: michael.d.kin...@intel.com, liming@intel.com





Add a function that checks if a target language is in the supported
languages list. Add some calls to this function where appropriate in
UefiLib.c

https://github.com/TMZhao/edk2/tree/implement_check_if_supported_lang

Cc: Michael D Kinney 
Cc: Liming Gao 
Signed-off-by: Tom Zhao 

Tom Zhao (1):
MdePkg: UefiLib: Add a function to check if a language is supported

MdePkg/Include/Library/UefiLib.h | 16 ++
MdePkg/Library/UefiLib/UefiLib.c | 59 +---
2 files changed, 54 insertions(+), 21 deletions(-)

--
2.21.0


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

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

[edk2-devel] [PATCH v1 1/1] MdePkg: UefiLib: Add a function to check if a language is supported

[Tom Zhao]

 Forwarded Message 
Subject: 	[PATCH v1 1/1] MdePkg: UefiLib: Add a function to check if a 
language is supported

Date:   Tue, 20 Aug 2019 17:13:19 +0100
From:   Tom Zhao 
To: edk2-de...@lists.01.org
CC: michael.d.kin...@intel.com, liming@intel.com



Add a function that checks if a target language is in the supported
languages list. Add some calls to this function where appropriate in
UefiLib.c

Cc: Michael D Kinney 
Cc: Liming Gao 
Signed-off-by: Tom Zhao 
---
MdePkg/Include/Library/UefiLib.h | 16 ++
MdePkg/Library/UefiLib/UefiLib.c | 59 +---
2 files changed, 54 insertions(+), 21 deletions(-)

diff --git a/MdePkg/Include/Library/UefiLib.h 
b/MdePkg/Include/Library/UefiLib.h

index 1650f30ddbc6..9dd170cbe2bf 100644
--- a/MdePkg/Include/Library/UefiLib.h
+++ b/MdePkg/Include/Library/UefiLib.h
@@ -461,6 +461,22 @@ EfiTestChildHandle (
IN CONST EFI_GUID *ProtocolGuid
);
+/**
+ * This function checks the supported languages list for a target language
+ *
+ * @param SupportedLanguages The supported languages
+ * @param TargetLanguage The target language
+ *
+ * @return Returns EFI_SUCCESS if the language is supported,
+ * EFI_UNSUPPORTED otherwise
+ */
+EFI_STATUS
+EFIAPI
+IsLanguageSupported (
+ IN CONST CHAR8 *SupportedLanguages,
+ IN CONST CHAR8 *TargetLanguage
+ );
+
/**
This function looks up a Unicode string in UnicodeStringTable.
diff --git a/MdePkg/Library/UefiLib/UefiLib.c 
b/MdePkg/Library/UefiLib/UefiLib.c

index daa4af762e62..56281d25fd99 100644
--- a/MdePkg/Library/UefiLib/UefiLib.c
+++ b/MdePkg/Library/UefiLib/UefiLib.c
@@ -640,6 +640,35 @@ EfiTestChildHandle (
return Status;
}
+/**
+ * This function checks the supported languages list for a target language
+ *
+ * @param SupportedLanguages The supported languages
+ * @param TargetLanguage The target language
+ *
+ * @return Returns EFI_SUCCESS if the language is supported,
+ * EFI_UNSUPPORTED otherwise
+ */
+EFI_STATUS
+EFIAPI
+IsLanguageSupported (
+ IN CONST CHAR8 *SupportedLanguages,
+ IN CONST CHAR8 *TargetLanguage
+ )
+{
+ UINTN Index;
+ while (*SupportedLanguages != 0) {
+ for (Index = 0; SupportedLanguages[Index] != 0 && 
SupportedLanguages[Index] != ';'; Index++);
+ if ((AsciiStrnCmp(SupportedLanguages, TargetLanguage, Index) == 0) && 
(TargetLanguage[Index] == 0)) {

+ return EFI_SUCCESS;
+ }
+ SupportedLanguages += Index;
+ for (; *SupportedLanguages != 0 && *SupportedLanguages == ';'; 
SupportedLanguages++);

+ }
+
+ return EFI_UNSUPPORTED;
+}
+
/**
This function looks up a Unicode string in UnicodeStringTable.
@@ -800,24 +829,19 @@ LookupUnicodeString2 (
// Make sure Language is in the set of Supported Languages
//
Found = FALSE;
- while (*SupportedLanguages != 0) {
- if (Iso639Language) {
+ if (Iso639Language) {
+ while (*SupportedLanguages != 0) {
if (CompareIso639LanguageCode (Language, SupportedLanguages)) {
Found = TRUE;
break;
}
SupportedLanguages += 3;
- } else {
- for (Index = 0; SupportedLanguages[Index] != 0 && 
SupportedLanguages[Index] != ';'; Index++);
- if ((AsciiStrnCmp(SupportedLanguages, Language, Index) == 0) && 
(Language[Index] == 0)) {

- Found = TRUE;
- break;
- }
- SupportedLanguages += Index;
- for (; *SupportedLanguages != 0 && *SupportedLanguages == ';'; 
SupportedLanguages++);

}
+ } else {
+ Found = !IsLanguageSupported(Language, SupportedLanguages);
}
+
//
// If Language is not a member of SupportedLanguages, then return 
EFI_UNSUPPORTED

//
@@ -1099,24 +1123,17 @@ AddUnicodeString2 (
// Make sure Language is a member of SupportedLanguages
//
Found = FALSE;
- while (*SupportedLanguages != 0) {
- if (Iso639Language) {
+ if (Iso639Language) {
+ while (*SupportedLanguages != 0) {
if (CompareIso639LanguageCode (Language, SupportedLanguages)) {
Found = TRUE;
break;
}
SupportedLanguages += 3;
- } else {
- for (Index = 0; SupportedLanguages[Index] != 0 && 
SupportedLanguages[Index] != ';'; Index++);

- if (AsciiStrnCmp(SupportedLanguages, Language, Index) == 0) {
- Found = TRUE;
- break;
- }
- SupportedLanguages += Index;
- for (; *SupportedLanguages != 0 && *SupportedLanguages == ';'; 
SupportedLanguages++);

}
+ } else {
+ Found = !IsLanguageSupported(Language, SupportedLanguages);
}
-
//
// If Language is not a member of SupportedLanguages, then return 
EFI_UNSUPPORTED

//

--
2.21.0


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

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

[edk2-devel] [PATCH v4] IntelSiliconPkg-Vtd: A new PMR interface

[Evelyn Wang]

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

1) IOMMU PMR feature should be generic to support different hardware
architecture. Platforms may request no overlap between PMR regions
and system reserve memory. Create an interface to control PLMR/PHMR
regions. It allows silicon code to adjust PLMR/PHMR region base on
the project needs.

2) DisableDMAr Function Code Optimization
Optimize the flow to follow the VT-d spec requirements.

3) Renamed InitDmar() to InitGlobalVtd()
The oringal function name is misleading

4) A new GetVtdPmrAlignmentLib for silicon code to get
PMR alignment values.

Signed-off-by: Evelyn Wang 
Cc: Jenny Huang 
Cc: More Shih 
Cc: Ray Ni 
Cc: Rangasai V Chaganty 

---
In V2:
1) Fixed the EFIAPI is missing in library API issue
2) Logs will be provided to make sure the backwards compatibility
3) Replaced BIT0 with EFI_ACPI_DMAR_DRHD_FLAGS_INCLUDE_PCI_ALL
4) Renamed GetVtdPmrAlignmentLib to PeiGetVtdPmrAlignmentLib
5) Fixed the indent in IntelVTdPmrPei.c
6) Follow VTd spec to define the data type of the SYSTEM_MEM_INFO_HOB
   Applied few changes coordinately

---
In V3:
1) Fixed the EFIAPI is missing in library API issue
2) Fixed the S3 resume assert

---
In V4:
Fixed the missing EFIAPI in .h file and added few more comments
---
 Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/VtdReg.c 
   |  30 +++---
 Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmr.c 
   |   4 ++--
 Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.c  
   |  71 
+--
 Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/VtdReg.c  
   |  29 ++---
 
Silicon/Intel/IntelSiliconPkg/Feature/VTd/PlatformVTdInfoSamplePei/PlatformVTdInfoSamplePei.c
 |   9 +
 
Silicon/Intel/IntelSiliconPkg/Library/PeiGetVtdPmrAlignmentLib/PeiGetVtdPmrAlignmentLib.c
 | 166 
++
 Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.inf
   |   5 -
 Silicon/Intel/IntelSiliconPkg/Include/Library/PeiGetVtdPmrAlignmentLib.h   
   |  22 ++
 Silicon/Intel/IntelSiliconPkg/Include/SysMemInfoHob.h  
   |  25 +
 Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec  
   |  11 +--
 Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc  
   |   3 ++-
 
Silicon/Intel/IntelSiliconPkg/Library/PeiGetVtdPmrAlignmentLib/PeiGetVtdPmrAlignmentLib.inf
   |  32 
 12 files changed, 369 insertions(+), 38 deletions(-)

diff --git a/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/VtdReg.c 
b/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/VtdReg.c
index 22bf821d2b..699639ba88 100644
--- a/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/VtdReg.c
+++ b/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/VtdReg.c
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2017 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -309,6 +309,8 @@ DisableDmar (
   UINTN Index;
   UINTN SubIndex;
   UINT32Reg32;
+  UINT32Status;
+  UINT32Command;
 
   for (Index = 0; Index < mVtdUnitNumber; Index++) {
 DEBUG((DEBUG_INFO, ">>DisableDmar() for engine [%d] \n", Index));
@@ -319,9 +321,31 @@ DisableDmar (
 FlushWriteBuffer (Index);
 
 //
-// Disable VTd
+// Disable Dmar
 //
-MmioWrite32 (mVtdUnitInformation[Index].VtdUnitBaseAddress + R_GCMD_REG, 
B_GMCD_REG_SRTP);
+//
+// Set TE (Translation Enable: BIT31) of Global command register to zero
+//
+Reg32 = MmioRead32 (mVtdUnitInformation[Index].VtdUnitBaseAddress + 
R_GSTS_REG);
+Status = (Reg32 & 0x96FF);   // Reset the one-shot bits
+Command = (Status & ~B_GMCD_REG_TE);
+MmioWrite32 (mVtdUnitInformation[Index].VtdUnitBaseAddress + R_GCMD_REG, 
Command);
+
+//
+// Poll on TE Status bit of Global status register to become zero
+//
+do {
+  Reg32 = MmioRead32 (mVtdUnitInformation[Index].VtdUnitBaseAddress + 
R_GSTS_REG);
+} while ((Reg32 & B_GSTS_REG_TE) == B_GSTS_REG_TE);
+
+//
+// Set SRTP (Set Root Table Pointer: BIT30) of Global command register in 
order to update the root table pointerDisable VTd
+//
+Reg32 = MmioRead32 (mVtdUnitInformation[Index].VtdUnitBaseAddress + 
R_GSTS_REG);
+Status = (Reg32 & 0x96FF);   // Reset the one-shot bits
+Command = (Status | B_GMCD_REG_SRTP);
+

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

[Laszlo Ersek]

On 08/19/19 16:10, Paolo Bonzini wrote:
> 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.

Alex, thank you for the help! Please let us know if we should remove you
from the CC list, in order not to clutter your inbox. (I've kept your
address for now, for saying thanks. Feel free to stop reading here. Thanks!)

> For OVMF
> we'll probably go with Igor's idea, it would be nice if Intel chipsets
> supported it too. :)

So what is Igor's idea? Please do spoon-feed it to me. I've seen the POC
patch but the memory region manipulation isn't obvious to me.

Regarding TSEG, QEMU doesn't implement it differently from normal RAM.
Instead, if memory serves, there is an extra "black hole" region that is
overlaid, which hides the RAM contents when TSEG is supposed to be
closed (and the guest is not running in SMM).

But this time we're doing something else, right? Is the idea to overlay
the RAM range at 0x3 with a window (alias) into the "compatible"
SMRAM at 0xA-0xB?

I don't know how the "compatible" SMRAM is implemented in QEMU. Does the
compatible SMRAM behave in sync with TSEG? OVMF doesn't configure or
touch compatible SMRAM at all, at the moment.

Thanks
Laszlo

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

View/Reply Online (#46145): https://edk2.groups.io/g/devel/message/46145
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-platforms: PATCH v2 03/10] Marvell/Cn9130Db: Add DeviceTree

[Marcin Wojtas]

Hi Leif, Laszlo

śr., 21 sie 2019 o 11:11 Laszlo Ersek  napisał(a):
>
> On 08/19/19 19:14, Leif Lindholm wrote:
> > +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.
>
> no particular comments from me; what Leif suggests looks fine to me
> (from orbit anyway)
>

Ok, fair enough - since I cannot re-send with contribution agreement
any more, I have to use edk2-non-osi path.

Best regards,
Marcin

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

View/Reply Online (#46144): https://edk2.groups.io/g/devel/message/46144
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]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [Patch][edk2-stable201908] BaseTools: Fix incremental build genmake issue

[Bob Feng]

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

This is a regression issue introduced by commit e8449e.
This patch is going to fix this issue.

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

diff --git a/BaseTools/Source/Python/build/build.py 
b/BaseTools/Source/Python/build/build.py
index 2c10670a69..0406ac314b 100755
--- a/BaseTools/Source/Python/build/build.py
+++ b/BaseTools/Source/Python/build/build.py
@@ -1217,11 +1217,10 @@ class Build():
 # for target which must generate AutoGen code and makefile
 mqueue = mp.Queue()
 for m in AutoGenObject.GetAllModuleInfo:
 mqueue.put(m)
 
-AutoGenObject.DataPipe.DataContainer = {"FfsCommand":FfsCommand}
 AutoGenObject.DataPipe.DataContainer = {"CommandTarget": 
self.Target}
 self.Progress.Start("Generating makefile and code")
 data_pipe_file = os.path.join(AutoGenObject.BuildDir, 
"GlobalVar_%s_%s.bin" % (str(AutoGenObject.Guid),AutoGenObject.Arch))
 AutoGenObject.DataPipe.dump(data_pipe_file)
 autogen_rt,errorcode = self.StartAutoGen(mqueue, 
AutoGenObject.DataPipe, self.SkipAutoGen, PcdMaList, GlobalData.gCacheIR)
@@ -1736,10 +1735,12 @@ class Build():
 if Ma.PcdIsDriver:
 Ma.PlatformInfo = Pa
 Ma.Workspace = Wa
 PcdMaList.append(Ma)
 self.BuildModules.append(Ma)
+Pa.DataPipe.DataContainer = {"FfsCommand":CmdListDict}
+Pa.DataPipe.DataContainer = {"Workspace_timestamp": 
Wa._SrcTimeStamp}
 self._BuildPa(self.Target, Pa, 
FfsCommand=CmdListDict,PcdMaList=PcdMaList)
 
 # Create MAP file when Load Fix Address is enabled.
 if self.Target in ["", "all", "fds"]:
 for Arch in Wa.ArchList:
-- 
2.20.1.windows.1


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

View/Reply Online (#46143): https://edk2.groups.io/g/devel/message/46143
Mute This Topic: https://groups.io/mt/32976745/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

[Laszlo Ersek]

On 08/19/19 19:14, Leif Lindholm wrote:
> +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.

no particular comments from me; what Leif suggests looks fine to me
(from orbit anyway)

thanks
Laszlo

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

View/Reply Online (#46142): https://edk2.groups.io/g/devel/message/46142
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] [Patch] MdeModulePkg DxeCore: Fix for missing MAT update

[Laszlo Ersek]

Hi Liming,

On 08/19/19 02:40, Gao, Liming wrote:

>> ... Ugh, wait. I've actually implemented this for OVMF almost 2 years
>> ago! And the answer to my question is "yes":
>>
>>  https://bugzilla.tianocore.org/show_bug.cgi?id=386
>>  https://lists.01.org/pipermail/edk2-devel/2017-November/018312.html
>>
>> See the OnReadOnlyVariable2Available() function:
>>
>> +  //
>> +  // Check if the "MemoryTypeInformation" variable exists, in the
>> +  // gEfiMemoryTypeInformationGuid namespace.
>> +  //
>> +  ReadOnlyVariable2 = Ppi;
>> +  DataSize = 0;
>> +  Status = ReadOnlyVariable2->GetVariable (
>> +ReadOnlyVariable2,
>> +EFI_MEMORY_TYPE_INFORMATION_VARIABLE_NAME,
>> +,
>> +NULL,
>> +,
>> +NULL
>> +);
>> +  if (Status == EFI_BUFFER_TOO_SMALL) {
>> +//
>> +// The variable exists; the DXE IPL PEIM will build the HOB from it.
>> +//
>> +return EFI_SUCCESS;
>> +  }
>> +  //
>> +  // Install the default memory type information HOB.
>> +  //
>> +  BuildMemTypeInfoHob ();
>>
>> Apologies for forgetting about this; you are right.
>>
>> Too bad my work for TianoCore#386 was rejected. :(
>>
> 
> So, this is one value to add PEI variable support in OVMF. 
> Do you consider to approve this feature request? 

Sorry, I don't understand your question.

Are you asking me if, in my opinion, we should fix TianoCore#386 (= add
PEI variable support to OVMF)?

If that is your question, then my answer is -- trivially -- "yes". If
you read through TianoCore#386, you will see that I submitted patches
for solving the BZ, twice (comment 6, comment 9).

Jordan rejected my patches both times, because he thought that the same
feature should be implemented in OVMF for Xen as well. I disagreed (and
still disagree) -- my patches depend on a build-time flag that produces
an OVMF binary that is only compatible with QEMU, and not Xen. The
reason for that is that the feature (PEI variable support) cannot be
implemented *sensibly* on Xen. (Xen offers no spec-conformant variable
storage, and in the PEI phase, the variable store would always appear
empty.) Later, Jordan tried to add dynamic pflash detection to PEI, but
it didn't work in all cases, because OVMF's PEI phase doesn't run in
SMM, while QEMU restricts pflash access to SMM. (In other words, pflash
protection in QEMU is less flexible than SMRAM protection -- SMRAM is
unlocked in PEI, but pflash is always locked.) Please see the threads
linked in the BZ for the discussion.

With TianoCore#1689, Anthony has started separating OVMF into different
firmware platforms for Xen and QEMU. In a year or so, "OVMF for QEMU"
will likely have nothing Xen-related in it (because "OVMF for Xen" will
exist separately). Then we can reopen TianoCore#386 just for "OVMF for
QEMU", and solve this feature.

In summary, I have had patches for TianoCore#386 ready for 2+ years,
they've been blocked because they only target QEMU (with a build-time
flag), and I expect to upstream them finally as soon as OvmfPkg offers
dedicated firmware platforms for Xen and QEMU separately.

Thanks
Laszlo

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

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

[edk2-devel] [PATCH 1/1] UefiCpuPkg/Cpuid: Remove white space

[Zhang, Shenglei]

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Shenglei Zhang 
---
 UefiCpuPkg/Application/Cpuid/Cpuid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/UefiCpuPkg/Application/Cpuid/Cpuid.c 
b/UefiCpuPkg/Application/Cpuid/Cpuid.c
index f39a7fb33ae5..cee64f2fb5fc 100644
--- a/UefiCpuPkg/Application/Cpuid/Cpuid.c
+++ b/UefiCpuPkg/Application/Cpuid/Cpuid.c
@@ -709,7 +709,7 @@ CpuidArchitecturalPerformanceMonitoring (
   Display CPUID_EXTENDED_TOPOLOGY leafs for all supported levels.
 
   @param[in] LeafFunction  Leaf function index for CPUID_EXTENDED_TOPOLOGY.
-  
+
 **/
 VOID
 CpuidExtendedTopology (
-- 
2.18.0.windows.1


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

View/Reply Online (#46140): https://edk2.groups.io/g/devel/message/46140
Mute This Topic: https://groups.io/mt/32976360/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 2/2] Platform/MinPlatformPkg: Add missing header files in INF files

[Chiu, Chasel]

Some of files touched by this patch still having old copyright year, please 
help to extend.
With above update: Reviewed-by: Chasel Chiu 


> -Original Message-
> From: Zhang, Shenglei
> Sent: Wednesday, August 21, 2019 4:01 PM
> To: devel@edk2.groups.io
> Cc: Kubacki, Michael A ; Chiu, Chasel
> ; Desimone, Nathaniel L
> ; Gao, Liming 
> Subject: [edk2-platform PATCH 2/2] Platform/MinPlatformPkg: Add missing
> header files in INF files
> 
> The header files are used but missing in INF,which causes warning message
> when building them.
> https://bugzilla.tianocore.org/show_bug.cgi?id=2037
> 
> Cc: Michael Kubacki 
> Cc: Chasel Chiu 
> Cc: Nate DeSimone 
> Cc: Liming Gao 
> Signed-off-by: Shenglei Zhang 
> ---
>  .../MinPlatformPkg/Flash/SpiFvbService/SpiFvbServiceSmm.inf | 1 +
>  .../SecFspWrapperPlatformSecLib/SecFspWrapperPlatformSecLib.inf | 1 +
>  .../Hsti/HstiIbvPlatformDxe/HstiIbvPlatformDxe.inf  | 1 +
>  .../Library/PeiHobVariableLibFce/PeiHobVariableLibFce.inf   | 2 ++
>  .../PeiHobVariableLibFce/PeiHobVariableLibFceOptSize.inf| 2 ++
>  .../Test/Library/TestPointCheckLib/DxeTestPointCheckLib.inf | 1 +
>  .../Test/Library/TestPointCheckLib/SmmTestPointCheckLib.inf | 1 +
>  7 files changed, 9 insertions(+)
> 
> diff --git
> a/Platform/Intel/MinPlatformPkg/Flash/SpiFvbService/SpiFvbServiceSmm.inf
> b/Platform/Intel/MinPlatformPkg/Flash/SpiFvbService/SpiFvbServiceSmm.inf
> index cca7de94..4c5202f9 100644
> ---
> a/Platform/Intel/MinPlatformPkg/Flash/SpiFvbService/SpiFvbServiceSmm.inf
> +++
> b/Platform/Intel/MinPlatformPkg/Flash/SpiFvbService/SpiFvbServiceSmm
> +++ .inf
> @@ -50,6 +50,7 @@
>  [Sources]
>Common/SpiFvbServiceCommon.c
>Common/FvbInfo.c
> +  Common/SpiFvbServiceCommon.h
>Smm/SpiFvbServiceSmm.c
> 
>  [Protocols]
> diff --git
> a/Platform/Intel/MinPlatformPkg/FspWrapper/Library/SecFspWrapperPlatfo
> rmSecLib/SecFspWrapperPlatformSecLib.inf
> b/Platform/Intel/MinPlatformPkg/FspWrapper/Library/SecFspWrapperPlatfo
> rmSecLib/SecFspWrapperPlatformSecLib.inf
> index 5d77e9e4..3f5a63f2 100644
> ---
> a/Platform/Intel/MinPlatformPkg/FspWrapper/Library/SecFspWrapperPlatfo
> rmSecLib/SecFspWrapperPlatformSecLib.inf
> +++
> b/Platform/Intel/MinPlatformPkg/FspWrapper/Library/SecFspWrapperPlat
> +++ formSecLib/SecFspWrapperPlatformSecLib.inf
> @@ -41,6 +41,7 @@
>SecGetPerformance.c
>SecTempRamDone.c
>PlatformInit.c
> +  FsptCoreUpd.h
> 
>  [Sources.IA32]
>Ia32/SecEntry.nasm
> diff --git
> a/Platform/Intel/MinPlatformPkg/Hsti/HstiIbvPlatformDxe/HstiIbvPlatformD
> xe.inf
> b/Platform/Intel/MinPlatformPkg/Hsti/HstiIbvPlatformDxe/HstiIbvPlatformD
> xe.inf
> index 64814528..172280e8 100644
> ---
> a/Platform/Intel/MinPlatformPkg/Hsti/HstiIbvPlatformDxe/HstiIbvPlatformD
> xe.inf
> +++ b/Platform/Intel/MinPlatformPkg/Hsti/HstiIbvPlatformDxe/HstiIbvPlatf
> +++ ormDxe.inf
> @@ -23,6 +23,7 @@
>SecureBootBypass.c
>ExternalDeviceDmaProtection.c
>MorSupport.c
> +  HstiIbvPlatformDxe.h
> 
>  [Packages]
>MdePkg/MdePkg.dec
> diff --git
> a/Platform/Intel/MinPlatformPkg/Library/PeiHobVariableLibFce/PeiHobVaria
> bleLibFce.inf
> b/Platform/Intel/MinPlatformPkg/Library/PeiHobVariableLibFce/PeiHobVaria
> bleLibFce.inf
> index fd80c611..ad8882fe 100644
> ---
> a/Platform/Intel/MinPlatformPkg/Library/PeiHobVariableLibFce/PeiHobVaria
> bleLibFce.inf
> +++
> b/Platform/Intel/MinPlatformPkg/Library/PeiHobVariableLibFce/PeiHobV
> +++ ariableLibFce.inf
> @@ -37,6 +37,8 @@
>  [Sources]
>PeiHobVariableLibFce.c
>InternalCommonLib.c
> +  Variable.h
> +  Fce.h
> 
>  [Ppis]
>gEfiPeiMemoryDiscoveredPpiGuid## NOTIFY
> diff --git
> a/Platform/Intel/MinPlatformPkg/Library/PeiHobVariableLibFce/PeiHobVaria
> bleLibFceOptSize.inf
> b/Platform/Intel/MinPlatformPkg/Library/PeiHobVariableLibFce/PeiHobVaria
> bleLibFceOptSize.inf
> index 82d81c98..e1a76715 100644
> ---
> a/Platform/Intel/MinPlatformPkg/Library/PeiHobVariableLibFce/PeiHobVaria
> bleLibFceOptSize.inf
> +++
> b/Platform/Intel/MinPlatformPkg/Library/PeiHobVariableLibFce/PeiHobV
> +++ ariableLibFceOptSize.inf
> @@ -36,6 +36,8 @@
>  [Sources]
>PeiHobVariableLibFceOptSize.c
>InternalCommonLib.c
> +  Variable.h
> +  Fce.h
> 
>  [Ppis]
>gEfiPeiMemoryDiscoveredPpiGuid## NOTIFY
> diff --git
> a/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeTestPoi
> ntCheckLib.inf
> b/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeTestPoi
> ntCheckLib.inf
> index 62fceffb..76e193dc 100644
> ---
> a/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeTestPoi
> ntCheckLib.inf
> +++ b/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeTe
> +++ stPointCheckLib.inf
> @@ -68,6 +68,7 @@
>DxeCheckTcgMor.c
>DxeCheckDmaProtection.c
>TestPointHelp.c
> +  TestPointInternal.h
> 
>  [Guids]
>gEfiMemoryAttributesTableGuid
> diff --git
> 

[edk2-devel] [edk2-platform PATCH 1/2] Platform/SmbiosBasicDxe: Add a missing header file in INF

[Zhang, Shenglei]

The header file is used but missing in INF,which causes
warning message when building them.
https://bugzilla.tianocore.org/show_bug.cgi?id=2037

Cc: Michael Kubacki 
Cc: Sai Chaganty 
Cc: Liming Gao 
Signed-off-by: Shenglei Zhang 
---
 .../AdvancedFeaturePkg/Smbios/SmbiosBasicDxe/SmbiosBasicDxe.inf  | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Platform/Intel/AdvancedFeaturePkg/Smbios/SmbiosBasicDxe/SmbiosBasicDxe.inf 
b/Platform/Intel/AdvancedFeaturePkg/Smbios/SmbiosBasicDxe/SmbiosBasicDxe.inf
index 69e930dd..bbac1d5c 100644
--- a/Platform/Intel/AdvancedFeaturePkg/Smbios/SmbiosBasicDxe/SmbiosBasicDxe.inf
+++ b/Platform/Intel/AdvancedFeaturePkg/Smbios/SmbiosBasicDxe/SmbiosBasicDxe.inf
@@ -23,6 +23,7 @@
 
 [Sources]
   SmbiosBasicEntryPoint.c
+  SmbiosBasic.h
   Type0BiosVendorFunction.c
   Type1SystemManufacturerFunction.c
   Type2BaseBoardManufacturerFunction.c
-- 
2.18.0.windows.1


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

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

[edk2-devel] [edk2-platform PATCH 2/2] Platform/MinPlatformPkg: Add missing header files in INF files

[Zhang, Shenglei]

The header files are used but missing in INF,which causes
warning message when building them.
https://bugzilla.tianocore.org/show_bug.cgi?id=2037

Cc: Michael Kubacki 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Signed-off-by: Shenglei Zhang 
---
 .../MinPlatformPkg/Flash/SpiFvbService/SpiFvbServiceSmm.inf | 1 +
 .../SecFspWrapperPlatformSecLib/SecFspWrapperPlatformSecLib.inf | 1 +
 .../Hsti/HstiIbvPlatformDxe/HstiIbvPlatformDxe.inf  | 1 +
 .../Library/PeiHobVariableLibFce/PeiHobVariableLibFce.inf   | 2 ++
 .../PeiHobVariableLibFce/PeiHobVariableLibFceOptSize.inf| 2 ++
 .../Test/Library/TestPointCheckLib/DxeTestPointCheckLib.inf | 1 +
 .../Test/Library/TestPointCheckLib/SmmTestPointCheckLib.inf | 1 +
 7 files changed, 9 insertions(+)

diff --git 
a/Platform/Intel/MinPlatformPkg/Flash/SpiFvbService/SpiFvbServiceSmm.inf 
b/Platform/Intel/MinPlatformPkg/Flash/SpiFvbService/SpiFvbServiceSmm.inf
index cca7de94..4c5202f9 100644
--- a/Platform/Intel/MinPlatformPkg/Flash/SpiFvbService/SpiFvbServiceSmm.inf
+++ b/Platform/Intel/MinPlatformPkg/Flash/SpiFvbService/SpiFvbServiceSmm.inf
@@ -50,6 +50,7 @@
 [Sources]
   Common/SpiFvbServiceCommon.c
   Common/FvbInfo.c
+  Common/SpiFvbServiceCommon.h
   Smm/SpiFvbServiceSmm.c
 
 [Protocols]
diff --git 
a/Platform/Intel/MinPlatformPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/SecFspWrapperPlatformSecLib.inf
 
b/Platform/Intel/MinPlatformPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/SecFspWrapperPlatformSecLib.inf
index 5d77e9e4..3f5a63f2 100644
--- 
a/Platform/Intel/MinPlatformPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/SecFspWrapperPlatformSecLib.inf
+++ 
b/Platform/Intel/MinPlatformPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/SecFspWrapperPlatformSecLib.inf
@@ -41,6 +41,7 @@
   SecGetPerformance.c
   SecTempRamDone.c
   PlatformInit.c
+  FsptCoreUpd.h
 
 [Sources.IA32]
   Ia32/SecEntry.nasm
diff --git 
a/Platform/Intel/MinPlatformPkg/Hsti/HstiIbvPlatformDxe/HstiIbvPlatformDxe.inf 
b/Platform/Intel/MinPlatformPkg/Hsti/HstiIbvPlatformDxe/HstiIbvPlatformDxe.inf
index 64814528..172280e8 100644
--- 
a/Platform/Intel/MinPlatformPkg/Hsti/HstiIbvPlatformDxe/HstiIbvPlatformDxe.inf
+++ 
b/Platform/Intel/MinPlatformPkg/Hsti/HstiIbvPlatformDxe/HstiIbvPlatformDxe.inf
@@ -23,6 +23,7 @@
   SecureBootBypass.c
   ExternalDeviceDmaProtection.c
   MorSupport.c
+  HstiIbvPlatformDxe.h
 
 [Packages]
   MdePkg/MdePkg.dec
diff --git 
a/Platform/Intel/MinPlatformPkg/Library/PeiHobVariableLibFce/PeiHobVariableLibFce.inf
 
b/Platform/Intel/MinPlatformPkg/Library/PeiHobVariableLibFce/PeiHobVariableLibFce.inf
index fd80c611..ad8882fe 100644
--- 
a/Platform/Intel/MinPlatformPkg/Library/PeiHobVariableLibFce/PeiHobVariableLibFce.inf
+++ 
b/Platform/Intel/MinPlatformPkg/Library/PeiHobVariableLibFce/PeiHobVariableLibFce.inf
@@ -37,6 +37,8 @@
 [Sources]
   PeiHobVariableLibFce.c
   InternalCommonLib.c
+  Variable.h
+  Fce.h
 
 [Ppis]
   gEfiPeiMemoryDiscoveredPpiGuid## NOTIFY
diff --git 
a/Platform/Intel/MinPlatformPkg/Library/PeiHobVariableLibFce/PeiHobVariableLibFceOptSize.inf
 
b/Platform/Intel/MinPlatformPkg/Library/PeiHobVariableLibFce/PeiHobVariableLibFceOptSize.inf
index 82d81c98..e1a76715 100644
--- 
a/Platform/Intel/MinPlatformPkg/Library/PeiHobVariableLibFce/PeiHobVariableLibFceOptSize.inf
+++ 
b/Platform/Intel/MinPlatformPkg/Library/PeiHobVariableLibFce/PeiHobVariableLibFceOptSize.inf
@@ -36,6 +36,8 @@
 [Sources]
   PeiHobVariableLibFceOptSize.c
   InternalCommonLib.c
+  Variable.h
+  Fce.h
 
 [Ppis]
   gEfiPeiMemoryDiscoveredPpiGuid## NOTIFY
diff --git 
a/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeTestPointCheckLib.inf
 
b/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeTestPointCheckLib.inf
index 62fceffb..76e193dc 100644
--- 
a/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeTestPointCheckLib.inf
+++ 
b/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/DxeTestPointCheckLib.inf
@@ -68,6 +68,7 @@
   DxeCheckTcgMor.c
   DxeCheckDmaProtection.c
   TestPointHelp.c
+  TestPointInternal.h
 
 [Guids]
   gEfiMemoryAttributesTableGuid
diff --git 
a/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/SmmTestPointCheckLib.inf
 
b/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/SmmTestPointCheckLib.inf
index 6007fbc9..03d027ec 100644
--- 
a/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/SmmTestPointCheckLib.inf
+++ 
b/Platform/Intel/MinPlatformPkg/Test/Library/TestPointCheckLib/SmmTestPointCheckLib.inf
@@ -45,6 +45,7 @@
   DxeCheckLoadedImage.c
   DxeCheckGcd.c
   TestPointHelp.c
+  TestPointInternal.h
 
 [Pcd]
   gMinPlatformPkgTokenSpaceGuid.PcdTestPointIbvPlatformFeature
-- 
2.18.0.windows.1


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

View/Reply Online (#46138): https://edk2.groups.io/g/devel/message/46138
Mute This Topic: https://groups.io/mt/32976203/21656

[edk2-devel] [edk2-platform PATCH 0/2] Fix warning message issues

[Zhang, Shenglei]

There are some header files used but not included in INF
files. This causes warings are generated when building the
packages. So now add them into INF files.
https://bugzilla.tianocore.org/show_bug.cgi?id=2037

Cc: Sai Chaganty 
Cc: Michael Kubacki 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Shenglei Zhang (2):
  Platform/SmbiosBasicDxe: Add a missing header file in INF
  Platform/MinPlatformPkg: Add missing header files in INF files

 .../AdvancedFeaturePkg/Smbios/SmbiosBasicDxe/SmbiosBasicDxe.inf | 1 +
 .../MinPlatformPkg/Flash/SpiFvbService/SpiFvbServiceSmm.inf | 1 +
 .../SecFspWrapperPlatformSecLib/SecFspWrapperPlatformSecLib.inf | 1 +
 .../Hsti/HstiIbvPlatformDxe/HstiIbvPlatformDxe.inf  | 1 +
 .../Library/PeiHobVariableLibFce/PeiHobVariableLibFce.inf   | 2 ++
 .../PeiHobVariableLibFce/PeiHobVariableLibFceOptSize.inf| 2 ++
 .../Test/Library/TestPointCheckLib/DxeTestPointCheckLib.inf | 1 +
 .../Test/Library/TestPointCheckLib/SmmTestPointCheckLib.inf | 1 +
 8 files changed, 10 insertions(+)

-- 
2.18.0.windows.1


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

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

[edk2-devel] FW: [PATCH v1 1/1] MdePkg: UefiLib: Add a function to check if a language is supported

[Liming Gao]

Send it to new mail list. 

-Original Message-
From: Gao, Liming 
Sent: Wednesday, August 21, 2019 2:33 PM
To: 'Tom Zhao' ; edk2-de...@lists.01.org
Cc: Kinney, Michael D 
Subject: RE: [PATCH v1 1/1] MdePkg: UefiLib: Add a function to check if a 
language is supported

Tom:
  Please submit BZ https://bugzilla.tianocore.org/ for this request, and please 
introduce this API usage model. 
  Which module will be updated to consume this API?

>-Original Message-
>From: Tom Zhao [mailto:tz...@solarflare.com]
>Sent: Wednesday, August 21, 2019 12:13 AM
>To: edk2-de...@lists.01.org
>Cc: Kinney, Michael D ; Gao, Liming
>
>Subject: [PATCH v1 1/1] MdePkg: UefiLib: Add a function to check if a
>language is supported
>
>Add a function that checks if a target language is in the supported
>languages list. Add some calls to this function where appropriate in
>UefiLib.c
>
>Cc: Michael D Kinney 
>Cc: Liming Gao 
>Signed-off-by: Tom Zhao 
>---
>  MdePkg/Include/Library/UefiLib.h | 16 ++
>  MdePkg/Library/UefiLib/UefiLib.c | 59 +---
>  2 files changed, 54 insertions(+), 21 deletions(-)
>
>diff --git a/MdePkg/Include/Library/UefiLib.h
>b/MdePkg/Include/Library/UefiLib.h
>index 1650f30ddbc6..9dd170cbe2bf 100644
>--- a/MdePkg/Include/Library/UefiLib.h
>+++ b/MdePkg/Include/Library/UefiLib.h
>@@ -461,6 +461,22 @@ EfiTestChildHandle (
>IN CONST EFI_GUID *ProtocolGuid
>);
>  +/**
>+ * This function checks the supported languages list for a target language
>+ *
>+ * @param  SupportedLanguages  The supported languages
>+ * @param  TargetLanguage  The target language
>+ *
>+ * @return Returns EFI_SUCCESS if the language is supported,
>+ * EFI_UNSUPPORTED otherwise
>+ */
>+EFI_STATUS
>+EFIAPI
>+IsLanguageSupported (
>+  IN CONST CHAR8 *SupportedLanguages,
>+  IN CONST CHAR8 *TargetLanguage
>+  );
>+
>  /**
>This function looks up a Unicode string in UnicodeStringTable.
>  diff --git a/MdePkg/Library/UefiLib/UefiLib.c
>b/MdePkg/Library/UefiLib/UefiLib.c
>index daa4af762e62..56281d25fd99 100644
>--- a/MdePkg/Library/UefiLib/UefiLib.c
>+++ b/MdePkg/Library/UefiLib/UefiLib.c
>@@ -640,6 +640,35 @@ EfiTestChildHandle (
>return Status;
>  }
>  +/**
>+ * This function checks the supported languages list for a target language
>+ *
>+ * @param  SupportedLanguages  The supported languages
>+ * @param  TargetLanguage  The target language
>+ *
>+ * @return Returns EFI_SUCCESS if the language is supported,
>+ * EFI_UNSUPPORTED otherwise
>+ */
>+EFI_STATUS
>+EFIAPI
>+IsLanguageSupported (
>+  IN CONST CHAR8 *SupportedLanguages,
>+  IN CONST CHAR8 *TargetLanguage
>+  )
>+{
>+  UINTN Index;
>+  while (*SupportedLanguages != 0) {
>+for (Index = 0; SupportedLanguages[Index] != 0 &&
>SupportedLanguages[Index] != ';'; Index++);
>+if ((AsciiStrnCmp(SupportedLanguages, TargetLanguage, Index) == 0)
>&& (TargetLanguage[Index] == 0)) {
>+  return EFI_SUCCESS;
>+}
>+SupportedLanguages += Index;
>+for (; *SupportedLanguages != 0 && *SupportedLanguages == ';';
>SupportedLanguages++);
>+  }
>+
>+  return EFI_UNSUPPORTED;
>+}
>+
>  /**
>This function looks up a Unicode string in UnicodeStringTable.
>  @@ -800,24 +829,19 @@ LookupUnicodeString2 (
>// Make sure Language is in the set of Supported Languages
>//
>Found = FALSE;
>-  while (*SupportedLanguages != 0) {
>-if (Iso639Language) {
>+  if (Iso639Language) {
>+while (*SupportedLanguages != 0) {
>if (CompareIso639LanguageCode (Language, SupportedLanguages)) {
>  Found = TRUE;
>  break;
>}
>SupportedLanguages += 3;
>-} else {
>-  for (Index = 0; SupportedLanguages[Index] != 0 &&
>SupportedLanguages[Index] != ';'; Index++);
>-  if ((AsciiStrnCmp(SupportedLanguages, Language, Index) == 0) &&
>(Language[Index] == 0)) {
>-Found = TRUE;
>-break;
>-  }
>-  SupportedLanguages += Index;
>-  for (; *SupportedLanguages != 0 && *SupportedLanguages == ';';
>SupportedLanguages++);
>  }
>+  } else {
>+Found = !IsLanguageSupported(Language, SupportedLanguages);
>}
>  +
>//
>// If Language is not a member of SupportedLanguages, then return
>EFI_UNSUPPORTED
>//
>@@ -1099,24 +1123,17 @@ AddUnicodeString2 (
>// Make sure Language is a member of SupportedLanguages
>//
>Found = FALSE;
>-  while (*SupportedLanguages != 0) {
>-if (Iso639Language) {
>+  if (Iso639Language) {
>+while (*SupportedLanguages != 0) {
>if (CompareIso639LanguageCode (Language, SupportedLanguages)) {
>  Found = TRUE;
>  break;
>}
>SupportedLanguages += 3;
>-} else {
>-  for (Index = 0; SupportedLanguages[Index] != 0 &&
>SupportedLanguages[Index] != ';'; Index++);
>-  if (AsciiStrnCmp(SupportedLanguages, Language, Index) == 0) {
>-Found = TRUE;
>-break;
>-  }
>-  SupportedLanguages += Index;
>-  for (; 

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

[Liming Gao]

Tiger:


From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Tiger 
Liu(BJ-RD)
Sent: Tuesday, August 20, 2019 1:01 PM
To: devel@edk2.groups.io; Gao, Liming 
Subject: 答复: [edk2-devel] [edk2] If use prebuild tools, not need install python 
2.7 anymore?

Hi, Liming:
Based on the below web info:
https://github.com/tianocore/tianocore.github.io/wiki/Edk2-buildtools
[Liming] This page is out of date. buildtools-BaseTools is DEPRECATED. Use 
BaseTools under EDK II instead.

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.”
[Liming] Thanks for your point. I will update this wiki page.

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.
[Liming] Now, edk2 requires Python3.x for build. This change happened one year 
ago. Please see https://edk2.groups.io/g/devel/message/29436.

Liming

Thanks
发件人: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>> 代表 Liming Gao
发送时间: 2019年8月19日 22:46
收件人: devel@edk2.groups.io; Tiger Liu(BJ-RD) 
mailto:tiger...@zhaoxin.com>>
主题: 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 (#46134): https://edk2.groups.io/g/devel/message/46134
Mute This Topic: https://groups.io/mt/32975936/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [Patch][edk2-stable201908] BaseTools: Incorrect error message for library instance not found

[Bob Feng]

BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2099
This is a regression issue introduced by commit e8449e.

This patch is to fix this issue.

Signed-off-by: Bob Feng 
Cc: Liming Gao 
---
 BaseTools/Source/Python/AutoGen/DataPipe.py  | 2 +-
 BaseTools/Source/Python/AutoGen/PlatformAutoGen.py   | 2 +-
 BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py  | 4 +++-
 BaseTools/Source/Python/Workspace/WorkspaceCommon.py | 3 ++-
 4 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/DataPipe.py 
b/BaseTools/Source/Python/AutoGen/DataPipe.py
index 2ca4f9ff4a..8b8cfd1c51 100755
--- a/BaseTools/Source/Python/AutoGen/DataPipe.py
+++ b/BaseTools/Source/Python/AutoGen/DataPipe.py
@@ -87,11 +87,11 @@ class MemoryDataPipe(DataPipe):
 #Module's Library Instance
 ModuleLibs = {}
 libModules = {}
 for m in PlatformInfo.Platform.Modules:
 module_obj = 
BuildDB.BuildObject[m,PlatformInfo.Arch,PlatformInfo.BuildTarget,PlatformInfo.ToolChain]
-Libs = GetModuleLibInstances(module_obj, PlatformInfo.Platform, 
BuildDB.BuildObject, 
PlatformInfo.Arch,PlatformInfo.BuildTarget,PlatformInfo.ToolChain)
+Libs = GetModuleLibInstances(module_obj, PlatformInfo.Platform, 
BuildDB.BuildObject, 
PlatformInfo.Arch,PlatformInfo.BuildTarget,PlatformInfo.ToolChain,PlatformInfo.MetaFile,EdkLogger)
 for lib in Libs:
 try:
 
libModules[(lib.MetaFile.File,lib.MetaFile.Root,lib.Arch,lib.MetaFile.Path)].append((m.File,m.Root,module_obj.Arch,m.Path))
 except:
 
libModules[(lib.MetaFile.File,lib.MetaFile.Root,lib.Arch,lib.MetaFile.Path)] = 
[(m.File,m.Root,module_obj.Arch,m.Path)]
diff --git a/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py 
b/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
index dd629ba2fa..565424a95e 100644
--- a/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
@@ -1087,11 +1087,11 @@ class PlatformAutoGen(AutoGen):
 def GetAllModuleInfo(self,WithoutPcd=True):
 ModuleLibs = set()
 for m in self.Platform.Modules:
 module_obj = 
self.BuildDatabase[m,self.Arch,self.BuildTarget,self.ToolChain]
 if not bool(module_obj.LibraryClass):
-Libs = GetModuleLibInstances(module_obj, self.Platform, 
self.BuildDatabase, self.Arch,self.BuildTarget,self.ToolChain)
+Libs = GetModuleLibInstances(module_obj, self.Platform, 
self.BuildDatabase, 
self.Arch,self.BuildTarget,self.ToolChain,self.MetaFile,EdkLogger)
 else:
 Libs = []
 ModuleLibs.update( 
set([(l.MetaFile.File,l.MetaFile.Root,l.MetaFile.Path,l.MetaFile.BaseName,l.MetaFile.OriginalPath,l.Arch,True)
 for l in Libs]))
 if WithoutPcd and module_obj.PcdIsDriver:
 continue
diff --git a/BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py 
b/BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py
index ea0d8f8bfb..2494267472 100644
--- a/BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py
@@ -246,11 +246,13 @@ class WorkspaceAutoGen(AutoGen):
 if BuildData.MetaFile.Ext == '.inf' and str(BuildData) in 
Platform.Modules :
 Libs.extend(GetModuleLibInstances(BuildData, Platform,
  self.BuildDatabase,
  Arch,
  self.BuildTarget,
- self.ToolChain
+ self.ToolChain,
+ self.Platform.MetaFile,
+ EdkLogger
  ))
 for BuildData in list(self.BuildDatabase._CACHE_.values()):
 if BuildData.Arch != Arch:
 continue
 if BuildData.MetaFile.Ext == '.inf':
diff --git a/BaseTools/Source/Python/Workspace/WorkspaceCommon.py 
b/BaseTools/Source/Python/Workspace/WorkspaceCommon.py
index 76583f46e5..cbbd550dbd 100644
--- a/BaseTools/Source/Python/Workspace/WorkspaceCommon.py
+++ b/BaseTools/Source/Python/Workspace/WorkspaceCommon.py
@@ -13,10 +13,11 @@ from .BuildClassObject import LibraryClassObject
 import Common.GlobalData as GlobalData
 from Workspace.BuildClassObject import StructurePcd
 from Common.BuildToolError import RESOURCE_NOT_AVAILABLE
 from Common.BuildToolError import OPTION_MISSING
 from Common.BuildToolError import BUILD_ERROR
+import Common.EdkLogger as EdkLogger
 
 class OrderedListDict(OrderedDict):
 def __init__(self, *args, **kwargs):
 super(OrderedListDict, self).__init__(*args, **kwargs)
 self.default_factory = list
@@ -83,11 +84,11 @@ def GetDeclaredPcd(Platform, BuildDatabase, Arch, Target, 
Toolchain, additionalP
 #  @param Target: Current 

[edk2-devel] [edk2-test][Patch 1/1] uefi-sct/SctPkg: Eliminate 2nd execution of ExitBootServices Test

[Eric Jin]

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

Cc: Supreeth Venkatesh 
Signed-off-by: Eric Jin 
---
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/ImageBBTest.inf
  |  3 ++-
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/ImageBBTest.h
|  9 -
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/ImageBBTestConformance.c
 | 98 
+++---
 3 files changed, 93 insertions(+), 17 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/ImageBBTest.inf
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/ImageBBTest.inf
index 49ad79915934..3de43a20e8a4 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/ImageBBTest.inf
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/ImageBBTest.inf
@@ -1,7 +1,7 @@
 ## @file
 #
 #  Copyright 2006 - 2012 Unified EFI, Inc.
-#  Copyright (c) 2010 - 2012, Intel Corporation. All rights reserved.
+#  Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
@@ -53,4 +53,5 @@
 
 [Protocols]
   gEfiTestProfileLibraryGuid
+  gEfiTestRecoveryLibraryGuid
   gBlackBoxEfiHIIPackageListProtocolGuid
diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/ImageBBTest.h
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/ImageBBTest.h
index b1c35fee7435..008584577ed1 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/ImageBBTest.h
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/ImageBBTest.h
@@ -1,7 +1,7 @@
 /** @file
 
   Copyright 2006 - 2017 Unified EFI, Inc.
-  Copyright (c) 2010 - 2017, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -35,6 +35,13 @@ Abstract:
 #include EFI_PROTOCOL_DEFINITION (LoadFile)
 
 #include EFI_TEST_PROTOCOL_DEFINITION (TestProfileLibrary)
+#include EFI_TEST_PROTOCOL_DEFINITION (TestRecoveryLibrary)
+
+typedef struct _RESET_DATA {
+  UINTN   Step;
+  UINTN   TplIndex;
+  UINT32  RepeatTimes;
+} RESET_DATA;
 
 #if (EFI_SPECIFICATION_VERSION >= 0x0002000A)
 
diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/ImageBBTestConformance.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/ImageBBTestConformance.c
index 0a26d46847da..e90afe7ecae0 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/ImageBBTestConformance.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/ImageServices/BlackBoxTest/ImageBBTestConformance.c
@@ -1,7 +1,7 @@
 /** @file
 
   Copyright 2006 - 2016 Unified EFI, Inc.
-  Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -30,7 +30,8 @@ Abstract:
 #define TEST_VENDOR1_GUID \
   { 0xF6FAB04F, 0xACAF, 0x4af3, { 0xB9, 0xFA, 0xDC, 0xF9, 0x7F, 0xB4, 0x42, 
0x6F } }
 
-#define MAX_BUFFER_SIZE  10
+#define STATUS_BUFFER_SIZE   8
+#define RECOVER_BUFFER_SIZE  1024
 
 EFI_GUID gTestVendor1Guid = TEST_VENDOR1_GUID;
 
@@ -778,19 +779,23 @@ BBTestExitBootServicesConsistencyTest (
   )
 {
   EFI_STANDARD_TEST_LIBRARY_PROTOCOL   *StandardLib;
+  EFI_TEST_RECOVERY_LIBRARY_PROTOCOL   *RecoveryLib;
   EFI_STATUS   Status;
   EFI_TEST_ASSERTION   AssertionType;
   UINTNMapKey;
-
+  UINTNSize;
   UINTNNumbers;
   UINTNDataSize;
-  UINT8Data[MAX_BUFFER_SIZE];
+  RESET_DATA   *ResetData;
+  UINT8Data[STATUS_BUFFER_SIZE];
+  UINT8Buffer[RECOVER_BUFFER_SIZE];
   EFI_STATUS   ReturnStatus;
 
   //
   // Init
   //
   StandardLib = NULL;
+  RecoveryLib = NULL;
 
   //
   // Get the Standard Library Interface
@@ -803,6 +808,14 @@ BBTestExitBootServicesConsistencyTest (
 return Status;
   }
 
+  Status = gtBS->HandleProtocol (
+   SupportHandle,
+   ,
+   (VOID **) );
+  if (EFI_ERROR(Status)) {
+return Status;
+  }
+
   Status =