Re: [edk2] [PATCH 0/3] MdePkg, MdeModulePkg, Vlv2TbltDevicePkg: 64-bit LoopTimes in S3 MEM_POLL

[Zeng, Star]

On 2016/12/2 9:53, Yao, Jiewen wrote:

HI Laszlo
Thank you to raise this long time existing issue. :-)

There is historic reason that we inherit this undocumented API from EDK-I to 
EDKII.

I do not object your update.
I am thinking if it is time to create a new API which can match PI 
specification, and suggest all consumers use the new API.

RETURN_STATUS
EFIAPI
S3BootScriptSavePiMemPoll (
  IN  S3_BOOT_SCRIPT_LIB_WIDTH  Width,
  IN  UINT64Address,
  IN  VOID  *Data,
  IN  VOID  *DataMask,
  IN  UINT64Delay,
  );


If the new API is introduced, the old one could be marked as deprecated 
by DISABLE_NEW_DEPRECATED_INTERFACES.


Thanks,
Star



Thank you
Yao Jiewen



-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Laszlo Ersek
Sent: Friday, December 2, 2016 1:56 AM
To: edk2-devel-01 
Cc: Tian, Feng ; Gao, Liming ;
Kinney, Michael D ; Zeng, Star
; Wei, David 
Subject: [edk2] [PATCH 0/3] MdePkg, MdeModulePkg, Vlv2TbltDevicePkg:
64-bit LoopTimes in S3 MEM_POLL

While working on S3 boot script related stuff in OVMF, I wanted to see
if infinite blocking was possible in the various POLL opcodes. While
edk2's implementation of IO_POLL, PCI_CONFIG_POLL and
PCI_CONFIG2_POLL
follows the PI spec vol5 closely, even internally (using 100ns delay
units), the MEM_POLL internals differ -- they are microseconds based.

That's not a problem per se (it's just a different internal opcode
representation, which is fine); the problem is that the current
internals don't conform to the spec: in 32-bit builds, the UINT64 number
of 100ns units that the caller intends to wait for is silently
truncated, for no good reason. This issue is not hard to fix (we can
even keep the microseconds-based internals), so let's fix it.

Repo:   https://github.com/lersek/edk2/
Branch: mempoll_looptimes_64bit

Cc: David Wei 
Cc: Feng Tian 
Cc: Liming Gao 
Cc: Mang Guo 
Cc: Michael D Kinney 
Cc: Star Zeng 

Thanks
Laszlo

Laszlo Ersek (3):
  MdePkg, MdeModulePkg: S3BootScriptSaveMemPoll(): accept 64-bit
LoopTimes
  MdeModulePkg: S3SaveStateDxe, SmmS3SaveState: save 64-bit
LoopTimes
  Vlv2TbltDevicePkg/BootScriptSaveDxe: save 64-bit LoopTimes

 MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c  | 2 +-
 MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c| 8

 MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c | 8

 MdePkg/Include/Library/S3BootScriptLib.h| 2 +-
 MdePkg/Library/BaseS3BootScriptLibNull/BootScriptLib.c  | 2 +-
 Vlv2TbltDevicePkg/BootScriptSaveDxe/ScriptSave.c| 4 ++--
 6 files changed, 13 insertions(+), 13 deletions(-)

--
2.9.2

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


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

