date:20151007

Re: [edk2] [PATCH v3] Pkg-Module: Integrate new RngLib into RngDxe

2015-10-07 Thread Long, Qin

Thomas,

Thanks for doing this.
I think it's better to separate your patch into two parts (one for MdePkg, and 
the other for SecurityPkg). Then you can CC me as Jordan's suggestion.


Best Regards & Thanks,
LONG, Qin

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jordan Justen
> Sent: Thursday, October 08, 2015 11:36 AM
> To: Thomas Palmer; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH v3] Pkg-Module: Integrate new RngLib into
> RngDxe
> 
> In the subject line, 'Pkg-Module' should be something like 'MdePkg:'
> or 'SecurityPkg/RandomNumberGenerator:'.
> 
> On 2015-10-07 18:55:42, Thomas Palmer wrote:
> > Use the new RngLib to provide the IA32/X64 random data for RngDxe.
> > Remove x86 specific functions from RdRand files.
> > Clean up files in RngDxe/IA32 and RngDxe/X64 that are subsumed by files
> in BaseRngLib.
> > Simplify RngDxe by using WriteUnaligned64 for both IA32 and X64
> platforms.
> > Create and use GetRandomNumber128 in RngDxe to leverage 128 bit
> > support found in some HW RNG devices
> 
> It sounds like you are doing about 5 things here. How about 5 patches?
> 
> Each patch should only touch one package whenever possiable.
> 
> Also, consider adding 'Cc:' near your Signed-off-by for the maintainers of a
> package. (see Maintainers.txt)
> 
> -Jordan
> 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Thomas Palmer 
> > ---
> >  MdePkg/Include/Library/RngLib.h|   17 ++
> >  MdePkg/Library/BaseRngLib/BaseRng.c|   32 +++
> >  .../RngDxe/IA32/AsmRdRand.asm  |   67 -
> >  .../RandomNumberGenerator/RngDxe/IA32/GccRdRand.c  |   69 --
> >  .../RandomNumberGenerator/RngDxe/IA32/RdRandWord.c |  104 
> > SecurityPkg/RandomNumberGenerator/RngDxe/RdRand.c  |  256
> > ++--
> SecurityPkg/RandomNumberGenerator/RngDxe/RdRand.h  |  151 +---
> >  SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.c  |9 +-
> >  .../RandomNumberGenerator/RngDxe/RngDxe.inf|   14 +-
> >  .../RandomNumberGenerator/RngDxe/X64/AsmRdRand.asm |   83 ---
> >  .../RandomNumberGenerator/RngDxe/X64/GccRdRand.c   |   95 
> >  .../RandomNumberGenerator/RngDxe/X64/RdRandWord.c  |   70 --
> >  SecurityPkg/SecurityPkg.dsc|3 +
> >  13 files changed, 75 insertions(+), 895 deletions(-)  delete mode
> > 100644
> SecurityPkg/RandomNumberGenerator/RngDxe/IA32/AsmRdRand.asm
> >  delete mode 100644
> > SecurityPkg/RandomNumberGenerator/RngDxe/IA32/GccRdRand.c
> >  delete mode 100644
> > SecurityPkg/RandomNumberGenerator/RngDxe/IA32/RdRandWord.c
> >  delete mode 100644
> > SecurityPkg/RandomNumberGenerator/RngDxe/X64/AsmRdRand.asm
> >  delete mode 100644
> > SecurityPkg/RandomNumberGenerator/RngDxe/X64/GccRdRand.c
> >  delete mode 100644
> > SecurityPkg/RandomNumberGenerator/RngDxe/X64/RdRandWord.c
> >
> > diff --git a/MdePkg/Include/Library/RngLib.h
> > b/MdePkg/Include/Library/RngLib.h index 157a931..ece4394 100644
> > --- a/MdePkg/Include/Library/RngLib.h
> > +++ b/MdePkg/Include/Library/RngLib.h
> > @@ -66,4 +66,21 @@ GetRandomNumber64 (
> >OUT UINT64*Rand
> >);
> >
> > +/**
> > +  Generates a 128-bit random number.
> > +
> > +  if Rand is NULL, then ASSERT().
> > +
> > +  @param[out] Rand Buffer pointer to store the 128-bit random value.
> > +
> > +  @retval TRUE Random number generated successfully.
> > +  @retval FALSEFailed to generate the random number.
> > +
> > +**/
> > +BOOLEAN
> > +EFIAPI
> > +GetRandomNumber128 (
> > +  OUT UINT64*Rand
> > +  );
> > +
> >  #endif  // __RNG_LIB_H__
> > diff --git a/MdePkg/Library/BaseRngLib/BaseRng.c
> > b/MdePkg/Library/BaseRngLib/BaseRng.c
> > index 279df30..2c8df56 100644
> > --- a/MdePkg/Library/BaseRngLib/BaseRng.c
> > +++ b/MdePkg/Library/BaseRngLib/BaseRng.c
> > @@ -155,3 +155,35 @@ GetRandomNumber64 (
> >
> >return FALSE;
> >  }
> > +
> > +/**
> > +  Generates a 128-bit random number.
> > +
> > +  if Rand is NULL, then ASSERT().
> > +
> > +  @param[out] Rand Buffer pointer to store the 128-bit random value.
> > +
> > +  @retval TRUE Random number generated successfully.
> > +  @retval FALSEFailed to generate the random number.
> > +
> > +**/
> > +BOOLEAN
> > +EFIAPI
> > +GetRandomNumber128 (
> > +  OUT UINT64*Rand
> > +  )
> > +{
> > +  ASSERT (Rand != NULL);
> > +
> > +  //
> > +  // Read first 64 bits
> > +  //
> > +  if (!GetRandomNumber64 (Rand)) {
> > +return FALSE;
> > +  }
> > +
> > +  //
> > +  // Read second 64 bits
> > +  //
> > +  return GetRandomNumber64 (++Rand);
> > +}
> > diff --git
> > a/SecurityPkg/RandomNumberGenerator/RngDxe/IA32/AsmRdRand.asm
> > b/SecurityPkg/RandomNumberGenerator/RngDxe/IA32/AsmRdRand.asm
> > deleted file mode 100644
> > index 37b3830..000
> > ---
> a/SecurityPkg/RandomNumberGenerator/RngDxe/

Re: [edk2] [PATCH v3] Pkg-Module: Integrate new RngLib into RngDxe

2015-10-07 Thread Jordan Justen

In the subject line, 'Pkg-Module' should be something like 'MdePkg:'
or 'SecurityPkg/RandomNumberGenerator:'.

On 2015-10-07 18:55:42, Thomas Palmer wrote:
> Use the new RngLib to provide the IA32/X64 random data for RngDxe.
> Remove x86 specific functions from RdRand files.
> Clean up files in RngDxe/IA32 and RngDxe/X64 that are subsumed by files in 
> BaseRngLib.
> Simplify RngDxe by using WriteUnaligned64 for both IA32 and X64 platforms.
> Create and use GetRandomNumber128 in RngDxe to leverage 128 bit support found 
> in some HW RNG devices

It sounds like you are doing about 5 things here. How about 5 patches?

Each patch should only touch one package whenever possiable.

Also, consider adding 'Cc:' near your Signed-off-by for the
maintainers of a package. (see Maintainers.txt)

