[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Build Script.

2017-07-11 Thread lushifex 
Change GCC build script.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: lushifex 
---
 BuildBIOS.sh | 28 ++-
 Platform/BroxtonPlatformPkg/BuildIFWI.sh | 46 ++--
 2 files changed, 41 insertions(+), 33 deletions(-)

diff --git a/BuildBIOS.sh b/BuildBIOS.sh
index c241d87..552cf2d 100755
--- a/BuildBIOS.sh
+++ b/BuildBIOS.sh
@@ -10,6 +10,25 @@
 #
 
 ##**
+## Function define
+##**
+function Usage () {
+  echo
+  echo "Script to build BIOS firmware and stitch the entire IFWI."
+  echo
+  echo "Usage: BuildBIOS.sh Build_Flags [PlatformName]  Target_Flag"
+  echo
+  echo "   Build_Flags: /A Set FabId to A (default:  
FAB_B)"
+  echo "   Build_Flags: /B Set FabId to B (default:  
FAB_B)"
+  echo "   PlatformName [optional]: Broxton  "   
+  echo "   Target_Flag: Release, Debug   "
+  echo
+  echo "Press any key.."
+  read
+  exit 0
+}
+
+##**
 ## Initial Setup
 ##**
 
@@ -20,6 +39,13 @@ if [ "$1" == "/?" ]; then
   Usage
 fi
 
