Re: [edk2] [PATCH 26/26] Revert "MdePkg: avoid __builtin_unreachable() on GCC v4.4"

[Marvin Häuser]

> -Original Message-
> From: Laszlo Ersek 
> Sent: Thursday, January 3, 2019 3:48 AM
> To: edk2-devel-01 
> Cc: Ard Biesheuvel ; Liming Gao
> ; Marvin Haeuser ;
> Michael D Kinney 
> Subject: [PATCH 26/26] Revert "MdePkg: avoid __builtin_unreachable() on
> GCC v4.4"
> 
> This reverts commit 357cec385d4f ("MdePkg: avoid __builtin_unreachable()
> on GCC v4.4", 2016-07-21).
> 
> We've removed BaseTools support for GCC44..GCC47, therefore we need
> not catch the GCC44 corner case for __builtin_unreachable().
> 
> No GCC44..GCC47 references remain under MdePkg after this patch.
> 
> Cc: Ard Biesheuvel 
> Cc: Liming Gao 
> Cc: Marvin Haeuser 

Reviewed-by: Marvin Haeuser 

> Cc: Michael D Kinney 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1377
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> I build-tested this change by building ArmVirtQemu with the GCC5
> toolchain (gcc-6.1.1), and OVMF with the GCC48 toolchain (gcc-4.8.5).
> 
> Namely, the PeiCore() function
> [MdeModulePkg/Core/Pei/PeiMain/PeiMain.c]
> and the DxeMain() function
> [MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c]
> use UNREACHABLE().
> 
>  MdePkg/Include/Base.h | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h index
> bc877d8125a5..d6b04baeaf8b 100644
> --- a/MdePkg/Include/Base.h
> +++ b/MdePkg/Include/Base.h
> @@ -112,11 +112,10 @@ VERIFY_SIZE_OF (__VERIFY_UINT32_ENUM_SIZE,
> 4);  // warnings.
>  //
>  #ifndef UNREACHABLE
> -  #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 4)
> +  #ifdef __GNUC__
>  ///
>  /// Signal compilers and analyzers that this call is not reachable.  It 
> is
>  /// up to the compiler to remove any code past that point.
> -/// Not implemented by GCC 4.4 or earlier.
>  ///
>  #define UNREACHABLE()  __builtin_unreachable ()
>#elif defined (__has_feature)
> --
> 2.19.1.3.g30247aa5d201

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

[edk2] [PATCH 1/2] MdePkg/UefiDebugLibConOut: Pass the correct buffer size.

[Marvin Häuser]

The second argument of "UnicodeVSPrintAsciiFormat" is "BufferSize",
which takes the size of the buffer in bytes. Replace the currently
used MAX_DEBUG_MESSAGE_LENGTH reference, which is the buffer's length,
with the actual buffer size.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Library/UefiDebugLibConOut/DebugLib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdePkg/Library/UefiDebugLibConOut/DebugLib.c 
b/MdePkg/Library/UefiDebugLibConOut/DebugLib.c
index f04207c93fe8..5aaf106762ea 100644
--- a/MdePkg/Library/UefiDebugLibConOut/DebugLib.c
+++ b/MdePkg/Library/UefiDebugLibConOut/DebugLib.c
@@ -69,7 +69,7 @@ DebugPrint (
   // Convert the DEBUG() message to a Unicode String
   //
   VA_START (Marker, Format);
-  UnicodeVSPrintAsciiFormat (Buffer, MAX_DEBUG_MESSAGE_LENGTH,  Format, 
Marker);
+  UnicodeVSPrintAsciiFormat (Buffer, sizeof (Buffer),  Format, Marker);
   VA_END (Marker);
 
 
-- 
2.19.1.windows.1

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

[edk2] [PATCH 2/2] MdePkg/UefiDebugLibStdErr: Pass the correct buffer size.

[Marvin Häuser]

The second argument of "UnicodeVSPrintAsciiFormat" is "BufferSize",
which takes the size of the buffer in bytes. Replace the currently
used MAX_DEBUG_MESSAGE_LENGTH reference, which is the buffer's length,
with the actual buffer size.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Library/UefiDebugLibStdErr/DebugLib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdePkg/Library/UefiDebugLibStdErr/DebugLib.c 
b/MdePkg/Library/UefiDebugLibStdErr/DebugLib.c
index 6830a3caa1fe..837fb49b3a21 100644
--- a/MdePkg/Library/UefiDebugLibStdErr/DebugLib.c
+++ b/MdePkg/Library/UefiDebugLibStdErr/DebugLib.c
@@ -71,7 +71,7 @@ DebugPrint (
   // Convert the DEBUG() message to a Unicode String
   //
   VA_START (Marker, Format);
-  UnicodeVSPrintAsciiFormat (Buffer, MAX_DEBUG_MESSAGE_LENGTH, Format, Marker);
+  UnicodeVSPrintAsciiFormat (Buffer, sizeof (Buffer), Format, Marker);
   VA_END (Marker);
 
   //
-- 
2.19.1.windows.1

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

[edk2] [PATCH 1/1] MdePkg/Base.h: Implement BASE_CR() via OFFSET_OF().

[Marvin Häuser]

Replace the current NULL pointer dereference to retrieve Field's
offset with a call to OFFSET_OF().  This is implemented via
__builtin_offsetof for GCC and Clang, which eliminates UB caught by
Clang UndefinedBehaviorSanitizer.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Include/Base.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
index 523192fd79fc..bc877d8125a5 100644
--- a/MdePkg/Include/Base.h
+++ b/MdePkg/Include/Base.h
@@ -869,7 +869,7 @@ typedef UINTN  *BASE_LIST;
   @return  A pointer to the structure from one of it's elements.
 
 **/
-#define BASE_CR(Record, TYPE, Field)  ((TYPE *) ((CHAR8 *) (Record) - (CHAR8 
*) &(((TYPE *) 0)->Field)))
+#define BASE_CR(Record, TYPE, Field)  ((TYPE *) ((CHAR8 *) (Record) - 
OFFSET_OF (TYPE, Field)))
 
 /**
   Rounds a value up to the next boundary using a specified alignment.
-- 
2.19.1.windows.1

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

Re: [edk2] [PATCH 2/2] UefiCpuPkg/PiSmmCpuDxeSmm: Fix ASSERT for success.

[Marvin Häuser]

Hey Eric,

I discovered it by accident, no tool was involved.

Regards,
Marvin

> -Original Message-
> From: Dong, Eric 
> Sent: Tuesday, October 30, 2018 3:30 AM
> To: Marvin Häuser ; edk2-
> de...@lists.01.org
> Cc: ler...@redhat.com
> Subject: RE: [PATCH 2/2] UefiCpuPkg/PiSmmCpuDxeSmm: Fix ASSERT for
> success.
> 
> Hi Marvin,
> 
> Thanks for your contribution. I have reviewed them and pushed to trunk.
> SHA numbers are:
> SHA-1: 4222e8e7e421e9c8d2c2f319a3860dd3332d6255
> SHA-1: 37fba7c2762e114a280e3b361b53ded034aac7e3
> 
> One more question which just curious by me, how you find this issue? by tool
> or code review?
> 
> Thanks,
> Eric
> 
> > -Original Message-
> > From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> > Sent: Sunday, October 28, 2018 4:51 PM
> > To: edk2-devel@lists.01.org
> > Cc: Dong, Eric ; ler...@redhat.com
> > Subject: [PATCH 2/2] UefiCpuPkg/PiSmmCpuDxeSmm: Fix ASSERT for
> > success.
> >
> > Index is initialized to MAX_UINT16 as default failure value, which is
> > what the ASSERT is supposed to test for.  The ASSERT condition however
> > can never return FALSE for INT16 != int, as due to Integer
> > Promotion[1], Index is converted to int, which can never result in -1.
> >
> > Furthermore, Index is used as a for loop index variable inbetween its
> > initialization and the ASSERT, so the value is unconditionally overwritten
> too.
> >
> > Fix the ASSERT check to compare Index to its upper boundary, which it
> > will be equal to if the loop was not broken out of on success.
> >
> > [1] ISO/IEC 9899:2011, 6.5.9.4
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Marvin Haeuser 
> > ---
> >  UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c
> > b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c
> > index b7c3ad31e82c..89b3f2b7257f 100644
> > --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c
> > +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c
> > @@ -110,7 +110,6 @@ GetProtectedModeCS (
> >UINTNGdtEntryCount;
> >UINT16   Index;
> >
> > -  Index = (UINT16) -1;
> >AsmReadGdtr ();
> >GdtEntryCount = (GdtrDesc.Limit + 1) / sizeof
> > (IA32_SEGMENT_DESCRIPTOR);
> >GdtEntry = (IA32_SEGMENT_DESCRIPTOR *) GdtrDesc.Base; @@ -122,7
> > +121,7 @@ GetProtectedModeCS (
> >  }
> >  GdtEntry++;
> >}
> > -  ASSERT (Index != -1);
> > +  ASSERT (Index != GdtEntryCount);
> >return Index * 8;
> >  }
> >
> > --
> > 2.19.1.windows.1

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

[edk2] [PATCH 1/2] UefiCpuPkg/MpInitLib: Fix ASSERT for success.

[Marvin Häuser]

Index is initialized to MAX_UINT16 as default failure value, which
is what the ASSERT is supposed to test for.  The ASSERT condition
however can never return FALSE for INT16 != int, as due to
Integer Promotion[1], Index is converted to int, which can never
result in -1.

Furthermore, Index is used as a for loop index variable inbetween its
initialization and the ASSERT, so the value is unconditionally
overwritten too.

Fix the ASSERT check to compare Index to its upper boundary, which it
will be equal to if the loop was not broken out of on success.

[1] ISO/IEC 9899:2011, 6.5.9.4

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 UefiCpuPkg/Library/MpInitLib/DxeMpLib.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c 
b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
index c17daa0fc0da..b2307cbb618d 100644
--- a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
@@ -236,7 +236,6 @@ GetProtectedModeCS (
   UINTNGdtEntryCount;
   UINT16   Index;
 
-  Index = (UINT16) -1;
   AsmReadGdtr ();
   GdtEntryCount = (GdtrDesc.Limit + 1) / sizeof (IA32_SEGMENT_DESCRIPTOR);
   GdtEntry = (IA32_SEGMENT_DESCRIPTOR *) GdtrDesc.Base;
@@ -248,7 +247,7 @@ GetProtectedModeCS (
 }
 GdtEntry++;
   }
-  ASSERT (Index != -1);
+  ASSERT (Index != GdtEntryCount);
   return Index * 8;
 }
 
-- 
2.19.1.windows.1

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

[edk2] [PATCH 2/2] UefiCpuPkg/PiSmmCpuDxeSmm: Fix ASSERT for success.

[Marvin Häuser]

Index is initialized to MAX_UINT16 as default failure value, which
is what the ASSERT is supposed to test for.  The ASSERT condition
however can never return FALSE for INT16 != int, as due to
Integer Promotion[1], Index is converted to int, which can never
result in -1.

Furthermore, Index is used as a for loop index variable inbetween its
initialization and the ASSERT, so the value is unconditionally
overwritten too.

Fix the ASSERT check to compare Index to its upper boundary, which it
will be equal to if the loop was not broken out of on success.

[1] ISO/IEC 9899:2011, 6.5.9.4

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c
index b7c3ad31e82c..89b3f2b7257f 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c
@@ -110,7 +110,6 @@ GetProtectedModeCS (
   UINTNGdtEntryCount;
   UINT16   Index;
 
-  Index = (UINT16) -1;
   AsmReadGdtr ();
   GdtEntryCount = (GdtrDesc.Limit + 1) / sizeof (IA32_SEGMENT_DESCRIPTOR);
   GdtEntry = (IA32_SEGMENT_DESCRIPTOR *) GdtrDesc.Base;
@@ -122,7 +121,7 @@ GetProtectedModeCS (
 }
 GdtEntry++;
   }
-  ASSERT (Index != -1);
+  ASSERT (Index != GdtEntryCount);
   return Index * 8;
 }
 
-- 
2.19.1.windows.1

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

[edk2] [PATCH 1/1] BaseTools: Update Makefile to exclude deleted file.

[Marvin Häuser]

GenFds/Attributes.py has been deleted in 1ad635b, but was not removed
from the Python Makefile. Remove it for successful compilation on
Windows.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 BaseTools/Source/Python/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/BaseTools/Source/Python/Makefile b/BaseTools/Source/Python/Makefile
index ac99259eb18a..2a80f1cf7fe9 100644
--- a/BaseTools/Source/Python/Makefile
+++ b/BaseTools/Source/Python/Makefile
@@ -114,7 +114,6 @@ 
CMD_BUILD=$(BASE_TOOLS_PATH)\Source\Python\build\BuildReport.py \
 $(BASE_TOOLS_PATH)\Source\Python\Eot\Report.py
 
 CMD_GENFDS=$(BASE_TOOLS_PATH)\Source\Python\GenFds\AprioriSection.py \
-$(BASE_TOOLS_PATH)\Source\Python\GenFds\Attribute.py \
 $(BASE_TOOLS_PATH)\Source\Python\GenFds\Capsule.py \
 $(BASE_TOOLS_PATH)\Source\Python\GenFds\CapsuleData.py \
 $(BASE_TOOLS_PATH)\Source\Python\GenFds\ComponentStatement.py \
-- 
2.19.1.windows.1

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

Re: [edk2] GOP Console Driver

[Marvin Häuser]

boot.efi requires a GOP instance to be present on gST->ConOutHandle, which Mac 
EFI installs via ConSplitter.
I know that Windows UEFI boot is not officially supported for such old models, 
however I'm not aware of the technical reasons - I think Windows should support 
UGA.
Shell is also trial with old Macs, I think I heard a modded EDK Shell 
once worked. As for finding out boot.efi's issues, I would just shim the most 
crucial Boot Services (especially HandleProtocol()) and protocol inputs and 
outputs.

Regards,
Marvin

> -Original Message-
> From: edk2-devel  On Behalf Of Jd Lyons
> Sent: Sunday, August 19, 2018 5:35 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] GOP Console Driver
> 
> 
> 
> > Begin forwarded message:
> >
> > From: Jd Lyons 
> > Subject: GOP Console Driver
> > Date: August 18, 2018 at 11:31:50 PM EDT
> > To: edk2-devel@lists.01.org
> >
> > I’ve been trying to hack together GOP support for Apples EFI 1.1 on my
> Mac Pro3,1. Apple uses a somewhat mix of EFI 1.x and UEFi2.x.
> >
> > I’m able to get the GOP rom for my graphics card to load and link to the
> device, Apple’s firmware takes care of that much, and I have some custom
> code for rEFInd boot loader that makes the graphics card work in graphics
> mode. However I can’t get back to a shell nor can I boot Windows or the Mac
> OS in this mode.
> >
> > I think the trouble with booting the macOS is Apple’s boot.efi can’t get the
> console, Apple has a UGA Console driver but no GOP Console driver in my
> firmware. I tried extracting the Graphics Console Driver from OVMF and it
> does load, but doesn’t link to any devices, even when I try to connect it with
> my device handle, I.E.
> >
> > connect DA 129
> >
> > Returns success, but invoking drivers shows the Graphics Console Driver is
> still not linked to any devices.
> >
> > Can anyone point me in the right direction on how to get a proper GOP
> Console Driver?
> >
> > Thanks,
> > JD
> 
> ___
> 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 v4 3/5] UefiCpuPkg/CpuS3DataDxe: Change Memory Type and address limitation.

[Marvin Häuser]

Comments inline.

Thanks and best regards,
Marvin.

> -Original Message-
> From: Laszlo Ersek 
> Sent: Thursday, August 16, 2018 2:31 PM
> To: Dong, Eric ; Marvin Häuser
> ; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu 
> Subject: Re: [edk2] [Patch v4 3/5] UefiCpuPkg/CpuS3DataDxe: Change
> Memory Type and address limitation.
> 
> On 08/16/18 02:56, Dong, Eric wrote:
> > Hi Marvin & Laszlo,
> >
> > I'm not very clear about the risk to use this function name. I think it is 
> > just
> used in a driver as an internal function, other drivers or libraries can't 
> use it. I
> think we don't need to add internal prefix to all internal functions in 
> drivers,
> maybe need for the libraries, right?  Here we need to add internal prefix just
> because it has similar name with other common API?
> 
> If I understood correctly, there were two points to Marvin's argument:
> 
> - AllocateZeroPages() is the most likely function name that
> "MemoryAllocationLib.h" would add, *if* it ever introduced a function for
> "allocating boot service data pages, plus zeroing them". In that case, it 
> would
> cause a conflict.

Correct

> 
> - Second, because the function is defined in the same translation unit where
> it is called from (and there are no other callers), we can make the function
> STATIC.

Pretty much, but it was tied to the first point. There are many functions that 
could be static but aren't in edk2, so this isn't significant itself. I 
mentioned it due to my personal naming convention to ensure uniqueness.

> 
> Regarding the first concern, I don't think it's a very practical one.
> I'm neutral on the question. My point is only that, if we really want to 
> change
> the name, I think we should do it separately / incrementally.

If it's supposed to be done separately, I don't see a point in fixing it 
either, it can still be fixed if such an API is ever introduced. It was meant 
as a "preventive" suggestion to be included in this series. "Just in case"

> 
> Regarding the second idea, STATIC is a generally good practice, and we
> should do that everywhere we can. But, because I don't want to re-test / re-
> review this series after all this effort, I suggest we do the STATIC thing
> incrementally as well.

+1, but that's not worth an own patch to be honest. I should see whether there 
is some static analyzer that has checks for "can be static" some day.

> 
> Thanks
> Laszlo
> 
> 
> >
> > Thanks,
> > Eric
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> >> Of Laszlo Ersek
> >> Sent: Wednesday, August 15, 2018 11:30 PM
> >> To: Marvin Häuser ;
> >> edk2-devel@lists.01.org; Dong, Eric 
> >> Cc: Ni, Ruiyu 
> >> Subject: Re: [edk2] [Patch v4 3/5] UefiCpuPkg/CpuS3DataDxe: Change
> >> Memory Type and address limitation.
> >>
> >> On 08/15/18 15:12, Marvin Häuser wrote:
> >>> Hey Eric and anyone CC'd,
> >>>
> >>> Are you sure you want to name the function "AllocateZeroPages"? It's
> >>> analogous to "AllocateZeroPool", so I could see it becoming an API
> >>> function at some point, which will conflict with this definition and
> >>> might silently break UefiCpuPkg compilation if not tested before
> >>> upstreaming. I usually make any module's private functions static
> >>> and prefix "Internal" if possible, or, if static cannot be used,
> >>> non-static plus prefix something derived from the module's name to
> >>> achieve uniqueness. If I am not mistaken, this could be made static,
> >>> couldn't it?
> >>
> >> I agree that the function's name is not optimal, primarily because
> >> the
> >> Allocate*Pages() functions tend to take a page count, not a byte count.
> >> However, I didn't want to ask for another version just because of
> >> this; a lot of review (and now testing) has gone into this set, and this is
> just a wart.
> >>
> >> I suggest that -- after the stable tag -- we push v4 as-is; however,
> >> Marvin, please go ahead and file a TianoCore BZ that depends on 959
> >> (i.e. on the BZ currently referenced in patch #5), about fixing up
> >> the function name (and about making it static).
> >>
> >> Note that an "AllocateZeroPages" function exists in
> >> "IntelSiliconPkg/Feature/VTd/IntelVTdDxe/TranslationTable.c" as well.
> >> I guess both functions should be renamed (and likely not to the same
> >> new name, because they have different parameter lists). And, only the
> >> UefiCpuPkg one can be made static however. Either way, both packages
> >> could be covered by the same BZ.
> >
> >
> >>
> >> Thanks
> >> Laszlo
> >> ___
> >> edk2-devel mailing list
> >> edk2-devel@lists.01.org
> >> https://lists.01.org/mailman/listinfo/edk2-devel

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

Re: [edk2] [Patch v4 3/5] UefiCpuPkg/CpuS3DataDxe: Change Memory Type and address limitation.

[Marvin Häuser]

Hey Eric and anyone CC'd,

Are you sure you want to name the function "AllocateZeroPages"? It's analogous 
to "AllocateZeroPool", so I could see it becoming an API function at some 
point, which will conflict with this definition and might silently break 
UefiCpuPkg compilation if not tested before upstreaming. I usually make any 
module's private functions static and prefix "Internal" if possible, or, if 
static cannot be used, non-static plus prefix something derived from the 
module's name to achieve uniqueness. If I am not mistaken, this could be made 
static, couldn't it?

Thanks,
Marvin

> -Original Message-
> From: Eric Dong 
> Sent: Wednesday, August 15, 2018 4:15 AM
> To: edk2-devel@lists.01.org
> Cc: Marvin Häuser ; Fan Jeff
> ; Laszlo Ersek ; Ruiyu Ni
> 
> Subject: [Patch v4 3/5] UefiCpuPkg/CpuS3DataDxe: Change Memory Type
> and address limitation.
> 
> Because CpuS3Data memory will be copy to smram at SmmReadyToLock
> point, the memory type no need to be ACPI NVS type, also the address not
> limit to below 4G.
> 
> This change remove the limit of ACPI NVS memory type and below 4G.
> 
> V4 Changes:
> 1. Create AllocateZeroPages and use it. It's easy to use than gBS-
> >AllocatePages.
> 
> Pass OS boot and resume from S3 test.
> 
> Cc: Marvin Häuser 
> Cc: Fan Jeff 
> Cc: Laszlo Ersek 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong 
> ---
>  UefiCpuPkg/CpuS3DataDxe/CpuS3Data.c  | 34
> +---
>  UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf |  1 +
>  2 files changed, 28 insertions(+), 7 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuS3DataDxe/CpuS3Data.c
> b/UefiCpuPkg/CpuS3DataDxe/CpuS3Data.c
> index dccb406b8d..3e8c8b383c 100644
> --- a/UefiCpuPkg/CpuS3DataDxe/CpuS3Data.c
> +++ b/UefiCpuPkg/CpuS3DataDxe/CpuS3Data.c
> @@ -31,6 +31,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include 
>  #include 
> @@ -81,6 +82,28 @@ AllocateAcpiNvsMemoryBelow4G (
>return Buffer;
>  }
> 
> +/**
> +  Allocate memory and clean it with zero.
> +
> +  @param[in] Size   Size of memory to allocate.
> +
> +  @return   Allocated address for output.
> +
> +**/
> +VOID *
> +AllocateZeroPages (
> +  IN UINTN  Size
> +  )
> +{
> +  VOID  *Buffer;
> +
> +  Buffer = AllocatePages (EFI_SIZE_TO_PAGES (Size));  if (Buffer !=
> + NULL) {
> +ZeroMem (Buffer, Size);
> +  }
> +
> +  return Buffer;
> +}
>  /**
>Callback function executed when the EndOfDxe event group is signaled.
> 
> @@ -171,10 +194,7 @@ CpuS3DataInitialize (
>//
>OldAcpiCpuData = (ACPI_CPU_DATA *) (UINTN) PcdGet64
> (PcdCpuS3DataAddress);
> 
> -  //
> -  // Allocate ACPI NVS memory below 4G memory for use on ACPI S3
> resume.
> -  //
> -  AcpiCpuDataEx = AllocateAcpiNvsMemoryBelow4G (sizeof
> (ACPI_CPU_DATA_EX));
> +  AcpiCpuDataEx = AllocateZeroPages (sizeof (ACPI_CPU_DATA_EX));
>ASSERT (AcpiCpuDataEx != NULL);
>AcpiCpuData = >AcpiCpuData;
> 
> @@ -223,11 +243,11 @@ CpuS3DataInitialize (
>AsmReadIdtr (>IdtrProfile);
> 
>//
> -  // Allocate GDT and IDT in ACPI NVS and copy current GDT and IDT contents
> +  // Allocate GDT and IDT and copy current GDT and IDT contents
>//
>GdtSize = AcpiCpuDataEx->GdtrProfile.Limit + 1;
>IdtSize = AcpiCpuDataEx->IdtrProfile.Limit + 1;
> -  Gdt = AllocateAcpiNvsMemoryBelow4G (GdtSize + IdtSize);
> +  Gdt = AllocateZeroPages (GdtSize + IdtSize);
>ASSERT (Gdt != NULL);
>Idt = (VOID *)((UINTN)Gdt + GdtSize);
>CopyMem (Gdt, (VOID *)AcpiCpuDataEx->GdtrProfile.Base, GdtSize); @@ -
> 243,7 +263,7 @@ CpuS3DataInitialize (
>  // Allocate buffer for empty RegisterTable and PreSmmInitRegisterTable
> for all CPUs
>  //
>  TableSize = 2 * NumberOfCpus * sizeof (CPU_REGISTER_TABLE);
> -RegisterTable = (CPU_REGISTER_TABLE
> *)AllocateAcpiNvsMemoryBelow4G (TableSize);
> +RegisterTable = (CPU_REGISTER_TABLE *)AllocateZeroPages
> + (TableSize);
>  ASSERT (RegisterTable != NULL);
> 
>  for (Index = 0; Index < NumberOfCpus; Index++) { diff --git
> a/UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf
> b/UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf
> index 480c98ebcd..c16731529c 100644
> --- a/UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf
> +++ b/UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf
> @@ -51,6 +51,7 @@
>DebugLib
>BaseLib
>MtrrLib
> +  MemoryAllocationLib
> 
>  [Guids]
>gEfiEndOfDxeEventGroupGuid ## CONSUMES   ## Event
> --
> 2.15.0.windows.1

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

Re: [edk2] [PATCH 7/8] OvmfPkg/SmmAccessPei: Update MM PPI usages.

[Marvin Häuser]

Hey Laszlo,

> -Original Message-
> From: Laszlo Ersek 
> Sent: Tuesday, July 24, 2018 11:20 AM
> To: Marvin Häuser ; edk2-
> de...@lists.01.org
> Cc: michael.d.kin...@intel.com; liming@intel.com;
> star.z...@intel.com; eric.d...@intel.com; ruiyu...@intel.com;
> kelly.ste...@intel.com; jordan.l.jus...@intel.com;
> ard.biesheu...@linaro.org
> Subject: Re: [PATCH 7/8] OvmfPkg/SmmAccessPei: Update MM PPI usages.
> 
> Hi Marvin,
> 
> On 07/24/18 03:40, Marvin Häuser wrote:
> > Update all references to the SMM PPIs from MdeModulePkg to rather use
> > MdePkg's MM PPI declarations.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Marvin Haeuser 
> > ---
> >  OvmfPkg/SmmAccess/SmmAccessPei.c   | 90 ++--
> >  OvmfPkg/SmmAccess/SmramInternal.c  |  8 +-
> > OvmfPkg/SmmAccess/SmmAccessPei.inf |  2 +-
> >  3 files changed, 50 insertions(+), 50 deletions(-)
> 
> two comments:
> 
> (1) Please post patch sets using a cover letter message:
> 
> git config format.coverletter true
> git config format.numberedtrue
> git config sendemail.chainreplyto false
> git config sendemail.thread   true
> 
> Otherwise the individual patches in the series will get intermixed with other
> messages / threads on the mailing list (and in people's inboxes), if the
> recipient uses a threaded view in their MUA (which most people should do --
> patches and discussions are very hard to follow otherwise).

Is V2 fine in this aspect? Outlook has never threaded multiple parts of a patch 
series for me but only replies to their original message, hence I did not 
notice something was off.

> 
> (2) More specifically, I disagree with this patch. I don't see what's wrong 
> with
> calling SMM "SMM" on x86 (or with calling SMI "SMI"). I understand that the
> PI spec now calls those things MM and MMI, and I tend to agree that new
> code (especially ARM/AARCH64 code) should use these more generic terms
> from the most recent PI spec releases. But, this is not new code, and it is 
> for
> x86; I don't see why we should forcefully drag it forward. I don't think the
> edk2 headers plan to remove the original / traditional names.
> 
> (Just the other day, I learned that EFI_FILE_HANDLE was basically a typedef
> for "pointer to EFI_FILE_PROTOCOL" -- it's a non-standard type, yet it's
> defined in "MdePkg/Include/Protocol/SimpleFileSystem.h", and it's used in
> e.g.
> - MdeModulePkg/Library/BootMaintenanceManagerUiLib
> - MdeModulePkg/Library/FileExplorerLib
> - MdeModulePkg/Universal/Disk/RamDiskDxe
> - MdeModulePkg/Universal/EbcDxe
> - MdePkg/Library/DxeServicesLib
> - MdePkg/Library/UefiFileHandleLib
> - NetworkPkg/TlsAuthConfigDxe
> - SecurityPkg/VariableAuthenticated/SecureBootConfigDxe
> 
> Should we use EFI_FILE_HANDLE in new code we write? No, we shouldn't.
> Should we embark on a journey to eradicate EFI_FILE_HANDLE? I would
> disagree with that idea too.)
> 
> Obviously I'm not arguing against migrating other packages to the new
> names, if their respective maintainers like the idea. I don't think it's 
> useful for
> OvmfPkg though.
> 
> Thanks
> Laszlo
> 
> > diff --git a/OvmfPkg/SmmAccess/SmmAccessPei.c
> > b/OvmfPkg/SmmAccess/SmmAccessPei.c
> > index 21119f80eefa..340122d6a598 100644
> > --- a/OvmfPkg/SmmAccess/SmmAccessPei.c
> > +++ b/OvmfPkg/SmmAccess/SmmAccessPei.c
> > @@ -3,7 +3,7 @@
> >A PEIM with the following responsibilities:
> >
> >- verify & configure the Q35 TSEG in the entry point,
> > -  - provide SMRAM access by producing PEI_SMM_ACCESS_PPI,
> > +  - provide MMRAM access by producing EFI_PEI_MM_ACCESS_PPI,
> >- set aside the SMM_S3_RESUME_STATE object at the bottom of TSEG,
> and expose
> >  it via the gEfiAcpiVariableGuid GUID HOB.
> >
> > @@ -32,28 +32,28 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> > +#include 
> >
> >  #include 
> >
> >  #include "SmramInternal.h"
> >
> >  //
> > -// PEI_SMM_ACCESS_PPI implementation.
> > +// EFI_PEI_MM_ACCESS_PPI implementation.
> >  //
> >
> >  /**
> > -  Opens the SMRAM area to be accessible by a PEIM driver.
> > +  Opens the MMRAM area to be accessible by a PEIM driver.
> >
> > -  This function "opens" SMRAM so that it is visible while not inside of 
> > SMM.
> > +  This function "opens" MMRAM so that it is visible while not inside of
> MM.
> >The function should return EFI_UNSUPPORTED if the hardware does not
> > sup

[edk2] [PATCH v2 2/2] MdeModulePkg: Change SMM PPIs to shim MM PPIs.

[Marvin Häuser]

The new PI MM PPIs deprecate MdeModulePkg's SMM PPIs entirely.
Shim the MM headers onto the previous SMM definitions.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdeModulePkg/Include/Ppi/SmmAccess.h| 114 +---
 MdeModulePkg/Include/Ppi/SmmCommunication.h |  36 +--
 MdeModulePkg/Include/Ppi/SmmControl.h   |  65 +--
 3 files changed, 9 insertions(+), 206 deletions(-)

diff --git a/MdeModulePkg/Include/Ppi/SmmAccess.h 
b/MdeModulePkg/Include/Ppi/SmmAccess.h
index 795c8815a9c1..e1f144ee2293 100644
--- a/MdeModulePkg/Include/Ppi/SmmAccess.h
+++ b/MdeModulePkg/Include/Ppi/SmmAccess.h
@@ -27,119 +27,11 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #ifndef _SMM_ACCESS_PPI_H_
 #define _SMM_ACCESS_PPI_H_
 
-#define PEI_SMM_ACCESS_PPI_GUID \
-  { 0x268f33a9, 0xcccd, 0x48be, { 0x88, 0x17, 0x86, 0x5, 0x3a, 0xc3, 0x2e, 
0xd6 }}
+#include 
 
-typedef struct _PEI_SMM_ACCESS_PPI  PEI_SMM_ACCESS_PPI;
+#define PEI_SMM_ACCESS_PPI_GUID  EFI_PEI_MM_ACCESS_PPI_GUID
 
-/**
-  Opens the SMRAM area to be accessible by a PEIM driver.
-
-  This function "opens" SMRAM so that it is visible while not inside of SMM. 
The function should
-  return EFI_UNSUPPORTED if the hardware does not support hiding of SMRAM. The 
function
-  should return EFI_DEVICE_ERROR if the SMRAM configuration is locked.
-
-  @param  PeiServicesGeneral purpose services available to every 
PEIM.
-  @param  This   The pointer to the SMM Access Interface.
-  @param  DescriptorIndexThe region of SMRAM to Open.
-
-  @retval EFI_SUCCESSThe region was successfully opened.
-  @retval EFI_DEVICE_ERROR   The region could not be opened because locked 
by chipset.
-  @retval EFI_INVALID_PARAMETER  The descriptor index was out of bounds.
-
-**/
-typedef
-EFI_STATUS
-(EFIAPI *PEI_SMM_OPEN)(
-  IN EFI_PEI_SERVICES**PeiServices,
-  IN PEI_SMM_ACCESS_PPI  *This,
-  IN UINTN   DescriptorIndex
-  );
-
-/**
-  Inhibits access to the SMRAM.
-
-  This function "closes" SMRAM so that it is not visible while outside of SMM. 
The function should
-  return EFI_UNSUPPORTED if the hardware does not support hiding of SMRAM.
-
-  @param  PeiServices  General purpose services available to every 
PEIM.
-  @param  This The pointer to the SMM Access Interface.
-  @param  DescriptorIndex  The region of SMRAM to Close.
-
-  @retval EFI_SUCCESS  The region was successfully closed.
-  @retval EFI_DEVICE_ERROR The region could not be closed because 
locked by chipset.
-  @retval EFI_INVALID_PARAMETERThe descriptor index was out of bounds.
-
-**/
-typedef
-EFI_STATUS
-(EFIAPI *PEI_SMM_CLOSE)(
-  IN EFI_PEI_SERVICES**PeiServices,
-  IN PEI_SMM_ACCESS_PPI  *This,
-  IN UINTN   DescriptorIndex
-  );
-
-/**
-  Inhibits access to the SMRAM.
-
-  This function prohibits access to the SMRAM region.  This function is 
usually implemented such
-  that it is a write-once operation.
-
-  @param  PeiServices  General purpose services available to every 
PEIM.
-  @param  This The pointer to the SMM Access Interface.
-  @param  DescriptorIndex  The region of SMRAM to Close.
-
-  @retval EFI_SUCCESSThe region was successfully locked.
-  @retval EFI_DEVICE_ERROR   The region could not be locked because at 
least
- one range is still open.
-  @retval EFI_INVALID_PARAMETER  The descriptor index was out of bounds.
-
-**/
-typedef
-EFI_STATUS
-(EFIAPI *PEI_SMM_LOCK)(
-  IN EFI_PEI_SERVICES**PeiServices,
-  IN PEI_SMM_ACCESS_PPI  *This,
-  IN UINTN   DescriptorIndex
-  );
-
-/**
-  Queries the memory controller for the possible regions that will support 
SMRAM.
-
-  @param  PeiServices   General purpose services available to every 
PEIM.
-  @param This   The pointer to the SmmAccessPpi Interface.
-  @param SmramMapSize   The pointer to the variable containing size of 
the
-buffer to contain the description information.
-  @param SmramMap   The buffer containing the data describing the 
Smram
-region descriptors.
-
-  @retval EFI_BUFFER_TOO_SMALL  The user did not provide a sufficient buffer.
-  @retval EFI_SUCCESS   The user provided a sufficiently-sized buffer.
-
-**/
-typedef
-EFI_STATUS
-(EFIAPI *PEI_SMM_CAPABILITIES)(
-  IN EFI_PEI_SERVICES**PeiServices,
-  IN PEI_SMM_ACCESS_PPI  *This,
-  IN OUT UINTN   *SmramMapSize,
-  IN OUT EFI_SMRAM_DESCRIPTOR*SmramMap
-  );
-
-///
-///  EFI SMM Access PPI is used to control the visibility of the SMRAM on the 
platform.
-///  It 

[edk2] [PATCH v2 0/2] Introduce UEFI PI 1.5 MM PPI.

[Marvin Häuser]

This patch series adds the MM PPIs introduced with the UEFI PI 1.5
specification and in consequence changes the previous MdeModulePkg
SMM PPIs to shim these.

Marvin Haeuser (2):
  MdePkg: Add PI 1.5 MM PPI declarations.
  MdeModulePkg: Change SMM PPIs to shim MM PPIs.

 MdeModulePkg/Include/Ppi/SmmAccess.h  | 114 +-
 MdeModulePkg/Include/Ppi/SmmCommunication.h   |  36 +-
 MdeModulePkg/Include/Ppi/SmmControl.h |  65 +-
 .../Include/Ppi/MmAccess.h|  92 +++---
 .../Include/Ppi/MmCommunication.h |  36 +++---
 MdePkg/Include/Ppi/MmConfiguration.h  |  86 +
 .../Include/Ppi/MmControl.h   |  50 
 MdePkg/MdePkg.dec |  12 ++
 8 files changed, 196 insertions(+), 295 deletions(-)
 copy MdeModulePkg/Include/Ppi/SmmAccess.h => MdePkg/Include/Ppi/MmAccess.h 
(58%)
 copy MdeModulePkg/Include/Ppi/SmmCommunication.h => 
MdePkg/Include/Ppi/MmCommunication.h (58%)
 create mode 100644 MdePkg/Include/Ppi/MmConfiguration.h
 copy MdeModulePkg/Include/Ppi/SmmControl.h => MdePkg/Include/Ppi/MmControl.h 
(65%)

-- 
2.18.0.windows.1

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

[edk2] [PATCH v2 1/2] MdePkg: Add PI 1.5 MM PPI declarations.

[Marvin Häuser]

Add the declarations for the MM PPIs introduced in PI 1.5.
MmAccess, MmCommunication and MmControl are directly derieved from
their Smm* counterparts in MdeModulePkg.
MmConfiguration is directly derieved from the MmConfiguration
Protocol declaration.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Include/Ppi/MmAccess.h| 146 
 MdePkg/Include/Ppi/MmCommunication.h |  64 +
 MdePkg/Include/Ppi/MmConfiguration.h |  86 
 MdePkg/Include/Ppi/MmControl.h   |  96 +
 MdePkg/MdePkg.dec|  12 ++
 5 files changed, 404 insertions(+)

diff --git a/MdePkg/Include/Ppi/MmAccess.h b/MdePkg/Include/Ppi/MmAccess.h
new file mode 100644
index ..b1a751aff42c
--- /dev/null
+++ b/MdePkg/Include/Ppi/MmAccess.h
@@ -0,0 +1,146 @@
+/** @file
+  EFI MM Access PPI definition.
+
+  This PPI is used to control the visibility of the MMRAM on the platform.
+  It abstracts the location and characteristics of MMRAM.  The expectation is
+  that the north bridge or memory controller would publish this PPI.
+
+  The principal functionality found in the memory controller includes the 
following:
+  - Exposing the MMRAM to all non-MM agents, or the "open" state
+  - Shrouding the MMRAM to all but the MM agents, or the "closed" state
+  - Preserving the system integrity, or "locking" the MMRAM, such that the 
settings cannot be
+perturbed by either boot service or runtime agents
+
+Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+
+This program and the accompanying materials
+are licensed and made available under the terms and conditions
+of the BSD License which accompanies this distribution.  The
+full text of the license may be found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef _MM_ACCESS_PPI_H_
+#define _MM_ACCESS_PPI_H_
+
+#define EFI_PEI_MM_ACCESS_PPI_GUID \
+  { 0x268f33a9, 0xcccd, 0x48be, { 0x88, 0x17, 0x86, 0x5, 0x3a, 0xc3, 0x2e, 
0xd6 }}
+
+typedef struct _EFI_PEI_MM_ACCESS_PPI  EFI_PEI_MM_ACCESS_PPI;
+
+/**
+  Opens the MMRAM area to be accessible by a PEIM driver.
+
+  This function "opens" MMRAM so that it is visible while not inside of MM. 
The function should
+  return EFI_UNSUPPORTED if the hardware does not support hiding of MMRAM. The 
function
+  should return EFI_DEVICE_ERROR if the MMRAM configuration is locked.
+
+  @param  PeiServicesGeneral purpose services available to every 
PEIM.
+  @param  This   The pointer to the MM Access Interface.
+  @param  DescriptorIndexThe region of MMRAM to Open.
+
+  @retval EFI_SUCCESSThe region was successfully opened.
+  @retval EFI_DEVICE_ERROR   The region could not be opened because locked 
by chipset.
+  @retval EFI_INVALID_PARAMETER  The descriptor index was out of bounds.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_PEI_MM_OPEN)(
+  IN EFI_PEI_SERVICES**PeiServices,
+  IN EFI_PEI_MM_ACCESS_PPI   *This,
+  IN UINTN   DescriptorIndex
+  );
+
+/**
+  Inhibits access to the MMRAM.
+
+  This function "closes" MMRAM so that it is not visible while outside of MM. 
The function should
+  return EFI_UNSUPPORTED if the hardware does not support hiding of MMRAM.
+
+  @param  PeiServices  General purpose services available to every 
PEIM.
+  @param  This The pointer to the MM Access Interface.
+  @param  DescriptorIndex  The region of MMRAM to Close.
+
+  @retval EFI_SUCCESS  The region was successfully closed.
+  @retval EFI_DEVICE_ERROR The region could not be closed because 
locked by chipset.
+  @retval EFI_INVALID_PARAMETERThe descriptor index was out of bounds.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_PEI_MM_CLOSE)(
+  IN EFI_PEI_SERVICES**PeiServices,
+  IN EFI_PEI_MM_ACCESS_PPI   *This,
+  IN UINTN   DescriptorIndex
+  );
+
+/**
+  Inhibits access to the MMRAM.
+
+  This function prohibits access to the MMRAM region.  This function is 
usually implemented such
+  that it is a write-once operation.
+
+  @param  PeiServices  General purpose services available to every 
PEIM.
+  @param  This The pointer to the MM Access Interface.
+  @param  DescriptorIndex  The region of MMRAM to Close.
+
+  @retval EFI_SUCCESSThe region was successfully locked.
+  @retval EFI_DEVICE_ERROR   The region could not be locked because at 
least
+ one range is still open.
+  @retval EFI_INVALID_PARAMETER  The descriptor index was out of bounds.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_PEI_MM_LOCK)(
+  IN EFI_PEI_SERVICES**PeiServices,
+  IN EFI_PEI_MM_ACCESS_PPI

[edk2] [PATCH 6/8] QuarkSocPkg/SmmControlPei: Update MM PPI usages.

[Marvin Häuser]

Update all references to the SMM PPIs from MdeModulePkg to rather use
MdePkg's MM PPI declarations.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 QuarkSocPkg/QuarkNorthCluster/Smm/Pei/SmmControlPei/SmmControlPei.c   | 24 
++--
 QuarkSocPkg/QuarkNorthCluster/Smm/Pei/SmmControlPei/SmmControlPei.inf |  2 +-
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git 
a/QuarkSocPkg/QuarkNorthCluster/Smm/Pei/SmmControlPei/SmmControlPei.c 
b/QuarkSocPkg/QuarkNorthCluster/Smm/Pei/SmmControlPei/SmmControlPei.c
index 4d19c8f89b0b..98f83d2ce82b 100644
--- a/QuarkSocPkg/QuarkNorthCluster/Smm/Pei/SmmControlPei/SmmControlPei.c
+++ b/QuarkSocPkg/QuarkNorthCluster/Smm/Pei/SmmControlPei/SmmControlPei.c
@@ -16,7 +16,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 #include 
 
-#include 
+#include 
 
 #include 
 #include 
@@ -34,7 +34,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
   @param  PeiServices Describes the list of possible PEI Services.
   @param  ThisA pointer to an instance of
-  EFI_SMM_CONTROL_PPI
+  EFI_PEI_MM_CONTROL_PPI
   @param  ArgumentBuffer  The argument buffer
   @param  ArgumentBufferSize  The size of the argument buffer
   @param  PeriodicTRUE to indicate a periodical SMI
@@ -48,7 +48,7 @@ EFI_STATUS
 EFIAPI
 PeiActivate (
   IN  EFI_PEI_SERVICES   **PeiServices,
-  IN  PEI_SMM_CONTROL_PPI*This,
+  IN  EFI_PEI_MM_CONTROL_PPI *This,
   IN OUT  INT8   *ArgumentBuffer OPTIONAL,
   IN OUT  UINTN  *ArgumentBufferSize OPTIONAL,
   IN  BOOLEANPeriodic OPTIONAL,
@@ -59,7 +59,7 @@ PeiActivate (
   Clears an SMI.
 
   @param  PeiServices Describes the list of possible PEI Services.
-  @param  ThisPointer to an instance of EFI_SMM_CONTROL_PPI
+  @param  ThisPointer to an instance of EFI_PEI_MM_CONTROL_PPI
   @param  PeriodicTRUE to indicate a periodical SMI
 
   @return Return value from SmmClear()
@@ -69,18 +69,18 @@ EFI_STATUS
 EFIAPI
 PeiDeactivate (
   IN  EFI_PEI_SERVICES**PeiServices,
-  IN  PEI_SMM_CONTROL_PPI *This,
+  IN  EFI_PEI_MM_CONTROL_PPI  *This,
   IN  BOOLEAN Periodic OPTIONAL
   );
 
-PEI_SMM_CONTROL_PPI  mSmmControlPpi = {
+EFI_PEI_MM_CONTROL_PPI  mSmmControlPpi = {
   PeiActivate,
   PeiDeactivate
 };
 
 EFI_PEI_PPI_DESCRIPTOR   mPpiList = {
   (EFI_PEI_PPI_DESCRIPTOR_PPI | EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST),
-  ,
+  ,
   
 };
 
@@ -177,7 +177,7 @@ Returns:
 
   @param  PeiServices Describes the list of possible PEI Services.
   @param  ThisA pointer to an instance of
-  EFI_SMM_CONTROL_PPI
+  EFI_PEI_MM_CONTROL_PPI
   @param  ArgumentBuffer  The argument buffer
   @param  ArgumentBufferSize  The size of the argument buffer
   @param  PeriodicTRUE to indicate a periodical SMI
@@ -191,7 +191,7 @@ EFI_STATUS
 EFIAPI
 PeiActivate (
   IN  EFI_PEI_SERVICES   **PeiServices,
-  IN  PEI_SMM_CONTROL_PPI*This,
+  IN  EFI_PEI_MM_CONTROL_PPI *This,
   IN OUT  INT8   *ArgumentBuffer OPTIONAL,
   IN OUT  UINTN  *ArgumentBufferSize OPTIONAL,
   IN  BOOLEANPeriodic OPTIONAL,
@@ -232,7 +232,7 @@ PeiActivate (
   Clears an SMI.
 
   @param  PeiServices Describes the list of possible PEI Services.
-  @param  ThisPointer to an instance of EFI_SMM_CONTROL_PPI
+  @param  ThisPointer to an instance of EFI_PEI_MM_CONTROL_PPI
   @param  PeriodicTRUE to indicate a periodical SMI
 
   @return Return value from SmmClear()
@@ -242,7 +242,7 @@ EFI_STATUS
 EFIAPI
 PeiDeactivate (
   IN  EFI_PEI_SERVICES**PeiServices,
-  IN  PEI_SMM_CONTROL_PPI *This,
+  IN  EFI_PEI_MM_CONTROL_PPI  *This,
   IN  BOOLEAN Periodic OPTIONAL
   )
 {
@@ -255,7 +255,7 @@ PeiDeactivate (
 /**
   This is the constructor for the SMM Control Ppi.
 
-  This function installs EFI_SMM_CONTROL_PPI.
+  This function installs EFI_PEI_MM_CONTROL_PPI.
 
   @param   FileHandle   Handle of the file being invoked.
   @param   PeiServices  Describes the list of possible PEI Services.
diff --git 
a/QuarkSocPkg/QuarkNorthCluster/Smm/Pei/SmmControlPei/SmmControlPei.inf 
b/QuarkSocPkg/QuarkNorthCluster/Smm/Pei/SmmControlPei/SmmControlPei.inf
index 6b1dd1bcfd1c..0a98e5739416 100644
--- a/QuarkSocPkg/QuarkNorthCluster/Smm/Pei/SmmControlPei/SmmControlPei.inf
+++ b/QuarkSocPkg/QuarkNorthCluster/Smm/Pei/SmmControlPei/SmmControlPei.inf
@@ -46,7 +46,7 @@ [LibraryClasses]
   QNCAccessLib
 
 [Ppis]
-  gPeiSmmControlPpiGuid   

[edk2] [PATCH 8/8] MdeModulePkg: Deprecate Smm* PPIs.

[Marvin Häuser]

MdeModulePkg's Smm* PPIs have been deprecated entirely by UEFI PI
PPIs. Do not allow their usage when DISABLE_NEW_DEPRECATED_INTERFACES
is defined.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdeModulePkg/Include/Ppi/SmmAccess.h| 4 
 MdeModulePkg/Include/Ppi/SmmCommunication.h | 4 
 MdeModulePkg/Include/Ppi/SmmControl.h   | 4 
 3 files changed, 12 insertions(+)

diff --git a/MdeModulePkg/Include/Ppi/SmmAccess.h 
b/MdeModulePkg/Include/Ppi/SmmAccess.h
index 795c8815a9c1..0ca6d0e3af22 100644
--- a/MdeModulePkg/Include/Ppi/SmmAccess.h
+++ b/MdeModulePkg/Include/Ppi/SmmAccess.h
@@ -24,6 +24,8 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 **/
 
+#ifndef DISABLE_NEW_DEPRECATED_INTERFACES
+
 #ifndef _SMM_ACCESS_PPI_H_
 #define _SMM_ACCESS_PPI_H_
 
@@ -144,3 +146,5 @@ struct _PEI_SMM_ACCESS_PPI {
 extern EFI_GUID gPeiSmmAccessPpiGuid;
 
 #endif
+
+#endif
diff --git a/MdeModulePkg/Include/Ppi/SmmCommunication.h 
b/MdeModulePkg/Include/Ppi/SmmCommunication.h
index 8ac86a443a15..7f24d851ae09 100644
--- a/MdeModulePkg/Include/Ppi/SmmCommunication.h
+++ b/MdeModulePkg/Include/Ppi/SmmCommunication.h
@@ -19,6 +19,8 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 **/
 
+#ifndef DISABLE_NEW_DEPRECATED_INTERFACES
+
 
 #ifndef _SMM_COMMUNICATION_PPI_H_
 #define _SMM_COMMUNICATION_PPI_H_
@@ -62,3 +64,5 @@ struct _EFI_PEI_SMM_COMMUNICATION_PPI {
 extern EFI_GUID gEfiPeiSmmCommunicationPpiGuid;
 
 #endif
+
+#endif
diff --git a/MdeModulePkg/Include/Ppi/SmmControl.h 
b/MdeModulePkg/Include/Ppi/SmmControl.h
index 0c62196fb44c..597a6db07f2c 100644
--- a/MdeModulePkg/Include/Ppi/SmmControl.h
+++ b/MdeModulePkg/Include/Ppi/SmmControl.h
@@ -22,6 +22,8 @@
 
 **/
 
+#ifndef DISABLE_NEW_DEPRECATED_INTERFACES
+
 
 #ifndef _SMM_CONTROL_PPI_H_
 #define _SMM_CONTROL_PPI_H_
@@ -94,3 +96,5 @@ struct _PEI_SMM_CONTROL_PPI {
 extern EFI_GUID gPeiSmmControlPpiGuid;
 
 #endif
+
+#endif
-- 
2.18.0.windows.1

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

[edk2] [PATCH 5/8] QuarkSocPkg/SmmAccessPei: Update MM PPI usages.

[Marvin Häuser]

Update all references to the SMM PPIs from MdeModulePkg to rather use
MdePkg's MM PPI declarations.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 QuarkSocPkg/QuarkNorthCluster/Smm/Pei/SmmAccessPei/SmmAccessPei.c   | 48 
++--
 QuarkSocPkg/QuarkNorthCluster/Smm/Pei/SmmAccessPei/SmmAccessPei.inf |  2 +-
 2 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/QuarkSocPkg/QuarkNorthCluster/Smm/Pei/SmmAccessPei/SmmAccessPei.c 
b/QuarkSocPkg/QuarkNorthCluster/Smm/Pei/SmmAccessPei/SmmAccessPei.c
index 70fdf096117f..6686d87a3fda 100644
--- a/QuarkSocPkg/QuarkNorthCluster/Smm/Pei/SmmAccessPei/SmmAccessPei.c
+++ b/QuarkSocPkg/QuarkNorthCluster/Smm/Pei/SmmAccessPei/SmmAccessPei.c
@@ -14,7 +14,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 **/
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -29,7 +29,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
   CR ( \
   a, \
   SMM_ACCESS_PRIVATE_DATA, \
-  SmmAccess, \
+  MmAccess, \
   SMM_ACCESS_PRIVATE_DATA_SIGNATURE \
   )
 
@@ -39,7 +39,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 typedef struct {
   UINTNSignature;
   EFI_HANDLE   Handle;
-  PEI_SMM_ACCESS_PPI   SmmAccess;
+  EFI_PEI_MM_ACCESS_PPIMmAccess;
   UINTNNumberRegions;
   EFI_SMRAM_DESCRIPTOR SmramDesc[MAX_SMRAM_RANGES];
   UINT8TsegSize;
@@ -55,7 +55,7 @@ EFI_STATUS
 EFIAPI
 Open (
   IN EFI_PEI_SERVICES   **PeiServices,
-  IN PEI_SMM_ACCESS_PPI *This,
+  IN EFI_PEI_MM_ACCESS_PPI  *This,
   IN UINTN  DescriptorIndex
   )
 /*++
@@ -70,7 +70,7 @@ Routine Description:
 Arguments:
 
   PeiServices  - General purpose services available to every PEIM.
-  This -  Pointer to the SMM Access Interface.
+  This -  Pointer to the MM Access Interface.
   DescriptorIndex  -  Region of SMRAM to Open.
 
 Returns:
@@ -102,7 +102,7 @@ Returns:
 
   SmmAccess->SmramDesc[DescriptorIndex].RegionState &= ~(EFI_SMRAM_CLOSED | 
EFI_ALLOCATED);
   SmmAccess->SmramDesc[DescriptorIndex].RegionState |= EFI_SMRAM_OPEN;
-  SmmAccess->SmmAccess.OpenState = TRUE;
+  SmmAccess->MmAccess.OpenState = TRUE;
 
   return EFI_SUCCESS;
 }
@@ -111,7 +111,7 @@ EFI_STATUS
 EFIAPI
 Close (
   IN EFI_PEI_SERVICES**PeiServices,
-  IN PEI_SMM_ACCESS_PPI  *This,
+  IN EFI_PEI_MM_ACCESS_PPI   *This,
   IN UINTN   DescriptorIndex
   )
 /*++
@@ -124,7 +124,7 @@ Routine Description:
 Arguments:
 
   PeiServices  - General purpose services available to every PEIM.
-  This -  Pointer to the SMM Access Interface.
+  This -  Pointer to the MM Access Interface.
   DescriptorIndex  -  Region of SMRAM to Close.
 
 Returns:
@@ -174,7 +174,7 @@ Returns:
 }
   }
 
-  SmmAccess->SmmAccess.OpenState = OpenState;
+  SmmAccess->MmAccess.OpenState = OpenState;
 
   return EFI_SUCCESS;
 }
@@ -183,7 +183,7 @@ EFI_STATUS
 EFIAPI
 Lock (
   IN EFI_PEI_SERVICES  **PeiServices,
-  IN PEI_SMM_ACCESS_PPI*This,
+  IN EFI_PEI_MM_ACCESS_PPI *This,
   IN UINTN DescriptorIndex
   )
 /*++
@@ -198,7 +198,7 @@ Routine Description:
 Arguments:
 
   PeiServices  - General purpose services available to every PEIM.
-  This -  Pointer to the SMM Access Interface.
+  This -  Pointer to the MM Access Interface.
   DescriptorIndex  -  Region of SMRAM to Lock.
 
 Returns:
@@ -216,12 +216,12 @@ Returns:
 
   if (DescriptorIndex >= SmmAccess->NumberRegions) {
 return EFI_INVALID_PARAMETER;
-  } else if (SmmAccess->SmmAccess.OpenState) {
+  } else if (SmmAccess->MmAccess.OpenState) {
 return EFI_DEVICE_ERROR;
   }
 
   SmmAccess->SmramDesc[DescriptorIndex].RegionState |= EFI_SMRAM_LOCKED;
-  SmmAccess->SmmAccess.LockState = TRUE;
+  SmmAccess->MmAccess.LockState = TRUE;
 
   //
   // Lock TSEG
@@ -235,7 +235,7 @@ EFI_STATUS
 EFIAPI
 GetCapabilities (
   IN EFI_PEI_SERVICES**PeiServices,
-  IN PEI_SMM_ACCESS_PPI  *This,
+  IN EFI_PEI_MM_ACCESS_PPI   *This,
   IN OUT UINTN   *SmramMapSize,
   IN OUT EFI_SMRAM_DESCRIPTOR*SmramMap
   )
@@ -293,7 +293,7 @@ SmmAccessPeiEntryPoint (
 
 Routine Description:
 
-This is the constructor for the SMM Access Ppi
+This is the constructor for the MM Access Ppi
 
 Arguments:
 
@@ -354,17 +354,17 @@ Returns:
 SmmAccessPrivate->SmramDesc[Index].RegionState   = 
DescriptorBlock->Descriptor[Index].RegionState;
   }
 
-  SmmAccessPrivate->NumberRegions  = Index;
-  SmmAccessPrivate->SmmAccess.Open = Open;
-  SmmAccessPrivate->SmmAccess.Close= Close;
-  

[edk2] [PATCH 7/8] OvmfPkg/SmmAccessPei: Update MM PPI usages.

[Marvin Häuser]

Update all references to the SMM PPIs from MdeModulePkg to rather use
MdePkg's MM PPI declarations.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 OvmfPkg/SmmAccess/SmmAccessPei.c   | 90 ++--
 OvmfPkg/SmmAccess/SmramInternal.c  |  8 +-
 OvmfPkg/SmmAccess/SmmAccessPei.inf |  2 +-
 3 files changed, 50 insertions(+), 50 deletions(-)

diff --git a/OvmfPkg/SmmAccess/SmmAccessPei.c b/OvmfPkg/SmmAccess/SmmAccessPei.c
index 21119f80eefa..340122d6a598 100644
--- a/OvmfPkg/SmmAccess/SmmAccessPei.c
+++ b/OvmfPkg/SmmAccess/SmmAccessPei.c
@@ -3,7 +3,7 @@
   A PEIM with the following responsibilities:
 
   - verify & configure the Q35 TSEG in the entry point,
-  - provide SMRAM access by producing PEI_SMM_ACCESS_PPI,
+  - provide MMRAM access by producing EFI_PEI_MM_ACCESS_PPI,
   - set aside the SMM_S3_RESUME_STATE object at the bottom of TSEG, and expose
 it via the gEfiAcpiVariableGuid GUID HOB.
 
@@ -32,28 +32,28 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 
 #include "SmramInternal.h"
 
 //
-// PEI_SMM_ACCESS_PPI implementation.
+// EFI_PEI_MM_ACCESS_PPI implementation.
 //
 
 /**
-  Opens the SMRAM area to be accessible by a PEIM driver.
+  Opens the MMRAM area to be accessible by a PEIM driver.
 
-  This function "opens" SMRAM so that it is visible while not inside of SMM.
+  This function "opens" MMRAM so that it is visible while not inside of MM.
   The function should return EFI_UNSUPPORTED if the hardware does not support
-  hiding of SMRAM. The function should return EFI_DEVICE_ERROR if the SMRAM
+  hiding of MMRAM. The function should return EFI_DEVICE_ERROR if the MMRAM
   configuration is locked.
 
   @param  PeiServicesGeneral purpose services available to every
  PEIM.
-  @param  This   The pointer to the SMM Access Interface.
-  @param  DescriptorIndexThe region of SMRAM to Open.
+  @param  This   The pointer to the MM Access Interface.
+  @param  DescriptorIndexThe region of MMRAM to Open.
 
   @retval EFI_SUCCESSThe region was successfully opened.
   @retval EFI_DEVICE_ERROR   The region could not be opened because locked
@@ -64,9 +64,9 @@
 STATIC
 EFI_STATUS
 EFIAPI
-SmmAccessPeiOpen (
+MmAccessPeiOpen (
   IN EFI_PEI_SERVICES**PeiServices,
-  IN PEI_SMM_ACCESS_PPI  *This,
+  IN EFI_PEI_MM_ACCESS_PPI   *This,
   IN UINTN   DescriptorIndex
   )
 {
@@ -82,16 +82,16 @@ SmmAccessPeiOpen (
 }
 
 /**
-  Inhibits access to the SMRAM.
+  Inhibits access to the MMRAM.
 
-  This function "closes" SMRAM so that it is not visible while outside of SMM.
+  This function "closes" MMRAM so that it is not visible while outside of MM.
   The function should return EFI_UNSUPPORTED if the hardware does not support
-  hiding of SMRAM.
+  hiding of MMRAM.
 
   @param  PeiServices  General purpose services available to every
PEIM.
-  @param  This The pointer to the SMM Access Interface.
-  @param  DescriptorIndex  The region of SMRAM to Close.
+  @param  This The pointer to the MM Access Interface.
+  @param  DescriptorIndex  The region of MMRAM to Close.
 
   @retval EFI_SUCCESS  The region was successfully closed.
   @retval EFI_DEVICE_ERROR The region could not be closed because
@@ -102,9 +102,9 @@ SmmAccessPeiOpen (
 STATIC
 EFI_STATUS
 EFIAPI
-SmmAccessPeiClose (
+MmAccessPeiClose (
   IN EFI_PEI_SERVICES**PeiServices,
-  IN PEI_SMM_ACCESS_PPI  *This,
+  IN EFI_PEI_MM_ACCESS_PPI   *This,
   IN UINTN   DescriptorIndex
   )
 {
@@ -120,15 +120,15 @@ SmmAccessPeiClose (
 }
 
 /**
-  Inhibits access to the SMRAM.
+  Inhibits access to the MMRAM.
 
-  This function prohibits access to the SMRAM region.  This function is usually
+  This function prohibits access to the MMRAM region.  This function is usually
   implemented such that it is a write-once operation.
 
   @param  PeiServices  General purpose services available to every
PEIM.
-  @param  This The pointer to the SMM Access Interface.
-  @param  DescriptorIndex  The region of SMRAM to Close.
+  @param  This The pointer to the MM Access Interface.
+  @param  DescriptorIndex  The region of MMRAM to Close.
 
   @retval EFI_SUCCESSThe region was successfully locked.
   @retval EFI_DEVICE_ERROR   The region could not be locked because at
@@ -139,9 +139,9 @@ SmmAccessPeiClose (
 STATIC
 EFI_STATUS
 EFIAPI
-SmmAccessPeiLock (
+MmAccessPeiLock (
   IN EFI_PEI_SERVICES**PeiServices,
-  IN PEI_SMM_ACCESS_PPI  *This,
+  IN EFI_PEI_MM_ACCESS_PPI   *This,
   IN UINTN   

[edk2] [PATCH 4/8] UefiCpuPkg/S3Resume2Pei: Update MM PPI usages.

[Marvin Häuser]

Update all references to the SMM PPIs from MdeModulePkg to rather use
MdePkg's MM PPI declarations.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c   | 40 
++--
 UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf |  4 +-
 2 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c 
b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
index 28e53ac5d334..8039e8cb200e 100644
--- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
+++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
@@ -27,10 +27,10 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 #include 
@@ -340,7 +340,7 @@ SignalToSmmByCommunication (
   )
 {
   EFI_STATUS Status;
-  EFI_PEI_SMM_COMMUNICATION_PPI  *SmmCommunicationPpi;
+  EFI_PEI_MM_COMMUNICATION_PPI   *MmCommunicationPpi;
   UINTN  CommSize;
   SMM_COMMUNICATE_HEADER_32  Header32;
   SMM_COMMUNICATE_HEADER_64  Header64;
@@ -366,23 +366,23 @@ SignalToSmmByCommunication (
   CopyGuid (CommBuffer, HandlerType);
 
   Status = PeiServicesLocatePpi (
- ,
+ ,
  0,
  NULL,
- (VOID **)
+ (VOID **)
  );
   if (EFI_ERROR (Status)) {
 DEBUG ((DEBUG_ERROR, "Locate Smm Communicate Ppi failed (%r)!\n", Status));
 return;
   }
 
-  Status = SmmCommunicationPpi->Communicate (
-  SmmCommunicationPpi,
-  (VOID *)CommBuffer,
-  
-  );
+  Status = MmCommunicationPpi->Communicate (
+ MmCommunicationPpi,
+ (VOID *)CommBuffer,
+ 
+ );
   if (EFI_ERROR (Status)) {
-DEBUG ((DEBUG_ERROR, "SmmCommunicationPpi->Communicate return failure 
(%r)!\n", Status));
+DEBUG ((DEBUG_ERROR, "MmCommunicationPpi->Communicate return failure 
(%r)!\n", Status));
   }
 
   DEBUG ((DEBUG_INFO, "Signal %g to SMM - Exit (%r)\n", HandlerType, Status));
@@ -749,7 +749,7 @@ S3ResumeExecuteBootScript (
   )
 {
   EFI_STATUS Status;
-  PEI_SMM_ACCESS_PPI *SmmAccess;
+  EFI_PEI_MM_ACCESS_PPI  *MmAccess;
   UINTN  Index;
   VOID   *GuidHob;
   IA32_DESCRIPTOR*IdtDescriptor;
@@ -778,22 +778,22 @@ S3ResumeExecuteBootScript (
 SendSmiIpi (GetApicId ());
 
 Status = PeiServicesLocatePpi (
-  ,
+  ,
   0,
   NULL,
-  (VOID **) 
+  (VOID **) 
   );
 if (!EFI_ERROR (Status)) {
   DEBUG ((DEBUG_INFO, "Close all SMRAM regions before executing boot 
script\n"));
 
   for (Index = 0, Status = EFI_SUCCESS; !EFI_ERROR (Status); Index++) {
-Status = SmmAccess->Close ((EFI_PEI_SERVICES 
**)GetPeiServicesTablePointer (), SmmAccess, Index);
+Status = MmAccess->Close ((EFI_PEI_SERVICES 
**)GetPeiServicesTablePointer (), MmAccess, Index);
   }
 
   DEBUG ((DEBUG_INFO, "Lock all SMRAM regions before executing boot 
script\n"));
 
   for (Index = 0, Status = EFI_SUCCESS; !EFI_ERROR (Status); Index++) {
-Status = SmmAccess->Lock ((EFI_PEI_SERVICES 
**)GetPeiServicesTablePointer (), SmmAccess, Index);
+Status = MmAccess->Lock ((EFI_PEI_SERVICES 
**)GetPeiServicesTablePointer (), MmAccess, Index);
   }
 }
 
@@ -954,7 +954,7 @@ S3RestoreConfig2 (
   )
 {
   EFI_STATUSStatus;
-  PEI_SMM_ACCESS_PPI*SmmAccess;
+  EFI_PEI_MM_ACCESS_PPI *MmAccess;
   UINTN Index;
   ACPI_S3_CONTEXT   *AcpiS3Context;
   EFI_PHYSICAL_ADDRESS  
TempEfiBootScriptExecutorVariable;
@@ -1048,13 +1048,13 @@ S3RestoreConfig2 (
   GuidHob = GetFirstGuidHob ();
   if (GuidHob != NULL) {
 Status = PeiServicesLocatePpi (
-  ,
+  ,
   0,
   NULL,
-  (VOID **) 
+  (VOID **) 
   );
 for (Index = 0; !EFI_ERROR (Status); Index++) {
-  Status = SmmAccess->Open ((EFI_PEI_SERVICES 
**)GetPeiServicesTablePointer (), SmmAccess, Index);
+  Status = MmAccess->Open ((EFI_PEI_SERVICES **)GetPeiServicesTablePointer 
(), MmAccess, Index);
 }
 
 SmramDescriptor = (EFI_SMRAM_DESCRIPTOR *) GET_GUID_HOB_DATA (GuidHob);

[edk2] [PATCH 3/8] UefiCpuPkg/PiSmmCommunicationPei: Update MM PPI usages.

[Marvin Häuser]

Update all references to the SMM PPIs from MdeModulePkg to rather use
MdePkg's MM PPI declarations.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.c   | 70 
++--
 UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationSmm.c   |  4 +-
 UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.inf | 10 +--
 UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationSmm.inf |  2 +-
 4 files changed, 43 insertions(+), 43 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.c 
b/UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.c
index aaeaa0672939..5c90f5193185 100644
--- a/UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.c
+++ b/UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.c
@@ -22,9 +22,9 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
 #include 
 
 #include "PiSmmCommunicationPrivate.h"
@@ -113,7 +113,7 @@ typedef EFI_CONFIGURATION_TABLE EFI_CONFIGURATION_TABLE64;
 
   This function provides a service to send and receive messages from a 
registered UEFI service.
 
-  @param[in] ThisThe EFI_PEI_SMM_COMMUNICATION_PPI instance.
+  @param[in] ThisThe EFI_PEI_MM_COMMUNICATION_PPI instance.
   @param[in, out] CommBuffer A pointer to the buffer to convey into SMRAM.
   @param[in, out] CommSize   The size of the data buffer being passed 
in.On exit, the size of data
  being returned. Zero if the handler does not 
wish to reply with any data.
@@ -125,17 +125,17 @@ typedef EFI_CONFIGURATION_TABLE EFI_CONFIGURATION_TABLE64;
 EFI_STATUS
 EFIAPI
 Communicate (
-  IN CONST EFI_PEI_SMM_COMMUNICATION_PPI   *This,
+  IN CONST EFI_PEI_MM_COMMUNICATION_PPI*This,
   IN OUT VOID  *CommBuffer,
   IN OUT UINTN *CommSize
   );
 
-EFI_PEI_SMM_COMMUNICATION_PPI  mSmmCommunicationPpi = { Communicate };
+EFI_PEI_MM_COMMUNICATION_PPI   mMmCommunicationPpi = { Communicate };
 
 EFI_PEI_PPI_DESCRIPTOR mPpiList = {
   (EFI_PEI_PPI_DESCRIPTOR_PPI | EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST),
-  ,
-  
+  ,
+  
 };
 
 /**
@@ -151,7 +151,7 @@ GetCommunicationContext (
   EFI_HOB_GUID_TYPE*GuidHob;
   EFI_SMM_COMMUNICATION_CONTEXT*SmmCommunicationContext;
 
-  GuidHob = GetFirstGuidHob ();
+  GuidHob = GetFirstGuidHob ();
   ASSERT (GuidHob != NULL);
 
   SmmCommunicationContext = (EFI_SMM_COMMUNICATION_CONTEXT *)GET_GUID_HOB_DATA 
(GuidHob);
@@ -174,7 +174,7 @@ SetCommunicationContext (
 
   BufferSize = sizeof (*SmmCommunicationContext);
   Hob.Raw = BuildGuidHob (
-  ,
+  ,
   BufferSize
   );
   ASSERT (Hob.Raw);
@@ -257,7 +257,7 @@ InitCommunicationContext (
   SmmCommunicationContext = (EFI_SMM_COMMUNICATION_CONTEXT 
*)InternalSmstGetVendorTableByGuid (

SmmS3ResumeState->Signature,

(EFI_SMM_SYSTEM_TABLE2 *)(UINTN)SmmS3ResumeState->Smst,
-   

+   

);
   ASSERT (SmmCommunicationContext != NULL);
 
@@ -271,7 +271,7 @@ InitCommunicationContext (
 
   This function provides a service to send and receive messages from a 
registered UEFI service.
 
-  @param[in] ThisThe EFI_PEI_SMM_COMMUNICATION_PPI instance.
+  @param[in] ThisThe EFI_PEI_MM_COMMUNICATION_PPI instance.
   @param[in, out] CommBuffer A pointer to the buffer to convey into SMRAM.
   @param[in, out] CommSize   The size of the data buffer being passed 
in.On exit, the size of data
  being returned. Zero if the handler does not 
wish to reply with any data.
@@ -283,14 +283,14 @@ InitCommunicationContext (
 EFI_STATUS
 EFIAPI
 Communicate (
-  IN CONST EFI_PEI_SMM_COMMUNICATION_PPI   *This,
+  IN CONST EFI_PEI_MM_COMMUNICATION_PPI*This,
   IN OUT VOID  *CommBuffer,
   IN OUT UINTN *CommSize
   )
 {
   EFI_STATUS   Status;
-  PEI_SMM_CONTROL_PPI  *SmmControl;
-  PEI_SMM_ACCESS_PPI   *SmmAccess;
+  EFI_PEI_MM_CONTROL_PPI   *MmControl;
+  EFI_PEI_MM_ACCESS_PPI*MmAccess;
   UINT8SmiCommand;
   UINTNSize;
   EFI_SMM_COMMUNICATION_CONTEXT*SmmCommunicationContext;
@@ -305,20 +305,20 @@ Communicate (
   // Get needed resource
   //
   Status = PeiServicesLocatePpi (
- ,
+ ,
  0,
  NULL,
- (VOID **)
+ 

[edk2] [PATCH 1/8] MdePkg: Add PI 1.5 MM PPI declarations.

[Marvin Häuser]

Add the declarations for the MM PPIs introduced in PI 1.5.
MmAccess, MmCommunication and MmControl are directly derieved from
their Smm* counterparts in MdeModulePkg.
MmConfiguration is directly derieved from the MmConfiguration
Protocol declaration.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Include/Ppi/MmAccess.h| 146 
 MdePkg/Include/Ppi/MmCommunication.h |  64 +
 MdePkg/Include/Ppi/MmConfiguration.h |  86 
 MdePkg/Include/Ppi/MmControl.h   |  96 +
 MdePkg/MdePkg.dec|  12 ++
 5 files changed, 404 insertions(+)

diff --git a/MdePkg/Include/Ppi/MmAccess.h b/MdePkg/Include/Ppi/MmAccess.h
new file mode 100644
index ..b1a751aff42c
--- /dev/null
+++ b/MdePkg/Include/Ppi/MmAccess.h
@@ -0,0 +1,146 @@
+/** @file
+  EFI MM Access PPI definition.
+
+  This PPI is used to control the visibility of the MMRAM on the platform.
+  It abstracts the location and characteristics of MMRAM.  The expectation is
+  that the north bridge or memory controller would publish this PPI.
+
+  The principal functionality found in the memory controller includes the 
following:
+  - Exposing the MMRAM to all non-MM agents, or the "open" state
+  - Shrouding the MMRAM to all but the MM agents, or the "closed" state
+  - Preserving the system integrity, or "locking" the MMRAM, such that the 
settings cannot be
+perturbed by either boot service or runtime agents
+
+Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+
+This program and the accompanying materials
+are licensed and made available under the terms and conditions
+of the BSD License which accompanies this distribution.  The
+full text of the license may be found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef _MM_ACCESS_PPI_H_
+#define _MM_ACCESS_PPI_H_
+
+#define EFI_PEI_MM_ACCESS_PPI_GUID \
+  { 0x268f33a9, 0xcccd, 0x48be, { 0x88, 0x17, 0x86, 0x5, 0x3a, 0xc3, 0x2e, 
0xd6 }}
+
+typedef struct _EFI_PEI_MM_ACCESS_PPI  EFI_PEI_MM_ACCESS_PPI;
+
+/**
+  Opens the MMRAM area to be accessible by a PEIM driver.
+
+  This function "opens" MMRAM so that it is visible while not inside of MM. 
The function should
+  return EFI_UNSUPPORTED if the hardware does not support hiding of MMRAM. The 
function
+  should return EFI_DEVICE_ERROR if the MMRAM configuration is locked.
+
+  @param  PeiServicesGeneral purpose services available to every 
PEIM.
+  @param  This   The pointer to the MM Access Interface.
+  @param  DescriptorIndexThe region of MMRAM to Open.
+
+  @retval EFI_SUCCESSThe region was successfully opened.
+  @retval EFI_DEVICE_ERROR   The region could not be opened because locked 
by chipset.
+  @retval EFI_INVALID_PARAMETER  The descriptor index was out of bounds.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_PEI_MM_OPEN)(
+  IN EFI_PEI_SERVICES**PeiServices,
+  IN EFI_PEI_MM_ACCESS_PPI   *This,
+  IN UINTN   DescriptorIndex
+  );
+
+/**
+  Inhibits access to the MMRAM.
+
+  This function "closes" MMRAM so that it is not visible while outside of MM. 
The function should
+  return EFI_UNSUPPORTED if the hardware does not support hiding of MMRAM.
+
+  @param  PeiServices  General purpose services available to every 
PEIM.
+  @param  This The pointer to the MM Access Interface.
+  @param  DescriptorIndex  The region of MMRAM to Close.
+
+  @retval EFI_SUCCESS  The region was successfully closed.
+  @retval EFI_DEVICE_ERROR The region could not be closed because 
locked by chipset.
+  @retval EFI_INVALID_PARAMETERThe descriptor index was out of bounds.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_PEI_MM_CLOSE)(
+  IN EFI_PEI_SERVICES**PeiServices,
+  IN EFI_PEI_MM_ACCESS_PPI   *This,
+  IN UINTN   DescriptorIndex
+  );
+
+/**
+  Inhibits access to the MMRAM.
+
+  This function prohibits access to the MMRAM region.  This function is 
usually implemented such
+  that it is a write-once operation.
+
+  @param  PeiServices  General purpose services available to every 
PEIM.
+  @param  This The pointer to the MM Access Interface.
+  @param  DescriptorIndex  The region of MMRAM to Close.
+
+  @retval EFI_SUCCESSThe region was successfully locked.
+  @retval EFI_DEVICE_ERROR   The region could not be locked because at 
least
+ one range is still open.
+  @retval EFI_INVALID_PARAMETER  The descriptor index was out of bounds.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_PEI_MM_LOCK)(
+  IN EFI_PEI_SERVICES**PeiServices,
+  IN EFI_PEI_MM_ACCESS_PPI

Re: [edk2] [PATCH 4/4] StandaloneMmPkg: Import StandaloneMmServicesTableLib library.

[Marvin Häuser]

Comment inline.

Thanks,
Marvin

> -Original Message-
> From: edk2-devel  On Behalf Of Marvin
> Häuser
> Sent: Sunday, July 22, 2018 12:32 AM
> To: edk2-devel@lists.01.org
> Cc: ruiyu...@intel.com; eric.d...@intel.com; liming@intel.com;
> jiewen@intel.com; michael.d.kin...@intel.com; star.z...@intel.com
> Subject: [edk2] [PATCH 4/4] StandaloneMmPkg: Import
> StandaloneMmServicesTableLib library.
> 
> Implements the MmServicesTableLib library class for MM Stanalone
> modules.  The code was derieved from SmmServicesTableLib.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marvin Haeuser 
> ---
> 
> StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneMmS
> ervicesTableLib.c   | 64 
> 
> StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneMmS
> ervicesTableLib.inf | 35 +++
> StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneMmS
> ervicesTableLib.uni | 21 +++
>  3 files changed, 120 insertions(+)
> 
> diff --git
> a/StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneM
> mServicesTableLib.c
> b/StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneM
> mServicesTableLib.c
> new file mode 100644
> index ..d33ff953b555
> --- /dev/null
> +++
> b/StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneM
> mS
> +++ ervicesTableLib.c
> @@ -0,0 +1,64 @@
> +/** @file
> +  Standalone MM Services Table Library.
> +
> +  Copyright (c) 2010 - 2018, Intel Corporation. All rights
> + reserved.  This program and the accompanying materials  are
> + licensed and made available under the terms and conditions of the BSD
> + License  which accompanies this distribution.  The full text of the
> + license may be found at  http://opensource.org/licenses/bsd-license.php.
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#include 
> +#include  #include 
> +
> +EFI_MM_SYSTEM_TABLE *gMmst = NULL;
> +
> +/**
> +  The constructor function caches the pointer of MM Services Table.
> +
> +  @param  ImageHandleThe firmware allocated handle for the EFI image.
> +  @param  MmSystemTable  A pointer to the MM System Table.
> +
> +  @retval EFI_SUCCESS   The constructor always returns EFI_SUCCESS.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +StandaloneMmServicesTableLibConstructor (
> +  IN EFI_HANDLE   ImageHandle,
> +  IN EFI_MM_SYSTEM_TABLE  *MmSystemTable
> +  )
> +{
> +  gMmst = MmSystemTable;
> +  ASSERT (gMmst != NULL);
> +
> +  return EFI_SUCCESS;
> +}
> +
> +/**
> +  This function allows the caller to determine if the driver is
> +executing in
> +  Management Mode(MM).
> +
> +  This function returns TRUE if the driver is executing in MM and FALSE
> + if the  driver is not executing in MM.
> +
> +  @retval  TRUE  The driver is executing in Management Mode (MM).
> +  @retval  FALSE The driver is not executing in Management Mode (MM).
> +
> +**/
> +BOOLEAN
> +EFIAPI
> +InMm (
> +  VOID
> +  )
> +{
> +  //
> +  // We are already in MM
> +  //
> +  return TRUE;
> +}
> diff --git
> a/StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneM
> mServicesTableLib.inf
> b/StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneM
> mServicesTableLib.inf
> new file mode 100644
> index ..bfe5678a5bc0
> --- /dev/null
> +++
> b/StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneM
> mS
> +++ ervicesTableLib.inf
> @@ -0,0 +1,35 @@
> +## @file
> +# Standalone MM Services Table Library.
> +#
> +# Copyright (c) 2009 - 2014, Intel Corporation. All rights
> +reserved. # #  This program and the accompanying materials #  are
> +licensed and made available under the terms and conditions of the BSD
> +License #  which accompanies this distribution. The full text of the
> +license may be found at #  http://opensource.org/licenses/bsd-license.php.
> +#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> +BASIS, #  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND,
> EITHER EXPRESS OR IMPLIED.
> +#
> +#
> +##
> +
> +[Defines]
> +  INF_VERSION= 0x00010005
> +  BASE_NAME  = StandaloneMmServicesTableLib
> +  MODULE_UNI_FILE= StandaloneMmServicesTableLib.uni
> +  FILE_GUID  = 821F6D8E-CE99-4CD5-B1FD-C33AC8BA5704
> +  MODULE_TYPE= MM_STANDALONE
> +  VERSION_STRING = 1.0
> +  LIBRARY_C

[edk2] [PATCH] PcAtChipsetPkg/AcpiTimerLib: Do not restrict Base instance.

[Marvin Häuser]

The current Base AcpiTimerLib instance restricts usage to SEC and PEI
modules, for which there is no obvious reason. Lift this restriction.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 PcAtChipsetPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/PcAtChipsetPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf 
b/PcAtChipsetPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf
index b7f737e30ac8..df9eecfdaeaa 100644
--- a/PcAtChipsetPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf
+++ b/PcAtChipsetPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf
@@ -24,7 +24,7 @@ [Defines]
   FILE_GUID  = 564DE85F-049E-4481-BF7A-CA04D2788CF9
   MODULE_TYPE= BASE
   VERSION_STRING = 1.0
-  LIBRARY_CLASS  = TimerLib|SEC PEI_CORE PEIM
+  LIBRARY_CLASS  = TimerLib
   CONSTRUCTOR= AcpiTimerLibConstructor
   MODULE_UNI_FILE= BaseAcpiTimerLib.uni
 
-- 
2.18.0.windows.1

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

[edk2] [PATCH] PcAtChipsetPkg/AcpiTimerLib: Support Standalone MM.

[Marvin Häuser]

To support Standalone MM, the current DXE implementation, which is
also used to support DXE SMM Drivers, has been modified. Its type was
changed to BASE to make the constructor function generic,
MM_STANDALONE modules types have been added to the support list and
the internal files were adapted to show support.

"DxeAcpiTimerLib.inf" has not been renamed to not break packages.
This might be addressed with a separate patch.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 PcAtChipsetPkg/Library/AcpiTimerLib/{DxeAcpiTimerLib.c => 
DxeStandaloneMmAcpiTimerLib.c} |  9 +++--
 PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
  | 14 +++---
 PcAtChipsetPkg/Library/AcpiTimerLib/{DxeAcpiTimerLib.uni => 
StandaloneMmDxeAcpiTimerLib.uni} |  2 +-
 3 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.c 
b/PcAtChipsetPkg/Library/AcpiTimerLib/DxeStandaloneMmAcpiTimerLib.c
similarity index 88%
rename from PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.c
rename to PcAtChipsetPkg/Library/AcpiTimerLib/DxeStandaloneMmAcpiTimerLib.c
index 9ed10ef2e297..784f33871d75 100644
--- a/PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.c
+++ b/PcAtChipsetPkg/Library/AcpiTimerLib/DxeStandaloneMmAcpiTimerLib.c
@@ -13,6 +13,7 @@
 **/
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -78,17 +79,13 @@ InternalGetPerformanceCounterFrequency (
 /**
   The constructor function enables ACPI IO space, and caches 
PerformanceCounterFrequency.
 
-  @param  ImageHandle   The firmware allocated handle for the EFI image.
-  @param  SystemTable   A pointer to the EFI System Table.
-
   @retval EFI_SUCCESS   The constructor always returns RETURN_SUCCESS.
 
 **/
 EFI_STATUS
 EFIAPI
-DxeAcpiTimerLibConstructor (
-  IN EFI_HANDLEImageHandle,
-  IN EFI_SYSTEM_TABLE  *SystemTable
+DxeStandaloneMmAcpiTimerLibConstructor (
+  VOID
   )
 {
   EFI_HOB_GUID_TYPE   *GuidHob;
diff --git a/PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf 
b/PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
index 601041c80137..f1f62247649e 100644
--- a/PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+++ b/PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
@@ -1,5 +1,5 @@
 ## @file
-#  DXE ACPI Timer Library
+#  DXE and Standalone MM ACPI Timer Library
 #
 #  Provides basic timer support using the ACPI timer hardware.  The performance
 #  counter features are provided by the processors time stamp counter.
@@ -20,17 +20,17 @@
 
 [Defines]
   INF_VERSION= 0x00010005
-  BASE_NAME  = DxeAcpiTimerLib
+  BASE_NAME  = DxeStandaloneMmAcpiTimerLib
   FILE_GUID  = E624B98C-845A-4b94-9B50-B20475D552B9
-  MODULE_TYPE= DXE_DRIVER
+  MODULE_TYPE= BASE
   VERSION_STRING = 1.0
-  LIBRARY_CLASS  = TimerLib|DXE_CORE DXE_DRIVER 
DXE_RUNTIME_DRIVER DXE_SMM_DRIVER UEFI_APPLICATION UEFI_DRIVER SMM_CORE
-  CONSTRUCTOR= DxeAcpiTimerLibConstructor
-  MODULE_UNI_FILE= DxeAcpiTimerLib.uni
+  LIBRARY_CLASS  = TimerLib|DXE_CORE DXE_DRIVER 
DXE_RUNTIME_DRIVER DXE_SMM_DRIVER MM_STANDALONE UEFI_APPLICATION UEFI_DRIVER 
SMM_CORE MM_CORE_STANDALONE
+  CONSTRUCTOR= DxeStandaloneMmAcpiTimerLibConstructor
+  MODULE_UNI_FILE= DxeStandaloneMmAcpiTimerLib.uni
 
 [Sources]
   AcpiTimerLib.c
-  DxeAcpiTimerLib.c
+  DxeStandaloneMmAcpiTimerLib.c
 
 [Packages]
   MdePkg/MdePkg.dec
diff --git a/PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.uni 
b/PcAtChipsetPkg/Library/AcpiTimerLib/StandaloneMmDxeAcpiTimerLib.uni
similarity index 92%
rename from PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.uni
rename to PcAtChipsetPkg/Library/AcpiTimerLib/StandaloneMmDxeAcpiTimerLib.uni
index bf31abf81d68..6b3abb85ebc8 100644
--- a/PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.uni
+++ b/PcAtChipsetPkg/Library/AcpiTimerLib/StandaloneMmDxeAcpiTimerLib.uni
@@ -1,5 +1,5 @@
 // /** @file
-// DXE ACPI Timer Library
+// DXE and Standalone MM ACPI Timer Library
 //
 // Provides basic timer support using the ACPI timer hardware.  The performance
 // counter features are provided by the processors time stamp counter.
-- 
2.18.0.windows.1

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

[edk2] [PATCH] BaseTools/GenC: Update Standalone MM EPs for StandaloneMmPkg.

[Marvin Häuser]

The current BaseTools GenC implementation for UEFI module entry
points declares Standalone MM Entry Points with the
EFI_SMM_SYSTEM_TABLE2 MmSystemTable pointer and includes SMM headers.
Update the code to reflect the imported StandaloneMmPkg by changing
MmSystemTable to the MM type and include both PiMm.h and the
StandaloneMmPkg Entry Point header over the original SMM variants.

This change should not break any existent code due to the absense
of any MM Standalone modules.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 BaseTools/Source/Python/AutoGen/GenC.py | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/GenC.py 
b/BaseTools/Source/Python/AutoGen/GenC.py
index 3b396491d023..bc7709f4b5e4 100644
--- a/BaseTools/Source/Python/AutoGen/GenC.py
+++ b/BaseTools/Source/Python/AutoGen/GenC.py
@@ -265,8 +265,8 @@ ${BEGIN}
 EFI_STATUS
 EFIAPI
 ${Function} (
-  IN EFI_HANDLEImageHandle,
-  IN EFI_SMM_SYSTEM_TABLE2 *MmSystemTable
+  IN EFI_HANDLE  ImageHandle,
+  IN EFI_MM_SYSTEM_TABLE *MmSystemTable
   );
 ${END}
 """)
@@ -278,8 +278,8 @@ GLOBAL_REMOVE_IF_UNREFERENCED const UINT32 _gMmRevision = 
${PiSpecVersion};
 EFI_STATUS
 EFIAPI
 ProcessModuleEntryPointList (
-  IN EFI_HANDLEImageHandle,
-  IN EFI_SMM_SYSTEM_TABLE2 *MmSystemTable
+  IN EFI_HANDLE  ImageHandle,
+  IN EFI_MM_SYSTEM_TABLE *MmSystemTable
   )
 
 {
@@ -292,8 +292,8 @@ ${BEGIN}
 EFI_STATUS
 EFIAPI
 ProcessModuleEntryPointList (
-  IN EFI_HANDLEImageHandle,
-  IN EFI_SMM_SYSTEM_TABLE2 *MmSystemTable
+  IN EFI_HANDLE  ImageHandle,
+  IN EFI_MM_SYSTEM_TABLE *MmSystemTable
   )
 
 {
@@ -307,8 +307,8 @@ GLOBAL_REMOVE_IF_UNREFERENCED const UINT32 _gMmRevision = 
${PiSpecVersion};
 EFI_STATUS
 EFIAPI
 ProcessModuleEntryPointList (
-  IN EFI_HANDLEImageHandle,
-  IN EFI_SMM_SYSTEM_TABLE2 *MmSystemTable
+  IN EFI_HANDLE  ImageHandle,
+  IN EFI_MM_SYSTEM_TABLE *MmSystemTable
   )
 
 {
@@ -675,8 +675,8 @@ ${Function} (
 EFI_STATUS
 EFIAPI
 ${Function} (
-  IN EFI_HANDLEImageHandle,
-  IN EFI_SMM_SYSTEM_TABLE2  *MmSystemTable
+  IN EFI_HANDLE   ImageHandle,
+  IN EFI_MM_SYSTEM_TABLE  *MmSystemTable
   );${END}
 """),
 }
@@ -755,8 +755,8 @@ ${BEGIN}${FunctionPrototype}${END}
 VOID
 EFIAPI
 ProcessLibrary${Type}List (
-  IN EFI_HANDLEImageHandle,
-  IN EFI_SMM_SYSTEM_TABLE2  *MmSystemTable
+  IN EFI_HANDLE   ImageHandle,
+  IN EFI_MM_SYSTEM_TABLE  *MmSystemTable
   )
 {
 ${BEGIN}  EFI_STATUS  Status;
@@ -780,8 +780,8 @@ gModuleTypeHeaderFile = {
 SUP_MODULE_UEFI_DRIVER   :   ["Uefi.h",  "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/UefiBootServicesTableLib.h", 
"Library/UefiDriverEntryPoint.h"],
 SUP_MODULE_UEFI_APPLICATION  :   ["Uefi.h",  "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/UefiBootServicesTableLib.h", 
"Library/UefiApplicationEntryPoint.h"],
 SUP_MODULE_SMM_CORE  :   ["PiDxe.h", "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/UefiDriverEntryPoint.h"],
-SUP_MODULE_MM_STANDALONE :   ["PiSmm.h", "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/SmmDriverStandaloneEntryPoint.h"],
-SUP_MODULE_MM_CORE_STANDALONE :  ["PiSmm.h", "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/SmmCoreStandaloneEntryPoint.h"],
+SUP_MODULE_MM_STANDALONE :   ["PiMm.h",  "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/StandaloneMmDriverEntryPoint.h"],
+SUP_MODULE_MM_CORE_STANDALONE :  ["PiMm.h",  "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/StandaloneMmCoreEntryPoint.h"],
 SUP_MODULE_USER_DEFINED  :   [gBasicHeaderFile]
 }
 
-- 
2.18.0.windows.1

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

[edk2] [PATCH 2/4] MdePkg: Import MmServicesTableLib library.

[Marvin Häuser]

Implements the MmServicesTableLib library class.
The code was derieved from SmmServicesTableLib.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Library/MmServicesTableLib/MmServicesTableLib.c   | 85 

 MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf | 41 ++
 MdePkg/Library/MmServicesTableLib/MmServicesTableLib.uni | 21 +
 MdePkg/MdePkg.dsc|  1 +
 4 files changed, 148 insertions(+)

diff --git a/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.c 
b/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.c
new file mode 100644
index ..1ecbb044162d
--- /dev/null
+++ b/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.c
@@ -0,0 +1,85 @@
+/** @file
+  MM Services Table Library.
+
+  Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php.
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+
+EFI_MM_SYSTEM_TABLE *gMmst = NULL;
+
+/**
+  The constructor function caches the pointer of MM Services Table.
+
+  @param  ImageHandle   The firmware allocated handle for the EFI image.
+  @param  SystemTable   A pointer to the EFI System Table.
+
+  @retval EFI_SUCCESS   The constructor always returns EFI_SUCCESS.
+
+**/
+EFI_STATUS
+EFIAPI
+MmServicesTableLibConstructor (
+  IN EFI_HANDLEImageHandle,
+  IN EFI_SYSTEM_TABLE  *SystemTable
+  )
+{
+  EFI_STATUS   Status;
+  EFI_MM_BASE_PROTOCOL *InternalMmBase;
+
+  InternalMmBase = NULL;
+  //
+  // Retrieve MM Base Protocol,  Do not use gBS from UefiBootServicesTableLib 
on purpose
+  // to prevent inclusion of gBS, gST, and gImageHandle from MM Drivers unless 
the
+  // MM driver explicity declares that dependency.
+  //
+  Status = SystemTable->BootServices->LocateProtocol (
+,
+NULL,
+(VOID **)
+);
+  ASSERT_EFI_ERROR (Status);
+  ASSERT (InternalMmBase != NULL);
+
+  //
+  // We are in MM, retrieve the pointer to MM System Table
+  //
+  InternalMmBase->GetMmstLocation (InternalMmBase, );
+  ASSERT (gMmst != NULL);
+
+  return EFI_SUCCESS;
+}
+
+/**
+  This function allows the caller to determine if the driver is executing in
+  Management Mode(MM).
+
+  This function returns TRUE if the driver is executing in MM and FALSE if the
+  driver is not executing in MM.
+
+  @retval  TRUE  The driver is executing in Management Mode (MM).
+  @retval  FALSE The driver is not executing in Management Mode (MM).
+
+**/
+BOOLEAN
+EFIAPI
+InMm (
+  VOID
+  )
+{
+  //
+  // We are already in MM
+  //
+  return TRUE;
+}
diff --git a/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf 
b/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
new file mode 100644
index ..fd6b2cbe1f94
--- /dev/null
+++ b/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
@@ -0,0 +1,41 @@
+## @file
+# MM Services Table Library.
+#
+# Copyright (c) 2009 - 2014, Intel Corporation. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution. The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php.
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = MmServicesTableLib
+  MODULE_UNI_FILE= MmServicesTableLib.uni
+  FILE_GUID  = 319D85EE-D290-4B26-BBDA-9D43CF35DF60
+  MODULE_TYPE= DXE_SMM_DRIVER
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = MmServicesTableLib|DXE_SMM_DRIVER
+  PI_SPECIFICATION_VERSION   = 0x0001000A
+  CONSTRUCTOR= MmServicesTableLibConstructor
+
+[Sources]
+  MmServicesTableLib.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+
+[LibraryClasses]
+  DebugLib
+
+[Protocols]
+  gEfiMmBaseProtocolGuid  ## CONSUMES
+
+[Depex]
+  gEfiMmBaseProtocolGuid
+
diff --git a/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.uni 
b/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.uni
new file mode 100644
index ..5194cd829051
--- /dev/null
+++ b/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.uni
@@ -0,0 +1,21 @@
+// /** @file
+// 

[edk2] [PATCH 1/4] MdePkg: Declare the MmServicesTableLib library class.

[Marvin Häuser]

Declare the MmServicesTableLib library class to follow the new naming
scheme of "MM" deprecating "SMM".

The code was derieved from SmmServicesTableLib.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Include/Library/MmServicesTableLib.h | 43 
 MdePkg/MdePkg.dec   |  4 ++
 2 files changed, 47 insertions(+)

diff --git a/MdePkg/Include/Library/MmServicesTableLib.h 
b/MdePkg/Include/Library/MmServicesTableLib.h
new file mode 100644
index ..60ee4299d902
--- /dev/null
+++ b/MdePkg/Include/Library/MmServicesTableLib.h
@@ -0,0 +1,43 @@
+/** @file
+  Provides a service to retrieve a pointer to the MM Services Table.
+  Only available to MM module types.
+
+Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __MM_SERVICES_TABLE_LIB_H__
+#define __MM_SERVICES_TABLE_LIB_H__
+
+#include 
+
+///
+/// Cache pointer to the MM Services Table
+///
+extern EFI_MM_SYSTEM_TABLE *gMmst;
+
+/**
+  This function allows the caller to determine if the driver is executing in
+  Management Mode(MM).
+
+  This function returns TRUE if the driver is executing in MM and FALSE if the
+  driver is not executing in MM.
+
+  @retval  TRUE  The driver is executing in Management Mode (MM).
+  @retval  FALSE The driver is not executing in Management Mode (MM).
+
+**/
+BOOLEAN
+EFIAPI
+InMm (
+  VOID
+  );
+
+#endif
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 94ad814dc9d6..08912fb9d55d 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -251,6 +251,10 @@ [LibraryClasses.IA32, LibraryClasses.X64]
   ##
   SmmLib|Include/Library/SmmLib.h
 
+  ##  @libraryclass  Provides a service to retrieve a pointer to the MM 
Services Table.
+  #  Only available to MM/DXE Combined and MM module types.
+  MmServicesTableLib|Include/Library/MmServicesTableLib.h
+
   ##  @libraryclass  Provides a service to retrieve a pointer to the SMM 
Services Table.
   #  Only available to SMM/DXE Combined and SMM module types.
   SmmServicesTableLib|Include/Library/SmmServicesTableLib.h
-- 
2.18.0.windows.1

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

[edk2] [PATCH 3/4] MdeModulePkg: Import PiSmmCoreMmServicesTableLib library.

[Marvin Häuser]

Implements the MmServicesTableLib library class for PiSmmCore.
The code was derieved from PiSmmCoreSmmServicesTableLib.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdeModulePkg/Library/PiSmmCoreMmServicesTableLib/PiSmmCoreMmServicesTableLib.c 
  | 61 
 
MdeModulePkg/Library/PiSmmCoreMmServicesTableLib/PiSmmCoreMmServicesTableLib.inf
 | 32 ++
 
MdeModulePkg/Library/PiSmmCoreMmServicesTableLib/PiSmmCoreMmServicesTableLib.uni
 | 21 +++
 3 files changed, 114 insertions(+)

diff --git 
a/MdeModulePkg/Library/PiSmmCoreMmServicesTableLib/PiSmmCoreMmServicesTableLib.c
 
b/MdeModulePkg/Library/PiSmmCoreMmServicesTableLib/PiSmmCoreMmServicesTableLib.c
new file mode 100644
index ..9184e9e2e6c9
--- /dev/null
+++ 
b/MdeModulePkg/Library/PiSmmCoreMmServicesTableLib/PiSmmCoreMmServicesTableLib.c
@@ -0,0 +1,61 @@
+/** @file
+  SMM Core MM Services Table Library.
+
+  Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+
+EFI_MM_SYSTEM_TABLE   *gMmst = NULL;
+extern EFI_SMM_SYSTEM_TABLE2  gSmmCoreSmst;
+
+/**
+  The constructor function caches the pointer of MM Services Table.
+
+  @param  ImageHandle   The firmware allocated handle for the EFI image.
+  @param  SystemTable   A pointer to the EFI System Table.
+
+  @retval EFI_SUCCESS   The constructor always returns EFI_SUCCESS.
+
+**/
+EFI_STATUS
+EFIAPI
+SmmCoreMmServicesTableLibConstructor (
+  IN EFI_HANDLEImageHandle,
+  IN EFI_SYSTEM_TABLE  *SystemTable
+  )
+{
+  gMmst = (EFI_MM_SYSTEM_TABLE *)
+  return EFI_SUCCESS;
+}
+
+/**
+  This function allows the caller to determine if the driver is executing in
+  Management Mode(MM).
+
+  This function returns TRUE if the driver is executing in MM and FALSE if the
+  driver is not executing in MM.
+
+  @retval  TRUE  The driver is executing in Management Mode (MM).
+  @retval  FALSE The driver is not executing in Management Mode (MM).
+
+**/
+BOOLEAN
+EFIAPI
+InMm (
+  VOID
+  )
+{
+  return TRUE;
+}
diff --git 
a/MdeModulePkg/Library/PiSmmCoreMmServicesTableLib/PiSmmCoreMmServicesTableLib.inf
 
b/MdeModulePkg/Library/PiSmmCoreMmServicesTableLib/PiSmmCoreMmServicesTableLib.inf
new file mode 100644
index ..06bb455b1777
--- /dev/null
+++ 
b/MdeModulePkg/Library/PiSmmCoreMmServicesTableLib/PiSmmCoreMmServicesTableLib.inf
@@ -0,0 +1,32 @@
+## @file
+# SMM Core MM Services Table Library.
+#
+# Copyright (c) 2010 - 2014, Intel Corporation. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution. The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = PiSmmCoreMmServicesTableLib
+  MODULE_UNI_FILE= PiSmmCoreMmServicesTableLib.uni
+  FILE_GUID  = 9E32CD7E-DB34-42B5-B5FA-77DD98633F47
+  MODULE_TYPE= SMM_CORE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = MmServicesTableLib|SMM_CORE
+  PI_SPECIFICATION_VERSION   = 0x0001000A
+  CONSTRUCTOR= SmmCoreMmServicesTableLibConstructor
+
+[Sources]
+  PiSmmCoreMmServicesTableLib.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+
diff --git 
a/MdeModulePkg/Library/PiSmmCoreMmServicesTableLib/PiSmmCoreMmServicesTableLib.uni
 
b/MdeModulePkg/Library/PiSmmCoreMmServicesTableLib/PiSmmCoreMmServicesTableLib.uni
new file mode 100644
index ..dbf7ce93731e
--- /dev/null
+++ 
b/MdeModulePkg/Library/PiSmmCoreMmServicesTableLib/PiSmmCoreMmServicesTableLib.uni
@@ -0,0 +1,21 @@
+// /** @file
+// SMM Core MM Services Table Library.
+//
+// SMM Core MM Services Table Library.
+//
+// Copyright (c) 2010 - 2014, Intel Corporation. All rights reserved.
+//
+// This program and the accompanying materials
+// are licensed and made available under the terms and conditions of the BSD 
License
+// which accompanies this distribution. The full text of the license may be 
found at
+// http://opensource.org/licenses/bsd-license.php
+// THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+// WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 

[edk2] [PATCH 4/4] StandaloneMmPkg: Import StandaloneMmServicesTableLib library.

[Marvin Häuser]

Implements the MmServicesTableLib library class for MM Stanalone
modules.  The code was derieved from SmmServicesTableLib.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 
StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.c
   | 64 
 
StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf
 | 35 +++
 
StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.uni
 | 21 +++
 3 files changed, 120 insertions(+)

diff --git 
a/StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.c
 
b/StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.c
new file mode 100644
index ..d33ff953b555
--- /dev/null
+++ 
b/StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.c
@@ -0,0 +1,64 @@
+/** @file
+  Standalone MM Services Table Library.
+
+  Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php.
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+#include 
+#include 
+
+EFI_MM_SYSTEM_TABLE *gMmst = NULL;
+
+/**
+  The constructor function caches the pointer of MM Services Table.
+
+  @param  ImageHandleThe firmware allocated handle for the EFI image.
+  @param  MmSystemTable  A pointer to the MM System Table.
+
+  @retval EFI_SUCCESS   The constructor always returns EFI_SUCCESS.
+
+**/
+EFI_STATUS
+EFIAPI
+StandaloneMmServicesTableLibConstructor (
+  IN EFI_HANDLE   ImageHandle,
+  IN EFI_MM_SYSTEM_TABLE  *MmSystemTable
+  )
+{
+  gMmst = MmSystemTable;
+  ASSERT (gMmst != NULL);
+
+  return EFI_SUCCESS;
+}
+
+/**
+  This function allows the caller to determine if the driver is executing in
+  Management Mode(MM).
+
+  This function returns TRUE if the driver is executing in MM and FALSE if the
+  driver is not executing in MM.
+
+  @retval  TRUE  The driver is executing in Management Mode (MM).
+  @retval  FALSE The driver is not executing in Management Mode (MM).
+
+**/
+BOOLEAN
+EFIAPI
+InMm (
+  VOID
+  )
+{
+  //
+  // We are already in MM
+  //
+  return TRUE;
+}
diff --git 
a/StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf
 
b/StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf
new file mode 100644
index ..bfe5678a5bc0
--- /dev/null
+++ 
b/StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf
@@ -0,0 +1,35 @@
+## @file
+# Standalone MM Services Table Library.
+#
+# Copyright (c) 2009 - 2014, Intel Corporation. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution. The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php.
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = StandaloneMmServicesTableLib
+  MODULE_UNI_FILE= StandaloneMmServicesTableLib.uni
+  FILE_GUID  = 821F6D8E-CE99-4CD5-B1FD-C33AC8BA5704
+  MODULE_TYPE= MM_STANDALONE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = MmServicesTableLib|MM_STANDALONE
+  PI_SPECIFICATION_VERSION   = 0x0001000A
+  CONSTRUCTOR= StandaloneMmServicesTableLibConstructor
+
+[Sources]
+  StandaloneMmServicesTableLib.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  StandaloneMmPkg/StandaloneMmPkg.dec
+
+[LibraryClasses]
+  DebugLib
diff --git 
a/StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.uni
 
b/StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.uni
new file mode 100644
index ..c0581e2820ce
--- /dev/null
+++ 
b/StandaloneMmPkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.uni
@@ -0,0 +1,21 @@
+// /** @file
+// Standalone MM Services Table Library.
+//
+// Standalone MM Services Table Library.
+//
+// Copyright (c) 2009 - 2014, Intel Corporation. All rights reserved.
+//
+// This program and the accompanying materials
+// are licensed and made available under the terms and conditions of the BSD 
License
+// which accompanies this distribution. The full text of the license may be 
found at
+// 

[edk2] [PATCH] UefiCpuPkg/CpuMpPei: Correct BIST PPI logic.

[Marvin Häuser]

Currently, the SecPlatformInformation2 PPI is installed when either
there is none present or the present one doesn't lack data.
Update the logic to only install the SecPlatformInformation2 PPI when
it's not already installed so that an up-to-date PPI remains the only
one and unchanged.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 UefiCpuPkg/CpuMpPei/CpuBist.c | 22 +++-
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/UefiCpuPkg/CpuMpPei/CpuBist.c b/UefiCpuPkg/CpuMpPei/CpuBist.c
index 20728525e2d9..5312d9f01dc8 100644
--- a/UefiCpuPkg/CpuMpPei/CpuBist.c
+++ b/UefiCpuPkg/CpuMpPei/CpuBist.c
@@ -275,18 +275,20 @@ CollectBistDataFromPpi (
 (UINTN) BistInformationSize
 );
 
-  if (SecPlatformInformation2 != NULL && NumberOfData < NumberOfProcessors) {
-//
-// Reinstall SecPlatformInformation2 PPI to include new BIST information
-//
-Status = PeiServicesReInstallPpi (
-   SecInformationDescriptor,
-   
-   );
-ASSERT_EFI_ERROR (Status);
+  if (SecPlatformInformation2 != NULL) {
+if (NumberOfData < NumberOfProcessors) {
+  //
+  // Reinstall SecPlatformInformation2 PPI to include new BIST information
+  //
+  Status = PeiServicesReInstallPpi (
+ SecInformationDescriptor,
+ 
+ );
+  ASSERT_EFI_ERROR (Status);
+}
   } else {
 //
-// Install SecPlatformInformation2 PPI to include new BIST information
+// Install SecPlatformInformation2 PPI
 //
 Status = PeiServicesInstallPpi ();
 ASSERT_EFI_ERROR(Status);
-- 
2.18.0.windows.1

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

Re: [edk2] StandaloneMmPkg comments

[Marvin Häuser]

> -Original Message-
> From: Ard Biesheuvel 
> Sent: Saturday, July 21, 2018 5:51 PM
> To: Marvin H?user 
> Cc: edk2-devel@lists.01.org; achin.gu...@arm.com; jiewen@intel.com;
> supreeth.venkat...@arm.com
> Subject: Re: [edk2] StandaloneMmPkg comments
> 
> On 21 July 2018 at 03:57, Marvin H?user 
> wrote:
> > Good day,
> >
> > I have been reading through the recently imported StandaloneMmPkg and
> found three odd things.
> >
> >
> >   1.  GUID prefixes: GUIDs defined in StandaloneMmPkg.dec either have no
> common prefix at all ("gMmFv") or use the "gEfi" prefix. Maybe the
> MdeModulePkg-style "gEdkii" prefix could be used for a uniform style?
> 
> The gEdkii prefix is used for GUIDs that are not defined in the PI or UEFI
> specs. The gEfi  prefix is used for GUIDs that are defined in either of those
> specs. I'm not sure what the rule is for prefixless GUIDs though.

I'm not aware of the GUIDs (here and for 3.) being defined in any UEFI 
specification, they seem to be package-defined, hence I thought "gEdkii" would 
be appropriate.

> 
> >   2.  The "gEfiMmConfigurationProtocolGuid" name is common between
> Standalone (StandaloneMmPkg.dec) and Traditional (MdePkg.dec) MM
> context despite having a different value of course. Shouldn't the naming
> reflect which is traditional and which is Standalone? I haven't checked in
> depth, but which is chosen when a module consumes both MdePkg and
> StandaloneMmPkg?
> 
> That smells like a bug to me.

The name is actually defined twice in the specification too. I'm assuming the 
authors intended for the appropriate GUID to be used depending on the consuming 
module. Maybe something like "[Protocols.common.MM_STANDALONE]" should be 
introduced?

> 
> >   3.  While .dec already uses the "Mmram" naming scheme, its header
> declares the MemoryReserve GUID as
> "gEfiMmPeiS(!)mramMemoryReserveGuid". Furthermore, the header
> references the SMM CIS (which has been replaced with "MM CIS" as part of
> the renaming), while the GUID has changed and the structure does not
> match the deprecated specification anyway. May I suggest to turn this GUID
> into a "gEdkii"-style GUID and remove all references to the SMM CIS? Maybe
> use the "EDKII_" prefix for "EFI_MMRAM_HOB_DESCRIPTOR_BLOCK" too? I
> wanted to prepare a patch, but I cannot compile the package at the moment
> and don't want to risk submitting anything broken.
> >
> 
> As mentioned above, EDKII prefixes are inappropriate here, since standalone
> MM is defined in the PI spec. I will let others comment on the SMM CIS thing.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3] MdePkg/UefiFileHandleLib: Fix the Root directory determination.

[Marvin Häuser]

The current implementation of the FileHandleGetFileName() function
assumes that the Root directory always has the FileName '\0'.
However, the only requirement the UEFI specification defines is that
a prepended '\\' must be supported to access files and folders
relative to the Root directory.
This patch removes this assumption and supports constructing valid
paths for any value of FileName for the Root Directory.

In practice, this fixes compatibility issues with File System drivers
that report '\\' as the FileName of the Root directory, which
currently is both generating an invalid path ("") and resulting
in an EFI_NOT_FOUND result from the CurrentHandle->Open() call.

V2:
  - Do not change the copyright date as requested.

V3:
  - Simplify the root check to not check the length of FileName.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c | 26 ++--
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c 
b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
index a768c3e23ae5..0a316231f984 100644
--- a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
+++ b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
@@ -820,10 +820,24 @@ FileHandleGetFileName (
 Status = EFI_OUT_OF_RESOURCES;
 break;
   } else {
+//
+// Prepare to move to the parent directory.
+// Also determine whether CurrentHandle refers to the Root directory.
+//
+Status = CurrentHandle->Open (CurrentHandle, , L"..", 
EFI_FILE_MODE_READ, 0);
 //
 // We got info... do we have a name? if yes precede the current path 
with it...
 //
-if (StrLen (FileInfo->FileName) == 0) {
+if (EFI_ERROR (Status)) {
+  //
+  // EFI_ERROR() suggests that CurrentHandle refers to the Root
+  // directory.  As this loop ensures FullFileName is starting with
+  // '\\' at all times, signal success and exit the loop.
+  // While FileInfo->FileName could theoretically be a value other than
+  // '\0' or '\\', '\\' is guaranteed to be supported by the
+  // specification and hence its value can safely be ignored.
+  //
+  Status = EFI_SUCCESS;
   if (*FullFileName == NULL) {
 ASSERT((*FullFileName == NULL && Size == 0) || (*FullFileName != 
NULL));
 *FullFileName = StrnCatGrowLeft(FullFileName, , L"\\", 0);
@@ -841,15 +855,11 @@ FileHandleGetFileName (
   FreePool(FileInfo);
 }
   }
-  //
-  // Move to the parent directory
-  //
-  Status = CurrentHandle->Open (CurrentHandle, , L"..", 
EFI_FILE_MODE_READ, 0);
-  if (EFI_ERROR (Status)) {
-break;
-  }
 
   FileHandleClose(CurrentHandle);
+  //
+  // Move to the parent directory
+  //
   CurrentHandle = NextHigherHandle;
 }
   } else if (Status == EFI_NOT_FOUND) {
-- 
2.18.0.windows.1

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

Re: [edk2] [PATCH v2] ShellPkg/UefiShellLevel2CommandsLib: Support unspecified local Timezone.

[Marvin Häuser]

Hey Ruiyu,

Sorry if I'm bothering you, but this V2 was still not reviewed or pushed.

Regards,
Marvin.

> -Original Message-
> From: Marvin Häuser
> Sent: Wednesday, June 13, 2018 10:30 PM
> To: edk2-devel@lists.01.org; ruiyu...@intel.com
> Cc: jaben.car...@intel.com
> Subject: RE: [PATCH v2] ShellPkg/UefiShellLevel2CommandsLib: Support
> unspecified local Timezone.
> 
> Good day Ruiyu,
> 
> Sorry, but you have not ack'd this V2 yet. Is there anything wrong you want
> me to correct?
> 
> Thanks,
> Marvin.
> 
> > -Original Message-
> > From: Carsey, Jaben 
> > Sent: Thursday, May 17, 2018 4:15 PM
> > To: Marvin Häuser ; edk2-
> > de...@lists.01.org
> > Cc: Ni, Ruiyu 
> > Subject: RE: [PATCH v2] ShellPkg/UefiShellLevel2CommandsLib: Support
> > unspecified local Timezone.
> >
> > Still looks good to me.  Ray?
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> > > Of Marvin Häuser
> > > Sent: Thursday, May 17, 2018 5:43 AM
> > > To: edk2-devel@lists.01.org
> > > Cc: Carsey, Jaben ; Ni, Ruiyu
> > > 
> > > Subject: [edk2] [PATCH v2] ShellPkg/UefiShellLevel2CommandsLib:
> > > Support unspecified local Timezone.
> > > Importance: High
> > >
> > > EFI_RUNTIME_SERVICES.GetTime() might return an unspecified
> Timezone,
> > > such as when SetTime() has not been called after the PC-AT CMOS RTC
> > > was cut off power. Consider this case by not attempting Timezone
> > > translations for when it is invalid.
> > >
> > > V2:
> > >   - Do not change the copyright date as requested.
> > >   - Added R-bs from V1 as no functional changes have been made.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Marvin Haeuser 
> > > Reviewed-by: Jaben Carsey 
> > > Reviewed-by: Ruiyu Ni 
> > > ---
> > >  ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
> > > b/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
> > > index 7d2e15f5206b..e502685a1dbb 100644
> > > --- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
> > > +++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
> > > @@ -506,7 +506,7 @@ PrintLsOutput(
> > >// Change the file time to local time.
> > >//
> > >Status = gRT->GetTime(, NULL);
> > > -  if (!EFI_ERROR (Status)) {
> > > +  if (!EFI_ERROR (Status) && (LocalTime.TimeZone !=
> > > EFI_UNSPECIFIED_TIMEZONE)) {
> > >  if ((Node->Info->CreateTime.TimeZone !=
> > > EFI_UNSPECIFIED_TIMEZONE) &&
> > >  (Node->Info->CreateTime.Month >= 1 && Node->Info-
> > > >CreateTime.Month <= 12)) {
> > >//
> > > --
> > > 2.17.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

Re: [edk2] [PATCH] MdePkg/UefiDebugLibConOut: Explicitely consume UefiLib.

[Marvin Häuser]

Sorry, you are right. The linker somehow blamed UefiDebugLibConOut for a module 
not declaring that dependency.

Regards,
Marvin.

> -Original Message-
> From: Gao, Liming 
> Sent: Monday, June 18, 2018 4:57 PM
> To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> Cc: Kinney, Michael D 
> Subject: RE: [PATCH] MdePkg/UefiDebugLibConOut: Explicitely consume
> UefiLib.
> 
> UefiDebugLibConOut depends on PrintLib. It doesn't call any API in UefiLib.
> 
> > -Original Message-
> > From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> > Sent: Sunday, June 17, 2018 12:15 AM
> > To: edk2-devel@lists.01.org
> > Cc: Kinney, Michael D ; Gao, Liming
> > 
> > Subject: [PATCH] MdePkg/UefiDebugLibConOut: Explicitely consume
> UefiLib.
> >
> > UefiDebugLibConOut does currently not consume UefiLib, from which it
> > uses the Print() function. This commit adds an explicit dependency.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Marvin Haeuser 
> > ---
> >  MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf
> > b/MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf
> > index 583872f54e81..64651c4169a8 100644
> > --- a/MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf
> > +++ b/MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf
> > @@ -46,6 +46,7 @@ [LibraryClasses]
> >PrintLib
> >UefiBootServicesTableLib
> >DebugPrintErrorLevelLib
> > +  UefiLib
> >
> >  [Pcd]
> >gEfiMdePkgTokenSpaceGuid.PcdDebugClearMemoryValue##
> SOMETIMES_CONSUMES
> > --
> > 2.17.1.windows.2

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

[edk2] [PATCH v3] SourceLevelDebugPkg/DebugCommunicationLibUsb: Add endpoint configuration.

[Marvin Häuser]

Currently, DebugCommunicationLibUsb uses the hardcoded endpoints 0x82
and 0x01 to communicate with the EHCI Debug Device. These, however,
are not standardized and may vary across different hardware.
To solve this problem, the endpoints are retrieved from the
USB Device Descriptor directly.

V2:
  - Store endpoint data in the USB Debug Port handle sturcture.

V3:
  - Remove the static endpoint PCDs as requested.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 
SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunicationLibUsb.c 
  | 18 --
 
SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunicationLibUsb.inf
 |  2 +-
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git 
a/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunicationLibUsb.c
 
b/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunicationLibUsb.c
index d996f80f59e3..1836c055267b 100644
--- 
a/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunicationLibUsb.c
+++ 
b/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunicationLibUsb.c
@@ -132,6 +132,14 @@ typedef struct _USB_DEBUG_PORT_HANDLE{
   //
   UINT32   EhciMemoryBase;
   //
+  // The usb debug device In endpoint.
+  //
+  UINT8InEndpoint;
+  //
+  // The usb debug device Out endpoint.
+  //
+  UINT8OutEndpoint;
+  //
   // The Bulk In endpoint toggle bit.
   //
   UINT8BulkInToggle;
@@ -722,6 +730,12 @@ InitializeUsbDebugHardware (
   return RETURN_DEVICE_ERROR;
 }
 
+//
+// Determine the usb debug device endpoints.
+//
+Handle->InEndpoint  = UsbDebugPortDescriptor.DebugInEndpoint;
+Handle->OutEndpoint = UsbDebugPortDescriptor.DebugOutEndpoint;
+
 //
 // enable the usb debug feature.
 //
@@ -879,7 +893,7 @@ DebugPortWriteBuffer (
   Sent = (UINT8)(NumberOfBytes - Total);
 }
 
-Status = UsbDebugPortOut(UsbDebugPortRegister, Buffer + Total, Sent, 
OUTPUT_PID, 0x7F, 0x01, UsbDebugPortHandle->BulkOutToggle);
+Status = UsbDebugPortOut(UsbDebugPortRegister, Buffer + Total, Sent, 
OUTPUT_PID, 0x7F, UsbDebugPortHandle->OutEndpoint, 
UsbDebugPortHandle->BulkOutToggle);
 
 if (RETURN_ERROR(Status)) {
   return Total;
@@ -959,7 +973,7 @@ DebugPortPollBuffer (
 UsbDebugPortRegister->SendPid  = DATA1_PID;
   }
   UsbDebugPortRegister->UsbAddress  = 0x7F;
-  UsbDebugPortRegister->UsbEndPoint = 0x82 & 0x0F;
+  UsbDebugPortRegister->UsbEndPoint = UsbDebugPortHandle->InEndpoint & 0x0F;
 
   //
   // Clearing W/R bit to indicate it's a READ operation
diff --git 
a/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunicationLibUsb.inf
 
b/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunicationLibUsb.inf
index 028b04afbf00..8009f62075ff 100644
--- 
a/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunicationLibUsb.inf
+++ 
b/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunicationLibUsb.inf
@@ -45,7 +45,7 @@ [Pcd]
   gEfiSourceLevelDebugPkgTokenSpaceGuid.PcdUsbEhciPciAddress  ## 
CONSUMES
   # The value of data buffer size used for USB debug port handle.
   # It should be equal to sizeof (USB_DEBUG_PORT_HANDLE).
-  gEfiSourceLevelDebugPkgTokenSpaceGuid.PcdDebugPortHandleBufferSize|23   ## 
SOMETIMES_CONSUMES
+  gEfiSourceLevelDebugPkgTokenSpaceGuid.PcdDebugPortHandleBufferSize|25   ## 
SOMETIMES_CONSUMES
 
 [LibraryClasses]
   TimerLib
-- 
2.17.1.windows.2

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

[edk2] [PATCH] BaseTools/WorkspaceCommon: Import used BuildToolError messages.

[Marvin Häuser]

Commit c14b58614ffb992dfc668966a19becb86614aafc added a few build
error message display calls to WorkspaceCommon.py without importing
the message resources explicitely. This commit adds imports the
missing directives.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 BaseTools/Source/Python/Workspace/WorkspaceCommon.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/BaseTools/Source/Python/Workspace/WorkspaceCommon.py 
b/BaseTools/Source/Python/Workspace/WorkspaceCommon.py
index a28fbdf03021..713c1ddbddc9 100644
--- a/BaseTools/Source/Python/Workspace/WorkspaceCommon.py
+++ b/BaseTools/Source/Python/Workspace/WorkspaceCommon.py
@@ -16,6 +16,9 @@ from Common.DataType import SUP_MODULE_USER_DEFINED
 from BuildClassObject import LibraryClassObject
 import Common.GlobalData as GlobalData
 from Workspace.BuildClassObject import StructurePcd
+from Common.BuildToolError import RESOURCE_NOT_AVAILABLE
+from Common.BuildToolError import OPTION_MISSING
+from Common.BuildToolError import BUILD_ERROR
 
 class OrderedListDict(OrderedDict, defaultdict):
 def __init__(self, *args, **kwargs):
-- 
2.17.1.windows.2

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

[edk2] [PATCH] MdePkg/UefiDebugLibConOut: Explicitely consume UefiLib.

[Marvin Häuser]

UefiDebugLibConOut does currently not consume UefiLib, from which it
uses the Print() function. This commit adds an explicit dependency.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf 
b/MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf
index 583872f54e81..64651c4169a8 100644
--- a/MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf
+++ b/MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf
@@ -46,6 +46,7 @@ [LibraryClasses]
   PrintLib
   UefiBootServicesTableLib
   DebugPrintErrorLevelLib
+  UefiLib
 
 [Pcd]
   gEfiMdePkgTokenSpaceGuid.PcdDebugClearMemoryValue## 
SOMETIMES_CONSUMES
-- 
2.17.1.windows.2

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

[edk2] [PATCH] MdePkg/SerialIo: Fix inaccurate header comment.

[Marvin Häuser]

EFI_SERIAL_READ currently has comments suggesting a write function.
Update those comments to express it being the Read function.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Include/Protocol/SerialIo.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdePkg/Include/Protocol/SerialIo.h 
b/MdePkg/Include/Protocol/SerialIo.h
index 1263dc4fe973..b155a19cac8b 100644
--- a/MdePkg/Include/Protocol/SerialIo.h
+++ b/MdePkg/Include/Protocol/SerialIo.h
@@ -199,7 +199,7 @@ EFI_STATUS
   );
 
 /**
-  Writes data to a serial device.
+  Reads data from a serial device.
 
   @param  This  Protocol instance pointer.
   @param  BufferSizeOn input, the size of the Buffer. On output, the 
amount of
@@ -208,7 +208,7 @@ EFI_STATUS
 
   @retval EFI_SUCCESS   The data was read.
   @retval EFI_DEVICE_ERROR  The device reported an error.
-  @retval EFI_TIMEOUT   The data write was stopped due to a timeout.
+  @retval EFI_TIMEOUT   The data read was stopped due to a timeout.
 
 **/
 typedef
-- 
2.17.1.windows.2

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

Re: [edk2] [PATCH v2] SourceLevelDebugPkg/DebugCommunicationLibUsb: Add endpoint configuration.

[Marvin Häuser]

Hey Hao,

I don't require hardcoded endpoint information, but I have only one debug 
device to test with in the first place.
The static endpoint option was added in case there are Debug Devices around 
which report incorrect information.
I assumed that was part of the reason the endpoints were hardcoded in the first 
place.

Do you want me to submit a V2 without the PCDs?

Thanks,
Marvin.

> -Original Message-
> From: Wu, Hao A 
> Sent: Thursday, June 14, 2018 9:03 AM
> To: Marvin Häuser ; edk2-
> de...@lists.01.org
> Cc: Ni, Ruiyu 
> Subject: RE: [PATCH v2] SourceLevelDebugPkg/DebugCommunicationLibUsb:
> Add endpoint configuration.
> 
> Hi Marvin,
> 
> One thing to confirm with you. For your using case, do you need to hard-
> code the IN/OUT endpoints for EHCI debug device?
> 
> If not, I think we can just remove the hard-code endpoints settings in the
> current code. And use the endpoints returned from the USB Device
> Descriptor.
> By doing so, I think we can avoid adding those 2 PCDs.
> 
> Please let me know your thoughts on this. Thanks in advance.
> 
> Best Regards,
> Hao Wu
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Marvin Häuser
> > Sent: Thursday, June 14, 2018 3:58 AM
> > To: edk2-devel@lists.01.org
> > Cc: Wu, Hao A
> > Subject: [edk2] [PATCH v2]
> SourceLevelDebugPkg/DebugCommunicationLibUsb:
> > Add endpoint configuration.
> >
> > Currently, DebugCommunicationLibUsb uses the hardcoded endpoints
> 0x82
> > and 0x01 to communicate with the EHCI Debug Device. These, however,
> > are not standardized and may vary across different hardware.
> > To solve this problem, two PCDs have been introduced to configure the
> > in and out endpoints of the EHCI Debug Device. These may be set to 0
> > to retrieve the endpoints from the USB Device Descriptor directly.
> > To ensure maximum compatibility, the PCD defaults have been set to the
> > former hardcoded values.
> >
> > V2:
> >   - Store endpoint data in the USB Debug Port handle sturcture.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Marvin Haeuser 
> > ---
> >
> >
> SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommun
> ica
> > tionLibUsb.c   | 32 ++--
> >
> >
> SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommun
> ica
> > tionLibUsb.inf |  6 +++-
> >  SourceLevelDebugPkg/SourceLevelDebugPkg.dec
> >| 12
> > 
> >  3 files changed, 47 insertions(+), 3 deletions(-)
> >
> > diff --git
> >
> a/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugComm
> uni
> > cationLibUsb.c
> >
> b/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugComm
> uni
> > cationLibUsb.c
> > index d996f80f59e3..a9a9ea07a39b 100644
> > ---
> >
> a/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugComm
> uni
> > cationLibUsb.c
> > +++
> >
> b/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugComm
> uni
> > cationLibUsb.c
> > @@ -132,6 +132,14 @@ typedef struct _USB_DEBUG_PORT_HANDLE{
> >//
> >UINT32   EhciMemoryBase;
> >//
> > +  // The usb debug device In endpoint.
> > +  //
> > +  UINT8InEndpoint;
> > +  //
> > +  // The usb debug device Out endpoint.
> > +  //
> > +  UINT8OutEndpoint;
> > +  //
> >// The Bulk In endpoint toggle bit.
> >//
> >UINT8BulkInToggle;
> > @@ -603,6 +611,8 @@ InitializeUsbDebugHardware (
> >UINT32*UsbHCSParam;
> >UINT8 DebugPortNumber;
> >UINT8 Length;
> > +  UINT8 InEndpoint;
> > +  UINT8 OutEndpoint;
> >
> >UsbDebugPortRegister = (USB_DEBUG_PORT_REGISTER
> *)((UINTN)Handle-
> > >UsbDebugPortMemoryBase + Handle->DebugPortOffset);
> >UsbHCSParam = (UINT32 *)((UINTN)Handle->EhciMemoryBase + 0x04);
> @@
> > -722,6 +732,24 @@ InitializeUsbDebugHardware (
> >return RETURN_DEVICE_ERROR;
> >  }
> >
> > +//
> > +// Determine the usb debug device endpoints.
> > +//
> > +InEndpoint = PcdGet8 (PcdUsbDebugPortInEndpoint);
> > +
> > +if (InEndpoint == 0) {
> > +  InEndpoint = UsbDebugPortDescriptor.DebugInEndpoint;
> > +}
> > +
> > +OutEndpoint = PcdGet8 (PcdUsbDebugPortOutEndpo

Re: [edk2] [PATCH v2] ShellPkg/UefiShellLevel2CommandsLib: Support unspecified local Timezone.

[Marvin Häuser]

Good day Ruiyu,

Sorry, but you have not ack'd this V2 yet. Is there anything wrong you want me 
to correct?

Thanks,
Marvin.

> -Original Message-
> From: Carsey, Jaben 
> Sent: Thursday, May 17, 2018 4:15 PM
> To: Marvin Häuser ; edk2-
> de...@lists.01.org
> Cc: Ni, Ruiyu 
> Subject: RE: [PATCH v2] ShellPkg/UefiShellLevel2CommandsLib: Support
> unspecified local Timezone.
> 
> Still looks good to me.  Ray?
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Marvin Häuser
> > Sent: Thursday, May 17, 2018 5:43 AM
> > To: edk2-devel@lists.01.org
> > Cc: Carsey, Jaben ; Ni, Ruiyu
> > 
> > Subject: [edk2] [PATCH v2] ShellPkg/UefiShellLevel2CommandsLib:
> > Support unspecified local Timezone.
> > Importance: High
> >
> > EFI_RUNTIME_SERVICES.GetTime() might return an unspecified Timezone,
> > such as when SetTime() has not been called after the PC-AT CMOS RTC
> > was cut off power. Consider this case by not attempting Timezone
> > translations for when it is invalid.
> >
> > V2:
> >   - Do not change the copyright date as requested.
> >   - Added R-bs from V1 as no functional changes have been made.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Marvin Haeuser 
> > Reviewed-by: Jaben Carsey 
> > Reviewed-by: Ruiyu Ni 
> > ---
> >  ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
> > b/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
> > index 7d2e15f5206b..e502685a1dbb 100644
> > --- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
> > +++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
> > @@ -506,7 +506,7 @@ PrintLsOutput(
> >// Change the file time to local time.
> >//
> >Status = gRT->GetTime(, NULL);
> > -  if (!EFI_ERROR (Status)) {
> > +  if (!EFI_ERROR (Status) && (LocalTime.TimeZone !=
> > EFI_UNSPECIFIED_TIMEZONE)) {
> >  if ((Node->Info->CreateTime.TimeZone !=
> > EFI_UNSPECIFIED_TIMEZONE) &&
> >  (Node->Info->CreateTime.Month >= 1 && Node->Info-
> > >CreateTime.Month <= 12)) {
> >//
> > --
> > 2.17.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

Re: [edk2] [PATCH v2] MdePkg/UefiFileHandleLib: Fix the Root directory determination.

[Marvin Häuser]

Hey Liming and Mike,

Sorry, but I have seen this and another patch to UefiFileHandleLib have not 
been reviewed and/or merged yet.
Is there anything wrong with the patches?

Thanks,
Marvin.

> -Original Message-
> From: edk2-devel  On Behalf Of Marvin
> Häuser
> Sent: Thursday, May 17, 2018 2:42 PM
> To: edk2-devel@lists.01.org
> Cc: michael.d.kin...@intel.com; liming@intel.com
> Subject: [edk2] [PATCH v2] MdePkg/UefiFileHandleLib: Fix the Root directory
> determination.
> 
> The current implementation of the FileHandleGetFileName() function
> assumes that the Root directory always has the FileName '\0'.
> However, the only requirement the UEFI specification defines is that a
> prepended '\\' must be supported to access files and folders relative to the
> Root directory.
> This patch removes this assumption and supports constructing valid paths for
> any value of FileName for the Root Directory.
> 
> In praxis, this fixes compatibility issues with File System drivers that 
> report
> '\\' as the FileName of the Root directory, which currently is both generating
> an invalid path ("") and resulting in an EFI_NOT_FOUND result from the
> CurrentHandle->Open() call.
> 
> V2:
>   - Do not change the copyright date as requested.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marvin Haeuser 
> ---
>  MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c | 27
> ++--
>  1 file changed, 19 insertions(+), 8 deletions(-)
> 
> diff --git a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
> b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
> index 57aad77bc135..251cbc55edb5 100644
> --- a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
> +++ b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
> @@ -820,10 +820,25 @@ FileHandleGetFileName (
>  Status = EFI_OUT_OF_RESOURCES;
>  break;
>} else {
> +//
> +// Prepare to move to the parent directory.
> +// Also determine whether CurrentHandle refers to the Root directory.
> +//
> +Status = CurrentHandle->Open (CurrentHandle, ,
> + L"..", EFI_FILE_MODE_READ, 0);
>  //
>  // We got info... do we have a name? if yes precede the current path
> with it...
>  //
> -if (StrLen (FileInfo->FileName) == 0) {
> +if ((StrLen (FileInfo->FileName) == 0) || EFI_ERROR (Status)) {
> +  //
> +  // Both FileInfo->FileName being '\0' and EFI_ERROR() suggest that
> +  // CurrentHandle refers to the Root directory.  As this loop 
> ensures
> +  // FullFileName is starting with '\\' at all times, signal success
> +  // and exit the loop.
> +  // While FileInfo->FileName could theoretically be a value other 
> than
> +  // '\0' or '\\', '\\' is guaranteed to be supported by the
> +  // specification and hence its value can safely be ignored.
> +  //
> +  Status = EFI_SUCCESS;
>if (*FullFileName == NULL) {
>  ASSERT((*FullFileName == NULL && Size == 0) || (*FullFileName !=
> NULL));
>  *FullFileName = StrnCatGrowLeft(FullFileName, , L"\\", 0); 
> @@ -
> 841,15 +856,11 @@ FileHandleGetFileName (
>FreePool(FileInfo);
>  }
>}
> -  //
> -  // Move to the parent directory
> -  //
> -  Status = CurrentHandle->Open (CurrentHandle, ,
> L"..", EFI_FILE_MODE_READ, 0);
> -  if (EFI_ERROR (Status)) {
> -break;
> -  }
> 
>FileHandleClose(CurrentHandle);
> +  //
> +  // Move to the parent directory
> +  //
>CurrentHandle = NextHigherHandle;
>  }
>} else if (Status == EFI_NOT_FOUND) {
> --
> 2.17.0.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2] SourceLevelDebugPkg/DebugCommunicationLibUsb: Add endpoint configuration.

[Marvin Häuser]

Currently, DebugCommunicationLibUsb uses the hardcoded endpoints 0x82
and 0x01 to communicate with the EHCI Debug Device. These, however,
are not standardized and may vary across different hardware.
To solve this problem, two PCDs have been introduced to configure the
in and out endpoints of the EHCI Debug Device. These may be set to 0
to retrieve the endpoints from the USB Device Descriptor directly.
To ensure maximum compatibility, the PCD defaults have been set to
the former hardcoded values.

V2:
  - Store endpoint data in the USB Debug Port handle sturcture.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 
SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunicationLibUsb.c 
  | 32 ++--
 
SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunicationLibUsb.inf
 |  6 +++-
 SourceLevelDebugPkg/SourceLevelDebugPkg.dec
   | 12 
 3 files changed, 47 insertions(+), 3 deletions(-)

diff --git 
a/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunicationLibUsb.c
 
b/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunicationLibUsb.c
index d996f80f59e3..a9a9ea07a39b 100644
--- 
a/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunicationLibUsb.c
+++ 
b/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunicationLibUsb.c
@@ -132,6 +132,14 @@ typedef struct _USB_DEBUG_PORT_HANDLE{
   //
   UINT32   EhciMemoryBase;
   //
+  // The usb debug device In endpoint.
+  //
+  UINT8InEndpoint;
+  //
+  // The usb debug device Out endpoint.
+  //
+  UINT8OutEndpoint;
+  //
   // The Bulk In endpoint toggle bit.
   //
   UINT8BulkInToggle;
@@ -603,6 +611,8 @@ InitializeUsbDebugHardware (
   UINT32*UsbHCSParam;
   UINT8 DebugPortNumber;
   UINT8 Length;
+  UINT8 InEndpoint;
+  UINT8 OutEndpoint;
 
   UsbDebugPortRegister = (USB_DEBUG_PORT_REGISTER 
*)((UINTN)Handle->UsbDebugPortMemoryBase + Handle->DebugPortOffset);
   UsbHCSParam = (UINT32 *)((UINTN)Handle->EhciMemoryBase + 0x04);
@@ -722,6 +732,24 @@ InitializeUsbDebugHardware (
   return RETURN_DEVICE_ERROR;
 }
 
+//
+// Determine the usb debug device endpoints.
+//
+InEndpoint = PcdGet8 (PcdUsbDebugPortInEndpoint);
+
+if (InEndpoint == 0) {
+  InEndpoint = UsbDebugPortDescriptor.DebugInEndpoint;
+}
+
+OutEndpoint = PcdGet8 (PcdUsbDebugPortOutEndpoint);
+
+if (OutEndpoint == 0) {
+  OutEndpoint = UsbDebugPortDescriptor.DebugOutEndpoint;
+}
+
+Handle->InEndpoint  = InEndpoint;
+Handle->OutEndpoint = OutEndpoint;
+
 //
 // enable the usb debug feature.
 //
@@ -879,7 +907,7 @@ DebugPortWriteBuffer (
   Sent = (UINT8)(NumberOfBytes - Total);
 }
 
-Status = UsbDebugPortOut(UsbDebugPortRegister, Buffer + Total, Sent, 
OUTPUT_PID, 0x7F, 0x01, UsbDebugPortHandle->BulkOutToggle);
+Status = UsbDebugPortOut(UsbDebugPortRegister, Buffer + Total, Sent, 
OUTPUT_PID, 0x7F, UsbDebugPortHandle->OutEndpoint, 
UsbDebugPortHandle->BulkOutToggle);
 
 if (RETURN_ERROR(Status)) {
   return Total;
@@ -959,7 +987,7 @@ DebugPortPollBuffer (
 UsbDebugPortRegister->SendPid  = DATA1_PID;
   }
   UsbDebugPortRegister->UsbAddress  = 0x7F;
-  UsbDebugPortRegister->UsbEndPoint = 0x82 & 0x0F;
+  UsbDebugPortRegister->UsbEndPoint = UsbDebugPortHandle->InEndpoint & 0x0F;
 
   //
   // Clearing W/R bit to indicate it's a READ operation
diff --git 
a/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunicationLibUsb.inf
 
b/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunicationLibUsb.inf
index 028b04afbf00..eb55e5ee0f63 100644
--- 
a/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunicationLibUsb.inf
+++ 
b/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunicationLibUsb.inf
@@ -43,9 +43,13 @@ [Pcd]
   # The pci address of ehci host controller, in which usb debug feature is 
enabled.
   # The format of pci address please refer to SourceLevelDebugPkg.dec
   gEfiSourceLevelDebugPkgTokenSpaceGuid.PcdUsbEhciPciAddress  ## 
CONSUMES
+  # The endpoint that should be used for read transactions from the usb debug 
device.
+  gEfiSourceLevelDebugPkgTokenSpaceGuid.PcdUsbDebugPortInEndpoint ## 
CONSUMES
+  # The endpoint that should be used for write transactions to the usb debug 
device.
+  gEfiSourceLevelDebugPkgTokenSpaceGuid.PcdUsbDebugPortOutEndpoint## 
CONSUMES
   # The value of data buffer size used for USB debug port handle.
   # It should be equal to sizeof (USB_DEBUG_PORT_HANDLE).
-  gEfiSourceLevelDebugPkgTokenSpaceGuid.PcdDebugPortHandleBufferSize|23   ## 
SOMETIMES_CONSUMES
+  gEfiSourceLevelDebugPkgTokenSpaceGuid.PcdDebugPortHandleBufferSize|25   ## 
SOMETIMES_CONSUMES
 
 [LibraryClasses]
   TimerLib
diff --git 

Re: [edk2] [PATCH] SourceLevelDebugPkg/DebugCommunicationLibUsb: Add endpoint configuration.

[Marvin Häuser]

Sorry, I made a mistake overlooking that the Initialization function is only 
called under certain circumstances.
I will submit a V2 soon.

Thanks,
Marvin

> -Original Message-
> From: edk2-devel  On Behalf Of Marvin
> Häuser
> Sent: Tuesday, June 12, 2018 2:34 PM
> To: edk2-devel@lists.01.org
> Cc: hao.a...@intel.com
> Subject: [edk2] [PATCH]
> SourceLevelDebugPkg/DebugCommunicationLibUsb: Add endpoint
> configuration.
> 
> Currently, DebugCommunicationLibUsb uses the hardcoded endpoints 0x82
> and 0x01 to communicate with the EHCI Debug Device. These, however, are
> not standardized and may vary across different hardware.
> To solve this problem, two PCDs have been introduced to configure the in
> and out endpoints of the EHCI Debug Device. These may be set to 0 to
> retrieve the endpoints from the USB Device Descriptor directly.
> To ensure maximum compatibility, the PCD defaults have been set to the
> former hardcoded values.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marvin Haeuser 
> ---
> 
> SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommun
> icationLibUsb.c   | 46 +---
> 
> SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommun
> icationLibUsb.inf |  4 ++
>  SourceLevelDebugPkg/SourceLevelDebugPkg.dec  
>  | 12
> +
>  3 files changed, 55 insertions(+), 7 deletions(-)
> 
> diff --git
> a/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugComm
> unicationLibUsb.c
> b/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugComm
> unicationLibUsb.c
> index d996f80f59e3..bb4be7b0710f 100644
> ---
> a/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugComm
> unicationLibUsb.c
> +++
> b/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugComm
> unic
> +++ ationLibUsb.c
> @@ -583,6 +583,8 @@ NeedReinitializeHardware(
>5. configure the usb debug device to debug mode.
> 
>@param  Handle   Debug port handle.
> +  @param  DebugInEndpoint  IN Endpoint of the usb debug device.
> +  @param  DebugOutEndpoint OUT Endpoint of the usb debug device.
> 
>@retval TRUE The usb debug port hardware configuration is 
> changed.
>@retval FALSEThe usb debug port hardware configuration is not
> changed.
> @@ -591,7 +593,9 @@ NeedReinitializeHardware(  RETURN_STATUS  EFIAPI
> InitializeUsbDebugHardware (
> -  IN USB_DEBUG_PORT_HANDLE *Handle
> +  IN  USB_DEBUG_PORT_HANDLE *Handle,
> +  OUT UINT8 *DebugInEndpoint, OPTIONAL
> +  OUT UINT8 *DebugOutEndpoint OPTIONAL
>  )
>  {
>RETURN_STATUS Status;
> @@ -722,6 +726,14 @@ InitializeUsbDebugHardware (
>return RETURN_DEVICE_ERROR;
>  }
> 
> +if (DebugInEndpoint != NULL) {
> +  *DebugInEndpoint = UsbDebugPortDescriptor.DebugInEndpoint;
> +}
> +
> +if (DebugOutEndpoint != NULL) {
> +  *DebugOutEndpoint = UsbDebugPortDescriptor.DebugOutEndpoint;
> +}
> +
>  //
>  // enable the usb debug feature.
>  //
> @@ -790,7 +802,7 @@ DebugPortReadBuffer (
>}
> 
>if (NeedReinitializeHardware(UsbDebugPortHandle)) {
> -Status = InitializeUsbDebugHardware (UsbDebugPortHandle);
> +Status = InitializeUsbDebugHardware (UsbDebugPortHandle, NULL,
> + NULL);
>  if (RETURN_ERROR(Status)) {
>return 0;
>  }
> @@ -845,6 +857,8 @@ DebugPortWriteBuffer (
>UINT8 Sent;
>UINTN Total;
>UINT8 ReceivedPid;
> +  UINT8 OutEndpoint;
> +  UINT8 StaticOutEndpoint;
> 
>if (NumberOfBytes == 0 || Buffer == NULL) {
>  return 0;
> @@ -864,12 +878,20 @@ DebugPortWriteBuffer (
>}
> 
>if (NeedReinitializeHardware(UsbDebugPortHandle)) {
> -Status = InitializeUsbDebugHardware (UsbDebugPortHandle);
> +Status = InitializeUsbDebugHardware (UsbDebugPortHandle, NULL,
> + );
>  if (RETURN_ERROR(Status)) {
>return 0;
>  }
>}
> 
> +  StaticOutEndpoint = PcdGet8 (PcdUsbDebugPortOutEndpoint);  //  // If
> + the endpoint has been configured statically, use it.
> +  //
> +  if (StaticOutEndpoint != 0) {
> +OutEndpoint = StaticOutEndpoint;
> +  }
> +
>UsbDebugPortRegister = (USB_DEBUG_PORT_REGISTER
> *)((UINTN)UsbDebugPortHandle->UsbDebugPortMemoryBase +
> UsbDebugPortHandle->DebugPortOffset);
> 
>while ((Total < NumberOfBytes)) {
> @@ -879,7 +901,7 @@ DebugPortWriteBuffer (
>Sent = (UINT8)(NumberOfBytes - Total);
>  }
> 
> -Status = UsbDebugPortOut(Usb

Re: [edk2] CpuS3DataDxe / DxeRegisterCpuFeaturesLib dependency.

[Marvin Häuser]

Hey Jeff,

Of course I meant to introduce a “gEdkiiCpuS3DataAvailablePpiGuid” or similar 
to create a Depex on.

Thanks,
Marvin.

From: Fan Jeff <vanjeff_...@hotmail.com>
Sent: Monday, May 28, 2018 4:19 PM
To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
Cc: ler...@redhat.com; eric.d...@intel.com
Subject: Re:RE: [edk2] CpuS3DataDxe / DxeRegisterCpuFeaturesLib dependency.

Marvin,

Thanks your reply. i have thought my mail hasn't sent out just now.

Adding CpuS3DataPei depends on wether we need to suppoert S3 without DXE, i 
think.

Even we add CpuS3DataPei, we cannot assume the dispatch order between 
CpuFeaturesPei and CpuS3DataPei from core code view. So,we cannot remove those 
code to produce PCD if it does not exist.

Thanks!
Jeff






发自我的小米手机
在 Marvin Häuser 
<marvin.haeu...@outlook.com<mailto:marvin.haeu...@outlook.com>>，2018年5月28日 
下午9:55写道：
Hey Jeff,

Thanks for looking into it!

Maybe both should be implemented (PEI and additional DXE Depex) and leave it to 
the platform maintainer, as with CpuFeaturesPei vs CpuFeaturesDxe?
If the platform PEI happens to not consume PCD, PcdPei would need to be 
introduced just to support “CpuS3DataPei”.
On the other hand, when e.g. CpuFeaturesPei is used anyway, it makes good sense 
to choose CpuS3DataPei over CpuS3DataDxe and remove the PCD allocation code 
from CpuFeaturesPei.

Regards,
Marvin.

From: Fan Jeff <vanjeff_...@hotmail.com<mailto:vanjeff_...@hotmail.com>>
Sent: Monday, May 28, 2018 11:51 AM
To: Laszlo Ersek <ler...@redhat.com<mailto:ler...@redhat.com>>; Marvin Häuser 
<marvin.haeu...@outlook.com<mailto:marvin.haeu...@outlook.com>>
Cc: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; 
eric.d...@intel.com<mailto:eric.d...@intel.com>
Subject: 答复: [edk2] CpuS3DataDxe / DxeRegisterCpuFeaturesLib dependency.


Hi,



The current implementation assumes CpuS3DataDxe was dispatched before 
CpuFeaturesDxe. I do not remember clearly why I made this assumption before. 
(It maybe only due to CpuS3DataDxe was just dispatched firstly on all my 
validation platforms.),

I agree this is one bug.  Simply, we could implement one AllocateAcpiCpuData() 
in DXE instance as PEI instance.



Thanks!

Jeff




From: edk2-devel 
<edk2-devel-boun...@lists.01.org<mailto:edk2-devel-boun...@lists.01.org>> on 
behalf of Laszlo Ersek <ler...@redhat.com<mailto:ler...@redhat.com>>
Sent: Friday, May 25, 2018 7:40:32 PM
To: Marvin Häuser
Cc: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; 
eric.d...@intel.com<mailto:eric.d...@intel.com>
Subject: Re: [edk2] CpuS3DataDxe / DxeRegisterCpuFeaturesLib dependency.

On 05/25/18 12:54, Marvin H?user wrote:
> Good day,
>
> While I was inspecting CpuS3DataDxe and the modules depending on its
> PCD PcdCpuS3DataAddress,

(Side remark: see e.g. the commit message on 92b87f1c8c0b, "OvmfPkg:
build CpuS3DataDxe for -D SMM_REQUIRE", 2015-11-30.)

> I noticed that DxeRegisterCpuFeaturesLib seemingly has an asserted
> dependency on the PCD being ready when it its executed. I did neither
> see a Depex entry, nor an event callback ensuring CpuS3DataDxe has
> been loaded, neither exposed by CpuS3DataDxe, nor consumed by this
> library.
> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/Library/RegisterCpuFeaturesLib/DxeRegisterCpuFeaturesLib.c#L211

"DxeRegisterCpuFeaturesLib.inf" has a depex on
"gEdkiiCpuFeaturesSetDoneGuid".

No module in the open source edk2 tree produces this protocol GUID, thus
I think this library instance is unusable without other, out-of-tree,
modules. I assume that one of those modules satisfies the dependency
somehow.

Note that CpuS3DataDxe is a platform driver [1]; it is possible that the
platform that includes DxeRegisterCpuFeaturesLib in a driver *also*
includes such a CpuS3DataDxe variant that populates the PCD and then
installs gEdkiiCpuFeaturesSetDoneGuid.

[1] I suggest reviewing the message of commit bfec5efa56ca
("UefiCpuPkg/CpuS3DataDxe: Add module to initialize ACPI_CPU_DATA for
S3", 2015-11-25).

In fact, the series that added "DxeRegisterCpuFeaturesLib.inf" (with the
depex mentioned above) *also* modified CpuS3DataDxe: see [2] and [3].

[2] 8b371e93f206 ("UefiCpuPkg/CpuS3DataDxe: Consume the existing
PcdCpuS3DataAddress", 2017-03-22)

[3] "[edk2] [PATCH 00/11] Add CPU features driver"
https://bugzilla.tianocore.org/show_bug.cgi?id=421
http://mid.mail-archive.com/20170309083553.6016-1-jeff.fan@intel.com

This suggests that there is an out-of-tree module that populates
PcdCpuS3DataAddress before *both* CpuS3DataDxe and
DxeRegisterCpuFeaturesLib access the PCD. For achieving this kind of
ordering, it would be enough for a driver to first populate the PCD, and
then install "gEfiMpServiceProtocolGuid", as both
"DxeRegisterC

Re: [edk2] smm lock query

[Marvin Häuser]

Hello Andrew and Laszlo,

Thanks for your comments!
Of course I'm with you that it is the platform that signals the SmmReadyToLock 
event and therefor is aware.
However, they might rely on the protocol's description that the resources are 
about(!) to be locked and code accordingly, not considering the event 
characteristic of the handler in PiSmmIpl.
The code might be written by different people, not especially reviewed against 
edk2's actions, or additional code might be supplied by third parties that do 
not have tree code access (which, by integration, would be "platform binaries" 
by the definition applying here).

Therefor I would still ask everyone to consider figuring out a solution to this 
discrepancy from the specification, such as the internal "dummy event" I 
proposed.

Thanks,
Marvin.

> -Original Message-
> From: Laszlo Ersek 
> Sent: Monday, May 28, 2018 12:58 PM
> To: Andrew Fish ; Marvin H?user
> 
> Cc: edk2-devel@lists.01.org; Abhishek Singh ;
> ruiyu...@intel.com; eric.d...@intel.com; star.z...@intel.com
> Subject: Re: [edk2] smm lock query
> 
> On 05/27/18 22:44, Andrew Fish wrote:
> >
> >
> >> On May 27, 2018, at 9:47 AM, Marvin H?user
>  wrote:
> >>
> >> Good day Abhishek,
> >>
> >> I CC'd the MdeModulePkg maintainers, Ruiyu for the Platform BDS aspect
> (exposes the ReadyToLock protocol) and Laszlo for his high-quality answers.
> >>
> >> Strictly speaking you are, right, because of the description for the MM
> protocol:
> >> "Indicates that MM resources and services that should not be used by the
> third party code are about[Marvin: (!)] to be locked."
> >> Practically however, I don't see any issue with the current
> implementation. Code inside MMRAM is not affected directly by the lock, it is
> just notified.
> >> However, either the code or the specification should be slightly updated
> to be in sync. A code update might require review of the caller assumptions,
> just to be sure.
> >>
> >> I have a different concern though and hope I'm actually overlooking
> something.
> >> If I understand the code correctly, it is the Platform BDS that exposes the
> (S)MmReadyToLock protocol. PiSmmIpl seems to consume that event and
> lock SMM resources based on the event.
> >> Because of latter being an event however, I don't think it is, or can be,
> guaranteed to be the last event group member executing.
> >> When it is not the last, the "about to be locked" part is not true for any
> subsequent callbacks, that could actually be a risky break of the 
> specification
> - if it is.
> >> If it is a break of the specification, I can only think of letting 
> >> Platform BDS
> expose an "internal" event group, which is only caught by PiSmmIpl, which
> then drives the actual SmmReadyToLock flow.
> >> This would require updates to all platform trees and hence I would
> propose a temporary backwards-compatibility.
> >>
> >> Any comments? Did I overlook something (I hope)?
> >>
> >
> > Mavvin,
> >
> > You are correct there is no guarantee of order in events. Thanks for cc'ing
> the right folks, as I don't remember all the low level details...
> >
> > In general the idea behind the MM code is it only comes from the platform,
> then by definition that code should be aware when the platform was going
> to lock MM. In a practical sense any MM module that had a depex evaluate
> to true would have dispatched in DXE prior to BDS being launched. In general
> BDS is the code that enumerates PCI and connects devices, thus there is no
> chance for 3rd party software to run before that point in the boot. So in an
> abstract sense that lock represents the end of DXE dispatch.
> 
> This is my understanding as well. gEfiDxeSmmReadyToLockProtocolGuid is
> installed by Plaform BDS before any non-platform binaries get a chance to
> run. In terms of the current PlatformBootManagerLib interfaces, that means
> the protocol should be installed from
> PlatformBootManagerBeforeConsole() (as noted on the API declaration
> itself).
> 
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] CpuS3DataDxe / DxeRegisterCpuFeaturesLib dependency.

[Marvin Häuser]

Hey Jeff,

Thanks for looking into it!

Maybe both should be implemented (PEI and additional DXE Depex) and leave it to 
the platform maintainer, as with CpuFeaturesPei vs CpuFeaturesDxe?
If the platform PEI happens to not consume PCD, PcdPei would need to be 
introduced just to support “CpuS3DataPei”.
On the other hand, when e.g. CpuFeaturesPei is used anyway, it makes good sense 
to choose CpuS3DataPei over CpuS3DataDxe and remove the PCD allocation code 
from CpuFeaturesPei.

Regards,
Marvin.

From: Fan Jeff <vanjeff_...@hotmail.com>
Sent: Monday, May 28, 2018 11:51 AM
To: Laszlo Ersek <ler...@redhat.com>; Marvin Häuser <marvin.haeu...@outlook.com>
Cc: edk2-devel@lists.01.org; eric.d...@intel.com
Subject: 答复: [edk2] CpuS3DataDxe / DxeRegisterCpuFeaturesLib dependency.


Hi,



The current implementation assumes CpuS3DataDxe was dispatched before 
CpuFeaturesDxe. I do not remember clearly why I made this assumption before. 
(It maybe only due to CpuS3DataDxe was just dispatched firstly on all my 
validation platforms.),

I agree this is one bug.  Simply, we could implement one AllocateAcpiCpuData() 
in DXE instance as PEI instance.



Thanks!

Jeff




From: edk2-devel 
<edk2-devel-boun...@lists.01.org<mailto:edk2-devel-boun...@lists.01.org>> on 
behalf of Laszlo Ersek <ler...@redhat.com<mailto:ler...@redhat.com>>
Sent: Friday, May 25, 2018 7:40:32 PM
To: Marvin Häuser
Cc: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; 
eric.d...@intel.com<mailto:eric.d...@intel.com>
Subject: Re: [edk2] CpuS3DataDxe / DxeRegisterCpuFeaturesLib dependency.

On 05/25/18 12:54, Marvin H?user wrote:
> Good day,
>
> While I was inspecting CpuS3DataDxe and the modules depending on its
> PCD PcdCpuS3DataAddress,

(Side remark: see e.g. the commit message on 92b87f1c8c0b, "OvmfPkg:
build CpuS3DataDxe for -D SMM_REQUIRE", 2015-11-30.)

> I noticed that DxeRegisterCpuFeaturesLib seemingly has an asserted
> dependency on the PCD being ready when it its executed. I did neither
> see a Depex entry, nor an event callback ensuring CpuS3DataDxe has
> been loaded, neither exposed by CpuS3DataDxe, nor consumed by this
> library.
> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/Library/RegisterCpuFeaturesLib/DxeRegisterCpuFeaturesLib.c#L211

"DxeRegisterCpuFeaturesLib.inf" has a depex on
"gEdkiiCpuFeaturesSetDoneGuid".

No module in the open source edk2 tree produces this protocol GUID, thus
I think this library instance is unusable without other, out-of-tree,
modules. I assume that one of those modules satisfies the dependency
somehow.

Note that CpuS3DataDxe is a platform driver [1]; it is possible that the
platform that includes DxeRegisterCpuFeaturesLib in a driver *also*
includes such a CpuS3DataDxe variant that populates the PCD and then
installs gEdkiiCpuFeaturesSetDoneGuid.

[1] I suggest reviewing the message of commit bfec5efa56ca
("UefiCpuPkg/CpuS3DataDxe: Add module to initialize ACPI_CPU_DATA for
S3", 2015-11-25).

In fact, the series that added "DxeRegisterCpuFeaturesLib.inf" (with the
depex mentioned above) *also* modified CpuS3DataDxe: see [2] and [3].

[2] 8b371e93f206 ("UefiCpuPkg/CpuS3DataDxe: Consume the existing
PcdCpuS3DataAddress", 2017-03-22)

[3] "[edk2] [PATCH 00/11] Add CPU features driver"
https://bugzilla.tianocore.org/show_bug.cgi?id=421
http://mid.mail-archive.com/20170309083553.6016-1-jeff.fan@intel.com

This suggests that there is an out-of-tree module that populates
PcdCpuS3DataAddress before *both* CpuS3DataDxe and
DxeRegisterCpuFeaturesLib access the PCD. For achieving this kind of
ordering, it would be enough for a driver to first populate the PCD, and
then install "gEfiMpServiceProtocolGuid", as both
"DxeRegisterCpuFeaturesLib.inf" and "CpuS3DataDxe.inf" depend on that.

> Is there anything I'm missing that ensures the execution of
> CpuS3DataDxe prior to executing the dependent code? If not, should
> there be a dummy protocol exposed? PiSmmCpuDxeSmm also retrieves this
> PCD, however safely quits when it has not been set. However, this
> could cause unexpected behavior when the PCD is set after this code
> has been executed. I did not notice any dependency satisfaction
> actions here either.

The ordering between CpuS3DataDxe and PiSmmCpuDxeSmm is safe; it's
orchestrated by Platform BDS. See commit 92b87f1c8c0b above.

> Furthermore, not directly related to this dependency issue, the DXE
> code obviously does not implement AllocateAcpiCpuData() entirely.

More precisely, the DXE code expects AllocateAcpiCpuData() never to be
called; i.e., when the common "RegisterCpuFeaturesLib.c" source file is
executed in DXE, the expectation is that it never reaches the call to
AllocateAcpiCpuData().

> Hence, the if-branch follo

Re: [edk2] CpuS3DataDxe / DxeRegisterCpuFeaturesLib dependency.

[Marvin Häuser]

Hey Laszlo and thanks once again for your detailed response.
Comments are inline.

Regards,
Marvin.

> -Original Message-
> From: Laszlo Ersek <ler...@redhat.com>
> Sent: Friday, May 25, 2018 1:41 PM
> To: Marvin Häuser <marvin.haeu...@outlook.com>
> Cc: edk2-devel@lists.01.org; eric.d...@intel.com
> Subject: Re: CpuS3DataDxe / DxeRegisterCpuFeaturesLib dependency.
> 
> On 05/25/18 12:54, Marvin H?user wrote:
> > Good day,
> >
> > While I was inspecting CpuS3DataDxe and the modules depending on its
> > PCD PcdCpuS3DataAddress,
> 
> (Side remark: see e.g. the commit message on 92b87f1c8c0b, "OvmfPkg:
> build CpuS3DataDxe for -D SMM_REQUIRE", 2015-11-30.)
> 
> > I noticed that DxeRegisterCpuFeaturesLib seemingly has an asserted
> > dependency on the PCD being ready when it its executed. I did neither
> > see a Depex entry, nor an event callback ensuring CpuS3DataDxe has
> > been loaded, neither exposed by CpuS3DataDxe, nor consumed by this
> > library.
> >
> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/Library/Regis
> > terCpuFeaturesLib/DxeRegisterCpuFeaturesLib.c#L211
> 
> "DxeRegisterCpuFeaturesLib.inf" has a depex on
> "gEdkiiCpuFeaturesSetDoneGuid".
> 
> No module in the open source edk2 tree produces this protocol GUID, thus I
> think this library instance is unusable without other, out-of-tree, modules. I
> assume that one of those modules satisfies the dependency somehow.
>

While this of course can be used to control the dependency flow, this GUID is 
documented as follows:
"CPU Features Set Done PPI/Protocol should be installed after CPU features 
configuration are set."
If it is really supposed to ensure the ACPI CPU Data PCD availability too, I 
think it should be documented.
However I do not think that would be a great idea in the first place because 
other modules might depend on it as well.
I get your point is just that an out-of-tree module is needed, however if it 
exists and whatever it does, I don't think it should rely on this GUID for this 
purpose.

> Note that CpuS3DataDxe is a platform driver [1]; it is possible that the
> platform that includes DxeRegisterCpuFeaturesLib in a driver *also* includes
> such a CpuS3DataDxe variant that populates the PCD and then installs
> gEdkiiCpuFeaturesSetDoneGuid.

That was one of the reasons I asked whether a dedicated signal protocol dummy 
would be a good idea.
I don't think it is likely that this is the case, but it is not impossible and 
would need to be discussed internally, if it is the case, I guess.

> 
> [1] I suggest reviewing the message of commit bfec5efa56ca
> ("UefiCpuPkg/CpuS3DataDxe: Add module to initialize ACPI_CPU_DATA for
> S3", 2015-11-25).
> 
> In fact, the series that added "DxeRegisterCpuFeaturesLib.inf" (with the
> depex mentioned above) *also* modified CpuS3DataDxe: see [2] and [3].
> 
> [2] 8b371e93f206 ("UefiCpuPkg/CpuS3DataDxe: Consume the existing
> PcdCpuS3DataAddress", 2017-03-22)

This commit indicates to me that there is no proper dependency resolve, to be 
honest.
If the "main" PCD exposer has code to handle already present data, it means 
that every consumer not executing dependent code very late,
as you have shown PiSmmCpuDxeSmm does, has to have an allocation routine or 
some kind of implicit dependency.

> 
> [3] "[edk2] [PATCH 00/11] Add CPU features driver"
> https://bugzilla.tianocore.org/show_bug.cgi?id=421
> http://mid.mail-archive.com/20170309083553.6016-1-jeff.fan@intel.com
> 
> This suggests that there is an out-of-tree module that populates
> PcdCpuS3DataAddress before *both* CpuS3DataDxe and
> DxeRegisterCpuFeaturesLib access the PCD. For achieving this kind of
> ordering, it would be enough for a driver to first populate the PCD, and then
> install "gEfiMpServiceProtocolGuid", as both
> "DxeRegisterCpuFeaturesLib.inf" and "CpuS3DataDxe.inf" depend on that.

gEfiMpServiceProtocolGuid is populated by CpuDxe, so I hope this is not 
actually the case.
And yet again it would be only a dangerous implicit dependency.

> 
> > Is there anything I'm missing that ensures the execution of
> > CpuS3DataDxe prior to executing the dependent code? If not, should
> > there be a dummy protocol exposed? PiSmmCpuDxeSmm also retrieves
> this
> > PCD, however safely quits when it has not been set. However, this
> > could cause unexpected behavior when the PCD is set after this code
> > has been executed. I did not notice any dependency satisfaction
> > actions here either.
> 
> The ordering between CpuS3DataDxe and PiSmmCpuDxeSmm is safe; it's
> orchestrated by Platform BDS. See commi

Re: [edk2] [PATCH v2] EmulatorPkg/SmbiosLib: Declare the correct library class.

[Marvin Häuser]

> -Original Message-
> From: Laszlo Ersek <ler...@redhat.com>
> Sent: Thursday, May 24, 2018 10:51 PM
> To: Jordan Justen <jordan.l.jus...@intel.com>; edk2-devel@lists.01.org;
> Marvin Häuser <marvin.haeu...@outlook.com>
> Cc: af...@apple.com
> Subject: Re: [edk2] [PATCH v2] EmulatorPkg/SmbiosLib: Declare the correct
> library class.
> 
> On 05/24/18 22:36, Jordan Justen wrote:
> > Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>
> >
> > Pushed as 7dc7c7435e.
> >
> > On 2018-05-17 05:43:30, Marvin Häuser wrote:
> >> Currently, SmbiosLib declares the PcdLib library class. Update the
> >> declaration to declare SmbiosLib.
> >>
> >> V2:
> >>   - Do not change the copyright date as requested.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Marvin Haeuser <marvin.haeu...@outlook.com>
> >> ---
> >>  EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf
> >> b/EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf
> >> index adcd7ef08e20..36d5c350f51a 100644
> >> --- a/EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf
> >> +++ b/EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf
> >> @@ -20,7 +20,7 @@ [Defines]
> >>FILE_GUID  = 881863A2-09FD-3E44-8D62-7AE038D03747
> >>MODULE_TYPE= DXE_DRIVER
> >>VERSION_STRING = 1.0
> >> -  LIBRARY_CLASS  = PcdLib|DXE_CORE DXE_DRIVER
> DXE_RUNTIME_DRIVER DXE_SAL_DRIVER DXE_SMM_DRIVER SMM_CORE
> UEFI_APPLICATION UEFI_DRIVER
> >> +  LIBRARY_CLASS  = SmbiosLib|DXE_CORE DXE_DRIVER
> DXE_RUNTIME_DRIVER DXE_SAL_DRIVER DXE_SMM_DRIVER SMM_CORE
> UEFI_APPLICATION UEFI_DRIVER
> >>
> >>CONSTRUCTOR= SmbiosLibConstructor
> 
> (Just because I pondered the question a few days ago, independently, I'll
> voice it here:)
> 
> Should BaseTools catch this? "EmulatorPkg/EmulatorPkg.dsc" contains the
> following library resolution:
> 
>   SmbiosLib|EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf
> 
> I think it should be possible to flag that the class of the lib instance 
> doesn't
> match the lib class that the platform DSC is resolving.

I think it definitely should, there is no case (known to me) where those two 
values diverging would be a supported or making any sense.

> 
> (Or is Marvin's patch the result of such an error message already?)

No, I was just checking the library for reference and noticed the mistake. I 
did not actually build EmulatorPkg though.

Regards,
Marvin

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

Re: [edk2] [PATCH v2] BaseTools/Workspace: Fix ValueChain set

[Marvin Häuser]

Thanks Liming!
Maybe this is an issue with my e-mail client or server, I just heard Exchange 
sometimes messes up.
If there really is no such change as I'm observing here, V1 should be fine too.

Regards,
Marvin.

> -Original Message-
> From: Gao, Liming <liming@intel.com>
> Sent: Tuesday, May 22, 2018 2:49 PM
> To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> Cc: Zhu, Yonghong <yonghong@intel.com>
> Subject: RE: [PATCH v2] BaseTools/Workspace: Fix ValueChain set
> 
> Marvin:
>   I don't see the whitespace in this patch. I also run
> BaseTools\Scripts\PatchCheck.py. There is no issue found.
> 
> > -Original Message-
> > From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> > Sent: Tuesday, May 22, 2018 7:52 PM
> > To: edk2-devel@lists.01.org
> > Cc: Gao, Liming <liming@intel.com>; Zhu, Yonghong
> > <yonghong@intel.com>
> > Subject: RE: [PATCH v2] BaseTools/Workspace: Fix ValueChain set
> >
> > This is odd. I generated another patch and checked for whitespace and
> CRLF/LF changes and found everything to be fine.
> > Now V2 has the exact same whitespace change as V1. Also, if I see it
> > right, it failed to CC Yonghong even though the CMD clearly shows the cc.
> >
> > Is there maybe some git expert around who has an idea what the issue
> could be?
> >
> > Thanks,
> > Marvin
> >
> > > -Original Message-
> > > From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of
> > > Marvin Häuser
> > > Sent: Tuesday, May 22, 2018 1:48 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: liming@intel.com
> > > Subject: [edk2] [PATCH v2] BaseTools/Workspace: Fix ValueChain set
> > >
> > > Commit 88252a90d1ca7846731cd2e4e8e860454f7d97a3 changed
> ValueChain
> > > from a dict to a set, but also changed the (former) key type from a
> > > touple to two separate values, which was probably unintended and
> > > also breaks build for packages involving Structured PCDs, because
> > > add() only takes one argument.
> > > This commit changes the values back to touples.
> > >
> > > V2:
> > >   - Removed a whitespace change.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Marvin Haeuser <marvin.haeu...@outlook.com>
> > > ---
> > >  BaseTools/Source/Python/Workspace/DscBuildData.py | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py
> > > b/BaseTools/Source/Python/Workspace/DscBuildData.py
> > > index 8476543c5352..0262a91ed855 100644
> > > --- a/BaseTools/Source/Python/Workspace/DscBuildData.py
> > > +++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
> > > @@ -1347,7 +1347,7 @@ class DscBuildData(PlatformBuildClassObject):
> > >  nextskuid = self.SkuIdMgr.GetNextSkuId(nextskuid)
> > >  stru_pcd.SkuOverrideValues[skuid] =
> > > copy.deepcopy(stru_pcd.SkuOverrideValues[nextskuid]) if not
> > > NoDefault else copy.deepcopy({defaultstorename:
> > > stru_pcd.DefaultValues for defaultstorename in DefaultStores} if
> > > DefaultStores else
> > > {TAB_DEFAULT_STORES_DEFAULT:stru_pcd.DefaultValues})
> > >  if not NoDefault:
> > > -stru_pcd.ValueChain.add(skuid,'')
> > > +stru_pcd.ValueChain.add((skuid,''))
> > >  if stru_pcd.Type in
> > > [self._PCD_TYPE_STRING_[MODEL_PCD_DYNAMIC_HII],
> > > self._PCD_TYPE_STRING_[MODEL_PCD_DYNAMIC_EX_HII]]:
> > >  for skuid in SkuIds:
> > >  nextskuid = skuid @@ -1366,7 +1366,7 @@ class
> > > DscBuildData(PlatformBuildClassObject):
> > >  for defaultstoreid in DefaultStores:
> > >  if defaultstoreid not in 
> > > stru_pcd.SkuOverrideValues[skuid]:
> > >
> > > stru_pcd.SkuOverrideValues[skuid][defaultstoreid] =
> > >
> copy.deepcopy(stru_pcd.SkuOverrideValues[nextskuid][mindefaultstoren
> > > a
> > > me])
> > > -stru_pcd.ValueChain.add(skuid,defaultstoreid)
> > > +
> > > + stru_pcd.ValueChain.add((skuid,defaultstoreid))
> > >  S_pcd_set = DscBuildData.OverrideByFdfComm(S_pcd_set)
> > >  Str_Pcd_Values = self.GenerateByteArrayValue(S_pcd_set)
> > >  if Str_Pcd_Values:
> > > --
> > > 2.17.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

Re: [edk2] [PATCH v2] BaseTools/Workspace: Fix ValueChain set

[Marvin Häuser]

This is odd. I generated another patch and checked for whitespace and CRLF/LF 
changes and found everything to be fine.
Now V2 has the exact same whitespace change as V1. Also, if I see it right, it 
failed to CC Yonghong even though the CMD clearly shows the cc.

Is there maybe some git expert around who has an idea what the issue could be?

Thanks,
Marvin

> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Marvin
> Häuser
> Sent: Tuesday, May 22, 2018 1:48 PM
> To: edk2-devel@lists.01.org
> Cc: liming@intel.com
> Subject: [edk2] [PATCH v2] BaseTools/Workspace: Fix ValueChain set
> 
> Commit 88252a90d1ca7846731cd2e4e8e860454f7d97a3 changed ValueChain
> from a dict to a set, but also changed the (former) key type from a touple to
> two separate values, which was probably unintended and also breaks build
> for packages involving Structured PCDs, because add() only takes one
> argument.
> This commit changes the values back to touples.
> 
> V2:
>   - Removed a whitespace change.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marvin Haeuser <marvin.haeu...@outlook.com>
> ---
>  BaseTools/Source/Python/Workspace/DscBuildData.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py
> b/BaseTools/Source/Python/Workspace/DscBuildData.py
> index 8476543c5352..0262a91ed855 100644
> --- a/BaseTools/Source/Python/Workspace/DscBuildData.py
> +++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
> @@ -1347,7 +1347,7 @@ class DscBuildData(PlatformBuildClassObject):
>  nextskuid = self.SkuIdMgr.GetNextSkuId(nextskuid)
>  stru_pcd.SkuOverrideValues[skuid] =
> copy.deepcopy(stru_pcd.SkuOverrideValues[nextskuid]) if not NoDefault
> else copy.deepcopy({defaultstorename: stru_pcd.DefaultValues for
> defaultstorename in DefaultStores} if DefaultStores else
> {TAB_DEFAULT_STORES_DEFAULT:stru_pcd.DefaultValues})
>  if not NoDefault:
> -stru_pcd.ValueChain.add(skuid,'')
> +stru_pcd.ValueChain.add((skuid,''))
>  if stru_pcd.Type in
> [self._PCD_TYPE_STRING_[MODEL_PCD_DYNAMIC_HII],
> self._PCD_TYPE_STRING_[MODEL_PCD_DYNAMIC_EX_HII]]:
>  for skuid in SkuIds:
>  nextskuid = skuid
> @@ -1366,7 +1366,7 @@ class DscBuildData(PlatformBuildClassObject):
>  for defaultstoreid in DefaultStores:
>  if defaultstoreid not in 
> stru_pcd.SkuOverrideValues[skuid]:
>  
> stru_pcd.SkuOverrideValues[skuid][defaultstoreid] =
> copy.deepcopy(stru_pcd.SkuOverrideValues[nextskuid][mindefaultstorena
> me])
> -stru_pcd.ValueChain.add(skuid,defaultstoreid)
> +
> + stru_pcd.ValueChain.add((skuid,defaultstoreid))
>  S_pcd_set = DscBuildData.OverrideByFdfComm(S_pcd_set)
>  Str_Pcd_Values = self.GenerateByteArrayValue(S_pcd_set)
>  if Str_Pcd_Values:
> --
> 2.17.0.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2] BaseTools/Workspace: Fix ValueChain set

[Marvin Häuser]

Commit 88252a90d1ca7846731cd2e4e8e860454f7d97a3 changed ValueChain
from a dict to a set, but also changed the (former) key type from a
touple to two separate values, which was probably unintended and also
breaks build for packages involving Structured PCDs, because add()
only takes one argument.
This commit changes the values back to touples.

V2:
  - Removed a whitespace change.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 BaseTools/Source/Python/Workspace/DscBuildData.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py 
b/BaseTools/Source/Python/Workspace/DscBuildData.py
index 8476543c5352..0262a91ed855 100644
--- a/BaseTools/Source/Python/Workspace/DscBuildData.py
+++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
@@ -1347,7 +1347,7 @@ class DscBuildData(PlatformBuildClassObject):
 nextskuid = self.SkuIdMgr.GetNextSkuId(nextskuid)
 stru_pcd.SkuOverrideValues[skuid] = 
copy.deepcopy(stru_pcd.SkuOverrideValues[nextskuid]) if not NoDefault else 
copy.deepcopy({defaultstorename: stru_pcd.DefaultValues for defaultstorename in 
DefaultStores} if DefaultStores else 
{TAB_DEFAULT_STORES_DEFAULT:stru_pcd.DefaultValues})
 if not NoDefault:
-stru_pcd.ValueChain.add(skuid,'')
+stru_pcd.ValueChain.add((skuid,''))
 if stru_pcd.Type in 
[self._PCD_TYPE_STRING_[MODEL_PCD_DYNAMIC_HII], 
self._PCD_TYPE_STRING_[MODEL_PCD_DYNAMIC_EX_HII]]:
 for skuid in SkuIds:
 nextskuid = skuid
@@ -1366,7 +1366,7 @@ class DscBuildData(PlatformBuildClassObject):
 for defaultstoreid in DefaultStores:
 if defaultstoreid not in 
stru_pcd.SkuOverrideValues[skuid]:
 stru_pcd.SkuOverrideValues[skuid][defaultstoreid] 
= copy.deepcopy(stru_pcd.SkuOverrideValues[nextskuid][mindefaultstorename])
-stru_pcd.ValueChain.add(skuid,defaultstoreid)
+stru_pcd.ValueChain.add((skuid,defaultstoreid))
 S_pcd_set = DscBuildData.OverrideByFdfComm(S_pcd_set)
 Str_Pcd_Values = self.GenerateByteArrayValue(S_pcd_set)
 if Str_Pcd_Values:
-- 
2.17.0.windows.1

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

[edk2] [PATCH] BaseTools: Rename String to StringUtils.

[Marvin Häuser]

For case-insensitive file systems, edk2 String.py collides with the
Python string.py, which results in build errors. This,for example,
applies to building via the Windows Subsystem for Linux from a
DriveFS file system. This patch renames String to StringUtils to
prevent conflicts for case-insensitive file systems.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 BaseTools/Source/Python/AutoGen/AutoGen.py| 2 +-
 BaseTools/Source/Python/AutoGen/BuildEngine.py| 2 +-
 BaseTools/Source/Python/AutoGen/GenC.py   | 2 +-
 BaseTools/Source/Python/AutoGen/GenMake.py| 2 +-
 BaseTools/Source/Python/AutoGen/GenPcdDb.py   | 2 +-
 BaseTools/Source/Python/AutoGen/IdfClassObject.py | 2 +-
 BaseTools/Source/Python/AutoGen/UniClassObject.py | 2 +-
 BaseTools/Source/Python/Common/Database.py| 2 +-
 BaseTools/Source/Python/Common/Parsing.py | 2 +-
 BaseTools/Source/Python/Common/{String.py => StringUtils.py}  | 0
 BaseTools/Source/Python/Common/ToolDefClassObject.py  | 2 +-
 BaseTools/Source/Python/Ecc/Configuration.py  | 2 +-
 BaseTools/Source/Python/Ecc/Ecc.py| 2 +-
 BaseTools/Source/Python/Ecc/MetaFileWorkspace/MetaFileParser.py   | 2 +-
 BaseTools/Source/Python/Eot/Eot.py| 2 +-
 BaseTools/Source/Python/Eot/InfParserLite.py  | 2 +-
 BaseTools/Source/Python/Eot/Parser.py | 4 ++--
 BaseTools/Source/Python/GenFds/AprioriSection.py  | 2 +-
 BaseTools/Source/Python/GenFds/FdfParser.py   | 4 ++--
 BaseTools/Source/Python/GenFds/FfsInfStatement.py | 2 +-
 BaseTools/Source/Python/GenFds/GenFds.py  | 2 +-
 BaseTools/Source/Python/GenFds/OptRomInfStatement.py  | 2 +-
 BaseTools/Source/Python/Makefile  | 4 ++--
 BaseTools/Source/Python/Table/TableDataModel.py   | 2 +-
 BaseTools/Source/Python/Table/TableDec.py | 2 +-
 BaseTools/Source/Python/Table/TableDsc.py | 2 +-
 BaseTools/Source/Python/Table/TableEotReport.py   | 2 +-
 BaseTools/Source/Python/Table/TableFdf.py | 2 +-
 BaseTools/Source/Python/Table/TableFile.py| 2 +-
 BaseTools/Source/Python/Table/TableFunction.py| 2 +-
 BaseTools/Source/Python/Table/TableIdentifier.py  | 2 +-
 BaseTools/Source/Python/Table/TableInf.py | 2 +-
 BaseTools/Source/Python/Table/TablePcd.py | 2 +-
 BaseTools/Source/Python/Table/TableQuery.py   | 2 +-
 BaseTools/Source/Python/Table/TableReport.py  | 2 +-
 BaseTools/Source/Python/UPT/Library/{String.py => StringUtils.py} | 0
 BaseTools/Source/Python/Workspace/DecBuildData.py | 2 +-
 BaseTools/Source/Python/Workspace/DscBuildData.py | 2 +-
 BaseTools/Source/Python/Workspace/InfBuildData.py | 2 +-
 BaseTools/Source/Python/Workspace/MetaFileParser.py   | 2 +-
 BaseTools/Source/Python/Workspace/WorkspaceDatabase.py| 2 +-
 BaseTools/Source/Python/build/BuildReport.py  | 2 +-
 42 files changed, 43 insertions(+), 43 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index 1e6511cdb5d2..4304967aee42 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -33,7 +33,7 @@ from Common.LongFilePathSupport import CopyLongFilePath
 from Common.BuildToolError import *
 from Common.DataType import *
 from Common.Misc import *
-from Common.String import *
+from Common.StringUtils import *
 import Common.GlobalData as GlobalData
 from GenFds.FdfParser import *
 from CommonDataClass.CommonClass import SkuInfoClass
diff --git a/BaseTools/Source/Python/AutoGen/BuildEngine.py 
b/BaseTools/Source/Python/AutoGen/BuildEngine.py
index dd6301b01fce..ad1919442e6e 100644
--- a/BaseTools/Source/Python/AutoGen/BuildEngine.py
+++ b/BaseTools/Source/Python/AutoGen/BuildEngine.py
@@ -23,7 +23,7 @@ from Common.LongFilePathSupport import OpenLongFilePath as 
open
 from Common.GlobalData import *
 from Common.BuildToolError import *
 from Common.Misc import tdict, PathClass
-from Common.String import NormPath
+from Common.StringUtils import NormPath
 from Common.DataType import *
 
 import Common.EdkLogger as EdkLogger
diff --git a/BaseTools/Source/Python/AutoGen/GenC.py 
b/BaseTools/Source/Python/AutoGen/GenC.py
index 40a343ca1057..1be27d2b89e0 100644
--- a/BaseTools/Source/Python/AutoGen/GenC.py
+++ 

Re: [edk2] [PATCH] BaseTools/Workspace: Fix ValueChain set

[Marvin Häuser]

Sorry, it seems like my IDE did whitespace changes for the second change.
I will submit a V2 once the functionality has been reviewed.

> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Marvin
> Häuser
> Sent: Saturday, May 19, 2018 12:43 AM
> To: edk2-devel@lists.01.org
> Cc: jaben.car...@intel.com; liming@intel.com
> Subject: [edk2] [PATCH] BaseTools/Workspace: Fix ValueChain set
> 
> Commit 88252a90d1ca7846731cd2e4e8e860454f7d97a3 changed ValueChain
> from a dict to a set, but also changed the (former) key type from a touple to
> two separate values, which was probably unintended and also breaks build
> for packages involving Structured PCDs, because add() only takes one
> argument.
> This commit changes the values back to touples.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marvin Haeuser <marvin.haeu...@outlook.com>
> ---
>  BaseTools/Source/Python/Workspace/DscBuildData.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py
> b/BaseTools/Source/Python/Workspace/DscBuildData.py
> index 8476543c5352..0262a91ed855 100644
> --- a/BaseTools/Source/Python/Workspace/DscBuildData.py
> +++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
> @@ -1347,7 +1347,7 @@ class DscBuildData(PlatformBuildClassObject):
>  nextskuid = self.SkuIdMgr.GetNextSkuId(nextskuid)
>  stru_pcd.SkuOverrideValues[skuid] =
> copy.deepcopy(stru_pcd.SkuOverrideValues[nextskuid]) if not NoDefault
> else copy.deepcopy({defaultstorename: stru_pcd.DefaultValues for
> defaultstorename in DefaultStores} if DefaultStores else
> {TAB_DEFAULT_STORES_DEFAULT:stru_pcd.DefaultValues})
>  if not NoDefault:
> -stru_pcd.ValueChain.add(skuid,'')
> +stru_pcd.ValueChain.add((skuid,''))
>  if stru_pcd.Type in
> [self._PCD_TYPE_STRING_[MODEL_PCD_DYNAMIC_HII],
> self._PCD_TYPE_STRING_[MODEL_PCD_DYNAMIC_EX_HII]]:
>  for skuid in SkuIds:
>  nextskuid = skuid
> @@ -1366,7 +1366,7 @@ class DscBuildData(PlatformBuildClassObject):
>  for defaultstoreid in DefaultStores:
>  if defaultstoreid not in 
> stru_pcd.SkuOverrideValues[skuid]:
>  
> stru_pcd.SkuOverrideValues[skuid][defaultstoreid] =
> copy.deepcopy(stru_pcd.SkuOverrideValues[nextskuid][mindefaultstorena
> me])
> -stru_pcd.ValueChain.add(skuid,defaultstoreid)
> +
> + stru_pcd.ValueChain.add((skuid,defaultstoreid))
>  S_pcd_set = DscBuildData.OverrideByFdfComm(S_pcd_set)
>  Str_Pcd_Values = self.GenerateByteArrayValue(S_pcd_set)
>  if Str_Pcd_Values:
> --
> 2.17.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] BaseTools/Workspace: Fix ValueChain set

[Marvin Häuser]

Commit 88252a90d1ca7846731cd2e4e8e860454f7d97a3 changed ValueChain
from a dict to a set, but also changed the (former) key type from a
touple to two separate values, which was probably unintended and also
breaks build for packages involving Structured PCDs, because add()
only takes one argument.
This commit changes the values back to touples.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 BaseTools/Source/Python/Workspace/DscBuildData.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py 
b/BaseTools/Source/Python/Workspace/DscBuildData.py
index 8476543c5352..0262a91ed855 100644
--- a/BaseTools/Source/Python/Workspace/DscBuildData.py
+++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
@@ -1347,7 +1347,7 @@ class DscBuildData(PlatformBuildClassObject):
 nextskuid = self.SkuIdMgr.GetNextSkuId(nextskuid)
 stru_pcd.SkuOverrideValues[skuid] = 
copy.deepcopy(stru_pcd.SkuOverrideValues[nextskuid]) if not NoDefault else 
copy.deepcopy({defaultstorename: stru_pcd.DefaultValues for defaultstorename in 
DefaultStores} if DefaultStores else 
{TAB_DEFAULT_STORES_DEFAULT:stru_pcd.DefaultValues})
 if not NoDefault:
-stru_pcd.ValueChain.add(skuid,'')
+stru_pcd.ValueChain.add((skuid,''))
 if stru_pcd.Type in 
[self._PCD_TYPE_STRING_[MODEL_PCD_DYNAMIC_HII], 
self._PCD_TYPE_STRING_[MODEL_PCD_DYNAMIC_EX_HII]]:
 for skuid in SkuIds:
 nextskuid = skuid
@@ -1366,7 +1366,7 @@ class DscBuildData(PlatformBuildClassObject):
 for defaultstoreid in DefaultStores:
 if defaultstoreid not in 
stru_pcd.SkuOverrideValues[skuid]:
 stru_pcd.SkuOverrideValues[skuid][defaultstoreid] 
= copy.deepcopy(stru_pcd.SkuOverrideValues[nextskuid][mindefaultstorename])
-stru_pcd.ValueChain.add(skuid,defaultstoreid)
+stru_pcd.ValueChain.add((skuid,defaultstoreid))
 S_pcd_set = DscBuildData.OverrideByFdfComm(S_pcd_set)
 Str_Pcd_Values = self.GenerateByteArrayValue(S_pcd_set)
 if Str_Pcd_Values:
-- 
2.17.0.windows.1

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

Re: [edk2] [PATCH] MdePkg/Hpet: Add Event Timer Block ID definition.

[Marvin Häuser]

Hey Jaben,

Done.

Regards,
Marvin.

> -Original Message-
> From: Carsey, Jaben <jaben.car...@intel.com>
> Sent: Thursday, May 17, 2018 12:32 AM
> To: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-
> de...@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Gao, Liming
> <liming@intel.com>
> Subject: RE: [PATCH] MdePkg/Hpet: Add Event Timer Block ID definition.
> 
> Marvin,
> 
> Can you resubmit your patch without the modification to the intel copyright?
> 
> Can you also do this for any other outstanding (not yet pushed) patches also?
> 
> -Jaben
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Marvin Häuser
> > Sent: Tuesday, May 15, 2018 12:35 PM
> > To: edk2-devel@lists.01.org
> > Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Gao, Liming
> > <liming@intel.com>
> > Subject: [edk2] [PATCH] MdePkg/Hpet: Add Event Timer Block ID
> definition.
> >
> > This patch adds the HPET Event Timer Block ID definition that can be
> > found in the IA-PC HPET Specification, section 3.2.4.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Marvin Haeuser <marvin.haeu...@outlook.com>
> > ---
> >  MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h | 18
> > +-
> >  1 file changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git
> > a/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h
> > b/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h
> > index 0d83cd5335de..926445233944 100644
> > --- a/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h
> > +++ b/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h
> > @@ -2,7 +2,7 @@
> >ACPI high precision event timer table definition, at www.intel.com
> >Specification name is IA-PC HPET (High Precision Event Timers)
> > Specification.
> >
> > -  Copyright (c) 2007 - 2008, Intel Corporation. All rights
> > reserved.
> > +  Copyright (c) 2007 - 2018, Intel Corporation. All rights
> > + reserved.
> >This program and the accompanying materials
> >are licensed and made available under the terms and conditions of
> > the BSD License
> >which accompanies this distribution.  The full text of the license
> > may be found at @@ -22,6 +22,22 @@  //  #pragma pack(1)
> >
> > +///
> > +/// HPET Event Timer Block ID described in IA-PC HPET Specification, 3.2.4.
> > +///
> > +typedef union {
> > +  struct {
> > +UINT32 Revision   : 8;
> > +UINT32 NumberOfTimers : 5;
> > +UINT32 CounterSize: 1;
> > +UINT32 Reserved   : 1;
> > +UINT32 LegacyRoute: 1;
> > +UINT32 VendorId   : 16;
> > +  }  Bits;
> > +  UINT32 Uint32;
> > +} EFI_ACPI_HIGH_PRECISION_EVENT_TIMER_BLOCK_ID;
> > +
> > +
> >  ///
> >  /// High Precision Event Timer Table header definition.
> >  ///
> > --
> > 2.17.0.windows.1
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2] EmulatorPkg/SmbiosLib: Declare the correct library class.

[Marvin Häuser]

Currently, SmbiosLib declares the PcdLib library class. Update the
declaration to declare SmbiosLib.

V2:
  - Do not change the copyright date as requested.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf 
b/EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf
index adcd7ef08e20..36d5c350f51a 100644
--- a/EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf
+++ b/EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf
@@ -20,7 +20,7 @@ [Defines]
   FILE_GUID  = 881863A2-09FD-3E44-8D62-7AE038D03747
   MODULE_TYPE= DXE_DRIVER
   VERSION_STRING = 1.0
-  LIBRARY_CLASS  = PcdLib|DXE_CORE DXE_DRIVER 
DXE_RUNTIME_DRIVER DXE_SAL_DRIVER DXE_SMM_DRIVER SMM_CORE UEFI_APPLICATION 
UEFI_DRIVER 
+  LIBRARY_CLASS  = SmbiosLib|DXE_CORE DXE_DRIVER 
DXE_RUNTIME_DRIVER DXE_SAL_DRIVER DXE_SMM_DRIVER SMM_CORE UEFI_APPLICATION 
UEFI_DRIVER 
 
   CONSTRUCTOR= SmbiosLibConstructor
 
-- 
2.17.0.windows.1

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

[edk2] [PATCH v2] ShellPkg/UefiShellLevel2CommandsLib: Support unspecified local Timezone.

[Marvin Häuser]

EFI_RUNTIME_SERVICES.GetTime() might return an unspecified Timezone,
such as when SetTime() has not been called after the PC-AT CMOS RTC
was cut off power. Consider this case by not attempting Timezone
translations for when it is invalid.

V2:
  - Do not change the copyright date as requested.
  - Added R-bs from V1 as no functional changes have been made.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
Reviewed-by: Jaben Carsey 
Reviewed-by: Ruiyu Ni 
---
 ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c 
b/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
index 7d2e15f5206b..e502685a1dbb 100644
--- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
+++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
@@ -506,7 +506,7 @@ PrintLsOutput(
   // Change the file time to local time.
   //
   Status = gRT->GetTime(, NULL);
-  if (!EFI_ERROR (Status)) {
+  if (!EFI_ERROR (Status) && (LocalTime.TimeZone != 
EFI_UNSPECIFIED_TIMEZONE)) {
 if ((Node->Info->CreateTime.TimeZone != EFI_UNSPECIFIED_TIMEZONE) &&
 (Node->Info->CreateTime.Month >= 1 && Node->Info->CreateTime.Month 
<= 12)) {
   //
-- 
2.17.0.windows.1

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

[edk2] [PATCH v2] MdePkg: Update MmSwDispatch.h's references to SmmSw2Dispatch.

[Marvin Häuser]

MmSwDispatch.h current refers to the deprecated SmmSw2Dispatch
protocol. Replace those references with the new MmSwDispatch name.

V2:
  - Do not change the copyright date as requested.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Include/Protocol/MmSwDispatch.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/MdePkg/Include/Protocol/MmSwDispatch.h 
b/MdePkg/Include/Protocol/MmSwDispatch.h
index d3acb64e6f3d..e412bb2e66c0 100644
--- a/MdePkg/Include/Protocol/MmSwDispatch.h
+++ b/MdePkg/Include/Protocol/MmSwDispatch.h
@@ -15,8 +15,8 @@
 
 **/
 
-#ifndef _MM_SW_DISPATCH2_H_
-#define _MM_SW_DISPATCH2_H_
+#ifndef _MM_SW_DISPATCH_H_
+#define _MM_SW_DISPATCH_H_
 
 #include 
 
@@ -117,7 +117,7 @@ EFI_STATUS
 ///
 /// Interface structure for the MM Software MMI Dispatch Protocol.
 ///
-/// The EFI_MM_SW_DISPATCH2_PROTOCOL provides the ability to install child 
handlers for the
+/// The EFI_MM_SW_DISPATCH_PROTOCOL provides the ability to install child 
handlers for the
 /// given software.  These handlers will respond to software interrupts, and 
the maximum software
 /// interrupt in the EFI_MM_SW_REGISTER_CONTEXT is denoted by MaximumSwiValue.
 ///
-- 
2.17.0.windows.1

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

[edk2] [PATCH v2] MdePkg/Hpet: Add Event Timer Block ID definition.

[Marvin Häuser]

This patch adds the HPET Event Timer Block ID definition that can be
found in the IA-PC HPET Specification, section 3.2.4.

V2:
  - Do not change the copyright date as requested.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h | 16 

 1 file changed, 16 insertions(+)

diff --git a/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h 
b/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h
index 0d83cd5335de..6218a77c543c 100644
--- a/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h
+++ b/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h
@@ -22,6 +22,22 @@
 //
 #pragma pack(1)
 
+///
+/// HPET Event Timer Block ID described in IA-PC HPET Specification, 3.2.4.
+///
+typedef union {
+  struct {
+UINT32 Revision   : 8;
+UINT32 NumberOfTimers : 5;
+UINT32 CounterSize: 1;
+UINT32 Reserved   : 1;
+UINT32 LegacyRoute: 1;
+UINT32 VendorId   : 16;
+  }  Bits;
+  UINT32 Uint32;
+} EFI_ACPI_HIGH_PRECISION_EVENT_TIMER_BLOCK_ID;
+
+
 ///
 /// High Precision Event Timer Table header definition.
 ///
-- 
2.17.0.windows.1

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

[edk2] [PATCH v2] MdePkg/UefiFileHandleLib: Fix the Root directory determination.

[Marvin Häuser]

The current implementation of the FileHandleGetFileName() function
assumes that the Root directory always has the FileName '\0'.
However, the only requirement the UEFI specification defines is that
a prepended '\\' must be supported to access files and folders
relative to the Root directory.
This patch removes this assumption and supports constructing valid
paths for any value of FileName for the Root Directory.

In praxis, this fixes compatibility issues with File System drivers
that report '\\' as the FileName of the Root directory, which
currently is both generating an invalid path ("") and resulting
in an EFI_NOT_FOUND result from the CurrentHandle->Open() call.

V2:
  - Do not change the copyright date as requested.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c | 27 ++--
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c 
b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
index 57aad77bc135..251cbc55edb5 100644
--- a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
+++ b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
@@ -820,10 +820,25 @@ FileHandleGetFileName (
 Status = EFI_OUT_OF_RESOURCES;
 break;
   } else {
+//
+// Prepare to move to the parent directory.
+// Also determine whether CurrentHandle refers to the Root directory.
+//
+Status = CurrentHandle->Open (CurrentHandle, , L"..", 
EFI_FILE_MODE_READ, 0);
 //
 // We got info... do we have a name? if yes precede the current path 
with it...
 //
-if (StrLen (FileInfo->FileName) == 0) {
+if ((StrLen (FileInfo->FileName) == 0) || EFI_ERROR (Status)) {
+  //
+  // Both FileInfo->FileName being '\0' and EFI_ERROR() suggest that
+  // CurrentHandle refers to the Root directory.  As this loop ensures
+  // FullFileName is starting with '\\' at all times, signal success
+  // and exit the loop.
+  // While FileInfo->FileName could theoretically be a value other than
+  // '\0' or '\\', '\\' is guaranteed to be supported by the
+  // specification and hence its value can safely be ignored.
+  //
+  Status = EFI_SUCCESS;
   if (*FullFileName == NULL) {
 ASSERT((*FullFileName == NULL && Size == 0) || (*FullFileName != 
NULL));
 *FullFileName = StrnCatGrowLeft(FullFileName, , L"\\", 0);
@@ -841,15 +856,11 @@ FileHandleGetFileName (
   FreePool(FileInfo);
 }
   }
-  //
-  // Move to the parent directory
-  //
-  Status = CurrentHandle->Open (CurrentHandle, , L"..", 
EFI_FILE_MODE_READ, 0);
-  if (EFI_ERROR (Status)) {
-break;
-  }
 
   FileHandleClose(CurrentHandle);
+  //
+  // Move to the parent directory
+  //
   CurrentHandle = NextHigherHandle;
 }
   } else if (Status == EFI_NOT_FOUND) {
-- 
2.17.0.windows.1

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

[edk2] [PATCH v2] MdePkg/UefiFileHandleLib: Fix potential NULL dereference.

[Marvin Häuser]

Move the NULL-check in FileHandleGetInfo() to directly after the
allocation to prevent potential NULL dereferences.

V2:
  - Do not change the copyright date as requested.
  - Added R-bs from V1 as no functional changes have been made.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
Reviewed-by: Ruiyu Ni 
---
 MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c | 28 +++-
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c 
b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
index 57aad77bc135..5b3d39ef6103 100644
--- a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
+++ b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
@@ -74,19 +74,21 @@ FileHandleGetInfo (
 // error is expected.  getting size to allocate
 //
 FileInfo = AllocateZeroPool(FileInfoSize);
-//
-// now get the information
-//
-Status = FileHandle->GetInfo(FileHandle,
- ,
- ,
- FileInfo);
-//
-// if we got an error free the memory and return NULL
-//
-if (EFI_ERROR(Status) && (FileInfo != NULL)) {
-  FreePool(FileInfo);
-  FileInfo = NULL;
+if (FileInfo != NULL) {
+  //
+  // now get the information
+  //
+  Status = FileHandle->GetInfo(FileHandle,
+   ,
+   ,
+   FileInfo);
+  //
+  // if we got an error free the memory and return NULL
+  //
+  if (EFI_ERROR(Status)) {
+FreePool(FileInfo);
+FileInfo = NULL;
+  }
 }
   }
   return (FileInfo);
-- 
2.17.0.windows.1

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

Re: [edk2] Proposition of a BmEnumerateBootOptions() hook.

[Marvin Häuser]

Thanks for your comment,
Comments are inline

Regards,
Marvin.

> -Original Message-
> From: Ni, Ruiyu <ruiyu...@intel.com>
> Sent: Thursday, May 17, 2018 9:58 AM
> To: Marvin Häuser <marvin.haeu...@outlook.com>; Laszlo Ersek
> <ler...@redhat.com>; edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>; ard.biesheu...@linaro.org; Justen,
> Jordan L <jordan.l.jus...@intel.com>; gso...@gmail.com; Zeng, Star
> <star.z...@intel.com>
> Subject: RE: [edk2] Proposition of a BmEnumerateBootOptions() hook.
> 
> 
> 
> Thanks/Ray
> 
> > -Original Message-
> > From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Marvin
> > Häuser
> > Sent: Wednesday, May 16, 2018 1:15 AM
> > To: Laszlo Ersek <ler...@redhat.com>; edk2-devel@lists.01.org
> > Cc: Ni, Ruiyu <ruiyu...@intel.com>; Dong, Eric <eric.d...@intel.com>;
> > ard.biesheu...@linaro.org; Justen, Jordan L
> > <jordan.l.jus...@intel.com>; gso...@gmail.com; Zeng, Star
> > <star.z...@intel.com>
> > Subject: Re: [edk2] Proposition of a BmEnumerateBootOptions() hook.
> >
> > Thanks for your feedback!
> > Comments inline
> >
> > Regards,
> > Marvin.
> >
> > > -Original Message-
> > > From: Laszlo Ersek <ler...@redhat.com>
> > > Sent: Tuesday, May 15, 2018 6:12 PM
> > > To: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-
> > > de...@lists.01.org
> > > Cc: gso...@gmail.com; ard.biesheu...@linaro.org; ruiyu...@intel.com;
> > > eric.d...@intel.com; star.z...@intel.com; jordan.l.jus...@intel.com
> > > Subject: Re: [edk2] Proposition of a BmEnumerateBootOptions() hook.
> > >
> > > On 05/15/18 17:38, Marvin Häuser wrote:
> > > >> -Original Message-
> > > >> From: Laszlo Ersek <ler...@redhat.com>
> > > >> Sent: Tuesday, May 15, 2018 3:53 PM
> > > >> To: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-
> > > >> de...@lists.01.org
> > > >> Cc: eric.d...@intel.com; star.z...@intel.com;
> > > >> jordan.l.jus...@intel.com; ard.biesheu...@linaro.org;
> > > >> ruiyu...@intel.com; Gabriel L. Somlo (GMail) <gso...@gmail.com>;
> > > >> Gerd Hoffmann <kra...@redhat.com>
> > > >> Subject: Re: [edk2] Proposition of a BmEnumerateBootOptions()
> hook.
> > > >>
> > > >> On 05/15/18 15:02, Marvin Häuser wrote:
> > >
> > > >>> 3.2: I think adding them as volatile variables is the better
> > > >>> approach, except for platform-specific code, which should be
> > > >>> capable of adding NV options. The reasoning behind this is that
> > > >>> usually the found volumes are removable volumes (such as USB
> > > >>> Flash
> > > >>> Drives) and will be cleaned away soon again anyway. "Extra wishes"
> > > >>> for boot options should be added via the UEFI Setup menu or UEFI
> > Shell.
> > > >>
> > > >> I can't really comment on this -- the fact that Boot options
> > > >> are
> > > >> non- volatile comes from the UEFI spec. I'm not immediately sure
> > > >> what I think of their suggested volatility, but this is likely
> > > >> something for the
> > > USWG to discuss.
> > > >
> > > > I think I might have been unclear here, I was solely referring to
> > > > the Boot
> > > options created by the enumeration process and not Boot in
> general.
> > > > I wouldn't know of anything restricting all Boot variables to
> > > > be NV, do
> > > you happen to have a quote?
> > >
> > > See "3.3 Globally Defined Variables" and "Table 10. Global Variables"
> > > in the
> > > UEFI-2.7 spec:
> > >
> > >   [...] The variables with an attribute of NV are nonvolatile. [...]
> > >
> > >   [...]
> > >
> > >   Variable Name  Attribute   Description
> > >   -  -   ---
> > >   [...]
> > >   Boot   NV, BS, RT  [...]
> > >   [...]
> >
> > I had hoped it was a recommendation, but indeed it seems to be
> mandatory.
> > What's your opinion on this fact and how do you think the chances are
> > NV could be made optional?
> >
> > >
> > > >> Second, just because a boot option fails, it should not be remove

[edk2] [PATCH] MdePkg/Hpet: Add Event Timer Block ID definition.

[Marvin Häuser]

This patch adds the HPET Event Timer Block ID definition that can be
found in the IA-PC HPET Specification, section 3.2.4.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h | 18 
+-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h 
b/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h
index 0d83cd5335de..926445233944 100644
--- a/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h
+++ b/MdePkg/Include/IndustryStandard/HighPrecisionEventTimerTable.h
@@ -2,7 +2,7 @@
   ACPI high precision event timer table definition, at www.intel.com
   Specification name is IA-PC HPET (High Precision Event Timers) Specification.
 
-  Copyright (c) 2007 - 2008, Intel Corporation. All rights reserved.
+  Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
   This program and the accompanying materials  
   are licensed and made available under the terms and conditions of the BSD 
License 
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -22,6 +22,22 @@
 //
 #pragma pack(1)
 
+///
+/// HPET Event Timer Block ID described in IA-PC HPET Specification, 3.2.4.
+///
+typedef union {
+  struct {
+UINT32 Revision   : 8;
+UINT32 NumberOfTimers : 5;
+UINT32 CounterSize: 1;
+UINT32 Reserved   : 1;
+UINT32 LegacyRoute: 1;
+UINT32 VendorId   : 16;
+  }  Bits;
+  UINT32 Uint32;
+} EFI_ACPI_HIGH_PRECISION_EVENT_TIMER_BLOCK_ID;
+
+
 ///
 /// High Precision Event Timer Table header definition.
 ///
-- 
2.17.0.windows.1

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

Re: [edk2] Proposition of a BmEnumerateBootOptions() hook.

[Marvin Häuser]

Thanks for your feedback!
Comments inline

Regards,
Marvin.

> -Original Message-
> From: Laszlo Ersek <ler...@redhat.com>
> Sent: Tuesday, May 15, 2018 6:12 PM
> To: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-
> de...@lists.01.org
> Cc: gso...@gmail.com; ard.biesheu...@linaro.org; ruiyu...@intel.com;
> eric.d...@intel.com; star.z...@intel.com; jordan.l.jus...@intel.com
> Subject: Re: [edk2] Proposition of a BmEnumerateBootOptions() hook.
> 
> On 05/15/18 17:38, Marvin Häuser wrote:
> >> -Original Message-
> >> From: Laszlo Ersek <ler...@redhat.com>
> >> Sent: Tuesday, May 15, 2018 3:53 PM
> >> To: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-
> >> de...@lists.01.org
> >> Cc: eric.d...@intel.com; star.z...@intel.com;
> >> jordan.l.jus...@intel.com; ard.biesheu...@linaro.org;
> >> ruiyu...@intel.com; Gabriel L. Somlo (GMail) <gso...@gmail.com>; Gerd
> >> Hoffmann <kra...@redhat.com>
> >> Subject: Re: [edk2] Proposition of a BmEnumerateBootOptions() hook.
> >>
> >> On 05/15/18 15:02, Marvin Häuser wrote:
> 
> >>> 3.2: I think adding them as volatile variables is the better
> >>> approach, except for platform-specific code, which should be capable
> >>> of adding NV options. The reasoning behind this is that usually the
> >>> found volumes are removable volumes (such as USB Flash Drives) and
> >>> will be cleaned away soon again anyway. "Extra wishes" for boot
> >>> options should be added via the UEFI Setup menu or UEFI Shell.
> >>
> >> I can't really comment on this -- the fact that Boot options are
> >> non- volatile comes from the UEFI spec. I'm not immediately sure what
> >> I think of their suggested volatility, but this is likely something for the
> USWG to discuss.
> >
> > I think I might have been unclear here, I was solely referring to the Boot
> options created by the enumeration process and not Boot in general.
> > I wouldn't know of anything restricting all Boot variables to be NV, do
> you happen to have a quote?
> 
> See "3.3 Globally Defined Variables" and "Table 10. Global Variables" in the
> UEFI-2.7 spec:
> 
>   [...] The variables with an attribute of NV are nonvolatile. [...]
> 
>   [...]
> 
>   Variable Name  Attribute   Description
>   -  -   ---
>   [...]
>   Boot   NV, BS, RT  [...]
>   [...]

I had hoped it was a recommendation, but indeed it seems to be mandatory.
What's your opinion on this fact and how do you think the chances are NV could 
be made optional?

> 
> >> Second, just because a boot option fails, it should not be removed.
> >> For example, a netboot option could fail, or a USB drive might not be
> >> connected (temporarily). I don't think that's grounds enough for
> >> summarily removing a boot option, in shared reference code.
> >
> > Oh, I was just talking about the possibility, because the current code does
> remove options under certain conditions.
> > However, for USB devices as you have mentioned, I do see this good
> practice so long as the option is volatile.
> > There is no point in exposing a boot option to a removable device that is
> not attached if not to prevent unnecessary Flash cycles as far as I can think.
> > Do you happen to have worries about a scenario I did not consider?
> 
> Sure; it's a simple scenario: the user might want the system to automatically
> boot off of a USB drive whenever they connect it, before powering on or
> rebooting the system, rather than boot from the hard drive.

Remember that point was made in the context of enumeration. What I was saying 
is that boot options created by the enum code, for removable drives, are fine 
to be gone (as they are volatile, or proactively removed when NV) after a 
reboot.
If a user wants to boot from such an USB device by default, in my opinion they 
should manually create a boot option for it. Otherwise, if I do not 
misunderstand your point, you are suggesting the firmware to keep track of 
every single bootable USB device ever attached.

> 
> (For USB devices, "USB WWID" and "USB Class" device path nodes are
> defined by the spec, so the user isn't even expected to plug the drive into
> the same USB port, for the drive to be found uniquely.)

Actually didn't know that, thanks for the fact!

> 
> >>> Primary partition: The so-called "Startup Volume" unfortunately is a
> >>> bit trickier. For it, a practically invalid Boot Option is added,
> >>> which is an expanded device path

Re: [edk2] Proposition of a BmEnumerateBootOptions() hook.

[Marvin Häuser]

> -Original Message-
> From: Laszlo Ersek <ler...@redhat.com>
> Sent: Tuesday, May 15, 2018 3:53 PM
> To: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-
> de...@lists.01.org
> Cc: eric.d...@intel.com; star.z...@intel.com; jordan.l.jus...@intel.com;
> ard.biesheu...@linaro.org; ruiyu...@intel.com; Gabriel L. Somlo (GMail)
> <gso...@gmail.com>; Gerd Hoffmann <kra...@redhat.com>
> Subject: Re: [edk2] Proposition of a BmEnumerateBootOptions() hook.
> 
> On 05/15/18 15:02, Marvin Häuser wrote:
> >> -Original Message-
> >> From: Laszlo Ersek <ler...@redhat.com>
> >> Sent: Tuesday, May 15, 2018 10:22 AM
> >> To: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-
> >> de...@lists.01.org
> >> Cc: eric.d...@intel.com; star.z...@intel.com
> >> Subject: Re: [edk2] Proposition of a BmEnumerateBootOptions() hook.
> >>
> >> On 05/14/18 21:00, Marvin Häuser wrote:
> >>> [...] there is a
> >>> function in the UefiBootManagerLib, "BmEnumerateBootOptions()",
> >>> which is called prior to entering the Boot Menu and, in my opinion,
> >>> would be the perfect place to introduce another
> >>> PlatformBootManagerLib hook, which retrieves platform-specific boot
> >>> options, such as an UEFI Shell or other utilities like a Memory Test
> >>> application.
> >>
> >> Hmmm, I'm not sure. The only function that calls
> >> BmEnumerateBootOptions() is EfiBootManagerRefreshAllBootOption().
> The
> >> latter is a public UefiBootManagerLib API that several
> >> PlatformBootManagerLib instances call, usually from
> >> PlatformBootManagerAfterConsole().
> PlatformBootManagerAfterConsole()
> >
> > I have misunderstood the current edk2 logic to be what I expected
> > (partially), however I have just discovered that scanned boot options
> > are added to NV and to BootOrder.
> 
> This is not a coincidence. That's what the
> EfiBootManagerRefreshAllBootOption() API does, by design, and that's the
> functionality for which platforms call the API.
> 
> > Furthermore, I did not mention another usage case for the proposed
> > hook as I thought it was practically irrelevant to the edk2 community:
> > Supporting Apple's bless boot concept. (For those who wonder,
> > virtualizing macOS on Apple hardware is perfectly legal). So, I will
> > have to explain a bit more in detail, in two parts.
> >
> > UEFI BOOT
> >
> > What I imagined to be the boot flow, by the specification and by my
> > personal taste, is the following:
> > 1. Boot BootOrder[] one-by-one. This connects the referenced drive and
> >attempts to start the specified file. This is the case today.
> > 2. Boot *Recovery[]. This is the case today.
> > 3. There are two alternatives here, based on platform preference.
> > 3.1. Boot enumerated drives (via the algorithm defined in the UEFI
> >  spec). I think this is not the case today.
> > 3.2. Enumerate the drives (via the algorithm defined in the UEFI spec)
> >  and show them in BootManagerMenuApp. I think this is done today
> >  and is what I would prefer too.
> >
> > What I basically do not agree with in the list above are two nuances.
> > 3.1 and 3.2: I would like to see support for a platform-defined logic
> > of enumerating in addition to the one defined in the UEFI spec. This
> > can be used for UEFI Shell, platform diagnostic apps and Apple bless.
> 
> I think platform-specific boot option generation -- enumeration of various
> protocols that stand for different kinds of devices, and generating boot
> options from them -- is already possible today.
> Platforms call EfiBootManagerRefreshAllBootOption() because (a) it's easy to
> call, (b) it generally does the right thing.

It surely is possible today, the proposition is more concerned about 
performance and "best practice".
I simply don't see a good reason to perform scanning and boot option writing 
when there is no code to read that (yet).
Of course this makes it come down to maintainer's preference because there is 
no significant demand.

> 
> (Note that this API does not connect devices; it just scans devices and turns
> whatever it finds into boot options.)
> 
> Nothing stops a platform from *not* calling
> EfiBootManagerRefreshAllBootOption() -- the platform can simply skip that
> and generate other options. Or the platform may generate options in
> addition to those that are generated by the API.

That is perfectly valid for the Status Quo, however if my NV vs volatile 
comment should be considered, it will not be b

Re: [edk2] Proposition of a BmEnumerateBootOptions() hook.

[Marvin Häuser]

Hi Laszlo, thanks for your feedback!
Comments are inline.

I also CC'd Jordan and Ard because of OVMF references in the third comment.
Thanks in advance for your time!

I have rewritten a few parts multiple times, so, if something doesn't make 
sense (because I forgot to rework it in the context), please feel free to ask 
for clarification.

Best regards,
Marvin

> -Original Message-
> From: Laszlo Ersek 
> Sent: Tuesday, May 15, 2018 10:22 AM
> To: Marvin H?user ; edk2-
> de...@lists.01.org
> Cc: eric.d...@intel.com; star.z...@intel.com
> Subject: Re: [edk2] Proposition of a BmEnumerateBootOptions() hook.
> 
> On 05/14/18 21:00, Marvin H?user wrote:
> > Hey Star, Eric and everyone else,
> >
> > I have seen that some platforms add a Boot Option for the UEFI Shell
> > in "PlatformBootManagerBeforeConsole()", which is called as part of
> > the regular boot flow. This is surely beneficial for development
> > platforms that are supposed to boot to UEFI Shell by default when no
> > other option has been registered,
> 
> (Side point: I sure wish *all* platforms included the UEFI shell, one way or
> another. Debugging issues is the *default* state of any computing system
> (all software has bugs), so debug tools must be a first class citizen. Forums
> are full of end-users asking for the UEFI shell on their physical platforms;
> frequently because their platform firmware gives them an extremely limited
> interface to managing boot and driver options, and the shell is seen as a way
> out of that, justifiedly.)

Definitely, sadly capacity and OEM mentality are still issues.
My point is just that a common user should not land in UEFI Shell by accident, 
but it should be explicitly launched.

> 
> > however for retail platforms it usually makes more sense to show the
> > UEFI Boot Menu,
> 
> Note that this is already solved in BdsDxe (if I understand your point
> anyway); please refer to commit d1de487dd2e7 ("MdeModulePkg/BdsDxe:
> fall back to a Boot Manager Menu loop before hanging", 2017-11-27).

Oh interesting, thanks! That might resolve it, but I didn't check it out yet.

> 
> > which renders adding the Shell Boot Option as part of the regular boot
> > flow obsolete and just adds up to the boot time. Meanwhile, there is a
> > function in the UefiBootManagerLib, "BmEnumerateBootOptions()", which
> > is called prior to entering the Boot Menu and, in my opinion, would be
> > the perfect place to introduce another PlatformBootManagerLib hook,
> > which retrieves platform-specific boot options, such as an UEFI Shell
> > or other utilities like a Memory Test application.
> 
> Hmmm, I'm not sure. The only function that calls
> BmEnumerateBootOptions() is EfiBootManagerRefreshAllBootOption(). The
> latter is a public UefiBootManagerLib API that several
> PlatformBootManagerLib instances call, usually from
> PlatformBootManagerAfterConsole(). PlatformBootManagerAfterConsole()

I have misunderstood the current edk2 logic to be what I expected (partially), 
however I have just discovered that scanned boot options are added to NV and to 
BootOrder. Furthermore, I did not mention another usage case for the proposed 
hook as I thought it was practically irrelevant to the edk2 community: 
Supporting Apple's bless boot concept. (For those who wonder, virtualizing 
macOS on Apple hardware is perfectly legal). So, I will have to explain a bit 
more in detail, in two parts.

UEFI BOOT

What I imagined to be the boot flow, by the specification and by my personal 
taste, is the following:
1. Boot BootOrder[] one-by-one. This connects the referenced drive and attempts 
to start the specified file. This is the case today.
2. Boot *Recovery[]. This is the case today.
3. There are two alternatives here, based on platform preference.
3.1. Boot enumerated drives (via the algorithm defined in the UEFI spec). I 
think this is not the case today.
3.2. Enumerate the drives (via the algorithm defined in the UEFI spec) and show 
them in BootManagerMenuApp. I think this is done today and is what I would 
prefer too.

What I basically do not agree with in the list above are two nuances.
3.1 and 3.2: I would like to see support for a platform-defined logic of 
enumerating in addition to the one defined in the UEFI spec. This can be used 
for UEFI Shell, platform diagnostic apps and Apple bless.
3.2: I think adding them as volatile variables is the better approach, except 
for platform-specific code, which should be capable of adding NV options. The 
reasoning behind this is that usually the found volumes are removable volumes 
(such as USB Flash Drives) and will be cleaned away soon again anyway. "Extra 
wishes" for boot options should be added via the UEFI Setup menu or UEFI Shell.
The reason why I still wish for platform code to be able to add NV options as 
part of enumeration is that FV-embedded tools are indeed NV (Shell etc.) and 
will not need to be cleaned up, as well as that we're 

[edk2] [PATCH] EmulatorPkg/SmbiosLib: Declare the correct library class.

[Marvin Häuser]

Currently, SmbiosLib declares the PcdLib library class. Update the
declaration to declare SmbiosLib.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf 
b/EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf
index adcd7ef08e20..a688fe02f225 100644
--- a/EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf
+++ b/EmulatorPkg/Library/SmbiosLib/SmbiosLib.inf
@@ -2,7 +2,7 @@
 # SMBIOS Library 
 #
 # Copyright (c) 2012, Apple Inc. All rights reserved. 
-# Portions copyright (c) 2006 - 2010, Intel Corporation. All rights 
reserved.
+# Portions copyright (c) 2006 - 2018, 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
@@ -20,7 +20,7 @@ [Defines]
   FILE_GUID  = 881863A2-09FD-3E44-8D62-7AE038D03747
   MODULE_TYPE= DXE_DRIVER
   VERSION_STRING = 1.0
-  LIBRARY_CLASS  = PcdLib|DXE_CORE DXE_DRIVER 
DXE_RUNTIME_DRIVER DXE_SAL_DRIVER DXE_SMM_DRIVER SMM_CORE UEFI_APPLICATION 
UEFI_DRIVER 
+  LIBRARY_CLASS  = SmbiosLib|DXE_CORE DXE_DRIVER 
DXE_RUNTIME_DRIVER DXE_SAL_DRIVER DXE_SMM_DRIVER SMM_CORE UEFI_APPLICATION 
UEFI_DRIVER 
 
   CONSTRUCTOR= SmbiosLibConstructor
 
-- 
2.17.0.windows.1

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

[edk2] [PATCH] MdePkg: Update MmSwDispatch.h's references to SmmSw2Dispatch.

[Marvin Häuser]

MmSwDispatch.h current refers to the deprecated SmmSw2Dispatch
protocol. Replace those references with the new MmSwDispatch name.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Include/Protocol/MmSwDispatch.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/MdePkg/Include/Protocol/MmSwDispatch.h 
b/MdePkg/Include/Protocol/MmSwDispatch.h
index d3acb64e6f3d..44ef69ed76c6 100644
--- a/MdePkg/Include/Protocol/MmSwDispatch.h
+++ b/MdePkg/Include/Protocol/MmSwDispatch.h
@@ -4,7 +4,7 @@
 
   This protocol provides the parent dispatch service for a given MMI source 
generator.
 
-  Copyright (c) 2017, Intel Corporation. All rights reserved.
+  Copyright (c) 2017 - 2018, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -15,8 +15,8 @@
 
 **/
 
-#ifndef _MM_SW_DISPATCH2_H_
-#define _MM_SW_DISPATCH2_H_
+#ifndef _MM_SW_DISPATCH_H_
+#define _MM_SW_DISPATCH_H_
 
 #include 
 
@@ -117,7 +117,7 @@ EFI_STATUS
 ///
 /// Interface structure for the MM Software MMI Dispatch Protocol.
 ///
-/// The EFI_MM_SW_DISPATCH2_PROTOCOL provides the ability to install child 
handlers for the
+/// The EFI_MM_SW_DISPATCH_PROTOCOL provides the ability to install child 
handlers for the
 /// given software.  These handlers will respond to software interrupts, and 
the maximum software
 /// interrupt in the EFI_MM_SW_REGISTER_CONTEXT is denoted by MaximumSwiValue.
 ///
-- 
2.17.0.windows.1

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

Re: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c

[Marvin Häuser]

Hey Tim,

The compiler has no information regarding the size of the stack and hence 
cannot determine an overflow.
This is basically a warning that stack of a single function is big enough to 
reach past the Guard Page and ensures it will be accessed.

Yao,

I just realized there already is Stack protection code in edk2, I was only 
aware of Heap protection.
Wouldn't a proper implementation make sense now to maybe not expand the stack, 
but at least runtime-error?

Regards,
Marvin

> -Original Message-
> From: Tim Lewis <tim.le...@insyde.com>
> Sent: Wednesday, May 9, 2018 3:28 AM
> To: 'Yao, Jiewen' <jiewen@intel.com>; marvin.haeu...@outlook.com;
> edk2-devel@lists.01.org
> Subject: RE: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> 
> I think that this is a fatal error in EDK2. It basically says, "we are out of 
> stack
> space." The alternative is: the system hangs in an unexpected way since the
> stack overflows into other pages.
> 
> Tim
> 
> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Yao,
> Jiewen
> Sent: Tuesday, May 8, 2018 5:25 PM
> To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> 
> We discussed internally in Intel.
> 
> The quick workaround is: use /Gs65536. :-)
> 
> At the same time, our recommendation is to revisit the code which triggers
> this error. Why this function need such a big stack? And try to reduce the
> local stack usage.
> 
> What is why we still use /Gs32768 as default, instead of /Gs65536.
> 
> Thank you
> Yao Jiewen
> 
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Marvin H?user
> > Sent: Tuesday, May 8, 2018 5:21 PM
> > To: edk2-devel@lists.01.org
> > Cc: Yao, Jiewen <jiewen@intel.com>
> > Subject: Re: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> >
> > Oh, if you are prefering a good implementation, I will be all for
> > that. This was just a 'quick workaround', same as currently done for GCC.
> > I'm actually unsure whether a good implementation is possible with a
> > flat memory model. It will likely be mere luck whether there is enough
> > space free below the stack, except for maybe when it's located very
> > high (preferably past the 32-bit space).
> > Has there been any prior discussion on this topic? Would be interested
> > to follow up if there was.
> >
> > Thanks,
> > Marvin
> >
> > > -Original Message-
> > > From: Yao, Jiewen <jiewen@intel.com>
> > > Sent: Wednesday, May 9, 2018 2:13 AM
> > > To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> > > Cc: Gao, Liming <liming@intel.com>
> > > Subject: RE: [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> > >
> > > There are some open source implementation:
> > > MSVC: https://github.com/ispc/ispc/issues/542
> > > GCC:
> > >
> https://android.googlesource.com/toolchain/gcc/+/b094d6c4bf572654a03
> > > 1e cc4afe675154c886dc5/gcc-4.4.3/gcc/config/i386/chkstk.asm
> > >
> > > The compiler generated code assumes the stack is enlarged after we
> > > can chkstk.
> > >
> > > I agree empty function can make build pass.
> > > But more important, we need make it work if there is a need to
> > > increase the stack.
> > > The potential issue is that the later code (after chkstk) assumes
> > > the stack is increased, but actually it is not.
> > >
> > > That is why I ask how this is validated.
> > >
> > > Thank you
> > > Yao Jiewen
> > >
> > >
> > > > -Original Message-
> > > > From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> > > > Sent: Tuesday, May 8, 2018 4:58 PM
> > > > To: edk2-devel@lists.01.org
> > > > Cc: Yao, Jiewen <jiewen@intel.com>; Gao, Liming
> > > > <liming@intel.com>
> > > > Subject: RE: [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> > > >
> > > > Hey Yao,
> > > >
> > > > As far as I am aware, all __chkstk does is access the stack in 4
> > > > KB intervals from the current location to the maximum requested
> > > > location to eventually hit the Windows Guard Page, which then
> > > > triggers the stack
> > > increase.
> > > > Because I do not know of any equivalent concept in edk2 and the
> > > > intrinsic was

Re: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c

[Marvin Häuser]

Oh, if you are prefering a good implementation, I will be all for that. This 
was just a 'quick workaround', same as currently done for GCC.
I'm actually unsure whether a good implementation is possible with a flat 
memory model. It will likely be mere luck whether there is enough space free 
below the stack, except for maybe when it's located very high (preferably past 
the 32-bit space).
Has there been any prior discussion on this topic? Would be interested to 
follow up if there was.

Thanks,
Marvin

> -Original Message-
> From: Yao, Jiewen <jiewen@intel.com>
> Sent: Wednesday, May 9, 2018 2:13 AM
> To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming@intel.com>
> Subject: RE: [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> 
> There are some open source implementation:
> MSVC: https://github.com/ispc/ispc/issues/542
> GCC:
> https://android.googlesource.com/toolchain/gcc/+/b094d6c4bf572654a031e
> cc4afe675154c886dc5/gcc-4.4.3/gcc/config/i386/chkstk.asm
> 
> The compiler generated code assumes the stack is enlarged after we can
> chkstk.
> 
> I agree empty function can make build pass.
> But more important, we need make it work if there is a need to increase the
> stack.
> The potential issue is that the later code (after chkstk) assumes the stack is
> increased, but actually it is not.
> 
> That is why I ask how this is validated.
> 
> Thank you
> Yao Jiewen
> 
> 
> > -Original Message-
> > From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> > Sent: Tuesday, May 8, 2018 4:58 PM
> > To: edk2-devel@lists.01.org
> > Cc: Yao, Jiewen <jiewen@intel.com>; Gao, Liming
> > <liming@intel.com>
> > Subject: RE: [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> >
> > Hey Yao,
> >
> > As far as I am aware, all __chkstk does is access the stack in 4 KB
> > intervals from the current location to the maximum requested location
> > to eventually hit the Windows Guard Page, which then triggers the stack
> increase.
> > Because I do not know of any equivalent concept in edk2 and the
> > intrinsic was already disabled for GCC, I supposed it was a good idea
> > to do so globally. Are the potential issues I am not aware of?
> >
> > Thanks,
> > Marvin.
> >
> > > -Original Message-
> > > From: Yao, Jiewen <jiewen@intel.com>
> > > Sent: Wednesday, May 9, 2018 1:52 AM
> > > To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> > > Cc: Gao, Liming <liming@intel.com>
> > > Subject: RE: [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> > >
> > > HI Marvin
> > > Would you mind to share the information on how you test this update?
> > >
> > >
> > > Per my experience, chkstk not only does the check but also does the
> > > real work to allocate more stack.
> > >
> > > /Gs can be used to indicate the size (/Gs[num] control stack
> > > checking calls)
> > >
> > > We use /Gs32768 by default, see tools_def.txt.
> > >
> > > Usually, we just increase this value to override the default one, if
> > > we hit this issue.
> > >
> > > Thank you
> > > Yao Jiewen
> > >
> > > > -Original Message-
> > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> > > > Behalf Of Marvin H?user
> > > > Sent: Tuesday, May 8, 2018 4:37 PM
> > > > To: edk2-devel@lists.01.org
> > > > Cc: Gao, Liming <liming@intel.com>
> > > > Subject: Re: [edk2] [PATCH] MdePkg/BaseLib: Globally include
> > > > ChkStk.c
> > > >
> > > > Hey Liming,
> > > >
> > > > According to the MSDN documentation, the call will be inserted for
> > > > a stack usage past a defined threshold - 4 KB for IA32, 8 KB for X64
> (source:
> > > > https://msdn.microsoft.com/en-us/library/ms648426(v=vs.85).aspx).
> > > >
> > > > Thanks,
> > > > Marvin
> > > >
> > > > > -Ursprüngliche Nachricht-
> > > > > Von: Gao, Liming <liming@intel.com>
> > > > > Gesendet: Montag, 7. Mai 2018 14:16
> > > > > An: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> > > > > Cc: Kinney, Michael D <michael.d.kin...@intel.com>
> > > > > Betreff: RE: [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> > > > >
> > > > > Marvin:
> > > > >   In VS compiler, what case will trig

Re: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c

[Marvin Häuser]

Hey Yao,

As far as I am aware, all __chkstk does is access the stack in 4 KB intervals 
from the current location to the maximum requested location to eventually hit 
the Windows Guard Page, which then triggers the stack increase.
Because I do not know of any equivalent concept in edk2 and the intrinsic was 
already disabled for GCC, I supposed it was a good idea to do so globally. Are 
the potential issues I am not aware of?

Thanks,
Marvin.

> -Original Message-
> From: Yao, Jiewen 
> Sent: Wednesday, May 9, 2018 1:52 AM
> To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: RE: [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> 
> HI Marvin
> Would you mind to share the information on how you test this update?
> 
> 
> Per my experience, chkstk not only does the check but also does the real
> work to allocate more stack.
> 
> /Gs can be used to indicate the size (/Gs[num] control stack checking calls)
> 
> We use /Gs32768 by default, see tools_def.txt.
> 
> Usually, we just increase this value to override the default one, if we hit 
> this
> issue.
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Marvin H?user
> > Sent: Tuesday, May 8, 2018 4:37 PM
> > To: edk2-devel@lists.01.org
> > Cc: Gao, Liming 
> > Subject: Re: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> >
> > Hey Liming,
> >
> > According to the MSDN documentation, the call will be inserted for a
> > stack usage past a defined threshold - 4 KB for IA32, 8 KB for X64 (source:
> > https://msdn.microsoft.com/en-us/library/ms648426(v=vs.85).aspx).
> >
> > Thanks,
> > Marvin
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Gao, Liming 
> > > Gesendet: Montag, 7. Mai 2018 14:16
> > > An: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> > > Cc: Kinney, Michael D 
> > > Betreff: RE: [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> > >
> > > Marvin:
> > >   In VS compiler, what case will trig this intrinsic function?
> > >
> > > Thanks
> > > Liming
> > > > -Original Message-
> > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> > > > Behalf Of Marvin H?user
> > > > Sent: Saturday, May 5, 2018 10:25 PM
> > > > To: edk2-devel@lists.01.org
> > > > Cc: Kinney, Michael D ; Gao, Liming
> > > > 
> > > > Subject: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> > > >
> > > > Initially added for GCC build support, this patch includes the
> > > > function for all compilers and all architectures. This is done as
> > > > huge variables on the stack may cause the generation of calls to
> > > > this intrinsic function for Microsoft compilers, even for the IA32
> > > > architecture, too.
> > > >
> > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > Signed-off-by: Marvin Haeuser 
> > > > ---
> > > >  MdePkg/Library/BaseLib/{ChkStkGcc.c => ChkStk.c} | 48
> > > > ++--
> > > 
> > > >  MdePkg/Library/BaseLib/BaseLib.inf   |  4 +-
> > > >  2 files changed, 26 insertions(+), 26 deletions(-)
> > > >
> > > > diff --git a/MdePkg/Library/BaseLib/ChkStkGcc.c
> > > > b/MdePkg/Library/BaseLib/ChkStk.c similarity index 74% rename from
> > > > MdePkg/Library/BaseLib/ChkStkGcc.c
> > > > rename to MdePkg/Library/BaseLib/ChkStk.c index
> > > > ecba3853b159..59e6d73f9331 100644
> > > > --- a/MdePkg/Library/BaseLib/ChkStkGcc.c
> > > > +++ b/MdePkg/Library/BaseLib/ChkStk.c
> > > > @@ -1,24 +1,24 @@
> > > > -/** @file
> > > > -  Provides hack function for passng GCC build.
> > > > -
> > > > -  Copyright (c) 2006 - 2008, Intel Corporation. All rights
> > > > reserved.
> > > > -  This program and the accompanying materials
> > > > -  are licensed and made available under the terms and conditions
> > > > of the BSD License
> > > > -  which accompanies this distribution.  The full text of the
> > > > license may be found at
> > > > -  http://opensource.org/licenses/bsd-license.php.
> > > > -
> > > > -  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS
> IS"
> > > > BASIS,
> > > > -  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> > > EXPRESS OR IMPLIED.
> > > > -
> > > > -**/
> > > > -
> > > > -#include "BaseLibInternals.h"
> > > > -
> > > > -/**
> > > > -  Hack function for passing GCC build.
> > > > -**/
> > > > -VOID
> > > > -__chkstk()
> > > > -{
> > > > -}
> > > > -
> > > > +/** @file
> > > > +  Provides hack function for passing build.
> > > > +
> > > > +  Copyright (c) 2006 - 2018, Intel Corporation. All rights
> > > > + reserved.  This program and the accompanying materials  are
> > > > + licensed and made available under the terms and conditions of
> > > > + the BSD License  which accompanies this distribution.  The full
> > > > + text 

Re: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c

[Marvin Häuser]

Hey Liming,

According to the MSDN documentation, the call will be inserted for a stack 
usage past a defined threshold - 4 KB for IA32, 8 KB for X64 (source: 
https://msdn.microsoft.com/en-us/library/ms648426(v=vs.85).aspx).

Thanks,
Marvin

> -Ursprüngliche Nachricht-
> Von: Gao, Liming 
> Gesendet: Montag, 7. Mai 2018 14:16
> An: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> Cc: Kinney, Michael D 
> Betreff: RE: [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> 
> Marvin:
>   In VS compiler, what case will trig this intrinsic function?
> 
> Thanks
> Liming
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Marvin H?user
> > Sent: Saturday, May 5, 2018 10:25 PM
> > To: edk2-devel@lists.01.org
> > Cc: Kinney, Michael D ; Gao, Liming
> > 
> > Subject: [edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c
> >
> > Initially added for GCC build support, this patch includes the
> > function for all compilers and all architectures. This is done as huge
> > variables on the stack may cause the generation of calls to this
> > intrinsic function for Microsoft compilers, even for the IA32
> > architecture, too.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Marvin Haeuser 
> > ---
> >  MdePkg/Library/BaseLib/{ChkStkGcc.c => ChkStk.c} | 48 ++--
> 
> >  MdePkg/Library/BaseLib/BaseLib.inf   |  4 +-
> >  2 files changed, 26 insertions(+), 26 deletions(-)
> >
> > diff --git a/MdePkg/Library/BaseLib/ChkStkGcc.c
> > b/MdePkg/Library/BaseLib/ChkStk.c similarity index 74% rename from
> > MdePkg/Library/BaseLib/ChkStkGcc.c
> > rename to MdePkg/Library/BaseLib/ChkStk.c index
> > ecba3853b159..59e6d73f9331 100644
> > --- a/MdePkg/Library/BaseLib/ChkStkGcc.c
> > +++ b/MdePkg/Library/BaseLib/ChkStk.c
> > @@ -1,24 +1,24 @@
> > -/** @file
> > -  Provides hack function for passng GCC build.
> > -
> > -  Copyright (c) 2006 - 2008, Intel Corporation. All rights
> > reserved.
> > -  This program and the accompanying materials
> > -  are licensed and made available under the terms and conditions of
> > the BSD License
> > -  which accompanies this distribution.  The full text of the license
> > may be found at
> > -  http://opensource.org/licenses/bsd-license.php.
> > -
> > -  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> > BASIS,
> > -  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> > -
> > -**/
> > -
> > -#include "BaseLibInternals.h"
> > -
> > -/**
> > -  Hack function for passing GCC build.
> > -**/
> > -VOID
> > -__chkstk()
> > -{
> > -}
> > -
> > +/** @file
> > +  Provides hack function for passing build.
> > +
> > +  Copyright (c) 2006 - 2018, Intel Corporation. All rights
> > + reserved.  This program and the accompanying materials  are
> > + licensed and made available under the terms and conditions of the
> > + BSD License  which accompanies this distribution.  The full text of
> > + the license may be found at  http://opensource.org/licenses/bsd-
> license.php.
> > +
> > +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> > + BASIS,  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND,
> EITHER EXPRESS OR IMPLIED.
> > +
> > +**/
> > +
> > +#include "BaseLibInternals.h"
> > +
> > +/**
> > +  Hack function for passing build.
> > +**/
> > +VOID
> > +__chkstk()
> > +{
> > +}
> > +
> > diff --git a/MdePkg/Library/BaseLib/BaseLib.inf
> > b/MdePkg/Library/BaseLib/BaseLib.inf
> > index 5fbbd02a94b6..d23a6db2581a 100644
> > --- a/MdePkg/Library/BaseLib/BaseLib.inf
> > +++ b/MdePkg/Library/BaseLib/BaseLib.inf
> > @@ -1,7 +1,7 @@
> >  ## @file
> >  #  Base Library implementation.
> >  #
> > -#  Copyright (c) 2007 - 2016, Intel Corporation. All rights
> > reserved.
> > +#  Copyright (c) 2007 - 2018, Intel Corporation. All rights
> > +reserved.
> >  #  Portions copyright (c) 2008 - 2009, Apple Inc. All rights
> > reserved.  #  Portions copyright (c) 2011 - 2013, ARM Ltd. All
> > rights reserved.  # @@ -64,6 +64,7 @@ [Sources]
> >SafeString.c
> >String.c
> >FilePaths.c
> > +  ChkStk.c
> >BaseLibInternals.h
> >
> >  [Sources.Ia32]
> > @@ -781,7 +782,6 @@ [Sources.X64]
> >X64/DisableCache.S | GCC
> >X64/RdRand.nasm| GCC
> >X64/RdRand.S | GCC
> > -  ChkStkGcc.c  | GCC
> >
> >  [Sources.IPF]
> >Ipf/AccessGp.s
> > --
> > 2.17.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 2/2] MdeModulePkg/AcpiPlatformDxe: Consume PlatformAcpiLib.

[Marvin Häuser]

This patch updates the generic ACPI Platform driver to consume
PlatformAcpiLib to allow platform specific updates to the ACPI tables
loaded from the configured Firmware Volume. This allows for more
platforms to incorporate the generic ACPI Platform driver.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c  | 55 

 MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatformDxe.inf |  1 +
 2 files changed, 33 insertions(+), 23 deletions(-)

diff --git a/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c 
b/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
index 8f335bde0d46..f1243279faa2 100644
--- a/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
+++ b/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -180,6 +181,7 @@ AcpiPlatformEntryPoint (
   UINT32 FvStatus;
   UINTN  TableSize;
   UINTN  Size;
+  RETURN_STATUS  Return;
 
   Instance = 0;
   CurrentTable = NULL;
@@ -216,35 +218,42 @@ AcpiPlatformEntryPoint (
   );
 if (!EFI_ERROR(Status)) {
   //
-  // Add the table
+  // Perform any platform-specific table updates.
   //
-  TableHandle = 0;
+  Return = PlatformAcpiUpdateTable (CurrentTable);
 
-  TableSize = ((EFI_ACPI_DESCRIPTION_HEADER *) CurrentTable)->Length;
-  ASSERT (Size >= TableSize);
+  if (!RETURN_ERROR (Return)) {
+//
+// Add the table
+//
+TableHandle = 0;
 
-  //
-  // Checksum ACPI table
-  //
-  AcpiPlatformChecksum ((UINT8*)CurrentTable, TableSize);
+TableSize = ((EFI_ACPI_DESCRIPTION_HEADER *) CurrentTable)->Length;
+ASSERT (Size >= TableSize);
 
-  //
-  // Install ACPI table
-  //
-  Status = AcpiTable->InstallAcpiTable (
-AcpiTable,
-CurrentTable,
-TableSize,
-
-);
+//
+// Checksum ACPI table
+//
+AcpiPlatformChecksum ((UINT8*)CurrentTable, TableSize);
 
-  //
-  // Free memory allocated by ReadSection
-  //
-  gBS->FreePool (CurrentTable);
+//
+// Install ACPI table
+//
+Status = AcpiTable->InstallAcpiTable (
+  AcpiTable,
+  CurrentTable,
+  TableSize,
+  
+  );
+
+//
+// Free memory allocated by ReadSection
+//
+gBS->FreePool (CurrentTable);
 
-  if (EFI_ERROR(Status)) {
-return EFI_ABORTED;
+if (EFI_ERROR(Status)) {
+  return EFI_ABORTED;
+}
   }
 
   //
diff --git a/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatformDxe.inf 
b/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatformDxe.inf
index 34b1600171d5..114a12dc3396 100644
--- a/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatformDxe.inf
+++ b/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatformDxe.inf
@@ -40,6 +40,7 @@ [LibraryClasses]
   PcdLib
   BaseMemoryLib
   DebugLib
+  PlatformAcpiLib
   UefiBootServicesTableLib
   UefiDriverEntryPoint
 
-- 
2.17.0.windows.1

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

[edk2] [PATCH 1/2] MdeModulePkg: Add PlatformAcpiLib LibraryClass.

[Marvin Häuser]

PlatformAcpiLib can be consumed by the generic ACPI Platform driver
to allow platform specific updates to the ACPI tables loaded from the
configured Firmware Volume. This allows for more platforms to
incorporate the generic ACPI Platform driver.

This commit also provides a NULL implementation of PlatformAcpiLib.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdeModulePkg/Library/BasePlatformAcpiLibNull/BasePlatformAcpiLibNull.c   | 36 

 MdeModulePkg/Include/Library/PlatformAcpiLib.h   | 36 

 MdeModulePkg/Library/BasePlatformAcpiLibNull/BasePlatformAcpiLibNull.inf | 35 
+++
 MdeModulePkg/Library/BasePlatformAcpiLibNull/BasePlatformAcpiLibNull.uni | 18 
++
 MdeModulePkg/MdeModulePkg.dec|  4 
+++
 MdeModulePkg/MdeModulePkg.dsc|  2 
++
 6 files changed, 131 insertions(+)

diff --git 
a/MdeModulePkg/Library/BasePlatformAcpiLibNull/BasePlatformAcpiLibNull.c 
b/MdeModulePkg/Library/BasePlatformAcpiLibNull/BasePlatformAcpiLibNull.c
new file mode 100644
index ..5d5d0d051e1b
--- /dev/null
+++ b/MdeModulePkg/Library/BasePlatformAcpiLibNull/BasePlatformAcpiLibNull.c
@@ -0,0 +1,36 @@
+/** @file
+  Null Platform ACPI Library instance.
+
+Copyright (c) 2018, Intel Corporation. All rights reserved.
+This program and the accompanying materials are licensed and made available 
under 
+the terms and conditions of the BSD License that accompanies this 
distribution.  
+The full text of the license may be found at
+http://opensource.org/licenses/bsd-license.php.

+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,  
   
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+
+#include 
+
+/**
+  Performs platform specific updates to CurrentTable.
+
+  @param[in,out] CurrentTable  The table to perform updates on.
+
+  @retval RETURN_SUCCESS  The platform specific ACPI table updates were applied
+  successfully.
+  @retval other   The platform specific ACPI table updates could not be
+  applied.
+  
+**/
+RETURN_STATUS
+PlatformAcpiUpdateTable (
+  IN OUT EFI_ACPI_COMMON_HEADER  *CurrentTable
+  )
+{
+  return RETURN_SUCCESS;
+}
diff --git a/MdeModulePkg/Include/Library/PlatformAcpiLib.h 
b/MdeModulePkg/Include/Library/PlatformAcpiLib.h
new file mode 100644
index ..a3e367f3ab61
--- /dev/null
+++ b/MdeModulePkg/Include/Library/PlatformAcpiLib.h
@@ -0,0 +1,36 @@
+/** @file
+  Platform ACPI library. Platform can provide an implementation of this
+  library class to provide an ACPI table update routine that may be required
+  for some type of platform initialization.
+
+Copyright (c) 2018, Intel Corporation. All rights reserved.
+This program and the accompanying materials are licensed and made available 
under 
+the terms and conditions of the BSD License that accompanies this 
distribution.  
+The full text of the license may be found at
+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 __PLATFORM_ACPI_LIB__
+#define __PLATFORM_ACPI_LIB__
+
+/**
+  Performs platform specific updates to CurrentTable.
+
+  @param[in,out] CurrentTable  The table to perform updates on.
+
+  @retval RETURN_SUCCESS  The platform specific ACPI table updates were applied
+  successfully.
+  @retval other   The platform specific ACPI table updates could not be
+  applied.
+  
+**/
+RETURN_STATUS
+PlatformAcpiUpdateTable (
+  IN OUT EFI_ACPI_COMMON_HEADER  *CurrentTable
+  );
+
+#endif // __PLATFORM_ACPI_LIB__
diff --git 
a/MdeModulePkg/Library/BasePlatformAcpiLibNull/BasePlatformAcpiLibNull.inf 
b/MdeModulePkg/Library/BasePlatformAcpiLibNull/BasePlatformAcpiLibNull.inf
new file mode 100644
index ..a548ecdd91a7
--- /dev/null
+++ b/MdeModulePkg/Library/BasePlatformAcpiLibNull/BasePlatformAcpiLibNull.inf
@@ -0,0 +1,35 @@
+## @file
+#  Null Platform ACPI Library instance.
+#
+#  Copyright (c) 2018, Intel Corporation. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution. The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+##
+
+[Defines]
+  INF_VERSION

[edk2] [PATCH v2] MdeModulePkg/AcpiPlatformDxe: Unload after execution.

[Marvin Häuser]

AcpiPlatformDxe solely performs one-time tasks and does not expose
any services or create any events. Hence it can safely be unloaded
after the Entry Point execution by returning an error code.

V2: Return EFI_REQUEST_UNLOAD_IMAGE.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c 
b/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
index 44bdd94fa8db..8f335bde0d46 100644
--- a/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
+++ b/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
@@ -1,7 +1,7 @@
 /** @file
   Sample ACPI Platform Driver
 
-  Copyright (c) 2008 - 2011, Intel Corporation. All rights reserved.
+  Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -255,6 +255,9 @@ AcpiPlatformEntryPoint (
 }
   }
 
-  return EFI_SUCCESS;
+  //
+  // The driver does not require to be kept loaded.
+  //
+  return EFI_REQUEST_UNLOAD_IMAGE;
 }
 
-- 
2.17.0.windows.1

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

Re: [edk2] [PATCH] MdeModulePkg/AcpiPlatformDxe: Unload after execution.

[Marvin Häuser]

Sorry, I did not realize that error code was a thing.
Sure, I will submit a V2 soon, thanks!

Best regards,
Marvin

> -Ursprüngliche Nachricht-
> Von: Zeng, Star <star.z...@intel.com>
> Gesendet: Montag, 7. Mai 2018 03:52
> An: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>; Zeng,
> Star <star.z...@intel.com>
> Betreff: RE: [PATCH] MdeModulePkg/AcpiPlatformDxe: Unload after
> execution.
> 
> It is a good change. :)
> 
> Only one minor comment. How about using EFI_REQUEST_UNLOAD_IMAGE
> instead?
> 
> 
> ///
> /// If this value is returned by an EFI image, then the image should be
> unloaded.
> ///
> #define EFI_REQUEST_UNLOAD_IMAGE  DXE_ERROR (1)
> 
> 
> Thanks,
> Star
> -Original Message-
> From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> Sent: Saturday, May 5, 2018 10:26 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star <star.z...@intel.com>; Dong, Eric <eric.d...@intel.com>; Ni,
> Ruiyu <ruiyu...@intel.com>
> Subject: [PATCH] MdeModulePkg/AcpiPlatformDxe: Unload after execution.
> 
> AcpiPlatformDxe solely performs one-time tasks and does not expose any
> services or create any events. Hence it can safely be unloaded after the Entry
> Point execution by returning an error code.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marvin Haeuser <marvin.haeu...@outlook.com>
> ---
>  MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c | 7 +-
> -
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
> b/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
> index 44bdd94fa8db..8772961bfd31 100644
> --- a/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
> +++ b/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
> @@ -1,7 +1,7 @@
>  /** @file
>Sample ACPI Platform Driver
> 
> -  Copyright (c) 2008 - 2011, Intel Corporation. All rights reserved.
> +  Copyright (c) 2008 - 2018, Intel Corporation. All rights
> + reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution.  The full text of the license may be
> found at @@ -255,6 +255,9 @@ AcpiPlatformEntryPoint (
>  }
>}
> 
> -  return EFI_SUCCESS;
> +  //
> +  // Return an error code so that the driver is unloaded.
> +  //
> +  return EFI_ALREADY_STARTED;
>  }
> 
> --
> 2.17.0.windows.1

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

[edk2] [PATCH] ShellPkg/UefiShellLevel2CommandsLib: Fix ls on entirely empty directories.

[Marvin Häuser]

Currently, when 'ls' is run on an entirely empty directory (this
includes not having '.' and '..'), the output is always 'File not
found'. For when not filtering its children, this patch rather
displays the usual header and footer.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c | 33 +---
 1 file changed, 28 insertions(+), 5 deletions(-)

diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c 
b/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
index 7d2e15f5206b..324dcb6091c8 100644
--- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
+++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
@@ -423,6 +423,8 @@ FileTimeToLocalTime (
   @param[in] Found  Set to TRUE, if anyone were found.
   @param[in] Count  The count of bits enabled in Attribs.
   @param[in] TimeZone   The current time zone offset.
+  @param[in] ListUnfiltered TRUE to request listing the directory contents
+unfiltered.
 
   @retval SHELL_SUCCESS the printing was sucessful.
 **/
@@ -435,7 +437,8 @@ PrintLsOutput(
   IN CONST CHAR16  *SearchString,
   IN   BOOLEAN *Found,
   IN CONST UINTN   Count,
-  IN CONST INT16   TimeZone
+  IN CONST INT16   TimeZone,
+  IN CONST BOOLEAN ListUnfiltered
   )
 {
   EFI_STATUSStatus;
@@ -561,7 +564,7 @@ PrintLsOutput(
   HeaderPrinted = TRUE;
 }
 
-if (!Sfo && ShellStatus != SHELL_ABORTED) {
+if (!Sfo && ShellStatus != SHELL_ABORTED && HeaderPrinted) {
   PrintNonSfoFooter(FileCount, FileSize, DirCount);
 }
   }
@@ -608,7 +611,8 @@ PrintLsOutput(
 SearchString,
 ,
 Count,
-TimeZone);
+TimeZone,
+FALSE);
 
   //
   // Since it's running recursively, we have to break immediately when 
returned SHELL_ABORTED
@@ -625,7 +629,21 @@ PrintLsOutput(
   ShellCloseFileMetaArg();
 
   if (Found == NULL && !FoundOne) {
-return (SHELL_NOT_FOUND);
+if (ListUnfiltered) {
+  //
+  // When running "ls" without any filtering request, avoid outputing
+  // "File not found" when the directory is entirely empty, but print
+  // header and footer stating "0 File(s), 0 Dir(s)".
+  //
+  if (!Sfo) {
+PrintNonSfoHeader (RootPath);
+if (ShellStatus != SHELL_ABORTED) {
+  PrintNonSfoFooter (FileCount, FileSize, DirCount);
+}
+  }
+} else {
+  return (SHELL_NOT_FOUND);
+}
   }
 
   if (Found != NULL) {
@@ -668,6 +686,7 @@ ShellCommandRunLs (
   UINTN Size;
   EFI_TIME  TheTime;
   CHAR16*SearchString;
+  BOOLEAN   ListUnfiltered;
 
   Size= 0;
   FullPath= NULL;
@@ -679,6 +698,7 @@ ShellCommandRunLs (
   SearchString= NULL;
   CurDir  = NULL;
   Count   = 0;
+  ListUnfiltered  = FALSE;
 
   //
   // initialize the shell lib (we must be in non-auto-init...)
@@ -774,6 +794,7 @@ ShellCommandRunLs (
 ShellStatus = SHELL_NOT_FOUND;
 ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_GEN_NO_CWD), 
gShellLevel2HiiHandle, L"ls");  
   }
+  ListUnfiltered = TRUE;
   //
   // Copy to the 2 strings for starting path and file search string
   //
@@ -814,6 +835,7 @@ ShellCommandRunLs (
   //
   // is listing ends with a directory, then we list all files in 
that directory
   //
+  ListUnfiltered = TRUE;
   StrnCatGrow(, NULL, L"*", 0);
 } else {
   //
@@ -845,7 +867,8 @@ ShellCommandRunLs (
 SearchString,
 NULL,
 Count,
-TheTime.TimeZone
+TheTime.TimeZone,
+ListUnfiltered
);
   if (ShellStatus == SHELL_NOT_FOUND) {
 ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN 
(STR_LS_FILE_NOT_FOUND), gShellLevel2HiiHandle, L"ls", FullPath);  
-- 
2.17.0.windows.1

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

[edk2] [PATCH] ShellPkg/UefiShellCommandLib: Do not error-exit when PlatformLang is missing.

[Marvin Häuser]

Currently, when the PlatformLang variable is missing,
UefiShellCommandLib error-exits. To prevent the entire UEFI Shell
from failing to load over a missing variable, "en-US" is assumed when
the variable location fails.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c 
b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
index 0df252b42036..dfcfd2e0dd54 100644
--- a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
+++ b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
@@ -81,9 +81,6 @@ CommandInit(
   CHAR8   *PlatformLang;
   
   GetEfiGlobalVariable2 (EFI_PLATFORM_LANG_VARIABLE_NAME, 
(VOID**), NULL);
-  if (PlatformLang == NULL) {
-return EFI_UNSUPPORTED;
-  }
 
   if (gUnicodeCollation == NULL) {
 Status = gBS->LocateHandleBuffer (
@@ -120,7 +117,7 @@ CommandInit(
   BestLanguage = GetBestLanguage (
Uc->SupportedLanguages,
FALSE,
-   PlatformLang,
+   ((PlatformLang != NULL) ? PlatformLang : "en-US"),
NULL
);
   if (BestLanguage != NULL) {
@@ -132,7 +129,9 @@ CommandInit(
 if (Handles != NULL) {
   FreePool (Handles);
 }
-FreePool (PlatformLang);
+if (PlatformLang != NULL) {
+  FreePool (PlatformLang);
+}
   }
 
   return (gUnicodeCollation == NULL) ? EFI_UNSUPPORTED : EFI_SUCCESS;
-- 
2.17.0.windows.1

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

[edk2] [PATCH] MdePkg/UefiFileHandleLib: Fix the Root directory determination.

[Marvin Häuser]

The current implementation of the FileHandleGetFileName() function
assumes that the Root directory always has the FileName '\0'.
However, the only requirement the UEFI specification defines is that
a prepended '\\' must be supported to access files and folders
relative to the Root directory.
This patch removes this assumption and supports constructing valid
paths for any value of FileName for the Root Directory.

In practice, this fixes compatibility issues with File System drivers
that report '\\' as the FileName of the Root directory, which
currently is both generating an invalid path ("") and resulting
in an EFI_NOT_FOUND result from the CurrentHandle->Open() call.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c | 29 ++--
 1 file changed, 20 insertions(+), 9 deletions(-)

diff --git a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c 
b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
index 57aad77bc135..820801422996 100644
--- a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
+++ b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
@@ -1,7 +1,7 @@
 /** @file
   Provides interface to EFI_FILE_HANDLE functionality.
 
-  Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved. 
+  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved. 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -820,10 +820,25 @@ FileHandleGetFileName (
 Status = EFI_OUT_OF_RESOURCES;
 break;
   } else {
+//
+// Prepare to move to the parent directory.
+// Also determine whether CurrentHandle refers to the Root directory.
+//
+Status = CurrentHandle->Open (CurrentHandle, , L"..", 
EFI_FILE_MODE_READ, 0);
 //
 // We got info... do we have a name? if yes precede the current path 
with it...
 //
-if (StrLen (FileInfo->FileName) == 0) {
+if ((StrLen (FileInfo->FileName) == 0) || EFI_ERROR (Status)) {
+  //
+  // Both FileInfo->FileName being '\0' and EFI_ERROR() suggest that
+  // CurrentHandle refers to the Root directory.  As this loop ensures
+  // FullFileName is starting with '\\' at all times, signal success
+  // and exit the loop.
+  // While FileInfo->FileName could theoretically be a value other than
+  // '\0' or '\\', '\\' is guaranteed to be supported by the
+  // specification and hence its value can safely be ignored.
+  //
+  Status = EFI_SUCCESS;
   if (*FullFileName == NULL) {
 ASSERT((*FullFileName == NULL && Size == 0) || (*FullFileName != 
NULL));
 *FullFileName = StrnCatGrowLeft(FullFileName, , L"\\", 0);
@@ -841,15 +856,11 @@ FileHandleGetFileName (
   FreePool(FileInfo);
 }
   }
-  //
-  // Move to the parent directory
-  //
-  Status = CurrentHandle->Open (CurrentHandle, , L"..", 
EFI_FILE_MODE_READ, 0);
-  if (EFI_ERROR (Status)) {
-break;
-  }
 
   FileHandleClose(CurrentHandle);
+  //
+  // Move to the parent directory
+  //
   CurrentHandle = NextHigherHandle;
 }
   } else if (Status == EFI_NOT_FOUND) {
-- 
2.17.0.windows.1

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

[edk2] [PATCH] ShellPkg/UefiShellLevel2CommandsLib: Support unspecified local Timezone.

[Marvin Häuser]

EFI_RUNTIME_SERVICES.GetTime() might return an unspecified Timezone,
such as when SetTime() has not been called after the PC-AT CMOS RTC
was cut off power. Consider this case by not attempting Timezone
translations for when it is invalid.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c 
b/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
index 7d2e15f5206b..73804b4516ba 100644
--- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
+++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Ls.c
@@ -2,7 +2,7 @@
   Main file for ls shell level 2 function.
 
   (C) Copyright 2013-2015 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2009 - 2017, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -506,7 +506,7 @@ PrintLsOutput(
   // Change the file time to local time.
   //
   Status = gRT->GetTime(, NULL);
-  if (!EFI_ERROR (Status)) {
+  if (!EFI_ERROR (Status) && (LocalTime.TimeZone != 
EFI_UNSPECIFIED_TIMEZONE)) {
 if ((Node->Info->CreateTime.TimeZone != EFI_UNSPECIFIED_TIMEZONE) &&
 (Node->Info->CreateTime.Month >= 1 && Node->Info->CreateTime.Month 
<= 12)) {
   //
-- 
2.17.0.windows.1

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

[edk2] [PATCH] MdePkg/UefiFileHandleLib: Fix potential NULL dereference.

[Marvin Häuser]

Move the NULL-check in FileHandleGetInfo() to directly after the
allocation to prevent potential NULL dereferences.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c | 30 +++-
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c 
b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
index 57aad77bc135..bcf3a328b82d 100644
--- a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
+++ b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
@@ -1,7 +1,7 @@
 /** @file
   Provides interface to EFI_FILE_HANDLE functionality.
 
-  Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved. 
+  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved. 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -74,19 +74,21 @@ FileHandleGetInfo (
 // error is expected.  getting size to allocate
 //
 FileInfo = AllocateZeroPool(FileInfoSize);
-//
-// now get the information
-//
-Status = FileHandle->GetInfo(FileHandle,
- ,
- ,
- FileInfo);
-//
-// if we got an error free the memory and return NULL
-//
-if (EFI_ERROR(Status) && (FileInfo != NULL)) {
-  FreePool(FileInfo);
-  FileInfo = NULL;
+if (FileInfo != NULL) {
+  //
+  // now get the information
+  //
+  Status = FileHandle->GetInfo(FileHandle,
+   ,
+   ,
+   FileInfo);
+  //
+  // if we got an error free the memory and return NULL
+  //
+  if (EFI_ERROR(Status)) {
+FreePool(FileInfo);
+FileInfo = NULL;
+  }
 }
   }
   return (FileInfo);
-- 
2.17.0.windows.1

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

[edk2] [PATCH] MdeModulePkg/AcpiPlatformDxe: Unload after execution.

[Marvin Häuser]

AcpiPlatformDxe solely performs one-time tasks and does not expose
any services or create any events. Hence it can safely be unloaded
after the Entry Point execution by returning an error code.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c 
b/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
index 44bdd94fa8db..8772961bfd31 100644
--- a/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
+++ b/MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatform.c
@@ -1,7 +1,7 @@
 /** @file
   Sample ACPI Platform Driver
 
-  Copyright (c) 2008 - 2011, Intel Corporation. All rights reserved.
+  Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -255,6 +255,9 @@ AcpiPlatformEntryPoint (
 }
   }
 
-  return EFI_SUCCESS;
+  //
+  // Return an error code so that the driver is unloaded.
+  //
+  return EFI_ALREADY_STARTED;
 }
 
-- 
2.17.0.windows.1

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

[edk2] [PATCH] MdePkg/PeiServicesLib: Decorate 'PpiDescriptor' as OPTIONAL for LocatePpi().

[Marvin Häuser]

The UEFI PI specification defines PpiDescriptor to be OPTIONAL for
the LocatePpi PEI Service. This patch reflects this in the function
declaration and definition of the corresponding PeiServices library
function.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Library/PeiServicesLib/PeiServicesLib.c | 4 ++--
 MdePkg/Include/Library/PeiServicesLib.h| 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/MdePkg/Library/PeiServicesLib/PeiServicesLib.c 
b/MdePkg/Library/PeiServicesLib/PeiServicesLib.c
index d0838ed709f6..881b9cd52e1a 100644
--- a/MdePkg/Library/PeiServicesLib/PeiServicesLib.c
+++ b/MdePkg/Library/PeiServicesLib/PeiServicesLib.c
@@ -1,7 +1,7 @@
 /** @file
   Implementation for PEI Services Library.
 
-  Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -95,7 +95,7 @@ EFIAPI
 PeiServicesLocatePpi (
   IN CONST EFI_GUID   *Guid,
   IN UINTN  Instance,
-  IN OUT EFI_PEI_PPI_DESCRIPTOR **PpiDescriptor,
+  IN OUT EFI_PEI_PPI_DESCRIPTOR **PpiDescriptor, OPTIONAL
   IN OUT VOID   **Ppi
   )
 {
diff --git a/MdePkg/Include/Library/PeiServicesLib.h 
b/MdePkg/Include/Library/PeiServicesLib.h
index 0be72237f290..7cea34000c2f 100644
--- a/MdePkg/Include/Library/PeiServicesLib.h
+++ b/MdePkg/Include/Library/PeiServicesLib.h
@@ -1,7 +1,7 @@
 /** @file
   Provides library functions for all PEI Services.
 
-Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -73,7 +73,7 @@ EFIAPI
 PeiServicesLocatePpi (
   IN CONST EFI_GUID   *Guid,
   IN UINTN  Instance,
-  IN OUT EFI_PEI_PPI_DESCRIPTOR **PpiDescriptor,
+  IN OUT EFI_PEI_PPI_DESCRIPTOR **PpiDescriptor, OPTIONAL
   IN OUT VOID   **Ppi
   );
 
-- 
2.17.0.windows.1

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

[edk2] [PATCH] MdePkg/BaseLib: Globally include ChkStk.c

[Marvin Häuser]

Initially added for GCC build support, this patch includes the
function for all compilers and all architectures. This is done as
huge variables on the stack may cause the generation of calls to this
intrinsic function for Microsoft compilers, even for the IA32
architecture, too.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Library/BaseLib/{ChkStkGcc.c => ChkStk.c} | 48 ++--
 MdePkg/Library/BaseLib/BaseLib.inf   |  4 +-
 2 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/MdePkg/Library/BaseLib/ChkStkGcc.c 
b/MdePkg/Library/BaseLib/ChkStk.c
similarity index 74%
rename from MdePkg/Library/BaseLib/ChkStkGcc.c
rename to MdePkg/Library/BaseLib/ChkStk.c
index ecba3853b159..59e6d73f9331 100644
--- a/MdePkg/Library/BaseLib/ChkStkGcc.c
+++ b/MdePkg/Library/BaseLib/ChkStk.c
@@ -1,24 +1,24 @@
-/** @file
-  Provides hack function for passng GCC build.
-
-  Copyright (c) 2006 - 2008, Intel Corporation. All rights reserved.
-  This program and the accompanying materials
-  are licensed and made available under the terms and conditions of the BSD 
License
-  which accompanies this distribution.  The full text of the license may be 
found at
-  http://opensource.org/licenses/bsd-license.php.
-
-  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-
-#include "BaseLibInternals.h"
-
-/**
-  Hack function for passing GCC build.
-**/
-VOID 
-__chkstk() 
-{
-}
-
+/** @file
+  Provides hack function for passing build.
+
+  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php.
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include "BaseLibInternals.h"
+
+/**
+  Hack function for passing build.
+**/
+VOID 
+__chkstk() 
+{
+}
+
diff --git a/MdePkg/Library/BaseLib/BaseLib.inf 
b/MdePkg/Library/BaseLib/BaseLib.inf
index 5fbbd02a94b6..d23a6db2581a 100644
--- a/MdePkg/Library/BaseLib/BaseLib.inf
+++ b/MdePkg/Library/BaseLib/BaseLib.inf
@@ -1,7 +1,7 @@
 ## @file
 #  Base Library implementation.
 #
-#  Copyright (c) 2007 - 2016, Intel Corporation. All rights reserved.
+#  Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
 #  Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
 #  Portions copyright (c) 2011 - 2013, ARM Ltd. All rights reserved.
 #
@@ -64,6 +64,7 @@ [Sources]
   SafeString.c
   String.c
   FilePaths.c
+  ChkStk.c
   BaseLibInternals.h
 
 [Sources.Ia32]
@@ -781,7 +782,6 @@ [Sources.X64]
   X64/DisableCache.S | GCC
   X64/RdRand.nasm| GCC
   X64/RdRand.S | GCC
-  ChkStkGcc.c  | GCC 
 
 [Sources.IPF]
   Ipf/AccessGp.s
-- 
2.17.0.windows.1

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

[edk2] [PATCH v2 1/2] MdePkg/UefiLib: Add 'OUT' decorator where necessary.

[Marvin Häuser]

The functions AddUnicodeString() and AddUnicodeString2() might return
a new value into their parameter UnicodeStringTable, hence add the
appropiate 'OUT' decorator.

V2: Update FrameworkUefiLib as well.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Library/UefiLib/UefiLib.c | 18 +-
 MdePkg/Include/Library/UefiLib.h | 18 +-
 2 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/MdePkg/Library/UefiLib/UefiLib.c b/MdePkg/Library/UefiLib/UefiLib.c
index f1a3f1c7af05..ba449a1c34ce 100644
--- a/MdePkg/Library/UefiLib/UefiLib.c
+++ b/MdePkg/Library/UefiLib/UefiLib.c
@@ -888,10 +888,10 @@ LookupUnicodeString2 (
 EFI_STATUS
 EFIAPI
 AddUnicodeString (
-  IN CONST CHAR8   *Language,
-  IN CONST CHAR8   *SupportedLanguages,
-  IN EFI_UNICODE_STRING_TABLE  **UnicodeStringTable,
-  IN CONST CHAR16  *UnicodeString
+  IN CONST CHAR8   *Language,
+  IN CONST CHAR8   *SupportedLanguages,
+  IN OUT EFI_UNICODE_STRING_TABLE  **UnicodeStringTable,
+  IN CONST CHAR16  *UnicodeString
   )
 {
   UINTN NumberOfEntries;
@@ -1065,11 +1065,11 @@ AddUnicodeString (
 EFI_STATUS
 EFIAPI
 AddUnicodeString2 (
-  IN CONST CHAR8   *Language,
-  IN CONST CHAR8   *SupportedLanguages,
-  IN EFI_UNICODE_STRING_TABLE  **UnicodeStringTable,
-  IN CONST CHAR16  *UnicodeString,
-  IN BOOLEAN   Iso639Language
+  IN CONST CHAR8   *Language,
+  IN CONST CHAR8   *SupportedLanguages,
+  IN OUT EFI_UNICODE_STRING_TABLE  **UnicodeStringTable,
+  IN CONST CHAR16  *UnicodeString,
+  IN BOOLEAN   Iso639Language
   )
 {
   UINTN NumberOfEntries;
diff --git a/MdePkg/Include/Library/UefiLib.h b/MdePkg/Include/Library/UefiLib.h
index 54bc2cc5a334..256498e3fd8d 100644
--- a/MdePkg/Include/Library/UefiLib.h
+++ b/MdePkg/Include/Library/UefiLib.h
@@ -587,10 +587,10 @@ LookupUnicodeString2 (
 EFI_STATUS
 EFIAPI
 AddUnicodeString (
-  IN CONST CHAR8   *Language,
-  IN CONST CHAR8   *SupportedLanguages,
-  IN EFI_UNICODE_STRING_TABLE  **UnicodeStringTable,
-  IN CONST CHAR16  *UnicodeString
+  IN CONST CHAR8   *Language,
+  IN CONST CHAR8   *SupportedLanguages,
+  IN OUT EFI_UNICODE_STRING_TABLE  **UnicodeStringTable,
+  IN CONST CHAR16  *UnicodeString
   );
 
 /**
@@ -638,11 +638,11 @@ AddUnicodeString (
 EFI_STATUS
 EFIAPI
 AddUnicodeString2 (
-  IN CONST CHAR8   *Language,
-  IN CONST CHAR8   *SupportedLanguages,
-  IN EFI_UNICODE_STRING_TABLE  **UnicodeStringTable,
-  IN CONST CHAR16  *UnicodeString,
-  IN BOOLEAN   Iso639Language
+  IN CONST CHAR8   *Language,
+  IN CONST CHAR8   *SupportedLanguages,
+  IN OUT EFI_UNICODE_STRING_TABLE  **UnicodeStringTable,
+  IN CONST CHAR16  *UnicodeString,
+  IN BOOLEAN   Iso639Language
   );
 
 /**
-- 
2.17.0.windows.1

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

[edk2] [PATCH v2 2/2] IntelFrameworkPkg/FrameworkUefiLib: Add 'OUT' decorator where necessary.

[Marvin Häuser]

The functions AddUnicodeString() and AddUnicodeString2() might return
a new value into their parameter UnicodeStringTable, hence add the
appropiate 'OUT' decorator.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLib.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLib.c 
b/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLib.c
index 895ff39fc140..61a32e297606 100644
--- a/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLib.c
+++ b/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLib.c
@@ -865,11 +865,10 @@ LookupUnicodeString2 (
 **/
 EFI_STATUS
 EFIAPI
-AddUnicodeString (
-  IN CONST CHAR8   *Language,
-  IN CONST CHAR8   *SupportedLanguages,
-  IN EFI_UNICODE_STRING_TABLE  **UnicodeStringTable,
-  IN CONST CHAR16  *UnicodeString
+  IN CONST CHAR8   *Language,
+  IN CONST CHAR8   *SupportedLanguages,
+  IN OUT EFI_UNICODE_STRING_TABLE  **UnicodeStringTable,
+  IN CONST CHAR16  *UnicodeString
   )
 {
   UINTN NumberOfEntries;
@@ -1043,11 +1042,11 @@ AddUnicodeString (
 EFI_STATUS
 EFIAPI
 AddUnicodeString2 (
-  IN CONST CHAR8   *Language,
-  IN CONST CHAR8   *SupportedLanguages,
-  IN EFI_UNICODE_STRING_TABLE  **UnicodeStringTable,
-  IN CONST CHAR16  *UnicodeString,
-  IN BOOLEAN   Iso639Language
+  IN CONST CHAR8   *Language,
+  IN CONST CHAR8   *SupportedLanguages,
+  IN OUT EFI_UNICODE_STRING_TABLE  **UnicodeStringTable,
+  IN CONST CHAR16  *UnicodeString,
+  IN BOOLEAN   Iso639Language
   )
 {
   UINTN NumberOfEntries;
-- 
2.17.0.windows.1

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

[edk2] FW: [PATCH] UefiCpuPkg/SecMain: Add NORETURN decorator to SecStartup().

[Marvin Häuser]

Hey Eric and Laszlo,

If I am not mistaken, this patch has neither been reviewed by Eric, nor was it 
pushed.
Just forwarding it in case it was forgotten about.

Thank you very much!

Best regards,
Marvin.

> -Ursprüngliche Nachricht-
> Von: Laszlo Ersek <ler...@redhat.com>
> Gesendet: Dienstag, 27. Februar 2018 18:41
> An: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-
> de...@lists.01.org
> Cc: eric.d...@intel.com
> Betreff: Re: [PATCH] UefiCpuPkg/SecMain: Add NORETURN decorator to
> SecStartup().
> 
> On 02/27/18 17:50, Marvin Häuser wrote:
> > The function SecStartup() is not supposed to return. Hence, add the
> > NORETURN decorator.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Marvin Haeuser <marvin.haeu...@outlook.com>
> > ---
> >  UefiCpuPkg/SecCore/SecMain.c | 6 ++
> UefiCpuPkg/SecCore/SecMain.h
> > | 1 +
> >  2 files changed, 7 insertions(+)
> >
> > diff --git a/UefiCpuPkg/SecCore/SecMain.c
> > b/UefiCpuPkg/SecCore/SecMain.c index c241d3704af7..6f9db0584ce1
> 100644
> > --- a/UefiCpuPkg/SecCore/SecMain.c
> > +++ b/UefiCpuPkg/SecCore/SecMain.c
> > @@ -113,6 +113,7 @@ SecPerformancePpiCallBack (
> >@param BootFirmwareVolume  Base address of the Boot Firmware
> Volume.
> >  **/
> >  VOID
> > +NORETURN
> >  EFIAPI
> >  SecStartup (
> >IN UINT32   SizeOfRam,
> > @@ -201,6 +202,11 @@ SecStartup (
> >// Initialize Debug Agent to support source level debug in SEC/PEI phases
> before memory ready.
> >//
> >InitializeDebugAgent (DEBUG_AGENT_INIT_PREMEM_SEC,
> ,
> > SecStartupPhase2);
> > +
> > +  //
> > +  // Should not come here.
> > +  //
> > +  UNREACHABLE ();
> >  }
> >
> >  /**
> > diff --git a/UefiCpuPkg/SecCore/SecMain.h
> > b/UefiCpuPkg/SecCore/SecMain.h index 46c7d41c6e3e..42a5718cfdd5
> 100644
> > --- a/UefiCpuPkg/SecCore/SecMain.h
> > +++ b/UefiCpuPkg/SecCore/SecMain.h
> > @@ -76,6 +76,7 @@ SecTemporaryRamDone (
> >@param BootFirmwareVolume  Base address of the Boot Firmware
> Volume.
> >  **/
> >  VOID
> > +NORETURN
> >  EFIAPI
> >  SecStartup (
> >IN UINT32   SizeOfRam,
> >
> 
> I checked the NORETURN and UNREACHABLE() macros in
> "MdePkg/Include/Base.h", and also the InitializeDebugAgent() API. I think
> the patch is correct.
> 
> Reviewed-by: Laszlo Ersek <ler...@redhat.com>
> 
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] TianoCore UEFI Development Kit build: how to cause the build process to correctly recognize the build platform (Linux)?

[Marvin Häuser]

Hey,

As you have found out, Nt32Pkg is for Windows and shouldn't be built on Linux.
You can specify the platform descriptor file to build via the "-p " 
parameter.

Regards,
Marvin.

> -Ursprüngliche Nachricht-
> Von: edk2-devel  Im Auftrag von Aleksey
> Shevandin
> Gesendet: Sonntag, 15. April 2018 17:23
> An: edk2-devel@lists.01.org
> Betreff: [edk2] TianoCore UEFI Development Kit build: how to cause the
> build process to correctly recognize the build platform (Linux)?
> 
> Dear members,
> 
> I'm trying to build *UDK2018* on *Ubuntu 17*. After studying the
> documentation, I had impressed that the platform setup script
> (*sedksetup.sh*) shall configure the build framework to target the correct
> build platform, the tool chain etc. Unfortunately this is not what actually
> happens.
> 
> The platform build process (the Build base tool) unexpectedly tries to build
> some *MS Windows* oriented stuff and fails. How this can be fixed?
> 
> Following the documented recommendations, at the first stage I build the
> "Base Tools":
> 
> |/make all -C ${EDK_TOOLS_PATH}/|
> 
> Then I run the setup script:
> 
> |/edksetup.sh BaseTools/|
> 
> This stages are finished with success, also the setup script runs some tests
> that successfully pass.
> 
> On the next stage I'm trying to build the platform:
> 
> |build all -a X64 -t GCC5|
> 
> This last stage fails with the follow error:
> 
> Nt32Pkg/Include/WinNtPeim.h:27:10: fatal error: Common/WinNtInclude.h:
> No such file or directory
> 
> 
> Regards,
> 
> Aleksey
> 
> ___
> 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 1/5] MdePkg/SPI: Change function definitions to match their descriptions.

[Marvin Häuser]

Hey Dandan,

Thanks for your reply.
I issued updates for the current headers because I saw activity in 
edk2-platforms to implement these incomplete protocols and because I haven't 
heard back for discussed changes in the specification for some time.
Sure I could help submitting the ECR, however I'm not sure how. I'm not an UEFI 
Contributor and neither did I find any design flaws, just typos and missing 
definitions, which obviously must be bit values due to their non-exclusive 
nature.
If you need me to do something concrete, I will try to do my best.

Regards,
Marvin.

> -Original Message-
> From: Bi, Dandan <dandan...@intel.com>
> Sent: Monday, March 5, 2018 3:15 AM
> To: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-
> de...@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Gao, Liming
> <liming@intel.com>; Bi, Dandan <dandan...@intel.com>
> Subject: RE: [PATCH 1/5] MdePkg/SPI: Change function definitions to match
> their descriptions.
> 
> Hi Marvin,
> 
> Thank you very much for your contribution. Could you hold this patch series?
> Since current SPI header files follow PI1.6 spec.
> For this case, we should submit an ECR to update the PI spec firstly. After 
> the
> ECR has been approved by PIWG, then we can send patch to update them.
> Since you have found a lot of missing/incorrect parts in the SPI part of PI
> Spec. Could you help to submit an ECR to update them?
> 
> 
> Thanks,
> Dandan
> 
> -----Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Marvin Häuser
> Sent: Wednesday, February 28, 2018 12:49 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Gao, Liming
> <liming@intel.com>
> Subject: [edk2] [PATCH 1/5] MdePkg/SPI: Change function definitions to
> match their descriptions.
> 
> The PI specification is not continuous with function headers and descriptions
> for the SPI protocols. Correct and comment these mistakes.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marvin Haeuser <marvin.haeu...@outlook.com>
> ---
>  MdePkg/Include/Protocol/SpiConfiguration.h | 12 
>  MdePkg/Include/Protocol/SpiHc.h| 14 +-
>  MdePkg/Include/Protocol/SpiIo.h| 15 ++-
>  3 files changed, 27 insertions(+), 14 deletions(-)
> 
> diff --git a/MdePkg/Include/Protocol/SpiConfiguration.h
> b/MdePkg/Include/Protocol/SpiConfiguration.h
> index c0df183ec7f0..c36a809f4232 100644
> --- a/MdePkg/Include/Protocol/SpiConfiguration.h
> +++ b/MdePkg/Include/Protocol/SpiConfiguration.h
> @@ -1,7 +1,7 @@
>  /** @file
>This file defines the SPI Configuration Protocol.
> 
> -  Copyright (c) 2017, Intel Corporation. All rights reserved.
> +  Copyright (c) 2017 - 2018, Intel Corporation. All rights
> + reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
>License which accompanies this distribution. The full text of the license 
> may
> @@ -65,6 +65,10 @@ EFI_STATUS
>IN BOOLEAN   PinValue
>);
> 
> +//
> +// Note: In the PI specification, ClockHz is decorated as only 'IN', which is
> +//   not conforming to the parameter description.
> +//
>  /**
>Set up the clock generator to produce the correct clock frequency, phase
> and
>polarity for a SPI chip.
> @@ -78,7 +82,7 @@ EFI_STATUS
>  ClockPhase and ClockPolarity fields. The routine
>  also has access to the names for the SPI bus and
>  chip which can be used during debugging.
> -  @param[in] ClockHzPointer to the requested clock frequency. The
> clock
> +  @param[in,out] ClockHzPointer to the requested clock frequency. The
> clock
>  generator will choose a supported clock frequency
>  which is less then or equal to this value.
>  Specify zero to turn the clock generator off.
> @@ -92,8 +96,8 @@ EFI_STATUS
>  **/
>  typedef EFI_STATUS
>  (EFIAPI *EFI_SPI_CLOCK) (
> -  IN CONST EFI_SPI_PERIPHERAL  *SpiPeripheral,
> -  IN UINT32*ClockHz
> +  IN CONST EFI_SPI_PERIPHERAL  *SpiPeripheral,
> +  IN OUT UINT32*ClockHz
>);
> 
>  ///
> diff --git a/MdePkg/Include/Protocol/SpiHc.h
> b/MdePkg/Include/Protocol/SpiHc.h index 12fe5d2dce0a..71c75431e4e8
> 100644
> --- a/MdePkg/Include/Protocol/SpiHc.h
> +++ b/MdePkg/Include/Protocol/SpiHc.h
> @@ -1,7 +1,7 @@
>  /** @file
>This file defin

Re: [edk2] [PATCH 2/2] MdeModulePkg/BaseSerialPortLib16550: Prevent truncating constant values.

[Marvin Häuser]

The Base.h changes making BIT definitions unsigned have been denied.
Is a V2 needed for this patch? I verified again that casting the result of the 
inversion triggers the warning, except when casted before doing so, at least by 
VS2017.

Thanks,
Marvin.

> -Original Message-
> From: Zeng, Star <star.z...@intel.com>
> Sent: Wednesday, February 28, 2018 3:44 AM
> To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Laszlo Ersek <ler...@redhat.com>;
> Dong, Eric <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: RE: [edk2] [PATCH 2/2] MdeModulePkg/BaseSerialPortLib16550:
> Prevent truncating constant values.
> 
> Could simply use 0xFFFC for this case?
> 
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Marvin H?user
> Sent: Wednesday, February 28, 2018 2:56 AM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Laszlo Ersek <ler...@redhat.com>;
> Dong, Eric <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: Re: [edk2] [PATCH 2/2] MdeModulePkg/BaseSerialPortLib16550:
> Prevent truncating constant values.
> 
> Hey Laszlo,
> 
> Thanks for your... detailed explanation. :) I actually submitted another patch
> to prevent what you explained - "[edk2] [PATCH 1/2] MdePkg/Base.h:
> Ensure safe bitwise operations.", which marks all BIT defines (and more) as
> unsigned.
> Most definitely I should have mentioned it in the commit message or held it
> back till that patch will be accepted (or denied?), seems like I forgot about
> that.
> Would you still prefer your suggestion even when the Base.h patch is
> merged? After all, int might happen to be even larger than INT32, if I'm not
> mistaken.
> 
> I'm quite sure VS2015x86 issued the warning despite that commit being
> applied locally. It seems to always warn when a constant is truncated,
> explicitely or implicitely, to give you the change to increase its size:
> https://msdn.microsoft.com/en-us/library/sz5z1byt.aspx
> 
> Thanks again for your comprehensive review!
> 
> Best regards,
> Marvin.
> 
> > -Original Message-
> > From: Laszlo Ersek <ler...@redhat.com>
> > Sent: Tuesday, February 27, 2018 7:35 PM
> > To: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-
> > de...@lists.01.org
> > Cc: ruiyu...@intel.com; eric.d...@intel.com; star.z...@intel.com
> > Subject: Re: [edk2] [PATCH 2/2] MdeModulePkg/BaseSerialPortLib16550:
> > Prevent truncating constant values.
> >
> > Hi Marvin,
> >
> > On 02/27/18 17:49, Marvin Häuser wrote:
> > > The toolcahin VS2015x86 issues warnings when truncating constant
> > > values. Explicitely cast such to avoid it.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Marvin Haeuser <marvin.haeu...@outlook.com>
> > > ---
> > >
> > > MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.c
> > > | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git
> > >
> >
> a/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.c
> > >
> >
> b/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.c
> > > index 0ccac96f419c..10eca6c0a7aa 100644
> > > ---
> > >
> >
> a/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.c
> > > +++
> > b/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib165
> > > +++ 50.c
> > > @@ -366,7 +366,7 @@ GetSerialRegisterBase (
> > >//
> > >if (DeviceInfo->PowerManagementStatusAndControlRegister != 0x00) {
> > >  if ((PciRead16 (PciLibAddress + DeviceInfo-
> > >PowerManagementStatusAndControlRegister) & (BIT0 | BIT1)) != 0x00) {
> > > -  PciAnd16 (PciLibAddress + DeviceInfo-
> > >PowerManagementStatusAndControlRegister, (UINT16)~(BIT0 | BIT1));
> > > +  PciAnd16 (PciLibAddress +
> > > + DeviceInfo->PowerManagementStatusAndControlRegister,
> > > + (UINT16)~(UINT16)(BIT0 | BIT1));
> > >//
> > >// If PCI UART was not in D0, then make sure FIFOs are
> > > enabled, but do
> > not reset FIFOs
> > >//
> > > @@ -402,7 +402,7 @@ GetSerialRegisterBase (
> > >  //
> > >  if (DeviceInfo->PowerManagementStatusAndControlRegister != 0x00)
> {
> > >if ((PciRead16 (PciLibAddress + DeviceInfo-
> > &g

Re: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure safe bitwise operations.

[Marvin Häuser]

Hey Mike,

Thanks for your reply.
Under these circumstances I will not submit a V2. I hope you find a decent set 
of tests to be performed.

Regards,
Marvin.

> -Original Message-
> From: Kinney, Michael D <michael.d.kin...@intel.com>
> Sent: Thursday, March 1, 2018 6:19 PM
> To: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-
> de...@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
> Cc: ler...@redhat.com; Gao, Liming <liming@intel.com>
> Subject: RE: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure safe bitwise
> operations.
> 
> Marvin,
> 
> Thanks.  I agree that there may be some compiler behavior assumptions.
> 
> I would prefer we add to Base.h tests for the expected behavior
> assumptions and break the build if the compiler does not adhere to those
> assumptions.  We have already added these to verify the size of base types
> and the size of enums.
> 
> /**
>   Verifies the storage size of a given data type.
> 
>   This macro generates a divide by zero error or a zero size array 
> declaration in
>   the preprocessor if the size is incorrect.  These are declared as "extern" 
> so
>   the space for these arrays will not be in the modules.
> 
>   @param  TYPE  The date type to determine the size of.
>   @param  Size  The expected size for the TYPE.
> 
> **/
> #define VERIFY_SIZE_OF(TYPE, Size) extern UINT8
> _VerifySizeof##TYPE[(sizeof(TYPE) == (Size)) / (sizeof(TYPE) == (Size))]
> 
> //
> // Verify that ProcessorBind.h produced UEFI Data Types that are compliant
> with // Section 2.3.1 of the UEFI 2.3 Specification.
> //
> VERIFY_SIZE_OF (BOOLEAN, 1);
> VERIFY_SIZE_OF (INT8, 1);
> VERIFY_SIZE_OF (UINT8, 1);
> VERIFY_SIZE_OF (INT16, 2);
> VERIFY_SIZE_OF (UINT16, 2);
> VERIFY_SIZE_OF (INT32, 4);
> VERIFY_SIZE_OF (UINT32, 4);
> VERIFY_SIZE_OF (INT64, 8);
> VERIFY_SIZE_OF (UINT64, 8);
> VERIFY_SIZE_OF (CHAR8, 1);
> VERIFY_SIZE_OF (CHAR16, 2);
> 
> //
> // The following three enum types are used to verify that the compiler //
> configuration for enum types is compliant with Section 2.3.1 of the // UEFI 
> 2.3
> Specification. These enum types and enum values are not // intended to be
> used. A prefix of '__' is used avoid conflicts with // other types.
> //
> typedef enum {
>   __VerifyUint8EnumValue = 0xff
> } __VERIFY_UINT8_ENUM_SIZE;
> 
> typedef enum {
>   __VerifyUint16EnumValue = 0x
> } __VERIFY_UINT16_ENUM_SIZE;
> 
> typedef enum {
>   __VerifyUint32EnumValue = 0x
> } __VERIFY_UINT32_ENUM_SIZE;
> 
> VERIFY_SIZE_OF (__VERIFY_UINT8_ENUM_SIZE, 4); VERIFY_SIZE_OF
> (__VERIFY_UINT16_ENUM_SIZE, 4); VERIFY_SIZE_OF
> (__VERIFY_UINT32_ENUM_SIZE, 4);
> 
> 
> Mike
> 
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-
> > boun...@lists.01.org] On Behalf Of Marvin Häuser
> > Sent: Thursday, March 1, 2018 3:11 AM
> > To: edk2-devel@lists.01.org; Kinney, Michael D
> > <michael.d.kin...@intel.com>
> > Cc: ler...@redhat.com; Gao, Liming
> > <liming@intel.com>
> > Subject: Re: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure safe bitwise
> > operations.
> >
> >
> > > -Original Message-
> > > From: Kinney, Michael D <michael.d.kin...@intel.com>
> > > Sent: Thursday, March 1, 2018 2:42 AM
> > > To: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-
> > > de...@lists.01.org; Kinney, Michael D
> > <michael.d.kin...@intel.com>
> > > Cc: ler...@redhat.com; Gao, Liming
> > <liming@intel.com>
> > > Subject: RE: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure
> > safe bitwise
> > > operations.
> > >
> > > Hi Marvin,
> > >
> > > Yes.  I have been reading the thread.
> > >
> > > Lots of really good analysis.
> > >
> > > However, it does not make sense to me to add 'u' to
> > the smaller BITxx,
> > > BASExx, and SIZExx macros if we have constants in
> > other places that do not
> > > add the 'u'. I think this patch may increase the
> > inconsistency of the whole
> > > tree.
> >
> > Basically applying this to the BIT definitions first was to see
> > whether the concept is percepted as a whole.
> > Of course this should be applied to all definitions that are at some
> > point used as a mask, which I continued to do locally.
> >
> > >
> > > If we don’t make this change, what types of issues do
> > we need to fix and
> > > what would the fix entail?
> >
> > To be honest, actual issues are very unlikely to happen as all
&

Re: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure safe bitwise operations.

[Marvin Häuser]

> -Original Message-
> From: Laszlo Ersek <ler...@redhat.com>
> Sent: Thursday, March 1, 2018 11:40 AM
> To: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-
> de...@lists.01.org
> Cc: michael.d.kin...@intel.com; liming@intel.com
> Subject: Re: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure safe bitwise
> operations.
> 
> On 02/28/18 22:07, Marvin Häuser wrote:
> > One comment is inline.
> >
> > Thank you in advance,
> > Marvin.
> >
> >> -Original Message-
> >> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of
> >> Marvin Häuser
> >> Sent: Wednesday, February 28, 2018 7:46 PM
> >> To: edk2-devel@lists.01.org; Laszlo Ersek <ler...@redhat.com>
> >> Cc: michael.d.kin...@intel.com; liming@intel.com
> >> Subject: Re: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure safe bitwise
> >> operations.
> >>
> >> I have just locally updated all BIT defines to use the ULL prefix and
> >> added casts to defines using them.
> >> I did that to ensure that 1) inversions always produce the correct
> >> value and 2) assignments never result in implicit casts to a smaller
> >> int, which would raise a warning.
> >>
> >> After I was done doing it for MdePkg, a build showed that (N)ASM
> >> files consumed these definitions.
> >>
> >> I only see a bunch of possible solutions to that:
> >> * Prohibit the usage of such defines in assembly code (which I would
> >> strongly dislike).
> >> * Introduce a "DEFINE_BIT" macro which produces one definition for C
> >> code and one for assembly.
> >
> > I only just realized that including C headers was not a NASM feature, but it
> is actually edk2 invoking the PP.
> > Might the best solution just be to introduce a casting macro, which casts
> when it's invoked for a C compiler and doesn't when it's invoked for an
> assembler?
> > Basically would require nothing else than adding a "-
> D__EDK2_ASSEMBLER__" or something alike to the PP flags when applicable.
> >
> > Any opinion on that?
> 
> Sigh, I don't know what to answer. On one hand (if we can get it to work
> without regressions) I like the idea of making all BITx macros ULL. On the
> other hand, defining the same macro with different replacement text,
> dependent on whether the including source code is assembly or C, looks
> dirty. I can't really put my finger on it, but I feel such dual definitions 
> could
> cause issues or confusion. If BaseTools people are OK with the dual
> definition, I guess I could live with it.

Indeed it is dirty, however I don't think there is any choice but the smallest 
devil.
Leaving them signed might become dangerous, relying on suffixes is not a proper 
solution considering the new 128-bit type and casting results in the sharing 
issue between C and NASM.
Actually I would abandon the "two definitions" concept as of the idea of 
introducing __EDK2_ASSEMBLER__.

The solution I think would be the best to ensure a safe and forward-compatible 
is:
1) Cast all generic defines that might be used as masks to the highest 
available integer type (macro), including BITx.
2) Introduce a casting macro which would roughly look like this and apply it to 
all "named bit" definitions:

#ifdef __EDK2_ASSEMLER__
  #define PP_CAST(Value, Type) (Value)
#else
  #define PP_CAST(Value, Type) ((Type)(Value))
#endif

This way:
* Bit operations on all types of unsigned integers are safe and well-defined.
* One can intuitively use inverses for both generic and "named" masks.
* One can continue to intuitively assign "named bits" to variables of their 
type (except for when integer promotion happens as part of an OP, of course, 
but this is unrelated).
* Code not casting correctly will raise compile-time errors.

The only alternative worth arguing I see is scrapping it all and introducing 
Unit Tests. However, should a Unit Test ever fail a specific compiler, we would 
be back here again.

Regards,
Marvin.

> 
> Thanks,
> Laszlo
> 
> >
> >> * Rely on 'ULL' always producing the biggest possible value
> >> (including the 128- bit range new to the spec) or documenting an
> >> exception for it, and insist on the caller casting (which I would find 
> >> quite
> ugly).
> >> * Scrap the patch and continue to rely on
> >> compiler-/architecture-specific behavior, which could cause issues
> seemingly randomly.
> >>
> >> Thanks,
> >> Marvin.
> >>
> >>> -Original Message-
> >>> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of
> >&g

Re: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure safe bitwise operations.

[Marvin Häuser]

> -Original Message-
> From: Kinney, Michael D <michael.d.kin...@intel.com>
> Sent: Thursday, March 1, 2018 2:42 AM
> To: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-
> de...@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
> Cc: ler...@redhat.com; Gao, Liming <liming@intel.com>
> Subject: RE: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure safe bitwise
> operations.
> 
> Hi Marvin,
> 
> Yes.  I have been reading the thread.
> 
> Lots of really good analysis.
> 
> However, it does not make sense to me to add 'u' to the smaller BITxx,
> BASExx, and SIZExx macros if we have constants in other places that do not
> add the 'u'. I think this patch may increase the inconsistency of the whole
> tree.

Basically applying this to the BIT definitions first was to see whether the 
concept is percepted as a whole.
Of course this should be applied to all definitions that are at some point used 
as a mask, which I continued to do locally.

> 
> If we don’t make this change, what types of issues do we need to fix and
> what would the fix entail?

To be honest, actual issues are very unlikely to happen as all architectures 
supported by the specification use two-complements for negative values.
Furthermore, all currently supported compilers implement bitwise operations for 
signed integers seemingly the same way as for unsigned types.
However, if either will change in the future, code will silently break as in 
many mask operations will return values not intended by the code.

If you are not interested in the solution concepts previously discussed, I 
propose as least a Unit Test to verify the operations used in praxis work out 
fine.

Thanks,
Marvin.

> 
> Mike
> 
> > -Original Message-
> > From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> > Sent: Wednesday, February 28, 2018 10:52 AM
> > To: edk2-devel@lists.01.org; Kinney, Michael D
> > <michael.d.kin...@intel.com>
> > Cc: ler...@redhat.com; Gao, Liming
> > <liming@intel.com>
> > Subject: RE: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure safe bitwise
> > operations.
> >
> > Hey Mike,
> >
> > You are right, the patch was premature because I did not consider any
> > 'incorrect' or 'clever' usages of these definitions.
> > The problem is not primarily undefined behavior, but
> > implementation-defined behavior.
> > Any bitwise operation to a signed integer results in
> > implementation-defined behavior, which compilers usually do not warn
> > about, while well-defined behavior is desirable.
> >
> > Have you read Laszlo's comments? They are quite good at showing up
> > what logics might be and are relied on, which however are not
> > guaranteed to be the case for
> > non-x86 architectures,
> > or even for x86 in case a development team decides to change this
> > behavior some day or a new toolchain not having adopted them in the
> > first place should be added.
> >
> > Furthermore, I don't think inconsistency between the definitions
> > generally is desirable.
> >
> > Thanks,
> > Marvin.
> >
> > > -Original Message-
> > > From: Kinney, Michael D <michael.d.kin...@intel.com>
> > > Sent: Wednesday, February 28, 2018 7:37 PM
> > > To: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-
> > > de...@lists.01.org; Laszlo Ersek <ler...@redhat.com>;
> > Kinney, Michael D
> > > <michael.d.kin...@intel.com>
> > > Cc: Gao, Liming <liming@intel.com>
> > > Subject: RE: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure
> > safe bitwise
> > > operations.
> > >
> > > Hi Marvin,
> > >
> > > I do not think add 'u' to the BITxx defines does not
> > seem to be a complete
> > > solution.  Code can use integer constants in lots of
> > places including other
> > > #defines or inline in expressions.
> > >
> > > If we follow your suggestion wouldn’t we need to add
> > 'u' to every constant
> > > that does not start with a '-'
> > > and might potentially be used with a bit operation?
> > >
> > > Compilers are doing a good job of finding undefined
> > behavior.  Isn’t that
> > > sufficient to fix the issues identified?
> > >
> > > Mike
> > >
> > > > -Original Message-
> > > > From: Marvin Häuser
> > [mailto:marvin.haeu...@outlook.com]
> > > > Sent: Wednesday, February 28, 2018 6:21 AM
> > > > To: edk2-devel@lists.01.org; Laszlo Ersek
> > <ler...@redhat.com>
> > > > Cc: K

Re: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure safe bitwise operations.

[Marvin Häuser]

One comment is inline.

Thank you in advance,
Marvin.

> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Marvin
> Häuser
> Sent: Wednesday, February 28, 2018 7:46 PM
> To: edk2-devel@lists.01.org; Laszlo Ersek <ler...@redhat.com>
> Cc: michael.d.kin...@intel.com; liming@intel.com
> Subject: Re: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure safe bitwise
> operations.
> 
> I have just locally updated all BIT defines to use the ULL prefix and added
> casts to defines using them.
> I did that to ensure that 1) inversions always produce the correct value and 
> 2)
> assignments never result in implicit casts to a smaller int, which would 
> raise a
> warning.
> 
> After I was done doing it for MdePkg, a build showed that (N)ASM files
> consumed these definitions.
> 
> I only see a bunch of possible solutions to that:
> * Prohibit the usage of such defines in assembly code (which I would strongly
> dislike).
> * Introduce a "DEFINE_BIT" macro which produces one definition for C code
> and one for assembly.

I only just realized that including C headers was not a NASM feature, but it is 
actually edk2 invoking the PP.
Might the best solution just be to introduce a casting macro, which casts when 
it's invoked for a C compiler and doesn't when it's invoked for an assembler?
Basically would require nothing else than adding a "-D__EDK2_ASSEMBLER__" or 
something alike to the PP flags when applicable.

Any opinion on that?

> * Rely on 'ULL' always producing the biggest possible value (including the 
> 128-
> bit range new to the spec) or documenting an exception for it, and insist on
> the caller casting (which I would find quite ugly).
> * Scrap the patch and continue to rely on compiler-/architecture-specific
> behavior, which could cause issues seemingly randomly.
> 
> Thanks,
> Marvin.
> 
> > -Original Message-
> > From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Marvin
> > Häuser
> > Sent: Wednesday, February 28, 2018 3:21 PM
> > To: edk2-devel@lists.01.org; Laszlo Ersek <ler...@redhat.com>
> > Cc: michael.d.kin...@intel.com; liming@intel.com
> > Subject: Re: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure safe bitwise
> > operations.
> >
> > Hey Laszlo,
> >
> > I cut your rant because it is not strictly related to this patch.
> > However, thank you for composing it nevertheless because it was an
> interesting read!
> > Comments are inline.
> >
> > Michael, Liming,
> > Do you have any comments regarding the discussion? Thanks in advance.
> >
> > Best regards,
> > Marvin.
> >
> > > -Original Message-
> > > From: Laszlo Ersek <ler...@redhat.com>
> > > Sent: Wednesday, February 28, 2018 2:57 PM
> > > To: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-
> > > de...@lists.01.org
> > > Cc: michael.d.kin...@intel.com; liming@intel.com
> > > Subject: Re: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure safe bitwise
> > > operations.
> > >
> > > On 02/28/18 12:43, Marvin Häuser wrote:
> > [...]
> > > > as edk2 does not support vendor extensions such as __int128 anyway.
> > >
> > > Not *yet*, I guess :) UEFI 2.7 does list UINT128 / INT128, in table
> > > 5, "Common UEFI Data Types". I believe those typedefs may have been
> > added for RISC-V.
> >
> > Oh yikes, I have not noticed that before. Besides that I wonder how
> > that will be implemented by edk2 for non-RISC-V platforms, maybe that
> > should be considered?
> > As ridiculous as it sounds, maybe some kind of UINT_MAX type (now
> > UINT64, later UINT128) should be introduced and any BIT or bitmask
> > definition being explicitly casted to that?
> > Are BIT definitions or masks occasionally used in preprocessor operations?
> > That might break after all.
> > Anyway, if that idea would be approved, there really would have to be
> > a note regarding this design in some of the EDK2 specifications,
> > probably C Code Style.
> >
> > [...]
> > >
> > > > -1) The 'truncating constant value' warning would probably need to
> > > > be disabled globally, however I don't understand how an explicit
> > > > cast is a problem anyway.
> > > >
> > > > Did I overlook anything contra regarding that?
> > >
> > > Hmmm... Do you think it could have a performance impact on 32-bit
> > > platforms? (I don't think so, at least not in optimized / RELEASE
> > > builds.)
> >
> > I don't think a

Re: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure safe bitwise operations.

[Marvin Häuser]

Hey Mike,

You are right, the patch was premature because I did not consider any 
'incorrect' or 'clever' usages of these definitions.
The problem is not primarily undefined behavior, but implementation-defined 
behavior.
Any bitwise operation to a signed integer results in implementation-defined 
behavior, which compilers usually do not warn about, while well-defined 
behavior is desirable.

Have you read Laszlo's comments? They are quite good at showing up what logics 
might be and are relied on, which however are not guaranteed to be the case for 
non-x86 architectures,
or even for x86 in case a development team decides to change this behavior some 
day or a new toolchain not having adopted them in the first place should be 
added.

Furthermore, I don't think inconsistency between the definitions generally is 
desirable.

Thanks,
Marvin.

> -Original Message-
> From: Kinney, Michael D <michael.d.kin...@intel.com>
> Sent: Wednesday, February 28, 2018 7:37 PM
> To: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-
> de...@lists.01.org; Laszlo Ersek <ler...@redhat.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>
> Cc: Gao, Liming <liming@intel.com>
> Subject: RE: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure safe bitwise
> operations.
> 
> Hi Marvin,
> 
> I do not think add 'u' to the BITxx defines does not seem to be a complete
> solution.  Code can use integer constants in lots of places including other
> #defines or inline in expressions.
> 
> If we follow your suggestion wouldn’t we need to add 'u' to every constant
> that does not start with a '-'
> and might potentially be used with a bit operation?
> 
> Compilers are doing a good job of finding undefined behavior.  Isn’t that
> sufficient to fix the issues identified?
> 
> Mike
> 
> > -Original Message-
> > From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> > Sent: Wednesday, February 28, 2018 6:21 AM
> > To: edk2-devel@lists.01.org; Laszlo Ersek <ler...@redhat.com>
> > Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Gao, Liming
> > <liming@intel.com>
> > Subject: RE: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure safe bitwise
> > operations.
> >
> > Hey Laszlo,
> >
> > I cut your rant because it is not strictly related to this patch.
> > However, thank you for composing it nevertheless because it was an
> > interesting read!
> > Comments are inline.
> >
> > Michael, Liming,
> > Do you have any comments regarding the discussion?
> > Thanks in advance.
> >
> > Best regards,
> > Marvin.
> >
> > > -Original Message-
> > > From: Laszlo Ersek <ler...@redhat.com>
> > > Sent: Wednesday, February 28, 2018 2:57 PM
> > > To: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-
> > > de...@lists.01.org
> > > Cc: michael.d.kin...@intel.com; liming@intel.com
> > > Subject: Re: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure
> > safe bitwise
> > > operations.
> > >
> > > On 02/28/18 12:43, Marvin Häuser wrote:
> > [...]
> > > > as edk2 does not support vendor extensions such as
> > __int128 anyway.
> > >
> > > Not *yet*, I guess :) UEFI 2.7 does list UINT128 /
> > INT128, in table 5, "Common
> > > UEFI Data Types". I believe those typedefs may have
> > been added for RISC-V.
> >
> > Oh yikes, I have not noticed that before. Besides that I wonder how
> > that will be implemented by edk2 for non- RISC-V platforms, maybe that
> > should be considered?
> > As ridiculous as it sounds, maybe some kind of UINT_MAX type (now
> > UINT64, later UINT128) should be introduced and any BIT or bitmask
> > definition being explicitly casted to that?
> > Are BIT definitions or masks occasionally used in preprocessor
> > operations? That might break after all.
> > Anyway, if that idea would be approved, there really would have to be
> > a note regarding this design in some of the EDK2 specifications,
> > probably C Code Style.
> >
> > [...]
> > >
> > > > -1) The 'truncating constant value' warning would
> > probably need to be
> > > > disabled globally, however I don't understand how
> > an explicit cast is
> > > > a problem anyway.
> > > >
> > > > Did I overlook anything contra regarding that?
> > >
> > > Hmmm... Do you think it could have a performance
> > impact on 32-bit
> > > platforms? (I don't think so, at least not in
> > optimized / RELEASE
> > > builds.)
> >
> > I don't think any proper optimizer would not optimize this. After all,
> > it can not only evaluate the value directly and notice that the value
> > does not reach into the 'long long range', but also consider the type
> > of the other operand.
> >
> > [...]

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

Re: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure safe bitwise operations.

[Marvin Häuser]

I have just locally updated all BIT defines to use the ULL prefix and added 
casts to defines using them.
I did that to ensure that 1) inversions always produce the correct value and 2) 
assignments never result in implicit casts to a smaller int, which would raise 
a warning.

After I was done doing it for MdePkg, a build showed that (N)ASM files consumed 
these definitions.

I only see a bunch of possible solutions to that:
* Prohibit the usage of such defines in assembly code (which I would strongly 
dislike).
* Introduce a "DEFINE_BIT" macro which produces one definition for C code and 
one for assembly.
* Rely on 'ULL' always producing the biggest possible value (including the 
128-bit range new to the spec) or documenting an exception for it, and insist 
on the caller casting (which I would find quite ugly).
* Scrap the patch and continue to rely on compiler-/architecture-specific 
behavior, which could cause issues seemingly randomly.

Thanks,
Marvin.

> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Marvin
> Häuser
> Sent: Wednesday, February 28, 2018 3:21 PM
> To: edk2-devel@lists.01.org; Laszlo Ersek <ler...@redhat.com>
> Cc: michael.d.kin...@intel.com; liming@intel.com
> Subject: Re: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure safe bitwise
> operations.
> 
> Hey Laszlo,
> 
> I cut your rant because it is not strictly related to this patch. However, 
> thank
> you for composing it nevertheless because it was an interesting read!
> Comments are inline.
> 
> Michael, Liming,
> Do you have any comments regarding the discussion? Thanks in advance.
> 
> Best regards,
> Marvin.
> 
> > -Original Message-
> > From: Laszlo Ersek <ler...@redhat.com>
> > Sent: Wednesday, February 28, 2018 2:57 PM
> > To: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-
> > de...@lists.01.org
> > Cc: michael.d.kin...@intel.com; liming@intel.com
> > Subject: Re: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure safe bitwise
> > operations.
> >
> > On 02/28/18 12:43, Marvin Häuser wrote:
> [...]
> > > as edk2 does not support vendor extensions such as __int128 anyway.
> >
> > Not *yet*, I guess :) UEFI 2.7 does list UINT128 / INT128, in table 5,
> > "Common UEFI Data Types". I believe those typedefs may have been
> added for RISC-V.
> 
> Oh yikes, I have not noticed that before. Besides that I wonder how that will
> be implemented by edk2 for non-RISC-V platforms, maybe that should be
> considered?
> As ridiculous as it sounds, maybe some kind of UINT_MAX type (now
> UINT64, later UINT128) should be introduced and any BIT or bitmask
> definition being explicitly casted to that?
> Are BIT definitions or masks occasionally used in preprocessor operations?
> That might break after all.
> Anyway, if that idea would be approved, there really would have to be a
> note regarding this design in some of the EDK2 specifications, probably C
> Code Style.
> 
> [...]
> >
> > > -1) The 'truncating constant value' warning would probably need to
> > > be disabled globally, however I don't understand how an explicit
> > > cast is a problem anyway.
> > >
> > > Did I overlook anything contra regarding that?
> >
> > Hmmm... Do you think it could have a performance impact on 32-bit
> > platforms? (I don't think so, at least not in optimized / RELEASE
> > builds.)
> 
> I don't think any proper optimizer would not optimize this. After all, it can 
> not
> only evaluate the value directly and notice that the value does not reach into
> the 'long long range', but also consider the type of the other operand.
> 
> [...]
> 
> ___
> 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 1/2] MdePkg/Base.h: Ensure safe bitwise operations.

[Marvin Häuser]

Hey Laszlo,

I cut your rant because it is not strictly related to this patch. However, 
thank you for composing it nevertheless because it was an interesting read!
Comments are inline.

Michael, Liming,
Do you have any comments regarding the discussion? Thanks in advance.

Best regards,
Marvin.

> -Original Message-
> From: Laszlo Ersek <ler...@redhat.com>
> Sent: Wednesday, February 28, 2018 2:57 PM
> To: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-
> de...@lists.01.org
> Cc: michael.d.kin...@intel.com; liming@intel.com
> Subject: Re: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure safe bitwise
> operations.
> 
> On 02/28/18 12:43, Marvin Häuser wrote:
[...]
> > as edk2 does not support vendor extensions such as __int128 anyway.
> 
> Not *yet*, I guess :) UEFI 2.7 does list UINT128 / INT128, in table 5, "Common
> UEFI Data Types". I believe those typedefs may have been added for RISC-V.

Oh yikes, I have not noticed that before. Besides that I wonder how that will 
be implemented by edk2 for non-RISC-V platforms, maybe that should be 
considered?
As ridiculous as it sounds, maybe some kind of UINT_MAX type (now UINT64, later 
UINT128) should be introduced and any BIT or bitmask definition being 
explicitly casted to that?
Are BIT definitions or masks occasionally used in preprocessor operations? That 
might break after all.
Anyway, if that idea would be approved, there really would have to be a note 
regarding this design in some of the EDK2 specifications, probably C Code Style.

[...]
> 
> > -1) The 'truncating constant value' warning would probably need to be
> > disabled globally, however I don't understand how an explicit cast is
> > a problem anyway.
> >
> > Did I overlook anything contra regarding that?
> 
> Hmmm... Do you think it could have a performance impact on 32-bit
> platforms? (I don't think so, at least not in optimized / RELEASE
> builds.)

I don't think any proper optimizer would not optimize this. After all, it can 
not only evaluate the value directly and notice that the value does not reach 
into the 'long long range', but also consider the type of the other operand.

[...]

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

Re: [edk2] [PATCH 1/2] MdeModulePkg/PciBusDxe: Prevent truncating constant values.

[Marvin Häuser]

> -Original Message-
> From: Laszlo Ersek <ler...@redhat.com>
> Sent: Wednesday, February 28, 2018 12:42 PM
> To: Andrew Fish <af...@apple.com>
> Cc: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-
> de...@lists.01.org; ruiyu...@intel.com; eric.d...@intel.com;
> star.z...@intel.com
> Subject: Re: [edk2] [PATCH 1/2] MdeModulePkg/PciBusDxe: Prevent
> truncating constant values.
> 
> On 02/27/18 19:50, Andrew Fish wrote:
> >
> >
> >> On Feb 27, 2018, at 10:42 AM, Laszlo Ersek <ler...@redhat.com> wrote:
> >>
> >> On 02/27/18 17:49, Marvin Häuser wrote:
> >>> The toolcahin VS2015x86 issues warnings when truncating constant
> >>> values. Explicitely cast such to avoid it.
> >>>
> >>> Contributed-under: TianoCore Contribution Agreement 1.1
> >>> Signed-off-by: Marvin Haeuser <marvin.haeu...@outlook.com>
> >>> ---
> >>> MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c | 4 ++--
> >>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
> >>> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
> >>> index 2f713fcee95e..a752853f3e9e 100644
> >>> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
> >>> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
> >>> @@ -1936,7 +1936,7 @@ ProgramP2C (
> >>>
> >>>);
> >>>
> >>> -  BridgeControl &= (UINT16)
> ~PCI_CARD_PREFETCHABLE_MEMORY_0_ENABLE;
> >>> +  BridgeControl &= (UINT16)
> >>> + ~(UINT16)PCI_CARD_PREFETCHABLE_MEMORY_0_ENABLE;
> >>>   PciIo->Pci.Write (
> >>>PciIo,
> >>>EfiPciIoWidthUint16, @@ -2005,7 +2005,7 @@
> >>> ProgramP2C (
> >>>
> >>>);
> >>>
> >>> -  BridgeControl &= (UINT16)
> ~(PCI_CARD_PREFETCHABLE_MEMORY_1_ENABLE);
> >>> +  BridgeControl &= (UINT16)
> >>> + ~(UINT16)(PCI_CARD_PREFETCHABLE_MEMORY_1_ENABLE);
> >>>   PciIo->Pci.Write (
> >>>PciIo,
> >>>EfiPciIoWidthUint16,
> >>>
> >>
> >> My recommendation is the same as for:
> >>
> >>  [edk2] [PATCH 2/2] MdeModulePkg/BaseSerialPortLib16550: Prevent
> >> truncating constant values.
> >>
> >> #define PCI_CARD_PREFETCHABLE_MEMORY_0_ENABLE BIT8 #define
> >> PCI_CARD_PREFETCHABLE_MEMORY_1_ENABLE BIT9
> >>
> >> #define  BIT8 0x0100
> >> #define  BIT9 0x0200
> >>
> >
> > Laszlo,
> >
> > Stupid question? Would making BIT8 0x0100U help? I notice we use
> ULL for the larger ones, and I don't remember why we don't use U for the
> ones that fit into a int?
> 
> I don't know why BIT[0..31] don't use the U suffix from the beginning. I agree
> they should have. Adding the suffixes now is the right thing in theory,
> although some "clever" applications of those macros could regress as a
> result.
> 
> Regarding the question whether this patch would be obviated by making
> BIT[0..31] unsigned, Marvin explained elsewhere that just making BIT[0..31]
> unsigned didn't help with suppressing the warning. As I commented under
> Marvin's explanation, I understand neither why the compiler warns about
> the current code (with or without making BIT[0..31] unsigned), nor --
> assuming the original warning is somehow justifiable
> -- why the warning is apparently silenced by inserting a UINT16 cast ahead of
> the bit-neg. As far as I could see, if the warning applied to the original 
> code, it
> should have applied to the patched code too.

Please check my new reply to the Base.h patch. Once we find a decent concept 
for a v2, I will undo these patches locally and try to find out what MSVC's 
problem is more carefully.
Either way, I agree that the warning, in this context, doesn't make any sense. 
If I did not happen to make any mistake or the warning plainly persists after 
v2, maybe MS should be contacted.

Best regards,
Marvin.

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

Re: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure safe bitwise operations.

[Marvin Häuser]

Thanks. Comments are inline.

Best regards,
Marvin.

> -Original Message-
> From: Laszlo Ersek <ler...@redhat.com>
> Sent: Wednesday, February 28, 2018 12:00 PM
> To: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-
> de...@lists.01.org
> Cc: michael.d.kin...@intel.com; liming@intel.com
> Subject: Re: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure safe bitwise
> operations.
> 
> On 02/27/18 21:31, Marvin Häuser wrote:
> >> -Original Message-
> >> From: Laszlo Ersek <ler...@redhat.com>
> >> Sent: Tuesday, February 27, 2018 8:54 PM
> >> To: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-
> >> de...@lists.01.org
> >> Cc: michael.d.kin...@intel.com; liming@intel.com
> >> Subject: Re: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensure safe bitwise
> >> operations.
> >>
[...]
> 
> This is exactly how I feel, yes. My concern is that making the change now
> runs the risk of tricky regressions that we might not even prevent with a
> detailed audit.

Actually, your explanations and the rest of the bit defines made me wonder, 
whether marking all BIT defines and bit masks of any kind, anywhere, as ULL, 
might be the best solution.
+1) Inversion can be used for any integer size uncasted, as edk2 does not 
support vendor extensions such as __int128 anyway.
+2) Binary operations (AND, OR, ...) should not raise any problems at all 
(except for our fellow using VS2005x86 :) )
+3) Assignments and passing-by-arguments will result in compiler-time errors 
when not done properly in the sense of this patch, which eliminates the need to 
audit all usages manually, but just compile the entire codebase and fix the 
errors one-by-one (which is of course still not a quick task, but if the 
package authors agree with the proposal, I might attempt it).
-1) The 'truncating constant value' warning would probably need to be disabled 
globally, however I don't understand how an explicit cast is a problem anyway.

Did I overlook anything contra regarding that?

> 
> Anyway, I don't want to spread FUD about this -- I think the goal of these
> changes is good. It's up to the MdePkg maintainers to evaluate the risks, I
> just wanted us to be aware of them. Once we reach an end state where all
> the BIT, SIZE and BASE macros are unsigned, and no regressions are found (or
> none remain), that's for the best!

Nah, your comments are great, thanks!

[...]
> I think I agree with your assessment, considering the usual application of
> these macros in source code. I distinguish three kinds of uses:
> 
[...]
> 
> (3) The clever code: is aware that BIT macros are (mostly) signed, and
> exploits that fact for various ends.
> 
> I agree that most of the edk2 codebase should fall under (1).
> 
> As you may expect, I personally write (2), and code like (2) should not worry
> about BIT / SIZE / BASE becoming unsigned.
> 
> My concern is (3). There have been examples in core edk2 modules that
> explicitly relied on undefined behavior, such as left shifts of negative 
> integers
> and such. We've only slowly fixed them up after compilers / analyzers started
> flagging them.
> 
> If we don't think (3) is a real risk, I'm fine with the approach of these 
> patches.
> (I don't think I'll be able to send a real R-b for them, because that would
> require me to evaluate all uses, and that's a Herculean task I just can't take
> on; apologies.)

I hope that the 'all ULL' proposal uncovers them all. Would there be cases, 
where no error would be raised?

[...]
> 
> >>> -#define ENCODE_ERROR(StatusCode) ((RETURN_STATUS)(MAX_BIT |
> >> (StatusCode)))
> >>> +#define ENCODE_ERROR(StatusCode) ((RETURN_STATUS)(MAX_BIT
> |
> >> (StatusCode##ULL)))
> >>>
> >>
> >> MAX_BIT always has type UINTN (UINT64 aka "unsigned long long" on
> >> 64-bit platforms, and UINT32 aka "unsigned int" on 32-bit platforms).
> >> This means that ENCODE_ERROR results in a UINTN, right now.
> >
> > Good point, I didn't keep that in mind. It probably should be solely
> > 'U'.
> 
> In fact there's no need even for that: because MAX_BIT has type UINTN
> ("unsigned long long" or "unsigned int"), the StatusCode macro argument,
> which is expected to be a small nonnegative "int", will be converted to
> UINTN, for the bitwise OR operator.

Oh, right, thanks. I would still prefer it to be explicit, but I'll wait for a 
maintainer's comment.

[...]
> 
> What is implementation-defined in the current definition of
> ENCODE_ERROR()?

That was a result of the misunderstanding above, scrap that.

> 
> Given the current definition, if StatusCode is a s