-Jordan

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Thomas Palmer 
> ---
>  MdePkg/Include/Library/RngLib.h|   17 ++
>  MdePkg/Library/BaseRngLib/BaseRng.c|   32 +++
>  .../RngDxe/IA32/AsmRdRand.asm  |   67 -
>  .../RandomNumberGenerator/RngDxe/IA32/GccRdRand.c  |   69 --
>  .../RandomNumberGenerator/RngDxe/IA32/RdRandWord.c |  104 
>  SecurityPkg/RandomNumberGenerator/RngDxe/RdRand.c  |  256 
> ++--
>  SecurityPkg/RandomNumberGenerator/RngDxe/RdRand.h  |  151 +---
>  SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.c  |9 +-
>  .../RandomNumberGenerator/RngDxe/RngDxe.inf|   14 +-
>  .../RandomNumberGenerator/RngDxe/X64/AsmRdRand.asm |   83 ---
>  .../RandomNumberGenerator/RngDxe/X64/GccRdRand.c   |   95 
>  .../RandomNumberGenerator/RngDxe/X64/RdRandWord.c  |   70 --
>  SecurityPkg/SecurityPkg.dsc|3 +
>  13 files changed, 75 insertions(+), 895 deletions(-)
>  delete mode 100644 
> SecurityPkg/RandomNumberGenerator/RngDxe/IA32/AsmRdRand.asm
>  delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/IA32/GccRdRand.c
>  delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/IA32/RdRandWord.c
>  delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/X64/AsmRdRand.asm
>  delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/X64/GccRdRand.c
>  delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/X64/RdRandWord.c
> 
> diff --git a/MdePkg/Include/Library/RngLib.h b/MdePkg/Include/Library/RngLib.h
> index 157a931..ece4394 100644
> --- a/MdePkg/Include/Library/RngLib.h
> +++ b/MdePkg/Include/Library/RngLib.h
> @@ -66,4 +66,21 @@ GetRandomNumber64 (
>OUT UINT64*Rand
>);
>  
> +/**
> +  Generates a 128-bit random number.
> +
> +  if Rand is NULL, then ASSERT().
> +
> +  @param[out] Rand Buffer pointer to store the 128-bit random value.
> +
> +  @retval TRUE Random number generated successfully.
> +  @retval FALSEFailed to generate the random number.
> +
> +**/
> +BOOLEAN
> +EFIAPI
> +GetRandomNumber128 (
> +  OUT UINT64*Rand
> +  );
> +
>  #endif  // __RNG_LIB_H__
> diff --git a/MdePkg/Library/BaseRngLib/BaseRng.c 
> b/MdePkg/Library/BaseRngLib/BaseRng.c
> index 279df30..2c8df56 100644
> --- a/MdePkg/Library/BaseRngLib/BaseRng.c
> +++ b/MdePkg/Library/BaseRngLib/BaseRng.c
> @@ -155,3 +155,35 @@ GetRandomNumber64 (
>  
>return FALSE;
>  }
> +
> +/**
> +  Generates a 128-bit random number.
> +
> +  if Rand is NULL, then ASSERT().
> +
> +  @param[out] Rand Buffer pointer to store the 128-bit random value.
> +
> +  @retval TRUE Random number generated successfully.
> +  @retval FALSEFailed to generate the random number.
> +
> +**/
> +BOOLEAN
> +EFIAPI
> +GetRandomNumber128 (
> +  OUT UINT64*Rand
> +  )
> +{
> +  ASSERT (Rand != NULL);
> +
> +  //
> +  // Read first 64 bits
> +  //
> +  if (!GetRandomNumber64 (Rand)) {
> +return FALSE;
> +  }
> +
> +  //
> +  // Read second 64 bits
> +  //
> +  return GetRandomNumber64 (++Rand);
> +}
> diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/IA32/AsmRdRand.asm 
> b/SecurityPkg/RandomNumberGenerator/RngDxe/IA32/AsmRdRand.asm
> deleted file mode 100644
> index 37b3830..000
> --- a/SecurityPkg/RandomNumberGenerator/RngDxe/IA32/AsmRdRand.asm
> +++ /dev/null
> @@ -1,67 +0,0 @@
> -;--
> -;
> -; Copyright (c) 2013, 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.
> -;
> -; Module Name:
> -;
> -;   AsmRdRand.Asm
> -;
> -; Abstract:
> -;
> -;   Implementation for

Re: [edk2] [PATCH v3 4/5] MdeModulePkg/DxeIplPeim: implement non-exec stack for ARM/AARCH64

2015-10-07 Thread Tian, Feng

Looks good to me

Reviewed-by: Feng Tian 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
Biesheuvel
Sent: Tuesday, October 06, 2015 20:48
To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; ler...@redhat.com; Tian, 
Feng
Cc: heyi@linaro.org; Ard Biesheuvel
Subject: [edk2] [PATCH v3 4/5] MdeModulePkg/DxeIplPeim: implement non-exec 
stack for ARM/AARCH64

Mark the DXE stack region as non-executable right before handing off to the DXE 
core, by invoking the appropriate ArmLib function.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 
---
 MdeModulePkg/Core/DxeIplPeim/Arm/DxeLoadFunc.c | 7 +++
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf| 8 
 2 files changed, 15 insertions(+)

diff --git a/MdeModulePkg/Core/DxeIplPeim/Arm/DxeLoadFunc.c 
b/MdeModulePkg/Core/DxeIplPeim/Arm/DxeLoadFunc.c
index df2dc70b1732..d6581a312541 100644
--- a/MdeModulePkg/Core/DxeIplPeim/Arm/DxeLoadFunc.c
+++ b/MdeModulePkg/Core/DxeIplPeim/Arm/DxeLoadFunc.c
@@ -16,6 +16,8 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 #include "DxeIpl.h"
 