+if [ "$1" == "" ]; then
+  echo "Not Enough Arguments Provided"
+  echo "Please review the Help screen"
+  Usage
+fi
+
+
 ## Build Flags
 for (( i=1; i<=$#; ))
   do
@@ -56,5 +82,5 @@ export 
PACKAGES_PATH=$WORKSPACE:$WORKSPACE/Core:$WORKSPACE/Silicon/:$WORKSPACE/P
 
 make -C BaseTools
 
-bash ./Platform/BroxtonPlatformPkg/BuildIFWI.sh $Build_Flags APLI $Target_Flag
+bash ./Platform/BroxtonPlatformPkg/BuildIFWI.sh $Build_Flags Broxton 
$Target_Flag
 
diff --git a/Platform/BroxtonPlatformPkg/BuildIFWI.sh 
b/Platform/BroxtonPlatformPkg/BuildIFWI.sh
index 69ed67a..a315e0b 100755
--- a/Platform/BroxtonPlatformPkg/BuildIFWI.sh
+++ b/Platform/BroxtonPlatformPkg/BuildIFWI.sh
@@ -13,41 +13,16 @@
 ##**
 ## Function define
 ##**
-function Usage() {
+function Usage () {
   echo
   echo "Script to build BIOS firmware and stitch the entire IFWI."
   echo
-  echo "Usage: BuildIFWI.bat [options] ^ ^ [IFWI 
Suffix]"
+  echo "Usage: BuildIFWI.sh Build_Flags Platform_Type Build_Target"
   echo
-  echo "   /?Display this help text
   "
-  echo "   /qQuiet mode. Only display Fatal Errors (slightly faster)   
   "
-  echo "   /lLog a copy of the build output to EDK2.log
   "
-  echo "   /cCleanAll before building  
   "
-  echo "   /wEnabled WinDbg module for build   
   "
-  echo "   /sv   Build with SVBIOS flags enabled   
   "
-  echo "   /ppv  Build with PPV flags enabled  
   "
-  echo "   /rvv  Build with RVV BXTM flags enabled 
   "
-  echo "   /rvvp Build with RVVP BXTP flags enabled
   "
-  echo "   /x64  Set Arch to X64  (default: IA32)  
   "
-  echo "   /sata Enable SATA Build 
   "
-  echo "   /pcie Enable PCIe Build 
   "
-  echo "   /nG   Not update GOP driver per StitchConfig (override src 
version)"
-  echo "   /uM   Update Microcode per StitchConfig  (override src version) 
   "
-  echo
-  echo "  Set ONLY ONE of the following:   
   "
-  echo "   /vp   Set special build flag for ALL Pre-Si 
   "
-  echo "   /csle Set special build flag for C-SLE  
   "
-  echo
-  echo " Platform Types:   $eNB_RVP $Phblt_RVP $Phblt_Die1_RVP $Embd_RVP   
   "
-  echo "  APLK - Netbook/Desktop   
   "
-  echo "  BXTM - Phablet build for BXT-A   
   "
-  echo "  BXTM1 - Phablet build for BXT Die1(E0)   
   "
-  echo "  APLI - Embedded/IVI build (IOTG) 
"
-  echo
-  echo "   Build Targets:Release, Debug
   "
-  echo "   IFWI Suffix:  Suffix to

[edk2] [Patch][edk2-platforms] Change GCC build script.

2017-07-11 Thread lushifex 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: lushifex 
---
 Vlv2TbltDevicePkg/Build_IFWI.sh | 7 +--
 Vlv2TbltDevicePkg/bld_vlv.sh| 2 +-
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/Vlv2TbltDevicePkg/Build_IFWI.sh b/Vlv2TbltDevicePkg/Build_IFWI.sh
index 4a11a1c..0f7e155 100755
--- a/Vlv2TbltDevicePkg/Build_IFWI.sh
+++ b/Vlv2TbltDevicePkg/Build_IFWI.sh
@@ -6,7 +6,7 @@ function Usage ( ) {
   echo
   echo "Script to build BIOS firmware and stitch the entire IFWI."
   echo
-  echo "Usage: Build_IFWI.bat [options]  PlatformType  BuildTarget  "
+  echo "Usage: Build_IFWI.sh [options]  PlatformType  BuildTarget  "
   echo
   echo 
   echo "   /yL [option]  :   Enable SPI lock"
@@ -15,7 +15,8 @@ function Usage ( ) {
   echo
   echo "   See  Stitch/Stitch_Config.txt  for additional stitching 
settings."
   echo
-  echo
+  echo "Press any key.."
+  read
   exit 0
 }
 
@@ -71,6 +72,8 @@ for (( i=1; i<=$#; ))
 
 ## Require 2 input parameters
 if [ "$2" == "" ]; then
+  echo "Not Enough Arguments Provided"
+  echo "Please review the Help screen"
   Usage
 fi
 
diff --git a/Vlv2TbltDevicePkg/bld_vlv.sh b/Vlv2TbltDevicePkg/bld_vlv.sh
index 538b3ef..cba30c6 100755
--- a/Vlv2TbltDevicePkg/bld_vlv.sh
+++ b/Vlv2TbltDevicePkg/bld_vlv.sh
@@ -7,7 +7,7 @@ function Usage() {
   echo 
"***"
   echo "Build BIOS rom for VLV platforms."
   echo
-  echo "Usage: bld_vlv.bat  PlatformType [Build Target]"
+  echo "Usage: bld_vlv.sh  PlatformType [Build Target]"
   echo
   echo
   echo "   Platform Types:  MNW2"
-- 
2.7.0.windows.1


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

Re: [edk2] [PATCH v2 1/1] OvmfPkg/QemuFwCfgLib: Suppress GCC49 IA32 build failure

2017-07-11 Thread Laszlo Ersek 
On 07/11/17 20:38, Brijesh Singh wrote:
> NumPages variable was introduced in commit 66c548be509d. In this commit
> we allocate an intermediate buffer when SEV is enabled. The 'BounceBuffer'
> variable points to the intermediate buffer pointer and NumPages variables
> stores the number of pages. Later in the code, 'BounceBuffer' variable is
> checked to see if we need to free the intermediate buffers. The code looks
> correct, suppress the warning.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Reported-by: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Brijesh Singh 
> ---
> Changes since v1:
>  - add comments and move the local variable initialization to new line
> 
>  OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c 
> b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
> index dbebd36b1853..0310d2872dae 100644
> --- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
> +++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
> @@ -83,6 +83,11 @@ InternalQemuFwCfgDmaBytes (
>}
>  
>//
> +  // set NumPages to suppress incorrect compiler/analyzer warnigns
> +  //
> +  NumPages = 0;
> +
> +  //
>// When SEV is enabled then allocate DMA bounce buffer
>//
>if (InternalQemuFwCfgSevIsEnabled ()) {
> 

Reported-by: Gerd Hoffmann 
Reviewed-by: Laszlo Ersek 
[ler...@redhat.com: s/warnigns/warnings/ in the code comment]
[ler...@redhat.com: add Gerd's Reported-by]
Signed-off-by: Laszlo Ersek 

Pushed as commit e508e069a809.

I also fixed up the typo in
.

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

[edk2] [PATCH v2 1/1] OvmfPkg/QemuFwCfgLib: Suppress GCC49 IA32 build failure

2017-07-11 Thread Brijesh Singh 
NumPages variable was introduced in commit 66c548be509d. In this commit
we allocate an intermediate buffer when SEV is enabled. The 'BounceBuffer'
variable points to the intermediate buffer pointer and NumPages variables
stores the number of pages. Later in the code, 'BounceBuffer' variable is
checked to see if we need to free the intermediate buffers. The code looks
correct, suppress the warning.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Reported-by: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Brijesh Singh 
---
Changes since v1:
 - add comments and move the local variable initialization to new line

 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c 
b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
index dbebd36b1853..0310d2872dae 100644
--- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
+++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
@@ -83,6 +83,11 @@ InternalQemuFwCfgDmaBytes (
   }
 
   //
+  // set NumPages to suppress incorrect compiler/analyzer warnigns
+  //
+  NumPages = 0;
+
+  //
   // When SEV is enabled then allocate DMA bounce buffer
   //
   if (InternalQemuFwCfgSevIsEnabled ()) {
-- 
2.7.4

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

Re: [edk2] [PATCH 1/1] OvmfPkg/QemuFwCfgLib: Suppress GCC49 IA32 build failure

2017-07-11 Thread Brijesh Singh 



On 07/11/2017 12:34 PM, Laszlo Ersek wrote:

Hi Brijesh,

On 07/11/17 19:08, Brijesh Singh wrote:

NumPages variable was introduced in commit 66c548be509d. In this commit
we allocate an intermediate buffer when SEV is enabled. The 'BounceBuffer'
variable points to the intermediate buffer pointer and NumPages variables
stores the number of pages. Later in the code, 'BounceBuffer' variable is
checked to see if we need to free the intermediate buffers. The code looks
correct, suppress the warning.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Reported-by: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Brijesh Singh 
---
  OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c 
b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
index dbebd36b1853..1b21ef094dc5 100644
--- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
+++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
@@ -72,7 +72,7 @@ InternalQemuFwCfgDmaBytes (
volatile FW_CFG_DMA_ACCESS *Access;
UINT32 AccessHigh, AccessLow;
UINT32 Status;
-  UINT32 NumPages;
+  UINT32 NumPages = 0;
VOID   *DmaBuffer, *BounceBuffer;
  
ASSERT (Control == FW_CFG_DMA_CTL_WRITE || Control == FW_CFG_DMA_CTL_READ ||




In edk2 we don't initialize local variables in the ISO C sense of
"initialization" -- please use a separate assignment, plus add a code
comment like mentioned here:

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



Thanks for quick review Laszlo, I will update the patch with those comments.

-Brijesh

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

Re: [edk2] [PATCH 1/1] OvmfPkg/QemuFwCfgLib: Suppress GCC49 IA32 build failure

2017-07-11 Thread Laszlo Ersek 
Hi Brijesh,

On 07/11/17 19:08, Brijesh Singh wrote:
> NumPages variable was introduced in commit 66c548be509d. In this commit
> we allocate an intermediate buffer when SEV is enabled. The 'BounceBuffer'
> variable points to the intermediate buffer pointer and NumPages variables
> stores the number of pages. Later in the code, 'BounceBuffer' variable is
> checked to see if we need to free the intermediate buffers. The code looks
> correct, suppress the warning.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Reported-by: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Brijesh Singh 
> ---
>  OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c 
> b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
> index dbebd36b1853..1b21ef094dc5 100644
> --- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
> +++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
> @@ -72,7 +72,7 @@ InternalQemuFwCfgDmaBytes (
>volatile FW_CFG_DMA_ACCESS *Access;
>UINT32 AccessHigh, AccessLow;
>UINT32 Status;
> -  UINT32 NumPages;
> +  UINT32 NumPages = 0;
>VOID   *DmaBuffer, *BounceBuffer;
>  
>ASSERT (Control == FW_CFG_DMA_CTL_WRITE || Control == FW_CFG_DMA_CTL_READ 
> ||
> 

In edk2 we don't initialize local variables in the ISO C sense of
"initialization" -- please use a separate assignment, plus add a code
comment like mentioned here:

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

Other than that, I agree that NumPages cannot be used without setting it
first. The only such path through the code would be if
InternalQemuFwCfgSevIsEnabled() returned FALSE. However, in that case,
BounceBuffer is set to NULL, and the final use of NumPages (on line 168)
is never reached.

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

Re: [edk2] TianoCore-docs GitBook Documentation Process

2017-07-11 Thread Kinney, Michael D 
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, July 11, 2017 10:05 AM
> To: Kinney, Michael D 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] TianoCore-docs GitBook Documentation Process
> 
> On 07/11/17 17:21, Kinney, Michael D wrote:
> > Laszlo,
> >
> > I found a GitBook plugin that can provide the branch name and
> > the SHA hash in either short or long form.
> >
> > https://plugins.gitbook.com/plugin/gitversion
> >
> > Here is an example patch to the EDK II Template Specification
> > That add this plugin to book.json and add the branch name and
> > SHA hash below the build time/date stamp of the document.
> >
> > diff --git a/README.md b/README.md
> > index 30edb2a..4ad8a96 100644
> > --- a/README.md
> > +++ b/README.md
> > @@ -41,6 +41,10 @@
> >
> >  ** {{ gitbook.time|date('MM/DD/ hh:mm:ss') }} **
> >
> > +** {{ "GIT branch: " | gitBranch }} **
> > +
> > +** {{ "GIT hash: " | gitLong }} **
> > +
> >  {% if book.udkrelease %}
> >  ** {{ book.udkrelease }} **
> >  {% endif %}
> > diff --git a/book.json b/book.json
> > index 8c58ffe..d94cbcc 100644
> > --- a/book.json
> > +++ b/book.json
> > @@ -5,6 +5,6 @@
> >  "version" : "Revision 0.20"
> >},
> >
> > -  "plugins": ["puml"],
> > +  "plugins": ["puml", "gitversion"],
> >"pluginsConfig": {}
> >  }
> 
> Ah, great!
> 
> Does the fact that the plugin list is provided in the book
> itself (in
> "book.json") imply that gitbook.com too will load the plugin,
> and
> generate the right output, in these "remote" renderings?

Yes.  When building locally, you need to run "gitbook install"
to install all plugins locally.  The GitBook server automatically
does this step as part of the publication action.

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

[edk2] [PATCH 1/1] OvmfPkg/QemuFwCfgLib: Suppress GCC49 IA32 build failure

2017-07-11 Thread Brijesh Singh 
NumPages variable was introduced in commit 66c548be509d. In this commit
we allocate an intermediate buffer when SEV is enabled. The 'BounceBuffer'
variable points to the intermediate buffer pointer and NumPages variables
stores the number of pages. Later in the code, 'BounceBuffer' variable is
checked to see if we need to free the intermediate buffers. The code looks
correct, suppress the warning.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Reported-by: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Brijesh Singh 
---
 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c 
b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
index dbebd36b1853..1b21ef094dc5 100644
--- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
+++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
@@ -72,7 +72,7 @@ InternalQemuFwCfgDmaBytes (
   volatile FW_CFG_DMA_ACCESS *Access;
   UINT32 AccessHigh, AccessLow;
   UINT32 Status;
-  UINT32 NumPages;
+  UINT32 NumPages = 0;
   VOID   *DmaBuffer, *BounceBuffer;
 
   ASSERT (Control == FW_CFG_DMA_CTL_WRITE || Control == FW_CFG_DMA_CTL_READ ||
-- 
2.7.4

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

Re: [edk2] TianoCore-docs GitBook Documentation Process

2017-07-11 Thread Laszlo Ersek 
On 07/11/17 17:21, Kinney, Michael D wrote:
> Laszlo,
> 
> I found a GitBook plugin that can provide the branch name and
> the SHA hash in either short or long form.
> 
> https://plugins.gitbook.com/plugin/gitversion
> 
> Here is an example patch to the EDK II Template Specification
> That add this plugin to book.json and add the branch name and
> SHA hash below the build time/date stamp of the document.
> 
> diff --git a/README.md b/README.md
> index 30edb2a..4ad8a96 100644
> --- a/README.md
> +++ b/README.md
> @@ -41,6 +41,10 @@
> 
>  ** {{ gitbook.time|date('MM/DD/ hh:mm:ss') }} **
> 
> +** {{ "GIT branch: " | gitBranch }} **
> +
> +** {{ "GIT hash: " | gitLong }} **
> +
>  {% if book.udkrelease %}
>  ** {{ book.udkrelease }} **
>  {% endif %}
> diff --git a/book.json b/book.json
> index 8c58ffe..d94cbcc 100644
> --- a/book.json
> +++ b/book.json
> @@ -5,6 +5,6 @@
>  "version" : "Revision 0.20"
>},
> 
> -  "plugins": ["puml"],
> +  "plugins": ["puml", "gitversion"],
>"pluginsConfig": {}
>  }

Ah, great!

Does the fact that the plugin list is provided in the book itself (in
"book.json") imply that gitbook.com too will load the plugin, and
generate the right output, in these "remote" renderings?

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

Re: [edk2] TianoCore-docs GitBook Documentation Process

2017-07-11 Thread Kinney, Michael D 
Laszlo,

I found a GitBook plugin that can provide the branch name and
the SHA hash in either short or long form.

https://plugins.gitbook.com/plugin/gitversion

Here is an example patch to the EDK II Template Specification
That add this plugin to book.json and add the branch name and
SHA hash below the build time/date stamp of the document.

diff --git a/README.md b/README.md
index 30edb2a..4ad8a96 100644
--- a/README.md
+++ b/README.md
@@ -41,6 +41,10 @@

 ** {{ gitbook.time|date('MM/DD/ hh:mm:ss') }} **

+** {{ "GIT branch: " | gitBranch }} **
+
+** {{ "GIT hash: " | gitLong }} **
+
 {% if book.udkrelease %}
 ** {{ book.udkrelease }} **
 {% endif %}
diff --git a/book.json b/book.json
index 8c58ffe..d94cbcc 100644
--- a/book.json
+++ b/book.json
@@ -5,6 +5,6 @@
 "version" : "Revision 0.20"
   },

-  "plugins": ["puml"],
+  "plugins": ["puml", "gitversion"],
   "pluginsConfig": {}
 }

Best regards,

Mike

> -Original Message-
> From: Kinney, Michael D
> Sent: Monday, July 10, 2017 9:44 AM
> To: Laszlo Ersek ; Kinney, Michael D
> 
> Cc: edk2-devel@lists.01.org
> Subject: RE: [edk2] TianoCore-docs GitBook Documentation Process
> 
> Hi Laszlo,
> 
> Thanks for the quick feedback on this content.
> 
> Reponses included below, and I have already made some
> updates to the wiki based on your feedback.
> 
> Mike
> 
> > -Original Message-
> > From: Laszlo Ersek [mailto:ler...@redhat.com]
> > Sent: Saturday, July 8, 2017 2:36 PM
> > To: Kinney, Michael D 
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [edk2] TianoCore-docs GitBook Documentation
> Process
> >
> > Hi Mike,
> >
> > On 07/08/17 02:37, Kinney, Michael D wrote:
> > > Hello,
> > >
> > > I have added wiki pages that provide an overview of the
> > GitBook documentation
> > > process for TianoCore related documents.  These wiki pages
> are
> > attached to the
> > > EDK II Template Specification repository.  The link to the
> > approved RFC on this
> > > topic is also provided.
> > >
> > > https://github.com/tianocore-docs/edk2-
> > TemplateSpecification/wiki
> > >
> > > https://github.com/tianocore-docs/edk2-
> > TemplateSpecification/wiki/TianoCore-Documents-GitBook-
> > Overview#introduction
> > >
> > > I have also added a link to this content from the EDK II
> > Specification wiki page:
> > >
> > > https://github.com/tianocore/tianocore.github.io/wiki/EDK-
> II-
> > Specifications
> > >
> > > Please review and provide feedback if there are steps that
> are
> > missing or need clarification.
> >
> > This is a large set of articles, it must have been a lot of
> > work!
> >
> > I have four questions/ideas:
> >
> >
> > (1) The article at
> >  > TemplateSpecification/wiki/TianoCore-Documents-Services>
> > says,
> >
> >   3. Join the TianoCore-Docs organization on GitHub
> >
> > Can you send an invite? :) On the org page
> > , I looked for a button
> > saying
> > "request an invite" or some such, but came up empty.
> >
> > So what is the github way for joining an organization? I guess
> > the org
> > can send out invites at will, but "solicitation" in the other
> > direction
> > has to occur off-site? (Such as on this mailing list?)
> 
> I do not see a way for a developer to do the request either, so
> sending
> an invite looks to be the way to go here.  I would like the EDK
> II
> Maintainers that have write access to code to have same write
> access to
> Docs.  I will send those invites.
> 
> If anyone else wants write access that is not an EDK II
> Maintainer,
> then they would have to send an email request to edk2-devel.
> 
> I have updated the following page with the email request
> instructions
> 
>   https://github.com/tianocore-docs/edk2-
> TemplateSpecification/wiki/TianoCore-Documents-Services
> 
> >
> >
> > (2) The article at
> >  > TemplateSpecification/wiki/TianoCore-Documents-GitBook-
> Overview>
> > explains that there is some kind of (automated) syncing from
> the
> > tianocore-docs repos to GitBook.com.
> >
> > In case I'm looking at one of the official document git repos
> on
> > GitHub,
> > such as ,
> > what is
> > the fastest way to see an HTML rendered "DRAFT" (matching the
> > master
> > branch) on GitBook.com? Is there some URL pattern that one can
> > compose
> > manually, or is there a way to search for the book quickly on
> > GitBook.com?
> 
> A couple ways:
> 
> 1) Goto the GitBook homepage for tianocore-docs
> 
>   https://www.gitbook.com/@edk2-docs
> 
>All the books are listed and you can select any one
>of them.  The main page for a book has a "Read" button
>for the HTML version and a drop down box for PDF, MOBI,
>EPUB.
> 
>I have added this link to the intro paragraph and the
> "Resources"
>section on the TianoCore Documents

Re: [edk2] [Patch] UefiCpuPkg: Update RegisterCpuFeaturesLib to consume PcdGetSize with UINTN

2017-07-11 Thread Fan, Jeff 
Reviewed-by: Jeff Fan 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
Gao
Sent: Tuesday, July 11, 2017 11:34 AM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch] UefiCpuPkg: Update RegisterCpuFeaturesLib to consume 
PcdGetSize with UINTN

PcdGetSize() returns UINTN data type. The consumer code should use UINTN data 
to get its size.

This issue is found when PcdCpuFeaturesSupport is configured as patchable.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c | 2 +-
 .../Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c   | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c 
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
index 5e11b2b..e305aca 100644
--- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
+++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
@@ -149,7 +149,7 @@ CpuInitDataInitialize (
   CpuFeaturesData = GetCpuFeaturesData ();
   CpuFeaturesData->InitOrder = AllocateZeroPool (sizeof 
(CPU_FEATURES_INIT_ORDER) * NumberOfCpus);
   ASSERT (CpuFeaturesData->InitOrder != NULL);
-  CpuFeaturesData->BitMaskSize = PcdGetSize (PcdCpuFeaturesSupport);
+  CpuFeaturesData->BitMaskSize = (UINT32) PcdGetSize 
+ (PcdCpuFeaturesSupport);
 
   //
   // Collect CPU Features information
diff --git a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c 
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
index 338f1a4..dd6a82b 100644
--- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
+++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
@@ -29,7 +29,7 @@ IsCpuFeatureMatch (
   IN UINT8   *SecondFeatureMask
   )
 {
-  UINT32 BitMaskSize;
+  UINTN BitMaskSize;
 
   BitMaskSize = PcdGetSize (PcdCpuFeaturesSupport);
   if (CompareMem (FirstFeatureMask, SecondFeatureMask, BitMaskSize) == 0) { @@ 
-51,7 +51,7 @@ DumpCpuFeatureMask (  {
   UINTN  Index;
   UINT8  *Data8;
-  UINT32 BitMaskSize;
+  UINTN  BitMaskSize;
 
   BitMaskSize = PcdGetSize (PcdCpuFeaturesSupport);
   Data8   = (UINT8 *) FeatureMask;
@@ -258,7 +258,7 @@ RegisterCpuFeatureWorker (
   CPU_FEATURES_DATA  *CpuFeaturesData;
   CPU_FEATURES_ENTRY *CpuFeatureEntry;
   LIST_ENTRY *Entry;
-  UINT32 BitMaskSize;
+  UINTN  BitMaskSize;
   BOOLEANFeatureExist;
 
   BitMaskSize = PcdGetSize (PcdCpuFeaturesSupport);
@@ -267,7 +267,7 @@ RegisterCpuFeatureWorker (
 InitializeListHead (>FeatureList);
 InitializeSpinLock (>MsrLock);
 InitializeSpinLock (>MemoryMappedLock);
-CpuFeaturesData->BitMaskSize = BitMaskSize;
+CpuFeaturesData->BitMaskSize = (UINT32) BitMaskSize;
   }
   ASSERT (CpuFeaturesData->BitMaskSize == BitMaskSize);
 
--
2.8.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] UefiCpuPkg: Update RegisterCpuFeaturesLib module UNI to match it

2017-07-11 Thread Fan, Jeff 
Reviewed-by: Jeff Fan 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
Gao
Sent: Tuesday, July 11, 2017 11:33 AM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch] UefiCpuPkg: Update RegisterCpuFeaturesLib module UNI to 
match it

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 .../DxeRegisterCpuFeaturesLib.inf  |  2 +-
 .../PeiRegisterCpuFeaturesLib.inf  |  2 +-
 .../RegisterCpuFeaturesDxe.uni | 22 --
 .../RegisterCpuFeaturesLib.uni | 22 ++
 4 files changed, 24 insertions(+), 24 deletions(-)  delete mode 100644 
UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesDxe.uni
 create mode 100644 
UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.uni

diff --git 
a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/DxeRegisterCpuFeaturesLib.inf 
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/DxeRegisterCpuFeaturesLib.inf
index 62ac8a9..f0f317c 100644
--- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/DxeRegisterCpuFeaturesLib.inf
+++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/DxeRegisterCpuFeaturesLi
+++ b.inf
@@ -15,7 +15,7 @@
 [Defines]
   INF_VERSION= 0x00010005
   BASE_NAME  = DxeRegisterCpuFeaturesLib
-  MODULE_UNI_FILE= DxeRegisterCpuFeaturesLib.uni
+  MODULE_UNI_FILE= RegisterCpuFeaturesLib.uni
   FILE_GUID  = ADE8F745-AA2E-49f6-8ED4-746B34867E52
   MODULE_TYPE= DXE_DRIVER
   VERSION_STRING = 1.0
diff --git 
a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/PeiRegisterCpuFeaturesLib.inf 
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/PeiRegisterCpuFeaturesLib.inf
index 5e9ab2c..fdfef98 100644
--- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/PeiRegisterCpuFeaturesLib.inf
+++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/PeiRegisterCpuFeaturesLi
+++ b.inf
@@ -15,7 +15,7 @@
 [Defines]
   INF_VERSION= 0x00010005
   BASE_NAME  = PeiRegisterCpuFeaturesLib
-  MODULE_UNI_FILE= PeiRegisterCpuFeaturesLib.uni
+  MODULE_UNI_FILE= RegisterCpuFeaturesLib.uni
   FILE_GUID  = D8855DB3-8348-41B5-BDA4-385351767D41
   MODULE_TYPE= PEIM
   VERSION_STRING = 1.0
diff --git 
a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesDxe.uni 
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesDxe.uni
deleted file mode 100644
index d928952..000
--- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesDxe.uni
+++ /dev/null
@@ -1,22 +0,0 @@
-// /** @file
-// CPU Register Table Library instance.
-//
-// CPU Register Table Library instance.
-//
-// Copyright (c) 2016, Intel Corporation. All rights reserved. -// -// 
This program and the accompanying materials -// are licensed and made available 
under the terms and conditions of the BSD License -// 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.
-//
-// **/
-
-
-#string STR_MODULE_ABSTRACT #language en-US "CPU Register Table 
Library instance"
-
-#string STR_MODULE_DESCRIPTION  #language en-US "CPU Register Table 
Library instance."
-
diff --git 
a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.uni 
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.uni
new file mode 100644
index 000..09368cc
--- /dev/null
+++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.u
+++ ni
@@ -0,0 +1,22 @@
+// /** @file
+// Register CPU Features Library instance.
+//
+// Register CPU Features Library instance.
+//
+// Copyright (c) 2017, 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.
+//
+// **/
+
+
+#string STR_MODULE_ABSTRACT #language en-US "Register CPU Features 
Library instance"
+
+#string STR_MODULE_DESCRIPTION  #language en-US "Register CPU Features 
Library instance."
+
--
2.8.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] Regarding User Input

2017-07-11 Thread Narashimman Srinivasan 
Hi

I am in development of some scripts in UEFI shell. I need have command for
accept user input and assign to variable. 'pause' command used for pausing
and will not assign  user input to a variable.
If this available in EDK2, which module it belongs for user input and how
to build it.

Thank & Regards
Manjunatha Srinivasan N
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] BaseTools: Add COREBOOT tools definition

2017-07-11 Thread Gao, Liming 
Patrick:
  In current tools_def.txt, iasl path is ENV(IASL_PREFIX)iasl. So, you can 
configure IASL_PREFIX env to point the your directory. In edk2, GCC5 is the 
tool chain configuration with LTO support, not specific to the compiler 
version. Since COREBOOT has the same configuration, it can reuse GCC5 tool 
chain. To let user correctly use GCC5 tool chain build CorebootPayloadPkg, you 
can add readme.md in CorebootPayloadPkg to introduce how to generate the cross 
compiler and how to configure GCC5_PREFIX and IASL_PREFIX env. In fact, even if 
COREBOOT tool chain is added, you also need to document these steps. 

Thanks
Liming
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Patrick Georgi
>Sent: Monday, July 10, 2017 11:06 PM
>To: Gao, Liming 
>Cc: edk2-devel@lists.01.org
>Subject: Re: [edk2] [PATCH] BaseTools: Add COREBOOT tools definition
>
>Hi Liming,
>
>thank you for the review!
>
>2017-07-10 16:46 GMT+02:00 Gao, Liming :
>
>> Patrick:
>>   Compared GCC5 and COREBOOT, the difference is that GCC5_IA32_PREFIX
>and
>> GCC5_X64_PREFIX. CoreBoot tool chain has the different style. So, it can't
>> reuse GCC5 tool chain. If GCC5 is update to refer to ENV (GCC5_IA32_PREFIX)
>> and ENV (GCC5_X64_PREFIX) like ENV(GCC5_ARM_PREFIX) in CC_PATH,
>GCC5 can
>> support COREBOOT usage. For the future, the different FLAG can be
>appended
>> in [BuildOptions] of platform.dsc. So, I suggest to reuse GCC5 tool chain
>> for coreboot.
>>
>We also use our own make and iasl binaries.
>*_COREBOOT_*_MAKE_PATH   = DEF(COREBOOT_PREFIX)make
>*_COREBOOT_*_ASL_PATH= DEF(COREBOOT_PREFIX)iasl
>
>The coreboot toolchain is gcc 6.3 based right now but will move to
>something newer at some point. That the GCC5 configuration is sufficient
>for now is a coincidence (although appreciated since it meant less work for
>me). Unfortunately I likely won't be able to get away with that forever.
>Asking people to adapt their Tianocore config because the toolchain was
>updated is a bad user experience IMHO.
>
>The two main benefits of using a well-defined, maintained toolchain and
>configuration are:
>1. a portable toolchain: you get the same results no matter the OS you're on
>2. reproducible builds: with a given source tree and configuratoin, we get
>bit identical binaries, which is rather useful for trust/security
>assessments. See
>https://tests.reproducible-builds.org/coreboot/coreboot.html
>
>It might be useful to extend this effort to payloads such as
>CorebootPayloadPkg. Dealing with random compilers (and their configs) is
>something we at coreboot left behind ~10 years ago, and it was for the
>better. (although I understand that the coreboot toolchain is just as
>"random" to you as any other).
>But if you feel this is too much extra stuff in your config files, I'll
>have to see how to deal with the existing config sets instead.
>
>
>Patrick
>--
>Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
>Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
>Hamburg
>Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
>___
>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] Fwd: Build failed in Jenkins: edk2 #2791

2017-07-11 Thread Brijesh Singh 

Hi Laszlo,

On 07/11/2017 08:55 AM, Laszlo Ersek wrote:

Hi Brijesh,

Gerd's Jenkins CI caught a number of (most likely invalid)
[-Werror=maybe-uninitialized] issues with the new code. Do you have a
way to build the tree for IA32 with DEBUG_GCC49, evaluate the errors,
and send a series to suppress the warnings whenever they are invalid?
(Simply by assigning zero to the affected variables early into the
affected functions.)



I have been using GCC5, will try to setup GCC49 environment and provide
patches to fix this warning. Thanks for report.



Please note that the coding style requires a specific comment format for
such warning suppressions:

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

Of course, if some of these warnings happen to be correct, then the bugs
should be fixed. :)

Please find the first such error below.

Thanks!
Laszlo

 Forwarded Message 
Subject: Build failed in Jenkins: edk2 #2791
Date: Tue, 11 Jul 2017 11:00:57 +0200 (CEST)

OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c: In function 
'InternalQemuFwCfgDmaBytes':
OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c:168:5: error: 'NumPages' may be 
used uninitialized in this function [-Werror=maybe-uninitialized]
  InternalQemuFwCfgSevDmaFreeBuffer (BounceBuffer, NumPages);
  ^~
cc1: all warnings being treated as errors
make: *** 
[Build/OvmfIa32/DEBUG_GCC49/IA32/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiLib/OUTPUT/QemuFwCfgLib.obj]
 Error 1
GNUmakefile:330: recipe for target 
'Build/OvmfIa32/DEBUG_GCC49/IA32/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiLib/OUTPUT/QemuFwCfgLib.obj'
 failed


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

[edk2] Fwd: Build failed in Jenkins: edk2 #2791

2017-07-11 Thread Laszlo Ersek 
Hi Brijesh,

Gerd's Jenkins CI caught a number of (most likely invalid)
[-Werror=maybe-uninitialized] issues with the new code. Do you have a
way to build the tree for IA32 with DEBUG_GCC49, evaluate the errors,
and send a series to suppress the warnings whenever they are invalid?
(Simply by assigning zero to the affected variables early into the
affected functions.)

Please note that the coding style requires a specific comment format for
such warning suppressions:

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

Of course, if some of these warnings happen to be correct, then the bugs
should be fixed. :)

Please find the first such error below.

Thanks!
Laszlo

 Forwarded Message 
Subject: Build failed in Jenkins: edk2 #2791
Date: Tue, 11 Jul 2017 11:00:57 +0200 (CEST)

OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c: In function 
'InternalQemuFwCfgDmaBytes':
OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c:168:5: error: 'NumPages' may be 
used uninitialized in this function [-Werror=maybe-uninitialized]
 InternalQemuFwCfgSevDmaFreeBuffer (BounceBuffer, NumPages);
 ^~
cc1: all warnings being treated as errors
make: *** 
[Build/OvmfIa32/DEBUG_GCC49/IA32/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiLib/OUTPUT/QemuFwCfgLib.obj]
 Error 1
GNUmakefile:330: recipe for target 
'Build/OvmfIa32/DEBUG_GCC49/IA32/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiLib/OUTPUT/QemuFwCfgLib.obj'
 failed
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/1] OvmfPkg/PlatformPei: support >=1TB high RAM, and discontiguous high RAM

2017-07-11 Thread Laszlo Ersek 
On 07/11/17 10:38, Igor Mammedov wrote:
> On Tue, 11 Jul 2017 05:22:31 +0200
> Laszlo Ersek  wrote:
> 
>> In OVMF we currently get the upper (>=4GB) memory size with the
>> GetSystemMemorySizeAbove4gb() function.
>>
>> The GetSystemMemorySizeAbove4gb() function is used in two places:
>>
>> (1) It is the starting point of the calculations in GetFirstNonAddress().
>> GetFirstNonAddress() in turn
>> - determines the placement of the 64-bit PCI MMIO aperture,
> that's probably broken in memory hotplug case as
> the first usable PCI MMIO address is at fwcfg("etc/reserved-memory-end")

No, it's not broken :) I wrote above, "starting point of the
calculations". The fw_cfg file "etc/reserved-memory-end" is specifically
considered already. (You explained that file to me when I previously
worked on this code, in 2016Q1 or so.) It's just a later point in the
calculation.

> though the file exists only when memory hotplug is enabled
> ( to make life of FW writers harder :/ )

No problem, OVMF deals with "etc/reserved-memory-end" being either
present or absent.

Basically the GetFirstNonAddress() function performs a "cascade of
increases" upwards, for determining the highest address plus one (i.e.,
the first non-address).

If you'd like to see the full function (with this patch applied), it
starts at:

https://github.com/lersek/edk2/blob/highram1tb/OvmfPkg/PlatformPei/MemDetect.c#L292

It is heavily commented.

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

Re: [edk2] [PATCH 1/1] OvmfPkg/PlatformPei: support >=1TB high RAM, and discontiguous high RAM

2017-07-11 Thread Igor Mammedov 
On Tue, 11 Jul 2017 05:22:31 +0200
Laszlo Ersek  wrote:

> In OVMF we currently get the upper (>=4GB) memory size with the
> GetSystemMemorySizeAbove4gb() function.
> 
> The GetSystemMemorySizeAbove4gb() function is used in two places:
> 
> (1) It is the starting point of the calculations in GetFirstNonAddress().
> GetFirstNonAddress() in turn
> - determines the placement of the 64-bit PCI MMIO aperture,
that's probably broken in memory hotplug case as
the first usable PCI MMIO address is at fwcfg("etc/reserved-memory-end")

though the file exists only when memory hotplug is enabled
( to make life of FW writers harder :/ )

> - provides input for the GCD memory space map's sizing (see
>   AddressWidthInitialization(), and the CPU HOB in
>   MiscInitialization()),
> - influences the permanent PEI RAM cap (the DXE core's page tables,
>   built in permanent PEI RAM, grow as the RAM to map grows).
> 
> (2) In QemuInitializeRam(), GetSystemMemorySizeAbove4gb() determines the
> single memory descriptor HOB that we produce for the upper memory.
> 
> Respectively, there are two problems with GetSystemMemorySizeAbove4gb():
> 
> (1) It reads a 24-bit count of 64KB RAM chunks from the CMOS, and
> therefore cannot return a larger value than one terabyte.
> 
> (2) It cannot express discontiguous high RAM.
> 
> Starting with version 1.7.0, QEMU has provided the fw_cfg file called
> "etc/e820". Refer to the following QEMU commits:
> 
> - 0624c7f916b4 ("e820: pass high memory too.", 2013-10-10),
> - 7d67110f2d9a ("pc: add etc/e820 fw_cfg file", 2013-10-18)
> - 7db16f2480db ("pc: register e820 entries for ram", 2013-10-10)
> 
> Ever since these commits in v1.7.0 -- with the last QEMU release being
> v2.9.0, and v2.10.0 under development --, the only two RAM entries added
> to this E820 map correspond to the below-4GB RAM range, and the above-4GB
> RAM range. And, the above-4GB range exactly matches the CMOS registers in
> question; see the use of "pcms->above_4g_mem_size":
> 
>   pc_q35_init() | pc_init1()
> pc_memory_init()
>   e820_add_entry(0x1ULL, pcms->above_4g_mem_size, E820_RAM);
> pc_cmos_init()
>   val = pcms->above_4g_mem_size / 65536;
>   rtc_set_memory(s, 0x5b, val);
>   rtc_set_memory(s, 0x5c, val >> 8);
>   rtc_set_memory(s, 0x5d, val >> 16);
> 
> Therefore, remedy the above OVMF limitations as follows:
> 
> (1) Start off GetFirstNonAddress() by scanning the E820 map for the
> highest exclusive >=4GB RAM address. Fall back to the CMOS if the E820
> map is unavailable. Base all further calculations (such as 64-bit PCI
> MMIO aperture placement, GCD sizing etc) on this value.
> 
> At the moment, the only difference this change makes is that we can
> have more than 1TB above 4GB -- given that the sole "high RAM" entry
> in the E820 map matches the CMOS exactly, modulo the most significant
> bits (see above).
> 
> However, Igor plans to add discontiguous (cold-plugged) high RAM to
> the fw_cfg E820 RAM map later on, and then this scanning will adapt
> automatically.
> 
> (2) In QemuInitializeRam(), describe the high RAM regions from the E820
> map one by one with memory HOBs. Fall back to the CMOS only if the
> E820 map is missing.
> 
> Again, right now this change only makes a difference if there is at
> least 1TB high RAM. Later on it will adapt to discontiguous high RAM
> (regardless of its size) automatically.
> 
> -*-
> 
> Implementation details: introduce the E820HighRamIterate() function, which
> reads the E820 entries from fw_cfg, and calls the requested callback
> function on each high RAM entry found. The RAM map is not read in a single
> go, because its size can vary, and in PlatformPei we should stay away from
> dynamic memory allocation, for the following reasons:
> 
> - "Pool" allocations are limited to ~64KB, are served from HOBs, and
>   cannot be released ever.
> 
> - "Page" allocations are seriously limited before PlatformPei installs the
>   permanent PEI RAM. Furthermore, page allocations can only be released in
>   DXE, with dedicated code (so the address would have to be passed on with
>   a HOB or PCD).
> 
> - Raw memory allocation HOBs would require the same freeing in DXE.
> 
> Therefore we process each E820 entry as soon as it is read from fw_cfg.
> 
> -*-
> 
> Considering the impact of high RAM on the DXE core:
> 
> A few years ago, installing high RAM as *tested* would cause the DXE core
> to inhabit such ranges rather than carving out its home from the permanent
> PEI RAM. Fortunately, this was fixed in the following edk2 commit:
> 
>   3a05b13106d1, "MdeModulePkg DxeCore: Take the range in resource HOB for
> PHIT as higher priority", 2015-09-18
> 
> which I regression-tested at the time:
> 
>   http://mid.mail-archive.com/55FC27B0.4070807@redhat.com
> 
> Later on, OVMF was changed to install its high RAM as tested

Re: [edk2] [PATCH v8 00/16] x86: Secure Encrypted Virtualization (AMD)

2017-07-11 Thread Jordan Justen 
Pushed as c6ab9aecb71bcdb78cc1e13ba3f5a74bc895d4db.

Thanks for filing https://bugzilla.tianocore.org/show_bug.cgi?id=623
and continuing to work with Andrew and PIWG.

-Jordan

On 2017-07-06 07:29:38, Brijesh Singh wrote:
> The patch series provides support for AMD's new Secure Encrypted
> Virtualization (SEV) feature.
> 
> SEV is an extension to the AMD-V architecture which supports running
> multiple VMs under the control of a hypervisor. The SEV feature allows
> the memory contents of a virtual machine (VM) to be transparently encrypted
> with a key unique to the guest VM. The memory controller contains a
> high performance encryption engine which can be programmed with multiple
> keys for use by a different VMs in the system. The programming and
> management of these keys is handled by the AMD Secure Processor firmware
> which exposes a commands for these tasks.
> 
> SEV guest VMs have the concept of private and shared memory.  Private memory 
> is
> encrypted with the guest-specific key, while shared memory may be encrypted
> with hypervisor key.  Certain types of memory (namely instruction pages and
> guest page tables) are always treated as private memory by the hardware.
> For data memory, SEV guest VMs can choose which pages they would like to be
> private. The choice is done using the standard CPU page tables using the 
> C-bit,
> and is fully controlled by the guest. Due to security reasons all the DMA
> operations inside the  guest must be performed on shared pages (C-bit clear).
> Note that since C-bit is only controllable by the guest OS when it is 
> operating
> in 64-bit or 32-bit PAE mode, in all other modes the SEV hardware forces the
> C-bit to a 1.
> 
> The following links provide additional details:
> 
> AMD Memory Encryption whitepaper:
> http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
> 
> AMD64 Architecture Programmer's Manual:
> http://support.amd.com/TechDocs/24593.pdf
> SME is section 7.10
> SEV is section 15.34
> 
> Secure Encrypted Virutualization Key Management:
> http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf
> 
> KVM Forum Presentation:
> http://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf
> 
> [1] http://marc.info/?l=linux-mm=148846752931115=2
> 
> ---
> 
> Patch series is based on commit 60e85a39fe49 (BaseTools/GenFw: disregard 
> payload in PE debug directory entry size)
> 
> https://github.com/codomania/edk2/tree/v8
> 
> The patch series is tested with OvmfIa32.dsc, OvmfIa32X64.dsc and OvmfX64.dsc.
> Since memory encryption bit is not accessiable when processor is in 32-bit 
> mode
> hence any DMA access in this mode would cause assert. I have also tested the
> suspend and resume path, it seems to be working fine. I still need to work to
> finish adding the SEV Dma support in QemuFwCfgS3Lib package (see TODO).
> 
> Changes since v7:
>  - rebase to the latest
>  - drop cpuid patch (it's already merged)
> 
> Changes since v6:
>  - Keep Red Hat copright in PlatformHasIoMmuLib
>  - PageTable64.asm: Do not use stack operations (push and pop instruction)
> 
> Changes since v5:
>  - add placeholder gIoMmuAbsentProtocolGuid
>  - add PlatformHasIoMmuLib
>  - fix indentation
> 
> Changes since v4:
>  - decouple IoMmu protocol implementation from AmdSevDxe into a seperate
>IoMmuDxe driver. And introduce a placeholder protocol to provide the
>dependency support for the dependent modules.
>  - update debug messages to use gEfiCallerBaseName where applicable.
>  - fix QemuFwCfgSecLib build errors and simplify SEV support
>  - update QemuFwCfgDxeLib to assert when failed to locate IOMMU
>  - update comments "host buffer" to " host buffer"
> 
> Changes since v3:
>  - update AmdSevDxe driver to produce IOMMU protocol
>  - remove BmDmaLib dependency
>  - update QemuFwCfgLib to use IOMMU protocol to allocate SEV DMA buffer
> 
> Changes since v2:
>  - move memory encryption CPUID and MSR definition into UefiCpuPkg
>  - fix the argument order for SUB instruction in ResetVector and add more
>comments
>  - update PlatformPei to use BaseMemEncryptSevLib
>  - break the overlong comment lines to 79 chars
>  - variable aligment and other formating fixes
>  - split the SEV DMA support patch for QemuFwCfgLib into multiple patches as
>recommended by Laszlo
>  - add AmdSevDxe driver which runs very early in DXE phase and clear the C-bit
>from MMIO memory region
>  - drop 'QemuVideoDxe: Clear C-bit from framebuffer' patch since AmdSevDxe
>driver takes care of clearing the C-bit from MMIO region
>  - Verified that Qemu PFLASH works fine with SEV guest, Found a KVM driver 
> issue
>which was causing #PF when PFLASH was enabled. I have submitted patch to
>fix it in upstream http://marc.info/?l=kvm=149304930814202=2
> 
> Changes since v1:
>  - bug fixes in OvmfPkg/ResetVector (pointed by Tom Lendacky)
>  - add SEV CPUID

Re: [edk2] [Patch V2 0/2] Fix enable Smx/Vmx error.

2017-07-11 Thread Fan, Jeff 
Reviewed-by: Jeff Fan 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Eric Dong
Sent: Tuesday, July 11, 2017 10:19 AM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch V2 0/2] Fix enable Smx/Vmx error.

Patch also add error handling code when enable feature failed.

V2 changes:
  If can't enable the feature, then disable it. V1 patch missed it.

Eric Dong (2):
  UefiCpuPkg RegisterCpuFeaturesLib: Add error handling code.
  UefiCpuPkg CpuCommonFeaturesLib: Fix smx/vmx enable logic error.

 .../CpuCommonFeaturesLib/CpuCommonFeatures.h   |  47 +++--
 .../CpuCommonFeaturesLib/CpuCommonFeaturesLib.c|  19 +---
 .../Library/CpuCommonFeaturesLib/FeatureControl.c  | 106 - 
 .../RegisterCpuFeaturesLib/CpuFeaturesInitialize.c |  47 -
 4 files changed, 101 insertions(+), 118 deletions(-)

--
2.7.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