Re: [edk2] [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5

[Gao, Liming]

I agree to root cause this issue with GCC6. Could you help submit this issue in 
bugzilia? Then, we will investigate it further. 

Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
Ersek
Sent: Friday, December 02, 2016 2:43 AM
To: Anthony PERARD ; Justen, Jordan L 
; Gao, Liming ; Zhu, Yonghong 
; Ard Biesheuvel 
Cc: edk2-de...@ml01.01.org
Subject: Re: [edk2] [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled 
with GCC5

On 12/01/16 16:28, Anthony PERARD wrote:
> Hi,
> 
> That might be only with the Xen part of OVMF but now that the GCC5 
> toolchains is used with my gcc (6.2.1 20160830, Arch Linux), OVMF fail 
> to boot in Xen guests.
> 
> Here is the result:
>  X64 Exception Type - 06(#UD - Invalid Opcode)  CPU Apic ID -  
> 
> RIP  - 1F26AF6B, CS  - 0038, RFLAGS - 
> 00010202 RAX  - 0001, RCX - 1F26AF51, RDX 
> - 0004 RBX  - , RSP - 1F43C510, 
> RBP - 1E583D18 RSI  - 0003, RDI - 0001
> R8   - , R9  - , R10 - 1E58DB98
> R11  - 0002, R12 - 1E58D898, R13 - 
> 
> R14  - 1E58D8A0, R15 - 1F26D001
> DS   - 0030, ES  - 0030, FS  - 0030
> GS   - 0030, SS  - 0030
> CR0  - 8033, CR2 - , CR3 - 
> 1F3DB000
> CR4  - 0668, CR8 - 
> DR0  - , DR1 - , DR2 - 
> 
> DR3  - , DR6 - 0FF0, DR7 - 
> 0400 GDTR - 1F3C9A98 0047, LDTR - 
> 
> IDTR - 1EB0A018 0FFF,   TR - 
> FXSAVE_STATE - 1F43C170
>  Find PE image 
> ./Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/XenBusDxe/XenBusDxe/DEBUG/XenBusDxe.dll
>  (ImageBase=1F266000, EntryPoint=1F2669D5) 
> 
> Removing the gcc option -flto in only the XenBusDxe module makes OVMF 
> boot.
> 
> While trying to debug that, I've added some debug prints (in this 
> module and in XenPvBlkDxe), and the exception could change and become 
> a "page fault" instead, or even an assert failure in the PrintLib, 
> that was the ASSERT(Buffer != NULL) at I think
> MdePkg/Library/BasePrintLib/PrintLibInternal.c:366
> 
> Adding EFIAPI to internal functions in XenBusDxe makes things work 
> again.  My guest is that gcc would bypass (optimise) an exported 
> functions and call directly an internal one but without reordering the 
> arguments (EFIAPI vs nothing).
> 
> Does that make sense?

Thank you for the investigation. It is strange that only the Xen modules are 
affected, I'm unsure what that's the case.

Either way, it seems to be a gcc-6 bug, or an edk2 toolchain bug. You should 
*not* need EFIAPI for functions with external linkage if the calls to them 
straddle only files in the same module. I'm suspecting
gcc-6 (we've received no such reports with gcc-5). Maybe we need a GCC6 
toolchain as well, for turning off some new features in gcc-6?

Jordan, Liming, Yonghong, Ard -- any ideas?

Anthony: while we all figure this out, please consider building OVMF with the 
"-b NOOPT" switch. Support for the NOOPT build target has recently been added 
to the GCC Ia32/X64 toolchains in BaseTools, and to the OVMF DSC files as well. 
The build targets correspond to:

RELEASE -- compiler optimization enabled; DEBUG, ASSERT, and similar
   DebugLib features compiled out
DEBUG   -- compiler optimization enabled; DebugLib features preserved
NOOPT   -- compiler optimization disabled; DebugLib features preserved

(Note that for ArmVirtPkg and the GCC AARCH64 toolchains in BaseTools, there is 
no NOOPT, and DEBUG means actually NOOPT -- if I remember correctly. Ard will 
correct me if I'm wrong :))

If "-b NOOPT" works for you, I'd prefer that as a temporary solution (until the 
root cause is found and addressed) to the XenBusDxe patches.

Hrpmf, wait a second, I do see something interesting: in this series you
*are* modifying APIs declared in a library class header (namely 
"OvmfPkg/Include/Library/XenHypercallLib.h"). Such functions (public
libraries) *are* required to specify EFIAPI.

What happens if you apply patch #1 only?

Thanks!
Laszlo

> Anthony PERARD (4):
>   OvmfPkg/XenHypercallLib: Add EFIAPI
>   OvmfPkg/XenBusDxe: Add EFIAPI to XenEventChannelNotify
>   OvmfPkg/XenBusDxe: Add EFIAPI to XenStore functions
>   OvmfPkg/XenBusDxe: Add EFIAPI to XenGrantTable{Grant,End}Access
> 
>  OvmfPkg/Include/Library/XenHypercallLib.h  |  3 +++
>  OvmfPkg/Library/XenHypercallLib/XenHypercall.c |  3 +++
>  OvmfPkg/XenBusDxe/EventChannel.c   |  1 +
>  OvmfPkg/XenBusDxe/EventChannel.h 

Re: [edk2] [PATCH] BaseTools/VolInfo: Fix printf issue using '%ls' in format string

[Wu, Hao A]

Got it. I will move those 2 implementation before main() before code
check-in.

Best Regards,
Hao Wu


> -Original Message-
> From: Gao, Liming
> Sent: Friday, December 02, 2016 10:56 AM
> To: Wu, Hao A; edk2-devel@lists.01.org
> Cc: Zhu, Yonghong
> Subject: RE: [PATCH] BaseTools/VolInfo: Fix printf issue using '%ls' in format
> string
> 
> Hao:
>   Place move  UnicodeStrLen() and Unicode2AsciiString() implementation
> before main() function. If so, they are not required to be declared again.
> 
>   Other changes are good. Reviewed-by: Liming Gao 
> 
> Thanks
> Liming
> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, December 01, 2016 8:40 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Gao, Liming ;
> Zhu, Yonghong 
> Subject: [PATCH] BaseTools/VolInfo: Fix printf issue using '%ls' in format
> string
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=257
> 
> For GCC compilers, when building with option '-fshort-wchar', wide char
> string format '%ls' does not work properly for printf() function. The string
> specified by '%ls' will not be printed.
> 
> This commit avoids using '%ls' for printf() function and converts the wide 
> char
> string to char string for printing.
> 
> Cc: Liming Gao 
> Cc: Yonghong Zhu 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Hao Wu 
> ---
>  BaseTools/Source/C/VolInfo/VolInfo.c | 79
> +++-
>  1 file changed, 78 insertions(+), 1 deletion(-)
> 
> diff --git a/BaseTools/Source/C/VolInfo/VolInfo.c
> b/BaseTools/Source/C/VolInfo/VolInfo.c
> index 46c7212..7d63e59 100644
> --- a/BaseTools/Source/C/VolInfo/VolInfo.c
> +++ b/BaseTools/Source/C/VolInfo/VolInfo.c
> @@ -148,6 +148,17 @@ Usage (
>VOID
>);
> 
> +UINT32
> +UnicodeStrLen (
> +  IN CHAR16 *String
> +  );
> +
> +VOID
> +Unicode2AsciiString (
> +  IN  CHAR16 *Source,
> +  OUT CHAR8  *Destination
> +  );
> +
>  int
>  main (
>int   argc,
> @@ -1606,6 +1617,7 @@ Returns:
>UINT32  RealHdrLen;
>CHAR8   *ToolInputFileName;
>CHAR8   *ToolOutputFileName;
> +  CHAR8   *UIFileName;
> 
>ParsedLength = 0;
>ToolInputFileName = NULL;
> @@ -1714,7 +1726,14 @@ Returns:
>break;
> 
>  case EFI_SECTION_USER_INTERFACE:
> -  printf ("  String: %ls\n", (wchar_t *) &((EFI_USER_INTERFACE_SECTION *)
> Ptr)->FileNameString);
> +  UIFileName = (CHAR8 *) malloc (UnicodeStrLen
> (((EFI_USER_INTERFACE_SECTION *) Ptr)->FileNameString) + 1);
> +  if (UIFileName == NULL) {
> +Error (NULL, 0, 4001, "Resource", "memory cannot be allocated!");
> +return EFI_OUT_OF_RESOURCES;
> +  }
> +  Unicode2AsciiString (((EFI_USER_INTERFACE_SECTION *) Ptr)-
> >FileNameString, UIFileName);
> +  printf ("  String: %s\n", UIFileName);
> +  free (UIFileName);
>break;
> 
>  case EFI_SECTION_FIRMWARE_VOLUME_IMAGE:
> @@ -2360,3 +2379,61 @@ Returns:
>  Reserved for future use\n");  }
> 
> +UINT32
> +UnicodeStrLen (
> +  IN CHAR16 *String
> +  )
> +  /*++
> +
> +  Routine Description:
> +
> +  Returns the length of a null-terminated unicode string.
> +
> +  Arguments:
> +
> +String - The pointer to a null-terminated unicode string.
> +
> +  Returns:
> +
> +N/A
> +
> +  --*/
> +{
> +  UINT32  Length;
> +
> +  for (Length = 0; *String != L'\0'; String++, Length++) {
> +;
> +  }
> +  return Length;
> +}
> +
> +VOID
> +Unicode2AsciiString (
> +  IN  CHAR16 *Source,
> +  OUT CHAR8  *Destination
> +  )
> +  /*++
> +
> +  Routine Description:
> +
> +  Convert a null-terminated unicode string to a null-terminated ascii string.
> +
> +  Arguments:
> +
> +Source  - The pointer to the null-terminated input unicode string.
> +Destination - The pointer to the null-terminated output ascii string.
> +
> +  Returns:
> +
> +N/A
> +
> +  --*/
> +{
> +  while (*Source != '\0') {
> +*(Destination++) = (CHAR8) *(Source++);
> +  }
> +  //
> +  // End the ascii with a NULL.
> +  //
> +  *Destination = '\0';
> +}
> --
> 1.9.5.msysgit.0

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

Re: [edk2] [PATCH] BaseTools/VolInfo: Fix printf issue using '%ls' in format string

[Gao, Liming]

Hao:
  Place move  UnicodeStrLen() and Unicode2AsciiString() implementation before 
main() function. If so, they are not required to be declared again. 

  Other changes are good. Reviewed-by: Liming Gao 

Thanks
Liming
-Original Message-
From: Wu, Hao A 
Sent: Thursday, December 01, 2016 8:40 PM
To: edk2-devel@lists.01.org
Cc: Wu, Hao A ; Gao, Liming ; Zhu, 
Yonghong 
Subject: [PATCH] BaseTools/VolInfo: Fix printf issue using '%ls' in format 
string

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

For GCC compilers, when building with option '-fshort-wchar', wide char string 
format '%ls' does not work properly for printf() function. The string specified 
by '%ls' will not be printed.

This commit avoids using '%ls' for printf() function and converts the wide char 
string to char string for printing.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 BaseTools/Source/C/VolInfo/VolInfo.c | 79 +++-
 1 file changed, 78 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/C/VolInfo/VolInfo.c 
b/BaseTools/Source/C/VolInfo/VolInfo.c
index 46c7212..7d63e59 100644
--- a/BaseTools/Source/C/VolInfo/VolInfo.c
+++ b/BaseTools/Source/C/VolInfo/VolInfo.c
@@ -148,6 +148,17 @@ Usage (
   VOID
   );
 
+UINT32
+UnicodeStrLen (
+  IN CHAR16 *String
+  );
+
+VOID
+Unicode2AsciiString (
+  IN  CHAR16 *Source,
+  OUT CHAR8  *Destination
+  );
+
 int
 main (
   int   argc,
@@ -1606,6 +1617,7 @@ Returns:
   UINT32  RealHdrLen;
   CHAR8   *ToolInputFileName;
   CHAR8   *ToolOutputFileName;
+  CHAR8   *UIFileName;
 
   ParsedLength = 0;
   ToolInputFileName = NULL;
@@ -1714,7 +1726,14 @@ Returns:
   break;
 
 case EFI_SECTION_USER_INTERFACE:
-  printf ("  String: %ls\n", (wchar_t *) &((EFI_USER_INTERFACE_SECTION *) 
Ptr)->FileNameString);
+  UIFileName = (CHAR8 *) malloc (UnicodeStrLen 
(((EFI_USER_INTERFACE_SECTION *) Ptr)->FileNameString) + 1);
+  if (UIFileName == NULL) {
+Error (NULL, 0, 4001, "Resource", "memory cannot be allocated!");
+return EFI_OUT_OF_RESOURCES;
+  }
+  Unicode2AsciiString (((EFI_USER_INTERFACE_SECTION *) 
Ptr)->FileNameString, UIFileName);
+  printf ("  String: %s\n", UIFileName);
+  free (UIFileName);
   break;
 
 case EFI_SECTION_FIRMWARE_VOLUME_IMAGE:
@@ -2360,3 +2379,61 @@ Returns:
 Reserved for future use\n");  }
 
+UINT32
+UnicodeStrLen (
+  IN CHAR16 *String
+  )
+  /*++
+
+  Routine Description:
+
+  Returns the length of a null-terminated unicode string.
+
+  Arguments:
+
+String - The pointer to a null-terminated unicode string.
+
+  Returns:
+
+N/A
+
+  --*/
+{
+  UINT32  Length;
+
+  for (Length = 0; *String != L'\0'; String++, Length++) {
+;
+  }
+  return Length;
+}
+
+VOID
+Unicode2AsciiString (
+  IN  CHAR16 *Source,
+  OUT CHAR8  *Destination
+  )
+  /*++
+
+  Routine Description:
+
+  Convert a null-terminated unicode string to a null-terminated ascii string.
+
+  Arguments:
+
+Source  - The pointer to the null-terminated input unicode string.
+Destination - The pointer to the null-terminated output ascii string.
+
+  Returns:
+
+N/A
+
+  --*/
+{
+  while (*Source != '\0') {
+*(Destination++) = (CHAR8) *(Source++);
+  }
+  //
+  // End the ascii with a NULL.
+  //
+  *Destination = '\0';
+}
--
1.9.5.msysgit.0

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

Re: [edk2] [Patch] BaseTools: Support QuotedString for PREBUILD/POSTBUILD in DSC file

[Gao, Liming]

Reviewed-by: Liming Gao 

-Original Message-
From: Zhu, Yonghong 
Sent: Wednesday, November 30, 2016 4:24 PM
To: edk2-devel@lists.01.org
Cc: Gao, Liming 
Subject: [Patch] BaseTools: Support QuotedString for PREBUILD/POSTBUILD in DSC 
file

If the prebuild/postbuild script statement start with double quotations, 
current tool report error, while DSC spec allow this usage. so update tool to 
support it.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/Workspace/WorkspaceDatabase.py | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py 
b/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py
index 46179a3..e7bc87d 100644
--- a/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py
+++ b/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py
@@ -229,13 +229,25 @@ class DscBuildData(PlatformBuildClassObject):
 ErrorCode, ErrorInfo = self._FlashDefinition.Validate('.fdf')
 if ErrorCode != 0:
 EdkLogger.error('build', ErrorCode, File=self.MetaFile, 
Line=Record[-1],
 ExtraData=ErrorInfo)
 elif Name == TAB_DSC_PREBUILD:
-self._Prebuild = PathClass(NormPath(Record[2], self._Macros), 
GlobalData.gWorkspace)
+PrebuildValue = Record[2]
+if Record[2][0] == '"':
+if Record[2][-1] != '"':
+EdkLogger.error('build', FORMAT_INVALID, 'Missing 
double quotes in the end of %s statement.' % TAB_DSC_PREBUILD,
+File=self.MetaFile, Line=Record[-1])
+PrebuildValue = Record[2][1:-1]
+self._Prebuild = PathClass(NormPath(PrebuildValue, 
+ self._Macros), GlobalData.gWorkspace)
 elif Name == TAB_DSC_POSTBUILD:
-self._Postbuild = PathClass(NormPath(Record[2], self._Macros), 
GlobalData.gWorkspace)
+PostbuildValue = Record[2]
+if Record[2][0] == '"':
+if Record[2][-1] != '"':
+EdkLogger.error('build', FORMAT_INVALID, 'Missing 
double quotes in the end of %s statement.' % TAB_DSC_POSTBUILD,
+File=self.MetaFile, Line=Record[-1])
+PostbuildValue = Record[2][1:-1]
+self._Postbuild = PathClass(NormPath(PostbuildValue, 
+ self._Macros), GlobalData.gWorkspace)
 elif Name == TAB_DSC_DEFINES_SUPPORTED_ARCHITECTURES:
 self._SupArchList = GetSplitValueList(Record[2], 
TAB_VALUE_SPLIT)
 elif Name == TAB_DSC_DEFINES_BUILD_TARGETS:
 self._BuildTargets = GetSplitValueList(Record[2])
 elif Name == TAB_DSC_DEFINES_SKUID_IDENTIFIER:
--
2.6.1.windows.1

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

Re: [edk2] [Patch] BaseTools: Fix the bug to parse the new map file format

[Gao, Liming]

Reviewed-by: Liming Gao 

-Original Message-
From: Zhu, Yonghong 
Sent: Wednesday, November 30, 2016 4:23 PM
To: edk2-devel@lists.01.org
Cc: Gao, Liming 
Subject: [Patch] BaseTools: Fix the bug to parse the new map file format

Current the variable and Pcd format save in the map file is changed, so this 
patch is to support this new format.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/Common/Misc.py | 11 +++
 .../Source/Python/GenPatchPcdTable/GenPatchPcdTable.py | 14 +-
 2 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/BaseTools/Source/Python/Common/Misc.py 
b/BaseTools/Source/Python/Common/Misc.py
index 3be1f0f..43d0818 100644
--- a/BaseTools/Source/Python/Common/Misc.py
+++ b/BaseTools/Source/Python/Common/Misc.py
@@ -72,11 +72,11 @@ def GetVariableOffset(mapfilepath, efifilepath, varnames):
 def _parseForGCC(lines, efifilepath, varnames):
 """ Parse map file generated by GCC linker """
 status = 0
 sections = []
 varoffset = []
-for line in lines:
+for index, line in enumerate(lines):
 line = line.strip()
 # status machine transection
 if status == 0 and line == "Memory Configuration":
 status = 1
 continue
@@ -86,18 +86,21 @@ def _parseForGCC(lines, efifilepath, varnames):
 elif status ==2 and line == 'START GROUP':
 status = 3
 continue
 
 # status handler
-if status == 2:
+if status == 3:
 m = re.match('^([\w_\.]+) +([\da-fA-Fx]+) +([\da-fA-Fx]+)$', line)
 if m != None:
 sections.append(m.groups(0))
 for varname in varnames:
-m = re.match("^([\da-fA-Fx]+) +[_]*(%s)$" % varname, line)
+m = re.match(".data.(%s)$" % varname, line)
 if m != None:
-varoffset.append((varname, int(m.groups(0)[0], 16) , 
int(sections[-1][1], 16), sections[-1][0]))
+if lines[index + 1]:
+m = re.match('^([\da-fA-Fx]+) +([\da-fA-Fx]+)', 
lines[index + 1].strip())
+if m != None:
+varoffset.append((varname, 
+ int(m.groups(0)[0], 16) , int(sections[-1][1], 16), sections[-1][0]))
 
 if not varoffset:
 return []
 # get section information from efi file
 efisecs = PeImageClass(efifilepath).SectionHeaderList
diff --git a/BaseTools/Source/Python/GenPatchPcdTable/GenPatchPcdTable.py 
b/BaseTools/Source/Python/GenPatchPcdTable/GenPatchPcdTable.py
index f4fd51a..4452fac 100644
--- a/BaseTools/Source/Python/GenPatchPcdTable/GenPatchPcdTable.py
+++ b/BaseTools/Source/Python/GenPatchPcdTable/GenPatchPcdTable.py
@@ -64,11 +64,11 @@ def _parseForGCC(lines, efifilepath):
 """ Parse map file generated by GCC linker """
 status = 0
 imageBase = -1
 sections = []
 bpcds = []
-for line in lines:
+for index, line in enumerate(lines):
 line = line.strip()
 # status machine transection
 if status == 0 and line == "Memory Configuration":
 status = 1
 continue
@@ -78,18 +78,22 @@ def _parseForGCC(lines, efifilepath):
 elif status ==2 and line == 'START GROUP':
 status = 3
 continue
 
 # status handler
-if status == 2:
+if status == 3:
 m = re.match('^([\w_\.]+) +([\da-fA-Fx]+) +([\da-fA-Fx]+)$', line)
 if m != None:
 sections.append(m.groups(0))
-if status == 2:
-m = re.match("^([\da-fA-Fx]+) +[_]+gPcd_BinaryPatch_([\w_\d]+)$", 
line)
+if status == 3:
+m = re.match('^.data._gPcd_BinaryPatch_([\w_\d]+)$', line)
 if m != None:
-bpcds.append((m.groups(0)[1], int(m.groups(0)[0], 16) , 
int(sections[-1][1], 16), sections[-1][0]))
+if lines[index + 1]:
+PcdName = m.groups(0)[0]
+m = re.match('^([\da-fA-Fx]+) +([\da-fA-Fx]+)', 
lines[index + 1].strip())
+if m != None:
+bpcds.append((PcdName, int(m.groups(0)[0], 16) 
+ , int(sections[-1][1], 16), sections[-1][0]))
 
 # get section information from efi file
 efisecs = PeImageClass(efifilepath).SectionHeaderList
 if efisecs == None or len(efisecs) == 0:
 return None
--
2.6.1.windows.1

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

[edk2] Root Cause of Parse Failure With Redirected Input

[Tim Lewis]

  if (StrStr (TempLine, L"ShellCommand,") == TempLine) {
LoopVariable++;
  }

This line fails because, with redirected input, the file has the UCS-2 byte 
order mark, so the string "ShellCommand," is not at the beginning of the line. 
With the file, the byte order mark is not present.

Why?

 if (StreamingUnicode) {
   TempLine = ParseReturnStdInLine (FileHandle);
 } else {
   TempLine = ShellFileHandleReturnLine (FileHandle, );
 }

The Shell library function ShellFileHandleReturnLine will strip off the byte 
order mark. But the ParseReturnStdInLine does not. So the first character on 
the line is not 'S', it is the byte order mark.

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

Re: [edk2] [PATCH] MdeModulePkg/PiSmmCore: AllocatePool should use MemoryType.

[Yao, Jiewen]

Thank you Laszlo.

This time, I did not use number purposely.

My thinking is that each patch resolves a specific problem. Although I fixed 
all of them at same time, they can be check in independently.

Thank you
Yao Jiewen

From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Friday, December 2, 2016 5:51 AM
To: Yao, Jiewen ; edk2-de...@ml01.01.org
Cc: Kinney, Michael D ; Fan, Jeff 

Subject: Re: [edk2] [PATCH] MdeModulePkg/PiSmmCore: AllocatePool should use 
MemoryType.

On 12/01/16 09:23, Jiewen Yao wrote:
> PiSmmCore supports page level protection based upon the Memory Type
> (EfiRuntimeServicesCode/EfiRuntimeServicesData) and PE image.
>
> However, the Memory Type information is ignored in AllocatePool().
> If a caller calls AllocatePool with EfiRuntimeServicesCode,
> the final memory is still allocated as EfiRuntimeServicesData.
>
> This patch supports AllocatePool with EfiRuntimeServicesCode.
>
> Cc: Jeff Fan >
> Cc: Michael D Kinney 
> >
> Cc: Laszlo Ersek >
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiewen Yao >
> ---
>  MdeModulePkg/Core/PiSmmCore/PiSmmCore.h  |  13 ++-
>  MdeModulePkg/Core/PiSmmCore/Pool.c   |  66 +---
>  MdeModulePkg/Core/PiSmmCore/SmramProfileRecord.c | 114 +++-
>  3 files changed, 124 insertions(+), 69 deletions(-)

series
Regression-tested-by: Laszlo Ersek >

(Please make sure to number the patches in the series next time.)

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

Re: [edk2] [PATCH 5/7] DuetPkg: Remove use of IntelFrameworkModulePkg legacy libs

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni 

Regards,
Ray

>-Original Message-
>From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
>Sent: Thursday, December 1, 2016 11:53 PM
>To: edk2-devel@lists.01.org
>Cc: Ni, Ruiyu ; Justen, Jordan L 
>; Andrew Fish ; Laszlo
>Ersek ; Kinney, Michael D ; 
>Steele, Kelly ; Wei,
>David ; Guo, Mang ; Ard Biesheuvel 
>
>Subject: [PATCH 5/7] DuetPkg: Remove use of IntelFrameworkModulePkg legacy libs
>
>LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
>from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
>kept for compatibility.
>
>Since the libraries are identical, move DuetPkg to use the MdeModulePkg
>versions instead.
>
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Leif Lindholm 
>---
> DuetPkg/DuetPkgIa32.dsc | 4 ++--
> DuetPkg/DuetPkgX64.dsc  | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
>diff --git a/DuetPkg/DuetPkgIa32.dsc b/DuetPkg/DuetPkgIa32.dsc
>index 3b59343..7dd963b 100644
>--- a/DuetPkg/DuetPkgIa32.dsc
>+++ b/DuetPkg/DuetPkgIa32.dsc
>@@ -178,7 +178,7 @@
>   gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2F
>   gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x8042
> 
>-
>DebugLib|IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
>+  
>DebugLib|MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
>
>ReportStatusCodeLib|DuetPkg/Library/DxeCoreReportStatusCodeLibFromHob/DxeCoreReportStatusCodeLibFromHob.inf
>   }
>
>@@ -211,7 +211,7 @@
>   DuetPkg/EfiLdr/EfiLdr.inf {
> 
>   DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
>-  
>NULL|IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
>+  
>NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
>   }
>   IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf {
> 
>diff --git a/DuetPkg/DuetPkgX64.dsc b/DuetPkg/DuetPkgX64.dsc
>index c23354a..1b08a95 100644
>--- a/DuetPkg/DuetPkgX64.dsc
>+++ b/DuetPkg/DuetPkgX64.dsc
>@@ -179,7 +179,7 @@
>   gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2F
>   gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x8042
> 
>-
>DebugLib|IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
>+  
>DebugLib|MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
>
>ReportStatusCodeLib|DuetPkg/Library/DxeCoreReportStatusCodeLibFromHob/DxeCoreReportStatusCodeLibFromHob.inf
>   }
>
>@@ -212,7 +212,7 @@
>   DuetPkg/EfiLdr/EfiLdr.inf {
> 
>   DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
>-  
>NULL|IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
>+  
>NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
>   }
>   IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf {
> 
>--
>2.10.2

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

Re: [edk2] [PATCH 0/3] MdePkg, MdeModulePkg, Vlv2TbltDevicePkg: 64-bit LoopTimes in S3 MEM_POLL

[Yao, Jiewen]

HI Laszlo
Thank you to raise this long time existing issue. :-)

There is historic reason that we inherit this undocumented API from EDK-I to 
EDKII.

I do not object your update.
I am thinking if it is time to create a new API which can match PI 
specification, and suggest all consumers use the new API.

RETURN_STATUS
EFIAPI
S3BootScriptSavePiMemPoll (
  IN  S3_BOOT_SCRIPT_LIB_WIDTH  Width,
  IN  UINT64Address,
  IN  VOID  *Data,
  IN  VOID  *DataMask,
  IN  UINT64Delay,
  );

Thank you
Yao Jiewen


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Friday, December 2, 2016 1:56 AM
> To: edk2-devel-01 
> Cc: Tian, Feng ; Gao, Liming ;
> Kinney, Michael D ; Zeng, Star
> ; Wei, David 
> Subject: [edk2] [PATCH 0/3] MdePkg, MdeModulePkg, Vlv2TbltDevicePkg:
> 64-bit LoopTimes in S3 MEM_POLL
> 
> While working on S3 boot script related stuff in OVMF, I wanted to see
> if infinite blocking was possible in the various POLL opcodes. While
> edk2's implementation of IO_POLL, PCI_CONFIG_POLL and
> PCI_CONFIG2_POLL
> follows the PI spec vol5 closely, even internally (using 100ns delay
> units), the MEM_POLL internals differ -- they are microseconds based.
> 
> That's not a problem per se (it's just a different internal opcode
> representation, which is fine); the problem is that the current
> internals don't conform to the spec: in 32-bit builds, the UINT64 number
> of 100ns units that the caller intends to wait for is silently
> truncated, for no good reason. This issue is not hard to fix (we can
> even keep the microseconds-based internals), so let's fix it.
> 
> Repo:   https://github.com/lersek/edk2/
> Branch: mempoll_looptimes_64bit
> 
> Cc: David Wei 
> Cc: Feng Tian 
> Cc: Liming Gao 
> Cc: Mang Guo 
> Cc: Michael D Kinney 
> Cc: Star Zeng 
> 
> Thanks
> Laszlo
> 
> Laszlo Ersek (3):
>   MdePkg, MdeModulePkg: S3BootScriptSaveMemPoll(): accept 64-bit
> LoopTimes
>   MdeModulePkg: S3SaveStateDxe, SmmS3SaveState: save 64-bit
> LoopTimes
>   Vlv2TbltDevicePkg/BootScriptSaveDxe: save 64-bit LoopTimes
> 
>  MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c  | 2 +-
>  MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c| 8
> 
>  MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c | 8
> 
>  MdePkg/Include/Library/S3BootScriptLib.h| 2 +-
>  MdePkg/Library/BaseS3BootScriptLibNull/BootScriptLib.c  | 2 +-
>  Vlv2TbltDevicePkg/BootScriptSaveDxe/ScriptSave.c| 4 ++--
>  6 files changed, 13 insertions(+), 13 deletions(-)
> 
> --
> 2.9.2
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Pipe causes pool failure in Shell.c

[Tim Lewis]

Using the latest Shell build, try:

ls -sfo | parse FileInfo 2

This ends up with a breakpoint when FreePool is called on Shell.c, line 1756.

I'm still debugging, but I wondered if anyone else has seen this?

Also:

ls -sfo > tmp
parse FileInfo 2 < tmp

prints nothing, but

parse tmp FileInfo 2

works fine.

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

Re: [edk2] [patch] MdeModulePkg/SdMmc: Fix build failure caused by last check-in

[Zeng, Star]

Reviewed-by: Star Zeng 

-Original Message-
From: Tian, Feng 
Sent: Thursday, December 1, 2016 4:42 PM
To: edk2-devel@lists.01.org
Cc: Jan Dabros ; Marcin Wojtas ; Zeng, 
Star 
Subject: [patch] MdeModulePkg/SdMmc: Fix build failure caused by last check-in

The commit e27cca has a typo on DEBUG level macro. And this debug message 
should be DEBUG_INFO rather than DEBUG_ERROR.

Cc: Jan Dabros 
Cc: Marcin Wojtas 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Feng Tian 
---
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c 
b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
index 4c1b5c8..23faec5 100644
--- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
+++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
@@ -638,7 +638,7 @@ SdMmcPciHcDriverBindingStart (
 if (EFI_ERROR (Status) && (Status != EFI_MEDIA_CHANGED)) {
   continue;
 } else if (!MediaPresent) {
-  DEBUG ((EFI_ERROR, "SdMmcHcCardDetect: No device attached in 
Slot[%d]!!!\n", Slot));
+  DEBUG ((DEBUG_INFO, "SdMmcHcCardDetect: No device attached in 
+ Slot[%d]!!!\n", Slot));
   continue;
 }
 
--
2.7.1.windows.2

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

[edk2] [shell] Redirection to environment variable used on command-line not working.

[Tim Lewis]

I have a command like this:

X %_key% >v _key

and

X %_key% _key

These two commands should do, essentially the same thing, since the command 'X' 
calls ShellSetEnvironmentVariable() if the 2nd parameter is present.

Any thoughts?

Tim

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

Re: [edk2] [PATCH 3/5] OvmfPkg/IndustryStandard: add QemuFwCfgDma.h

[Jordan Justen]

On 2016-12-01 12:48:51, Laszlo Ersek wrote:
> On 12/01/16 20:34, Jordan Justen wrote:
> > On 2016-12-01 09:56:31, Laszlo Ersek wrote:
> >> Add the type and macro definitions related to QEMU's DMA-like fw_cfg
> >> access method in a dedicated header file.
> >>
> >> Cc: Ard Biesheuvel 
> >> Cc: Jordan Justen 
> >> Contributed-under: TianoCore Contribution Agreement 1.0
> >> Signed-off-by: Laszlo Ersek 
> >> ---
> >>  OvmfPkg/Include/IndustryStandard/QemuFwCfgDma.h | 50 
> > 
> > What do you think about just
> > OvmfPkg/Include/IndustryStandard/QemuFwCfg.h?
> > 
> > Arguably, the FIRMWARE_CONFIG_ITEM enums could be moved there as
> > well...
> > 
> > Then again, I think we could also just put this content into
> > OvmfPkg/Include/Library/QemuFwCfgLib.h.
> 
> Adding this stuff to "OvmfPkg/Include/Library/QemuFwCfgLib.h" sounds
> good to me; I'll do that in v2.
> 

Ok. By the way, I looked over the series, and with that change you can
add Reviewed-by: Jordan Justen 

I'll let you decide if you want to send out a v2.

-Jordan

> 
> > -Jordan
> > 
> >>  1 file changed, 50 insertions(+)
> >>
> >> diff --git a/OvmfPkg/Include/IndustryStandard/QemuFwCfgDma.h 
> >> b/OvmfPkg/Include/IndustryStandard/QemuFwCfgDma.h
> >> new file mode 100644
> >> index ..37a5804adb05
> >> --- /dev/null
> >> +++ b/OvmfPkg/Include/IndustryStandard/QemuFwCfgDma.h
> >> @@ -0,0 +1,50 @@
> >> +/** @file
> >> +  Macro and type definitions related to QEMU's DMA-like fw_cfg access 
> >> method,
> >> +  based on "docs/specs/fw_cfg.txt" in the QEMU tree.
> >> +
> >> +  Copyright (C) 2016, Red Hat, Inc.
> >> +
> >> +  This program and the accompanying materials are licensed and made 
> >> available
> >> +  under the terms and conditions of the BSD License which accompanies this
> >> +  distribution.  The full text of the license may be found at
> >> +  http://opensource.org/licenses/bsd-license.php
> >> +
> >> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
> >> WITHOUT
> >> +  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> >> +**/
> >> +
> >> +
> >> +#ifndef __FW_CFG_DMA__
> >> +#define __FW_CFG_DMA__
> >> +
> >> +#include 
> >> +
> >> +//
> >> +// If the following bit is set in the UINT32 fw_cfg revision / feature 
> >> bitmap
> >> +// -- read from key 0x0001 with the basic IO Port or MMIO method --, then 
> >> the
> >> +// DMA interface is available.
> >> +//
> >> +#define FW_CFG_F_DMA BIT1
> >> +
> >> +//
> >> +// Communication structure for the DMA access method. All fields are 
> >> encoded in
> >> +// big endian.
> >> +//
> >> +#pragma pack (1)
> >> +typedef struct {
> >> +  UINT32 Control;
> >> +  UINT32 Length;
> >> +  UINT64 Address;
> >> +} FW_CFG_DMA_ACCESS;
> >> +#pragma pack ()
> >> +
> >> +//
> >> +// Macros for the FW_CFG_DMA_ACCESS.Control bitmap (in native encoding).
> >> +//
> >> +#define FW_CFG_DMA_CTL_ERROR  BIT0
> >> +#define FW_CFG_DMA_CTL_READ   BIT1
> >> +#define FW_CFG_DMA_CTL_SKIP   BIT2
> >> +#define FW_CFG_DMA_CTL_SELECT BIT3
> >> +#define FW_CFG_DMA_CTL_WRITE  BIT4
> >> +
> >> +#endif
> >> -- 
> >> 2.9.2
> >>
> >>
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5

[Jordan Justen]

On 2016-12-01 12:54:34, Laszlo Ersek wrote:
> On 12/01/16 21:06, Jordan Justen wrote:
> > On 2016-12-01 10:43:24, Laszlo Ersek wrote:
> >> Hrpmf, wait a second, I do see something interesting: in this series you
> >> *are* modifying APIs declared in a library class header (namely
> >> "OvmfPkg/Include/Library/XenHypercallLib.h"). Such functions (public
> >> libraries) *are* required to specify EFIAPI.
> >>
> >> What happens if you apply patch #1 only?
> > 
> > I agree that this should be fixed.
> > 
> > But, if it works, I'm concerned that it would just be hiding a bug. My
> > understanding was that the EFIAPI on libraries was needed so that a
> > library implementation could be assembly based if desired. In this
> > case C is used for the implementation, so the calling conventions
> > should align.
> 
> Never tried the following, so I'm unsure if edk2 intends to support it
> explicitly, but what about binary-only library instances (the 2-clause
> BSDL allows that)?

Good point. Once again, I agree that it is a bug that needs to be
fixed. The functions in the library interface should have EFIAPI.

I was just pointing out that I don't think it *ought* be the issue
here since both side are C, and being built by the same compiler.

Like you mentioned ... maybe it is a compiler bug, or a bug with our
build flags.

-Jordan

> If the library class header doesn't state EFIAPI on the functions, the
> library vendor builds the library instance with Visual Studio, and the
> library user builds the client module with gcc (against the same library
> class header), calls will fail.
> 
> (The way I imagine using binary-only library instances is that the
> library comes as a binary object with a matching INF file, in a separate
> subdirectory, and the user resolves the library class in his/her
> platform DSC to that INF file. Not sure about the exact [section names]
> in the library instance's INF file though.)
> 
> Thanks!
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch v2 0/4] Fix SOURCE_DEBUG_ENABLE

[Michael Kinney]

Changes in V2
=
* Fix build failure when SOURCE_DEBUG_ENABLE is FALSE

Fix SOURCE_DEBUG_ENABLE feature that includes updates to library
mappings, PCD settings, and adding DebugAgent UART Console as one
of the possible console devices in the PlatformBdsLib.

The series also cleans up a few inconsistencies in the DSC files
and updates PlatformPkgGccX64.dsc to match PlatformPkgX64.dsc.

Cc: Jiewen Yao 
Cc: David Wei 
Cc: Mang Guo 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 

Michael Kinney (4):
  Vlv2TbltDevicePkg: Make !if statement usage consistent
  Vlv2TbltDevicePkg: Fix SOURCE_DEBUG_ENABLE feature
  Vlv2TbltDevicePkg/PlatformBdsLib: Add DebugAgent Console
  Vlv2TbltDevicePkg: Update PlatformPkgGccX64.dsc

 .../Library/PlatformBdsLib/BdsPlatform.h   | 13 +++-
 .../Library/PlatformBdsLib/PlatformBdsLib.inf  |  1 +
 .../Library/PlatformBdsLib/PlatformData.c  | 48 +-
 Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc| 77 ++
 Vlv2TbltDevicePkg/PlatformPkgIA32.dsc  | 15 +++--
 Vlv2TbltDevicePkg/PlatformPkgX64.dsc   | 26 
 6 files changed, 119 insertions(+), 61 deletions(-)

-- 
2.6.3.windows.1

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

[edk2] [Patch v2 4/4] Vlv2TbltDevicePkg: Update PlatformPkgGccX64.dsc

[Michael Kinney]

Update PlatformPkgGccX64.dsc to align with PlatformPkgX64.dsc
on library mappings and PCD settings.

Cc: Jiewen Yao 
Cc: David Wei 
Cc: Mang Guo 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 75 +++--
 1 file changed, 35 insertions(+), 40 deletions(-)

diff --git a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
index 5215c56..9c3d4c4 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
@@ -227,8 +227,8 @@
   DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
   SerialPortLib|MdePkg/Library/BaseSerialPortLibNull/BaseSerialPortLibNull.inf
 !else
-  DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
-  SerialPortLib|MdePkg/Library/BaseSerialPortLibNull/BaseSerialPortLibNull.inf
+  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
+  SerialPortLib|$(PLATFORM_PACKAGE)/Library/SerialPortLib/SerialPortLib.inf
 !endif
 
   
PerformanceLib|MdePkg/Library/BasePerformanceLibNull/BasePerformanceLibNull.inf
@@ -332,14 +332,15 @@
   DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
   SerialPortLib|MdePkg/Library/BaseSerialPortLibNull/BaseSerialPortLibNull.inf
 !else
-  DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
-  SerialPortLib|MdePkg/Library/BaseSerialPortLibNull/BaseSerialPortLibNull.inf
+  
DebugLib|IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
+  SerialPortLib|$(PLATFORM_PACKAGE)/Library/SerialPortLib/SerialPortLib.inf
 !endif
 
   LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf
   
HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.inf
-  
PeCoffExtraActionLib|MdePkg/Library/BasePeCoffExtraActionLibNull/BasePeCoffExtraActionLibNull.inf
-  DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
+!if $(SOURCE_DEBUG_ENABLE) == TRUE
+  DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
+!endif
 
  !if $(MINNOW2_FSP_BUILD) == TRUE
  PlatformFspLib|Vlv2TbltDevicePkg/Library/PlatformFspLib/PlatformFspLib.inf
@@ -413,7 +414,7 @@
 
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
   !if $(TARGET) != RELEASE
-  DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
+  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
   !endif
 
 !if $(SOURCE_DEBUG_ENABLE) == TRUE
@@ -436,12 +437,7 @@
   
PerformanceLib|MdePkg/Library/BasePerformanceLibNull/BasePerformanceLibNull.inf
 
 !if $(TARGET) != RELEASE
-  DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
-!endif
-
-!if $(SOURCE_DEBUG_ENABLE) == TRUE
-  DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
-  
TimerLib|$(PLATFORM_PACKAGE)/Library/IntelPchAcpiTimerLib/IntelPchAcpiTimerLib.inf
+  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
 !endif
 
 [LibraryClasses.X64.DXE_RUNTIME_DRIVER]
@@ -616,6 +612,10 @@
 
   gEfiCpuTokenSpaceGuid.PcdCpuSmmBlockStartupThisAp|TRUE
 
+!if $(SOURCE_DEBUG_ENABLE)
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmDebug|TRUE
+!endif
+
 [PcdsFixedAtBuild.common]
 !if $(MINNOW2_FSP_BUILD) == TRUE
 # $(FLASH_REGION_VLVMICROCODE_BASE)
@@ -694,6 +694,7 @@
   gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x17
   gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x07
   gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseHardwareFlowControl|FALSE
+  gEfiSourceLevelDebugPkgTokenSpaceGuid.PcdDebugLoadImageMethod|2
 !endif
 
 [PcdsFixedAtBuild.IA32.PEIM, PcdsFixedAtBuild.IA32.PEI_CORE, 
PcdsFixedAtBuild.IA32.SEC]
@@ -848,16 +849,15 @@
   !if $(TPM_ENABLED) == TRUE
 gEfiSecurityPkgTokenSpaceGuid.PcdTpmInstanceGuid|{0x7b, 0x3a, 0xcd, 0x72, 
0xA5, 0xFE, 0x5e, 0x4f, 0x91, 0x65, 0x4d, 0xd1, 0x21, 0x87, 0xbb, 0x13}
   !endif
-  !if $(FTPM_ENABLE) == TRUE
-gEfiSecurityPkgTokenSpaceGuid.PcdTpmInstanceGuid|{0x7b, 0x3a, 0xcd, 0x72, 
0xA5, 0xFE, 0x5e, 0x4f, 0x91, 0x65, 0x4d, 0xd1, 0x21, 0x87, 0xbb, 0x13}
-  !endif
 
   ## This PCD defines the video horizontal resolution.
   #  This PCD could be set to 0 then video resolution could be at highest 
resolution.
-  gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|0
+  #gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|0
+  gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|800
   ## This PCD defines the video vertical resolution.
   #  This PCD could be set to 0 then video resolution could be at highest 
resolution.
-  gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution|0
+  #gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution|0
+  gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution|600
 
   ## This PCD defines the Console output column and the default value is 25 

[edk2] [Patch v2 3/4] Vlv2TbltDevicePkg/PlatformBdsLib: Add DebugAgent Console

[Michael Kinney]

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

Add the UART console produced by the DebugAgent when
SOURCE_DEBUG_ENABLE is TRUE.  Without this change, the
debugger connects but the Boot Manager and the UEFI
Shell do not have an active console because the Boot
Manager does not know about the DebugAgent UART
Console device path and the Debug Agent is using the
UART device.

Cc: Jiewen Yao 
Cc: David Wei 
Cc: Mang Guo 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 .../Library/PlatformBdsLib/BdsPlatform.h   | 13 +-
 .../Library/PlatformBdsLib/PlatformBdsLib.inf  |  1 +
 .../Library/PlatformBdsLib/PlatformData.c  | 48 +-
 3 files changed, 60 insertions(+), 2 deletions(-)

diff --git a/Vlv2TbltDevicePkg/Library/PlatformBdsLib/BdsPlatform.h 
b/Vlv2TbltDevicePkg/Library/PlatformBdsLib/BdsPlatform.h
index d757243..807094f 100644
--- a/Vlv2TbltDevicePkg/Library/PlatformBdsLib/BdsPlatform.h
+++ b/Vlv2TbltDevicePkg/Library/PlatformBdsLib/BdsPlatform.h
@@ -1,6 +1,6 @@
 /*++
 
-  Copyright (c) 2004  - 2014, Intel Corporation. All rights reserved.
+  Copyright (c) 2004  - 2016, Intel Corporation. All rights reserved.



   This program and the accompanying materials are licensed and made available 
under

   the terms and conditions of the BSD License that accompanies this 
distribution.  

@@ -46,6 +46,7 @@ Abstract:
 #include 
 #include 
 #include 
+#include 
 
 
 #include 
@@ -281,6 +282,16 @@ typedef struct {
 } PLATFORM_USB_DEVICE_PATH;
 
 //
+// Debug Agent UART Console device path definition
+//
+typedef struct {
+  VENDOR_DEVICE_PATHVendorHardware;
+  UART_DEVICE_PATH  Uart;
+  VENDOR_DEVICE_PATHTerminalType;
+  EFI_DEVICE_PATH_PROTOCOL  End;
+} VENDOR_UART_DEVICE_PATH;
+
+//
 // Below is the platform PCI device path
 //
 typedef struct {
diff --git a/Vlv2TbltDevicePkg/Library/PlatformBdsLib/PlatformBdsLib.inf 
b/Vlv2TbltDevicePkg/Library/PlatformBdsLib/PlatformBdsLib.inf
index 3e45a31..7512556 100644
--- a/Vlv2TbltDevicePkg/Library/PlatformBdsLib/PlatformBdsLib.inf
+++ b/Vlv2TbltDevicePkg/Library/PlatformBdsLib/PlatformBdsLib.inf
@@ -50,6 +50,7 @@
   CryptoPkg/CryptoPkg.dec
   SecurityPkg/SecurityPkg.dec
   SignedCapsulePkg/SignedCapsulePkg.dec
+  SourceLevelDebugPkg/SourceLevelDebugPkg.dec
 
 [LibraryClasses]
   DxeServicesTableLib
diff --git a/Vlv2TbltDevicePkg/Library/PlatformBdsLib/PlatformData.c 
b/Vlv2TbltDevicePkg/Library/PlatformBdsLib/PlatformData.c
index 64e68d3..45bd32d 100644
--- a/Vlv2TbltDevicePkg/Library/PlatformBdsLib/PlatformData.c
+++ b/Vlv2TbltDevicePkg/Library/PlatformBdsLib/PlatformData.c
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2004  - 2014, Intel Corporation. All rights reserved.
+  Copyright (c) 2004  - 2016, Intel Corporation. All rights reserved.



   This program and the accompanying materials are licensed and made available 
under

   the terms and conditions of the BSD License that accompanies this 
distribution.  

@@ -119,12 +119,57 @@ USB_CLASS_FORMAT_DEVICE_PATH gUsbClassKeyboardDevicePath 
= {
 };
 
 //
+// Debug Agent UART Console device path 
+//
+VENDOR_UART_DEVICE_PATH gDebugAgentUartDevicePath = {
+  {
+{
+  HARDWARE_DEVICE_PATH,
+  HW_VENDOR_DP,
+  {
+(UINT8) (sizeof (VENDOR_DEVICE_PATH)),
+(UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8)
+  }
+},
+EFI_DEBUG_AGENT_GUID,
+  },
+  {
+{
+  MESSAGING_DEVICE_PATH,
+  MSG_UART_DP,
+  {
+(UINT8) (sizeof (UART_DEVICE_PATH)),
+(UINT8) ((sizeof (UART_DEVICE_PATH)) >> 8)
+  }
+},
+0,  // Reserved
+0,  // BaudRate - Default
+0,  // DataBits - Default
+0,  // Parity   - Default
+0,  // StopBits - Default
+  },
+  {
+{
+  MESSAGING_DEVICE_PATH,
+  MSG_VENDOR_DP,
+  {
+(UINT8)(sizeof (VENDOR_DEVICE_PATH)),
+(UINT8)((sizeof (VENDOR_DEVICE_PATH)) >> 8)
+  }
+},
+DEVICE_PATH_MESSAGING_PC_ANSI
+  },
+  gEndEntire
+};
+
+//
 // Predefined platform default console device path
 //
 BDS_CONSOLE_CONNECT_ENTRY gPlatformConsole [] = {
   {(EFI_DEVICE_PATH_PROTOCOL*), CONSOLE_ALL},
   {(EFI_DEVICE_PATH_PROTOCOL*), CONSOLE_IN},
   {(EFI_DEVICE_PATH_PROTOCOL*), CONSOLE_IN},
+  {(EFI_DEVICE_PATH_PROTOCOL*), CONSOLE_ALL},
   {(EFI_DEVICE_PATH_PROTOCOL*), CONSOLE_IN},
   {NULL, 0}
 };
@@ -242,6 +287,7 @@ BDS_CONSOLE_CONNECT_ENTRY gPlatformSimpleConsole [] = {
   {(EFI_DEVICE_PATH_PROTOCOL*), CONSOLE_OUT},
   {(EFI_DEVICE_PATH_PROTOCOL*), CONSOLE_ALL},
   {(EFI_DEVICE_PATH_PROTOCOL*), CONSOLE_IN},
+  {(EFI_DEVICE_PATH_PROTOCOL*), CONSOLE_ALL},
   {(EFI_DEVICE_PATH_PROTOCOL*), CONSOLE_IN},
   {NULL, 0}
 };
-- 
2.6.3.windows.1

[edk2] [Patch v2 2/4] Vlv2TbltDevicePkg: Fix SOURCE_DEBUG_ENABLE feature

[Michael Kinney]

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

Fix library mapping and PCD settings required to use
the SOURCE_DEBUG_ENABLE feature in PEI, DXE, and SMM.

Cc: Jiewen Yao 
Cc: David Wei 
Cc: Mang Guo 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 Vlv2TbltDevicePkg/PlatformPkgIA32.dsc | 15 ---
 Vlv2TbltDevicePkg/PlatformPkgX64.dsc  | 24 ++--
 2 files changed, 22 insertions(+), 17 deletions(-)

diff --git a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
index 5b5523f..9ec3f3b 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
@@ -338,8 +338,9 @@
 
   LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf
   
HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.inf
-  
PeCoffExtraActionLib|MdePkg/Library/BasePeCoffExtraActionLibNull/BasePeCoffExtraActionLibNull.inf
-  DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
+!if $(SOURCE_DEBUG_ENABLE) == TRUE
+  DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
+!endif
 
  !if $(MINNOW2_FSP_BUILD) == TRUE
  PlatformFspLib|Vlv2TbltDevicePkg/Library/PlatformFspLib/PlatformFspLib.inf
@@ -439,11 +440,6 @@
   DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
 !endif
 
-!if $(SOURCE_DEBUG_ENABLE) == TRUE
-  DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
-  
TimerLib|$(PLATFORM_PACKAGE)/Library/IntelPchAcpiTimerLib/IntelPchAcpiTimerLib.inf
-!endif
-
 [LibraryClasses.IA32.DXE_RUNTIME_DRIVER]
   
ReportStatusCodeLib|MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/RuntimeDxeReportStatusCodeLib.inf
 !if $(SECURE_BOOT_ENABLE) == TRUE
@@ -616,6 +612,10 @@
 
   gEfiCpuTokenSpaceGuid.PcdCpuSmmBlockStartupThisAp|TRUE
 
+!if $(SOURCE_DEBUG_ENABLE)
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmDebug|TRUE
+!endif
+
 [PcdsFixedAtBuild.common]
 !if $(MINNOW2_FSP_BUILD) == TRUE
 # $(FLASH_REGION_VLVMICROCODE_BASE)
@@ -694,6 +694,7 @@
   gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x17
   gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x07
   gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseHardwareFlowControl|FALSE
+  gEfiSourceLevelDebugPkgTokenSpaceGuid.PcdDebugLoadImageMethod|2
 !endif
 
 [PcdsFixedAtBuild.IA32.PEIM, PcdsFixedAtBuild.IA32.PEI_CORE, 
PcdsFixedAtBuild.IA32.SEC]
diff --git a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
index cd9dee0..807860f 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
@@ -338,8 +338,9 @@
 
   LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf
   
HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.inf
-  
PeCoffExtraActionLib|MdePkg/Library/BasePeCoffExtraActionLibNull/BasePeCoffExtraActionLibNull.inf
-  DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
+!if $(SOURCE_DEBUG_ENABLE) == TRUE
+  DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
+!endif
 
  !if $(MINNOW2_FSP_BUILD) == TRUE
  PlatformFspLib|Vlv2TbltDevicePkg/Library/PlatformFspLib/PlatformFspLib.inf
@@ -439,11 +440,6 @@
   DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
 !endif
 
-!if $(SOURCE_DEBUG_ENABLE) == TRUE
-  DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
-  
TimerLib|$(PLATFORM_PACKAGE)/Library/IntelPchAcpiTimerLib/IntelPchAcpiTimerLib.inf
-!endif
-
 [LibraryClasses.X64.DXE_RUNTIME_DRIVER]
   
ReportStatusCodeLib|MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/RuntimeDxeReportStatusCodeLib.inf
 !if $(SECURE_BOOT_ENABLE) == TRUE
@@ -616,6 +612,10 @@
 
   gEfiCpuTokenSpaceGuid.PcdCpuSmmBlockStartupThisAp|TRUE
 
+!if $(SOURCE_DEBUG_ENABLE)
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmDebug|TRUE
+!endif
+
 [PcdsFixedAtBuild.common]
 !if $(MINNOW2_FSP_BUILD) == TRUE
 # $(FLASH_REGION_VLVMICROCODE_BASE)
@@ -694,6 +694,7 @@
   gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x17
   gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x07
   gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseHardwareFlowControl|FALSE
+  gEfiSourceLevelDebugPkgTokenSpaceGuid.PcdDebugLoadImageMethod|2
 !endif
 
 [PcdsFixedAtBuild.IA32.PEIM, PcdsFixedAtBuild.IA32.PEI_CORE, 
PcdsFixedAtBuild.IA32.SEC]
@@ -1152,9 +1153,12 @@ 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/IA32/fTPMInitPeim.inf
 !if $(CAPSULE_ENABLE) == TRUE
   MdeModulePkg/Universal/CapsulePei/CapsuleX64.inf {
 
-PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
-
MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
-HobLib|MdePkg/Library/PeiHobLib/PeiHobLib.inf
+  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
+  

[edk2] [Patch v2 1/4] Vlv2TbltDevicePkg: Make !if statement usage consistent

[Michael Kinney]

Cc: Jiewen Yao 
Cc: David Wei 
Cc: Mang Guo 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---
 Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 2 +-
 Vlv2TbltDevicePkg/PlatformPkgX64.dsc| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
index 6da2a8a..5215c56 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
@@ -457,7 +457,7 @@
   DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
 !endif
 
-!if $(CAPSULE_ENABLE)
+!if $(CAPSULE_ENABLE) == TRUE
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibFmp/DxeRuntimeCapsuleLib.inf
 !endif
 
diff --git a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
index 54d2b81..cd9dee0 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
@@ -457,7 +457,7 @@
   DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
 !endif
 
-!if $(CAPSULE_ENABLE)
+!if $(CAPSULE_ENABLE) == TRUE
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibFmp/DxeRuntimeCapsuleLib.inf
 !endif
 
-- 
2.6.3.windows.1

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

Re: [edk2] [PATCH V2] UefiCpuPkg/PiSmmCpu: Fixed #double fault on #page fault.

[Laszlo Ersek]

On 12/01/16 13:04, Jiewen Yao wrote:
> This patch fixes https://bugzilla.tianocore.org/show_bug.cgi?id=246
> 
> Previously, when SMM exception happens after EndOfDxe,
> with StackGuard enabled on IA32, the #double fault exception
> is reported instead of #page fault.
> 
> Root cause is below:
> 
> Current EDKII SMM page protection will lock GDT.
> If IA32 stack guard is enabled, the page fault handler will do task switch.
> This task switch need write busy flag in GDT, and write TSS.
> 
> However, the GDT and TSS is locked at that time, so the
> double fault happens.
> 
> We decide to not lock GDT for IA32 StackGuard enabled.
> 
> This issue does not exist on X64, or IA32 without StackGuard.
> 
> Cc: Laszlo Ersek 
> Cc: Jeff Fan 
> Cc: Michael D Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiewen Yao 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmFuncsArch.c  | 55 
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 68 
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c | 48 --
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c   | 49 +-
>  4 files changed, 171 insertions(+), 49 deletions(-)

Regression-tested-by: Laszlo Ersek 

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

Re: [edk2] [PATCH] MdeModulePkg/PiSmmCore: AllocatePool should use MemoryType.

[Laszlo Ersek]

On 12/01/16 09:23, Jiewen Yao wrote:
> PiSmmCore supports page level protection based upon the Memory Type
> (EfiRuntimeServicesCode/EfiRuntimeServicesData) and PE image.
> 
> However, the Memory Type information is ignored in AllocatePool().
> If a caller calls AllocatePool with EfiRuntimeServicesCode,
> the final memory is still allocated as EfiRuntimeServicesData.
> 
> This patch supports AllocatePool with EfiRuntimeServicesCode.
> 
> Cc: Jeff Fan 
> Cc: Michael D Kinney 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiewen Yao 
> ---
>  MdeModulePkg/Core/PiSmmCore/PiSmmCore.h  |  13 ++-
>  MdeModulePkg/Core/PiSmmCore/Pool.c   |  66 +---
>  MdeModulePkg/Core/PiSmmCore/SmramProfileRecord.c | 114 +++-
>  3 files changed, 124 insertions(+), 69 deletions(-)

series
Regression-tested-by: Laszlo Ersek 

(Please make sure to number the patches in the series next time.)

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

Re: [edk2] [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5

[Laszlo Ersek]

On 12/01/16 21:06, Jordan Justen wrote:
> On 2016-12-01 10:43:24, Laszlo Ersek wrote:
>> On 12/01/16 16:28, Anthony PERARD wrote:
>>> Hi,
>>>
>>> That might be only with the Xen part of OVMF but now that the GCC5
>>> toolchains is used with my gcc (6.2.1 20160830, Arch Linux), OVMF fail
>>> to boot in Xen guests.
>>>
>>> Here is the result:
>>>  X64 Exception Type - 06(#UD - Invalid Opcode)  CPU Apic ID -  
>>> 
>>> RIP  - 1F26AF6B, CS  - 0038, RFLAGS - 00010202
>>> RAX  - 0001, RCX - 1F26AF51, RDX - 0004
>>> RBX  - , RSP - 1F43C510, RBP - 1E583D18
>>> RSI  - 0003, RDI - 0001
>>> R8   - , R9  - , R10 - 1E58DB98
>>> R11  - 0002, R12 - 1E58D898, R13 - 
>>> R14  - 1E58D8A0, R15 - 1F26D001
>>> DS   - 0030, ES  - 0030, FS  - 0030
>>> GS   - 0030, SS  - 0030
>>> CR0  - 8033, CR2 - , CR3 - 1F3DB000
>>> CR4  - 0668, CR8 - 
>>> DR0  - , DR1 - , DR2 - 
>>> DR3  - , DR6 - 0FF0, DR7 - 0400
>>> GDTR - 1F3C9A98 0047, LDTR - 
>>> IDTR - 1EB0A018 0FFF,   TR - 
>>> FXSAVE_STATE - 1F43C170
>>>  Find PE image 
>>> ./Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/XenBusDxe/XenBusDxe/DEBUG/XenBusDxe.dll
>>>  (ImageBase=1F266000, EntryPoint=1F2669D5) 
>>>
>>> Removing the gcc option -flto in only the XenBusDxe module makes OVMF
>>> boot.
>>>
>>> While trying to debug that, I've added some debug prints (in this module
>>> and in XenPvBlkDxe), and the exception could change and become a "page
>>> fault" instead, or even an assert failure in the PrintLib, that was the
>>> ASSERT(Buffer != NULL) at I think
>>> MdePkg/Library/BasePrintLib/PrintLibInternal.c:366
>>>
>>> Adding EFIAPI to internal functions in XenBusDxe makes things work
>>> again.  My guest is that gcc would bypass (optimise) an exported
>>> functions and call directly an internal one but without reordering the
>>> arguments (EFIAPI vs nothing).
>>>
>>> Does that make sense?
>>
>> Thank you for the investigation. It is strange that only the Xen modules
>> are affected, I'm unsure what that's the case.
>>
>> Either way, it seems to be a gcc-6 bug, or an edk2 toolchain bug. You
>> should *not* need EFIAPI for functions with external linkage if the
>> calls to them straddle only files in the same module. I'm suspecting
>> gcc-6 (we've received no such reports with gcc-5). Maybe we need a GCC6
>> toolchain as well, for turning off some new features in gcc-6?
>>
>> Jordan, Liming, Yonghong, Ard -- any ideas?
>>
>> Anthony: while we all figure this out, please consider building OVMF
>> with the "-b NOOPT" switch. Support for the NOOPT build target has
>> recently been added to the GCC Ia32/X64 toolchains in BaseTools, and to
>> the OVMF DSC files as well. The build targets correspond to:
>>
>> RELEASE -- compiler optimization enabled; DEBUG, ASSERT, and similar
>>DebugLib features compiled out
>> DEBUG   -- compiler optimization enabled; DebugLib features preserved
>> NOOPT   -- compiler optimization disabled; DebugLib features preserved
>>
>> (Note that for ArmVirtPkg and the GCC AARCH64 toolchains in BaseTools,
>> there is no NOOPT, and DEBUG means actually NOOPT -- if I remember
>> correctly. Ard will correct me if I'm wrong :))
>>
>> If "-b NOOPT" works for you, I'd prefer that as a temporary solution
>> (until the root cause is found and addressed) to the XenBusDxe patches.
>>
>> Hrpmf, wait a second, I do see something interesting: in this series you
>> *are* modifying APIs declared in a library class header (namely
>> "OvmfPkg/Include/Library/XenHypercallLib.h"). Such functions (public
>> libraries) *are* required to specify EFIAPI.
>>
>> What happens if you apply patch #1 only?
> 
> I agree that this should be fixed.
> 
> But, if it works, I'm concerned that it would just be hiding a bug. My
> understanding was that the EFIAPI on libraries was needed so that a
> library implementation could be assembly based if desired. In this
> case C is used for the implementation, so the calling conventions
> should align.

Never tried the following, so I'm unsure if edk2 intends to support it
explicitly, but what about binary-only library instances (the 2-clause
BSDL allows that)?

If the library class header doesn't state EFIAPI on the functions, the
library vendor builds the library instance with Visual Studio, and the
library user builds the client module with gcc (against the same library
class header), calls will fail.

(The way I imagine using binary-only library instances is that the
library comes as a binary object with a matching INF 

Re: [edk2] [PATCH 3/5] OvmfPkg/IndustryStandard: add QemuFwCfgDma.h

[Laszlo Ersek]

On 12/01/16 20:34, Jordan Justen wrote:
> On 2016-12-01 09:56:31, Laszlo Ersek wrote:
>> Add the type and macro definitions related to QEMU's DMA-like fw_cfg
>> access method in a dedicated header file.
>>
>> Cc: Ard Biesheuvel 
>> Cc: Jordan Justen 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek 
>> ---
>>  OvmfPkg/Include/IndustryStandard/QemuFwCfgDma.h | 50 
> 
> What do you think about just
> OvmfPkg/Include/IndustryStandard/QemuFwCfg.h?
> 
> Arguably, the FIRMWARE_CONFIG_ITEM enums could be moved there as
> well...
> 
> Then again, I think we could also just put this content into
> OvmfPkg/Include/Library/QemuFwCfgLib.h.

Adding this stuff to "OvmfPkg/Include/Library/QemuFwCfgLib.h" sounds
good to me; I'll do that in v2.

Thanks!
Laszlo

> -Jordan
> 
>>  1 file changed, 50 insertions(+)
>>
>> diff --git a/OvmfPkg/Include/IndustryStandard/QemuFwCfgDma.h 
>> b/OvmfPkg/Include/IndustryStandard/QemuFwCfgDma.h
>> new file mode 100644
>> index ..37a5804adb05
>> --- /dev/null
>> +++ b/OvmfPkg/Include/IndustryStandard/QemuFwCfgDma.h
>> @@ -0,0 +1,50 @@
>> +/** @file
>> +  Macro and type definitions related to QEMU's DMA-like fw_cfg access 
>> method,
>> +  based on "docs/specs/fw_cfg.txt" in the QEMU tree.
>> +
>> +  Copyright (C) 2016, Red Hat, Inc.
>> +
>> +  This program and the accompanying materials are licensed and made 
>> available
>> +  under the terms and conditions of the BSD License which accompanies this
>> +  distribution.  The full text of the license may be found at
>> +  http://opensource.org/licenses/bsd-license.php
>> +
>> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
>> WITHOUT
>> +  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
>> +**/
>> +
>> +
>> +#ifndef __FW_CFG_DMA__
>> +#define __FW_CFG_DMA__
>> +
>> +#include 
>> +
>> +//
>> +// If the following bit is set in the UINT32 fw_cfg revision / feature 
>> bitmap
>> +// -- read from key 0x0001 with the basic IO Port or MMIO method --, then 
>> the
>> +// DMA interface is available.
>> +//
>> +#define FW_CFG_F_DMA BIT1
>> +
>> +//
>> +// Communication structure for the DMA access method. All fields are 
>> encoded in
>> +// big endian.
>> +//
>> +#pragma pack (1)
>> +typedef struct {
>> +  UINT32 Control;
>> +  UINT32 Length;
>> +  UINT64 Address;
>> +} FW_CFG_DMA_ACCESS;
>> +#pragma pack ()
>> +
>> +//
>> +// Macros for the FW_CFG_DMA_ACCESS.Control bitmap (in native encoding).
>> +//
>> +#define FW_CFG_DMA_CTL_ERROR  BIT0
>> +#define FW_CFG_DMA_CTL_READ   BIT1
>> +#define FW_CFG_DMA_CTL_SKIP   BIT2
>> +#define FW_CFG_DMA_CTL_SELECT BIT3
>> +#define FW_CFG_DMA_CTL_WRITE  BIT4
>> +
>> +#endif
>> -- 
>> 2.9.2
>>
>>

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

Re: [edk2] [PATCH v2 4/4] OvmfPkg/SmmControl2Dxe: select broadcast SMI if available

[Laszlo Ersek]

On 11/23/16 16:44, Laszlo Ersek wrote:
> On 11/23/16 04:44, Jordan Justen wrote:

>> Series Reviewed-by: Jordan Justen 
> 
> Thank you!
> 
> I'll delay pushing the patches until Michael Tsirkin reviews the
> interface spec in the QEMU series on qemu-devel.

This version of the series can be dropped. The underlying QEMU patches
weren't accepted, and for QEMU I've posted another patch set today:

http://lists.nongnu.org/archive/html/qemu-devel/2016-12/msg00129.html

For this I have the corresponding OVMF patches ready (of course), but
until the QEMU work converges, there's little point in posting them.

I did post some of the prerequisite edk2 / OVMF patches today (which are
useful independently, and can be reviewed independently).

Thanks, and apologies for the review-in-vain. :/
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5

[Jordan Justen]

On 2016-12-01 10:43:24, Laszlo Ersek wrote:
> On 12/01/16 16:28, Anthony PERARD wrote:
> > Hi,
> > 
> > That might be only with the Xen part of OVMF but now that the GCC5
> > toolchains is used with my gcc (6.2.1 20160830, Arch Linux), OVMF fail
> > to boot in Xen guests.
> > 
> > Here is the result:
> >  X64 Exception Type - 06(#UD - Invalid Opcode)  CPU Apic ID -  
> > 
> > RIP  - 1F26AF6B, CS  - 0038, RFLAGS - 00010202
> > RAX  - 0001, RCX - 1F26AF51, RDX - 0004
> > RBX  - , RSP - 1F43C510, RBP - 1E583D18
> > RSI  - 0003, RDI - 0001
> > R8   - , R9  - , R10 - 1E58DB98
> > R11  - 0002, R12 - 1E58D898, R13 - 
> > R14  - 1E58D8A0, R15 - 1F26D001
> > DS   - 0030, ES  - 0030, FS  - 0030
> > GS   - 0030, SS  - 0030
> > CR0  - 8033, CR2 - , CR3 - 1F3DB000
> > CR4  - 0668, CR8 - 
> > DR0  - , DR1 - , DR2 - 
> > DR3  - , DR6 - 0FF0, DR7 - 0400
> > GDTR - 1F3C9A98 0047, LDTR - 
> > IDTR - 1EB0A018 0FFF,   TR - 
> > FXSAVE_STATE - 1F43C170
> >  Find PE image 
> > ./Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/XenBusDxe/XenBusDxe/DEBUG/XenBusDxe.dll
> >  (ImageBase=1F266000, EntryPoint=1F2669D5) 
> > 
> > Removing the gcc option -flto in only the XenBusDxe module makes OVMF
> > boot.
> > 
> > While trying to debug that, I've added some debug prints (in this module
> > and in XenPvBlkDxe), and the exception could change and become a "page
> > fault" instead, or even an assert failure in the PrintLib, that was the
> > ASSERT(Buffer != NULL) at I think
> > MdePkg/Library/BasePrintLib/PrintLibInternal.c:366
> > 
> > Adding EFIAPI to internal functions in XenBusDxe makes things work
> > again.  My guest is that gcc would bypass (optimise) an exported
> > functions and call directly an internal one but without reordering the
> > arguments (EFIAPI vs nothing).
> > 
> > Does that make sense?
> 
> Thank you for the investigation. It is strange that only the Xen modules
> are affected, I'm unsure what that's the case.
> 
> Either way, it seems to be a gcc-6 bug, or an edk2 toolchain bug. You
> should *not* need EFIAPI for functions with external linkage if the
> calls to them straddle only files in the same module. I'm suspecting
> gcc-6 (we've received no such reports with gcc-5). Maybe we need a GCC6
> toolchain as well, for turning off some new features in gcc-6?
> 
> Jordan, Liming, Yonghong, Ard -- any ideas?
> 
> Anthony: while we all figure this out, please consider building OVMF
> with the "-b NOOPT" switch. Support for the NOOPT build target has
> recently been added to the GCC Ia32/X64 toolchains in BaseTools, and to
> the OVMF DSC files as well. The build targets correspond to:
> 
> RELEASE -- compiler optimization enabled; DEBUG, ASSERT, and similar
>DebugLib features compiled out
> DEBUG   -- compiler optimization enabled; DebugLib features preserved
> NOOPT   -- compiler optimization disabled; DebugLib features preserved
> 
> (Note that for ArmVirtPkg and the GCC AARCH64 toolchains in BaseTools,
> there is no NOOPT, and DEBUG means actually NOOPT -- if I remember
> correctly. Ard will correct me if I'm wrong :))
> 
> If "-b NOOPT" works for you, I'd prefer that as a temporary solution
> (until the root cause is found and addressed) to the XenBusDxe patches.
> 
> Hrpmf, wait a second, I do see something interesting: in this series you
> *are* modifying APIs declared in a library class header (namely
> "OvmfPkg/Include/Library/XenHypercallLib.h"). Such functions (public
> libraries) *are* required to specify EFIAPI.
> 
> What happens if you apply patch #1 only?

I agree that this should be fixed.

But, if it works, I'm concerned that it would just be hiding a bug. My
understanding was that the EFIAPI on libraries was needed so that a
library implementation could be assembly based if desired. In this
case C is used for the implementation, so the calling conventions
should align.

-Jordan

> 
> > Anthony PERARD (4):
> >   OvmfPkg/XenHypercallLib: Add EFIAPI
> >   OvmfPkg/XenBusDxe: Add EFIAPI to XenEventChannelNotify
> >   OvmfPkg/XenBusDxe: Add EFIAPI to XenStore functions
> >   OvmfPkg/XenBusDxe: Add EFIAPI to XenGrantTable{Grant,End}Access
> > 
> >  OvmfPkg/Include/Library/XenHypercallLib.h  |  3 +++
> >  OvmfPkg/Library/XenHypercallLib/XenHypercall.c |  3 +++
> >  OvmfPkg/XenBusDxe/EventChannel.c   |  1 +
> >  OvmfPkg/XenBusDxe/EventChannel.h   |  1 +
> >  OvmfPkg/XenBusDxe/GrantTable.c |  2 ++
> >  OvmfPkg/XenBusDxe/XenStore.c   

Re: [edk2] [PATCH 0/7] Various: Remove EDK2 use of IntelFrameworkModulePkg legacy libs

[Jordan Justen]

For the future, I'd recommend adding Cc's for package owners to the
associated patch commit message.

Series Reviewed-by: Jordan Justen 

On 2016-12-01 07:53:19, Leif Lindholm wrote:
> LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
> from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
> kept for compatibility.
> 
> Nevertheless, new code should be using the MdeModulePkg versions, so
> change all references in in-tree platforms.
> 
> Since the patches are individually independent, I plan to push them
> myself as Reviewed-by:s appear. Laszlo/Mike - Are you OK with me pusing
> 1 and 2 myself before the whole series is reviewed?
> 
> Changes from RFC:
> - Broken down into per-package patches.
> - Received Reviewed-by:s added.
> 
> Leif Lindholm (7):
>   OvmfPkg: Remove use of IntelFrameworkModulePkg legacy libs
>   QuarkSocPkg: Remove use of IntelFrameworkModulePkg legacy libs
>   BeagleBoardPkg: Remove use of IntelFrameworkModulePkg legacy libs
>   EmbeddedPkg: Remove use of IntelFrameworkModulePkg legacy libs
>   DuetPkg: Remove use of IntelFrameworkModulePkg legacy libs
>   EmulatorPkg: Remove use of IntelFrameworkModulePkg legacy libs
>   Vlv2TbltDevicePkg: Remove use of IntelFrameworkModulePkg legacy libs
> 
>  BeagleBoardPkg/BeagleBoardPkg.dsc   | 4 ++--
>  DuetPkg/DuetPkgIa32.dsc | 4 ++--
>  DuetPkg/DuetPkgX64.dsc  | 4 ++--
>  EmbeddedPkg/EmbeddedPkg.dsc | 2 +-
>  EmulatorPkg/EmulatorPkg.dsc | 4 ++--
>  OvmfPkg/OvmfPkgIa32.dsc | 4 ++--
>  OvmfPkg/OvmfPkgIa32X64.dsc  | 4 ++--
>  OvmfPkg/OvmfPkgX64.dsc  | 4 ++--
>  QuarkSocPkg/QuarkSocPkg.dsc | 2 +-
>  Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 4 ++--
>  Vlv2TbltDevicePkg/PlatformPkgIA32.dsc   | 6 +++---
>  Vlv2TbltDevicePkg/PlatformPkgX64.dsc| 6 +++---
>  12 files changed, 24 insertions(+), 24 deletions(-)
> 
> -- 
> 2.10.2
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/5] OvmfPkg/IndustryStandard: add QemuFwCfgDma.h

[Jordan Justen]

On 2016-12-01 09:56:31, Laszlo Ersek wrote:
> Add the type and macro definitions related to QEMU's DMA-like fw_cfg
> access method in a dedicated header file.
> 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
>  OvmfPkg/Include/IndustryStandard/QemuFwCfgDma.h | 50 

What do you think about just
OvmfPkg/Include/IndustryStandard/QemuFwCfg.h?

Arguably, the FIRMWARE_CONFIG_ITEM enums could be moved there as
well...

Then again, I think we could also just put this content into
OvmfPkg/Include/Library/QemuFwCfgLib.h.

-Jordan

>  1 file changed, 50 insertions(+)
> 
> diff --git a/OvmfPkg/Include/IndustryStandard/QemuFwCfgDma.h 
> b/OvmfPkg/Include/IndustryStandard/QemuFwCfgDma.h
> new file mode 100644
> index ..37a5804adb05
> --- /dev/null
> +++ b/OvmfPkg/Include/IndustryStandard/QemuFwCfgDma.h
> @@ -0,0 +1,50 @@
> +/** @file
> +  Macro and type definitions related to QEMU's DMA-like fw_cfg access method,
> +  based on "docs/specs/fw_cfg.txt" in the QEMU tree.
> +
> +  Copyright (C) 2016, Red Hat, Inc.
> +
> +  This program and the accompanying materials are licensed and made available
> +  under the terms and conditions of the BSD License which accompanies this
> +  distribution.  The full text of the license may be found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
> WITHOUT
> +  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +**/
> +
> +
> +#ifndef __FW_CFG_DMA__
> +#define __FW_CFG_DMA__
> +
> +#include 
> +
> +//
> +// If the following bit is set in the UINT32 fw_cfg revision / feature bitmap
> +// -- read from key 0x0001 with the basic IO Port or MMIO method --, then the
> +// DMA interface is available.
> +//
> +#define FW_CFG_F_DMA BIT1
> +
> +//
> +// Communication structure for the DMA access method. All fields are encoded 
> in
> +// big endian.
> +//
> +#pragma pack (1)
> +typedef struct {
> +  UINT32 Control;
> +  UINT32 Length;
> +  UINT64 Address;
> +} FW_CFG_DMA_ACCESS;
> +#pragma pack ()
> +
> +//
> +// Macros for the FW_CFG_DMA_ACCESS.Control bitmap (in native encoding).
> +//
> +#define FW_CFG_DMA_CTL_ERROR  BIT0
> +#define FW_CFG_DMA_CTL_READ   BIT1
> +#define FW_CFG_DMA_CTL_SKIP   BIT2
> +#define FW_CFG_DMA_CTL_SELECT BIT3
> +#define FW_CFG_DMA_CTL_WRITE  BIT4
> +
> +#endif
> -- 
> 2.9.2
> 
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5

[Laszlo Ersek]

On 12/01/16 16:28, Anthony PERARD wrote:
> Hi,
> 
> That might be only with the Xen part of OVMF but now that the GCC5
> toolchains is used with my gcc (6.2.1 20160830, Arch Linux), OVMF fail
> to boot in Xen guests.
> 
> Here is the result:
>  X64 Exception Type - 06(#UD - Invalid Opcode)  CPU Apic ID -  
> 
> RIP  - 1F26AF6B, CS  - 0038, RFLAGS - 00010202
> RAX  - 0001, RCX - 1F26AF51, RDX - 0004
> RBX  - , RSP - 1F43C510, RBP - 1E583D18
> RSI  - 0003, RDI - 0001
> R8   - , R9  - , R10 - 1E58DB98
> R11  - 0002, R12 - 1E58D898, R13 - 
> R14  - 1E58D8A0, R15 - 1F26D001
> DS   - 0030, ES  - 0030, FS  - 0030
> GS   - 0030, SS  - 0030
> CR0  - 8033, CR2 - , CR3 - 1F3DB000
> CR4  - 0668, CR8 - 
> DR0  - , DR1 - , DR2 - 
> DR3  - , DR6 - 0FF0, DR7 - 0400
> GDTR - 1F3C9A98 0047, LDTR - 
> IDTR - 1EB0A018 0FFF,   TR - 
> FXSAVE_STATE - 1F43C170
>  Find PE image 
> ./Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/XenBusDxe/XenBusDxe/DEBUG/XenBusDxe.dll
>  (ImageBase=1F266000, EntryPoint=1F2669D5) 
> 
> Removing the gcc option -flto in only the XenBusDxe module makes OVMF
> boot.
> 
> While trying to debug that, I've added some debug prints (in this module
> and in XenPvBlkDxe), and the exception could change and become a "page
> fault" instead, or even an assert failure in the PrintLib, that was the
> ASSERT(Buffer != NULL) at I think
> MdePkg/Library/BasePrintLib/PrintLibInternal.c:366
> 
> Adding EFIAPI to internal functions in XenBusDxe makes things work
> again.  My guest is that gcc would bypass (optimise) an exported
> functions and call directly an internal one but without reordering the
> arguments (EFIAPI vs nothing).
> 
> Does that make sense?

Thank you for the investigation. It is strange that only the Xen modules
are affected, I'm unsure what that's the case.

Either way, it seems to be a gcc-6 bug, or an edk2 toolchain bug. You
should *not* need EFIAPI for functions with external linkage if the
calls to them straddle only files in the same module. I'm suspecting
gcc-6 (we've received no such reports with gcc-5). Maybe we need a GCC6
toolchain as well, for turning off some new features in gcc-6?

Jordan, Liming, Yonghong, Ard -- any ideas?

Anthony: while we all figure this out, please consider building OVMF
with the "-b NOOPT" switch. Support for the NOOPT build target has
recently been added to the GCC Ia32/X64 toolchains in BaseTools, and to
the OVMF DSC files as well. The build targets correspond to:

RELEASE -- compiler optimization enabled; DEBUG, ASSERT, and similar
   DebugLib features compiled out
DEBUG   -- compiler optimization enabled; DebugLib features preserved
NOOPT   -- compiler optimization disabled; DebugLib features preserved

(Note that for ArmVirtPkg and the GCC AARCH64 toolchains in BaseTools,
there is no NOOPT, and DEBUG means actually NOOPT -- if I remember
correctly. Ard will correct me if I'm wrong :))

If "-b NOOPT" works for you, I'd prefer that as a temporary solution
(until the root cause is found and addressed) to the XenBusDxe patches.

Hrpmf, wait a second, I do see something interesting: in this series you
*are* modifying APIs declared in a library class header (namely
"OvmfPkg/Include/Library/XenHypercallLib.h"). Such functions (public
libraries) *are* required to specify EFIAPI.

What happens if you apply patch #1 only?

Thanks!
Laszlo

> Anthony PERARD (4):
>   OvmfPkg/XenHypercallLib: Add EFIAPI
>   OvmfPkg/XenBusDxe: Add EFIAPI to XenEventChannelNotify
>   OvmfPkg/XenBusDxe: Add EFIAPI to XenStore functions
>   OvmfPkg/XenBusDxe: Add EFIAPI to XenGrantTable{Grant,End}Access
> 
>  OvmfPkg/Include/Library/XenHypercallLib.h  |  3 +++
>  OvmfPkg/Library/XenHypercallLib/XenHypercall.c |  3 +++
>  OvmfPkg/XenBusDxe/EventChannel.c   |  1 +
>  OvmfPkg/XenBusDxe/EventChannel.h   |  1 +
>  OvmfPkg/XenBusDxe/GrantTable.c |  2 ++
>  OvmfPkg/XenBusDxe/XenStore.c   | 13 +
>  OvmfPkg/XenBusDxe/XenStore.h   | 10 ++
>  7 files changed, 33 insertions(+)
> 

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

Re: [edk2] [PATCH 1/7] OvmfPkg: Remove use of IntelFrameworkModulePkg legacy libs

[Laszlo Ersek]

On 12/01/16 16:53, Leif Lindholm wrote:
> LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
> from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
> kept for compatibility.
> 
> Since the libraries are identical, move OvmfPkg to use the MdeModulePkg
> versions instead.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Leif Lindholm 
> Reviewed-by: Laszlo Ersek 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc| 4 ++--
>  OvmfPkg/OvmfPkgIa32X64.dsc | 4 ++--
>  OvmfPkg/OvmfPkgX64.dsc | 4 ++--
>  3 files changed, 6 insertions(+), 6 deletions(-)

Since you can push, I'll let you. :)

Thanks
Laszlo

> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index d913030..81f7521 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -505,7 +505,7 @@
>#
>OvmfPkg/Sec/SecMain.inf {
>  
> -  
> NULL|IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
> +  
> NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
>}
>  
>#
> @@ -550,7 +550,7 @@
>#
>MdeModulePkg/Core/Dxe/DxeMain.inf {
>  
> -  
> NULL|IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
> +  
> NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
>DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
>}
>  
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 8143ea9..f7855b6 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -513,7 +513,7 @@
>#
>OvmfPkg/Sec/SecMain.inf {
>  
> -  
> NULL|IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
> +  
> NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
>}
>  
>#
> @@ -559,7 +559,7 @@
>#
>MdeModulePkg/Core/Dxe/DxeMain.inf {
>  
> -  
> NULL|IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
> +  
> NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
>DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
>}
>  
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index d48d603..e933a41 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -512,7 +512,7 @@
>#
>OvmfPkg/Sec/SecMain.inf {
>  
> -  
> NULL|IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
> +  
> NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
>}
>  
>#
> @@ -557,7 +557,7 @@
>#
>MdeModulePkg/Core/Dxe/DxeMain.inf {
>  
> -  
> NULL|IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
> +  
> NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
>DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
>}
>  
> 

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

Re: [edk2] [PATCH 0/7] Various: Remove EDK2 use of IntelFrameworkModulePkg legacy libs

[Kinney, Michael D]

Leif,

Yes.  You can push QuarkSocPkg patch based on my previous rb.

Thanks,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leif
> Lindholm
> Sent: Thursday, December 1, 2016 7:53 AM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Ard Biesheuvel 
> ;
> Justen, Jordan L ; Andrew Fish ;
> Kinney, Michael D ; Laszlo Ersek 
> ;
> Wei, David 
> Subject: [edk2] [PATCH 0/7] Various: Remove EDK2 use of 
> IntelFrameworkModulePkg
> legacy libs
> 
> LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
> from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
> kept for compatibility.
> 
> Nevertheless, new code should be using the MdeModulePkg versions, so
> change all references in in-tree platforms.
> 
> Since the patches are individually independent, I plan to push them
> myself as Reviewed-by:s appear. Laszlo/Mike - Are you OK with me pusing
> 1 and 2 myself before the whole series is reviewed?
> 
> Changes from RFC:
> - Broken down into per-package patches.
> - Received Reviewed-by:s added.
> 
> Leif Lindholm (7):
>   OvmfPkg: Remove use of IntelFrameworkModulePkg legacy libs
>   QuarkSocPkg: Remove use of IntelFrameworkModulePkg legacy libs
>   BeagleBoardPkg: Remove use of IntelFrameworkModulePkg legacy libs
>   EmbeddedPkg: Remove use of IntelFrameworkModulePkg legacy libs
>   DuetPkg: Remove use of IntelFrameworkModulePkg legacy libs
>   EmulatorPkg: Remove use of IntelFrameworkModulePkg legacy libs
>   Vlv2TbltDevicePkg: Remove use of IntelFrameworkModulePkg legacy libs
> 
>  BeagleBoardPkg/BeagleBoardPkg.dsc   | 4 ++--
>  DuetPkg/DuetPkgIa32.dsc | 4 ++--
>  DuetPkg/DuetPkgX64.dsc  | 4 ++--
>  EmbeddedPkg/EmbeddedPkg.dsc | 2 +-
>  EmulatorPkg/EmulatorPkg.dsc | 4 ++--
>  OvmfPkg/OvmfPkgIa32.dsc | 4 ++--
>  OvmfPkg/OvmfPkgIa32X64.dsc  | 4 ++--
>  OvmfPkg/OvmfPkgX64.dsc  | 4 ++--
>  QuarkSocPkg/QuarkSocPkg.dsc | 2 +-
>  Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 4 ++--
>  Vlv2TbltDevicePkg/PlatformPkgIA32.dsc   | 6 +++---
>  Vlv2TbltDevicePkg/PlatformPkgX64.dsc| 6 +++---
>  12 files changed, 24 insertions(+), 24 deletions(-)
> 
> --
> 2.10.2
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 4/5] ArmVirtPkg/QemuFwCfgLib: rebase lib instance to OvmfPkg/IndustryStandard

[Laszlo Ersek]

where "QemuFwCfgDma.h" was added in the previous patch.

Cc: Ard Biesheuvel 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c | 24 +++-
 1 file changed, 3 insertions(+), 21 deletions(-)

diff --git a/ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c 
b/ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
index 2fd8d9050566..62a85dff328e 100644
--- a/ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
+++ b/ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
@@ -25,6 +25,8 @@
 
 #include 
 
+#include 
+
 STATIC UINTN mFwCfgSelectorAddress;
 STATIC UINTN mFwCfgDataAddress;
 STATIC UINTN mFwCfgDmaAddress;
@@ -53,26 +55,6 @@ STATIC READ_BYTES_FUNCTION DmaReadBytes;
 //
 STATIC READ_BYTES_FUNCTION *InternalQemuFwCfgReadBytes = MmioReadBytes;
 
-//
-// Communication structure for DmaReadBytes(). All fields are encoded in big
-// endian.
-//
-#pragma pack (1)
-typedef struct {
-  UINT32 Control;
-  UINT32 Length;
-  UINT64 Address;
-} FW_CFG_DMA_ACCESS;
-#pragma pack ()
-
-//
-// Macros for the FW_CFG_DMA_ACCESS.Control bitmap (in native encoding).
-//
-#define FW_CFG_DMA_CTL_ERROR  BIT0
-#define FW_CFG_DMA_CTL_READ   BIT1
-#define FW_CFG_DMA_CTL_SKIP   BIT2
-#define FW_CFG_DMA_CTL_SELECT BIT3
-
 
 /**
   Returns a boolean indicating if the firmware configuration interface
@@ -183,7 +165,7 @@ QemuFwCfgInitialize (
 
 QemuFwCfgSelectItem (QemuFwCfgItemInterfaceVersion);
 Features = QemuFwCfgRead32 ();
-if ((Features & BIT1) != 0) {
+if ((Features & FW_CFG_F_DMA) != 0) {
   mFwCfgDmaAddress = FwCfgDmaAddress;
   InternalQemuFwCfgReadBytes = DmaReadBytes;
 }
-- 
2.9.2


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

[edk2] [PATCH 1/5] ArmVirtPkg/QemuFwCfgLib: remove superfluous InternalQemuFwCfgIsAvailable()

[Laszlo Ersek]

InternalQemuFwCfgIsAvailable() is an API that is incorrectly exposed by
the "OvmfPkg/Include/Library/QemuFwCfgLib.h" library class header; the API
is meant to be used internally to library instances (if it's needed at
all). ArmVirtPkg's instance has no use for it actually, so simplify the
code and remove the function definition.

Cc: Ard Biesheuvel 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c | 31 
 1 file changed, 6 insertions(+), 25 deletions(-)

diff --git a/ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c 
b/ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
index 8ecbe3fb5fe6..2fd8d9050566 100644
--- a/ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
+++ b/ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
@@ -75,25 +75,6 @@ typedef struct {
 
 
 /**
-  Returns a boolean indicating if the firmware configuration interface is
-  available for library-internal purposes.
-
-  This function never changes fw_cfg state.
-
-  @retval TRUE   The interface is available internally.
-  @retval FALSE  The interface is not available internally.
-**/
-BOOLEAN
-EFIAPI
-InternalQemuFwCfgIsAvailable (
-  VOID
-  )
-{
-  return (BOOLEAN)(mFwCfgSelectorAddress != 0 && mFwCfgDataAddress != 0);
-}
-
-
-/**
   Returns a boolean indicating if the firmware configuration interface
   is available or not.
 
@@ -109,7 +90,7 @@ QemuFwCfgIsAvailable (
   VOID
   )
 {
-  return InternalQemuFwCfgIsAvailable ();
+  return (BOOLEAN)(mFwCfgSelectorAddress != 0 && mFwCfgDataAddress != 0);
 }
 
 
@@ -187,7 +168,7 @@ QemuFwCfgInitialize (
 FwCfgDmaAddress = 0;
   }
 
-  if (InternalQemuFwCfgIsAvailable ()) {
+  if (QemuFwCfgIsAvailable ()) {
 UINT32 Signature;
 
 QemuFwCfgSelectItem (QemuFwCfgItemSignature);
@@ -231,7 +212,7 @@ QemuFwCfgSelectItem (
   IN FIRMWARE_CONFIG_ITEM QemuFwCfgItem
   )
 {
-  if (InternalQemuFwCfgIsAvailable ()) {
+  if (QemuFwCfgIsAvailable ()) {
 MmioWrite16 (mFwCfgSelectorAddress, SwapBytes16 ((UINT16)QemuFwCfgItem));
   }
 }
@@ -360,7 +341,7 @@ QemuFwCfgReadBytes (
   IN VOID  *Buffer
   )
 {
-  if (InternalQemuFwCfgIsAvailable ()) {
+  if (QemuFwCfgIsAvailable ()) {
 InternalQemuFwCfgReadBytes (Size, Buffer);
   } else {
 ZeroMem (Buffer, Size);
@@ -384,7 +365,7 @@ QemuFwCfgWriteBytes (
   IN VOID   *Buffer
   )
 {
-  if (InternalQemuFwCfgIsAvailable ()) {
+  if (QemuFwCfgIsAvailable ()) {
 UINTN Idx;
 
 for (Idx = 0; Idx < Size; ++Idx) {
@@ -494,7 +475,7 @@ QemuFwCfgFindFile (
   UINT32 Count;
   UINT32 Idx;
 
-  if (!InternalQemuFwCfgIsAvailable ()) {
+  if (!QemuFwCfgIsAvailable ()) {
 return RETURN_UNSUPPORTED;
   }
 
-- 
2.9.2


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

[edk2] [PATCH 5/5] OvmfPkg/QemuFwCfgLib: support QEMU's DMA-like fw_cfg access method

[Laszlo Ersek]

The benefits of the DMA-like access method are (a) speed, (b) write
support in QEMU 2.9+.

(IOPort-based write support was discontinued in QEMU 2.4, and the
DMA-based one is being added to QEMU 2.9. Write support needs no separate
feature detection because writeability is governed on the level of
individual fw_cfg files -- if a file meant to be written by the firmware
exists in the directory, then it is writeable with the DMA method.)

We don't enable this feature for the SEC library instance, because:
- the SEC instance remains without clients (I've checked that it builds
  though),
- in SEC, any possible fw_cfg use is expected to be small and read-only.

Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibInternal.h | 13 
 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c | 73 
 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiDxe.c  | 26 ++-
 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSec.c | 15 
 4 files changed, 126 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibInternal.h 
b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibInternal.h
index 5b162bf98739..6e87c625102e 100644
--- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibInternal.h
+++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibInternal.h
@@ -30,4 +30,17 @@ InternalQemuFwCfgIsAvailable (
   VOID
   );
 
+
+/**
+  Returns a boolean indicating whether QEMU provides the DMA-like access method
+  for fw_cfg.
+
+  @retvalTRUE   The DMA-like access method is available.
+  @retvalFALSE  The DMA-like access method is unavailable.
+**/
+BOOLEAN
+InternalQemuFwCfgDmaIsAvailable (
+  VOID
+  );
+
 #endif
diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c 
b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
index 804d5b0e42be..f609f6422878 100644
--- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
+++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "QemuFwCfgLibInternal.h"
 
@@ -99,6 +100,70 @@ QemuFwCfgSelectItem (
 
 
 /**
+  Transfer an array of bytes using the DMA interface.
+
+  @param[in] SizeSize in bytes to transfer.
+  @param[in,out] Buffer  Buffer to read data into or write data from. May be
+ NULL if Size is zero.
+  @param[in] Write   TRUE if writing to fw_cfg from Buffer, FALSE if
+ reading from fw_cfg into Buffer.
+**/
+VOID
+InternalQemuFwCfgDmaBytes (
+  IN UINT32   Size,
+  IN OUT VOID *Buffer OPTIONAL,
+  IN BOOLEAN  Write
+  )
+{
+  volatile FW_CFG_DMA_ACCESS Access;
+  UINT32 AccessHigh, AccessLow;
+  UINT32 Status;
+
+  if (Size == 0) {
+return;
+  }
+
+  Access.Control = SwapBytes32 (
+Write ? FW_CFG_DMA_CTL_WRITE : FW_CFG_DMA_CTL_READ
+);
+  Access.Length  = SwapBytes32 (Size);
+  Access.Address = SwapBytes64 ((UINTN)Buffer);
+
+  //
+  // Delimit the transfer from (a) modifications to Access, (b) in case of a
+  // write, from writes to Buffer by the caller.
+  //
+  MemoryFence ();
+
+  //
+  // Start the transfer.
+  //
+  AccessHigh = (UINT32)RShiftU64 ((UINTN), 32);
+  AccessLow  = (UINT32)(UINTN)
+  IoWrite32 (0x514, SwapBytes32 (AccessHigh));
+  IoWrite32 (0x518, SwapBytes32 (AccessLow));
+
+  //
+  // Don't look at Access.Control before starting the transfer.
+  //
+  MemoryFence ();
+
+  //
+  // Wait for the transfer to complete.
+  //
+  do {
+Status = SwapBytes32 (Access.Control);
+ASSERT ((Status & FW_CFG_DMA_CTL_ERROR) == 0);
+  } while (Status != 0);
+
+  //
+  // After a read, the caller will want to use Buffer.
+  //
+  MemoryFence ();
+}
+
+
+/**
   Reads firmware configuration bytes into a buffer
 
   @param[in] Size - Size in bytes to read
@@ -112,6 +177,10 @@ InternalQemuFwCfgReadBytes (
   IN VOID   *Buffer  OPTIONAL
   )
 {
+  if (InternalQemuFwCfgDmaIsAvailable () && Size <= MAX_UINT32) {
+InternalQemuFwCfgDmaBytes ((UINT32)Size, Buffer, FALSE);
+return;
+  }
   IoReadFifo8 (0x511, Size, Buffer);
 }
 
@@ -160,6 +229,10 @@ QemuFwCfgWriteBytes (
   )
 {
   if (InternalQemuFwCfgIsAvailable ()) {
+if (InternalQemuFwCfgDmaIsAvailable () && Size <= MAX_UINT32) {
+  InternalQemuFwCfgDmaBytes ((UINT32)Size, Buffer, TRUE);
+  return;
+}
 IoWriteFifo8 (0x511, Size, Buffer);
   }
 }
diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiDxe.c 
b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiDxe.c
index 88d88c0edf69..fde4a11b4e0d 100644
--- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiDxe.c
+++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiDxe.c
@@ -14,12 +14,14 @@
   WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 **/
 
+#include 
 #include 
 #include 
 
 #include "QemuFwCfgLibInternal.h"
 
 STATIC BOOLEAN mQemuFwCfgSupported = 

[edk2] [PATCH 0/5] OvmfPkg/QemuFwCfgLib: support the DMA-like interface

[Laszlo Ersek]

I plan to use the DMA interface of QEMU's fw_cfg in upcoming features
(one short term, another long term).

The first four patches in the series refactor the current library
instances (and even the lib class) slightly, while the last patch adds
the feature to OVMF.

Repo:   https://github.com/lersek/edk2/
Branch: ovmf_fwcfg_dma

Cc: Ard Biesheuvel 
Cc: Jordan Justen 

Thanks
Laszlo

Laszlo Ersek (5):
  ArmVirtPkg/QemuFwCfgLib: remove superfluous
InternalQemuFwCfgIsAvailable()
  OvmfPkg/QemuFwCfgLib: move InternalQemuFwCfgIsAvailable() to lib
instances
  OvmfPkg/IndustryStandard: add QemuFwCfgDma.h
  ArmVirtPkg/QemuFwCfgLib: rebase lib instance to
OvmfPkg/IndustryStandard
  OvmfPkg/QemuFwCfgLib: support QEMU's DMA-like fw_cfg access method

 ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c  | 55 +++---
 OvmfPkg/Include/IndustryStandard/QemuFwCfgDma.h | 50 +
 OvmfPkg/Include/Library/QemuFwCfgLib.h  | 16 -
 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c | 75 
 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf   |  1 +
 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibInternal.h | 46 
 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiDxe.c  | 29 +++-
 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSec.c | 17 -
 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf|  1 +
 9 files changed, 225 insertions(+), 65 deletions(-)
 create mode 100644 OvmfPkg/Include/IndustryStandard/QemuFwCfgDma.h
 create mode 100644 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibInternal.h

-- 
2.9.2

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

[edk2] [PATCH 2/5] OvmfPkg/QemuFwCfgLib: move InternalQemuFwCfgIsAvailable() to lib instances

[Laszlo Ersek]

InternalQemuFwCfgIsAvailable() is an API that is incorrectly exposed by
the "OvmfPkg/Include/Library/QemuFwCfgLib.h" library class header; the API
is meant to be used internally to library instances (if it's needed at
all).

In OvmfPkg, we have two lib instances (for SEC and PEI/DXE); they provide
different implementations of InternalQemuFwCfgIsAvailable(), for the
shared file "OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c". Move the API
declaration to a new internal header called "QemuFwCfgLibInternal.h", and
drop EFIAPI in the process.

Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf   |  1 +
 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf|  1 +
 OvmfPkg/Include/Library/QemuFwCfgLib.h  | 16 --
 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibInternal.h | 33 
 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c |  2 ++
 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiDxe.c  |  3 +-
 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSec.c |  2 +-
 7 files changed, 40 insertions(+), 18 deletions(-)

diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf 
b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf
index a95e1e730c2c..66ac77850915 100644
--- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf
+++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf
@@ -32,6 +32,7 @@ [Defines]
 #
 
 [Sources]
+  QemuFwCfgLibInternal.h
   QemuFwCfgLib.c
   QemuFwCfgPeiDxe.c
 
diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf 
b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf
index 03a659c9b082..c1d6a54b1a39 100644
--- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf
+++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf
@@ -30,6 +30,7 @@ [Defines]
 #
 
 [Sources]
+  QemuFwCfgLibInternal.h
   QemuFwCfgLib.c
   QemuFwCfgSec.c
 
diff --git a/OvmfPkg/Include/Library/QemuFwCfgLib.h 
b/OvmfPkg/Include/Library/QemuFwCfgLib.h
index baaa257d6188..7c29422fbd72 100644
--- a/OvmfPkg/Include/Library/QemuFwCfgLib.h
+++ b/OvmfPkg/Include/Library/QemuFwCfgLib.h
@@ -206,22 +206,6 @@ QemuFwCfgFindFile (
 
 
 /**
-  Returns a boolean indicating if the firmware configuration interface is
-  available for library-internal purposes.
-
-  This function never changes fw_cfg state.
-
-  @retvalTRUE   The interface is available internally.
-  @retvalFALSE  The interface is not available internally.
-**/
-BOOLEAN
-EFIAPI
-InternalQemuFwCfgIsAvailable (
-  VOID
-  );
-
-
-/**
   Determine if S3 support is explicitly enabled.
 
   @retval  TRUE   if S3 support is explicitly enabled.
diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibInternal.h 
b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibInternal.h
new file mode 100644
index ..5b162bf98739
--- /dev/null
+++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibInternal.h
@@ -0,0 +1,33 @@
+/** @file
+  Internal interfaces specific to the QemuFwCfgLib instances in OvmfPkg.
+
+  Copyright (C) 2016, Red Hat, Inc.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License which accompanies this
+  distribution.  The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __QEMU_FW_CFG_LIB_INTERNAL_H__
+#define __QEMU_FW_CFG_LIB_INTERNAL_H__
+
+/**
+  Returns a boolean indicating if the firmware configuration interface is
+  available for library-internal purposes.
+
+  This function never changes fw_cfg state.
+
+  @retvalTRUE   The interface is available internally.
+  @retvalFALSE  The interface is not available internally.
+**/
+BOOLEAN
+InternalQemuFwCfgIsAvailable (
+  VOID
+  );
+
+#endif
diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c 
b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
index 5c96d2af2532..804d5b0e42be 100644
--- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
+++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
@@ -22,6 +22,8 @@
 #include 
 #include 
 
+#include "QemuFwCfgLibInternal.h"
+
 
 /**
   Reads an 8-bit I/O port fifo into a block of memory.
diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiDxe.c 
b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiDxe.c
index f693cff29e01..88d88c0edf69 100644
--- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiDxe.c
+++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiDxe.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 
+#include "QemuFwCfgLibInternal.h"
+
 STATIC BOOLEAN mQemuFwCfgSupported = FALSE;
 
 
@@ -83,7 +85,6 @@ QemuFwCfgInitialize (
   @retvalFALSE  The interface is not available internally.
 **/
 BOOLEAN
-EFIAPI
 InternalQemuFwCfgIsAvailable (
   VOID
   )
diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSec.c 

[edk2] [PATCH 3/5] OvmfPkg/IndustryStandard: add QemuFwCfgDma.h

[Laszlo Ersek]

Add the type and macro definitions related to QEMU's DMA-like fw_cfg
access method in a dedicated header file.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Include/IndustryStandard/QemuFwCfgDma.h | 50 
 1 file changed, 50 insertions(+)

diff --git a/OvmfPkg/Include/IndustryStandard/QemuFwCfgDma.h 
b/OvmfPkg/Include/IndustryStandard/QemuFwCfgDma.h
new file mode 100644
index ..37a5804adb05
--- /dev/null
+++ b/OvmfPkg/Include/IndustryStandard/QemuFwCfgDma.h
@@ -0,0 +1,50 @@
+/** @file
+  Macro and type definitions related to QEMU's DMA-like fw_cfg access method,
+  based on "docs/specs/fw_cfg.txt" in the QEMU tree.
+
+  Copyright (C) 2016, Red Hat, Inc.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License which accompanies this
+  distribution.  The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+**/
+
+
+#ifndef __FW_CFG_DMA__
+#define __FW_CFG_DMA__
+
+#include 
+
+//
+// If the following bit is set in the UINT32 fw_cfg revision / feature bitmap
+// -- read from key 0x0001 with the basic IO Port or MMIO method --, then the
+// DMA interface is available.
+//
+#define FW_CFG_F_DMA BIT1
+
+//
+// Communication structure for the DMA access method. All fields are encoded in
+// big endian.
+//
+#pragma pack (1)
+typedef struct {
+  UINT32 Control;
+  UINT32 Length;
+  UINT64 Address;
+} FW_CFG_DMA_ACCESS;
+#pragma pack ()
+
+//
+// Macros for the FW_CFG_DMA_ACCESS.Control bitmap (in native encoding).
+//
+#define FW_CFG_DMA_CTL_ERROR  BIT0
+#define FW_CFG_DMA_CTL_READ   BIT1
+#define FW_CFG_DMA_CTL_SKIP   BIT2
+#define FW_CFG_DMA_CTL_SELECT BIT3
+#define FW_CFG_DMA_CTL_WRITE  BIT4
+
+#endif
-- 
2.9.2


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

[edk2] [PATCH 0/3] MdePkg, MdeModulePkg, Vlv2TbltDevicePkg: 64-bit LoopTimes in S3 MEM_POLL

[Laszlo Ersek]

While working on S3 boot script related stuff in OVMF, I wanted to see
if infinite blocking was possible in the various POLL opcodes. While
edk2's implementation of IO_POLL, PCI_CONFIG_POLL and PCI_CONFIG2_POLL
follows the PI spec vol5 closely, even internally (using 100ns delay
units), the MEM_POLL internals differ -- they are microseconds based.

That's not a problem per se (it's just a different internal opcode
representation, which is fine); the problem is that the current
internals don't conform to the spec: in 32-bit builds, the UINT64 number
of 100ns units that the caller intends to wait for is silently
truncated, for no good reason. This issue is not hard to fix (we can
even keep the microseconds-based internals), so let's fix it.

Repo:   https://github.com/lersek/edk2/
Branch: mempoll_looptimes_64bit

Cc: David Wei 
Cc: Feng Tian 
Cc: Liming Gao 
Cc: Mang Guo 
Cc: Michael D Kinney 
Cc: Star Zeng 

Thanks
Laszlo

Laszlo Ersek (3):
  MdePkg, MdeModulePkg: S3BootScriptSaveMemPoll(): accept 64-bit
LoopTimes
  MdeModulePkg: S3SaveStateDxe, SmmS3SaveState: save 64-bit LoopTimes
  Vlv2TbltDevicePkg/BootScriptSaveDxe: save 64-bit LoopTimes

 MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c  | 2 +-
 MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c| 8 
 MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c | 8 
 MdePkg/Include/Library/S3BootScriptLib.h| 2 +-
 MdePkg/Library/BaseS3BootScriptLibNull/BootScriptLib.c  | 2 +-
 Vlv2TbltDevicePkg/BootScriptSaveDxe/ScriptSave.c| 4 ++--
 6 files changed, 13 insertions(+), 13 deletions(-)

-- 
2.9.2

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

[edk2] [PATCH 3/3] Vlv2TbltDevicePkg/BootScriptSaveDxe: save 64-bit LoopTimes

[Laszlo Ersek]

The BootScriptMemPoll() helper function does the following:

- pop LoopTimes from the variable argument list as UINT64, then truncate
  it to UINTN,

- pass the truncated value to S3BootScriptSaveMemPoll() as last argument.

The truncation to UINTN is now superfluous, thanks to the patch titled
"MdePkg, MdeModulePkg: S3BootScriptSaveMemPoll(): accept 64-bit
LoopTimes".

Cc: David Wei 
Cc: Mang Guo 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 Vlv2TbltDevicePkg/BootScriptSaveDxe/ScriptSave.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Vlv2TbltDevicePkg/BootScriptSaveDxe/ScriptSave.c 
b/Vlv2TbltDevicePkg/BootScriptSaveDxe/ScriptSave.c
index af7b9680b643..4c6667df0c61 100644
--- a/Vlv2TbltDevicePkg/BootScriptSaveDxe/ScriptSave.c
+++ b/Vlv2TbltDevicePkg/BootScriptSaveDxe/ScriptSave.c
@@ -348,14 +348,14 @@ BootScriptMemPoll (
   UINT8 *BitMask;
   UINT8 *BitValue;
   UINTNDuration;
-  UINTNLoopTimes;
+  UINT64   LoopTimes;
 
   Width   = VA_ARG (Marker, S3_BOOT_SCRIPT_LIB_WIDTH);
   Address = VA_ARG (Marker, UINT64);
   BitMask = VA_ARG (Marker, UINT8 *);
   BitValue= VA_ARG (Marker, UINT8 *);
   Duration= (UINTN)VA_ARG (Marker, UINT64);
-  LoopTimes   = (UINTN)VA_ARG (Marker, UINT64);
+  LoopTimes   = VA_ARG (Marker, UINT64);
 
   return S3BootScriptSaveMemPoll (Width, Address, BitMask, BitValue, Duration, 
LoopTimes);
 }
-- 
2.9.2

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

[edk2] [PATCH 2/3] MdeModulePkg: S3SaveStateDxe, SmmS3SaveState: save 64-bit LoopTimes

[Laszlo Ersek]

The BootScriptWriteMemPoll() helper function in both drivers does the
following:

- pop Delay from the variable argument list as UINT64, then truncate it to
  UINTN,

- divide Delay by 10, using DivU64x32Remainder(), then store the quotient
  in LoopTimes (also UINTN),

- pass LoopTimes to S3BootScriptSaveMemPoll() as last argument.

The truncation to UINTN is superfluous and wrong in this logic (not to
mention incompatible with the PI spec); it prevents callers from
specifying Delays longer than 0x_ * 100ns (approximately 429
seconds == 7 minutes 9 seconds) on Ia32. In particular it prevents callers
from specifying an infinite timeout (for example, 0x___ *
100ns, approximately 58494 years).

Change the type of Delay and LoopTimes to UINT64. Keep the same logic,
just remove the truncations. The resultant LoopTimes values can be safely
passed to S3BootScriptSaveMemPoll() thanks to the previous patch.

Cc: Feng Tian 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c| 8 
 MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c 
b/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
index 32263c96c56b..efc0ef914064 100644
--- a/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
+++ b/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
@@ -343,15 +343,15 @@ BootScriptWriteMemPoll (
   UINT64 Address;
   VOID  *Data;
   VOID  *DataMask;  
-  UINTN Delay;   
-  UINTN LoopTimes;
+  UINT64Delay;
+  UINT64LoopTimes;
   UINT32Remainder;
 
   Width= VA_ARG (Marker, S3_BOOT_SCRIPT_LIB_WIDTH);  
   Address  = VA_ARG (Marker, UINT64);
   Data = VA_ARG (Marker, VOID *);
   DataMask = VA_ARG (Marker, VOID *);
-  Delay= (UINTN)VA_ARG (Marker, UINT64);
+  Delay= VA_ARG (Marker, UINT64);
   //
   // According to the spec, the interval between 2 polls is 100ns,
   // but the unit of Duration for S3BootScriptSaveMemPoll() is 
microsecond(1000ns).
@@ -359,7 +359,7 @@ BootScriptWriteMemPoll (
   // Duration will be minimum 1(microsecond) to be minimum deviation,
   // so LoopTimes = Delay / 10.
   //
-  LoopTimes = (UINTN) DivU64x32Remainder (
+  LoopTimes = DivU64x32Remainder (
 Delay,
 10,
 
diff --git a/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c 
b/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c
index 739f19eac437..0d1580dc35ab 100644
--- a/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c
+++ b/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c
@@ -342,15 +342,15 @@ BootScriptWriteMemPoll (
   UINT64 Address;
   VOID  *Data;   
   VOID  *DataMask;   
-  UINTN  Delay;   
-  UINTN  LoopTimes;
+  UINT64 Delay;
+  UINT64 LoopTimes;
   UINT32 Remainder;
 
   Width= VA_ARG (Marker, S3_BOOT_SCRIPT_LIB_WIDTH);  
   Address  = VA_ARG (Marker, UINT64);
   Data = VA_ARG (Marker, VOID *);
   DataMask = VA_ARG (Marker, VOID *);
-  Delay= (UINTN)VA_ARG (Marker, UINT64);
+  Delay= VA_ARG (Marker, UINT64);
   //
   // According to the spec, the interval between 2 polls is 100ns,
   // but the unit of Duration for S3BootScriptSaveMemPoll() is 
microsecond(1000ns).
@@ -358,7 +358,7 @@ BootScriptWriteMemPoll (
   // Duration will be minimum 1(microsecond) to be minimum deviation,
   // so LoopTimes = Delay / 10.
   //
-  LoopTimes = (UINTN) DivU64x32Remainder (
+  LoopTimes = DivU64x32Remainder (
 Delay,
 10,
 
-- 
2.9.2


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

[edk2] [PATCH 1/3] MdePkg, MdeModulePkg: S3BootScriptSaveMemPoll(): accept 64-bit LoopTimes

[Laszlo Ersek]

The BaseNull instance of S3BootScriptLib obviously doesn't care about the
type of the S3BootScriptSaveMemPoll() function's LoopTimes parameter; this
lib instance doesn't do anything with the parameters received in
S3BootScriptSaveMemPoll().

The PiDxe instance saves the LoopTimes parameter in
EFI_BOOT_SCRIPT_MEM_POLL.LoopTimes. This target field already has UINT64
type. Furthermore, the BootScriptExecuteMemPoll() function in the same
library instance already uses a local UINT64 variable called LoopTimes to
count up to EFI_BOOT_SCRIPT_MEM_POLL.LoopTimes. This means that the the
UINTN type for S3BootScriptSaveMemPoll()'s LoopTimes parameter is an
unnecessary restriction.

The callers of S3BootScriptSaveMemPoll() will be updated in the next
patches, functionally. At this stage, they will continue to compile, since
UINT64 parameters can accept UINTN arguments.

Cc: Feng Tian 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 MdePkg/Include/Library/S3BootScriptLib.h   | 2 +-
 MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c | 2 +-
 MdePkg/Library/BaseS3BootScriptLibNull/BootScriptLib.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/MdePkg/Include/Library/S3BootScriptLib.h 
b/MdePkg/Include/Library/S3BootScriptLib.h
index 0a8cbe355aff..3f43da879469 100644
--- a/MdePkg/Include/Library/S3BootScriptLib.h
+++ b/MdePkg/Include/Library/S3BootScriptLib.h
@@ -343,7 +343,7 @@ S3BootScriptSaveMemPoll (
   IN  VOID  *BitMask,
   IN  VOID  *BitValue,
   IN  UINTN Duration,
-  IN  UINTN LoopTimes
+  IN  UINT64LoopTimes
   );
 
 /**
diff --git a/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c 
b/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
index 9ff5b80e7a36..5698c9166399 100644
--- a/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
+++ b/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
@@ -1672,7 +1672,7 @@ S3BootScriptSaveMemPoll (
   IN  VOID  *BitMask,
   IN  VOID  *BitValue,
   IN  UINTN Duration,
-  IN  UINTN LoopTimes
+  IN  UINT64LoopTimes
   )
 {
   UINT8 Length;
diff --git a/MdePkg/Library/BaseS3BootScriptLibNull/BootScriptLib.c 
b/MdePkg/Library/BaseS3BootScriptLibNull/BootScriptLib.c
index 373ce6b388e5..3dee64746ad9 100644
--- a/MdePkg/Library/BaseS3BootScriptLibNull/BootScriptLib.c
+++ b/MdePkg/Library/BaseS3BootScriptLibNull/BootScriptLib.c
@@ -303,7 +303,7 @@ S3BootScriptSaveMemPoll (
   IN  VOID  *BitMask,
   IN  VOID  *BitValue,
   IN  UINTN Duration,
-  IN  UINTN LoopTimes
+  IN  UINT64LoopTimes
   )
 {
return RETURN_SUCCESS;
-- 
2.9.2


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

Re: [edk2] [PATCH] ArmPkg: fix compilation error in ArmDmaLib

[Leif Lindholm]

On Thu, Dec 01, 2016 at 05:00:19PM +, Ard Biesheuvel wrote:
> On 1 December 2016 at 16:45, Leif Lindholm  wrote:
> > Commit 0a99a65d2c8a ("fix incorrect device address of double buffer")
> > retained an explicit cast on the variable "Buffer" which became
> > incorrect with the other changes, leading to compilation failures
> > with some toolchains. Drop the cast.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Reported-by: Sudeep Holla 
> > Signed-off-by: Leif Lindholm 
> 
> Reviewed-by: Ard Biesheuvel 

Get back on holiday!

Thanks :)

Pushed as 018c3c0, thanks.

/
Leif

> > ---
> >
> > Mike, Andrew - since Ard is on holiday and the fix is trivial,
> > could either of you give me a Reviewed-by: on this one?
> >
> >  ArmPkg/Library/ArmDmaLib/ArmDmaLib.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/ArmPkg/Library/ArmDmaLib/ArmDmaLib.c 
> > b/ArmPkg/Library/ArmDmaLib/ArmDmaLib.c
> > index acc106b..f4ee9e4 100644
> > --- a/ArmPkg/Library/ArmDmaLib/ArmDmaLib.c
> > +++ b/ArmPkg/Library/ArmDmaLib/ArmDmaLib.c
> > @@ -142,7 +142,7 @@ DmaMap (
> >  CopyMem (Buffer, HostAddress, *NumberOfBytes);
> >}
> >
> > -  *DeviceAddress = HostToDeviceAddress (ConvertToPhysicalAddress 
> > ((UINTN)Buffer));
> > +  *DeviceAddress = HostToDeviceAddress (ConvertToPhysicalAddress 
> > (Buffer));
> >Map->BufferAddress = Buffer;
> >  } else {
> >Map->DoubleBuffer  = FALSE;
> > --
> > 2.10.2
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmPkg: fix compilation error in ArmDmaLib

[Ard Biesheuvel]

On 1 December 2016 at 16:45, Leif Lindholm  wrote:
> Commit 0a99a65d2c8a ("fix incorrect device address of double buffer")
> retained an explicit cast on the variable "Buffer" which became
> incorrect with the other changes, leading to compilation failures
> with some toolchains. Drop the cast.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Reported-by: Sudeep Holla 
> Signed-off-by: Leif Lindholm 

Reviewed-by: Ard Biesheuvel 

> ---
>
> Mike, Andrew - since Ard is on holiday and the fix is trivial,
> could either of you give me a Reviewed-by: on this one?
>
>  ArmPkg/Library/ArmDmaLib/ArmDmaLib.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ArmPkg/Library/ArmDmaLib/ArmDmaLib.c 
> b/ArmPkg/Library/ArmDmaLib/ArmDmaLib.c
> index acc106b..f4ee9e4 100644
> --- a/ArmPkg/Library/ArmDmaLib/ArmDmaLib.c
> +++ b/ArmPkg/Library/ArmDmaLib/ArmDmaLib.c
> @@ -142,7 +142,7 @@ DmaMap (
>  CopyMem (Buffer, HostAddress, *NumberOfBytes);
>}
>
> -  *DeviceAddress = HostToDeviceAddress (ConvertToPhysicalAddress 
> ((UINTN)Buffer));
> +  *DeviceAddress = HostToDeviceAddress (ConvertToPhysicalAddress 
> (Buffer));
>Map->BufferAddress = Buffer;
>  } else {
>Map->DoubleBuffer  = FALSE;
> --
> 2.10.2
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmPkg: fix compilation error in ArmDmaLib

[Sudeep Holla]

On 01/12/16 16:45, Leif Lindholm wrote:

Commit 0a99a65d2c8a ("fix incorrect device address of double buffer")
retained an explicit cast on the variable "Buffer" which became
incorrect with the other changes, leading to compilation failures
with some toolchains. Drop the cast.

Contributed-under: TianoCore Contribution Agreement 1.0
Reported-by: Sudeep Holla 


It fixes the build for me.

Tested-by: Sudeep Holla 

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

[edk2] [PATCH] ArmPkg: fix compilation error in ArmDmaLib

[Leif Lindholm]

Commit 0a99a65d2c8a ("fix incorrect device address of double buffer")
retained an explicit cast on the variable "Buffer" which became
incorrect with the other changes, leading to compilation failures
with some toolchains. Drop the cast.

Contributed-under: TianoCore Contribution Agreement 1.0
Reported-by: Sudeep Holla 
Signed-off-by: Leif Lindholm 
---

Mike, Andrew - since Ard is on holiday and the fix is trivial,
could either of you give me a Reviewed-by: on this one?

 ArmPkg/Library/ArmDmaLib/ArmDmaLib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ArmPkg/Library/ArmDmaLib/ArmDmaLib.c 
b/ArmPkg/Library/ArmDmaLib/ArmDmaLib.c
index acc106b..f4ee9e4 100644
--- a/ArmPkg/Library/ArmDmaLib/ArmDmaLib.c
+++ b/ArmPkg/Library/ArmDmaLib/ArmDmaLib.c
@@ -142,7 +142,7 @@ DmaMap (
 CopyMem (Buffer, HostAddress, *NumberOfBytes);
   }
 
-  *DeviceAddress = HostToDeviceAddress (ConvertToPhysicalAddress 
((UINTN)Buffer));
+  *DeviceAddress = HostToDeviceAddress (ConvertToPhysicalAddress (Buffer));
   Map->BufferAddress = Buffer;
 } else {
   Map->DoubleBuffer  = FALSE;
-- 
2.10.2

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

Re: [edk2] [PATCH] ShellPkg/MV: Fix MV to deny moving parent of current directory

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ruiyu Ni
> Sent: Tuesday, November 22, 2016 6:58 PM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Chen, Chen A
> 
> Subject: [edk2] [PATCH] ShellPkg/MV: Fix MV to deny moving parent of
> current directory
> Importance: High
> 
> From: Chen A Chen 
> 
> When user types "mv -r fs0:\A\ fs1:\" under directory
> "fs0:\A\B\", MV command should deny such movement.
> 
> The patch fixes the above issue.
> It also denies moving current directory.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Chen A Chen 
> Cc: Jaben Carsey 
> ---
>  ShellPkg/Library/UefiShellLevel2CommandsLib/Mv.c | 81
> ++--
>  1 file changed, 75 insertions(+), 6 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Mv.c
> b/ShellPkg/Library/UefiShellLevel2CommandsLib/Mv.c
> index efaaeb2..71e4336 100644
> --- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Mv.c
> +++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Mv.c
> @@ -58,6 +58,73 @@ IsBetweenFileSystem(
>  }
> 
>  /**
> +  function to determine if SrcPath is valid to mv.
> +
> +  if SrcPath equal CWD then it's invalid.
> +  if SrcPath is the parent path of CWD then it's invalid.
> +  is SrcPath is NULL return FALSE.
> +
> +  if CwdPath is NULL then ASSERT()
> +
> +  @param SrcPath  [in]The source path.
> +  @param CwdPath  [in]The current working directory.
> +
> +  @retval TRUEThe source path is valid.
> +  @retval FALSE   The source path is invalid.
> +**/
> +BOOLEAN
> +IsSoucePathValid(
> +  IN CONST CHAR16*  SrcPath,
> +  IN CONST CHAR16*  CwdPath
> +  )
> +{
> +  CHAR16* SrcPathBuffer;
> +  CHAR16* CwdPathBuffer;
> +  BOOLEAN Ret;
> +
> +  ASSERT (CwdPath != NULL);
> +  if (SrcPath == NULL) {
> +return FALSE;
> +  }
> +
> +  Ret = TRUE;
> +
> +  SrcPathBuffer = AllocateCopyPool (StrSize (SrcPath), SrcPath);
> +  if (SrcPathBuffer == NULL) {
> +return FALSE;
> +  }
> +
> +  CwdPathBuffer = AllocateCopyPool (StrSize (CwdPath), CwdPath);
> +  if (CwdPathBuffer == NULL) {
> +FreePool(SrcPathBuffer);
> +return FALSE;
> +  }
> +
> +  gUnicodeCollation->StrUpr (gUnicodeCollation, SrcPathBuffer);
> +  gUnicodeCollation->StrUpr (gUnicodeCollation, CwdPathBuffer);
> +
> +  if (SrcPathBuffer[StrLen (SrcPathBuffer) -1 ] == L'\\') {
> +SrcPathBuffer[StrLen (SrcPathBuffer) - 1] = CHAR_NULL;
> +  }
> +
> +  if (CwdPathBuffer[StrLen (CwdPathBuffer) - 1] == L'\\') {
> +CwdPathBuffer[StrLen (CwdPathBuffer) - 1] = CHAR_NULL;
> +  }
> +
> +  if (StrCmp (CwdPathBuffer, SrcPathBuffer) == 0 ||
> +  ((StrStr (CwdPathBuffer, SrcPathBuffer) == CwdPathBuffer) &&
> +   (CwdPathBuffer[StrLen (SrcPathBuffer)] == L'\\'))
> + ) {
> +Ret = FALSE;
> +  }
> +
> +  FreePool (SrcPathBuffer);
> +  FreePool (CwdPathBuffer);
> +
> +  return Ret;
> +}
> +
> +/**
>Function to validate that moving a specific file (FileName) to a specific
>location (DestPath) is valid.
> 
> @@ -90,12 +157,14 @@ IsValidMove(
>CHAR16  *DestPathCopy;
>CHAR16  *DestPathWalker;
> 
> -  if (Cwd != NULL && StrCmp(SourcePath, Cwd) == 0) {
> -//
> -// Invalid move
> -//
> -ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_MV_INV_CWD),
> gShellLevel2HiiHandle);
> -return (FALSE);
> +  if ((Cwd != NULL) && ((Attribute & EFI_FILE_DIRECTORY) ==
> EFI_FILE_DIRECTORY)) {
> +if (!IsSoucePathValid (SourcePath, Cwd)) {
> +  //
> +  // Invalid move
> +  //
> +  ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN(STR_MV_INV_CWD),
> gShellLevel2HiiHandle);
> +  return FALSE;
> +}
>}
> 
>//
> --
> 2.9.0.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 7/7] Vlv2TbltDevicePkg: Remove use of IntelFrameworkModulePkg legacy libs

[Leif Lindholm]

LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
kept for compatibility.

Since the libraries are identical, move Vlv2TbltDevicePkg to use the
MdeModulePkg versions instead.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm 
---
 Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 4 ++--
 Vlv2TbltDevicePkg/PlatformPkgIA32.dsc   | 6 +++---
 Vlv2TbltDevicePkg/PlatformPkgX64.dsc| 6 +++---
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
index 6da2a8a..80d75d1 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
@@ -1064,7 +1064,7 @@ 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/IA32/fTPMInitPeim.inf
   MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf {
 
 !if $(LZMA_ENABLE) == TRUE
-
NULL|IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
+
NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
 !endif
   }
 
@@ -1121,7 +1121,7 @@ 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/IA32/fTPMInitPeim.inf
   
NULL|MdeModulePkg/Library/DxeCrc32GuidedSectionExtractLib/DxeCrc32GuidedSectionExtractLib.inf
 !endif
 !if $(LZMA_ENABLE) == TRUE
-  
NULL|IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
+  
NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
 !endif
 !if $(TARGET) != RELEASE
   DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
diff --git a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
index 5b5523f..44ec378 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
@@ -332,7 +332,7 @@
   DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
   SerialPortLib|MdePkg/Library/BaseSerialPortLibNull/BaseSerialPortLibNull.inf
 !else
-  
DebugLib|IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
+  
DebugLib|MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
   SerialPortLib|$(PLATFORM_PACKAGE)/Library/SerialPortLib/SerialPortLib.inf
 !endif
 
@@ -1058,7 +1058,7 @@ 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/IA32/fTPMInitPeim.inf
   MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf {
 
 !if $(LZMA_ENABLE) == TRUE
-
NULL|IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
+
NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
 !endif
   }
 
@@ -1115,7 +1115,7 @@ 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/IA32/fTPMInitPeim.inf
   
NULL|MdeModulePkg/Library/DxeCrc32GuidedSectionExtractLib/DxeCrc32GuidedSectionExtractLib.inf
 !endif
 !if $(LZMA_ENABLE) == TRUE
-  
NULL|IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
+  
NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
 !endif
 !if $(TARGET) != RELEASE
   DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
diff --git a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
index 54d2b81..40568f6 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
@@ -332,7 +332,7 @@
   DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
   SerialPortLib|MdePkg/Library/BaseSerialPortLibNull/BaseSerialPortLibNull.inf
 !else
-  
DebugLib|IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
+  
DebugLib|MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
   SerialPortLib|$(PLATFORM_PACKAGE)/Library/SerialPortLib/SerialPortLib.inf
 !endif
 
@@ -1058,7 +1058,7 @@ 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/IA32/fTPMInitPeim.inf
   MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf {
 
 !if $(LZMA_ENABLE) == TRUE
-
NULL|IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
+
NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
 !endif
   }
 
@@ -1115,7 +1115,7 @@ 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/IA32/fTPMInitPeim.inf
   
NULL|MdeModulePkg/Library/DxeCrc32GuidedSectionExtractLib/DxeCrc32GuidedSectionExtractLib.inf
 !endif
 !if $(LZMA_ENABLE) == TRUE
-  
NULL|IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
+  
NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
 !endif
 !if $(TARGET) != RELEASE
   DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
-- 
2.10.2

___
edk2-devel mailing list

[edk2] [PATCH 1/7] OvmfPkg: Remove use of IntelFrameworkModulePkg legacy libs

[Leif Lindholm]

LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
kept for compatibility.

Since the libraries are identical, move OvmfPkg to use the MdeModulePkg
versions instead.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm 
Reviewed-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32.dsc| 4 ++--
 OvmfPkg/OvmfPkgIa32X64.dsc | 4 ++--
 OvmfPkg/OvmfPkgX64.dsc | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index d913030..81f7521 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -505,7 +505,7 @@
   #
   OvmfPkg/Sec/SecMain.inf {
 
-  
NULL|IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
+  
NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
   }
 
   #
@@ -550,7 +550,7 @@
   #
   MdeModulePkg/Core/Dxe/DxeMain.inf {
 
-  
NULL|IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
+  
NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
   DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
   }
 
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 8143ea9..f7855b6 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -513,7 +513,7 @@
   #
   OvmfPkg/Sec/SecMain.inf {
 
-  
NULL|IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
+  
NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
   }
 
   #
@@ -559,7 +559,7 @@
   #
   MdeModulePkg/Core/Dxe/DxeMain.inf {
 
-  
NULL|IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
+  
NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
   DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
   }
 
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index d48d603..e933a41 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -512,7 +512,7 @@
   #
   OvmfPkg/Sec/SecMain.inf {
 
-  
NULL|IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
+  
NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
   }
 
   #
@@ -557,7 +557,7 @@
   #
   MdeModulePkg/Core/Dxe/DxeMain.inf {
 
-  
NULL|IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
+  
NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
   DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
   }
 
-- 
2.10.2

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

[edk2] [PATCH 3/7] BeagleBoardPkg: Remove use of IntelFrameworkModulePkg legacy libs

[Leif Lindholm]

LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
kept for compatibility.

Since the libraries are identical, move BeagleBoardPkg to use the
MdeModulePkg versions instead.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm 
---
 BeagleBoardPkg/BeagleBoardPkg.dsc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/BeagleBoardPkg/BeagleBoardPkg.dsc 
b/BeagleBoardPkg/BeagleBoardPkg.dsc
index f40095a..b074b92 100644
--- a/BeagleBoardPkg/BeagleBoardPkg.dsc
+++ b/BeagleBoardPkg/BeagleBoardPkg.dsc
@@ -141,7 +141,7 @@
 
 [LibraryClasses.common.SEC]
   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
-  
ReportStatusCodeLib|IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
+  
ReportStatusCodeLib|MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
   
UefiDecompressLib|MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.inf
   
ExtractGuidedSectionLib|EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.inf
   
LzmaDecompressLib|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
@@ -163,7 +163,7 @@
 
 [LibraryClasses.common.PEI_CORE]
   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
-  
ReportStatusCodeLib|IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
+  
ReportStatusCodeLib|MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
 
 [LibraryClasses.common.DXE_CORE]
   HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
-- 
2.10.2

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

[edk2] [PATCH 2/7] QuarkSocPkg: Remove use of IntelFrameworkModulePkg legacy libs

[Leif Lindholm]

LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
kept for compatibility.

Since the libraries are identical, move iQuarkSocPkg to use the
MdeModulePkg versions instead.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm 
Reviewed-by: Michael Kinney 
---
 QuarkSocPkg/QuarkSocPkg.dsc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/QuarkSocPkg/QuarkSocPkg.dsc b/QuarkSocPkg/QuarkSocPkg.dsc
index 42bb5bb..9e37a0b 100644
--- a/QuarkSocPkg/QuarkSocPkg.dsc
+++ b/QuarkSocPkg/QuarkSocPkg.dsc
@@ -116,7 +116,7 @@
   #
   # Misc
   #
-  
DebugLib|IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
+  
DebugLib|MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
   
DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
   
PerformanceLib|MdePkg/Library/BasePerformanceLibNull/BasePerformanceLibNull.inf
   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
-- 
2.10.2

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

[edk2] [PATCH 6/7] EmulatorPkg: Remove use of IntelFrameworkModulePkg legacy libs

[Leif Lindholm]

LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
kept for compatibility.

Since the libraries are identical, move EmulatorPkg to use the
MdeModulePkg versions instead.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm 
---
 EmulatorPkg/EmulatorPkg.dsc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
index f516adf..b96b9f2 100644
--- a/EmulatorPkg/EmulatorPkg.dsc
+++ b/EmulatorPkg/EmulatorPkg.dsc
@@ -101,7 +101,7 @@
   
PerformanceLib|MdePkg/Library/BasePerformanceLibNull/BasePerformanceLibNull.inf
   DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
   
PeiServicesTablePointerLib|EmulatorPkg/Library/PeiServicesTablePointerLibMagicPage/PeiServicesTablePointerLibMagicPage.inf
-  
DebugLib|IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
+  
DebugLib|MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
   LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
   
CpuExceptionHandlerLib|MdeModulePkg/Library/CpuExceptionHandlerLibNull/CpuExceptionHandlerLibNull.inf
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
@@ -281,7 +281,7 @@
   
SerialPortLib|EmulatorPkg/Library/DxeEmuStdErrSerialPortLib/DxeEmuStdErrSerialPortLib.inf
   DxeEmuLib|EmulatorPkg/Library/DxeEmuLib/DxeEmuLib.inf
   
NULL|MdeModulePkg/Library/DxeCrc32GuidedSectionExtractLib/DxeCrc32GuidedSectionExtractLib.inf
-  
NULL|IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
+  
NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
   }
   MdeModulePkg/Universal/PCD/Dxe/Pcd.inf {
 
-- 
2.10.2

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

[edk2] [PATCH 4/7] EmbeddedPkg: Remove use of IntelFrameworkModulePkg legacy libs

[Leif Lindholm]

LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
kept for compatibility.

Since the libraries are identical, move EmbeddedPkg to use the
MdeModulePkg versions instead.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm 
---
 EmbeddedPkg/EmbeddedPkg.dsc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/EmbeddedPkg/EmbeddedPkg.dsc b/EmbeddedPkg/EmbeddedPkg.dsc
index eb7af80..ba4f1ea 100644
--- a/EmbeddedPkg/EmbeddedPkg.dsc
+++ b/EmbeddedPkg/EmbeddedPkg.dsc
@@ -60,7 +60,7 @@
   
UefiDecompressLib|MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.inf
   EfiFileLib|EmbeddedPkg/Library/EfiFileLib/EfiFileLib.inf
 
-  
ReportStatusCodeLib|IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
+  
ReportStatusCodeLib|MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
 
   
PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
   PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
-- 
2.10.2

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

[edk2] [PATCH 5/7] DuetPkg: Remove use of IntelFrameworkModulePkg legacy libs

[Leif Lindholm]

LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
kept for compatibility.

Since the libraries are identical, move DuetPkg to use the MdeModulePkg
versions instead.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm 
---
 DuetPkg/DuetPkgIa32.dsc | 4 ++--
 DuetPkg/DuetPkgX64.dsc  | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/DuetPkg/DuetPkgIa32.dsc b/DuetPkg/DuetPkgIa32.dsc
index 3b59343..7dd963b 100644
--- a/DuetPkg/DuetPkgIa32.dsc
+++ b/DuetPkg/DuetPkgIa32.dsc
@@ -178,7 +178,7 @@
   gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2F
   gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x8042
 
-  
DebugLib|IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
+  
DebugLib|MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
   
ReportStatusCodeLib|DuetPkg/Library/DxeCoreReportStatusCodeLibFromHob/DxeCoreReportStatusCodeLibFromHob.inf
   }
 
@@ -211,7 +211,7 @@
   DuetPkg/EfiLdr/EfiLdr.inf {
 
   DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
-  
NULL|IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
+  
NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
   }
   IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf {
 
diff --git a/DuetPkg/DuetPkgX64.dsc b/DuetPkg/DuetPkgX64.dsc
index c23354a..1b08a95 100644
--- a/DuetPkg/DuetPkgX64.dsc
+++ b/DuetPkg/DuetPkgX64.dsc
@@ -179,7 +179,7 @@
   gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2F
   gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x8042
 
-  
DebugLib|IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
+  
DebugLib|MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
   
ReportStatusCodeLib|DuetPkg/Library/DxeCoreReportStatusCodeLibFromHob/DxeCoreReportStatusCodeLibFromHob.inf
   }
 
@@ -212,7 +212,7 @@
   DuetPkg/EfiLdr/EfiLdr.inf {
 
   DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
-  
NULL|IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
+  
NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
   }
   IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf {
 
-- 
2.10.2

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

[edk2] [PATCH 0/7] Various: Remove EDK2 use of IntelFrameworkModulePkg legacy libs

[Leif Lindholm]

LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
kept for compatibility.

Nevertheless, new code should be using the MdeModulePkg versions, so
change all references in in-tree platforms.

Since the patches are individually independent, I plan to push them
myself as Reviewed-by:s appear. Laszlo/Mike - Are you OK with me pusing
1 and 2 myself before the whole series is reviewed?

Changes from RFC:
- Broken down into per-package patches.
- Received Reviewed-by:s added.

Leif Lindholm (7):
  OvmfPkg: Remove use of IntelFrameworkModulePkg legacy libs
  QuarkSocPkg: Remove use of IntelFrameworkModulePkg legacy libs
  BeagleBoardPkg: Remove use of IntelFrameworkModulePkg legacy libs
  EmbeddedPkg: Remove use of IntelFrameworkModulePkg legacy libs
  DuetPkg: Remove use of IntelFrameworkModulePkg legacy libs
  EmulatorPkg: Remove use of IntelFrameworkModulePkg legacy libs
  Vlv2TbltDevicePkg: Remove use of IntelFrameworkModulePkg legacy libs

 BeagleBoardPkg/BeagleBoardPkg.dsc   | 4 ++--
 DuetPkg/DuetPkgIa32.dsc | 4 ++--
 DuetPkg/DuetPkgX64.dsc  | 4 ++--
 EmbeddedPkg/EmbeddedPkg.dsc | 2 +-
 EmulatorPkg/EmulatorPkg.dsc | 4 ++--
 OvmfPkg/OvmfPkgIa32.dsc | 4 ++--
 OvmfPkg/OvmfPkgIa32X64.dsc  | 4 ++--
 OvmfPkg/OvmfPkgX64.dsc  | 4 ++--
 QuarkSocPkg/QuarkSocPkg.dsc | 2 +-
 Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 4 ++--
 Vlv2TbltDevicePkg/PlatformPkgIA32.dsc   | 6 +++---
 Vlv2TbltDevicePkg/PlatformPkgX64.dsc| 6 +++---
 12 files changed, 24 insertions(+), 24 deletions(-)

-- 
2.10.2

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

[edk2] [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5

[Anthony PERARD]

Hi,

That might be only with the Xen part of OVMF but now that the GCC5
toolchains is used with my gcc (6.2.1 20160830, Arch Linux), OVMF fail
to boot in Xen guests.

Here is the result:
 X64 Exception Type - 06(#UD - Invalid Opcode)  CPU Apic ID -  
RIP  - 1F26AF6B, CS  - 0038, RFLAGS - 00010202
RAX  - 0001, RCX - 1F26AF51, RDX - 0004
RBX  - , RSP - 1F43C510, RBP - 1E583D18
RSI  - 0003, RDI - 0001
R8   - , R9  - , R10 - 1E58DB98
R11  - 0002, R12 - 1E58D898, R13 - 
R14  - 1E58D8A0, R15 - 1F26D001
DS   - 0030, ES  - 0030, FS  - 0030
GS   - 0030, SS  - 0030
CR0  - 8033, CR2 - , CR3 - 1F3DB000
CR4  - 0668, CR8 - 
DR0  - , DR1 - , DR2 - 
DR3  - , DR6 - 0FF0, DR7 - 0400
GDTR - 1F3C9A98 0047, LDTR - 
IDTR - 1EB0A018 0FFF,   TR - 
FXSAVE_STATE - 1F43C170
 Find PE image 
./Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/XenBusDxe/XenBusDxe/DEBUG/XenBusDxe.dll 
(ImageBase=1F266000, EntryPoint=1F2669D5) 

Removing the gcc option -flto in only the XenBusDxe module makes OVMF
boot.

While trying to debug that, I've added some debug prints (in this module
and in XenPvBlkDxe), and the exception could change and become a "page
fault" instead, or even an assert failure in the PrintLib, that was the
ASSERT(Buffer != NULL) at I think
MdePkg/Library/BasePrintLib/PrintLibInternal.c:366

Adding EFIAPI to internal functions in XenBusDxe makes things work
again.  My guest is that gcc would bypass (optimise) an exported
functions and call directly an internal one but without reordering the
arguments (EFIAPI vs nothing).

Does that make sense?

Anthony PERARD (4):
  OvmfPkg/XenHypercallLib: Add EFIAPI
  OvmfPkg/XenBusDxe: Add EFIAPI to XenEventChannelNotify
  OvmfPkg/XenBusDxe: Add EFIAPI to XenStore functions
  OvmfPkg/XenBusDxe: Add EFIAPI to XenGrantTable{Grant,End}Access

 OvmfPkg/Include/Library/XenHypercallLib.h  |  3 +++
 OvmfPkg/Library/XenHypercallLib/XenHypercall.c |  3 +++
 OvmfPkg/XenBusDxe/EventChannel.c   |  1 +
 OvmfPkg/XenBusDxe/EventChannel.h   |  1 +
 OvmfPkg/XenBusDxe/GrantTable.c |  2 ++
 OvmfPkg/XenBusDxe/XenStore.c   | 13 +
 OvmfPkg/XenBusDxe/XenStore.h   | 10 ++
 7 files changed, 33 insertions(+)

-- 
Anthony PERARD

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

[edk2] [PATCH 3/4] OvmfPkg/XenBusDxe: Add EFIAPI to XenStore functions

[Anthony PERARD]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/XenBusDxe/XenStore.c | 13 +
 OvmfPkg/XenBusDxe/XenStore.h | 10 ++
 2 files changed, 23 insertions(+)

diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
index 1666c4b..d69ed7d 100644
--- a/OvmfPkg/XenBusDxe/XenStore.c
+++ b/OvmfPkg/XenBusDxe/XenStore.c
@@ -791,6 +791,7 @@ XenStoreReadReply (
 **/
 STATIC
 XENSTORE_STATUS
+EFIAPI
 XenStoreTalkv (
   IN  CONST XENSTORE_TRANSACTION *Transaction,
   IN  enum xsd_sockmsg_type   RequestType,
@@ -874,6 +875,7 @@ Error:
 **/
 STATIC
 XENSTORE_STATUS
+EFIAPI
 XenStoreSingle (
   IN  CONST XENSTORE_TRANSACTION *Transaction,
   IN  enum xsd_sockmsg_type   RequestType,
@@ -949,6 +951,7 @@ XenStoreUnwatch (
 
 STATIC
 XENSTORE_STATUS
+EFIAPI
 XenStoreWaitWatch (
   VOID *Token
   )
@@ -1162,6 +1165,7 @@ XenStoreDeinit (
 //
 
 XENSTORE_STATUS
+EFIAPI
 XenStoreListDirectory (
   IN  CONST XENSTORE_TRANSACTION *Transaction,
   IN  CONST CHAR8   *DirectoryPath,
@@ -1189,6 +1193,7 @@ XenStoreListDirectory (
 }
 
 BOOLEAN
+EFIAPI
 XenStorePathExists (
   IN CONST XENSTORE_TRANSACTION *Transaction,
   IN CONST CHAR8   *Directory,
@@ -1209,6 +1214,7 @@ XenStorePathExists (
 }
 
 XENSTORE_STATUS
+EFIAPI
 XenStoreRead (
   IN  CONST XENSTORE_TRANSACTION *Transaction,
   IN  CONST CHAR8 *DirectoryPath,
@@ -1233,6 +1239,7 @@ XenStoreRead (
 }
 
 XENSTORE_STATUS
+EFIAPI
 XenStoreWrite (
   IN CONST XENSTORE_TRANSACTION *Transaction,
   IN CONST CHAR8   *DirectoryPath,
@@ -1258,6 +1265,7 @@ XenStoreWrite (
 }
 
 XENSTORE_STATUS
+EFIAPI
 XenStoreRemove (
   IN CONST XENSTORE_TRANSACTION *Transaction,
   IN CONST CHAR8*DirectoryPath,
@@ -1275,6 +1283,7 @@ XenStoreRemove (
 }
 
 XENSTORE_STATUS
+EFIAPI
 XenStoreTransactionStart (
   OUT XENSTORE_TRANSACTION  *Transaction
   )
@@ -1293,6 +1302,7 @@ XenStoreTransactionStart (
 }
 
 XENSTORE_STATUS
+EFIAPI
 XenStoreTransactionEnd (
   IN CONST XENSTORE_TRANSACTION *Transaction,
   IN BOOLEANAbort
@@ -1307,6 +1317,7 @@ XenStoreTransactionEnd (
 }
 
 XENSTORE_STATUS
+EFIAPI
 XenStoreVSPrint (
   IN CONST XENSTORE_TRANSACTION *Transaction,
   IN CONST CHAR8   *DirectoryPath,
@@ -1352,6 +1363,7 @@ XenStoreSPrint (
 }
 
 XENSTORE_STATUS
+EFIAPI
 XenStoreRegisterWatch (
   IN CONST CHAR8  *DirectoryPath,
   IN CONST CHAR8  *Node,
@@ -1393,6 +1405,7 @@ XenStoreRegisterWatch (
 }
 
 VOID
+EFIAPI
 XenStoreUnregisterWatch (
   IN XENSTORE_WATCH *Watch
   )
diff --git a/OvmfPkg/XenBusDxe/XenStore.h b/OvmfPkg/XenBusDxe/XenStore.h
index c9d4c65..c38fe37 100644
--- a/OvmfPkg/XenBusDxe/XenStore.h
+++ b/OvmfPkg/XenBusDxe/XenStore.h
@@ -53,6 +53,7 @@ typedef struct _XENSTORE_WATCH XENSTORE_WATCH;
 caller.
 **/
 XENSTORE_STATUS
+EFIAPI
 XenStoreListDirectory (
   IN  CONST XENSTORE_TRANSACTION *Transaction,
   IN  CONST CHAR8   *DirectoryPath,
@@ -73,6 +74,7 @@ XenStoreListDirectory (
 to make that determination.
 **/
 BOOLEAN
+EFIAPI
 XenStorePathExists (
   IN CONST XENSTORE_TRANSACTION *Transaction,
   IN CONST CHAR8 *Directory,
@@ -97,6 +99,7 @@ XenStorePathExists (
 caller.
 **/
 XENSTORE_STATUS
+EFIAPI
 XenStoreRead (
   IN  CONST XENSTORE_TRANSACTION *Transaction,
   IN  CONST CHAR8 *DirectoryPath,
@@ -117,6 +120,7 @@ XenStoreRead (
indicating the type of failure.
 **/
 XENSTORE_STATUS
+EFIAPI
 XenStoreWrite (
   IN CONST XENSTORE_TRANSACTION *Transaction,
   IN CONST CHAR8   *DirectoryPath,
@@ -135,6 +139,7 @@ XenStoreWrite (
indicating the type of failure.
 **/
 XENSTORE_STATUS
+EFIAPI
 XenStoreRemove (
   IN CONST XENSTORE_TRANSACTION *Transaction,
   IN CONST CHAR8*DirectoryPath,
@@ -154,6 +159,7 @@ XenStoreRemove (
indicating the type of failure.
 **/
 XENSTORE_STATUS
+EFIAPI
 XenStoreTransactionStart (
   OUT XENSTORE_TRANSACTION *Transaction
   );
@@ -169,6 +175,7 @@ XenStoreTransactionStart (
indicating the type of failure.
 **/
 XENSTORE_STATUS
+EFIAPI
 XenStoreTransactionEnd (
   IN CONST XENSTORE_TRANSACTION *Transaction,
   IN BOOLEANAbort
@@ -209,6 +216,7 @@ XenStoreSPrint (
indicating the type of write failure.
 **/
 XENSTORE_STATUS
+EFIAPI
 XenStoreVSPrint (
   IN CONST XENSTORE_TRANSACTION *Transaction,
   IN CONST CHAR8   *DirectoryPath,
@@ -233,6 +241,7 @@ XenStoreVSPrint (
xenbus_watch objects, to watch the same path in the XenStore.
 **/
 XENSTORE_STATUS
+EFIAPI
 XenStoreRegisterWatch (
   IN  CONST CHAR8 *DirectoryPath,
   IN  CONST CHAR8 *Node,
@@ -246,6 +255,7 @@ XenStoreRegisterWatch (
 call to XenStoreRegisterWatch ().
 **/
 VOID
+EFIAPI
 XenStoreUnregisterWatch (
   IN XENSTORE_WATCH *Watch
   );
-- 
Anthony PERARD

___
edk2-devel mailing list

[edk2] [PATCH 2/4] OvmfPkg/XenBusDxe: Add EFIAPI to XenEventChannelNotify

[Anthony PERARD]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD 
---
 OvmfPkg/XenBusDxe/EventChannel.c | 1 +
 OvmfPkg/XenBusDxe/EventChannel.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/OvmfPkg/XenBusDxe/EventChannel.c b/OvmfPkg/XenBusDxe/EventChannel.c
index 490ca58..b9d919f 100644
--- a/OvmfPkg/XenBusDxe/EventChannel.c
+++ b/OvmfPkg/XenBusDxe/EventChannel.c
@@ -20,6 +20,7 @@
 #include 
 
 UINT32
+EFIAPI
 XenEventChannelNotify (
   IN XENBUS_DEVICE *Dev,
   IN evtchn_port_t Port
diff --git a/OvmfPkg/XenBusDxe/EventChannel.h b/OvmfPkg/XenBusDxe/EventChannel.h
index 4dcc20f..24520e6 100644
--- a/OvmfPkg/XenBusDxe/EventChannel.h
+++ b/OvmfPkg/XenBusDxe/EventChannel.h
@@ -28,6 +28,7 @@
   @return   Return 0 on success, or return the errno code from the 
hypercall.
 **/
 UINT32
+EFIAPI
 XenEventChannelNotify (
   IN XENBUS_DEVICE *Dev,
   IN evtchn_port_t Port
-- 
Anthony PERARD

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

Re: [edk2] [patch] MdeModulePkg/SdMmc: Fix build failure caused by last check-in

[Marcin Wojtas]

Hi Feng,

You are right. Sorry for the mistake.

Best regards,
Marcin

2016-12-01 9:41 GMT+01:00 Feng Tian :
> The commit e27cca has a typo on DEBUG level macro. And this debug
> message should be DEBUG_INFO rather than DEBUG_ERROR.
>
> Cc: Jan Dabros 
> Cc: Marcin Wojtas 
> Cc: Star Zeng 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Feng Tian 
> ---
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c 
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> index 4c1b5c8..23faec5 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> @@ -638,7 +638,7 @@ SdMmcPciHcDriverBindingStart (
>  if (EFI_ERROR (Status) && (Status != EFI_MEDIA_CHANGED)) {
>continue;
>  } else if (!MediaPresent) {
> -  DEBUG ((EFI_ERROR, "SdMmcHcCardDetect: No device attached in 
> Slot[%d]!!!\n", Slot));
> +  DEBUG ((DEBUG_INFO, "SdMmcHcCardDetect: No device attached in 
> Slot[%d]!!!\n", Slot));
>continue;
>  }
>
> --
> 2.7.1.windows.2
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] BaseTools/VolInfo: Fix printf issue using '%ls' in format string

[Hao Wu]

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

For GCC compilers, when building with option '-fshort-wchar', wide char
string format '%ls' does not work properly for printf() function. The
string specified by '%ls' will not be printed.

This commit avoids using '%ls' for printf() function and converts the wide
char string to char string for printing.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 BaseTools/Source/C/VolInfo/VolInfo.c | 79 +++-
 1 file changed, 78 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/C/VolInfo/VolInfo.c 
b/BaseTools/Source/C/VolInfo/VolInfo.c
index 46c7212..7d63e59 100644
--- a/BaseTools/Source/C/VolInfo/VolInfo.c
+++ b/BaseTools/Source/C/VolInfo/VolInfo.c
@@ -148,6 +148,17 @@ Usage (
   VOID
   );
 
+UINT32
+UnicodeStrLen (
+  IN CHAR16 *String
+  );
+
+VOID
+Unicode2AsciiString (
+  IN  CHAR16 *Source,
+  OUT CHAR8  *Destination
+  );
+
 int
 main (
   int   argc,
@@ -1606,6 +1617,7 @@ Returns:
   UINT32  RealHdrLen;
   CHAR8   *ToolInputFileName;
   CHAR8   *ToolOutputFileName;
+  CHAR8   *UIFileName;
 
   ParsedLength = 0;
   ToolInputFileName = NULL;
@@ -1714,7 +1726,14 @@ Returns:
   break;
 
 case EFI_SECTION_USER_INTERFACE:
-  printf ("  String: %ls\n", (wchar_t *) &((EFI_USER_INTERFACE_SECTION *) 
Ptr)->FileNameString);
+  UIFileName = (CHAR8 *) malloc (UnicodeStrLen 
(((EFI_USER_INTERFACE_SECTION *) Ptr)->FileNameString) + 1);
+  if (UIFileName == NULL) {
+Error (NULL, 0, 4001, "Resource", "memory cannot be allocated!");
+return EFI_OUT_OF_RESOURCES;
+  }
+  Unicode2AsciiString (((EFI_USER_INTERFACE_SECTION *) 
Ptr)->FileNameString, UIFileName);
+  printf ("  String: %s\n", UIFileName);
+  free (UIFileName);
   break;
 
 case EFI_SECTION_FIRMWARE_VOLUME_IMAGE:
@@ -2360,3 +2379,61 @@ Returns:
 Reserved for future use\n");
 }
 
+UINT32
+UnicodeStrLen (
+  IN CHAR16 *String
+  )
+  /*++
+
+  Routine Description:
+
+  Returns the length of a null-terminated unicode string.
+
+  Arguments:
+
+String - The pointer to a null-terminated unicode string.
+
+  Returns:
+
+N/A
+
+  --*/
+{
+  UINT32  Length;
+
+  for (Length = 0; *String != L'\0'; String++, Length++) {
+;
+  }
+  return Length;
+}
+
+VOID
+Unicode2AsciiString (
+  IN  CHAR16 *Source,
+  OUT CHAR8  *Destination
+  )
+  /*++
+
+  Routine Description:
+
+  Convert a null-terminated unicode string to a null-terminated ascii string.
+
+  Arguments:
+
+Source  - The pointer to the null-terminated input unicode string.
+Destination - The pointer to the null-terminated output ascii string.
+
+  Returns:
+
+N/A
+
+  --*/
+{
+  while (*Source != '\0') {
+*(Destination++) = (CHAR8) *(Source++);
+  }
+  //
+  // End the ascii with a NULL.
+  //
+  *Destination = '\0';
+}
-- 
1.9.5.msysgit.0

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

[edk2] [PATCH V2] UefiCpuPkg/PiSmmCpu: Fixed #double fault on #page fault.

[Jiewen Yao]

This patch fixes https://bugzilla.tianocore.org/show_bug.cgi?id=246

Previously, when SMM exception happens after EndOfDxe,
with StackGuard enabled on IA32, the #double fault exception
is reported instead of #page fault.

Root cause is below:

Current EDKII SMM page protection will lock GDT.
If IA32 stack guard is enabled, the page fault handler will do task switch.
This task switch need write busy flag in GDT, and write TSS.

However, the GDT and TSS is locked at that time, so the
double fault happens.

We decide to not lock GDT for IA32 StackGuard enabled.

This issue does not exist on X64, or IA32 without StackGuard.

Cc: Laszlo Ersek 
Cc: Jeff Fan 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmFuncsArch.c  | 55 
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 68 
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c | 48 --
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c   | 49 +-
 4 files changed, 171 insertions(+), 49 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmFuncsArch.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmFuncsArch.c
index f4db6c8..3c68c97 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmFuncsArch.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmFuncsArch.c
@@ -127,6 +127,61 @@ InitGdt (
 }
 
 /**
+  This function sets GDT/IDT buffer to be RO and XP.
+**/
+VOID
+PatchGdtIdtMap (
+  VOID
+  )
+{
+  EFI_PHYSICAL_ADDRESS   BaseAddress;
+  UINTN  Size;
+
+  //
+  // GDT
+  //
+  DEBUG ((DEBUG_INFO, "PatchGdtIdtMap - GDT:\n"));
+
+  BaseAddress = mGdtBuffer;
+  Size = ALIGN_VALUE(mGdtBufferSize, SIZE_4KB);
+  if (!FeaturePcdGet (PcdCpuSmmStackGuard)) {
+//
+// Do not set RO for IA32 when stack guard feature is enabled.
+// Stack Guard need use task switch to switch stack.
+// It need write GDT and TSS.
+//
+SmmSetMemoryAttributes (
+  BaseAddress,
+  Size,
+  EFI_MEMORY_RO
+  );
+  }
+  SmmSetMemoryAttributes (
+BaseAddress,
+Size,
+EFI_MEMORY_XP
+);
+
+  //
+  // IDT
+  //
+  DEBUG ((DEBUG_INFO, "PatchGdtIdtMap - IDT:\n"));
+
+  BaseAddress = gcSmiIdtr.Base;
+  Size = ALIGN_VALUE(gcSmiIdtr.Limit + 1, SIZE_4KB);
+  SmmSetMemoryAttributes (
+BaseAddress,
+Size,
+EFI_MEMORY_RO
+);
+  SmmSetMemoryAttributes (
+BaseAddress,
+Size,
+EFI_MEMORY_XP
+);
+}
+
+/**
   Transfer AP to safe hlt-loop after it finished restore CPU features on S3 
patch.
 
   @param[in] ApHltLoopCode  The address of the safe hlt-loop function.
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h 
b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
index abe5cc6..c415858 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
@@ -524,6 +524,14 @@ InitGdt (
   );
 
 /**
+  This function sets GDT/IDT buffer to be RO and XP.
+**/
+VOID
+PatchGdtIdtMap (
+  VOID
+  );
+
+/**
 
   Register the SMM Foundation entry point.
 
@@ -596,6 +604,66 @@ SmmBlockingStartupThisAp (
   );
 
 /**
+  This function sets the attributes for the memory region specified by 
BaseAddress and
+  Length from their current attributes to the attributes specified by 
Attributes.
+
+  @param[in]  BaseAddress  The physical address that is the start address 
of a memory region.
+  @param[in]  Length   The size in bytes of the memory region.
+  @param[in]  Attributes   The bit mask of attributes to set for the 
memory region.
+
+  @retval EFI_SUCCESS   The attributes were set for the memory region.
+  @retval EFI_ACCESS_DENIED The attributes for the memory resource range 
specified by
+BaseAddress and Length cannot be modified.
+  @retval EFI_INVALID_PARAMETER Length is zero.
+Attributes specified an illegal combination of 
attributes that
+cannot be set together.
+  @retval EFI_OUT_OF_RESOURCES  There are not enough system resources to 
modify the attributes of
+the memory resource range.
+  @retval EFI_UNSUPPORTED   The processor does not support one or more 
bytes of the memory
+resource range specified by BaseAddress and 
Length.
+The bit mask of attributes is not support for 
the memory resource
+range specified by BaseAddress and Length.
+
+**/
+EFI_STATUS
+EFIAPI
+SmmSetMemoryAttributes (
+  IN  EFI_PHYSICAL_ADDRESS   BaseAddress,
+  IN  UINT64 Length,
+  IN  UINT64 Attributes
+  );
+
+/**
+  This function clears the attributes for the memory region specified by 
BaseAddress and
+  Length from their 

Re: [edk2] [RFC] Various: Remove EDK2 use of IntelFrameworkModulePkg legacy libs

[Leif Lindholm]

On Thu, Dec 01, 2016 at 09:52:15AM +0800, Zeng, Star wrote:
> On 2016/12/1 1:20, Leif Lindholm wrote:
> >LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
> >from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
> >kept for compatibility.
> >
> >Nevertheless, new code should be using the MdeModulePkg versions, so
> >change all references in in-tree platforms.
> >
> >Contributed-under: TianoCore Contribution Agreement 1.0
> >Signed-off-by: Leif Lindholm 
> >---
> > BeagleBoardPkg/BeagleBoardPkg.dsc   | 4 ++--
> > DuetPkg/DuetPkgIa32.dsc | 4 ++--
> > DuetPkg/DuetPkgX64.dsc  | 4 ++--
> > EmbeddedPkg/EmbeddedPkg.dsc | 2 +-
> > EmulatorPkg/EmulatorPkg.dsc | 4 ++--
> > IntelFrameworkModulePkg/IntelFrameworkModulePkg.dsc | 6 +++---
> 
> The change to IntelFrameworkModulePkg.dsc should be not needed as the
> package dsc is for package build to cover the libraries and modules in that
> package.

OK, yes, I admit my approach was of the shotgun variety.

I will drop the modifications to IntelFrameworkModulePkg when I split
this up into individual patches.

Thanks!

/
Leif

> Other changes look good to me.
> 
> 
> Thanks,
> Star
> 
> > OvmfPkg/OvmfPkgIa32.dsc | 4 ++--
> > OvmfPkg/OvmfPkgIa32X64.dsc  | 4 ++--
> > OvmfPkg/OvmfPkgX64.dsc  | 4 ++--
> > QuarkSocPkg/QuarkSocPkg.dsc | 2 +-
> > Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 4 ++--
> > Vlv2TbltDevicePkg/PlatformPkgIA32.dsc   | 6 +++---
> > Vlv2TbltDevicePkg/PlatformPkgX64.dsc| 6 +++---
> > 13 files changed, 27 insertions(+), 27 deletions(-)
> >
> >diff --git a/BeagleBoardPkg/BeagleBoardPkg.dsc 
> >b/BeagleBoardPkg/BeagleBoardPkg.dsc
> >index f40095a..b074b92 100644
> >--- a/BeagleBoardPkg/BeagleBoardPkg.dsc
> >+++ b/BeagleBoardPkg/BeagleBoardPkg.dsc
> >@@ -141,7 +141,7 @@
> >
> > [LibraryClasses.common.SEC]
> >   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
> >-  
> >ReportStatusCodeLib|IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
> >+  
> >ReportStatusCodeLib|MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
> >   
> > UefiDecompressLib|MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.inf
> >   
> > ExtractGuidedSectionLib|EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.inf
> >   
> > LzmaDecompressLib|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
> >@@ -163,7 +163,7 @@
> >
> > [LibraryClasses.common.PEI_CORE]
> >   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
> >-  
> >ReportStatusCodeLib|IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
> >+  
> >ReportStatusCodeLib|MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
> >
> > [LibraryClasses.common.DXE_CORE]
> >   HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
> >diff --git a/DuetPkg/DuetPkgIa32.dsc b/DuetPkg/DuetPkgIa32.dsc
> >index 3b59343..7dd963b 100644
> >--- a/DuetPkg/DuetPkgIa32.dsc
> >+++ b/DuetPkg/DuetPkgIa32.dsc
> >@@ -178,7 +178,7 @@
> >   gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2F
> >   gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x8042
> > 
> >-  
> >DebugLib|IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
> >+  
> >DebugLib|MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
> >   
> > ReportStatusCodeLib|DuetPkg/Library/DxeCoreReportStatusCodeLibFromHob/DxeCoreReportStatusCodeLibFromHob.inf
> >   }
> >
> >@@ -211,7 +211,7 @@
> >   DuetPkg/EfiLdr/EfiLdr.inf {
> > 
> >   DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
> >-  
> >NULL|IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
> >+  
> >NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
> >   }
> >   IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf {
> > 
> >diff --git a/DuetPkg/DuetPkgX64.dsc b/DuetPkg/DuetPkgX64.dsc
> >index c23354a..1b08a95 100644
> >--- a/DuetPkg/DuetPkgX64.dsc
> >+++ b/DuetPkg/DuetPkgX64.dsc
> >@@ -179,7 +179,7 @@
> >   gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2F
> >   gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x8042
> > 
> >-  
> >DebugLib|IntelFrameworkModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
> >+  
> >DebugLib|MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf
> >   
> > ReportStatusCodeLib|DuetPkg/Library/DxeCoreReportStatusCodeLibFromHob/DxeCoreReportStatusCodeLibFromHob.inf
> >   }
> >
> >@@ 

Re: [edk2] [PATCH] MdeModulePkg/CapsuleApp: add Internal for function name.

[Tian, Feng]

Reviewed-by: Feng Tian 

Thanks
Feng

-Original Message-
From: Yao, Jiewen 
Sent: Thursday, December 1, 2016 4:51 PM
To: edk2-devel@lists.01.org
Cc: Tian, Feng ; Fan, Jeff 
Subject: [PATCH] MdeModulePkg/CapsuleApp: add Internal for function name.

To prevent potential build failure.

Cc: Feng Tian 
Cc: Jeff Fan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
---
 MdeModulePkg/Application/CapsuleApp/AppSupport.c | 8   
MdeModulePkg/Application/CapsuleApp/CapsuleApp.c | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Application/CapsuleApp/AppSupport.c 
b/MdeModulePkg/Application/CapsuleApp/AppSupport.c
index 6aea76a..a5fd0ca 100644
--- a/MdeModulePkg/Application/CapsuleApp/AppSupport.c
+++ b/MdeModulePkg/Application/CapsuleApp/AppSupport.c
@@ -74,7 +74,7 @@ GetArg (
 
 **/
 EFI_STATUS
-StrToBuf (
+InternalStrToBuf (
   OUT UINT8*Buf,
   IN  UINTNBufferLength,
   IN  CHAR16   *Str
@@ -135,7 +135,7 @@ StrToBuf (
 
 **/
 EFI_STATUS
-StrToGuid (
+InternalStrToGuid (
   IN  CHAR16   *Str,
   OUT EFI_GUID *Guid
   )
@@ -185,7 +185,7 @@ StrToGuid (
   //
   // Get the following 8 bytes data
   //
-  StrToBuf (>Data4[0], 2, Str);
+  InternalStrToBuf (>Data4[0], 2, Str);
   //
   // Skip 2 byte hex chars
   //
@@ -196,7 +196,7 @@ StrToGuid (
   } else {
 return EFI_UNSUPPORTED;
   }
-  StrToBuf (>Data4[2], 6, Str);
+  InternalStrToBuf (>Data4[2], 6, Str);
 
   return EFI_SUCCESS;
 }
diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c 
b/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
index 5137259..5b8c147 100644
--- a/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
+++ b/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
@@ -155,7 +155,7 @@ WriteFileFromBuffer (
 
 **/
 EFI_STATUS
-StrToGuid (
+InternalStrToGuid (
   IN  CHAR16   *Str,
   OUT EFI_GUID *Guid
   );
@@ -782,7 +782,7 @@ UefiMain (
 //
 // FMP->GetImage()
 //
-Status = StrToGuid(Argv[3], );
+Status = InternalStrToGuid(Argv[3], );
 if (EFI_ERROR(Status)) {
   Print (L"Invalid ImageTypeId - %s\n", Argv[3]);
   return Status;
--
2.7.4.windows.1

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

[edk2] [PATCH] MdeModulePkg/CapsuleApp: add Internal for function name.

[Jiewen Yao]

To prevent potential build failure.

Cc: Feng Tian 
Cc: Jeff Fan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
---
 MdeModulePkg/Application/CapsuleApp/AppSupport.c | 8 
 MdeModulePkg/Application/CapsuleApp/CapsuleApp.c | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Application/CapsuleApp/AppSupport.c 
b/MdeModulePkg/Application/CapsuleApp/AppSupport.c
index 6aea76a..a5fd0ca 100644
--- a/MdeModulePkg/Application/CapsuleApp/AppSupport.c
+++ b/MdeModulePkg/Application/CapsuleApp/AppSupport.c
@@ -74,7 +74,7 @@ GetArg (
 
 **/
 EFI_STATUS
-StrToBuf (
+InternalStrToBuf (
   OUT UINT8*Buf,
   IN  UINTNBufferLength,
   IN  CHAR16   *Str
@@ -135,7 +135,7 @@ StrToBuf (
 
 **/
 EFI_STATUS
-StrToGuid (
+InternalStrToGuid (
   IN  CHAR16   *Str,
   OUT EFI_GUID *Guid
   )
@@ -185,7 +185,7 @@ StrToGuid (
   //
   // Get the following 8 bytes data
   //
-  StrToBuf (>Data4[0], 2, Str);
+  InternalStrToBuf (>Data4[0], 2, Str);
   //
   // Skip 2 byte hex chars
   //
@@ -196,7 +196,7 @@ StrToGuid (
   } else {
 return EFI_UNSUPPORTED;
   }
-  StrToBuf (>Data4[2], 6, Str);
+  InternalStrToBuf (>Data4[2], 6, Str);
 
   return EFI_SUCCESS;
 }
diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c 
b/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
index 5137259..5b8c147 100644
--- a/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
+++ b/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
@@ -155,7 +155,7 @@ WriteFileFromBuffer (
 
 **/
 EFI_STATUS
-StrToGuid (
+InternalStrToGuid (
   IN  CHAR16   *Str,
   OUT EFI_GUID *Guid
   );
@@ -782,7 +782,7 @@ UefiMain (
 //
 // FMP->GetImage()
 //
-Status = StrToGuid(Argv[3], );
+Status = InternalStrToGuid(Argv[3], );
 if (EFI_ERROR(Status)) {
   Print (L"Invalid ImageTypeId - %s\n", Argv[3]);
   return Status;
-- 
2.7.4.windows.1

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

[edk2] [patch] MdeModulePkg/SdMmc: Fix build failure caused by last check-in

[Feng Tian]

The commit e27cca has a typo on DEBUG level macro. And this debug
message should be DEBUG_INFO rather than DEBUG_ERROR.

Cc: Jan Dabros 
Cc: Marcin Wojtas 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Feng Tian 
---
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c 
b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
index 4c1b5c8..23faec5 100644
--- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
+++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
@@ -638,7 +638,7 @@ SdMmcPciHcDriverBindingStart (
 if (EFI_ERROR (Status) && (Status != EFI_MEDIA_CHANGED)) {
   continue;
 } else if (!MediaPresent) {
-  DEBUG ((EFI_ERROR, "SdMmcHcCardDetect: No device attached in 
Slot[%d]!!!\n", Slot));
+  DEBUG ((DEBUG_INFO, "SdMmcHcCardDetect: No device attached in 
Slot[%d]!!!\n", Slot));
   continue;
 }
 
-- 
2.7.1.windows.2

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

Re: [edk2] [Patch] MdeModulePkg PiSmmCore: Update comments in InitializeMemoryServices

[Gao, Liming]

Got it. I will keep comment "Need add Free memory at first, to let 
gSmmMemoryMap record data".

-Original Message-
From: Yao, Jiewen 
Sent: Thursday, December 01, 2016 3:41 PM
To: Gao, Liming ; edk2-devel@lists.01.org
Cc: Zeng, Star 
Subject: RE: [Patch] MdeModulePkg PiSmmCore: Update comments in 
InitializeMemoryServices

HI Liming
How about we keep original comment?
Your new comment describes *what* the coding is doing, and original comment 
describes *why*.

If you agree, reviewed-by: jiewen@intel.com


> -Original Message-
> From: Gao, Liming
> Sent: Thursday, December 1, 2016 2:47 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Yao, Jiewen 
> 
> Subject: [Patch] MdeModulePkg PiSmmCore: Update comments in 
> InitializeMemoryServices
> 
> Add the comments to describe Free and Allocated SMRAM are added 
> separately.
> 
> Cc: Star Zeng 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao 
> ---
>  MdeModulePkg/Core/PiSmmCore/Pool.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/PiSmmCore/Pool.c
> b/MdeModulePkg/Core/PiSmmCore/Pool.c
> index dcfd13e..b638aad 100644
> --- a/MdeModulePkg/Core/PiSmmCore/Pool.c
> +++ b/MdeModulePkg/Core/PiSmmCore/Pool.c
> @@ -85,8 +85,7 @@ SmmInitializeMemoryServices (
>  SmramRanges[CurrentSmramRangesIndex].PhysicalSize = 
> SmramRanges[CurrentSmramRangesIndex].PhysicalSize - SmmCodeSize;
>}
>//
> -  // Initialize free SMRAM regions
> -  // Need add Free memory at first, to let gSmmMemoryMap record data
> +  // Add Free SMRAM regions
>//
>for (Index = 0; Index < SmramRangeCount; Index++) {
>  if ((SmramRanges[Index].RegionState & (EFI_ALLOCATED | 
> EFI_NEEDS_TESTING | EFI_NEEDS_ECC_INITIALIZATION)) != 0) { @@ -100,6 
> +99,9 @@ SmmInitializeMemoryServices (
>);
>}
> 
> +  //
> +  // Add the allocated SMRAM regions
> +  //
>for (Index = 0; Index < SmramRangeCount; Index++) {
>  if ((SmramRanges[Index].RegionState & (EFI_ALLOCATED | 
> EFI_NEEDS_TESTING | EFI_NEEDS_ECC_INITIALIZATION)) == 0) {
>continue;
> --
> 2.8.0.windows.1

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

[edk2] [PATCH] MdeModulePkg/PiSmmCore; Use DEBUG_WARN for non 4k aligned image.

[Jiewen Yao]

Cc: Jeff Fan 
Cc: Michael D Kinney 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
---
 MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c 
b/MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c
index f7e5029..f8edb78 100644
--- a/MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c
+++ b/MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c
@@ -1126,11 +1126,11 @@ SmmInsertImageRecord (
 
   SetMemoryAttributesTableSectionAlignment (SectionAlignment);
   if ((SectionAlignment & (EFI_ACPI_RUNTIME_PAGE_ALLOCATION_ALIGNMENT - 1)) != 
0) {
-DEBUG ((DEBUG_ERROR, "SMM   InsertImageRecord - Section 
Alignment(0x%x) is not %dK  \n",
+DEBUG ((DEBUG_WARN, "SMM   InsertImageRecord - Section 
Alignment(0x%x) is not %dK  \n",
   SectionAlignment, EFI_ACPI_RUNTIME_PAGE_ALLOCATION_ALIGNMENT >> 10));
 PdbPointer = PeCoffLoaderGetPdbPointer ((VOID*) (UINTN) ImageAddress);
 if (PdbPointer != NULL) {
-  DEBUG ((DEBUG_ERROR, "SMM   Image - %a  \n", 
PdbPointer));
+  DEBUG ((DEBUG_WARN, "SMM   Image - %a  \n", PdbPointer));
 }
 goto Finish;
   }
-- 
2.7.4.windows.1

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

[edk2] [PATCH] MdeModulePkg/PiSmmCore: MemoryAttributeTable need keep non-PE record.

[Jiewen Yao]

Current memory attribute table implementation will only mark PE code
to be EfiRuntimeServicesCode, and mark rest to be EfiRuntimeServicesData.

However, there might be a case that a SMM code wants to allocate
EfiRuntimeServicesCode explicitly to let page table protect this region
to be read only. It is unsupported.

This patch enhances the current solution so that MemoryAttributeTable
does not touch non PE image record.
Only the PE image region is forced to be EfiRuntimeServicesCode for
code and EfiRuntimeServicesData for data.

Cc: Jeff Fan 
Cc: Michael D Kinney 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
---
 MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c | 91 +++-
 1 file changed, 51 insertions(+), 40 deletions(-)

diff --git a/MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c 
b/MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c
index 3a5a2c8..a6ab830 100644
--- a/MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c
+++ b/MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c
@@ -268,15 +268,19 @@ EnforceMemoryMapAttribute (
   MemoryMapEntry = MemoryMap;
   MemoryMapEnd   = (EFI_MEMORY_DESCRIPTOR *) ((UINT8 *) MemoryMap + 
MemoryMapSize);
   while ((UINTN)MemoryMapEntry < (UINTN)MemoryMapEnd) {
-switch (MemoryMapEntry->Type) {
-case EfiRuntimeServicesCode:
-  MemoryMapEntry->Attribute |= EFI_MEMORY_RO;
-  break;
-case EfiRuntimeServicesData:
-  MemoryMapEntry->Attribute |= EFI_MEMORY_XP;
-  break;
+if (MemoryMapEntry->Attribute != 0) {
+  // It is PE image, the attribute is already set.
+} else {
+  switch (MemoryMapEntry->Type) {
+  case EfiRuntimeServicesCode:
+MemoryMapEntry->Attribute = EFI_MEMORY_RO;
+break;
+  case EfiRuntimeServicesData:
+  default:
+MemoryMapEntry->Attribute |= EFI_MEMORY_XP;
+break;
+  }
 }
-
 MemoryMapEntry = NEXT_MEMORY_DESCRIPTOR (MemoryMapEntry, DescriptorSize);
   }
 
@@ -358,6 +362,21 @@ SetNewRecord (
   PhysicalEnd = TempRecord.PhysicalStart + 
EfiPagesToSize(TempRecord.NumberOfPages);
   NewRecordCount = 0;
 
+  //
+  // Always create a new entry for non-PE image record
+  //
+  if (ImageRecord->ImageBase > TempRecord.PhysicalStart) {
+NewRecord->Type = TempRecord.Type;
+NewRecord->PhysicalStart = TempRecord.PhysicalStart;
+NewRecord->VirtualStart  = 0;
+NewRecord->NumberOfPages = EfiSizeToPages(ImageRecord->ImageBase - 
TempRecord.PhysicalStart);
+NewRecord->Attribute = TempRecord.Attribute;
+NewRecord = NEXT_MEMORY_DESCRIPTOR (NewRecord, DescriptorSize);
+NewRecordCount ++;
+TempRecord.PhysicalStart = ImageRecord->ImageBase;
+TempRecord.NumberOfPages = EfiSizeToPages(PhysicalEnd - 
TempRecord.PhysicalStart);
+  }
+
   ImageRecordCodeSectionList = >CodeSegmentList;
 
   ImageRecordCodeSectionLink = ImageRecordCodeSectionList->ForwardLink;
@@ -452,14 +471,10 @@ GetMaxSplitRecordCount (
 if (ImageRecord == NULL) {
   break;
 }
-SplitRecordCount += (2 * ImageRecord->CodeSegmentCount + 1);
+SplitRecordCount += (2 * ImageRecord->CodeSegmentCount + 2);
 PhysicalStart = ImageRecord->ImageBase + ImageRecord->ImageSize;
   } while ((ImageRecord != NULL) && (PhysicalStart < PhysicalEnd));
 
-  if (SplitRecordCount != 0) {
-SplitRecordCount--;
-  }
-
   return SplitRecordCount;
 }
 
@@ -516,28 +531,16 @@ SplitRecord (
   //
   // No more image covered by this range, stop
   //
-  if ((PhysicalEnd > PhysicalStart) && (ImageRecord != NULL)) {
+  if (PhysicalEnd > PhysicalStart) {
 //
-// If this is still address in this record, need record.
+// Always create a new entry for non-PE image record
 //
-NewRecord = PREVIOUS_MEMORY_DESCRIPTOR (NewRecord, DescriptorSize);
-if (NewRecord->Type == EfiRuntimeServicesData) {
-  //
-  // Last record is DATA, just merge it.
-  //
-  NewRecord->NumberOfPages = EfiSizeToPages(PhysicalEnd - 
NewRecord->PhysicalStart);
-} else {
-  //
-  // Last record is CODE, create a new DATA entry.
-  //
-  NewRecord = NEXT_MEMORY_DESCRIPTOR (NewRecord, DescriptorSize);
-  NewRecord->Type = EfiRuntimeServicesData;
-  NewRecord->PhysicalStart = TempRecord.PhysicalStart;
-  NewRecord->VirtualStart  = 0;
-  NewRecord->NumberOfPages = TempRecord.NumberOfPages;
-  NewRecord->Attribute = TempRecord.Attribute | EFI_MEMORY_XP;
-  TotalNewRecordCount ++;
-}
+NewRecord->Type = TempRecord.Type;
+NewRecord->PhysicalStart = TempRecord.PhysicalStart;
+NewRecord->VirtualStart  = 0;
+NewRecord->NumberOfPages = TempRecord.NumberOfPages;
+NewRecord->Attribute = TempRecord.Attribute;
+

[edk2] [PATCH] MdeModulePkg/PiSmmCore: use EfiPagesToSize to prevent build error.

[Jiewen Yao]

EFI_PAGES_TO_SIZE only handles UINTN, so we use EfiPagesToSize
to handle UINT64.

Cc: Jeff Fan 
Cc: Michael D Kinney 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
---
 MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c 
b/MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c
index a6ab830..f7e5029 100644
--- a/MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c
+++ b/MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c
@@ -138,7 +138,7 @@ SmmMemoryAttributesTableConsistencyCheck (
 if (Address != 0) {
   ASSERT (Address == MemoryMap->PhysicalStart);
 }
-Address = MemoryMap->PhysicalStart + 
EFI_PAGES_TO_SIZE(MemoryMap->NumberOfPages);
+Address = MemoryMap->PhysicalStart + 
EfiPagesToSize(MemoryMap->NumberOfPages);
 MemoryMap = NEXT_MEMORY_DESCRIPTOR(MemoryMap, DescriptorSize);
   }
 }
@@ -1077,7 +1077,7 @@ SmmInsertImageRecord (
   // Step 1: record whole region
   //
   ImageRecord->ImageBase = DriverEntry->ImageBuffer;
-  ImageRecord->ImageSize = EFI_PAGES_TO_SIZE(DriverEntry->NumberOfPage);
+  ImageRecord->ImageSize = EfiPagesToSize(DriverEntry->NumberOfPage);
 
   ImageAddress = (VOID *)(UINTN)DriverEntry->ImageBuffer;
 
@@ -1281,7 +1281,7 @@ SmmRemoveImageRecord (
   DEBUG ((DEBUG_VERBOSE, "SMM RemoveImageRecord - 0x%x\n", DriverEntry));
   DEBUG ((DEBUG_VERBOSE, "SMM RemoveImageRecord - 0x%016lx - 0x%016lx\n", 
DriverEntry->ImageBuffer, DriverEntry->NumberOfPage));
 
-  ImageRecord = FindImageRecord (DriverEntry->ImageBuffer, 
EFI_PAGES_TO_SIZE(DriverEntry->NumberOfPage));
+  ImageRecord = FindImageRecord (DriverEntry->ImageBuffer, 
EfiPagesToSize(DriverEntry->NumberOfPage));
   if (ImageRecord == NULL) {
 DEBUG ((DEBUG_ERROR, "SMM  ImageRecord not found \n"));
 return ;
-- 
2.7.4.windows.1

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

[edk2] [PATCH] MdeModulePkg/PiSmmCore: AllocatePool should use MemoryType.

[Jiewen Yao]

PiSmmCore supports page level protection based upon the Memory Type
(EfiRuntimeServicesCode/EfiRuntimeServicesData) and PE image.

However, the Memory Type information is ignored in AllocatePool().
If a caller calls AllocatePool with EfiRuntimeServicesCode,
the final memory is still allocated as EfiRuntimeServicesData.

This patch supports AllocatePool with EfiRuntimeServicesCode.

Cc: Jeff Fan 
Cc: Michael D Kinney 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
---
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.h  |  13 ++-
 MdeModulePkg/Core/PiSmmCore/Pool.c   |  66 +---
 MdeModulePkg/Core/PiSmmCore/SmramProfileRecord.c | 114 +++-
 3 files changed, 124 insertions(+), 69 deletions(-)

diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h 
b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
index e2fee54..8df1e50 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
@@ -1109,8 +1109,9 @@ extern LIST_ENTRY  mSmmMemoryMap;
 #define MAX_POOL_INDEX  (MAX_POOL_SHIFT - MIN_POOL_SHIFT + 1)
 
 typedef struct {
-  UINTNSize;
-  BOOLEAN  Available;
+  UINTN   Size;
+  BOOLEAN Available;
+  EFI_MEMORY_TYPE Type;
 } POOL_HEADER;
 
 typedef struct {
@@ -1118,6 +1119,12 @@ typedef struct {
   LIST_ENTRY   Link;
 } FREE_POOL_HEADER;
 
-extern LIST_ENTRY  mSmmPoolLists[MAX_POOL_INDEX];
+typedef enum {
+  SmmPoolTypeCode,
+  SmmPoolTypeData,
+  SmmPoolTypeMax,
+} SMM_POOL_TYPE;
+
+extern LIST_ENTRY  mSmmPoolLists[SmmPoolTypeMax][MAX_POOL_INDEX];
 
 #endif
diff --git a/MdeModulePkg/Core/PiSmmCore/Pool.c 
b/MdeModulePkg/Core/PiSmmCore/Pool.c
index dcfd13e..6fb426c 100644
--- a/MdeModulePkg/Core/PiSmmCore/Pool.c
+++ b/MdeModulePkg/Core/PiSmmCore/Pool.c
@@ -14,7 +14,7 @@
 
 #include "PiSmmCore.h"
 
-LIST_ENTRY  mSmmPoolLists[MAX_POOL_INDEX];
+LIST_ENTRY  mSmmPoolLists[SmmPoolTypeMax][MAX_POOL_INDEX];
 //
 // To cache the SMRAM base since when Loading modules At fixed address feature 
is enabled, 
 // all module is assigned an offset relative the SMRAM base in build time.
@@ -22,6 +22,30 @@ LIST_ENTRY  mSmmPoolLists[MAX_POOL_INDEX];
 GLOBAL_REMOVE_IF_UNREFERENCED  EFI_PHYSICAL_ADDRESS   
gLoadModuleAtFixAddressSmramBase = 0;
 
 /**
+  Convert a UEFI memory type to SMM pool type.
+
+  @param[in]  PoolType  Type of pool to allocate.
+
+  @return SMM pool type
+**/
+SMM_POOL_TYPE
+UefiMemoryTypeToSmmPoolType (
+  IN  EFI_MEMORY_TYPE   MemoryType
+  )
+{
+  ASSERT ((MemoryType == EfiRuntimeServicesCode) || (MemoryType == 
EfiRuntimeServicesData));
+  switch (MemoryType) {
+  case EfiRuntimeServicesCode:
+return SmmPoolTypeCode;
+  case EfiRuntimeServicesData:
+return SmmPoolTypeData;
+  default:
+return SmmPoolTypeMax;
+  }
+}
+
+
+/**
   Called to initialize the memory service.
 
   @param   SmramRangeCount   Number of SMRAM Regions
@@ -35,15 +59,18 @@ SmmInitializeMemoryServices (
   )
 {
   UINTN  Index;
-   UINT64 SmmCodeSize;
-   UINTN  CurrentSmramRangesIndex;
-   UINT64 MaxSize;
+  UINT64 SmmCodeSize;
+  UINTN  CurrentSmramRangesIndex;
+  UINT64 MaxSize;
+  UINTN  SmmPoolTypeIndex;
 
   //
   // Initialize Pool list
   //
-  for (Index = ARRAY_SIZE (mSmmPoolLists); Index > 0;) {
-InitializeListHead ([--Index]);
+  for (SmmPoolTypeIndex = 0; SmmPoolTypeIndex < SmmPoolTypeMax; 
SmmPoolTypeIndex++) {
+for (Index = 0; Index < ARRAY_SIZE (mSmmPoolLists[SmmPoolTypeIndex]); 
Index++) {
+  InitializeListHead ([SmmPoolTypeIndex][Index]);
+}
   }
   CurrentSmramRangesIndex = 0;
   //
@@ -117,6 +144,7 @@ SmmInitializeMemoryServices (
 /**
   Internal Function. Allocate a pool by specified PoolIndex.
 
+  @param  PoolType  Type of pool to allocate.
   @param  PoolIndex Index which indicate the Pool size.
   @param  FreePoolHdr   The returned Free pool.
 
@@ -126,6 +154,7 @@ SmmInitializeMemoryServices (
 **/
 EFI_STATUS
 InternalAllocPoolByIndex (
+  IN  EFI_MEMORY_TYPE   PoolType,
   IN  UINTN PoolIndex,
   OUT FREE_POOL_HEADER  **FreePoolHdr
   )
@@ -133,25 +162,29 @@ InternalAllocPoolByIndex (
   EFI_STATUSStatus;
   FREE_POOL_HEADER  *Hdr;
   EFI_PHYSICAL_ADDRESS  Address;
+  SMM_POOL_TYPE SmmPoolType;
+
+  SmmPoolType = UefiMemoryTypeToSmmPoolType(PoolType);
 
   ASSERT (PoolIndex <= MAX_POOL_INDEX);
   Status = EFI_SUCCESS;
   Hdr = NULL;
   if (PoolIndex == MAX_POOL_INDEX) {
-Status = SmmInternalAllocatePages (AllocateAnyPages, 
EfiRuntimeServicesData, EFI_SIZE_TO_PAGES (MAX_POOL_SIZE << 1), );
+Status = SmmInternalAllocatePages (AllocateAnyPages, PoolType, 
EFI_SIZE_TO_PAGES (MAX_POOL_SIZE << 1), );
 if (EFI_ERROR (Status)) {