+#include 
+
 /**
Transfers control to DxeCore.
 
@@ -43,6 +45,11 @@ HandOffToDxeCore (
   BaseOfStack = AllocatePages (EFI_SIZE_TO_PAGES (STACK_SIZE));
   ASSERT (BaseOfStack != NULL);
 
+  if (PcdGetBool (PcdSetNxForStack)) {
+Status = ArmSetMemoryRegionNoExec ((UINTN)BaseOfStack, STACK_SIZE);
+ASSERT_EFI_ERROR (Status);
+  }
+
   //
   // Compute the top of the stack we were allocated. Pre-allocate a UINTN
   // for safety.
diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf 
b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
index 66c58b1d0f07..04ad928c9f84 100644
--- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
+++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
@@ -61,6 +61,9 @@ [Packages]
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
 
+[Packages.ARM, Packages.AARCH64]
+  ArmPkg/ArmPkg.dec
+
 [LibraryClasses]
   PcdLib
   MemoryAllocationLib
@@ -76,6 +79,9 @@ [LibraryClasses]
   DebugAgentLib
   PeiServicesTablePointerLib
 
+[LibraryClasses.ARM, LibraryClasses.AARCH64]
+  ArmLib
+
 [Ppis]
   gEfiDxeIplPpiGuid ## PRODUCES
   gEfiPeiDecompressPpiGuid  ## PRODUCES
@@ -104,6 +110,8 @@ [FeaturePcd]
 
 [Pcd.IA32,Pcd.X64]
   gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable  ## 
SOMETIMES_CONSUMES
+
+[Pcd.IA32,Pcd.X64,Pcd.ARM,Pcd.AARCH64]
   gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack   ## 
SOMETIMES_CONSUMES
 
 [Depex]
--
1.9.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] Support for UBI volumes and UBIFS?

2015-10-07 Thread Tian, Feng

Hi, Brian

As far as I know, there is no changes on that.

Could you introduce further about your usage model? FAT32 for the first 
partition is not enough for boot?

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Welch, 
Brian J
Sent: Tuesday, October 06, 2015 23:46
To: edk2-devel@lists.01.org
Subject: [edk2] Support for UBI volumes and UBIFS?

Hi,

I searched the list and the most recent topic I found was 10-months-old and 
said that no support for UBI/UBIFS was available at that time.

http://sourceforge.net/p/edk2/mailman/message/33144044/
That thread is similar to what I'm wanting to do, which is to have a raw flash 
device for boot which ideally would contain an EFI partition and at least one 
additional partition for the device's root filesystem.

I'm wondering if support/availability has changed since then.

Brian

___
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/Scripts: Add PatchCheck.py script

2015-10-07 Thread Jordan Justen

This script can be used to check some expected rules for EDK II
patches. It only works on git formatted patches.

It checks both the commit message and the lines that are added in the
patch diff.

In the commit message it verifies line lengths, signature formats, and
the Contributed-under tag.

In the patch, it checks that line endings are CRLF for all files that
don't have a .sh extension. It verifies that no trailing whitespace is
present and that tab characters are not used.

Patch contributors should use this script prior to submitting their
patches. Package maintainers can also use it to verify incoming
patches.

It can also be run by specifying a git revision list, so actual patch
files are not always required.

For example, to checkout this last 5 patches in your git branch you
can run:

  python PatchCheck.py HEAD~5..

Or, a shortcut (like git log):

  python PatchCheck.py -5

The --oneline option works similar to git log --oneline.

The --silent option enables silent operation.

The script supports python 2.7 and python 3.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen 
Cc: Erik Bjorge 
Cc: Yonghong Zhu 
Cc: Liming Gao 
---
 BaseTools/Scripts/PatchCheck.py | 607 
 1 file changed, 607 insertions(+)
 create mode 100644 BaseTools/Scripts/PatchCheck.py

diff --git a/BaseTools/Scripts/PatchCheck.py b/BaseTools/Scripts/PatchCheck.py
new file mode 100644
index 000..340a997
--- /dev/null
+++ b/BaseTools/Scripts/PatchCheck.py
@@ -0,0 +1,607 @@
+## @file
+#  Check a patch for various format issues
+#
+#  Copyright (c) 2015, 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.
+#
+
+from __future__ import print_function
+
+VersionNumber = '0.1'
+__copyright__ = "Copyright (c) 2015, Intel Corporation  All rights reserved."
+
+import email
+import argparse
+import os
+import re
+import subprocess
+import sys
+
+class Verbose:
+SILENT, ONELINE, NORMAL = range(3)
+level = NORMAL
+
+class CommitMessageCheck:
+"""Checks the contents of a git commit message."""
+
+def __init__(self, subject, message):
+self.ok = True
+
+if subject is None and  message is None:
+self.error('Commit message is missing!')
+return
+
+self.subject = subject
+self.msg = message
+
+self.check_contributed_under()
+self.check_signed_off_by()
+self.check_misc_signatures()
+self.check_overall_format()
+self.report_message_result()
+
+url = 
'https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format'
+
+def report_message_result(self):
+if Verbose.level < Verbose.NORMAL:
+return
+if self.ok:
+# All checks passed
+return_code = 0
+print('The commit message format passed all checks.')
+else:
+return_code = 1
+if not self.ok:
+print(self.url)
+
+def error(self, *err):
+if self.ok and Verbose.level > Verbose.ONELINE:
+print('The commit message format is not valid:')
+self.ok = False
+if Verbose.level < Verbose.NORMAL:
+return
+count = 0
+for line in err:
+prefix = (' *', '  ')[count > 0]
+print(prefix, line)
+count += 1
+
+def check_contributed_under(self):
+cu_msg='Contributed-under: TianoCore Contribution Agreement 1.0'
+if self.msg.find(cu_msg) < 0:
+self.error('Missing Contributed-under! (Note: this must be ' +
+   'added by the code contributor!)')
+
+@staticmethod
+def make_signature_re(sig, re_input=False):
+if re_input:
+sub_re = sig
+else:
+sub_re = sig.replace('-', r'[-\s]+')
+re_str = (r'^(?P' + sub_re +
+  r')(\s*):(\s*)(?P\S.*?)(?:\s*)$')
+try:
+return re.compile(re_str, re.MULTILINE|re.IGNORECASE)
+except Exception:
+print("Tried to compile re:", re_str)
+raise
+
+sig_block_re = \
+re.compile(r'''^
+(?: (?P[^:]+) \s* : \s*
+(?P\S.*?) )
+|
+(?: \[ (?P[^:]+) \s* : \s*
+   (?P.+?) \s* \] )
+\s* $''',
+   re.VERBOSE | re.MULTILINE)
+
+def find_signatures(self, sig):
+if not sig.endswith('-by') and sig != 'Cc':
+sig += '-by'
+

[edk2] [PATCH v3] Pkg-Module: Integrate new RngLib into RngDxe

2015-10-07 Thread Thomas Palmer

Use the new RngLib to provide the IA32/X64 random data for RngDxe.
Remove x86 specific functions from RdRand files.
Clean up files in RngDxe/IA32 and RngDxe/X64 that are subsumed by files in 
BaseRngLib.
Simplify RngDxe by using WriteUnaligned64 for both IA32 and X64 platforms.
Create and use GetRandomNumber128 in RngDxe to leverage 128 bit support found 
in some HW RNG devices

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Palmer 
---
 MdePkg/Include/Library/RngLib.h|   17 ++
 MdePkg/Library/BaseRngLib/BaseRng.c|   32 +++
 .../RngDxe/IA32/AsmRdRand.asm  |   67 -
 .../RandomNumberGenerator/RngDxe/IA32/GccRdRand.c  |   69 --
 .../RandomNumberGenerator/RngDxe/IA32/RdRandWord.c |  104 
 SecurityPkg/RandomNumberGenerator/RngDxe/RdRand.c  |  256 ++--
 SecurityPkg/RandomNumberGenerator/RngDxe/RdRand.h  |  151 +---
 SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.c  |9 +-
 .../RandomNumberGenerator/RngDxe/RngDxe.inf|   14 +-
 .../RandomNumberGenerator/RngDxe/X64/AsmRdRand.asm |   83 ---
 .../RandomNumberGenerator/RngDxe/X64/GccRdRand.c   |   95 
 .../RandomNumberGenerator/RngDxe/X64/RdRandWord.c  |   70 --
 SecurityPkg/SecurityPkg.dsc|3 +
 13 files changed, 75 insertions(+), 895 deletions(-)
 delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/IA32/AsmRdRand.asm
 delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/IA32/GccRdRand.c
 delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/IA32/RdRandWord.c
 delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/X64/AsmRdRand.asm
 delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/X64/GccRdRand.c
 delete mode 100644 SecurityPkg/RandomNumberGenerator/RngDxe/X64/RdRandWord.c

diff --git a/MdePkg/Include/Library/RngLib.h b/MdePkg/Include/Library/RngLib.h
index 157a931..ece4394 100644
--- a/MdePkg/Include/Library/RngLib.h
+++ b/MdePkg/Include/Library/RngLib.h
@@ -66,4 +66,21 @@ GetRandomNumber64 (
   OUT UINT64*Rand
   );
 
+/**
+  Generates a 128-bit random number.
+
+  if Rand is NULL, then ASSERT().
+
+  @param[out] Rand Buffer pointer to store the 128-bit random value.
+
+  @retval TRUE Random number generated successfully.
+  @retval FALSEFailed to generate the random number.
+
+**/
+BOOLEAN
+EFIAPI
+GetRandomNumber128 (
+  OUT UINT64*Rand
+  );
+
 #endif  // __RNG_LIB_H__
diff --git a/MdePkg/Library/BaseRngLib/BaseRng.c 
b/MdePkg/Library/BaseRngLib/BaseRng.c
index 279df30..2c8df56 100644
--- a/MdePkg/Library/BaseRngLib/BaseRng.c
+++ b/MdePkg/Library/BaseRngLib/BaseRng.c
@@ -155,3 +155,35 @@ GetRandomNumber64 (
 
   return FALSE;
 }
+
+/**
+  Generates a 128-bit random number.
+
+  if Rand is NULL, then ASSERT().
+
+  @param[out] Rand Buffer pointer to store the 128-bit random value.
+
+  @retval TRUE Random number generated successfully.
+  @retval FALSEFailed to generate the random number.
+
+**/
+BOOLEAN
+EFIAPI
+GetRandomNumber128 (
+  OUT UINT64*Rand
+  )
+{
+  ASSERT (Rand != NULL);
+
+  //
+  // Read first 64 bits
+  //
+  if (!GetRandomNumber64 (Rand)) {
+return FALSE;
+  }
+
+  //
+  // Read second 64 bits
+  //
+  return GetRandomNumber64 (++Rand);
+}
diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/IA32/AsmRdRand.asm 
b/SecurityPkg/RandomNumberGenerator/RngDxe/IA32/AsmRdRand.asm
deleted file mode 100644
index 37b3830..000
--- a/SecurityPkg/RandomNumberGenerator/RngDxe/IA32/AsmRdRand.asm
+++ /dev/null
@@ -1,67 +0,0 @@
-;--
-;
-; Copyright (c) 2013, 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.
-;
-; Module Name:
-;
-;   AsmRdRand.Asm
-;
-; Abstract:
-;
-;   Implementation for 16-, and 32- invocations of RDRAND instruction under 
32bit platform.
-;
-; Notes:
-;
-;   Visual Studio coding practices do not use inline asm since multiple 
compilers and 
-;   architectures are supported assembler not recognizing rdrand instruction 
so using DB's.
-;
-;--
-
-.586P
-.model flat, C
-.code
- 
-;--
-;  Generate a 16 bit random number
-;  Return TRUE if Rand generated successfully, or FALSE if not
-;
-;  BOOLEAN EFIAPI RdRand16Step (UINT16 *Rand);   ECX
-;---

Re: [edk2] [PATCH 6/7] UefiCpiPkg: Add PiSmmCpuDxeSmm module

2015-10-07 Thread Kinney, Michael D

Hi Laszlo,

Thanks for the feedback!

Please let me know if I missed any of your questions.

Mike

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Laszlo Ersek
>Sent: Wednesday, October 07, 2015 10:32 AM
>To: Kinney, Michael D
>Cc: edk2-de...@ml01.01.org
>Subject: Re: [edk2] [PATCH 6/7] UefiCpiPkg: Add PiSmmCpuDxeSmm module
>
>On 10/05/15 01:57, Michael Kinney wrote:
>> Add module that initializes a CPU for the SMM envirnment and
>> installs the first level SMI handler.  This module along with the
>> SMM IPL and SMM Core provide the services required for
>> DXE_SMM_DRIVERS to register hardware and software SMI handlers.
>>
>> CPU specific features are abstracted through the SmmCpuFeaturesLib
>>
>> Platform specific features are abstracted through the
>> SmmCpuPlatformHookLib
>>
>> Several PCDs are added to enable/disable features and configure
>> settings for the PiSmmCpuDxeSmm module
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Michael Kinney 
>
>(I'm snipping the patch because it is extremely long.)
>
>I'm going through my "QuarkPort" patches, evaluating for each one if I
>should keep it, drop it, or adapt it.
>
>* [PATCH 27/58] OvmfPkg: import PCDs from
>  Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg
>  http://thread.gmane.org/gmane.comp.bios.edk2.devel/329/focus=350
>
>  Going through all the PCDs I had to import there, and checking if each
>  was present in this patch too, I found the following difference:
>
>  PcdCpuSmmUncacheCpuSyncData is absent from this patch. In my
>  "QuarkPort", the PCD is used by the InitializeMpServiceData() function
>  only, gating a call to SetCacheability(). And that call to
>  SetCacheability() is the *only* such call.
>
>  Now, this patch provides SetCacheability(), but no calls are made to
>  it, ever (in accordance with the fact that the PCD that would control
>  the call is also absent).
>
>  (1) Therefore I recommend to delete the SetCacheability() function
>  from this patch.

I agree.  I will remove that function.  I missed that function when I removed
PcdCpuSmmUncacheCpuSyncData.

>
>  (2) I have a question wrt. PcdCpuSmmEnableBspElection. In the Quark
>  package, the "IA32FamilyCpuBasePkg.dsc" file overrides the default
>  TRUE value (from the .dec) for this PCD, with FALSE.
>
>  The .dec default is similarly TRUE here. In my "QuarkPort" for
>  OVMF, I flipped the PCD to FALSE as well. Does that make sense?
>  Should I stick with that override, when rebasing the OVMF SMM
>  series on top of this series? I don't know why this PCD matters.
>  What are the benefits vs. drawbacks of dynamic BSP-for-SMI
>  election?

For OVMF you will likely not see any difference in behavior.  
This PCD allows a platform to provide PlatformSmmBspElection() 
in a  platform specific SmmCpuPlatformHookLib instance to 
decide which CPU gets elected to be the BSP in each SMI.

The SmmCpuPlatformHookLibNull always returns 
EFI_NOT_READY for that function, which makes the 
module behave the same as the PCD being set to FALSE.

The default is TRUE, so the platform lib is always called,
so a platform developer can implement the hook 
function and does not have to also change a PCD
setting for the hook function to be active.

A platform that wants to eliminate the call to the 
hook function all together can set the PCD to FALSE.

So for OVMF, I think it makes sense to set this PCD to
FALSE in the DSC file.

>
>* [PATCH 28/58] OvmfPkg: import three protocols from
>  Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg
>  http://thread.gmane.org/gmane.comp.bios.edk2.devel/329/focus=351
>
>  (3) This patch doesn't install gSmmCpuSyncProtocolGuid or
>  gSmmCpuSync2ProtocolGuid in PiCpuSmmEntry(), whereas Quark does.
>
>  I don't know what those protocols good for, but can you please
>  summarize why this patch doesn't need them?

I did not find any consumers of the Sync protocols, so I removed them.

>
>* [PATCH 32/58] OvmfPkg: QuarkPort: drop ACPI_CPU_DATA.APState
>  http://thread.gmane.org/gmane.comp.bios.edk2.devel/329/focus=362
>
>  (4) Patch 5/7 in this series introduces the ACPI_CPU_DATA structure.
>  That structure has a field APState. I think it should be dropped,
>  it is never used in 6/7.

I agree it is not used.  However, this structure is shared between modules
through a buffer address in a PCD, and I am concerned that there may be 
other modules that depend on this layout.  I will need to do more
investigation before I can consider removing it.

>
>* [PATCH 33/58] OvmfPkg: add skeleton QuarkPort/CpuS3DataDxe
>  http://thread.gmane.org/gmane.comp.bios.edk2.devel/329/focus=357
>
>  This patch in my SMM series (and a few later ones that relate to
>  CpuS3DataDxe) make me ask my most important question here.
>
>  The PiSmmCpuDxeSmm module in this series -- same as in Quark -- only
>  *consumes* PcdCpuS3DataAddress, to save the ACPI_CPU_DATA structure,
>  collecte

Re: [edk2] [PATCH 7/7] UefiCpuPkg: Add missing UefiCpuPkgTokenSpace include

2015-10-07 Thread Kinney, Michael D

Laszlo,

Good question.  

It is a good practice to have the .h file for each GUID.  The .h file contains 
the extern for the global variable associated with the GUID along with data 
structures associated with the GUID.

For PCD token space GUIDs, there is no data structure and the AutoGen.h file 
contains an extern to all token space GUIDs a module references, so the .h file 
for the token space GUID is not required.

The C name for a Token space GUID (i.e. gUefiCpuPkgTokenSpaceGuid) would be 
required in C code if the PcdLib PcdGetEx8 (),PcdGetEx16 (),PcdGetEx32 
(),PcdGetEx64 (),PcdGetExBool (),or PcdGetExPtr () APIs are used.  Most 
modules/libs do not use the 'Ex' versions of these, so it is very rare for a 
module to use the C name for a Token space GUID.

I will remove the UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h from the patch 
set.

Thanks,

Mike

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Wednesday, October 07, 2015 10:38 AM
To: Kinney, Michael D; edk2-de...@ml01.01.org
Subject: Re: [edk2] [PATCH 7/7] UefiCpuPkg: Add missing UefiCpuPkgTokenSpace 
include

On 10/05/15 01:57, Michael Kinney wrote:
> Add missing include files for the token space GUID for the UefiCpuPkg
> Add path to the token space include file to the UefiCpuPkg DEC file.

Is this usual? For example, gUefiOvmfPkgTokenSpaceGuid is also not
defined anywhere else than in the DEC file.

What could a programmer use UEFICPUPKG_TOKEN_SPACE_GUID /
gUefiCpuPkgTokenSpaceGuid for, in C source code?

... Only the following packages / header files seem to expose their
respective token space GUIDs in a similar way:

MdeModulePkg/Include/Guid/MdeModulePkgTokenSpace.h
MdePkg/Include/Guid/MdePkgTokenSpace.h
PcAtChipsetPkg/Include/Guid/PcAtChipsetTokenSpace.h
PerformancePkg/Include/Guid/PerformancePkgTokenSpace.h
SecurityPkg/Include/Guid/SecurityPkgTokenSpace.h
ShellPkg/Include/Guid/ShellPkgTokenSpace.h
Vlv2DeviceRefCodePkg/Include/Guid/Vlv2DeviceRefCodePkgTokenSpace.h

Thanks!
Laszlo

> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Michael Kinney 
> ---
>  UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h | 25 +
>  UefiCpuPkg/UefiCpuPkg.dec  |  1 +
>  2 files changed, 26 insertions(+)
>  create mode 100644 UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h
> 
> diff --git a/UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h 
> b/UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h
> new file mode 100644
> index 000..6c4e671
> --- /dev/null
> +++ b/UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h
> @@ -0,0 +1,25 @@
> +/** @file
> +GUID for UefiCpuPkg PCD Token Space
> +
> +Copyright (c) 2015, 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 _UEFICPUPKG_TOKEN_SPACE_GUID_H_
> +#define _UEFICPUPKG_TOKEN_SPACE_GUID_H_
> +
> +#define UEFICPUPKG_TOKEN_SPACE_GUID \
> +  { \
> +0xac05bf33, 0x995a, 0x4ed4, { 0xaa, 0xb8, 0xef, 0x7a, 0xe8, 0xf, 0x5c, 
> 0xb0 } \
> +  }
> +
> +extern EFI_GUID gUefiCpuPkgTokenSpaceGuid;
> +
> +#endif
> diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
> index e4b8030..e293390 100644
> --- a/UefiCpuPkg/UefiCpuPkg.dec
> +++ b/UefiCpuPkg/UefiCpuPkg.dec
> @@ -51,6 +51,7 @@
>SmmCpuFeaturesLib|Include/Library/SmmCpuFeaturesLib.h
>  
>  [Guids]
> +  ## Include/Guid/UefiCpuPkgTokenSpace.h
>gUefiCpuPkgTokenSpaceGuid  = { 0xac05bf33, 0x995a, 0x4ed4, { 0xaa, 
> 0xb8, 0xef, 0x7a, 0xe8, 0xf, 0x5c, 0xb0 }}
>  
>  [Protocols]
> 

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

[edk2] Driver Health Protocol, UI interaction and Intel DQ77MK vs. OVMF

2015-10-07 Thread Bruce Cran

I have a controller which implements the Driver Health Protocol. Under 
OVMF (built from latest edk2 master), when the controller isn't healthy 
I can go into the 'Device Manager' menu, click the 'Some drivers are not 
healthy' entry and on clicking the unhealthy controller it gets repaired.


I'm wondering if anyone knows if this is recent behavior or if a bug was 
fixed, since on my Intel DQ77MK system I have a similar menu, except 
labeled "TPV EFI Device Manager" - but when I click the "Some drivers 
are not healthy" item the screen just refreshes back to the same page 
and nothing happens.


I had also expected that if I selected a boot item that resides on the 
unhealthy controller, the repair operation would get invoked and upon it 
returning a healthy status the OS would boot. But that doesn't seem to 
be the case.


Can anyone tell me what I'm misunderstanding please?

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

Re: [edk2] Is it possible to 'resume' and event?

2015-10-07 Thread Andrew Fish


> On Sep 29, 2015, at 12:15 PM, Tomaz Fogaça  wrote:
> 
> Hello, everyone
> 
> Is it possible to have lengthy event code resume from where it left off
> when it was interrupted?
> 
> What I'm trying to do is have a very responsive graphical application (with
> mouse pointer and the like), that can trigger some very slow functions that
> run in the "background", in the form of events. Being slow functions, they
> will naturally be interrupted by routines that need to repaint the screen,
> so I would like them to resume where they left off once they get the
> control again.
> 
> I've found this in the edk2 documentation, pertaining to the TPL_NOTIFY
> event priority level:
> 
> "If code requires more processing" - mine does - ", it needs to signal an
> event to wait to obtain control again at whatever level it requires. This
> level is typically used to process low level IO to or from a device"
> 
> but I'm really not sure how that would work, or if it even means what I
> want. But if the main 'thread' is interrupted and resumes from where it
> left off, shouldn't it be possible to do the same with other events?
> 

It is not possible as there is no scheduling in EFI. The main thread is always 
running, and it only gets interrupted by events. Only higher priority events 
interrupt lower priority events. 

It is the responsibility of the event to not take too much time. 

You will need to chop up the work in the event, or make the main code process 
an event loop. 


https://web.stanford.edu/~ouster/cgi-bin/papers/threads.pdf 



Thanks,

Andrew Fish



> 
> Thank you,
> Tomaz Vieira
> ___
> 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 5/7] UefiCpuPkg: Add PiSmmCpuDxeSmm module includes

2015-10-07 Thread Laszlo Ersek

On 10/05/15 01:57, Michael Kinney wrote:
> Add SmmCpuFeaturesLib that provides CPU specific functions that are
> used to initialize SMM and process SMIs.  A functional implementation
> of this library class is provided that is based on the
> Intel(R) 64 and IA-32 Architectures Software Developer's Manual
> 
> Add SmmCpuPlatformHookLib that provides platform specific functions
> that are used to initialize SMM and process SMIs.  A Null instance
> of this library is provided that should work for most platforms.
> 
> Add defintion of the SMM CPU Service Protocol that is produced by
> the PiSmmCpuDxeSmm module.
> 
> Add SmramSaveStateMap.h file that defines the 32-bit and 64-bit CPU
> SMRAM Save State Map.
> 
> Add AcpuCpuData.h that defines a data structure that is shared between
> modules and is required for ACPI S3 support.
> 
> Add CpuHotPlugData.h that defines a data structure that is shared between
> modules and is required for to support hot plug CPUs.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Michael Kinney 
> ---

[snip]

I think this patch should be split up into six patches, one per
paragraph in the commit message. (If that's possible.)

No other comments for now.

Thanks!
Laszlo

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

Re: [edk2] [PATCH 7/7] UefiCpuPkg: Add missing UefiCpuPkgTokenSpace include

2015-10-07 Thread Laszlo Ersek

On 10/05/15 01:57, Michael Kinney wrote:
> Add missing include files for the token space GUID for the UefiCpuPkg
> Add path to the token space include file to the UefiCpuPkg DEC file.

Is this usual? For example, gUefiOvmfPkgTokenSpaceGuid is also not
defined anywhere else than in the DEC file.

What could a programmer use UEFICPUPKG_TOKEN_SPACE_GUID /
gUefiCpuPkgTokenSpaceGuid for, in C source code?

... Only the following packages / header files seem to expose their
respective token space GUIDs in a similar way:

MdeModulePkg/Include/Guid/MdeModulePkgTokenSpace.h
MdePkg/Include/Guid/MdePkgTokenSpace.h
PcAtChipsetPkg/Include/Guid/PcAtChipsetTokenSpace.h
PerformancePkg/Include/Guid/PerformancePkgTokenSpace.h
SecurityPkg/Include/Guid/SecurityPkgTokenSpace.h
ShellPkg/Include/Guid/ShellPkgTokenSpace.h
Vlv2DeviceRefCodePkg/Include/Guid/Vlv2DeviceRefCodePkgTokenSpace.h

Thanks!
Laszlo

> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Michael Kinney 
> ---
>  UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h | 25 +
>  UefiCpuPkg/UefiCpuPkg.dec  |  1 +
>  2 files changed, 26 insertions(+)
>  create mode 100644 UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h
> 
> diff --git a/UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h 
> b/UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h
> new file mode 100644
> index 000..6c4e671
> --- /dev/null
> +++ b/UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h
> @@ -0,0 +1,25 @@
> +/** @file
> +GUID for UefiCpuPkg PCD Token Space
> +
> +Copyright (c) 2015, 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 _UEFICPUPKG_TOKEN_SPACE_GUID_H_
> +#define _UEFICPUPKG_TOKEN_SPACE_GUID_H_
> +
> +#define UEFICPUPKG_TOKEN_SPACE_GUID \
> +  { \
> +0xac05bf33, 0x995a, 0x4ed4, { 0xaa, 0xb8, 0xef, 0x7a, 0xe8, 0xf, 0x5c, 
> 0xb0 } \
> +  }
> +
> +extern EFI_GUID gUefiCpuPkgTokenSpaceGuid;
> +
> +#endif
> diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
> index e4b8030..e293390 100644
> --- a/UefiCpuPkg/UefiCpuPkg.dec
> +++ b/UefiCpuPkg/UefiCpuPkg.dec
> @@ -51,6 +51,7 @@
>SmmCpuFeaturesLib|Include/Library/SmmCpuFeaturesLib.h
>  
>  [Guids]
> +  ## Include/Guid/UefiCpuPkgTokenSpace.h
>gUefiCpuPkgTokenSpaceGuid  = { 0xac05bf33, 0x995a, 0x4ed4, { 0xaa, 
> 0xb8, 0xef, 0x7a, 0xe8, 0xf, 0x5c, 0xb0 }}
>  
>  [Protocols]
> 

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

Re: [edk2] [PATCH 6/7] UefiCpiPkg: Add PiSmmCpuDxeSmm module

2015-10-07 Thread Laszlo Ersek

On 10/05/15 01:57, Michael Kinney wrote:
> Add module that initializes a CPU for the SMM envirnment and
> installs the first level SMI handler.  This module along with the
> SMM IPL and SMM Core provide the services required for
> DXE_SMM_DRIVERS to register hardware and software SMI handlers.
>
> CPU specific features are abstracted through the SmmCpuFeaturesLib
>
> Platform specific features are abstracted through the
> SmmCpuPlatformHookLib
>
> Several PCDs are added to enable/disable features and configure
> settings for the PiSmmCpuDxeSmm module
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Michael Kinney 

(I'm snipping the patch because it is extremely long.)

I'm going through my "QuarkPort" patches, evaluating for each one if I
should keep it, drop it, or adapt it.

* [PATCH 27/58] OvmfPkg: import PCDs from
  Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg
  http://thread.gmane.org/gmane.comp.bios.edk2.devel/329/focus=350

  Going through all the PCDs I had to import there, and checking if each
  was present in this patch too, I found the following difference:

  PcdCpuSmmUncacheCpuSyncData is absent from this patch. In my
  "QuarkPort", the PCD is used by the InitializeMpServiceData() function
  only, gating a call to SetCacheability(). And that call to
  SetCacheability() is the *only* such call.

  Now, this patch provides SetCacheability(), but no calls are made to
  it, ever (in accordance with the fact that the PCD that would control
  the call is also absent).

  (1) Therefore I recommend to delete the SetCacheability() function
  from this patch.

  (2) I have a question wrt. PcdCpuSmmEnableBspElection. In the Quark
  package, the "IA32FamilyCpuBasePkg.dsc" file overrides the default
  TRUE value (from the .dec) for this PCD, with FALSE.

  The .dec default is similarly TRUE here. In my "QuarkPort" for
  OVMF, I flipped the PCD to FALSE as well. Does that make sense?
  Should I stick with that override, when rebasing the OVMF SMM
  series on top of this series? I don't know why this PCD matters.
  What are the benefits vs. drawbacks of dynamic BSP-for-SMI
  election?

* [PATCH 28/58] OvmfPkg: import three protocols from
  Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg
  http://thread.gmane.org/gmane.comp.bios.edk2.devel/329/focus=351

  (3) This patch doesn't install gSmmCpuSyncProtocolGuid or
  gSmmCpuSync2ProtocolGuid in PiCpuSmmEntry(), whereas Quark does.

  I don't know what those protocols good for, but can you please
  summarize why this patch doesn't need them?

* [PATCH 32/58] OvmfPkg: QuarkPort: drop ACPI_CPU_DATA.APState
  http://thread.gmane.org/gmane.comp.bios.edk2.devel/329/focus=362

  (4) Patch 5/7 in this series introduces the ACPI_CPU_DATA structure.
  That structure has a field APState. I think it should be dropped,
  it is never used in 6/7.

* [PATCH 33/58] OvmfPkg: add skeleton QuarkPort/CpuS3DataDxe
  http://thread.gmane.org/gmane.comp.bios.edk2.devel/329/focus=357

  This patch in my SMM series (and a few later ones that relate to
  CpuS3DataDxe) make me ask my most important question here.

  The PiSmmCpuDxeSmm module in this series -- same as in Quark -- only
  *consumes* PcdCpuS3DataAddress, to save the ACPI_CPU_DATA structure,
  collected by "some driver", into SMRAM.

  In Quark, PiSmmCpuDxeSmm insisted on this, therefore I had to extract
  the "collection" portions of CpuMpDxe, and I named it CpuS3DataDxe.

  However, in this patch, PiSmmCpuDxeSmm seems to be able to handle
  a zero PcdCpuS3DataAddress:

  - in SmmReadyToLockEventNotify(), on normal boot, no collected data is
saved into SMRAM,

  - in SmmRestoreCpu(), at S3 resume, the restoration of said data is
also skipped.

  My questions are:

  (5) Why is this safe? For OVMF's "QuarkPort", identifying and porting
  the required subset of CpuMpDxe (under the name CpuS3DataDxe), in
  order to populate PcdCpuS3DataAddress and ACPI_CPU_DATA, was a
  *major* headache. (Each field in that structure required separate
  analysis.)

  If PcdCpuS3DataAddress doesn't get populated though, then none of
  the ACPI_CPU_DATA fields are restored at S3 resume either, in
  EarlyInitializeCpu() and InitializeCpu().

  (6) When you tested this series on physical hardware, did a different
  driver (not included in this series) exist there in the firmware,
  populating PcdCpuS3DataAddress, and the pointed-to ACPI_CPU_DATA
  structure? Did you test S3?

  - If you think it is safe to leave PcdCpuS3DataAddress and the
pointed-to ACPI_CPU_DATA struct empty (and you tested such a
config), then I'll just drop my CpuS3DataDxe driver. Meaning [PATCH
33/58] referenced above, plus *all* of these patches (note that
there's one UefiCpuPkg/CpuDxe patch among them):

[PATCH 34/58] OvmfPkg: QuarkPort/CpuS3DataDxe: fill in
  ACPI_CPU_DATA.StartupVector
[PATCH 35/58] OvmfPkg: QuarkPor

[edk2] iPXE and UEFI HTTP Boot

2015-10-07 Thread El-Haj-Mahmoud, Samer

Looks like iPXE has been updated to work with UEFI 2.5 HTTP Boot, and tested 
with OVMF:

http://ipxe.org/appnote/uefihttp

The page also includes instructions for configuring the DHCP server to enable 
HTTP Boot, and building OVMF with HTTP_BOOT enabled.

It would be interesting to see if iPXE EFI version will directly use 
EFI_HTTP_PROTOCOL or carry its own TCP/IP HTTP code.

Thanks,
--Samer

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

Re: [edk2] [PATCH] OvmfPkg: raise DXEFV size to 9 MB

2015-10-07 Thread Laszlo Ersek

On 10/07/15 11:11, Gary Ching-Pang Lin wrote:
> With gcc5 and enabling SECURE_BOOT and NETWORK_IP6, the build
> failed with this error:
> 
> GenFv: ERROR 3000: Invalid
>   the required fv image size 0x814c18 exceeds the set fv image size 0x80
> 
> Raise the DXEFV size to 9 MB to fix the build error.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Gary Ching-Pang Lin 
> ---
>  OvmfPkg/OvmfPkgIa32.fdf| 6 +++---
>  OvmfPkg/OvmfPkgIa32X64.fdf | 6 +++---
>  OvmfPkg/OvmfPkgX64.fdf | 6 +++---
>  3 files changed, 9 insertions(+), 9 deletions(-)

Yes, I've considered doing this earlier. Glad to see it being
contributed. :)

So, I eyeballed the FDF file(s), and various parts of the OVMF
whitepaper, and I think this change is correct.

Reviewed-by: Laszlo Ersek 

In addition, I tested S3 suspend-resume, both with and without my
pending SMM series (which I rebased on top of this change). Everything
works, and comparing the verbose OVMF debug logs, the
PcdOvmfDxeMemFvSize change is reflected, and the derived differences
appear correct too. Therefore,

Regression-tested-by: Laszlo Ersek 

Committed to SVN as r18577.

Going forward, let's remember that the compressed size (for more than
just DXEFV) is capped independently, with FVMAIN_COMPACT, to 1712 KB
(see FVMAIN_SIZE in "OvmfPkg/OvmfPkg.fdf.inc", the non-FD_SIZE_1MB case).

In the (distant) future, that could become a practical limitation (and
then we'd have to increase the size of the flash image too), but for the
time being, I think we have plenty of room left empty in FVMAIN_COMPACT,
after the compression. (More than 25% in my usual builds.)

Thanks!
Laszlo


> diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
> index 20b6df2..d4ae2f9 100644
> --- a/OvmfPkg/OvmfPkgIa32.fdf
> +++ b/OvmfPkg/OvmfPkgIa32.fdf
> @@ -79,10 +79,10 @@ [FD.OVMF_CODE]
>  
>  [FD.MEMFD]
>  BaseAddress   = 0x80
> -Size  = 0x90
> +Size  = 0xA0
>  ErasePolarity = 1
>  BlockSize = 0x1
> -NumBlocks = 0x90
> +NumBlocks = 0xA0
>  
>  0x00|0x006000
>  
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
> @@ -103,7 +103,7 @@ [FD.MEMFD]
>  
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
>  FV = PEIFV
>  
> -0x10|0x80
> +0x10|0x90
>  
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
>  FV = DXEFV
>  
> diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
> index 6852e0e..5b4d9dc 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.fdf
> +++ b/OvmfPkg/OvmfPkgIa32X64.fdf
> @@ -79,10 +79,10 @@ [FD.OVMF_CODE]
>  
>  [FD.MEMFD]
>  BaseAddress   = 0x80
> -Size  = 0x90
> +Size  = 0xA0
>  ErasePolarity = 1
>  BlockSize = 0x1
> -NumBlocks = 0x90
> +NumBlocks = 0xA0
>  
>  0x00|0x006000
>  
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
> @@ -103,7 +103,7 @@ [FD.MEMFD]
>  
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
>  FV = PEIFV
>  
> -0x10|0x80
> +0x10|0x90
>  
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
>  FV = DXEFV
>  
> diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
> index 7fbd038..8b4dd60 100644
> --- a/OvmfPkg/OvmfPkgX64.fdf
> +++ b/OvmfPkg/OvmfPkgX64.fdf
> @@ -79,10 +79,10 @@ [FD.OVMF_CODE]
>  
>  [FD.MEMFD]
>  BaseAddress   = 0x80
> -Size  = 0x90
> +Size  = 0xA0
>  ErasePolarity = 1
>  BlockSize = 0x1
> -NumBlocks = 0x90
> +NumBlocks = 0xA0
>  
>  0x00|0x006000
>  
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
> @@ -103,7 +103,7 @@ [FD.MEMFD]
>  
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
>  FV = PEIFV
>  
> -0x10|0x80
> +0x10|0x90
>  
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
>  FV = DXEFV
>  
> 

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

[edk2] [PATCH] OvmfPkg: raise DXEFV size to 9 MB

2015-10-07 Thread Gary Ching-Pang Lin

With gcc5 and enabling SECURE_BOOT and NETWORK_IP6, the build
failed with this error:

GenFv: ERROR 3000: Invalid
  the required fv image size 0x814c18 exceeds the set fv image size 0x80

Raise the DXEFV size to 9 MB to fix the build error.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Ching-Pang Lin 
---
 OvmfPkg/OvmfPkgIa32.fdf| 6 +++---
 OvmfPkg/OvmfPkgIa32X64.fdf | 6 +++---
 OvmfPkg/OvmfPkgX64.fdf | 6 +++---
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 20b6df2..d4ae2f9 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -79,10 +79,10 @@ [FD.OVMF_CODE]
 
 [FD.MEMFD]
 BaseAddress   = 0x80
-Size  = 0x90
+Size  = 0xA0
 ErasePolarity = 1
 BlockSize = 0x1
-NumBlocks = 0x90
+NumBlocks = 0xA0
 
 0x00|0x006000
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
@@ -103,7 +103,7 @@ [FD.MEMFD]
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
 FV = PEIFV
 
-0x10|0x80
+0x10|0x90
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
 FV = DXEFV
 
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 6852e0e..5b4d9dc 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -79,10 +79,10 @@ [FD.OVMF_CODE]
 
 [FD.MEMFD]
 BaseAddress   = 0x80
-Size  = 0x90
+Size  = 0xA0
 ErasePolarity = 1
 BlockSize = 0x1
-NumBlocks = 0x90
+NumBlocks = 0xA0
 
 0x00|0x006000
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
@@ -103,7 +103,7 @@ [FD.MEMFD]
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
 FV = PEIFV
 
-0x10|0x80
+0x10|0x90
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
 FV = DXEFV
 
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 7fbd038..8b4dd60 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -79,10 +79,10 @@ [FD.OVMF_CODE]
 
 [FD.MEMFD]
 BaseAddress   = 0x80
-Size  = 0x90
+Size  = 0xA0
 ErasePolarity = 1
 BlockSize = 0x1
-NumBlocks = 0x90
+NumBlocks = 0xA0
 
 0x00|0x006000
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
@@ -103,7 +103,7 @@ [FD.MEMFD]
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
 FV = PEIFV
 
-0x10|0x80
+0x10|0x90
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
 FV = DXEFV
 
-- 
2.1.4

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

Re: [edk2] [PATCH] ArmPlatformPkg/ARMJunoPkg: Change Interrupt for PCI Routing table

2015-10-07 Thread Leif Lindholm

Thanks!

Committed as svn revision 18576, with a line break added to commit
message to keep line length below 72 characters.

Final comment: can you change the mailing list address you use to the
@lists.01.org variant instead of @ml01.01.org?

Regards,

Leif

On Tue, Oct 06, 2015 at 05:24:09PM +, Supreeth Venkatesh wrote:
> Will do.
> 
> Thanks,
> Supreeth
> 
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Tuesday, October 06, 2015 10:47 AM
> To: Supreeth Venkatesh
> Cc: edk2-de...@ml01.01.org
> Subject: Re: [PATCH] ArmPlatformPkg/ARMJunoPkg: Change Interrupt for PCI 
> Routing table
> 
> Hi Supreeth,
> 
> Thanks for this, and sorry for delay.
> Could you update the title and commit message though - the title says you're 
> changing IRQ numbers and the body says you're you're adding PCI IO ranges, 
> but the patch does both of these.
> 
> I would suggest a title of "ArmPlatformPkg: Fixes for Juno ACPI", and a body 
> describing both sets of changes.
> 
> Regards,
> 
> Leif
> 
> On Fri, Sep 11, 2015 at 02:00:26PM -0500, Supreeth Venkatesh wrote:
> > Support for PCI IO range with ACPI on JUNO
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> >
> > Signed-off-by: Supreeth Venkatesh 
> > ---
> >  .../ArmJunoPkg/AcpiTables/AcpiSsdtRootPci.asl  | 27 
> > --
> >  1 file changed, 20 insertions(+), 7 deletions(-)
> >
> > diff --git a/ArmPlatformPkg/ArmJunoPkg/AcpiTables/AcpiSsdtRootPci.asl
> > b/ArmPlatformPkg/ArmJunoPkg/AcpiTables/AcpiSsdtRootPci.asl
> > index c6d5a9a..7d50a5f 100644
> > --- a/ArmPlatformPkg/ArmJunoPkg/AcpiTables/AcpiSsdtRootPci.asl
> > +++ b/ArmPlatformPkg/ArmJunoPkg/AcpiTables/AcpiSsdtRootPci.asl
> > @@ -57,13 +57,13 @@ DefinitionBlock("SsdtPci.aml", "SSDT", 1, "ARMLTD", 
> > "ARM-JUNO", EFI_ACPI_ARM_OEM
> >  Name(_ADR, 0xF000)// Dev 0, Func 0
> >  }
> >
> > -// PCI Routing Table
> > - Name(_PRT, Package() {
> > - ROOT_PRT_ENTRY(0, 136),   // INTA
> > - ROOT_PRT_ENTRY(1, 137),   // INTB
> > - ROOT_PRT_ENTRY(2, 138),   // INTC
> > - ROOT_PRT_ENTRY(3, 139),   // INTD
> > - })
> > + // PCI Routing Table
> > + Name(_PRT, Package() {
> > + ROOT_PRT_ENTRY(0, 168),   // INTA
> > + ROOT_PRT_ENTRY(1, 169),   // INTB
> > + ROOT_PRT_ENTRY(2, 170),   // INTC
> > + ROOT_PRT_ENTRY(3, 171),   // INTD
> > + })
> >  // Root complex resources
> >   Method (_CRS, 0, Serialized) {
> >   Name (RBUF, ResourceTemplate () { @@ -98,6 +98,19 @@
> > DefinitionBlock("SsdtPci.aml", "SSDT", 1, "ARMLTD", "ARM-JUNO", 
> > EFI_ACPI_ARM_OEM
> >   0x,   
> >   // Translate
> >   0x1   
> >   // Length
> >   )
> > +
> > + DWordIo ( // IO window
> > + ResourceProducer,
> > + MinFixed,
> > + MaxFixed,
> > + PosDecode,
> > + EntireRange,
> > + 0x,   
> >   // Granularity
> > + 0x5f80,   
> >   // Min Base Address
> > + 0x5fff,   
> >   // Max Base Address
> > + 0x5f80,   
> >   // Translate
> > + 0x0080
> >   // Length
> > + )
> >   }) // Name(RBUF)
> >
> >   Return (RBUF)
> > --
> > 2.5.0
> >
> 
> 
> 
> 
> -- IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3] Pkg-Module: Integrate new RngLib into RngDxe

Re: [edk2] [PATCH v3] Pkg-Module: Integrate new RngLib into RngDxe

Re: [edk2] [PATCH v3 4/5] MdeModulePkg/DxeIplPeim: implement non-exec stack for ARM/AARCH64

Re: [edk2] Support for UBI volumes and UBIFS?

[edk2] [PATCH] BaseTools/Scripts: Add PatchCheck.py script

[edk2] [PATCH v3] Pkg-Module: Integrate new RngLib into RngDxe

Re: [edk2] [PATCH 6/7] UefiCpiPkg: Add PiSmmCpuDxeSmm module

Re: [edk2] [PATCH 7/7] UefiCpuPkg: Add missing UefiCpuPkgTokenSpace include

[edk2] Driver Health Protocol, UI interaction and Intel DQ77MK vs. OVMF

Re: [edk2] Is it possible to 'resume' and event?

Re: [edk2] [PATCH 5/7] UefiCpuPkg: Add PiSmmCpuDxeSmm module includes

Re: [edk2] [PATCH 7/7] UefiCpuPkg: Add missing UefiCpuPkgTokenSpace include

Re: [edk2] [PATCH 6/7] UefiCpiPkg: Add PiSmmCpuDxeSmm module

[edk2] iPXE and UEFI HTTP Boot

Re: [edk2] [PATCH] OvmfPkg: raise DXEFV size to 9 MB

[edk2] [PATCH] OvmfPkg: raise DXEFV size to 9 MB

Re: [edk2] [PATCH] ArmPlatformPkg/ARMJunoPkg: Change Interrupt for PCI Routing table

17 matches

Site Navigation

Mail list logo

Footer information