date:20151103

Re: [edk2] [Patch 08/11] MdeModulePkg: Add missing PrintLib to BdsDxe.inf

2015-11-03 Thread Wang, Sunny (HPS SW)

This patch looks good to me. 
Reviewed by: Sunny Wang 

Regards,
Sunny Wang

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu Ni
Sent: Monday, November 02, 2015 7:34 PM
To: edk2-devel@lists.01.org
Cc: Ruiyu Ni; Eric Dong
Subject: [edk2] [Patch 08/11] MdeModulePkg: Add missing PrintLib to BdsDxe.inf

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Eric Dong 
---
 MdeModulePkg/Universal/BdsDxe/BdsDxe.inf | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MdeModulePkg/Universal/BdsDxe/BdsDxe.inf 
b/MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
index 12d61e7..bdbc83e 100644
--- a/MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
+++ b/MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
@@ -58,6 +58,7 @@
   UefiBootManagerLib
   PlatformBootManagerLib
   PcdLib
+  PrintLib
 
 [Guids]
   gEfiGlobalVariableGuid## SOMETIMES_PRODUCES ## 
Variable:L"BootNext" (The number of next boot option)
-- 
1.9.5.msysgit.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 11/11] MdeModulePkg: Enable PlatformRecovery in BdsDxe driver

2015-11-03 Thread Wang, Sunny (HPS SW)

Hi Ray,
The places for launching PlatformRecovery options and boot menu option 
(for Successful boot) in this code change look good to me. I think this patch 
can solve problem I mentioned in our previous discussion for 
PlatformBootManagerDefaultBootFail related patch. Thanks for making this code 
change. 
In addition, I made four review comments in this patch. You can search 
"[Sunny]" to find my comments out.
 
Regards,
Sunny Wang

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu Ni
Sent: Monday, November 02, 2015 7:34 PM
To: edk2-devel@lists.01.org
Cc: Ruiyu Ni; Eric Dong
Subject: [edk2] [Patch 11/11] MdeModulePkg: Enable PlatformRecovery in BdsDxe 
driver

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Eric Dong 
---
 MdeModulePkg/Universal/BdsDxe/Bds.h  |   3 -
 MdeModulePkg/Universal/BdsDxe/BdsEntry.c | 405 ---
 2 files changed, 95 insertions(+), 313 deletions(-)

diff --git a/MdeModulePkg/Universal/BdsDxe/Bds.h 
b/MdeModulePkg/Universal/BdsDxe/Bds.h
index 2171d14..ac54482 100644
--- a/MdeModulePkg/Universal/BdsDxe/Bds.h
+++ b/MdeModulePkg/Universal/BdsDxe/Bds.h
@@ -24,9 +24,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
 
 #include   #include  diff 
--git a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c 
b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
index b632ada..05cdb73 100644
--- a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
+++ b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
@@ -51,10 +51,10 @@ CHAR16  *mReadOnlyVariables[] = {
 CHAR16 *mBdsLoadOptionName[] = {
   L"Driver",
   L"SysPrep",
-  L"Boot"
+  L"Boot",
+  L"PlatformRecovery"
 };
 
-CHAR16  mRecoveryBoot[] = L"Recovery Boot";
 /**
   Event to Connect ConIn.
 
@@ -122,187 +122,6 @@ BdsInitialize (
 }
 
 /**
-  Emuerate all possible bootable medias in the following order:
-  1. Removable BlockIo- The boot option only points to the 
removable media
-device, like USB key, DVD, Floppy etc.
-  2. Fixed BlockIo- The boot option only points to a Fixed 
blockIo device,
-like HardDisk.
-  3. Non-BlockIo SimpleFileSystem - The boot option points to a device 
supporting
-SimpleFileSystem Protocol, but not 
supporting BlockIo
-protocol.
-  4. LoadFile - The boot option points to the media 
supporting 
-LoadFile protocol.
-  Reference: UEFI Spec chapter 3.3 Boot Option Variables Default Boot Behavior
-
-  @param BootOptionCount   Return the boot option count which has been found.
-
-  @retval   Pointer to the boot option array.
-**/
-EFI_BOOT_MANAGER_LOAD_OPTION *
-BdsEnumerateBootOptions (
-  UINTN *BootOptionCount
-  )
-{
-  EFI_STATUSStatus;
-  EFI_BOOT_MANAGER_LOAD_OPTION  *BootOptions;
-  UINTN HandleCount;
-  EFI_HANDLE*Handles;
-  EFI_BLOCK_IO_PROTOCOL *BlkIo;
-  UINTN Removable;
-  UINTN Index;
-
-  ASSERT (BootOptionCount != NULL);
-
-  *BootOptionCount = 0;
-  BootOptions  = NULL;
-
-  //
-  // Parse removable block io followed by fixed block io
-  //
-  gBS->LocateHandleBuffer (
- ByProtocol,
- ,
- NULL,
- ,
- 
- );
-
-  for (Removable = 0; Removable < 2; Removable++) {
-for (Index = 0; Index < HandleCount; Index++) {
-  Status = gBS->HandleProtocol (
-  Handles[Index],
-  ,
-  (VOID **) 
-  );
-  if (EFI_ERROR (Status)) {
-continue;
-  }
-
-  //
-  // Skip the logical partitions
-  //
-  if (BlkIo->Media->LogicalPartition) {
-continue;
-  }
-
-  //
-  // Skip the fixed block io then the removable block io
-  //
-  if (BlkIo->Media->RemovableMedia == ((Removable == 0) ? FALSE : TRUE)) {
-continue;
-  }
-
-  BootOptions = ReallocatePool (
-  sizeof (EFI_BOOT_MANAGER_LOAD_OPTION) * 
(*BootOptionCount),
-  sizeof (EFI_BOOT_MANAGER_LOAD_OPTION) * 
(*BootOptionCount + 1),
-  BootOptions
-  );
-  ASSERT (BootOptions != NULL);
-
-  Status = EfiBootManagerInitializeLoadOption (
- [(*BootOptionCount)++],
- LoadOptionNumberUnassigned,
- LoadOptionTypeBoot,
- LOAD_OPTION_ACTIVE,
- mRecoveryBoot,
- DevicePathFromHandle (Handles[Index]),
-

Re: [edk2] PCI: "rejected due to resource confliction"

2015-11-03 Thread Laszlo Ersek

On 11/03/15 02:56, Ni, Ruiyu wrote:

> Shell doesn't depend on PciIo protocol to find all PCI devices.

I didn't know that, thank you for the info!
Laszlo

> 
> Thanks,
> Ray
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
> Ersek
> Sent: Tuesday, November 3, 2015 1:58 AM
> To: Leif Lindholm 
> Cc: edk2-devel@lists.01.org 
> Subject: Re: [edk2] PCI: "rejected due to resource confliction"
> 
> On 11/02/15 18:25, Leif Lindholm wrote:
>> Hi all,
>>
>> I am playing around with an off-the-shelf USB3 (XHCI) PCIe controller card.
>> On my Juno (r1) board, this works as expected.
>>
>> However, on another platform where I try it, I get an error message
>> during Bds init:
>> "PciBus: [01|00|00] was rejected due to resource confliction."
>>
>> The card is still discovered, and listed in the shell with the "pci" command.
>>
>> Before I try to learn the entire PCI subsystem from the code - Is
>> there anything obvious that could cause the above message?
>> (Yes, I know it's printed by PciHostBridgeAdjustAllocation(), but I
>> don't quite understand why.)
> 
> From a quick skim, my speculation is: the host bridge cannot satisfy all
> the resource requirements that the PCI devices pose *together*. In this
> case the maximum resource hog (= largest MMIO window I guess, for one of
> the PCI memory types) is identified, and rejected. The idea being (I
> guess!) that this should relieve resource pressure with the smallest
> number of "victim" PCI devices.
> 
> I don't know why the "PCI" command can still list the device as
> sucessfully enumerated.
> 
> As to why it works (without such a message) on the other platform, I
> think it depends on the host bridge / root bridge driver (which is
> platform-specific); in particular on the size(s) of the MMIO aperture(s)
> that the PCI Bus driver can allocate ranges out of, with the help of the
> host bridge / root bridge driver.
> 
> Also, on the failing (well, "complaining") platform, perhaps the device
> is plugged behind a PCI bridge, and that bridge could have more limited
> apertures than the root bridge (or perhaps that bridge is "overcrowded").
> 
> Again, just speculating. I *think* I've seen this error message while
> porting ArmVirtPkg/PciHostBridgeDxe, but I've forgotten the
> circumstances. (And I can't find the message in my email archives, or in
> the edk2 commit log.)
> 
> Can you post the PCI Bus driver's log (about the enumeration / resource
> allocation) in both cases?
> 
> Thanks
> Laszlo
> 
>>
>> Regards,
>>
>> Leif
>> ___
>> 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-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg: Fix memory leak issues

2015-11-03 Thread Wang, Sunny (HPS SW)

Hi Jordan, 
Yes, you are right! It could make commit message subject clearer. I saw 
the related information mentioned in 
https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format
This is my mistake. Thanks for the reminder. I will do that next time.

Regards,
Sunny Wang

-Original Message-
From: Jordan Justen [mailto:jordan.l.jus...@intel.com] 
Sent: Tuesday, November 03, 2015 3:57 PM
To: Wang, Sunny (HPS SW); Ni, Ruiyu
Cc: Tian, Feng; edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH] MdeModulePkg: Fix memory leak issues
Importance: High

Although this was already committed, I had one comment for the future.
In the patch commit message subject, I think you should have included 
UefiBootManagerLib.

MdeModulePkg UefiBootManagerLib: Fix memory leak issues

-Jordan

On 2015-11-02 02:56:14, Wang, Sunny (HPS SW) wrote:
> Hi Ray, 
> Good catch! Thanks. :)
> I updated patch for this. Please help to review it again.
> 
> Regards,
> Sunny Wang
> 
> -Original Message-
> From: Ni, Ruiyu [mailto:ruiyu...@intel.com]
> Sent: Saturday, October 31, 2015 6:59 AM
> To: Wang, Sunny (HPS SW)
> Cc: Tian, Feng; El-Haj-Mahmoud, Samer; edk2-devel@lists.01.org
> Subject: RE: [edk2] [PATCH] MdeModulePkg: Fix memory leak issues
> Importance: High
> 
> Sunny,
> You could move the two FreePool (FullInstance) to one place which is under 
> the LocateDevicePath() call to make the change smaller a bit.
> What do you think?
> 
> Thanks,
> Ray
> 
> -Original Message-
> From: Wang, Sunny (HPS SW) [mailto:sunnyw...@hpe.com]
> Sent: Friday, October 30, 2015 6:21 PM
> To: Ni, Ruiyu 
> Cc: Tian, Feng ; El-Haj-Mahmoud, Samer 
> ; Wang, Sunny (HPS SW) 
> ; edk2-devel@lists.01.org
> Subject: RE: [edk2] [PATCH] MdeModulePkg: Fix memory leak issues
> 
> Hi Ray,
> Are you the owner of this module (UefiBootManagerLib)? If so, could 
> you help to review and commit it?  If not, could you tell me who is the 
> owner? 
> In addition, the attached patch would also need your help to get 
> committed. Thanks!
> 
> Regards,
> Sunny Wang
> 
> -Original Message-
> From: Tian, Feng [mailto:feng.t...@intel.com]
> Sent: Thursday, October 29, 2015 8:21 AM
> To: El-Haj-Mahmoud, Samer; Wang, Sunny (HPS SW); 
> edk2-devel@lists.01.org
> Cc: Tian, Feng
> Subject: RE: [edk2] [PATCH] MdeModulePkg: Fix memory leak issues
> Importance: High
> 
> I will let module owner review and commit it.
> 
> Thanks
> Feng
> 
> -Original Message-
> From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hpe.com]
> Sent: Wednesday, October 28, 2015 22:58
> To: Wang, Sunny (HPS SW); edk2-devel@lists.01.org; Tian, Feng
> Subject: RE: [edk2] [PATCH] MdeModulePkg: Fix memory leak issues
> 
> + MdeModuklePkg maintainers.
> 
> Can someone help by committing this please?
> 
> 
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> El-Haj-Mahmoud, Samer
> Sent: Tuesday, October 27, 2015 10:14 AM
> To: Wang, Sunny (HPS SW) ; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH] MdeModulePkg: Fix memory leak issues
> 
> Reviewed-by: Samer El-Haj-Mahmoud 
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Wang, Sunny (HPS SW)
> Sent: Tuesday, October 27, 2015 3:47 AM
> To: edk2-devel@lists.01.org
> Cc: El-Haj-Mahmoud, Samer 
> Subject: [edk2] [PATCH] MdeModulePkg: Fix memory leak issues
> 
> Fix memory leak issues
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> 
> Signed-off-by: Sunny Wang 
> ---
>  MdeModulePkg/Library/UefiBootManagerLib/BmConsole.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmConsole.c 
> b/MdeModulePkg/Library/UefiBootManagerLib/BmConsole.c
> index 86b4fac..0830166 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmConsole.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmConsole.c
> @@ -2,6 +2,7 @@
>Library functions which contain all the code to connect console device.
>  
>  Copyright (c) 2011 - 2015, Intel Corporation. All rights 
> reserved.
> +(C) Copyright 2015 Hewlett Packard Enterprise Development LP
>  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 @@ -301,6 +302,7 
> @@ BmUpdateSystemTableConsole (
>EFI_DEVICE_PATH_PROTOCOL*FullDevicePath;
>EFI_DEVICE_PATH_PROTOCOL*VarConsole;
>EFI_DEVICE_PATH_PROTOCOL*Instance;
> +  EFI_DEVICE_PATH_PROTOCOL*FullInstance;
>VOID*Interface;
>EFI_HANDLE  NewHandle;
>

[edk2] [PATCH] NetworkPkg/HttpDxe: Missing CloseEvent() in HttpResponseWorker

2015-11-03 Thread Nagaraj Hegde

Two additional scenarios in which CloseEvent() needs to be called:

We sent a Request to HTTP server, following which we did a
Response() call, with the intent of capturing only the headers.
In this case, we execute an if condition in HttpResponseWorker do
a goto Exit. HttpDxe will cache the body that it received for which
we dint ask for right now. After we have received the headers, we
call a Response() again. Now, we get the data out of cache and
again do a goto Exit. In both cases, two CreateEvent() are called,
one on Event in RxToken in Wrap structure and another on Event in
RxToken in HttpInstance structure. In Exit label, we are missing
the CloseEvent() call for both the Events created.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Nagaraj Hegde 
---
 NetworkPkg/HttpDxe/HttpImpl.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c
index 3094400..0e7e60d 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.c
+++ b/NetworkPkg/HttpDxe/HttpImpl.c
@@ -1130,6 +1130,18 @@ Exit:
   }
   Token->Status = Status;
   gBS->SignalEvent (Token->Event);
+
+  if (Wrap != NULL) {
+if (Wrap->TcpWrap.RxToken.CompletionToken.Event != NULL) {
+  gBS->CloseEvent (Wrap->TcpWrap.RxToken.CompletionToken.Event);
+}
+  }
+
+  if (HttpInstance->RxToken.CompletionToken.Event != NULL) {
+gBS->CloseEvent (HttpInstance->RxToken.CompletionToken.Event);
+HttpInstance->RxToken.CompletionToken.Event = NULL;
+  }
+
   FreePool (Wrap);
   return Status;
 
-- 
2.6.2.windows.1

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

Re: [edk2] [Patch 09/11] MdeModulePkg: Use UefiSpec.h defined macro to replace L"xxx" string

2015-11-03 Thread Wang, Sunny (HPS SW)

Hi Ray,
This patch overall looks good to me. I just made a minor comment in 
this patch. You can search "[Sunny]" to find it out.

Regards,
Sunny Wang

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu Ni
Sent: Monday, November 02, 2015 7:34 PM
To: edk2-devel@lists.01.org
Cc: Ruiyu Ni; Eric Dong
Subject: [edk2] [Patch 09/11] MdeModulePkg: Use UefiSpec.h defined macro to 
replace L"xxx" string

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Eric Dong 
---
 MdeModulePkg/Universal/BdsDxe/BdsEntry.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c 
b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
index c889892..4154d41 100644
--- a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
+++ b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
@@ -672,7 +672,7 @@ BdsFormalizeOSIndicationVariable (
   //
   OsIndicationSupport = EFI_OS_INDICATIONS_BOOT_TO_FW_UI;
   Status = gRT->SetVariable (
-  L"OsIndicationsSupported",
+  EFI_OS_INDICATIONS_SUPPORT_VARIABLE_NAME,
   ,
   EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS,
   sizeof(UINT64),
@@ -694,7 +694,7 @@ BdsFormalizeOSIndicationVariable (
   Attributes = 0;
   DataSize = sizeof(UINT64);
   Status = gRT->GetVariable (
-  L"OsIndications",
+  EFI_OS_INDICATIONS_VARIABLE_NAME,
   ,
   ,
   ,
@@ -711,7 +711,7 @@ BdsFormalizeOSIndicationVariable (
 
 DEBUG ((EFI_D_ERROR, "[Bds] Unformalized OsIndications variable exists. 
Delete it\n"));
 Status = gRT->SetVariable (
-L"OsIndications",
+EFI_OS_INDICATIONS_VARIABLE_NAME,
 ,
 0,
 0,
@@ -737,9 +737,9 @@ BdsFormalizeEfiGlobalVariable (
   //
   // Validate Console variable.
   //
-  BdsFormalizeConsoleVariable (L"ConIn");
-  BdsFormalizeConsoleVariable (L"ConOut");
-  BdsFormalizeConsoleVariable (L"ErrOut");
+  BdsFormalizeConsoleVariable (EFI_CON_IN_VARIABLE_NAME);  
+ BdsFormalizeConsoleVariable (EFI_CON_OUT_VARIABLE_NAME);  
+ BdsFormalizeConsoleVariable (EFI_ERR_OUT_VARIABLE_NAME);
[Sunny] Are these two lines above having the wrong indent?  
 
   //
   // Validate OSIndication related variable.
@@ -1045,7 +1045,7 @@ BdsEntry (
   //
   DataSize = sizeof (UINT64);
   Status = gRT->GetVariable (
-  L"OsIndications",
+  EFI_OS_INDICATIONS_VARIABLE_NAME,
   ,
   NULL,
   ,
@@ -1062,7 +1062,7 @@ BdsEntry (
   if (BootFwUi) {
 OsIndication &= ~((UINT64) EFI_OS_INDICATIONS_BOOT_TO_FW_UI);
 Status = gRT->SetVariable (
-   L"OsIndications",
+   EFI_OS_INDICATIONS_VARIABLE_NAME,
,
EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS | 
EFI_VARIABLE_NON_VOLATILE,
sizeof(UINT64),
--
1.9.5.msysgit.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 1/2] ShellPkg/UefiDpLib: Fix a DP cumulative data issue

2015-11-03 Thread Carsey, Jaben


> -Original Message-
> From: Zeng, Star
> Sent: Monday, November 02, 2015 7:13 PM
> To: Carsey, Jaben ; Cinnamon Shia
> ; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH 1/2] ShellPkg/UefiDpLib: Fix a DP cumulative data
> issue
> Importance: High
> 
> On 2015/11/3 1:12, Carsey, Jaben wrote:
> > Reviewed-by: Jaben Carsey 
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> >> Cinnamon Shia
> >> Sent: Monday, November 02, 2015 1:12 AM
> >> To: edk2-devel@lists.01.org
> >> Subject: [edk2] [PATCH 1/2] ShellPkg/UefiDpLib: Fix a DP cumulative data
> >> issue
> >> Importance: High
> >>
> >> The value of PERF_CUM_DATA.Count and PERF_CUM_DATA.Duration field
> >> keep cumulating on every execution of dp.
> >> Initialize the CumData at dp's entry point.
> >>
> >> Signed-off-by: Cinnamon Shia 
> >> ---
> >>   ShellPkg/Library/UefiDpLib/Dp.c | 27 ++-
> >>   1 file changed, 26 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/ShellPkg/Library/UefiDpLib/Dp.c
> b/ShellPkg/Library/UefiDpLib/Dp.c
> >> index 8270172..62a4e7b 100644
> >> --- a/ShellPkg/Library/UefiDpLib/Dp.c
> >> +++ b/ShellPkg/Library/UefiDpLib/Dp.c
> 
> This patch is not needed for PerformancePkg\Dp_App as
> PerformancePkg\Dp_App is a standalone application.
> 
> Thanks,
> Star

Star,

This is for the DP library that allows the command to be built into the shell, 
not the application.  I am confused by your comment.

-Jaben

> 
> >> @@ -14,6 +14,7 @@
> >> timer information to calculate elapsed time for each measurement.
> >>
> >> Copyright (c) 2009 - 2013, Intel Corporation. All rights reserved.
> >> +  (C) Copyright 2015 Hewlett Packard Enterprise Development LP
> >> 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
> >> @@ -110,7 +111,26 @@ DumpStatistics( void )
> >> SHELL_FREE_NON_NULL (StringPtrUnknown);
> >>   }
> >>
> >> -/**
> >> +/**
> >> +  Initialize the cumulative data.
> >> +
> >> +**/
> >> +VOID
> >> +InitCumulativeData (
> >> +  VOID
> >> +  )
> >> +{
> >> +  UINTN Index;
> >> +
> >> +  for (Index = 0; Index < NumCum; ++Index) {
> >> +CumData[Index].Count = 0;
> >> +CumData[Index].MinDur = PERF_MAXDUR;
> >> +CumData[Index].MaxDur = 0;
> >> +CumData[Index].Duration = 0;
> >> +  }
> >> +}
> >> +
> >> +/**
> >> Dump performance data.
> >>
> >> @param[in]  ImageHandle The image handle.
> >> @@ -219,6 +239,11 @@ ShellCommandRunDp (
> >> }
> >>
> >> //
> >> +  // Initialize the pre-defined cumulative data.
> >> +  //
> >> +  InitCumulativeData ();
> >> +
> >> +  //
> >> // Timer specific processing
> >> //
> >> // Get the Performance counter characteristics:
> >> --
> >> 1.9.5.msysgit.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] ShellPkg UefiDpLib: Use correct string length for the input UnicodeBuffer

2015-11-03 Thread Carsey, Jaben

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Zeng, Star
> Sent: Monday, November 02, 2015 8:02 PM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben 
> Subject: [PATCH] ShellPkg UefiDpLib: Use correct string length for the input
> UnicodeBuffer
> Importance: High
> 
> Same as the beginning of function to use DP_GAUGE_STRING_LENGTH, but not
> DXE_PERFORMANCE_STRING_LENGTH.
> 
> Cc: Jaben Carsey 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng 
> ---
>  ShellPkg/Library/UefiDpLib/DpUtilities.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiDpLib/DpUtilities.c
> b/ShellPkg/Library/UefiDpLib/DpUtilities.c
> index 5237459..e9d8fb3 100644
> --- a/ShellPkg/Library/UefiDpLib/DpUtilities.c
> +++ b/ShellPkg/Library/UefiDpLib/DpUtilities.c
> @@ -164,8 +164,8 @@ DpGetShortPdbFileName (
>  for (IndexA = StartIndex; IndexA < EndIndex; IndexA++) {
>UnicodeBuffer[IndexU] = (CHAR16) PdbFileName[IndexA];
>IndexU++;
> -  if (IndexU >= DXE_PERFORMANCE_STRING_LENGTH) {
> -UnicodeBuffer[DXE_PERFORMANCE_STRING_LENGTH] = 0;
> +  if (IndexU >= DP_GAUGE_STRING_LENGTH) {
> +UnicodeBuffer[DP_GAUGE_STRING_LENGTH] = 0;
>  break;
>}
>  }
> --
> 1.9.5.msysgit.0

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

Re: [edk2] [PATCH 03/10] ArmPkg/ArmLib: remove unused ARM9 support

2015-11-03 Thread Ard Biesheuvel

On 3 November 2015 at 12:56, Leif Lindholm  wrote:
> On Tue, Nov 03, 2015 at 11:16:28AM +0100, Ard Biesheuvel wrote:
>> The ARM9 ArmLib implementation is not referenced anywhere in the
>> tree, and unlikely to be useful going forward, considering that
>> ARM9 outdates even ARMv6. So remove it.
>
> While I agree in principle, I don't think we can safely make too many
> assumptions here - we know the majority of 32-bit ARM UEFI platforms
> are out of tree.
>
> Can we break this out from the current set and keep as a separate
> discussion, giving people a few weeks to respond?
>

Sure.

I don't think it makes sense to fix this code in the same way as I fix
the other versions in this series.
(Note that the ARM9 code does not even get built if you build
ArmPkg/ArmPkg.dsc in isolation)

-- 
Ard.


>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  ArmPkg/Library/ArmLib/Arm9/Arm9ArmLib.inf |  43 -
>>  ArmPkg/Library/ArmLib/Arm9/Arm9ArmLibPrePi.inf|  43 -
>>  ArmPkg/Library/ArmLib/Arm9/Arm9CacheInformation.c | 165 
>>  ArmPkg/Library/ArmLib/Arm9/Arm9Lib.c  | 134 
>>  ArmPkg/Library/ArmLib/Arm9/Arm9Support.S  | 153 --
>>  ArmPkg/Library/ArmLib/Arm9/Arm9Support.asm| 153 --
>>  6 files changed, 691 deletions(-)
>>
>> diff --git a/ArmPkg/Library/ArmLib/Arm9/Arm9ArmLib.inf 
>> b/ArmPkg/Library/ArmLib/Arm9/Arm9ArmLib.inf
>> deleted file mode 100644
>> index e8aa056fbfea..
>> --- a/ArmPkg/Library/ArmLib/Arm9/Arm9ArmLib.inf
>> +++ /dev/null
>> @@ -1,43 +0,0 @@
>> -#/** @file
>> -# Semihosting  serail port lib
>> -#
>> -# Copyright (c) 2008 - 2010, Apple Inc. All rights reserved.
>> -#
>> -#  This program and the accompanying materials
>> -#  are licensed and made available under the terms and conditions of the 
>> BSD License
>> -#  which accompanies this distribution. The full text of the license may be 
>> found at
>> -#  http://opensource.org/licenses/bsd-license.php
>> -#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
>> -#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
>> IMPLIED.
>> -#
>> -#
>> -#**/
>> -
>> -[Defines]
>> -  INF_VERSION= 0x00010005
>> -  BASE_NAME  = Arm9ArmLib
>> -  FILE_GUID  = 375D70D3-91E0-4374-A540-68BD959EB184
>> -  MODULE_TYPE= DXE_DRIVER
>> -  VERSION_STRING = 1.0
>> -  LIBRARY_CLASS  = ArmLib
>> -
>> -[Sources.common]
>> -  ../Common/Arm/ArmLibSupport.S| GCC
>> -  ../Common/Arm/ArmLibSupport.asm  | RVCT
>> -  ../Common/ArmLib.c
>> -
>> -  Arm9Support.S| GCC
>> -  Arm9Support.asm  | RVCT
>> -
>> -  Arm9Lib.c
>> -  Arm9CacheInformation.c
>> -
>> -[Packages]
>> -  ArmPkg/ArmPkg.dec
>> -  MdePkg/MdePkg.dec
>> -
>> -[LibraryClasses]
>> -  MemoryAllocationLib
>> -
>> -[Protocols]
>> -  gEfiCpuArchProtocolGuid
>> diff --git a/ArmPkg/Library/ArmLib/Arm9/Arm9ArmLibPrePi.inf 
>> b/ArmPkg/Library/ArmLib/Arm9/Arm9ArmLibPrePi.inf
>> deleted file mode 100644
>> index 556e3dc5ab2a..
>> --- a/ArmPkg/Library/ArmLib/Arm9/Arm9ArmLibPrePi.inf
>> +++ /dev/null
>> @@ -1,43 +0,0 @@
>> -#/** @file
>> -# Semihosting  serail port lib
>> -#
>> -# Copyright (c) 2008 - 2010, Apple Inc. All rights reserved.
>> -#
>> -#  This program and the accompanying materials
>> -#  are licensed and made available under the terms and conditions of the 
>> BSD License
>> -#  which accompanies this distribution. The full text of the license may be 
>> found at
>> -#  http://opensource.org/licenses/bsd-license.php
>> -#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
>> -#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
>> IMPLIED.
>> -#
>> -#
>> -#**/
>> -
>> -[Defines]
>> -  INF_VERSION= 0x00010005
>> -  BASE_NAME  = Arm9ArmLibPrePi
>> -  FILE_GUID  = e9b6011f-ee15-4e59-ab8f-a819a081fa54
>> -  MODULE_TYPE= DXE_DRIVER
>> -  VERSION_STRING = 1.0
>> -  LIBRARY_CLASS  = ArmLib
>> -
>> -[Sources.common]
>> -  ../Common/Arm/ArmLibSupport.S| GCC
>> -  ../Common/Arm/ArmLibSupport.asm  | RVCT
>> -  ../Common/ArmLib.c
>> -
>> -  Arm9Support.S| GCC
>> -  Arm9Support.asm  | RVCT
>> -
>> -  Arm9Lib.c
>> -  Arm9CacheInformation.c
>> -
>> -[Packages]
>> -  ArmPkg/ArmPkg.dec
>> -  MdePkg/MdePkg.dec
>> -
>> -[LibraryClasses]
>> -  PrePiLib
>> -
>> -[Protocols]
>> -  gEfiCpuArchProtocolGuid
>> diff --git a/ArmPkg/Library/ArmLib/Arm9/Arm9CacheInformation.c 
>> b/ArmPkg/Library/ArmLib/Arm9/Arm9CacheInformation.c
>> deleted file mode 100644
>> index f0b5060249fe..
>> --- a/ArmPkg/Library/ArmLib/Arm9/Arm9CacheInformation.c
>> +++ /dev/null
>> @@ -1,165 +0,0 @@
>> -/** @file

Re: [edk2] [PATCH 2/2] ShellPkg/UefiDpLib: Support dumping cumulative data

2015-11-03 Thread Shia, Cinnamon

Stat,

Thanks for your feedback and review.
Will submit the v2 patch for addressing your comments.
And submit another patch for PerformancePkg\Dp_App

Thanks,
Cinnamon Shia

-Original Message-
From: Zeng, Star [mailto:star.z...@intel.com] 
Sent: Tuesday, November 3, 2015 11:16 AM
To: Shia, Cinnamon; edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH 2/2] ShellPkg/UefiDpLib: Support dumping cumulative 
data

On 2015/11/2 17:11, Cinnamon Shia wrote:
> Add a new option -c to dump cumulative data.
> For example:
> shell> dp -c
> ==[ Cumulative ]
> (Times in microsec.) Cumulative   Average ShortestLongest
> Name  CountDurationDurationDurationDuration
> LoadImage: 200 1007000   0  10
> StartImage:2002000   9   0 700
>DB:Start:2002000  10   0 900
> DB:Support: 20  10   0   07000
>
> shell> dp -c DXE
> ==[ Cumulative ]
> (Times in microsec.) Cumulative   Average ShortestLongest
> Name  CountDurationDurationDurationDuration
> LoadImage: 200 1007000   0  10
> StartImage:2002000   9   0 700
>DB:Start:2002000  10   0 900
> DB:Support: 20  10   0   07000
>  DXE  130003000   03000
>
> Signed-off-by: Cinnamon Shia 
> ---
>   ShellPkg/Library/UefiDpLib/Dp.c  |  33 +--
>   ShellPkg/Library/UefiDpLib/DpInternal.h  |   9 +++--
>   ShellPkg/Library/UefiDpLib/DpTrace.c |  55 
> ---
>   ShellPkg/Library/UefiDpLib/UefiDpLib.uni | Bin 17466 -> 18146 bytes
>   4 files changed, 87 insertions(+), 10 deletions(-)

Could the "HP_ISS" be removed from the patch?
Could you help sync the change to PerformancePkg\Dp_App?

Thanks,
Star

>
> diff --git a/ShellPkg/Library/UefiDpLib/Dp.c 
> b/ShellPkg/Library/UefiDpLib/Dp.c index 62a4e7b..4d109d0 100644
> --- a/ShellPkg/Library/UefiDpLib/Dp.c
> +++ b/ShellPkg/Library/UefiDpLib/Dp.c
> @@ -79,6 +79,7 @@ STATIC CONST SHELL_PARAM_ITEM ParamList[] = {
>   #endif // PROFILING_IMPLEMENTED
> {L"-x", TypeFlag},   // -x   eXclude Cumulative Items
> {L"-i", TypeFlag},   // -i   Display Identifier
> +  {L"-c", TypeValue},  // -c   Display cumulative data.
> {L"-n", TypeValue},  // -n # Number of records to display for A and R
> {L"-t", TypeValue},  // -t # Threshold of interest
> {NULL, TypeMax}
> @@ -164,6 +165,9 @@ ShellCommandRunDp (
> BOOLEAN   TraceMode;
> BOOLEAN   ProfileMode;
> BOOLEAN   ExcludeMode;
> +  BOOLEAN   CumulativeMode;
> +  CONST CHAR16  *CustomCumulativeToken;
> +  PERF_CUM_DATA *CustomCumulativeData;
>
> StringPtr   = NULL;
> SummaryMode = FALSE;
> @@ -173,6 +177,8 @@ ShellCommandRunDp (
> TraceMode   = FALSE;
> ProfileMode = FALSE;
> ExcludeMode = FALSE;
> +  CumulativeMode = FALSE;
> +  CustomCumulativeData = NULL;
>
> // Get DP's entry time as soon as possible.
> // This is used as the Shell-Phase end time.
> @@ -210,6 +216,7 @@ ShellCommandRunDp (
>   #endif  // PROFILING_IMPLEMENTED
> ExcludeMode = ShellCommandLineGetFlag (ParamPackage, L"-x");
> mShowId = ShellCommandLineGetFlag (ParamPackage, L"-i");
> +  CumulativeMode = ShellCommandLineGetFlag (ParamPackage, L"-c");
>
> // Options with Values
> CmdLineArg  = ShellCommandLineGetValue (ParamPackage, L"-n"); @@ 
> -244,6 +251,20 @@ ShellCommandRunDp (
> InitCumulativeData ();
>
> //
> +  // Init the custom cumulative data.
> +  //
> +  CustomCumulativeToken = ShellCommandLineGetValue (ParamPackage, 
> + L"-c");  if (CustomCumulativeToken != NULL) {
> +CustomCumulativeData = AllocateZeroPool (sizeof (PERF_CUM_DATA));
> +CustomCumulativeData->MinDur = 0;
> +CustomCumulativeData->MaxDur = 0;
> +CustomCumulativeData->Count  = 0;
> +CustomCumulativeData->Duration = 0;
> +CustomCumulativeData->Name   = AllocateZeroPool (StrLen 
> (CustomCumulativeToken) + 1);
> +UnicodeStrToAsciiStr (CustomCumulativeToken, 
> + CustomCumulativeData->Name);  }
> +
> +  //
> // Timer specific processing
> //
> // Get the Performance counter characteristics:
> @@ -302,8 +323,10 @@ ShellCommandRunDp (
>   !T &&  P  := (2) Only Profile records are displayed
>    T &&  P  := (3) Same as Default, both are displayed
>   
> **
> **/
> -  GatherStatistics();
> -  if (AllMode) {
> +  GatherStatistics (CustomCumulativeData);  if (CumulativeMode) {
> +ProcessCumulative (CustomCumulativeData);  } else if

[edk2] [PATCH v2 2/2] ShellPkg/UefiDpLib: Support dumping cumulative data

2015-11-03 Thread Cinnamon Shia

Add a new option -c to dump cumulative data.
For example:
shell> dp -c
==[ Cumulative ]
(Times in microsec.) Cumulative   Average ShortestLongest
   Name  CountDurationDurationDurationDuration
LoadImage: 200 1007000   0  10
StartImage:2002000   9   0 700
  DB:Start:2002000  10   0 900
DB:Support: 20  10   0   07000

shell> dp -c DXE
==[ Cumulative ]
(Times in microsec.) Cumulative   Average ShortestLongest
   Name  CountDurationDurationDurationDuration
LoadImage: 200 1007000   0  10
StartImage:2002000   9   0 700
  DB:Start:2002000  10   0 900
DB:Support: 20  10   0   07000
DXE  130003000   03000

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia 
---
 ShellPkg/Library/UefiDpLib/Dp.c  |  33 +--
 ShellPkg/Library/UefiDpLib/DpInternal.h  |   9 +++--
 ShellPkg/Library/UefiDpLib/DpTrace.c |  55 ---
 ShellPkg/Library/UefiDpLib/UefiDpLib.uni | Bin 17466 -> 18146 bytes
 4 files changed, 87 insertions(+), 10 deletions(-)

diff --git a/ShellPkg/Library/UefiDpLib/Dp.c b/ShellPkg/Library/UefiDpLib/Dp.c
index 62a4e7b..4d109d0 100644
--- a/ShellPkg/Library/UefiDpLib/Dp.c
+++ b/ShellPkg/Library/UefiDpLib/Dp.c
@@ -79,6 +79,7 @@ STATIC CONST SHELL_PARAM_ITEM ParamList[] = {
 #endif // PROFILING_IMPLEMENTED
   {L"-x", TypeFlag},   // -x   eXclude Cumulative Items
   {L"-i", TypeFlag},   // -i   Display Identifier
+  {L"-c", TypeValue},  // -c   Display cumulative data.
   {L"-n", TypeValue},  // -n # Number of records to display for A and R
   {L"-t", TypeValue},  // -t # Threshold of interest
   {NULL, TypeMax}
@@ -164,6 +165,9 @@ ShellCommandRunDp (
   BOOLEAN   TraceMode;
   BOOLEAN   ProfileMode;
   BOOLEAN   ExcludeMode;
+  BOOLEAN   CumulativeMode;
+  CONST CHAR16  *CustomCumulativeToken;
+  PERF_CUM_DATA *CustomCumulativeData;
 
   StringPtr   = NULL;
   SummaryMode = FALSE;
@@ -173,6 +177,8 @@ ShellCommandRunDp (
   TraceMode   = FALSE;
   ProfileMode = FALSE;
   ExcludeMode = FALSE;
+  CumulativeMode = FALSE;
+  CustomCumulativeData = NULL;
 
   // Get DP's entry time as soon as possible.
   // This is used as the Shell-Phase end time.
@@ -210,6 +216,7 @@ ShellCommandRunDp (
 #endif  // PROFILING_IMPLEMENTED
   ExcludeMode = ShellCommandLineGetFlag (ParamPackage, L"-x");
   mShowId = ShellCommandLineGetFlag (ParamPackage, L"-i");
+  CumulativeMode = ShellCommandLineGetFlag (ParamPackage, L"-c");
 
   // Options with Values
   CmdLineArg  = ShellCommandLineGetValue (ParamPackage, L"-n");
@@ -244,6 +251,20 @@ ShellCommandRunDp (
   InitCumulativeData ();
 
   //
+  // Init the custom cumulative data.
+  //
+  CustomCumulativeToken = ShellCommandLineGetValue (ParamPackage, L"-c");
+  if (CustomCumulativeToken != NULL) {
+CustomCumulativeData = AllocateZeroPool (sizeof (PERF_CUM_DATA));
+CustomCumulativeData->MinDur = 0;
+CustomCumulativeData->MaxDur = 0;
+CustomCumulativeData->Count  = 0;
+CustomCumulativeData->Duration = 0;
+CustomCumulativeData->Name   = AllocateZeroPool (StrLen 
(CustomCumulativeToken) + 1);
+UnicodeStrToAsciiStr (CustomCumulativeToken, CustomCumulativeData->Name);
+  }
+
+  //
   // Timer specific processing
   //
   // Get the Performance counter characteristics:
@@ -302,8 +323,10 @@ ShellCommandRunDp (
 !T &&  P  := (2) Only Profile records are displayed
  T &&  P  := (3) Same as Default, both are displayed
 /
-  GatherStatistics();
-  if (AllMode) {
+  GatherStatistics (CustomCumulativeData);
+  if (CumulativeMode) {   
+ProcessCumulative (CustomCumulativeData);
+  } else if (AllMode) {
 if (TraceMode) {
   DumpAllTrace( Number2Display, ExcludeMode);
 }
@@ -326,7 +349,7 @@ ShellCommandRunDp (
 if ( ! EFI_ERROR( Status)) {
   ProcessPeims ();
   ProcessGlobal ();
-  ProcessCumulative ();
+  ProcessCumulative (NULL);
 }
   }
 }
@@ -339,6 +362,10 @@ ShellCommandRunDp (
   }
 
   SHELL_FREE_NON_NULL (StringPtr);
+  if (CustomCumulativeData != NULL) {
+SHELL_FREE_NON_NULL (CustomCumulativeData->Name);
+  }
+  SHELL_FREE_NON_NULL (CustomCumulativeData);
 
   return SHELL_SUCCESS;
 }
diff --git a/ShellPkg/Library/UefiDpLib/DpInternal.h 
b/ShellPkg/Library/UefiDpLib/DpInternal.h
index 9b8163a..b51f0d8 100644
---

Re: [edk2] [PATCH v3] ArmPlatformPkg/ArmJunoPkg: Add the correct SPI interrupt numbers for the MSI range

2015-11-03 Thread Ryan Harkin

Thanks Jeremy.

On 2 November 2015 at 20:54, Jeremy Linton  wrote:
> The JunoR1 has a GICv2m which is a GICv2 with a little piece of hardware
> that has some memory mapped locations that can trigger traditional SPI
> interrupts. This allows some basic PCIe MSI capabilities.
>
> Setup the SPI range that is mapped by the MSI window. This range is described
> in the JunoR1 SoC TRM, table 3-3. Under Interrupt ID 244-351 is described as
> "GICv2m PCI Express MSI". In the future when these tables are generated
> programmatically the information may be found in the MSI_TYPER register as 
> well.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeremy Linton 
Reviewed-by: Ryan Harkin 

> ---
>  ArmPlatformPkg/ArmJunoPkg/AcpiTables/Madt.aslc  | 4 +++-
>  ArmPlatformPkg/ArmJunoPkg/Include/ArmPlatform.h | 5 +
>  2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/ArmPlatformPkg/ArmJunoPkg/AcpiTables/Madt.aslc 
> b/ArmPlatformPkg/ArmJunoPkg/AcpiTables/Madt.aslc
> index d63a19b..f7e4e52 100644
> --- a/ArmPlatformPkg/ArmJunoPkg/AcpiTables/Madt.aslc
> +++ b/ArmPlatformPkg/ArmJunoPkg/AcpiTables/Madt.aslc
> @@ -117,9 +117,11 @@
>EFI_ACPI_5_1_GICC_STRUCTURE_INIT( // A57-1
>1, 5, GET_MPID(0, 1),  EFI_ACPI_5_0_GIC_ENABLED, 38, FixedPcdGet32 
> (PcdGicInterruptInterfaceBase),
>0x2C06F000, 0x2C04F000, 25, 0 /* GicRBase */),
> +
>  },
>  EFI_ACPI_5_0_GIC_DISTRIBUTOR_INIT(0, FixedPcdGet32 
> (PcdGicDistributorBase), 0),
> -EFI_ACPI_6_0_GIC_MSI_FRAME_INIT(0, ARM_JUNO_GIV2M_MSI_BASE, 0, 0, 0)
> +// Format: EFI_ACPI_6_0_GIC_MSI_FRAME_INIT(GicMsiFrameId, 
> PhysicalBaseAddress, Flags, SPICount, SPIBase)
> +EFI_ACPI_6_0_GIC_MSI_FRAME_INIT(0, ARM_JUNO_GIV2M_MSI_BASE, 0, 
> ARM_JUNO_GIV2M_MSI_SPI_COUNT, ARM_JUNO_GIV2M_MSI_SPI_BASE)
>};
>  #endif
>
> diff --git a/ArmPlatformPkg/ArmJunoPkg/Include/ArmPlatform.h 
> b/ArmPlatformPkg/ArmJunoPkg/Include/ArmPlatform.h
> index 9928c5a..d01d136 100644
> --- a/ArmPlatformPkg/ArmJunoPkg/Include/ArmPlatform.h
> +++ b/ArmPlatformPkg/ArmJunoPkg/Include/ArmPlatform.h
> @@ -40,9 +40,14 @@
>  #define ARM_JUNO_PERIPHERALS_BASE 0x2000
>  #define ARM_JUNO_PERIPHERALS_SZ   0x0E00
>
> +// PCIe MSI address window
>  #define ARM_JUNO_GIV2M_MSI_BASE   0x2c1c
>  #define ARM_JUNO_GIV2M_MSI_SZ SIZE_256KB
>
> +// PCIe MSI to SPI mapping range
> +#define ARM_JUNO_GIV2M_MSI_SPI_BASE   224
> +#define ARM_JUNO_GIV2M_MSI_SPI_COUNT  127 //TRM says last SPI is 
> 351, 351-224=127
> +
>  // On-Chip non-secure SRAM
>  #define ARM_JUNO_NON_SECURE_SRAM_BASE 0x2E00
>  #define ARM_JUNO_NON_SECURE_SRAM_SZ   SIZE_16MB
> --
> 2.4.3
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 04/10] ArmPkg/ArmLib: remove unused ArmCleanDataCacheToPoU()

2015-11-03 Thread Mark Rutland

On Tue, Nov 03, 2015 at 11:16:29AM +0100, Ard Biesheuvel wrote:
> The function ArmCleanDataCacheToPoU() has no users, and its purpose
> is unclear, since it uses cache maintenance by set/way to perform
> the clean to PoU, which is a dubious practice to begin with. So
> remove the declaration and all definitions.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 

Acked-by: Mark Rutland 

Mark.

> ---
>  ArmPkg/Include/Library/ArmLib.h|  6 ---
>  ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c | 30 
>  ArmPkg/Library/ArmLib/AArch64/AArch64Lib.h |  6 ---
>  ArmPkg/Library/ArmLib/AArch64/AArch64Support.S | 14 --
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.c | 30 
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.h |  6 ---
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S | 50 
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.asm   | 50 
>  8 files changed, 192 deletions(-)
> 
> diff --git a/ArmPkg/Include/Library/ArmLib.h b/ArmPkg/Include/Library/ArmLib.h
> index 58116663b28d..f1de303d952d 100644
> --- a/ArmPkg/Include/Library/ArmLib.h
> +++ b/ArmPkg/Include/Library/ArmLib.h
> @@ -243,12 +243,6 @@ ArmCleanDataCache (
>  
>  VOID
>  EFIAPI
> -ArmCleanDataCacheToPoU (
> -  VOID
> -  );
> -
> -VOID
> -EFIAPI
>  ArmInvalidateInstructionCache (
>VOID
>);
> diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c 
> b/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c
> index a4e1f20ad910..f795a2f896b2 100644
> --- a/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c
> +++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c
> @@ -206,26 +206,6 @@ AArch64DataCacheOperation (
>}
>  }
>  
> -
> -VOID
> -AArch64PoUDataCacheOperation (
> -  IN  AARCH64_CACHE_OPERATION  DataCacheOperation
> -  )
> -{
> -  UINTN SavedInterruptState;
> -
> -  SavedInterruptState = ArmGetInterruptState ();
> -  ArmDisableInterrupts ();
> -
> -  AArch64PerformPoUDataCacheOperation (DataCacheOperation);
> -
> -  ArmDrainWriteBuffer ();
> -
> -  if (SavedInterruptState) {
> -ArmEnableInterrupts ();
> -  }
> -}
> -
>  VOID
>  EFIAPI
>  ArmInvalidateDataCache (
> @@ -255,13 +235,3 @@ ArmCleanDataCache (
>ArmDrainWriteBuffer ();
>AArch64DataCacheOperation (ArmCleanDataCacheEntryBySetWay);
>  }
> -
> -VOID
> -EFIAPI
> -ArmCleanDataCacheToPoU (
> -  VOID
> -  )
> -{
> -  ArmDrainWriteBuffer ();
> -  AArch64PoUDataCacheOperation (ArmCleanDataCacheEntryBySetWay);
> -}
> diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.h 
> b/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.h
> index c8bb84365bb6..7b9b9c371531 100644
> --- a/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.h
> +++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.h
> @@ -18,12 +18,6 @@
>  
>  typedef VOID (*AARCH64_CACHE_OPERATION)(UINTN);
>  
> -
> -VOID
> -AArch64PerformPoUDataCacheOperation (
> -  IN  AARCH64_CACHE_OPERATION  DataCacheOperation
> -  );
> -
>  VOID
>  AArch64AllDataCachesOperation (
>IN  AARCH64_CACHE_OPERATION  DataCacheOperation
> diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S 
> b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
> index 8b5e0fb6e7fe..f973a35c21d6 100644
> --- a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
> +++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
> @@ -40,7 +40,6 @@ GCC_ASM_EXPORT (ArmEnableAlignmentCheck)
>  GCC_ASM_EXPORT (ArmEnableBranchPrediction)
>  GCC_ASM_EXPORT (ArmDisableBranchPrediction)
>  GCC_ASM_EXPORT (AArch64AllDataCachesOperation)
> -GCC_ASM_EXPORT (AArch64PerformPoUDataCacheOperation)
>  GCC_ASM_EXPORT (ArmDataMemoryBarrier)
>  GCC_ASM_EXPORT (ArmDataSynchronizationBarrier)
>  GCC_ASM_EXPORT (ArmInstructionSynchronizationBarrier)
> @@ -324,19 +323,6 @@ ASM_PFX(AArch64AllDataCachesOperation):
>  // right to ease the access to CSSELR and 
> the Set/Way operation.
>cbz   x3, L_Finished  // No need to clean if LoC is 0
>mov   x10, #0 // Start clean at cache level 0
> -  b Loop1
> -
> -ASM_PFX(AArch64PerformPoUDataCacheOperation):
> -// We can use regs 0-7 and 9-15 without having to save/restore.
> -// Save our link register on the stack. - The stack must always be quad-word 
> aligned
> -  str   x30, [sp, #-16]!
> -  mov   x1, x0  // Save Function call in x1
> -  mrs   x6, clidr_el1   // Read EL1 CLIDR
> -  and   x3, x6, #0x3800 // Mask out all but Point of Unification 
> (PoU)
> -  lsr   x3, x3, #26 // Left align cache level value - the level 
> is shifted by 1 to the
> -// right to ease the access to CSSELR and 
> the Set/Way operation.
> -  cbz   x3, L_Finished  // No need to clean if LoC is 0
> -  mov   x10, #0 // Start clean at cache level 0
>  
>  Loop1:
>add   x2, x10, x10, lsr #1// Work out 3x cachelevel for cache info
> diff --git

Re: [edk2] [Patch] MdeModulePkg: Fix a PciBusDxe hot plug bug

2015-11-03 Thread Leif Lindholm

Hi guys,

I never saw a response to this feedback I sent on the revised patch
set, but I see it has now been committed.
Could you let me know why my feedback was ignored?

Regards,

Leif

On 30 October 2015 at 18:02, Leif Lindholm  wrote:
> Hi Ray,
>
> Many thanks for this.
>
> On Fri, Oct 30, 2015 at 04:53:54AM +, Ni, Ruiyu wrote:
>> Ok I will revert the two patches I committed (big patch + small
>> patch). But I want to clarify one thing that not every big patch can
>> be easily understood by just splitting to small patches.
>
> Certainly, but it is always helpful to split as much as is possible.
> The shorter a patch is to review, the more likely reviewers are to
> spot mistakes - especially when reviewing code they are not already
> very familiar with.
>
> As an example, I have split your set up a little bit further by
> breaking 2/3 into two separate patches.
> https://git.linaro.org/people/leif.lindholm/edk2.git/shortlog/refs/heads/ray-pci
>
> I have also tried to remove modifications completely unrelated to this
> fix - resulting in a difference between the tree with your current
> patch set and my variant as included below. The changes in your set
> are all valid changes, but they are not related to the fix.
>
> The method behind all of this madness is to make the output of "git
> blame" as relevant as possible, as well as making automated "git
> bisect" sessions for tracking down which specific change caused an
> issue more useful.
>
> Best Regards,
>
> Leif
>
>
> Diff between Ray's v2 and my version of it:
>
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c 
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
> index 12647be..523c698 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
> @@ -281,13 +281,13 @@ DumpResourceMap (
>IN UINTN ResourceCount
>)
>  {
> -  EFI_STATUS   Status;
> -  LIST_ENTRY   *Link;
> -  PCI_IO_DEVICE*Device;
> -  UINTNIndex;
> -  CHAR16   *Str;
> -  PCI_RESOURCE_NODE**ChildResources;
> -  UINTNChildResourceCount;
> +  EFI_STATUS   Status;^M
> +  LIST_ENTRY   *Link;^M
> +  PCI_IO_DEVICE*Device;^M
> +  UINTNIndex;^M
> +  CHAR16   *Str;^M
> +  PCI_RESOURCE_NODE**ChildResources;^M
> +  UINTNChildResourceCount;^M
>
>DEBUG ((EFI_D_INFO, "PciBus: Resource Map for "));
>
> @@ -976,7 +976,7 @@ PciScanBus (
>UINT8 Device;
>UINT8 Func;
>UINT64Address;
> -  UINT8 SecondBus;
> +  UINTN SecondBus;^M
>UINT8 PaddedSubBus;
>UINT16Register;
>UINTN HpIndex;
> @@ -1211,7 +1211,7 @@ PciScanBus (
>
>Status = PciScanBus (
>  PciDevice,
> -SecondBus,
> +(UINT8) (SecondBus),^M
>  SubBusNumber,
>  PaddedBusRange
>  );
> @@ -1227,7 +1227,7 @@ PciScanBus (
>if ((Attributes == EfiPaddingPciRootBridge) &&
>(State & EFI_HPC_STATE_ENABLED) != 0&&
>(State & EFI_HPC_STATE_INITIALIZED) != 0) {
> -*PaddedBusRange = (UINT8) ((UINT8) (BusRange) + *PaddedBusRange);
> +*PaddedBusRange = (UINT8) ((UINT8) (BusRange) 
> +*PaddedBusRange);^M
>} else {
>  //
>  // Reserve the larger one between the actual occupied bus
>  // number and padded bus number
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
> index e12d59f..fb6270b 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
> @@ -245,6 +245,7 @@ CalculateApertureIo16 (
>) {
>
>  Node = RESOURCE_NODE_FROM_LINK (CurrentLink);
> +^M
>  if (Node->ResourceUsage == PciResUsagePadding) {
>ASSERT (PaddingAperture == 0);
>PaddingAperture = Node->Length;
> @@ -303,7 +304,8 @@ CalculateApertureIo16 (
>}
>
>//
> -  // Adjust the aperture with the bridge's alignment
> +  // At last, adjust the aperture with the bridge's^M
> +  // alignment^M
>//
>Offset = Aperture & (Bridge->Alignment);
>
> @@ -346,6 +348,7 @@ CalculateResourceAperture (
>UINT64Aperture;
>LIST_ENTRY*CurrentLink;
>PCI_RESOURCE_NODE *Node;
> +^M
>UINT64PaddingAperture;
>UINT64Offset;
>
> @@ -419,7 +422,7 @@ CalculateResourceAperture (
>}
>
>//
> -  // Adjust the bridge's alignment to the first child's alignment
> +  // At last,

Re: [edk2] [PATCH 03/10] ArmPkg/ArmLib: remove unused ARM9 support

2015-11-03 Thread Leif Lindholm

On Tue, Nov 03, 2015 at 11:16:28AM +0100, Ard Biesheuvel wrote:
> The ARM9 ArmLib implementation is not referenced anywhere in the
> tree, and unlikely to be useful going forward, considering that
> ARM9 outdates even ARMv6. So remove it.

While I agree in principle, I don't think we can safely make too many
assumptions here - we know the majority of 32-bit ARM UEFI platforms
are out of tree.

Can we break this out from the current set and keep as a separate
discussion, giving people a few weeks to respond?

/
Leif

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Library/ArmLib/Arm9/Arm9ArmLib.inf |  43 -
>  ArmPkg/Library/ArmLib/Arm9/Arm9ArmLibPrePi.inf|  43 -
>  ArmPkg/Library/ArmLib/Arm9/Arm9CacheInformation.c | 165 
>  ArmPkg/Library/ArmLib/Arm9/Arm9Lib.c  | 134 
>  ArmPkg/Library/ArmLib/Arm9/Arm9Support.S  | 153 --
>  ArmPkg/Library/ArmLib/Arm9/Arm9Support.asm| 153 --
>  6 files changed, 691 deletions(-)
> 
> diff --git a/ArmPkg/Library/ArmLib/Arm9/Arm9ArmLib.inf 
> b/ArmPkg/Library/ArmLib/Arm9/Arm9ArmLib.inf
> deleted file mode 100644
> index e8aa056fbfea..
> --- a/ArmPkg/Library/ArmLib/Arm9/Arm9ArmLib.inf
> +++ /dev/null
> @@ -1,43 +0,0 @@
> -#/** @file
> -# Semihosting  serail port lib
> -#
> -# Copyright (c) 2008 - 2010, Apple Inc. All rights reserved.
> -#
> -#  This program and the accompanying materials
> -#  are licensed and made available under the terms and conditions of the BSD 
> License
> -#  which accompanies this distribution. The full text of the license may be 
> found at
> -#  http://opensource.org/licenses/bsd-license.php
> -#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> -#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> -#
> -#
> -#**/
> -
> -[Defines]
> -  INF_VERSION= 0x00010005
> -  BASE_NAME  = Arm9ArmLib
> -  FILE_GUID  = 375D70D3-91E0-4374-A540-68BD959EB184
> -  MODULE_TYPE= DXE_DRIVER
> -  VERSION_STRING = 1.0
> -  LIBRARY_CLASS  = ArmLib
> -
> -[Sources.common]
> -  ../Common/Arm/ArmLibSupport.S| GCC
> -  ../Common/Arm/ArmLibSupport.asm  | RVCT
> -  ../Common/ArmLib.c
> -
> -  Arm9Support.S| GCC
> -  Arm9Support.asm  | RVCT
> -
> -  Arm9Lib.c
> -  Arm9CacheInformation.c
> -
> -[Packages]
> -  ArmPkg/ArmPkg.dec
> -  MdePkg/MdePkg.dec
> -
> -[LibraryClasses]
> -  MemoryAllocationLib
> -
> -[Protocols]
> -  gEfiCpuArchProtocolGuid
> diff --git a/ArmPkg/Library/ArmLib/Arm9/Arm9ArmLibPrePi.inf 
> b/ArmPkg/Library/ArmLib/Arm9/Arm9ArmLibPrePi.inf
> deleted file mode 100644
> index 556e3dc5ab2a..
> --- a/ArmPkg/Library/ArmLib/Arm9/Arm9ArmLibPrePi.inf
> +++ /dev/null
> @@ -1,43 +0,0 @@
> -#/** @file
> -# Semihosting  serail port lib
> -#
> -# Copyright (c) 2008 - 2010, Apple Inc. All rights reserved.
> -#
> -#  This program and the accompanying materials
> -#  are licensed and made available under the terms and conditions of the BSD 
> License
> -#  which accompanies this distribution. The full text of the license may be 
> found at
> -#  http://opensource.org/licenses/bsd-license.php
> -#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> -#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> -#
> -#
> -#**/
> -
> -[Defines]
> -  INF_VERSION= 0x00010005
> -  BASE_NAME  = Arm9ArmLibPrePi
> -  FILE_GUID  = e9b6011f-ee15-4e59-ab8f-a819a081fa54
> -  MODULE_TYPE= DXE_DRIVER
> -  VERSION_STRING = 1.0
> -  LIBRARY_CLASS  = ArmLib
> -
> -[Sources.common]
> -  ../Common/Arm/ArmLibSupport.S| GCC
> -  ../Common/Arm/ArmLibSupport.asm  | RVCT
> -  ../Common/ArmLib.c
> -
> -  Arm9Support.S| GCC
> -  Arm9Support.asm  | RVCT
> -
> -  Arm9Lib.c
> -  Arm9CacheInformation.c
> -
> -[Packages]
> -  ArmPkg/ArmPkg.dec
> -  MdePkg/MdePkg.dec
> -
> -[LibraryClasses]
> -  PrePiLib
> -
> -[Protocols]
> -  gEfiCpuArchProtocolGuid
> diff --git a/ArmPkg/Library/ArmLib/Arm9/Arm9CacheInformation.c 
> b/ArmPkg/Library/ArmLib/Arm9/Arm9CacheInformation.c
> deleted file mode 100644
> index f0b5060249fe..
> --- a/ArmPkg/Library/ArmLib/Arm9/Arm9CacheInformation.c
> +++ /dev/null
> @@ -1,165 +0,0 @@
> -/** @file
> -
> -  Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
> -  Copyright (c) 2014, ARM Limited. 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

[edk2] [PATCH 08/10] ArmCacheMaintenanceLib: disallow whole D-cache maintenance operations

2015-11-03 Thread Ard Biesheuvel

The ARM architecture provides no reliable way to clean or invalidate
the entire data cache at runtime. The reason is that such maintenance
requires the use of set/way maintenance operations, which are suitable
only for the kind of maintenance that is carried out when the cache is
taken offline entirely.

So ASSERT () when any of the CacheMaintenanceLib whole data cache routines
are invoked rather than pretending we can do anything meaningful here.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c 
b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
index 175d29496c32..8cc1990b3266 100644
--- a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
+++ b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
@@ -14,6 +14,7 @@
 **/
 #include 
 #include 
+#include 
 #include 
 
 VOID
@@ -44,7 +45,6 @@ InvalidateInstructionCache (
   VOID
   )
 {
-  ArmCleanDataCache();
   ArmInvalidateInstructionCache();
 }
 
@@ -54,7 +54,7 @@ InvalidateDataCache (
   VOID
   )
 {
-  ArmInvalidateDataCache();
+  ASSERT (FALSE);
 }
 
 VOID *
@@ -76,7 +76,7 @@ WriteBackInvalidateDataCache (
   VOID
   )
 {
-  ArmCleanInvalidateDataCache();
+  ASSERT (FALSE);
 }
 
 VOID *
@@ -96,7 +96,7 @@ WriteBackDataCache (
   VOID
   )
 {
-  ArmCleanDataCache();
+  ASSERT (FALSE);
 }
 
 VOID *
-- 
1.9.1

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

[edk2] [PATCH 10/10] ArmPlatformPkg: do not invalidate the entire data cache at startup

2015-11-03 Thread Ard Biesheuvel

Drop the call to ArmInvalidateDataCache () from the PrePi and PrePeiCore
startup sequences. This kind of data cache maintenance should not be
performed at the UEFI firmware level.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/PrePeiCore/PrePeiCore.c | 2 --
 ArmPlatformPkg/PrePi/PrePi.c   | 2 --
 2 files changed, 4 deletions(-)

diff --git a/ArmPlatformPkg/PrePeiCore/PrePeiCore.c 
b/ArmPlatformPkg/PrePeiCore/PrePeiCore.c
index 491d7a6f851f..42877e75aea3 100644
--- a/ArmPlatformPkg/PrePeiCore/PrePeiCore.c
+++ b/ArmPlatformPkg/PrePeiCore/PrePeiCore.c
@@ -73,8 +73,6 @@ CEntryPoint (
 {
   // Data Cache enabled on Primary core when MMU is enabled.
   ArmDisableDataCache ();
-  // Invalidate Data cache
-  ArmInvalidateDataCache ();
   // Invalidate instruction cache
   ArmInvalidateInstructionCache ();
   // Enable Instruction Caches on all cores.
diff --git a/ArmPlatformPkg/PrePi/PrePi.c b/ArmPlatformPkg/PrePi/PrePi.c
index 99afe6fa9064..871487ff1c4f 100755
--- a/ArmPlatformPkg/PrePi/PrePi.c
+++ b/ArmPlatformPkg/PrePi/PrePi.c
@@ -225,8 +225,6 @@ CEntryPoint (
 
   // Data Cache enabled on Primary core when MMU is enabled.
   ArmDisableDataCache ();
-  // Invalidate Data cache
-  ArmInvalidateDataCache ();
   // Invalidate instruction cache
   ArmInvalidateInstructionCache ();
   // Enable Instruction Caches on all cores.
-- 
1.9.1

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

[edk2] [PATCH 01/10] ArmPkg/ArmLib: fix barriers in AArch64 ArmEnableMmu

2015-11-03 Thread Ard Biesheuvel

From: Mark Rutland 

The ARM architecture requires a DSB to complete TLB maintenance, with a
subsequent ISB being required to synchronize subsequent items in the
current instruction stream against the completed TLB maintenance.

The ArmEnableMmu function is currently missing the DSB, and hence the
TLB maintenance is not guaranteed to have completed at the point the MMU
is enabled. This may result in unpredictable behaviour.

The DSB subsequent to the write to SCTLR_EL1 is unnecessary; the ISB
alone is sufficient to complete all prior instructions and to
synchronise the new context with any subsequent instructions.

This patch adds missing DSBs to complete TLB maintenance, and removes
the unnecessary trailing DSB.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Mark Rutland 
Reviewed-by: Ard Biesheuvel 
---
 ArmPkg/Library/ArmLib/AArch64/AArch64Support.S | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S 
b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
index bdede48724e6..28cf27fbd1b6 100644
--- a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
+++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
@@ -123,18 +123,20 @@ ASM_PFX(ArmEnableMmu):
 4: orr x0, x0, #CTRL_M_BIT // Set MMU enable bit
EL1_OR_EL2_OR_EL3(x1)
 1: tlbivmalle1
+   dsb nsh
isb
msr sctlr_el1, x0   // Write back
b   4f
 2: tlbialle2
+   dsb nsh
isb
msr sctlr_el2, x0   // Write back
b   4f
 3: tlbialle3
+   dsb nsh
isb
msr sctlr_el3, x0   // Write back
-4: dsb sy
-   isb
+4: isb
ret
 
 
-- 
1.9.1

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

[edk2] [PATCH 04/10] ArmPkg/ArmLib: remove unused ArmCleanDataCacheToPoU()

2015-11-03 Thread Ard Biesheuvel

The function ArmCleanDataCacheToPoU() has no users, and its purpose
is unclear, since it uses cache maintenance by set/way to perform
the clean to PoU, which is a dubious practice to begin with. So
remove the declaration and all definitions.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Include/Library/ArmLib.h|  6 ---
 ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c | 30 
 ArmPkg/Library/ArmLib/AArch64/AArch64Lib.h |  6 ---
 ArmPkg/Library/ArmLib/AArch64/AArch64Support.S | 14 --
 ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.c | 30 
 ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.h |  6 ---
 ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S | 50 
 ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.asm   | 50 
 8 files changed, 192 deletions(-)

diff --git a/ArmPkg/Include/Library/ArmLib.h b/ArmPkg/Include/Library/ArmLib.h
index 58116663b28d..f1de303d952d 100644
--- a/ArmPkg/Include/Library/ArmLib.h
+++ b/ArmPkg/Include/Library/ArmLib.h
@@ -243,12 +243,6 @@ ArmCleanDataCache (
 
 VOID
 EFIAPI
-ArmCleanDataCacheToPoU (
-  VOID
-  );
-
-VOID
-EFIAPI
 ArmInvalidateInstructionCache (
   VOID
   );
diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c 
b/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c
index a4e1f20ad910..f795a2f896b2 100644
--- a/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c
+++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c
@@ -206,26 +206,6 @@ AArch64DataCacheOperation (
   }
 }
 
-
-VOID
-AArch64PoUDataCacheOperation (
-  IN  AARCH64_CACHE_OPERATION  DataCacheOperation
-  )
-{
-  UINTN SavedInterruptState;
-
-  SavedInterruptState = ArmGetInterruptState ();
-  ArmDisableInterrupts ();
-
-  AArch64PerformPoUDataCacheOperation (DataCacheOperation);
-
-  ArmDrainWriteBuffer ();
-
-  if (SavedInterruptState) {
-ArmEnableInterrupts ();
-  }
-}
-
 VOID
 EFIAPI
 ArmInvalidateDataCache (
@@ -255,13 +235,3 @@ ArmCleanDataCache (
   ArmDrainWriteBuffer ();
   AArch64DataCacheOperation (ArmCleanDataCacheEntryBySetWay);
 }
-
-VOID
-EFIAPI
-ArmCleanDataCacheToPoU (
-  VOID
-  )
-{
-  ArmDrainWriteBuffer ();
-  AArch64PoUDataCacheOperation (ArmCleanDataCacheEntryBySetWay);
-}
diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.h 
b/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.h
index c8bb84365bb6..7b9b9c371531 100644
--- a/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.h
+++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.h
@@ -18,12 +18,6 @@
 
 typedef VOID (*AARCH64_CACHE_OPERATION)(UINTN);
 
-
-VOID
-AArch64PerformPoUDataCacheOperation (
-  IN  AARCH64_CACHE_OPERATION  DataCacheOperation
-  );
-
 VOID
 AArch64AllDataCachesOperation (
   IN  AARCH64_CACHE_OPERATION  DataCacheOperation
diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S 
b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
index 8b5e0fb6e7fe..f973a35c21d6 100644
--- a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
+++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
@@ -40,7 +40,6 @@ GCC_ASM_EXPORT (ArmEnableAlignmentCheck)
 GCC_ASM_EXPORT (ArmEnableBranchPrediction)
 GCC_ASM_EXPORT (ArmDisableBranchPrediction)
 GCC_ASM_EXPORT (AArch64AllDataCachesOperation)
-GCC_ASM_EXPORT (AArch64PerformPoUDataCacheOperation)
 GCC_ASM_EXPORT (ArmDataMemoryBarrier)
 GCC_ASM_EXPORT (ArmDataSynchronizationBarrier)
 GCC_ASM_EXPORT (ArmInstructionSynchronizationBarrier)
@@ -324,19 +323,6 @@ ASM_PFX(AArch64AllDataCachesOperation):
 // right to ease the access to CSSELR and the 
Set/Way operation.
   cbz   x3, L_Finished  // No need to clean if LoC is 0
   mov   x10, #0 // Start clean at cache level 0
-  b Loop1
-
-ASM_PFX(AArch64PerformPoUDataCacheOperation):
-// We can use regs 0-7 and 9-15 without having to save/restore.
-// Save our link register on the stack. - The stack must always be quad-word 
aligned
-  str   x30, [sp, #-16]!
-  mov   x1, x0  // Save Function call in x1
-  mrs   x6, clidr_el1   // Read EL1 CLIDR
-  and   x3, x6, #0x3800 // Mask out all but Point of Unification (PoU)
-  lsr   x3, x3, #26 // Left align cache level value - the level is 
shifted by 1 to the
-// right to ease the access to CSSELR and the 
Set/Way operation.
-  cbz   x3, L_Finished  // No need to clean if LoC is 0
-  mov   x10, #0 // Start clean at cache level 0
 
 Loop1:
   add   x2, x10, x10, lsr #1// Work out 3x cachelevel for cache info
diff --git a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.c 
b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.c
index feb60881bdcd..6a8f0d3fdd98 100644
--- a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.c
+++ b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.c
@@ -208,26 +208,6 @@ ArmV7DataCacheOperation (
   }
 }
 
-
-VOID
-ArmV7PoUDataCacheOperation (
-  IN  ARM_V7_CACHE_OPERATION  DataCacheOperation
-  )
-{
-  UINTN SavedInterruptState;
-
-  SavedInterruptState =

Re: [edk2] [PATCH 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

2015-11-03 Thread Paolo Bonzini



On 03/11/2015 15:35, Xiao Guangrong wrote:
>
> -if ((cr0 ^ old_cr0) & X86_CR0_CD)
> +if (!kvm_check_has_quirk(vcpu->kvm, KVM_X86_QUIRK_CD_NW_CLEARED) &&
> +(cr0 ^ old_cr0) & X86_CR0_CD)
>   kvm_zap_gfn_range(vcpu->kvm, 0, ~0ULL);
>
>   return 0;
>>> (Honestly I just imitated fb279950ba here; I'm not making any better
>>> argument for this diff. But, independently, I wonder why this hunk
>>> didn't have the noncoherent DMA check either, originally.)
>>
>> Great job.  I look forward to the testing results.
>>
>> It should also have the noncoherent DMA check, in fact, though that's
>> just an optimization and it would have masked the bug on your system.
> 
> Hmm... but kvm_zap_gfn_range even other shadow page zapping operations
> are really usual behaviour in host - it depends on how we handle memory
> overcommit/memory-layout-change on host.
> 
> I doubt it is really a right way to go. kvm_zap_gfn_range() is just a time
> delay factor to trigger OVMF boot issue but there must have other factors
> have such delay too, for example, more vcpus in OVMF, high overload on
> host, etc.

But it's pointless if the quirk is enabled.  Also, bringing up APs will
cause heavy contention on mmu_lock as Laszlo pointed out.

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

Re: [edk2] [PATCH 09/10] ArmVirtPkg/PrePi: do not invalidate the entire data cache at startup

2015-11-03 Thread Mark Rutland

On Tue, Nov 03, 2015 at 11:16:34AM +0100, Ard Biesheuvel wrote:
> Drop the call to ArmInvalidateDataCache () from the PrePi startup
> sequence. This kind of data cache maintenance should not be performed
> at the UEFI firmware level.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmVirtPkg/PrePi/PrePi.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/ArmVirtPkg/PrePi/PrePi.c b/ArmVirtPkg/PrePi/PrePi.c
> index f9ad37427217..fe7612cec74b 100755
> --- a/ArmVirtPkg/PrePi/PrePi.c
> +++ b/ArmVirtPkg/PrePi/PrePi.c
> @@ -194,8 +194,6 @@ CEntryPoint (
>  
>// Data Cache enabled on Primary core when MMU is enabled.
>ArmDisableDataCache ();
> -  // Invalidate Data cache
> -  ArmInvalidateDataCache ();
>// Invalidate instruction cache
>ArmInvalidateInstructionCache ();
>// Enable Instruction Caches on all cores.

I'm not sure the I-cache maintenance is necessary either, given that
we're already executing code that must have been fetched into the
I-cache, but that really depends on what EDK's requirements are w.r.t.
the state of the system.

For this patch as is:

Acked-by: Mark Rutland 

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

Re: [edk2] [PATCH 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

2015-11-03 Thread Laszlo Ersek

On 11/03/15 15:58, Janusz Mocek wrote:
> W dniu 03.11.2015 o 14:31, Laszlo Ersek pisze:
>> On 11/03/15 13:34, Paolo Bonzini wrote:
>>>
>>> On 03/11/2015 02:14, Laszlo Ersek wrote:
 Anyway, with the following host kernel change, the AP startup problem
 goes away (tested on top of v4.3):

>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index 9a9a198..4f978ad 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -622,7 +622,8 @@ int kvm_set_cr0(struct kvm_vcpu *vcpu, unsigned long 
>> cr0)
>>  if ((cr0 ^ old_cr0) & update_bits)
>>  kvm_mmu_reset_context(vcpu);
>>
>> -if ((cr0 ^ old_cr0) & X86_CR0_CD)
>> +if (!kvm_check_has_quirk(vcpu->kvm, 
>> KVM_X86_QUIRK_CD_NW_CLEARED) &&
>> +(cr0 ^ old_cr0) & X86_CR0_CD)
>>  kvm_zap_gfn_range(vcpu->kvm, 0, ~0ULL);
>>
>>  return 0;
 (Honestly I just imitated fb279950ba here; I'm not making any better
 argument for this diff. But, independently, I wonder why this hunk
 didn't have the noncoherent DMA check either, originally.)
>>> Great job.  I look forward to the testing results.
>>>
>>> It should also have the noncoherent DMA check, in fact, though that's
>>> just an optimization and it would have masked the bug on your system.
>> Thank you! I'll wait for Janusz's results, and if stuff works, I'll post
>> the patch with the update you're suggesting (zap only if the guest has
>> noncoherent DMA and lacks the quirk).
>>
>> Laszlo
>>
>>> Thanks,
>>>
>>> Paolo
>>>
 Janusz, could you rebuild your host kernel with this patch, and share
 the results? (I'm also attaching the same as a formatted patch, so you
 can apply it with "git am" easily.)
> Looks like its working correctly now
> 

Awesome, thank you for testing it. I'll put together a patch.

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

Re: [edk2] [Patch v2 1/1] AppPkg/Python remove improper characters from pyconfig.h

2015-11-03 Thread Bjorge, Erik C

Reviewed-by: Erik Bjorge 

-Original Message-
From: Daryl McDaniel [mailto:edk2-li...@mc2research.org] 
Sent: Tuesday, November 3, 2015 10:37 AM
To: edk2-devel@lists.01.org; Carsey, Jaben ; Bjorge, 
Erik C ; Rosenbaum, Lee G 
Subject: [Patch v2 1/1] AppPkg/Python remove improper characters from pyconfig.h

AppPkg: Within the Ia32 and X64 pyconfig.h files, there are 178 occurrences
of an accent character, `, being used instead of a regular single quote, ',
within comments.

Replace all occurrences of ` within comments with '.  Example:
OLD:  `foobar'
NEW: 'foobar'

The same changes are applied to both
AppPkg/Applications/Python/Ia32/pyconfig.h and
AppPkg/Applications/Python/X64/pyconfig.h.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Daryl McDaniel 

*** a/AppPkg/Applications/Python/X64/pyconfig.h-revBASE.svn001.tmp.hFri
Mar 23 17:19:06 2012
--- b/AppPkg/Applications/Python/X64/pyconfig.h Tue Oct 20 12:43:43 2015
***
*** 58,88 
 the case on Motorola V4 (R40V4.2) */
  #undef GETTIMEOFDAY_NO_TZ

! /* Define to 1 if you have the `acosh' function. */
  #undef HAVE_ACOSH

  /* struct addrinfo (netdb.h) */
  #undef HAVE_ADDRINFO

! /* Define to 1 if you have the `alarm' function. */
  #undef HAVE_ALARM

  /* Define this if your time.h defines altzone. */
  #undef HAVE_ALTZONE

! /* Define to 1 if you have the `asinh' function. */
  #undef HAVE_ASINH

  /* Define to 1 if you have the  header file. */
  #undef HAVE_ASM_TYPES_H

! /* Define to 1 if you have the `atanh' function. */
  #undef HAVE_ATANH

  /* Define if GCC supports __attribute__((format(PyArg_ParseTuple, 2, 3)))
*/
  #undef HAVE_ATTRIBUTE_FORMAT_PARSETUPLE

! /* Define to 1 if you have the `bind_textdomain_codeset' function. */
  #undef HAVE_BIND_TEXTDOMAIN_CODESET

  /* Define to 1 if you have the  header file. */
--- 58,88 
 the case on Motorola V4 (R40V4.2) */
  #undef GETTIMEOFDAY_NO_TZ

! /* Define to 1 if you have the 'acosh' function. */
  #undef HAVE_ACOSH

  /* struct addrinfo (netdb.h) */
  #undef HAVE_ADDRINFO

! /* Define to 1 if you have the 'alarm' function. */
  #undef HAVE_ALARM

  /* Define this if your time.h defines altzone. */
  #undef HAVE_ALTZONE

! /* Define to 1 if you have the 'asinh' function. */
  #undef HAVE_ASINH

  /* Define to 1 if you have the  header file. */
  #undef HAVE_ASM_TYPES_H

! /* Define to 1 if you have the 'atanh' function. */
  #undef HAVE_ATANH

  /* Define if GCC supports __attribute__((format(PyArg_ParseTuple, 2, 3)))
*/
  #undef HAVE_ATTRIBUTE_FORMAT_PARSETUPLE

! /* Define to 1 if you have the 'bind_textdomain_codeset' function. */
  #undef HAVE_BIND_TEXTDOMAIN_CODESET

  /* Define to 1 if you have the  header file. */
***
*** 112,139 
  /* Define this if you have the type _Bool. */
  #define HAVE_C99_BOOL 1

! /* Define to 1 if you have the `chflags' function. */
  #undef HAVE_CHFLAGS

! /* Define to 1 if you have the `chown' function. */
  #undef HAVE_CHOWN

  /* Define if you have the 'chroot' function. */
  #undef HAVE_CHROOT

! /* Define to 1 if you have the `clock' function. */
  #define HAVE_CLOCK1

! /* Define to 1 if you have the `confstr' function. */
  #undef HAVE_CONFSTR

  /* Define to 1 if you have the  header file. */
  #undef HAVE_CONIO_H

! /* Define to 1 if you have the `copysign' function. */
  #undef HAVE_COPYSIGN

! /* Define to 1 if you have the `ctermid' function. */
  #undef HAVE_CTERMID

  /* Define if you have the 'ctermid_r' function. */
--- 112,139 
  /* Define this if you have the type _Bool. */
  #define HAVE_C99_BOOL 1

! /* Define to 1 if you have the 'chflags' function. */
  #undef HAVE_CHFLAGS

! /* Define to 1 if you have the 'chown' function. */
  #undef HAVE_CHOWN

  /* Define if you have the 'chroot' function. */
  #undef HAVE_CHROOT

! /* Define to 1 if you have the 'clock' function. */
  #define HAVE_CLOCK1

! /* Define to 1 if you have the 'confstr' function. */
  #undef HAVE_CONFSTR

  /* Define to 1 if you have the  header file. */
  #undef HAVE_CONIO_H

! /* Define to 1 if you have the 'copysign' function. */
  #undef HAVE_COPYSIGN

! /* Define to 1 if you have the 'ctermid' function. */
  #undef HAVE_CTERMID

  /* Define if you have the 'ctermid_r' function. */
***
*** 151,169 
  /* Define if you have the 'resize_term' function. */
  #undef HAVE_CURSES_RESIZE_TERM

! /* Define to 1 if you have the declaration of `isfinite', and to 0 if you
 don't. */
  #define HAVE_DECL_ISFINITE0

! /* Define to 1 if you have the declaration of `isinf', and to 0 if you
don't.
 */
  #define HAVE_DECL_ISINF   1

! /* Define to 1 if you have the declaration of `isnan', and

Re: [edk2] [Patch v2 1/1] AppPkg/Python remove improper characters from pyconfig.h

2015-11-03 Thread Carsey, Jaben

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Daryl McDaniel [mailto:edk2-li...@mc2research.org]
> Sent: Tuesday, November 03, 2015 10:37 AM
> To: edk2-devel@lists.01.org; Carsey, Jaben ;
> Bjorge, Erik C ; Rosenbaum, Lee G
> 
> Subject: [Patch v2 1/1] AppPkg/Python remove improper characters from
> pyconfig.h
> Importance: High
> 
> AppPkg: Within the Ia32 and X64 pyconfig.h files, there are 178 occurrences
> of an accent character, `, being used instead of a regular single quote, ',
> within comments.
> 
> Replace all occurrences of ` within comments with '.  Example:
> OLD:  `foobar'
> NEW: 'foobar'
> 
> The same changes are applied to both
> AppPkg/Applications/Python/Ia32/pyconfig.h and
> AppPkg/Applications/Python/X64/pyconfig.h.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Daryl McDaniel 
> 
> 
> *** a/AppPkg/Applications/Python/X64/pyconfig.h-revBASE.svn001.tmp.h
>   Fri
> Mar 23 17:19:06 2012
> --- b/AppPkg/Applications/Python/X64/pyconfig.h   Tue Oct 20 12:43:43
> 2015
> ***
> *** 58,88 
>  the case on Motorola V4 (R40V4.2) */
>   #undef GETTIMEOFDAY_NO_TZ
> 
> ! /* Define to 1 if you have the `acosh' function. */
>   #undef HAVE_ACOSH
> 
>   /* struct addrinfo (netdb.h) */
>   #undef HAVE_ADDRINFO
> 
> ! /* Define to 1 if you have the `alarm' function. */
>   #undef HAVE_ALARM
> 
>   /* Define this if your time.h defines altzone. */
>   #undef HAVE_ALTZONE
> 
> ! /* Define to 1 if you have the `asinh' function. */
>   #undef HAVE_ASINH
> 
>   /* Define to 1 if you have the  header file. */
>   #undef HAVE_ASM_TYPES_H
> 
> ! /* Define to 1 if you have the `atanh' function. */
>   #undef HAVE_ATANH
> 
>   /* Define if GCC supports __attribute__((format(PyArg_ParseTuple, 2, 3)))
> */
>   #undef HAVE_ATTRIBUTE_FORMAT_PARSETUPLE
> 
> ! /* Define to 1 if you have the `bind_textdomain_codeset' function. */
>   #undef HAVE_BIND_TEXTDOMAIN_CODESET
> 
>   /* Define to 1 if you have the  header file. */
> --- 58,88 
>  the case on Motorola V4 (R40V4.2) */
>   #undef GETTIMEOFDAY_NO_TZ
> 
> ! /* Define to 1 if you have the 'acosh' function. */
>   #undef HAVE_ACOSH
> 
>   /* struct addrinfo (netdb.h) */
>   #undef HAVE_ADDRINFO
> 
> ! /* Define to 1 if you have the 'alarm' function. */
>   #undef HAVE_ALARM
> 
>   /* Define this if your time.h defines altzone. */
>   #undef HAVE_ALTZONE
> 
> ! /* Define to 1 if you have the 'asinh' function. */
>   #undef HAVE_ASINH
> 
>   /* Define to 1 if you have the  header file. */
>   #undef HAVE_ASM_TYPES_H
> 
> ! /* Define to 1 if you have the 'atanh' function. */
>   #undef HAVE_ATANH
> 
>   /* Define if GCC supports __attribute__((format(PyArg_ParseTuple, 2, 3)))
> */
>   #undef HAVE_ATTRIBUTE_FORMAT_PARSETUPLE
> 
> ! /* Define to 1 if you have the 'bind_textdomain_codeset' function. */
>   #undef HAVE_BIND_TEXTDOMAIN_CODESET
> 
>   /* Define to 1 if you have the  header file. */
> ***
> *** 112,139 
>   /* Define this if you have the type _Bool. */
>   #define HAVE_C99_BOOL 1
> 
> ! /* Define to 1 if you have the `chflags' function. */
>   #undef HAVE_CHFLAGS
> 
> ! /* Define to 1 if you have the `chown' function. */
>   #undef HAVE_CHOWN
> 
>   /* Define if you have the 'chroot' function. */
>   #undef HAVE_CHROOT
> 
> ! /* Define to 1 if you have the `clock' function. */
>   #define HAVE_CLOCK1
> 
> ! /* Define to 1 if you have the `confstr' function. */
>   #undef HAVE_CONFSTR
> 
>   /* Define to 1 if you have the  header file. */
>   #undef HAVE_CONIO_H
> 
> ! /* Define to 1 if you have the `copysign' function. */
>   #undef HAVE_COPYSIGN
> 
> ! /* Define to 1 if you have the `ctermid' function. */
>   #undef HAVE_CTERMID
> 
>   /* Define if you have the 'ctermid_r' function. */
> --- 112,139 
>   /* Define this if you have the type _Bool. */
>   #define HAVE_C99_BOOL 1
> 
> ! /* Define to 1 if you have the 'chflags' function. */
>   #undef HAVE_CHFLAGS
> 
> ! /* Define to 1 if you have the 'chown' function. */
>   #undef HAVE_CHOWN
> 
>   /* Define if you have the 'chroot' function. */
>   #undef HAVE_CHROOT
> 
> ! /* Define to 1 if you have the 'clock' function. */
>   #define HAVE_CLOCK1
> 
> ! /* Define to 1 if you have the 'confstr' function. */
>   #undef HAVE_CONFSTR
> 
>   /* Define to 1 if you have the  header file. */
>   #undef HAVE_CONIO_H
> 
> ! /* Define to 1 if you have the 'copysign' function. */
>   #undef HAVE_COPYSIGN
> 
> ! /* Define to 1 if you have the 'ctermid' function. */
>   #undef HAVE_CTERMID
> 
>   /* Define if you have the 'ctermid_r' function. */
> ***
> *** 151,169 
>   /* Define if you have the 'resize_term' function. */
>   #undef HAVE_CURSES_RESIZE_TERM
> 
> ! /* Define to 1 if you have the

[edk2] [PATCH v3 1/2] ShellPkg/UefiDpLib: Fix a DP cumulative data issue

2015-11-03 Thread Cinnamon Shia

The value of PERF_CUM_DATA.Count and PERF_CUM_DATA.Duration field
keep cumulating on every execution of dp.
Initialize the CumData at dp's entry point.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia 
---
 ShellPkg/Library/UefiDpLib/Dp.c | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/ShellPkg/Library/UefiDpLib/Dp.c b/ShellPkg/Library/UefiDpLib/Dp.c
index 8270172..62a4e7b 100644
--- a/ShellPkg/Library/UefiDpLib/Dp.c
+++ b/ShellPkg/Library/UefiDpLib/Dp.c
@@ -14,6 +14,7 @@
   timer information to calculate elapsed time for each measurement.
  
   Copyright (c) 2009 - 2013, Intel Corporation. All rights reserved.
+  (C) Copyright 2015 Hewlett Packard Enterprise Development LP
   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
@@ -110,7 +111,26 @@ DumpStatistics( void )
   SHELL_FREE_NON_NULL (StringPtrUnknown);
 }
 
-/** 
+/**
+  Initialize the cumulative data.
+
+**/
+VOID
+InitCumulativeData (
+  VOID
+  )
+{
+  UINTN Index;
+
+  for (Index = 0; Index < NumCum; ++Index) {
+CumData[Index].Count = 0;
+CumData[Index].MinDur = PERF_MAXDUR;
+CumData[Index].MaxDur = 0;
+CumData[Index].Duration = 0;
+  }
+}
+
+/**
   Dump performance data.
   
   @param[in]  ImageHandle The image handle.
@@ -219,6 +239,11 @@ ShellCommandRunDp (
   }
 
   //
+  // Initialize the pre-defined cumulative data.
+  //
+  InitCumulativeData ();
+
+  //
   // Timer specific processing
   //
   // Get the Performance counter characteristics:
-- 
1.9.5.msysgit.1

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

[edk2] [Patch v2 1/1] AppPkg/Python remove improper characters from pyconfig.h

2015-11-03 Thread Daryl McDaniel

AppPkg: Within the Ia32 and X64 pyconfig.h files, there are 178 occurrences
of an accent character, `, being used instead of a regular single quote, ',
within comments.

Replace all occurrences of ` within comments with '.  Example:
OLD:  `foobar'
NEW: 'foobar'

The same changes are applied to both
AppPkg/Applications/Python/Ia32/pyconfig.h and
AppPkg/Applications/Python/X64/pyconfig.h.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Daryl McDaniel 


*** a/AppPkg/Applications/Python/X64/pyconfig.h-revBASE.svn001.tmp.hFri
Mar 23 17:19:06 2012
--- b/AppPkg/Applications/Python/X64/pyconfig.h Tue Oct 20 12:43:43 2015
***
*** 58,88 
 the case on Motorola V4 (R40V4.2) */
  #undef GETTIMEOFDAY_NO_TZ
  
! /* Define to 1 if you have the `acosh' function. */
  #undef HAVE_ACOSH
  
  /* struct addrinfo (netdb.h) */
  #undef HAVE_ADDRINFO
  
! /* Define to 1 if you have the `alarm' function. */
  #undef HAVE_ALARM
  
  /* Define this if your time.h defines altzone. */
  #undef HAVE_ALTZONE
  
! /* Define to 1 if you have the `asinh' function. */
  #undef HAVE_ASINH
  
  /* Define to 1 if you have the  header file. */
  #undef HAVE_ASM_TYPES_H
  
! /* Define to 1 if you have the `atanh' function. */
  #undef HAVE_ATANH
  
  /* Define if GCC supports __attribute__((format(PyArg_ParseTuple, 2, 3)))
*/
  #undef HAVE_ATTRIBUTE_FORMAT_PARSETUPLE
  
! /* Define to 1 if you have the `bind_textdomain_codeset' function. */
  #undef HAVE_BIND_TEXTDOMAIN_CODESET
  
  /* Define to 1 if you have the  header file. */
--- 58,88 
 the case on Motorola V4 (R40V4.2) */
  #undef GETTIMEOFDAY_NO_TZ
  
! /* Define to 1 if you have the 'acosh' function. */
  #undef HAVE_ACOSH
  
  /* struct addrinfo (netdb.h) */
  #undef HAVE_ADDRINFO
  
! /* Define to 1 if you have the 'alarm' function. */
  #undef HAVE_ALARM
  
  /* Define this if your time.h defines altzone. */
  #undef HAVE_ALTZONE
  
! /* Define to 1 if you have the 'asinh' function. */
  #undef HAVE_ASINH
  
  /* Define to 1 if you have the  header file. */
  #undef HAVE_ASM_TYPES_H
  
! /* Define to 1 if you have the 'atanh' function. */
  #undef HAVE_ATANH
  
  /* Define if GCC supports __attribute__((format(PyArg_ParseTuple, 2, 3)))
*/
  #undef HAVE_ATTRIBUTE_FORMAT_PARSETUPLE
  
! /* Define to 1 if you have the 'bind_textdomain_codeset' function. */
  #undef HAVE_BIND_TEXTDOMAIN_CODESET
  
  /* Define to 1 if you have the  header file. */
***
*** 112,139 
  /* Define this if you have the type _Bool. */
  #define HAVE_C99_BOOL 1
  
! /* Define to 1 if you have the `chflags' function. */
  #undef HAVE_CHFLAGS
  
! /* Define to 1 if you have the `chown' function. */
  #undef HAVE_CHOWN
  
  /* Define if you have the 'chroot' function. */
  #undef HAVE_CHROOT
  
! /* Define to 1 if you have the `clock' function. */
  #define HAVE_CLOCK1
  
! /* Define to 1 if you have the `confstr' function. */
  #undef HAVE_CONFSTR
  
  /* Define to 1 if you have the  header file. */
  #undef HAVE_CONIO_H
  
! /* Define to 1 if you have the `copysign' function. */
  #undef HAVE_COPYSIGN
  
! /* Define to 1 if you have the `ctermid' function. */
  #undef HAVE_CTERMID
  
  /* Define if you have the 'ctermid_r' function. */
--- 112,139 
  /* Define this if you have the type _Bool. */
  #define HAVE_C99_BOOL 1
  
! /* Define to 1 if you have the 'chflags' function. */
  #undef HAVE_CHFLAGS
  
! /* Define to 1 if you have the 'chown' function. */
  #undef HAVE_CHOWN
  
  /* Define if you have the 'chroot' function. */
  #undef HAVE_CHROOT
  
! /* Define to 1 if you have the 'clock' function. */
  #define HAVE_CLOCK1
  
! /* Define to 1 if you have the 'confstr' function. */
  #undef HAVE_CONFSTR
  
  /* Define to 1 if you have the  header file. */
  #undef HAVE_CONIO_H
  
! /* Define to 1 if you have the 'copysign' function. */
  #undef HAVE_COPYSIGN
  
! /* Define to 1 if you have the 'ctermid' function. */
  #undef HAVE_CTERMID
  
  /* Define if you have the 'ctermid_r' function. */
***
*** 151,169 
  /* Define if you have the 'resize_term' function. */
  #undef HAVE_CURSES_RESIZE_TERM
  
! /* Define to 1 if you have the declaration of `isfinite', and to 0 if you
 don't. */
  #define HAVE_DECL_ISFINITE0
  
! /* Define to 1 if you have the declaration of `isinf', and to 0 if you
don't.
 */
  #define HAVE_DECL_ISINF   1
  
! /* Define to 1 if you have the declaration of `isnan', and to 0 if you
don't.
 */
  #define HAVE_DECL_ISNAN   1
  
! /* Define to 1 if you have the declaration of `tzname', and to 0 if you
don't.
 */
  #define HAVE_DECL_TZNAME  0
  
--- 151,169 
  /* Define if you have the 'resize_term' function. */
  #undef HAVE_CURSES_RESIZE_TERM
  
! /* Define to 1 if you have the declaration of 'isfinite', and to 0 if you
 don't. */
  #define

Re: [edk2] [Patch 1/1] AppPkg/Python remove improper characters from pyconfig.h

2015-11-03 Thread Carsey, Jaben

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Bjorge, Erik C
> Sent: Tuesday, November 03, 2015 10:43 AM
> To: Daryl McDaniel ; edk2-devel@lists.01.org;
> Carsey, Jaben ; Rosenbaum, Lee G
> 
> Subject: RE: [Patch 1/1] AppPkg/Python remove improper characters from
> pyconfig.h
> Importance: High
> 
> Reviewed-by: Erik Bjorge 
> 
> -Original Message-
> From: Daryl McDaniel [mailto:edk2-li...@mc2research.org]
> Sent: Tuesday, November 3, 2015 10:29 AM
> To: edk2-devel@lists.01.org; Carsey, Jaben ;
> Bjorge, Erik C ; Rosenbaum, Lee G
> 
> Subject: [Patch 1/1] AppPkg/Python remove improper characters from
> pyconfig.h
> 
> AppPkg: Within the Ia32 and X64 pyconfig.h files, there are 178 occurrences
> of an accent character, `, being used instead of a regular single quote, ',
> within comments.
> 
> Replace all occurrences of ` within comments with '.  Example:
> OLD:  `foobar'
> NEW: 'foobar'
> 
> The same changes are applied to both
> AppPkg/Applications/Python/Ia32/pyconfig.h and
> AppPkg/Applications/Python/X64/pyconfig.h.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Daryl McDaniel 
> 
> 
> Changes are detailed in the attached patch file.
> 
> Sincerely,
> Daryl McDaniel

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

Re: [edk2] [PATCH 08/10] ArmCacheMaintenanceLib: disallow whole D-cache maintenance operations

2015-11-03 Thread Cohen, Eugene

Ard,

This is probably a reflection of my lack of deep understanding of ARM cache 
maintenance on more complex systems.

The "entire cache" operations exist to allow transitions across major 
environments (initialization of non-self initializing caches, changing phases 
of boot, etc) to clean/clean+invalidate/invalidate cache without knowing 
apriori what virtual addresses have dirty data.  The set/way solution was a 
matter of convenience since the ARM did not have an architectural means of 
operating on the full cache in one instruction.  We do have cases where we need 
to turn off caches entirely - booting our OS as well as in core power 
management scenarios - I think we have to do a full cache flush in these cases 
if not by set/way then somehow.

I don't think we can expect any one component (or whatever phase-thunking code) 
to know what virtual addresses may have dirty data nor can we expect it to loop 
across all possible cacheable virtual addresses.

I also see that the "threshold" based modification of the cache flush from MVA 
to entire-cache was removed earlier this year (I missed that!).  Have you 
quantified the performance impact from removing of the threshold methodology?

Since PEI/DXE/UEFI Boot Services is uniprocessor I don't know if it makes sense 
to eliminate the "entire cache" methodology entirely - I agree for other phases 
like runtime and TZ/SMM that it should be banished.

Eugene

-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] 
Sent: Tuesday, November 03, 2015 7:30 AM
To: Cohen, Eugene 
Cc: edk2-devel@lists.01.org; leif.lindh...@linaro.org; mark.rutl...@arm.com; 
ler...@redhat.com
Subject: Re: [edk2] [PATCH 08/10] ArmCacheMaintenanceLib: disallow whole 
D-cache maintenance operations

On 3 November 2015 at 14:51, Cohen, Eugene  wrote:
> Please don't remove this functionality.  At times we do want to use this 
> library to turn off the cache in preparation for going to another environment 
> (say, loading an OS) and this is useful.
>

Note that this is not about turning off the caches.

As Mark points out, the set/way operations are not suitable for ensuring that 
the OS boot image has made it all the way to memory, and that it will be 
visible to the CPU with the MMU off. The cache maintenance by VA operations do 
offer those guarantees, so the architecturally sound method of achieving that 
is to clean the
region(s) you care about by VA before disabling the MMU.

Under virtualization, these issues are a bit more prominent, and I have had to 
add by-VA cache maintenance on several occasions to fix actual problems.

Note that this patch does not remove any of the functionality. It just changes 
the CacheMaintenanceLib implementation so that this functionality is not 
exported to generic code. If any non-ARM specific code in the tree requires the 
ability to clean and/or invalidate the whole data cache, it is making incorrect 
assumptions about the platform that it runs on.

Regards,
Ard.

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Ard Biesheuvel
> Sent: Tuesday, November 03, 2015 3:17 AM
> To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; 
> mark.rutl...@arm.com
> Cc: ler...@redhat.com; Ard Biesheuvel 
> Subject: [edk2] [PATCH 08/10] ArmCacheMaintenanceLib: disallow whole 
> D-cache maintenance operations
>
> The ARM architecture provides no reliable way to clean or invalidate the 
> entire data cache at runtime. The reason is that such maintenance requires 
> the use of set/way maintenance operations, which are suitable only for the 
> kind of maintenance that is carried out when the cache is taken offline 
> entirely.
>
> So ASSERT () when any of the CacheMaintenanceLib whole data cache routines 
> are invoked rather than pretending we can do anything meaningful here.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c | 8 
> 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git 
> a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c 
> b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> index 175d29496c32..8cc1990b3266 100644
> --- a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> +++ b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> @@ -14,6 +14,7 @@
>  **/
>  #include 
>  #include 
> +#include 
>  #include 
>
>  VOID
> @@ -44,7 +45,6 @@ InvalidateInstructionCache (
>VOID
>)
>  {
> -  ArmCleanDataCache();
>ArmInvalidateInstructionCache();
>  }
>
> @@ -54,7 +54,7 @@ InvalidateDataCache (
>VOID
>)
>  {
> -  ArmInvalidateDataCache();
> +  ASSERT (FALSE);
>  }
>
>  VOID *
> @@ -76,7 +76,7 @@ WriteBackInvalidateDataCache (
>VOID
>)
>  {
> -  ArmCleanInvalidateDataCache();
>

[edk2] RELEASE_DDK3790_X64_DLINK_FLAGS has machine:AMD64

2015-11-03 Thread Sathya Prakash

The Link flags are as below in the latest UDK2015 (and in 2014 too).  Is
the machine type good or should be changed to X64?



RELEASE_DDK3790_X64_DLINK_FLAGS  = /NOLOGO /NODEFAULTLIB /IGNORE:4001
/IGNORE:4078 /OPT:REF /OPT:ICF=10 /MAP /ALIGN:32 /SECTION:.xdata,D
/SECTION:.pdata,D */Machine:AMD64* /LTCG /DLL /ENTRY:$(IMAGE_ENTRY_POINT)
/SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /DRIVER
/MERGE:.data=.text /MERGE:.rdata=.text



Thanks

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

[edk2] [PATCH v4 29/41] OvmfPkg: QuarkPort/CpuS3DataDxe: handle IDT, GDT and MCE in ACPI_CPU_DATA

2015-11-03 Thread Laszlo Ersek

In this patch we incorporate code from
Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe that populates the
following fields in ACPI_CPU_DATA for PiSmmCpuDxeSmm:

- ACPI_CPU_DATA.GdtrProfile
- ACPI_CPU_DATA.IdtrProfile
- ACPI_CPU_DATA.ApMachineCheckHandlerBase
- ACPI_CPU_DATA.ApMachineCheckHandlerSize

The patch performs the following steps:
(1) In the entry point call stack of the driver, allocate an AcpiNVS
block, and copy the BSP's GDT and IDT into it.

(2) Additionally, tack on a small Machine Check Exception handler routine
that we provide in assembly. Hook this handler into the copied IDT
mentined in (1) as well.

(3) In the EFI_SMM_CONFIGURATION_PROTOCOL installation callback, GDTR and
IDTR fields of the MP_CPU_SAVED_DATA AcpiNVS object that embeds
ACPI_CPU_DATA are pointed to the copied GDT and IDT mentioned in (1).

(4) In the same callback, the latter two fields of the ACPI_CPU_DATA
object are pointed to the MCE handler described in (2). The former two
fields (which are doubly indirect pointers) are pointed to the
MP_CPU_SAVED_DATA pointer fields described in (3).

The PiSmmCpuDxeSmm driver acts upon the data as follows:
(5) In the SmmReadyToLockEventNotify() function, during normal boot,
PiSmmCpuDxeSmm loads these data from AcpiNVS memory, and stashes them
all in SMRAM.

(6) When the S3 resume PEIM transfers control to SmmRestoreCpu(), on the
resume path, the GDT, IDT and MCE handler are restored from SMRAM to
the AcpiNVS block allocated in (1).

(7) IDTR and GDTR values saved in (3) and then stashed in (5) are written
to the AP startup routine parameter / communication block. (See
"mExchangeInfo" in PrepareApStartupVector() in
"UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c".)

(8) The startup vector in "UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/MpFuncs.S" loads
these values (identically for all APs) with the LGDT and LIDT
instructions.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- Reword commit message: PiSmmCpuDxeSmm lives under UefiCpuPkg now. Plus
  Mike renamed PrepareAPStartupVector() to PrepareApStartupVector();
  update the reference in the commit message.

 OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf|   3 +
 OvmfPkg/QuarkPort/CpuS3DataDxe/Cpu.h   |  24 
 OvmfPkg/QuarkPort/CpuS3DataDxe/IA32/ArchSpecificDef.h  |  57 
++
 OvmfPkg/QuarkPort/CpuS3DataDxe/MpCommon.h  |  74 
+
 OvmfPkg/QuarkPort/CpuS3DataDxe/IA32/ArchSpecific.c |  48 

 OvmfPkg/QuarkPort/CpuS3DataDxe/MpCommon.c  | 115 

 OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c   |  15 +++
 OvmfPkg/QuarkPort/CpuS3DataDxe/{CpuS3DataDxe.inf => IA32/CpuAsm.S} |  77 
-
 OvmfPkg/QuarkPort/CpuS3DataDxe/IA32/CpuAsm.asm |  69 

 9 files changed, 426 insertions(+), 56 deletions(-)

diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
index be362d8..7440c2d 100644
--- a/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
@@ -56,6 +56,9 @@ [Sources]
   Cpu.h
 
 [Sources.Ia32]
+  IA32/CpuAsm.asm
+  IA32/CpuAsm.S
+  IA32/ArchSpecificDef.h
   IA32/ArchSpecific.c
 
 [Packages]
diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/Cpu.h 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/Cpu.h
index 62faa0b..904e646 100644
--- a/OvmfPkg/QuarkPort/CpuS3DataDxe/Cpu.h
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/Cpu.h
@@ -70,4 +70,28 @@ SaveCpuS3Data (
   VOID*Context
   );
 
+/**
+  Label of start of AP machine check handler.
+
+  This is just a label of start of AP machine check handler.
+
+**/
+VOID
+EFIAPI
+ApMachineCheckHandler (
+  VOID
+  );
+
+/**
+  Label of end of AP machine check handler.
+
+  This is just a label of end of AP machine check handler.
+
+**/
+VOID
+EFIAPI
+ApMachineCheckHandlerEnd (
+  VOID
+  );
+
 #endif
diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/IA32/ArchSpecificDef.h 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/IA32/ArchSpecificDef.h
new file mode 100644
index 000..2bed3d3
--- /dev/null
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/IA32/ArchSpecificDef.h
@@ -0,0 +1,57 @@
+/** @file
+
+Copyright (C) 2015, Red Hat, Inc.
+Copyright (c) 2013-2015 Intel Corporation.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of Intel Corporation nor the names

[edk2] [PATCH v4 28/41] OvmfPkg: QuarkPort/CpuS3DataDxe: fill in ACPI_CPU_DATA.StartupVector

2015-11-03 Thread Laszlo Ersek

The StartupVector member of ACPI_CPU_DATA points to low level assembly
code that starts out in real mode, and is the boot code that gets run on
each AP in response to an INIT-Start-up-Start-up IPI sequence.

Importantly, *each* one of PiSmmCpuDxeSmm and CpuMpDxe (from
Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/) has its own, private startup
vector implementation. They are similar, and are located in the respective
"IA32/MpFuncs.S" files (named RendezvousFunnelProcStart()).

With regard to the communication from CpuMpDxe to PiSmmCpuDxeSmm,
PiSmmCpuDxeSmm does not reuse CpuMpDxe's startup vector on the S3 resume
path (which would be unsafe anyway, unless the startup vector itself were
saved in SMRAM). PiSmmCpuDxeSmm only reuses (and overwrites) the reserved
memory *buffer* underneath ACPI_CPU_DATA.StartupVector that CpuMpDxe
allocated.

Therefore in this patch we only cover the allocation in our CpuS3DataDxe
driver; we can ignore everything else that CpuMpDxe would otherwise do
with its own startup vector.

PiSmmCpuDxeSmm silently assumes that its startup vector (plus the BSP-AP
communication structure that follows it directly) are not larger than the
same pair from CpuMpDxe. Because our CpuS3DataDxe driver has no such
things to key the allocation size off of, we allocate a single page (which
in practice is already larger than the original pair from CpuMpDxe).
PiSmmCpuDxeSmm should assert or enforce that this page is sufficient for
PiSmmCpuDxeSmm's startup vector and BSP-AP communication area.

The code added to CpuS3DataDxe is a little awkward; it looks like this
because it is built from positionally correct snippets (modified as
necessary) lifted from CpuMpDxe, preserving the original control flow:

  entry point (MultiProcessorInitialize() vs. CpuS3DataInitialize())
ProcessorConfiguration()
  WakeupAPAndCollectBist()
PrepareAPStartupVector()
  AllocateStartupVector()
// allocates mStartupVector

  SmmConfigurationEventNotify()
SaveCpuS3Data()
  // sets ACPI_CPU_DATA.StartupVector to mStartupVector

  ReAllocateMemoryForAP() -- optionally, if CSM is present
// reallocates mStartupVector from legacy region
// re-sets ACPI_CPU_DATA.StartupVector to mStartupVector

The CpuS3DataDxe subdirectory is supposed to be diffable against the
original CpuMpDxe.

(In fact the original CpuMpDxe has a bug; it *only* sets
mAcpiCpuData->StartupVector to mStartupVector when the Legacy BIOS
Protocol (ie. CSM) is present, and the startup vector is relocated into
the E or F segment.)

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v3:
- This patch no longer breaks the X64 build, because we now delay
  building QuarkPort/CpuS3DataDxe until after Paolo's patch that enables
  it for X64 too. Update commit message accordingly.

v2:
- Drop the ASSERT() that v1 added to QuarkPort/PiSmmCpuDxeSmm, about the
  size of the area pre-allocated by CpuS3DataDxe. Instead, spell out
  this idea in the commit message; with Mike we've agreed that
  UefiCpuPkg/PiSmmCpuDxeSmm will verify or enforce this in the future
  somehow.

 OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf   |   6 ++
 OvmfPkg/QuarkPort/CpuS3DataDxe/Cpu.h  |  16 +++
 OvmfPkg/QuarkPort/CpuS3DataDxe/MpCommon.h |  42 
 OvmfPkg/QuarkPort/CpuS3DataDxe/{Cpu.h => IA32/ArchSpecific.c} |  34 +++
 OvmfPkg/QuarkPort/CpuS3DataDxe/MpCommon.c | 107 

 OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c  |  63 

 6 files changed, 251 insertions(+), 17 deletions(-)

diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
index efb71d4..be362d8 100644
--- a/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
@@ -56,13 +56,17 @@ [Sources]
   Cpu.h
 
 [Sources.Ia32]
+  IA32/ArchSpecific.c
 
 [Packages]
   MdePkg/MdePkg.dec
+  IntelFrameworkPkg/IntelFrameworkPkg.dec
+  IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
   UefiCpuPkg/UefiCpuPkg.dec
 
 [LibraryClasses]
   UefiBootServicesTableLib
+  MemoryAllocationLib
   UefiDriverEntryPoint
   BaseMemoryLib
   UefiLib
@@ -72,6 +76,7 @@ [LibraryClasses]
 [Guids]
 
 [Protocols]
+  gEfiLegacyBiosProtocolGuid## SOMETIMES_CONSUMES
   gEfiSmmConfigurationProtocolGuid  # PROTOCOL ALWAYS_CONSUMED
 
 [FeaturePcd]
@@ -80,6 +85,7 @@ [FixedPcd]
 
 [Pcd]
   gUefiCpuPkgTokenSpaceGuid.PcdCpuS3DataAddress
+  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdEbdaReservedMemorySize
 
 [Depex]
   TRUE
diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/Cpu.h 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/Cpu.h
index ca4816b..62faa0b 100644
--- a/OvmfPkg/QuarkPort/CpuS3DataDxe/Cpu.h
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/Cpu.h
@@ -40,6 +40,22 @@
 
 #include "MpCommon.h"

[edk2] [PATCH v4 30/41] OvmfPkg: QuarkPort/CpuS3DataDxe: handle StackAddress and StackSize

2015-11-03 Thread Laszlo Ersek

Continuing the pattern seen in the previous patches, we now incorporate
code from Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe that populates
- ACPI_CPU_DATA.StackAddress,
- ACPI_CPU_DATA.StackSize.

During normal boot, CpuS3DataDxe allocates stack in the entry point for
all the APs in AcpiNVS memory. In the EFI_SMM_CONFIGURATION_PROTOCOL
installation callback, the address of that block, and the individual AP
stack size gets exposed.

On the S3 resume path:
- PiSmmCpuDxeSmm parametrizes the AP startup vector (in the exchange area)
  with the location and size of the AP stack in AcpiNVS, read from
  ACPI_CPU_DATA. (See PrepareApStartupVector() in
  "UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c".)

- When APs swarm the startup vector in
  "UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/MpFuncs.S", they serialize on the
  "ProgramStack" logic. No matter the order they claim and vacate the
  critical section, they keep incrementing the StackStart field in the
  exchange area by StackSize, and each AP ends up assigning a distinct
  value to its own %esp.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- Reword commit message: PiSmmCpuDxeSmm lives under UefiCpuPkg now. Plus
  Mike renamed PrepareAPStartupVector() to PrepareApStartupVector();
  update the reference in the commit message.

 OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf  |  2 ++
 OvmfPkg/QuarkPort/CpuS3DataDxe/MpCommon.h|  1 +
 OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c | 28 
 3 files changed, 31 insertions(+)

diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
index 7440c2d..4ade193 100644
--- a/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
@@ -85,9 +85,11 @@ [Protocols]
 [FeaturePcd]
 
 [FixedPcd]
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber
 
 [Pcd]
   gUefiCpuPkgTokenSpaceGuid.PcdCpuS3DataAddress
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuApStackSize
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdEbdaReservedMemorySize
 
 [Depex]
diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/MpCommon.h 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/MpCommon.h
index bb4a0f8..8f47da2 100644
--- a/OvmfPkg/QuarkPort/CpuS3DataDxe/MpCommon.h
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/MpCommon.h
@@ -68,6 +68,7 @@ typedef  struct {
 #pragma pack()
 
 typedef struct {
+  VOID  *StackStart;
   IA32_DESCRIPTOR   GdtrProfile;
   IA32_DESCRIPTOR   IdtrProfile;
 } MP_CPU_EXCHANGE_INFO;
diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c
index f1f07b0..3498230 100644
--- a/OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c
@@ -43,6 +43,26 @@ EFI_EVENT   
mSmmConfigurationNotificationEvent;
 EFI_HANDLE  mImageHandle;
 
 /**
+  Prepares memory region for processor configuration.
+  
+  This function prepares memory region for processor configuration.
+
+**/
+VOID
+PrepareMemoryForConfiguration (
+  VOID
+  )
+{
+  //
+  // Claim memory for AP stack.
+  //
+  mExchangeInfo->StackStart = AllocateAcpiNvsMemoryBelow4G (
+PcdGet32 (PcdCpuMaxLogicalProcessorNumber) *
+PcdGet32 (PcdCpuApStackSize)
+);
+}
+
+/**
   Event notification that is fired every time a gEfiSmmConfigurationProtocol
   installs.
 
@@ -110,6 +130,11 @@ ProcessorConfiguration (
   //
   WakeupAPAndCollectBist ();
 
+  //
+  // Prepare data in memory for processor configuration
+  //
+  PrepareMemoryForConfiguration ();
+
   return EFI_SUCCESS;
 }
 
@@ -206,6 +231,9 @@ SaveCpuS3Data (
 (EFI_PHYSICAL_ADDRESS) (UINTN) &(MpCpuSavedData->GdtrProfile);
   mAcpiCpuData->IdtrProfile=
 (EFI_PHYSICAL_ADDRESS) (UINTN) &(MpCpuSavedData->IdtrProfile);
+  mAcpiCpuData->StackAddress   =
+(EFI_PHYSICAL_ADDRESS) (UINTN) mExchangeInfo->StackStart;
+  mAcpiCpuData->StackSize  = PcdGet32 (PcdCpuApStackSize);
 
   mAcpiCpuData->ApMachineCheckHandlerBase = mApMachineCheckHandlerBase;
   mAcpiCpuData->ApMachineCheckHandlerSize = mApMachineCheckHandlerSize;
-- 
1.8.3.1


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

[edk2] [PATCH v4 35/41] OvmfPkg: port CpuS3DataDxe to X64

2015-11-03 Thread Laszlo Ersek

From: Paolo Bonzini 

The descriptor format is different and the assembly source is
converted to nasm, but otherwise there is no difference.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini 
---

Notes:
v3:
- new in v3

 OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf  |   5 +
 OvmfPkg/QuarkPort/CpuS3DataDxe/X64/ArchSpecificDef.h |  59 +++
 OvmfPkg/QuarkPort/CpuS3DataDxe/X64/ArchSpecific.c| 108 
 OvmfPkg/QuarkPort/CpuS3DataDxe/X64/CpuAsm.nasm   |  58 +++
 4 files changed, 230 insertions(+)

diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
index 2610a63..4bec056 100644
--- a/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
@@ -63,6 +63,11 @@ [Sources.Ia32]
   IA32/ArchSpecificDef.h
   IA32/ArchSpecific.c
 
+[Sources.X64]
+  X64/CpuAsm.nasm
+  X64/ArchSpecificDef.h
+  X64/ArchSpecific.c
+
 [Packages]
   MdePkg/MdePkg.dec
   IntelFrameworkPkg/IntelFrameworkPkg.dec
diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/X64/ArchSpecificDef.h 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/X64/ArchSpecificDef.h
new file mode 100644
index 000..5ea4cf6
--- /dev/null
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/X64/ArchSpecificDef.h
@@ -0,0 +1,59 @@
+/** @file
+
+Copyright (C) 2015, Red Hat, Inc.
+Copyright (c) 2013-2015 Intel Corporation.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of Intel Corporation nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+
+Module Name:
+
+  ProcessorDef.h
+
+Abstract:
+
+  Definition for X64 processor
+
+**/
+
+#ifndef _PROCESSOR_DEF_H_
+#define _PROCESSOR_DEF_H_
+
+#pragma pack(1)
+
+typedef struct {
+  UINT16  OffsetLow;
+  UINT16  SegmentSelector;
+  UINT16  Attributes;
+  UINT16  OffsetHigh;
+  UINT32  OffsetUpper;
+  UINT32  Zero;
+} INTERRUPT_GATE_DESCRIPTOR;
+
+#pragma pack()
+
+#endif
diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/X64/ArchSpecific.c 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/X64/ArchSpecific.c
new file mode 100644
index 000..544816d
--- /dev/null
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/X64/ArchSpecific.c
@@ -0,0 +1,108 @@
+/** @file
+
+  Memory Operation Functions for IA32 Architecture.
+
+  Copyright (C) 2015, Red Hat, Inc.
+  Copyright (c) 2013-2015 Intel Corporation.
+
+  Redistribution and use in source and binary forms, with or without
+  modification, are permitted provided that the following conditions
+  are met:
+
+  * Redistributions of source code must retain the above copyright
+  notice, this list of conditions and the following disclaimer.
+  * Redistributions in binary form must reproduce the above copyright
+  notice, this list of conditions and the following disclaimer in
+  the documentation and/or other materials provided with the
+  distribution.
+  * Neither the name of Intel Corporation nor the names of its
+  contributors may be used to endorse or promote products derived
+  from this software without specific prior written permission.
+
+  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+  THEORY OF

[edk2] [PATCH v4 26/41] OvmfPkg: build PiSmmCpuDxeSmm for -D SMM_REQUIRE

2015-11-03 Thread Laszlo Ersek

At this point we can enable building PiSmmCpuDxeSmm.

CPU specific features, like SMRR detection, and functions that are used to
initialize SMM and process SMIs, are abstracted through the
SmmCpuFeaturesLib class for the PiSmmCpuDxeSmm module. Resolve it to our
own implementation under OvmfPkg -- it allows PiSmmCpuDxeSmm to work with
QEMU's and KVM's 64-bit state save map format, which follows the
definition from AMD's programmer manual.

SmmCpuPlatformHookLib provides platform specific functions that are used
to initialize SMM and process SMIs. Resolve it to the one Null instance
provided by UefiCpuPkg, which is expected to work for most platforms.

PiSmmCpuDxeSmm is not yet intended to function correctly with regard to
S3; the upcoming, trimmed down CpuMpDxe port (under the name CpuS3DataDxe)
will be necessary for that.

Cc: Paolo Bonzini 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
[pbonz...@redhat.com: resolve the SmmCpuFeaturesLib class to OVMF's own
 instance]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini 
---

Notes:
v4:
- Drop the SmmLib resolution from the DSC files, and the matching
  paragraph from the commit message. Starting with SVN r18673 / git
  f40577c3563f ("UefiCpuPkg: PiSmmCpuDxeSmm: Remove unused references to
  SmmLib"), PiSmmCpuDxeSmm depends on SmmLib no more.

v3:
- resolve SmmCpuFeaturesLib to OvmfPkg's own instance [Paolo]

v2:
- The module builds now for X64 too, thanks to Intel for open sourcing
  the X64 SMM entry vector (huge kudos). Update the commit message
  accordingly.
- Thanks to Mike, PiSmmCpuDxeSmm and SmmCpuPlatformHookLibNull are now
  under UefiCpuPkg; update pathnames in the DSC / FDF files accordingly.
- Version 2 of this patch also obviates "OvmfPkg: PiSmmCpuDxeSmm:
  eliminate SmmLib dependency" from v1.
- Resolve SmmCpuFeaturesLib. This abstraction is new in Mike's
  PiSmmCpuDxeSmm module; Quark used to have similar code in
  "SmmFeatures.c" non-separably.

 OvmfPkg/OvmfPkgIa32.dsc| 5 +
 OvmfPkg/OvmfPkgIa32X64.dsc | 5 +
 OvmfPkg/OvmfPkgX64.dsc | 5 +
 OvmfPkg/OvmfPkgIa32.fdf| 1 +
 OvmfPkg/OvmfPkgIa32X64.fdf | 1 +
 OvmfPkg/OvmfPkgX64.fdf | 1 +
 6 files changed, 18 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index f9b7af7..d6d7253 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -741,4 +741,9 @@ [Components]
 
   LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
   }
+  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf {
+
+  
SmmCpuPlatformHookLib|UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
+  SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
+  }
 !endif
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 028c21a..cea39c6 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -748,4 +748,9 @@ [Components.X64]
 
   LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
   }
+  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf {
+
+  
SmmCpuPlatformHookLib|UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
+  SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
+  }
 !endif
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 5ee17ff..98a0133 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -746,4 +746,9 @@ [Components]
 
   LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
   }
+  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf {
+
+  
SmmCpuPlatformHookLib|UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
+  SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
+  }
 !endif
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 53ddae3..7f9e201 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -362,6 +362,7 @@ [FV.DXEFV]
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
 INF  UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
 INF  MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf
+INF  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
 !endif
 
 

diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index bb7ca6e..d70736e 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -362,6 +362,7 @@ [FV.DXEFV]
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
 INF  UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
 INF  MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf
+INF  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
 !endif
 
 

diff --git

[edk2] [PATCH v4 37/41] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: add DXE_SMM_DRIVER build

2015-11-03 Thread Laszlo Ersek

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 
---
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf  | 89 

 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceSmm.c | 66 +++
 2 files changed, 155 insertions(+)

diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
new file mode 100644
index 000..6af0649
--- /dev/null
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
@@ -0,0 +1,89 @@
+## @file
+#  Component description file for QEMU Flash Fimware Volume Block SMM driver
+#  module.
+#
+#  This SMM driver implements and produces the SMM Fimware Volue Block Protocol
+#  for a QEMU flash device.
+#
+#  Copyright (C) 2015, Red Hat, Inc.
+#  Copyright (c) 2006 - 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.
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = FvbServicesSmm
+  FILE_GUID  = 2E7DB7A7-608E-4041-B45F-00359E0766C6
+  MODULE_TYPE= DXE_SMM_DRIVER
+  VERSION_STRING = 1.0
+  PI_SPECIFICATION_VERSION   = 0x0001000A
+  ENTRY_POINT= FvbInitialize
+
+#
+# The following information is for reference only and not required by the build
+# tools.
+#
+#  VALID_ARCHITECTURES   = IA32 X64
+#
+
+[Sources]
+  FvbInfo.c
+  FwBlockService.c
+  FwBlockServiceSmm.c
+  QemuFlash.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  OvmfPkg/OvmfPkg.dec
+
+[LibraryClasses]
+  BaseLib
+  BaseMemoryLib
+  DebugLib
+  DevicePathLib
+  DxeServicesTableLib
+  MemoryAllocationLib
+  PcdLib
+  SmmServicesTableLib
+  UefiBootServicesTableLib
+  UefiDriverEntryPoint
+
+[Guids]
+
+[Protocols]
+  gEfiSmmFirmwareVolumeBlockProtocolGuid# PROTOCOL ALWAYS_PRODUCED
+  gEfiDevicePathProtocolGuid# PROTOCOL ALWAYS_PRODUCED
+
+[FixedPcd]
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageVariableBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwWorkingBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwSpareBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogSize
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareFdSize
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareBlockSize
+
+[Pcd]
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogBase
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable
+
+
+[Depex]
+  TRUE
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceSmm.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceSmm.c
new file mode 100644
index 000..e77129e
--- /dev/null
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceSmm.c
@@ -0,0 +1,66 @@
+/**@file
+  Functions related to the Firmware Volume Block service whose
+  implementation is specific to the SMM driver build.
+
+  Copyright (C) 2015, Red Hat, Inc.
+  Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License which accompanies this
+  distribution.  The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+**/
+
+#include 
+#include 
+#include 
+#include 
+
+#include "FwBlockService.h"
+
+VOID
+InstallProtocolInterfaces (
+  IN EFI_FW_VOL_BLOCK_DEVICE *FvbDevice
+  )
+{
+  EFI_HANDLE FvbHandle;
+  EFI_STATUS Status;
+
+  //
+  // There is no SMM service that can install multiple protocols in the SMM
+  // protocol database in one go.
+  //
+  // The SMM Firmware Volume Block protocol structure is the same as the
+  // Firmware Volume Block protocol structure.
+  //
+  FvbHandle = NULL;
+  DEBUG ((EFI_D_INFO, "Installing QEMU flash

Re: [edk2] [PATCH 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

2015-11-03 Thread Andrew Fish


> On Nov 3, 2015, at 11:42 AM, Jordan Justen  wrote:
> 
> On 2015-11-03 05:45:52, Paolo Bonzini wrote:
>> 
>> 
>> On 03/11/2015 14:25, Laszlo Ersek wrote:
>>>  - Agreement between Paolo, Jordan and Mike about implementing
>>>broadcast SMIs. I am willing to code up whatever design is
>>>agreed upon. Can everyone involved please prioritize this
>>>discussion a little?
> 
> Obviously we'll have to follow what QEMU decides, so I'm not sure how
> much we can actually influence this.
> 
> Aside from the desire to better emulate chipset/platform designs of
> the actual hardware, I do have a related question.
> 

The SMI IPI is sent from a processor in SMM, so like all other hardware 
resources used in SMM the SMM handler needs to restore any state it changes on 
exit. The old PCI 0xCF8/0xCFC IO ports are the old school example of this need 
to restore state to be transparent to the OS. 

Funny old school story but this kind of issue cropped up with the IPMI in the 
1990's  as the hardware interface was an indexed IO registers, and the 
communications was a message (multiple bytes of data). It was not always 
possible to home the IPMI state machine and some times the SMM handler would 
bork the OS IPMI driver state. The final resolution was adding a 2nd set of 
registers dedicated to SMM so the IPMI device could probably track state in all 
cases.  


> If we use the local apic to initiate IPIs to other processors, what
> impact might that have on the state of the local apic if the OS is
> also trying to use it? For example, what if the OS is in the middle of
> trying to send an IPI?
> 
> I think real platforms get to nicely avoid this by having the chipset
> assert SMI to the hardware pins of all processors in the system. It
> looks like our code has a provision for having one processor send the
> others into SMM, but I wonder under which scenarios this is used, and
> how they deal with the local apic state in that case.
> 

I've seen the SMI IPI in code, but I think it is mostly used to deal with the 
case that the processor is sitting in an INIT and the broadcast SMI was 
ignored. 

Thanks,

Andrew Fish

>> Actually, I was *de*prioritizing it because things _more or less_ work
>> without it, especially if the timeout is temporarily reduced.  We
>> probably agree that timeouts are evil in a virt setting, but even
>> without this issue you can commit the ~70 patches that bring us to 99%
>> of the way.
>> 
>> Once the slate is clean and everybody is focused on the few remaining
>> problems, we can tackle them---including broadcast SMIs.
>> 
>> In fact, the rest of your email lists some more pressing problems than
>> broadcast SMIs, which I'm quoting below to further remind other readers. :)
> 
> Since it involves multiple projects, could it take longer to
> coordinate a change?
> 
> -Jordan
> 
>> 
>> Paolo
>> 
>>>  - Solving the MP-related ExitBootServices() handler bug in CpuDxe.
>>>Patches have been on the list for almost a week. While I've been
>>>breaking my back testing and reviewing patches for others (not
>>>just on edk2-devel, mind you), nobody has batted an eye about
>>>that series.
>>> 
>>>[edk2] [PATCH v2 0/4] UefiCpuPkg/CpuDxe: Fix ExitBootServices()
>>>  callback in the presence of SMIs
>>>http://thread.gmane.org/gmane.comp.bios.edk2.devel/3518
>>> 
>>>Please review it, so that I can include it at the front of my
>>>upcoming v4 SMM series.
>>> 
>>>  - Thirty (30) patches from the SMM series still need reviews. Once
>>>all of the above is covered, I'll update the OvmfPkg/README
>>>patch about the status, and post version 4. I wouldn't mind if
>>>we could commit the series still in 2015, but I'm getting less
>>>and less hopeful.
> ___
> 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 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

2015-11-03 Thread Paolo Bonzini



On 03/11/2015 20:42, Jordan Justen wrote:
> On 2015-11-03 05:45:52, Paolo Bonzini wrote:
>>
>>
>> On 03/11/2015 14:25, Laszlo Ersek wrote:
>>>   - Agreement between Paolo, Jordan and Mike about implementing
>>> broadcast SMIs. I am willing to code up whatever design is
>>> agreed upon. Can everyone involved please prioritize this
>>> discussion a little?
> 
> Obviously we'll have to follow what QEMU decides, so I'm not sure how
> much we can actually influence this.
> 
> Aside from the desire to better emulate chipset/platform designs of
> the actual hardware, I do have a related question.
> 
> If we use the local apic to initiate IPIs to other processors, what
> impact might that have on the state of the local apic if the OS is
> also trying to use it? For example, what if the OS is in the middle of
> trying to send an IPI?

A sequence like

   write to ICR
   out to 0xb2
   write to ICR2

is invalid.

On the other hand, the state of the _destination_ APICs is unaffected by
any IPIs that are delivered between writes to ICR and ICR2.

So it's okay to use the APIC from SMM, as long as it's only done on the
processor that received the synchronous SMI.

> Since it involves multiple projects, could it take longer to
> coordinate a change?

Perhaps, but on the other hand it's just the final 1%.  It's worthless
if we do not have the rest.

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

Re: [edk2] [PATCH 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

2015-11-03 Thread Laszlo Ersek

On 11/03/15 14:25, Laszlo Ersek wrote:

> (6) In closing:
> 
> - The LZMA decompression slowdown has been quirked in the upstream
>   kernel. A KVM ioctl() has been introduced that allows QEMU
>   userspace to *disable* any quirks, but as far as I can see in
>   QEMU, this is not being done automatically, nor is it exposed to
>   the user. Therefore we can conclude that this issue has been
>   solved for the mid term at least.

I consider this "done" for now.

> 
> - I have proved that the AP startup slowdown is a separate issue,
>   one that is caused (or "exposed") by the "other" part of host
>   kernel commit b18d5431acc7 -- the part that has lived on to v4.3
>   un-quirked.
> 
>   I'll await Janusz's test results, and then I'll submit my proposed
>   fix (= extending the quirk) to the KVM mailing list. With that we
>   should consider this issue also resolved for OVMF, for the mid
>   term.

Janusz reported back (thanks for that) with positive results (thanks for
*that*), and I have since posted the KVM patch. (As I indicated there,
that patch is not related to the SMM work.)

> - Rather than auditing the MP services implementation in
>   UefiCpuPkg/CpuDxe *right now*, can we *PLEASE* focus on the SMM
>   series?
> 
>   I've been working on it (with some intermittent delays due to
>   external pressure) since *April*. We are so close now. This is
>   what remains to be done:
> 
>   - Agreement between Paolo, Jordan and Mike about implementing
> broadcast SMIs. I am willing to code up whatever design is
> agreed upon. Can everyone involved please prioritize this
> discussion a little?

We can postpone this question for now. I've withdrawn my proof of
concept QEMU patch on qemu-devel, and I shelved the OVMF-side patch too.
This has been made possible by Paolo's idea to return to the relaxed
mode BSP/AP sync mode, *and* to mitigate the perf hit when an AP enters
SMM first / only, and calls in the BSP, by shortening the relevant timeout.

I just wrote a patch for the second part, and retested this approach; it
works well.

>   - Solving the MP-related ExitBootServices() handler bug in CpuDxe.
> Patches have been on the list for almost a week. While I've been
> breaking my back testing and reviewing patches for others (not
> just on edk2-devel, mind you), nobody has batted an eye about
> that series.
> 
> [edk2] [PATCH v2 0/4] UefiCpuPkg/CpuDxe: Fix ExitBootServices()
>   callback in the presence of SMIs
> http://thread.gmane.org/gmane.comp.bios.edk2.devel/3518
> 
> Please review it, so that I can include it at the front of my
> upcoming v4 SMM series.

As I indicated in that thread a few hours (?) ago, I'm withdrawing this
series as well, for now. The series aims to fix a bug in the
ExitBootServices() handler that is only triggered by broadcast SMIs, and
by returning to the relaxed mode / unicast SMI approach (see above),
this bug ceases to block the SMM work. Postponed.

> 
>   - Thirty (30) patches from the SMM series still need reviews. Once
> all of the above is covered, I'll update the OvmfPkg/README
> patch about the status, and post version 4. I wouldn't mind if
> we could commit the series still in 2015, but I'm getting less
> and less hopeful.

I'm in the process of formatting and double checking version 4. I'll
post it later tonight.

The main things to keep in mind about v4 are:

- KVM + X64 + MP + S3 works (the most important use case);
  where S3 resume requires the Ia32X64 build

- The series has no pending dependencies. All prereq patches are
  present in upstream edk2, QEMU, and (queued) for KVM. The
  cross-component diffstat is edk2/OvmfPkg/ only.

Dependent on review feedback, I'll propose v4 for merging.

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

[edk2] [PATCH v4 02/41] OvmfPkg: Sec: force reinit of BaseExtractGuidedSectionLib handler table

2015-11-03 Thread Laszlo Ersek

BaseExtractGuidedSectionLib uses a table at the static physical address
PcdGuidedExtractHandlerTableAddress, and modules that are linked against
BaseExtractGuidedSectionLib are expected to work together on that table.
Namely, some modules can register handlers for GUIDed sections, some other
modules can decode such sections with the pre-registered handlers. The
table carries persistent information between these modules.

BaseExtractGuidedSectionLib checks a table signature whenever it is used
(by whichever module that is linked against it), and at the first use
(identified by a signature mismatch) it initializes the table.

One of the module types that BaseExtractGuidedSectionLib can be used with
is SEC, if the SEC module in question runs with the platform's RAM already
available.

In such cases the question emerges whether the initial contents of the RAM
(ie. contents that predate the very first signature check) can be trusted.
Normally RAM starts out with all zeroes (leading to a signature mismatch
on the first check); however a malicious runtime OS can populate the area
with some payload, then force a warm platform reset or an S3
suspend-and-resume. In such cases the signature check in the SEC module
might not fire, and ExtractGuidedSectionDecode() might run code injected
by the runtime OS, as part of SEC (ie. with high privileges).

-D SMM_REQUIRE signals that the firmware should be secure against
tampering from a malicious OS, therefore we clear the handler table in
SEC, in such builds.

See also git commit ad43bc6b2e (SVN rev 15433) -- this patch secures the
(d) and (e) code paths examined in that commit. Furthermore, a
non-malicious runtime OS will observe no change in behavior; see case (c)
in said commit.

Cc: Michael Kinney 
Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
[michael.d.kin...@intel.com: prevent VS20xx loop intrinsic with volatile]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
---

Notes:
v3:
- volatile-qualify the Table pointer to prevent VS20xx from turning the
  zeroing loop into a compiler intrinsic [Mike]

v2:
- This implements option #2 from Jordan's feedback at
  .
  Liming was okay with that option:
  .

- This patch replaces the following patches from the v1 series:

  [PATCH 03/58] MdePkg: BaseExtractGuidedSectionLib: allow forced reinit
of handler table
  

  [PATCH 04/58] OvmfPkg: set PcdBaseExtractGuidedSectionLibForceInit for
SEC on SMM_REQUIRE
  

 OvmfPkg/Sec/SecMain.inf |  5 
 OvmfPkg/Sec/SecMain.c   | 28 
 2 files changed, 33 insertions(+)

diff --git a/OvmfPkg/Sec/SecMain.inf b/OvmfPkg/Sec/SecMain.inf
index 2f78f3c..8f4d86c 100644
--- a/OvmfPkg/Sec/SecMain.inf
+++ b/OvmfPkg/Sec/SecMain.inf
@@ -68,3 +68,8 @@ [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
+  gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
+  gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
+
+[FeaturePcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c
index 4f87059..1556032 100644
--- a/OvmfPkg/Sec/SecMain.c
+++ b/OvmfPkg/Sec/SecMain.c
@@ -699,8 +699,36 @@ SecCoreStartupWithStack (
   IA32_DESCRIPTOR IdtDescriptor;
   UINT32  Index;
 
+  //
+  // This code may be running on the S3 resume boot path, where RAM has been
+  // populated by the runtime guest OS. Guarantee the reinitialization of the
+  // BaseExtractGuidedSectionLib handler table, before the constructor of
+  // LzmaCustomDecompressLib calls into BaseExtractGuidedSectionLib, due to our
+  // explicit ProcessLibraryConstructorList() call below.
+  //
+  // We must not rely on any libraries before calling
+  // ProcessLibraryConstructorList(), thus we clear the table with an
+  // open-coded loop. (The FeaturePcdGet() and FixedPcdGetXX() macro
+  // invocations are preprocessed to constants.)
+  //
+  if (FeaturePcdGet (PcdSmmSmramRequire)) {
+volatile UINT8 *Table;
+
+Table = (UINT8*)(UINTN)FixedPcdGet64 (PcdGuidedExtractHandlerTableAddress);
+for (Index = 0;
+ Index < FixedPcdGet32 (PcdGuidedExtractHandlerTableSize);
+ ++Index) {
+  Table[Index] = 0;
+}
+  }
+
   ProcessLibraryConstructorList (NULL, NULL);
 
+  if (FeaturePcdGet (PcdSmmSmramRequire)) {
+DEBUG ((EFI_D_VERBOSE,

[edk2] [PATCH v4 17/41] OvmfPkg: resolve DebugAgentLib for DXE_SMM_DRIVER modules

2015-11-03 Thread Laszlo Ersek

From: Michael Kinney 

Add mappings to DebugAgentLib for SMM modules to prevent build breaks when
SMM_REQUIRE and SOURCE_DEBUG_ENABLE are both set.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney 
[ler...@redhat.com: cover the X64 dsc, update commit msg, kudos Jordan]
Cc: Michael Kinney 
Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 
---

Notes:
v3:
- new in v3

 OvmfPkg/OvmfPkgIa32.dsc| 3 +++
 OvmfPkg/OvmfPkgIa32X64.dsc | 3 +++
 OvmfPkg/OvmfPkgX64.dsc | 3 +++
 3 files changed, 9 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index f3de592..f229edf 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -309,6 +309,9 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
   DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
 !endif
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
+!ifdef $(SOURCE_DEBUG_ENABLE)
+  DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
+!endif
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index ee97c84..557c15f 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -314,6 +314,9 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
   DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
 !endif
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
+!ifdef $(SOURCE_DEBUG_ENABLE)
+  DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
+!endif
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 6ab7ffe..4b6e6db 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -314,6 +314,9 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
   DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
 !endif
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
+!ifdef $(SOURCE_DEBUG_ENABLE)
+  DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
+!endif
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
-- 
1.8.3.1


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

[edk2] [PATCH v4 01/41] OvmfPkg: introduce -D SMM_REQUIRE and PcdSmmSmramRequire

2015-11-03 Thread Laszlo Ersek

This build time flag and corresponding Feature PCD will control whether
OVMF supports (and, equivalently, requires) SMM/SMRAM support from QEMU.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 
---
 OvmfPkg/OvmfPkg.dec| 10 ++
 OvmfPkg/OvmfPkgIa32.dsc|  4 
 OvmfPkg/OvmfPkgIa32X64.dsc |  4 
 OvmfPkg/OvmfPkgX64.dsc |  4 
 4 files changed, 22 insertions(+)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index d79aff4..f9decd3 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -121,3 +121,13 @@ [PcdsFeatureFlag]
   gUefiOvmfPkgTokenSpaceGuid.PcdSecureBootEnable|FALSE|BOOLEAN|3
   gUefiOvmfPkgTokenSpaceGuid.PcdQemuBootOrderPciTranslation|TRUE|BOOLEAN|0x1c
   gUefiOvmfPkgTokenSpaceGuid.PcdQemuBootOrderMmioTranslation|FALSE|BOOLEAN|0x1d
+
+  ## This feature flag enables SMM/SMRAM support. Note that it also requires
+  #  such support from the underlying QEMU instance; if that support is not
+  #  present, the firmware will reject continuing after a certain point.
+  #
+  #  The flag also acts as a general "security switch"; when TRUE, many
+  #  components will change behavior, with the goal of preventing a malicious
+  #  runtime OS from tampering with firmware structures (special memory ranges
+  #  used by OVMF, the varstore pflash chip, LockBox etc).
+  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|FALSE|BOOLEAN|0x1e
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 0d044c2..c6850ff 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -36,6 +36,7 @@ [Defines]
   DEFINE SECURE_BOOT_ENABLE  = FALSE
   DEFINE NETWORK_IP6_ENABLE  = FALSE
   DEFINE HTTP_BOOT_ENABLE= FALSE
+  DEFINE SMM_REQUIRE = FALSE
 
 [BuildOptions]
   GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
@@ -311,6 +312,9 @@ [PcdsFeatureFlag]
 !if $(SECURE_BOOT_ENABLE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdSecureBootEnable|TRUE
 !endif
+!if $(SMM_REQUIRE) == TRUE
+  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
+!endif
 
 [PcdsFixedAtBuild]
   gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 19d2221..dd65bf9 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -36,6 +36,7 @@ [Defines]
   DEFINE SECURE_BOOT_ENABLE  = FALSE
   DEFINE NETWORK_IP6_ENABLE  = FALSE
   DEFINE HTTP_BOOT_ENABLE= FALSE
+  DEFINE SMM_REQUIRE = FALSE
 
 [BuildOptions]
   GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
@@ -316,6 +317,9 @@ [PcdsFeatureFlag]
 !if $(SECURE_BOOT_ENABLE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdSecureBootEnable|TRUE
 !endif
+!if $(SMM_REQUIRE) == TRUE
+  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
+!endif
 
 [PcdsFixedAtBuild]
   gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index b8df1dc..0de3c85 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -36,6 +36,7 @@ [Defines]
   DEFINE SECURE_BOOT_ENABLE  = FALSE
   DEFINE NETWORK_IP6_ENABLE  = FALSE
   DEFINE HTTP_BOOT_ENABLE= FALSE
+  DEFINE SMM_REQUIRE = FALSE
 
 [BuildOptions]
   GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
@@ -316,6 +317,9 @@ [PcdsFeatureFlag]
 !if $(SECURE_BOOT_ENABLE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdSecureBootEnable|TRUE
 !endif
+!if $(SMM_REQUIRE) == TRUE
+  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
+!endif
 
 [PcdsFixedAtBuild]
   gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
-- 
1.8.3.1


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

[edk2] [PATCH v4 15/41] OvmfPkg: resolve ReportStatusCodeLib for DXE_SMM_DRIVER modules

2015-11-03 Thread Laszlo Ersek

PiSmmCpuDxeSmm depends on this library class, and it's okay to resolve it
generally for all DXE_SMM_DRIVER modules.

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

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index a19d4e2..6a93fd2 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -299,6 +299,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
   TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
   
MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf
+  
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
   HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
   SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
   
SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index d177154..dbaf8fb 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -304,6 +304,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
   TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
   
MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf
+  
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
   HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
   SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
   
SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 7908a31..a7efe52 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -304,6 +304,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
   TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
   
MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf
+  
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
   HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
   SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
   
SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
-- 
1.8.3.1


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

[edk2] [PATCH v4 12/41] OvmfPkg: AcpiS3SaveDxe: don't fake LockBox protocol if SMM_REQUIRE

2015-11-03 Thread Laszlo Ersek

In SVN r15306 (git commit d4ba06df), "OvmfPkg: S3 Resume: fake LockBox
protocol for BootScriptExecutorDxe", we installed a fake LockBox protocol
in OVMF's AcpiS3SaveDxe clone. While our other AcpiS3SaveDxe
customizations remain valid (or harmless), said change is invalid when
OVMF is built with -D SMM_REQUIRE and includes the real protocol provider,
"MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf".

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf |  3 ++-
 OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c  | 14 --
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf 
b/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
index 4cc0713..a288b95 100644
--- a/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
+++ b/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
@@ -59,7 +59,7 @@ [Guids]
   gEfiEndOfDxeEventGroupGuid## CONSUMES  ## Event
 
 [Protocols]
-  gEfiLockBoxProtocolGuid   # PROTOCOL ALWAYS_PRODUCED
+  gEfiLockBoxProtocolGuid   # PROTOCOL SOMETIMES_PRODUCED
   gEfiLegacyBiosProtocolGuid# PROTOCOL ALWAYS_CONSUMED
   gEfiLegacyRegion2ProtocolGuid # PROTOCOL SOMETIMES_CONSUMED
   gFrameworkEfiMpServiceProtocolGuid# PROTOCOL SOMETIMES_CONSUMED
@@ -71,6 +71,7 @@ [Pcd]
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdS3AcpiReservedMemorySize## 
CONSUMES
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdS3BootScriptStackSize   ## 
CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable
+  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire## 
CONSUMES
 
 [Depex]
   gEfiVariableArchProtocolGuid AND gEfiVariableWriteArchProtocolGuid
diff --git a/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c 
b/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c
index f20560f..e3ff234 100644
--- a/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c
+++ b/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c
@@ -538,12 +538,14 @@ InstallEndOfDxeCallback (
 return EFI_LOAD_ERROR;
   }
 
-  Status = gBS->InstallMultipleProtocolInterfaces (
-  ,
-  , NULL,
-  NULL
-  );
-  ASSERT_EFI_ERROR (Status);
+  if (!FeaturePcdGet (PcdSmmSmramRequire)) {
+Status = gBS->InstallMultipleProtocolInterfaces (
+,
+, NULL,
+NULL
+);
+ASSERT_EFI_ERROR (Status);
+  }
 
   Status = gBS->CreateEventEx (
   EVT_NOTIFY_SIGNAL,
-- 
1.8.3.1


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

Re: [edk2] [PATCH 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

2015-11-03 Thread Jordan Justen

On 2015-11-03 05:45:52, Paolo Bonzini wrote:
> 
> 
> On 03/11/2015 14:25, Laszlo Ersek wrote:
> >   - Agreement between Paolo, Jordan and Mike about implementing
> > broadcast SMIs. I am willing to code up whatever design is
> > agreed upon. Can everyone involved please prioritize this
> > discussion a little?

Obviously we'll have to follow what QEMU decides, so I'm not sure how
much we can actually influence this.

Aside from the desire to better emulate chipset/platform designs of
the actual hardware, I do have a related question.

If we use the local apic to initiate IPIs to other processors, what
impact might that have on the state of the local apic if the OS is
also trying to use it? For example, what if the OS is in the middle of
trying to send an IPI?

I think real platforms get to nicely avoid this by having the chipset
assert SMI to the hardware pins of all processors in the system. It
looks like our code has a provision for having one processor send the
others into SMM, but I wonder under which scenarios this is used, and
how they deal with the local apic state in that case.

> Actually, I was *de*prioritizing it because things _more or less_ work
> without it, especially if the timeout is temporarily reduced.  We
> probably agree that timeouts are evil in a virt setting, but even
> without this issue you can commit the ~70 patches that bring us to 99%
> of the way.
> 
> Once the slate is clean and everybody is focused on the few remaining
> problems, we can tackle them---including broadcast SMIs.
> 
> In fact, the rest of your email lists some more pressing problems than
> broadcast SMIs, which I'm quoting below to further remind other readers. :)

Since it involves multiple projects, could it take longer to
coordinate a change?

-Jordan

> 
> Paolo
> 
> >   - Solving the MP-related ExitBootServices() handler bug in CpuDxe.
> > Patches have been on the list for almost a week. While I've been
> > breaking my back testing and reviewing patches for others (not
> > just on edk2-devel, mind you), nobody has batted an eye about
> > that series.
> > 
> > [edk2] [PATCH v2 0/4] UefiCpuPkg/CpuDxe: Fix ExitBootServices()
> >   callback in the presence of SMIs
> > http://thread.gmane.org/gmane.comp.bios.edk2.devel/3518
> > 
> > Please review it, so that I can include it at the front of my
> > upcoming v4 SMM series.
> > 
> >   - Thirty (30) patches from the SMM series still need reviews. Once
> > all of the above is covered, I'll update the OvmfPkg/README
> > patch about the status, and post version 4. I wouldn't mind if
> > we could commit the series still in 2015, but I'm getting less
> > and less hopeful.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v4 22/41] OvmfPkg: SmmCpuFeaturesLib: implement SMRAM state save map access

2015-11-03 Thread Laszlo Ersek

From: Paolo Bonzini 

This implementation copies SMRAM state save map access from the
PiSmmCpuDxeSmm module.

The most notable change is:

- dropping support for EFI_SMM_SAVE_STATE_REGISTER_IO

- changing the implementation of EFI_SMM_SAVE_STATE_REGISTER_LMA to use
  the SMM revision id instead of a local variable (which
  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c initializes from CPUID's LM
  bit).  This accounts for QEMU's implementation of x86_64, which always
  uses revision 0x20064 even if the LM bit is zero.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini 
[ler...@redhat.com: reflow commit message & fix typo, convert patch to
 CRLF]
Cc: Paolo Bonzini 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v3:
- new in v3

 OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf |   2 +
 OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c   | 377 
+++-
 2 files changed, 376 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf 
b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
index 656dd08..594d85b 100644
--- a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
+++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
@@ -31,5 +31,7 @@ [Packages]
   
 [LibraryClasses]
   BaseLib
+  BaseMemoryLib
   PcdLib
   DebugLib
+  SmmServicesTableLib
diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c 
b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
index 078ea96..bd825b4 100644
--- a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
+++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
@@ -15,11 +15,18 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
+//
+// EFER register LMA bit
+//
+#define LMA BIT10
+
 /**
   The constructor function 
 
@@ -125,7 +132,35 @@ SmmCpuFeaturesHookReturnFromSmm (
   IN UINT64NewInstructionPointer
   )
 {
-  return 0;
+  UINT64 OriginalInstructionPointer;
+  SMRAM_SAVE_STATE_MAP  *CpuSaveState = (SMRAM_SAVE_STATE_MAP *)CpuState;
+
+  if ((CpuSaveState->x86.SMMRevId & 0x) == 0) {
+OriginalInstructionPointer = (UINT64)CpuSaveState->x86._EIP;
+CpuSaveState->x86._EIP = (UINT32)NewInstructionPointer;
+//
+// Clear the auto HALT restart flag so the RSM instruction returns
+// program control to the instruction following the HLT instruction.
+//
+if ((CpuSaveState->x86.AutoHALTRestart & BIT0) != 0) {
+  CpuSaveState->x86.AutoHALTRestart &= ~BIT0;
+}
+  } else {
+OriginalInstructionPointer = CpuSaveState->x64._RIP;
+if ((CpuSaveState->x64.IA32_EFER & LMA) == 0) {
+  CpuSaveState->x64._RIP = (UINT32)NewInstructionPointer32;
+} else {
+  CpuSaveState->x64._RIP = (UINT32)NewInstructionPointer;
+}
+//
+// Clear the auto HALT restart flag so the RSM instruction returns
+// program control to the instruction following the HLT instruction.
+//
+if ((CpuSaveState->x64.AutoHALTRestart & BIT0) != 0) {
+  CpuSaveState->x64.AutoHALTRestart &= ~BIT0;
+}
+  }
+  return OriginalInstructionPointer;
 }
 
 /**
@@ -356,6 +391,213 @@ SmmCpuFeaturesSetSmmRegister (
   ASSERT (FALSE);
 }
 
+///
+/// Macro used to simplify the lookup table entries of type 
CPU_SMM_SAVE_STATE_LOOKUP_ENTRY
+///
+#define SMM_CPU_OFFSET(Field) OFFSET_OF (SMRAM_SAVE_STATE_MAP, Field)
+
+///
+/// Macro used to simplify the lookup table entries of type 
CPU_SMM_SAVE_STATE_REGISTER_RANGE
+///
+#define SMM_REGISTER_RANGE(Start, End) { Start, End, End - Start + 1 }
+
+///
+/// Structure used to describe a range of registers
+///
+typedef struct {
+  EFI_SMM_SAVE_STATE_REGISTER  Start;
+  EFI_SMM_SAVE_STATE_REGISTER  End;
+  UINTNLength;
+} CPU_SMM_SAVE_STATE_REGISTER_RANGE;
+
+///
+/// Structure used to build a lookup table to retrieve the widths and offsets
+/// associated with each supported EFI_SMM_SAVE_STATE_REGISTER value
+///
+
+#define SMM_SAVE_STATE_REGISTER_FIRST_INDEX 1
+
+typedef struct {
+  UINT8   Width32;
+  UINT8   Width64;
+  UINT16  Offset32;
+  UINT16  Offset64Lo;
+  UINT16  Offset64Hi;
+  BOOLEAN Writeable;
+} CPU_SMM_SAVE_STATE_LOOKUP_ENTRY;
+
+///
+/// Table used by GetRegisterIndex() to convert an EFI_SMM_SAVE_STATE_REGISTER 
+/// value to an index into a table of type CPU_SMM_SAVE_STATE_LOOKUP_ENTRY
+///
+static CONST CPU_SMM_SAVE_STATE_REGISTER_RANGE mSmmCpuRegisterRanges[] = {
+  SMM_REGISTER_RANGE (EFI_SMM_SAVE_STATE_REGISTER_GDTBASE, 
EFI_SMM_SAVE_STATE_REGISTER_LDTINFO),
+  SMM_REGISTER_RANGE (EFI_SMM_SAVE_STATE_REGISTER_ES,  
EFI_SMM_SAVE_STATE_REGISTER_RIP),
+  SMM_REGISTER_RANGE (EFI_SMM_SAVE_STATE_REGISTER_RFLAGS,

[edk2] [PATCH v4 06/41] OvmfPkg: PlatformPei: account for TSEG size with PcdSmmSmramRequire set

2015-11-03 Thread Laszlo Ersek

PlatformPei calls GetSystemMemorySizeBelow4gb() in three locations:

- PublishPeiMemory(): on normal boot, the permanent PEI RAM is installed
  so that it ends with the RAM below 4GB,

- QemuInitializeRam(): on normal boot, memory resource descriptor HOBs are
  created for the RAM below 4GB; plus MTRR attributes are set
  (independently of S3 vs. normal boot)

- MemMapInitialization(): an MMIO resource descriptor HOB is created for
  PCI resource allocation, on normal boot, starting at max(RAM below 4GB,
  2GB).

The first two of these is adjusted for the configured TSEG size, if
PcdSmmSmramRequire is set:

- In PublishPeiMemory(), the permanent PEI RAM is kept under TSEG.

- In QemuInitializeRam(), we must keep the DXE out of TSEG.

  One idea would be to simply trim the [1MB .. LowerMemorySize] memory
  resource descriptor HOB, leaving a hole for TSEG in the memory space
  map.

  The SMM IPL will however want to massage the caching attributes of the
  SMRAM range that it loads the SMM core into, with
  gDS->SetMemorySpaceAttributes(), and that won't work on a hole. So,
  instead of trimming this range, split the TSEG area off, and report it
  as a cacheable reserved memory resource.

  Finally, since reserved memory can be allocated too, pre-allocate TSEG
  in InitializeRamRegions(), after QemuInitializeRam() returns. (Note that
  this step alone does not suffice without the resource descriptor HOB
  trickery: if we omit that, then the DXE IPL PEIM fails to load and start
  the DXE core.)

- In MemMapInitialization(), the start of the PCI MMIO range is not
  affected.

We choose the largest option (8MB) for the default TSEG size. Michael
Kinney pointed out that the SMBASE relocation in PiSmmCpuDxeSmm consumes
SMRAM proportionally to the number of CPUs. From the three options
available, he reported that 8MB was both necessary and sufficient for the
SMBASE relocation to succeed with 255 CPUs:

- http://thread.gmane.org/gmane.comp.bios.edk2.devel/3020/focus=3137
- http://thread.gmane.org/gmane.comp.bios.edk2.devel/3020/focus=3177

Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 
---

Notes:
v4:
- drop the patch "OvmfPkg: double the SMRAM (TSEG) size for the 64-bit
  DXE phase builds", and change the default TSEG size from 1MB to 8MB
  globally [Mike]

 OvmfPkg/OvmfPkg.dec |  7 
 OvmfPkg/PlatformPei/PlatformPei.inf |  1 +
 OvmfPkg/PlatformPei/MemDetect.c | 34 +++-
 3 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 3fab2af..04859b4 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -93,6 +93,13 @@ [PcdsFixedAtBuild]
   gUefiOvmfPkgTokenSpaceGuid.PcdVirtioScsiMaxTargetLimit|31|UINT16|6
   gUefiOvmfPkgTokenSpaceGuid.PcdVirtioScsiMaxLunLimit|7|UINT32|7
 
+  ## The following setting controls how many megabytes we configure as TSEG on
+  #  Q35, for SMRAM purposes. Permitted values are: 1, 2, 8. Other values cause
+  #  undefined behavior.
+  #
+  #  This PCD is only consulted if PcdSmmSmramRequire is TRUE (see below).
+  gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8|UINT8|0x20
+
 [PcdsFixedAtBuild]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogBase|0x0|UINT32|0x8
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogSize|0x0|UINT32|0x9
diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
b/OvmfPkg/PlatformPei/PlatformPei.inf
index 62f64fe..ee044a2 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -75,6 +75,7 @@ [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd
+  gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdS3AcpiReservedMemorySize
   gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
   gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize
diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
index 5fe8b28..1bdc2df 100644
--- a/OvmfPkg/PlatformPei/MemDetect.c
+++ b/OvmfPkg/PlatformPei/MemDetect.c
@@ -214,6 +214,12 @@ PublishPeiMemory (
 MemorySize = PcdGet32 (PcdS3AcpiReservedMemorySize);
   } else {
 LowerMemorySize = GetSystemMemorySizeBelow4gb ();
+if (FeaturePcdGet (PcdSmmSmramRequire)) {
+  //
+  // TSEG is chipped from the end of low RAM
+  //
+  LowerMemorySize -= FixedPcdGet8 (PcdQ35TsegMbytes) * SIZE_1MB;
+}
 
 PeiMemoryCap = GetPeiMemoryCap ();
 DEBUG ((EFI_D_INFO, "%a: mPhysMemAddressWidth=%d PeiMemoryCap=%u KB\n",
@@ -277,7 +283,18 @@ QemuInitializeRam (
 // Create memory HOBs
 //
 AddMemoryRangeHob (0, BASE_512KB + BASE_128KB);
-AddMemoryRangeHob (BASE_1MB, LowerMemorySize);
+
+if

[edk2] [PATCH v4 38/41] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: adhere to -D SMM_REQUIRE

2015-11-03 Thread Laszlo Ersek

When the user requires "security" by passing -D SMM_REQUIRE, and
consequently by setting PcdSmmSmramRequire, enforce flash-based variables.

Furthermore, add two ASSERT()s to catch if the wrong module were pulled
into the build.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 
---
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf | 2 ++
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf| 2 ++
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c   | 3 +++
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceSmm.c   | 3 +++
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c   | 1 +
 5 files changed, 11 insertions(+)

diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
index ea8413f..c0dda75 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
@@ -85,6 +85,8 @@ [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable
 
+[FeaturePcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
 
 [Depex]
   TRUE
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
index 6af0649..ba2d367 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
@@ -84,6 +84,8 @@ [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable
 
+[FeaturePcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
 
 [Depex]
   TRUE
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c
index c11f598..63b3086 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -34,6 +35,8 @@ InstallProtocolInterfaces (
   EFI_HANDLE FwbHandle;
   EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL *OldFwbInterface;
 
+  ASSERT (!FeaturePcdGet (PcdSmmSmramRequire));
+
   //
   // Find a handle with a matching device path that has supports FW Block
   // protocol
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceSmm.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceSmm.c
index e77129e..e0617f2 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceSmm.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceSmm.c
@@ -15,6 +15,7 @@
 **/
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -29,6 +30,8 @@ InstallProtocolInterfaces (
   EFI_HANDLE FvbHandle;
   EFI_STATUS Status;
 
+  ASSERT (FeaturePcdGet (PcdSmmSmramRequire));
+
   //
   // There is no SMM service that can install multiple protocols in the SMM
   // protocol database in one go.
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
index 28bcb13..5677b5e 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
@@ -245,6 +245,7 @@ QemuFlashInitialize (
   mFdBlockCount = PcdGet32 (PcdOvmfFirmwareFdSize) / mFdBlockSize;
 
   if (!QemuFlashDetected ()) {
+ASSERT (!FeaturePcdGet (PcdSmmSmramRequire));
 return EFI_WRITE_PROTECTED;
   }
 
-- 
1.8.3.1


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

[edk2] [PATCH v4 36/41] OvmfPkg: build QuarkPort/CpuS3DataDxe for -D SMM_REQUIRE

2015-11-03 Thread Laszlo Ersek

Thanks to the previous patch, from Paolo, we can now build
QuarkPort/CpuS3DataDxe for X64 as well.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v3:
- new in v3; split out from
  "OvmfPkg: add skeleton QuarkPort/CpuS3DataDxe".

 OvmfPkg/OvmfPkgIa32.dsc| 1 +
 OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
 OvmfPkg/OvmfPkgX64.dsc | 1 +
 OvmfPkg/OvmfPkgIa32.fdf| 1 +
 OvmfPkg/OvmfPkgIa32X64.fdf | 1 +
 OvmfPkg/OvmfPkgX64.fdf | 1 +
 6 files changed, 6 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index d6d7253..833e8ba 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -722,6 +722,7 @@ [Components]
 !if $(SMM_REQUIRE) == TRUE
   OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
   OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
+  OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
 
   #
   # SMM Initial Program Load (a DXE_RUNTIME_DRIVER)
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index cea39c6..663244c 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -729,6 +729,7 @@ [Components.X64]
 !if $(SMM_REQUIRE) == TRUE
   OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
   OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
+  OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
 
   #
   # SMM Initial Program Load (a DXE_RUNTIME_DRIVER)
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 98a0133..197a13c 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -727,6 +727,7 @@ [Components]
 !if $(SMM_REQUIRE) == TRUE
   OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
   OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
+  OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
 
   #
   # SMM Initial Program Load (a DXE_RUNTIME_DRIVER)
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 7f9e201..e4e105a 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -358,6 +358,7 @@ [FV.DXEFV]
 !if $(SMM_REQUIRE) == TRUE
 INF  OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
 INF  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
+INF  OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
 INF  UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index d70736e..7dc2523 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -358,6 +358,7 @@ [FV.DXEFV]
 !if $(SMM_REQUIRE) == TRUE
 INF  OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
 INF  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
+INF  OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
 INF  UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index b9fee36..6bd333b 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -358,6 +358,7 @@ [FV.DXEFV]
 !if $(SMM_REQUIRE) == TRUE
 INF  OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
 INF  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
+INF  OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
 INF  UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
-- 
1.8.3.1


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

[edk2] [PATCH v4 41/41] OvmfPkg: README: document SMM status

2015-11-03 Thread Laszlo Ersek

Cc: Paolo Bonzini 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v4:
- update to current test results

v3:
- this documentation is not accurate any longer, but since Paolo and
  myself are getting different test results, I'm not bothering updating
  this until our results converge

v2:
- documented "-nx" VCPU feature flag
  

 OvmfPkg/README | 53 
 1 file changed, 53 insertions(+)

diff --git a/OvmfPkg/README b/OvmfPkg/README
index 147e6e0..575dfe8 100644
--- a/OvmfPkg/README
+++ b/OvmfPkg/README
@@ -118,6 +118,59 @@ $ OvmfPkg/build.sh -a X64 qemu -cdrom 
/path/to/disk-image.iso
 To build a 32-bit OVMF without debug messages using GCC 4.5:
 $ OvmfPkg/build.sh -a IA32 -b RELEASE -t GCC45
 
+=== SMM support ===
+
+OVMF is capable of utilizing SMM if the underlying QEMU or KVM hypervisor
+emulates SMM. SMM is put to use in the S3 suspend and resume infrastructure,
+and in the UEFI variable driver stack. The purpose is (virtual) hardware
+separation between the runtime guest OS and the firmware (OVMF), with the
+intent to make Secure Boot actually secure, by preventing the runtime guest OS
+from tampering with the variable store and S3 areas.
+
+For SMM support, OVMF must be built with the "-D SMM_REQUIRE" option. The
+resultant firmware binary will check if QEMU actually provides SMM emulation;
+if it doesn't, then OVMF will log an error and trigger an assertion failure
+during boot (even in RELEASE builds). Both the naming of the flag (SMM_REQUIRE,
+instead of SMM_ENABLE), and this behavior are consistent with the goal
+described above: this is supposed to be a security feature, and fallbacks are
+not allowed. Similarly, a pflash-backed variable store is a requirement.
+
+QEMU should be started with the options listed below (in addition to any other
+guest-specific flags). The command line should be gradually composed from the
+hints below. The minimum required QEMU release (and Q35 machine type) is 2.5.
+
+* QEMU binary and options specific to 32-bit guests:
+
+  qemu-system-i386 -cpu coreduo,-nx \
+
+  or
+
+  qemu-system-x86_64 -cpu ,-lm,-nx \
+
+* QEMU binary for running 64-bit guests (no particular options):
+
+  qemu-system-x86_64 \
+
+* Flags common to all SMM scenarios (only the Q35 machine type is supported):
+
+  -machine q35,smm=on,accel=(tcg|kvm) \
+  -m ... \
+  -smp ... \
+  -global driver=cfi.pflash01,property=secure,value=on \
+  -drive if=pflash,format=raw,unit=0,file=OVMF_CODE.fd,readonly=on \
+  -drive if=pflash,format=raw,unit=1,file=copy_of_OVMF_VARS.fd \
+
+* In order to enable S3, add:
+
+  -global ICH9-LPC.disable_s3=0 \
+
+For KVM acceleration, a v4.4 or later Linux kernel is required on the host.
+
+Dependent on the development status of the
+"UefiCpuPkg/Universal/Acpi/S3Resume2Pei" module, S3 resume may not work in
+OvmfPkg/OvmfPkgX64.dsc builds. In such cases, OvmfPkg/OvmfPkgIa32X64.dsc is
+recommended for running X64 guests.
+
 === Network Support ===
 
 OVMF provides a UEFI network stack by default. Its lowest level driver is the
-- 
1.8.3.1

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

[edk2] [PATCH v4 23/41] OvmfPkg: SmmCpuFeaturesLib: customize state save map format

2015-11-03 Thread Laszlo Ersek

From: Paolo Bonzini 

This adjusts the previously introduced state save map access functions, to
account for QEMU and KVM's 64-bit state save map following the AMD spec
rather than the Intel one.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini 
[ler...@redhat.com: reflow commit message, convert patch to CRLF]
Cc: Paolo Bonzini 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v3:
- new in v3

 OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf |   1 +
 OvmfPkg/Include/Register/QemuSmramSaveStateMap.h| 184 

 OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c   |  50 +++---
 3 files changed, 212 insertions(+), 23 deletions(-)

diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf 
b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
index 594d85b..aaf4b02 100644
--- a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
+++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
@@ -27,6 +27,7 @@ [Sources]
 
 [Packages]
   MdePkg/MdePkg.dec
+  OvmfPkg/OvmfPkg.dec
   UefiCpuPkg/UefiCpuPkg.dec
   
 [LibraryClasses]
diff --git a/OvmfPkg/Include/Register/QemuSmramSaveStateMap.h 
b/OvmfPkg/Include/Register/QemuSmramSaveStateMap.h
new file mode 100644
index 000..389428d
--- /dev/null
+++ b/OvmfPkg/Include/Register/QemuSmramSaveStateMap.h
@@ -0,0 +1,184 @@
+/** @file
+SMRAM Save State Map Definitions.
+
+SMRAM Save State Map definitions based on contents of the 
+Intel(R) 64 and IA-32 Architectures Software Developer's Manual
+  Volume 3C, Section 34.4 SMRAM
+  Volume 3C, Section 34.5 SMI Handler Execution Environment
+  Volume 3C, Section 34.7 Managing Synchronous and Asynchronous SMIs
+
+and the AMD64 Architecture Programmer's Manual
+  Volume 2, Section 10.2 SMM Resources
+
+Copyright (c) 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2015, Red Hat, Inc.
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __QEMU_SMRAM_SAVE_STATE_MAP_H__
+#define __QEMU_SMRAM_SAVE_STATE_MAP_H__
+
+#pragma pack (1)
+
+///
+/// 32-bit SMRAM Save State Map
+///
+typedef struct {
+  UINT8   Reserved0[0x200]; // 7c00h
+  UINT8   Reserved1[0xf8];  // 7e00h
+  UINT32  SMBASE;   // 7ef8h
+  UINT32  SMMRevId; // 7efch
+  UINT16  IORestart;// 7f00h
+  UINT16  AutoHALTRestart;  // 7f02h
+  UINT8   Reserved2[0x9C];  // 7f08h
+  UINT32  IOMemAddr;// 7fa0h
+  UINT32  IOMisc;   // 7fa4h
+  UINT32  _ES;  // 7fa8h
+  UINT32  _CS;  // 7fach
+  UINT32  _SS;  // 7fb0h
+  UINT32  _DS;  // 7fb4h
+  UINT32  _FS;  // 7fb8h
+  UINT32  _GS;  // 7fbch
+  UINT32  Reserved3;// 7fc0h
+  UINT32  _TR;  // 7fc4h
+  UINT32  _DR7; // 7fc8h
+  UINT32  _DR6; // 7fcch
+  UINT32  _EAX; // 7fd0h
+  UINT32  _ECX; // 7fd4h
+  UINT32  _EDX; // 7fd8h
+  UINT32  _EBX; // 7fdch
+  UINT32  _ESP; // 7fe0h
+  UINT32  _EBP; // 7fe4h
+  UINT32  _ESI; // 7fe8h
+  UINT32  _EDI; // 7fech
+  UINT32  _EIP; // 7ff0h
+  UINT32  _EFLAGS;  // 7ff4h
+  UINT32  _CR3; // 7ff8h
+  UINT32  _CR0; // 7ffch
+} QEMU_SMRAM_SAVE_STATE_MAP32;
+
+///
+/// 64-bit SMRAM Save State Map
+///
+typedef struct {
+  UINT8   Reserved0[0x200];  // 7c00h
+
+  UINT16  _ES;   // 7e00h
+  UINT16  _ESAccessRights;   // 7e02h
+  UINT32  _ESLimit;  // 7e04h
+  UINT64  _ESBase;   // 7e08h
+
+  UINT16  _CS;   // 7e10h
+  UINT16  _CSAccessRights;   // 7e12h
+  UINT32  _CSLimit;  // 7e14h
+  UINT64  _CSBase;   // 7e18h
+
+  UINT16  _SS;   // 7e20h
+  UINT16  _SSAccessRights;   // 7e22h
+  UINT32  _SSLimit;  // 7e24h
+  UINT64  _SSBase;   // 7e28h
+
+  UINT16  _DS;   // 7e30h
+  UINT16  _DSAccessRights;   // 7e32h
+  UINT32  _DSLimit;  // 7e34h
+  UINT64  _DSBase;   // 7e38h
+
+  UINT16  _FS;   // 7e40h
+  UINT16  _FSAccessRights;   // 7e42h
+  UINT32  _FSLimit;  // 7e44h
+  UINT64  _FSBase;   // 7e48h
+
+  UINT16  _GS;   // 7e50h
+  UINT16  _GSAccessRights;   // 7e52h
+  UINT32  _GSLimit;  // 7e54h
+  UINT64  _GSBase;   // 7e58h
+
+  UINT32  _GDTRReserved1;// 7e60h
+  UINT16  _GDTRLimit;// 7e64h
+  UINT16  _GDTRReserved2;//

[edk2] [PATCH v4 39/41] OvmfPkg: consolidate variable driver stack in DSC and FDF files

2015-11-03 Thread Laszlo Ersek

The following modules constitute the variable driver stack:

- QemuFlashFvbServicesRuntimeDxe and EmuVariableFvbRuntimeDxe, runtime
  alternatives for providing the Firmware Volume Block(2) Protocol,
  dependent on qemu pflash presence,

- FaultTolerantWriteDxe, providing the Fault Tolerant Write Protocol,

- MdeModulePkg/Universal/Variable/RuntimeDxe, independently of
  -D SECURE_BOOT_ENABLE, providing the Variable and Variable Write
  Architectural Protocols.

Let's move these drivers closer to each other in the DSC and FDF files, so
that we can switch the variable driver stack to SMM with more local
changes.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 
---
 OvmfPkg/OvmfPkgIa32.dsc| 24 
 OvmfPkg/OvmfPkgIa32X64.dsc | 24 
 OvmfPkg/OvmfPkgX64.dsc | 24 
 OvmfPkg/OvmfPkgIa32.fdf| 12 ++
 OvmfPkg/OvmfPkgIa32X64.fdf | 12 ++
 OvmfPkg/OvmfPkgX64.fdf | 12 ++
 6 files changed, 66 insertions(+), 42 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 833e8ba..26d50d5 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -548,19 +548,9 @@ [Components]
   OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
   OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
   OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
-  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
   OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
   OvmfPkg/XenBusDxe/XenBusDxe.inf
   OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
-  OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
-
-  PlatformFvbLib|OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.inf
-  }
-  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
-  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
-
-  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
-  }
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
   
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
   MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
@@ -748,3 +738,17 @@ [Components]
   SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
   }
 !endif
+
+  #
+  # Variable driver stack
+  #
+  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+  OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
+
+  PlatformFvbLib|OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.inf
+  }
+  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
+  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+
+  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+  }
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 663244c..47ba2a2 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -555,19 +555,9 @@ [Components.X64]
   OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
   OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
   OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
-  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
   OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
   OvmfPkg/XenBusDxe/XenBusDxe.inf
   OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
-  OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
-
-  PlatformFvbLib|OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.inf
-  }
-  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
-  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
-
-  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
-  }
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
   
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
   MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
@@ -755,3 +745,17 @@ [Components.X64]
   SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
   }
 !endif
+
+  #
+  # Variable driver stack
+  #
+  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+  OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
+
+  PlatformFvbLib|OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.inf
+  }
+  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
+  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+
+  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+  }
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 197a13c..d5f1ba9 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -553,19 +553,9 @@ [Components]
   OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
   OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
   OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
-  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
   OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
   OvmfPkg/XenBusDxe/XenBusDxe.inf
   OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
-

[edk2] [PATCH v4 04/41] OvmfPkg: decompress FVs on S3 resume if SMM_REQUIRE is set

2015-11-03 Thread Laszlo Ersek

If OVMF was built with -D SMM_REQUIRE, that implies that the runtime OS is
not trusted and we should defend against it tampering with the firmware's
data.

One such datum is the PEI firmware volume (PEIFV). Normally PEIFV is
decompressed on the first boot by SEC, then the OS preserves it across S3
suspend-resume cycles; at S3 resume SEC just reuses the originally
decompressed PEIFV.

However, if we don't trust the OS, then SEC must decompress PEIFV from the
pristine flash every time, lest we execute OS-injected code or work with
OS-injected data.

Due to how FVMAIN_COMPACT is organized, we can't decompress just PEIFV;
the decompression brings DXEFV with itself, plus it uses a temporary
output buffer and a scratch buffer too, which even reach above the end of
the finally installed DXEFV. For this reason we must keep away a
non-malicious OS from DXEFV too, plus the memory up to
PcdOvmfDecomprScratchEnd.

The delay introduced by the LZMA decompression on S3 resume is negligible.

If -D SMM_REQUIRE is not specified, then PcdSmmSmramRequire remains FALSE
(from the DEC file), and then this patch has no effect (not counting some
changed debug messages).

If QEMU doesn't support S3 (or the user disabled it on the QEMU command
line), then this patch has no effect also.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 
---

Notes:
v2:
- PcdOvmfDecomprScratchEnd => PcdOvmfDecompressionScratchEnd [Jordan]
  

- "S3 resume (insecure)" => "S3 resume",
  "S3 resume (hopefully secure)" => "S3 resume (with PEI decompression)"
  [Jordan]
  

 OvmfPkg/PlatformPei/PlatformPei.inf |  4 +++
 OvmfPkg/PlatformPei/Fv.c| 27 +++-
 OvmfPkg/PlatformPei/MemDetect.c | 11 +++-
 OvmfPkg/Sec/SecMain.c   | 16 ++--
 4 files changed, 54 insertions(+), 4 deletions(-)

diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
b/OvmfPkg/PlatformPei/PlatformPei.inf
index 0c7ae5f..62f64fe 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -74,6 +74,7 @@ [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
   gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdS3AcpiReservedMemorySize
   gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
   gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize
@@ -88,6 +89,9 @@ [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable
   gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
 
+[FeaturePcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
+
 [Ppis]
   gEfiPeiMasterBootModePpiGuid
 
diff --git a/OvmfPkg/PlatformPei/Fv.c b/OvmfPkg/PlatformPei/Fv.c
index 3ed775c..248c585 100644
--- a/OvmfPkg/PlatformPei/Fv.c
+++ b/OvmfPkg/PlatformPei/Fv.c
@@ -32,6 +32,8 @@ PeiFvInitialization (
   VOID
   )
 {
+  BOOLEAN SecureS3Needed;
+
   DEBUG ((EFI_D_INFO, "Platform PEI Firmware Volume Initialization\n"));
 
   //
@@ -50,16 +52,39 @@ PeiFvInitialization (
   //
   BuildFvHob (PcdGet32 (PcdOvmfDxeMemFvBase), PcdGet32 (PcdOvmfDxeMemFvSize));
 
+  SecureS3Needed = mS3Supported && FeaturePcdGet (PcdSmmSmramRequire);
+
   //
   // Create a memory allocation HOB for the DXE FV.
   //
+  // If "secure" S3 is needed, then SEC will decompress both PEI and DXE
+  // firmware volumes at S3 resume too, hence we need to keep away the OS from
+  // DXEFV as well. Otherwise we only need to keep away DXE itself from the
+  // DXEFV area.
+  //
   BuildMemoryAllocationHob (
 PcdGet32 (PcdOvmfDxeMemFvBase),
 PcdGet32 (PcdOvmfDxeMemFvSize),
-EfiBootServicesData
+SecureS3Needed ? EfiACPIMemoryNVS : EfiBootServicesData
 );
 
   //
+  // Additionally, said decompression will use temporary memory above the end
+  // of DXEFV, so let's keep away the OS from there too.
+  //
+  if (SecureS3Needed) {
+UINT32 DxeMemFvEnd;
+
+DxeMemFvEnd = PcdGet32 (PcdOvmfDxeMemFvBase) +
+  PcdGet32 (PcdOvmfDxeMemFvSize);
+BuildMemoryAllocationHob (
+  DxeMemFvEnd,
+  PcdGet32 (PcdOvmfDecompressionScratchEnd) - DxeMemFvEnd,
+  EfiACPIMemoryNVS
+  );
+  }
+
+  //
   // Let PEI know about the DXE FV so it can find the DXE Core
   //
   PeiServicesInstallFvInfoPpi (
diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
index 612bb4a..5fe8b28 100644
--- a/OvmfPkg/PlatformPei/MemDetect.c
+++ b/OvmfPkg/PlatformPei/MemDetect.c
@@ -222,7 +222,16 @@ PublishPeiMemory (
 //
 // Determine the range of memory to use during PEI
 //
-MemoryBase = PcdGet32 (PcdOvmfDxeMemFvBase) + PcdGet32

[edk2] [PATCH v4 40/41] OvmfPkg: pull in SMM-based variable driver stack

2015-11-03 Thread Laszlo Ersek

When -D SMM_REQUIRE is given, replace both
- OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf and
- OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
with
- OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf.

The outermost (= runtime DXE driver) VariableSmmRuntimeDxe enters SMM, and
the rest:
- the privileged half of the variable driver, VariableSmm,
- the fault tolerant write driver, FaultTolerantWriteSmm,
- and the FVB driver, FvbServicesSmm,
work in SMM purely.

We also resolve the BaseCryptLib class for DXE_SMM_DRIVER modules, for the
authenticated VariableSmm driver's sake.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 
---

Notes:
v2:
- hook VarCheckUefiLib into VariableSmm
  


 OvmfPkg/OvmfPkgIa32.dsc| 18 --
 OvmfPkg/OvmfPkgIa32X64.dsc | 18 --
 OvmfPkg/OvmfPkgX64.dsc | 18 --
 OvmfPkg/OvmfPkgIa32.fdf| 16 ++--
 OvmfPkg/OvmfPkgIa32X64.fdf | 16 ++--
 OvmfPkg/OvmfPkgX64.fdf | 16 ++--
 6 files changed, 90 insertions(+), 12 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 26d50d5..9e37d9e 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -318,6 +318,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
 !ifdef $(SOURCE_DEBUG_ENABLE)
   DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
 !endif
+  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
@@ -737,10 +738,22 @@ [Components]
   
SmmCpuPlatformHookLib|UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
   SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
   }
-!endif
 
   #
-  # Variable driver stack
+  # Variable driver stack (SMM)
+  #
+  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
+  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf
+  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf {
+
+  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+  }
+  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
+
+!else
+
+  #
+  # Variable driver stack (non-SMM)
   #
   OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
   OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
@@ -752,3 +765,4 @@ [Components]
 
   NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
   }
+!endif
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 47ba2a2..f169c48 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -323,6 +323,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
 !ifdef $(SOURCE_DEBUG_ENABLE)
   DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
 !endif
+  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
@@ -744,10 +745,22 @@ [Components.X64]
   
SmmCpuPlatformHookLib|UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
   SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
   }
-!endif
 
   #
-  # Variable driver stack
+  # Variable driver stack (SMM)
+  #
+  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
+  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf
+  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf {
+
+  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+  }
+  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
+
+!else
+
+  #
+  # Variable driver stack (non-SMM)
   #
   OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
   OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
@@ -759,3 +772,4 @@ [Components.X64]
 
   NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
   }
+!endif
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index d5f1ba9..d7fe8c0 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -323,6 +323,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
 !ifdef $(SOURCE_DEBUG_ENABLE)
   DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
 !endif
+  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
@@ -742,10 +743,22 @@ [Components]
   
SmmCpuPlatformHookLib|UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
   SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
   }
-!endif
 
   #
-  # Variable driver stack
+  # Variable driver stack (SMM)
+  #
+  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
+

[edk2] [PATCH v4 27/41] OvmfPkg: add skeleton QuarkPort/CpuS3DataDxe

2015-11-03 Thread Laszlo Ersek

The PiSmmCpuDxeSmm driver depends on the ACPI_CPU_DATA structure, from a
platform- and CPU-specific driver, in order to support S3. The address of
this structure is communicated through the dynamic PCD
PcdCpuS3DataAddress.

The data and control flows are as follows (CpuMpDxe stands for the
original Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe/ driver, from
which CpuS3DataDxe is being extracted):

  CpuMpDxeS3ResumePei  PiSmmCpuDxeSmm
  (DXE_DRIVER)(PEIM)   (DXE_SMM_DRIVER)
  ---  ---
normalcollects datainstalls
boot  |EFI_SMM_CONFIGUR...PROTOCOL
  |in PiCpuSmmEntry()
  v |
  SmmConfi...Notify() <-+
  |
  v
  saves data into
  ACPI_CPU_DATA in
  AcpiNVS memory,
  sets
  PcdCpuS3DataAddress
  in SaveCpuS3Data()
  |
SMM ready +--> SmmReadyToLockEv...Notify()
to lock |
v
   gets PcdCpuS3DataAddress,
   copies ACPI_CPU_DATA from
   AcpiNVS to SMRAM
   (mAcpiCpuData)

runtime

S3
suspend

S3transfers
resumecontrol to
  PiSmmCpuDxeSmm
  via
  SmmS3Res...Point
  |
  +--> SmmRestoreCpu() and its
   callees use mAcpiCpuData
   from SMRAM

Since CpuMpDxe is very complex and covers much more functionality, we're
going to gradually import only the above feature. This patch pulls in the
basic skeleton of the driver.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v3:
- don't add the driver to the DSC/FDF files just yet; a patch from
  Paolo will enable this driver for X64 as well -- later in the series.

v2:
- PcdCpuS3DataAddress comes from "UefiCpuPkg/UefiCpuPkg.dec" now
- adapt the commit message to the fact that Mike added PiSmmCpuDxeSmm
  to UefiCpuPkg

 OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf  |  85 +++
 OvmfPkg/QuarkPort/CpuS3DataDxe/Cpu.h |  57 
 OvmfPkg/QuarkPort/CpuS3DataDxe/MpCommon.h|  67 +
 OvmfPkg/QuarkPort/CpuS3DataDxe/MpService.h   |  49 +++
 OvmfPkg/QuarkPort/CpuS3DataDxe/MpCommon.c|  76 ++
 OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c | 147 
 6 files changed, 481 insertions(+)

diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
new file mode 100644
index 000..efb71d4
--- /dev/null
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
@@ -0,0 +1,85 @@
+## @file
+#
+# DXE driver that populates ACPI_CPU_DATA for PiSmmCpuDxeSmm.
+#
+# Based on Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe.
+#
+# Copyright (C) 2015, Red Hat, Inc.
+# Copyright (c) 2013-2015 Intel Corporation.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+#
+# * Redistributions of source code must retain the above copyright
+# notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+# notice, this list of conditions and the following disclaimer in
+# the documentation and/or other materials provided with the
+# distribution.
+# * Neither the name of Intel Corporation nor the names of its
+# contributors may be used to endorse or promote products derived
+# from this software without specific prior written permission.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE

[edk2] [PATCH v4 25/41] OvmfPkg: any AP in SMM should not wait for the BSP for more than 100 ms

2015-11-03 Thread Laszlo Ersek

This patch complements the previous one, "OvmfPkg: use relaxed AP SMM
synchronization mode". While that patch focuses on the case when the SMI
is raised synchronously by the BSP, on the BSP:

  BSPHandler() [UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c]
SmmWaitForApArrival()  [UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c]
  IsSyncTimerTimeout() [UefiCpuPkg/PiSmmCpuDxeSmm/SyncTimer.c]

this patch concerns itself with the case when it is one of the APs that
raises (and sees delivered) the synchronous SMI:

  APHandler()[UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c]
IsSyncTimerTimeout() [UefiCpuPkg/PiSmmCpuDxeSmm/SyncTimer.c]

Namely, in APHandler() the AP waits for the BSP to enter SMM regardless of
PcdCpuSmmSyncMode, for PcdCpuSmmApSyncTimeout microseconds (the default
value is 1 second). If the BSP doesn't show up in SMM within that
interval, then the AP brings it in with a directed SMI, and waits for the
BSP again for PcdCpuSmmApSyncTimeout microseconds.

Although during boot services, SmmControl2DxeTrigger() is only called by
the BSP, at runtime the OS can invoke runtime services from an AP (it can
even be forced with "taskset -c 1 efibootmgr"). Because on QEMU
SmmControl2DxeTrigger() only raises the SMI for the calling processor (BSP
and AP alike), the first interval above times out invariably in such cases
-- the BSP never shows up before the AP calls it in.

In order to mitigate the performance penalty, decrease
PcdCpuSmmApSyncTimeout to one tenth of its default value: 100 ms. (For
comparison, Vlv2TbltDevicePkg sets 1 ms.)

NOTE: once QEMU becomes capable of synchronous broadcast SMIs, this patch
and the previous one ("OvmfPkg: use relaxed AP SMM synchronization mode")
should be reverted, and SmmControl2DxeTrigger() should be adjusted
instead.

Cc: Paolo Bonzini 
Cc: Jordan Justen 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v4:
- new in v4

 OvmfPkg/OvmfPkgIa32.dsc| 1 +
 OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
 OvmfPkg/OvmfPkgX64.dsc | 1 +
 3 files changed, 3 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 850c2ab..f9b7af7 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -406,6 +406,7 @@ [PcdsFixedAtBuild]
 
 !if $(SMM_REQUIRE) == TRUE
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmApSyncTimeout|10
 !endif
 
 !if $(SECURE_BOOT_ENABLE) == TRUE
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 48960a5..028c21a 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -412,6 +412,7 @@ [PcdsFixedAtBuild]
 [PcdsFixedAtBuild.X64]
 !if $(SMM_REQUIRE) == TRUE
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmApSyncTimeout|10
 !endif
 
 !if $(SECURE_BOOT_ENABLE) == TRUE
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index bb93a72..5ee17ff 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -411,6 +411,7 @@ [PcdsFixedAtBuild]
 
 !if $(SMM_REQUIRE) == TRUE
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmApSyncTimeout|10
 !endif
 
 !if $(SECURE_BOOT_ENABLE) == TRUE
-- 
1.8.3.1


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

[edk2] [PATCH v4 21/41] OvmfPkg: SmmCpuFeaturesLib: remove unnecessary bits

2015-11-03 Thread Laszlo Ersek

From: Paolo Bonzini 

SMRR and MTRR support is not needed on a virtual platform.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini 
Acked-by: Laszlo Ersek 
[ler...@redhat.com: insert space between ASSERT and (), convert to CRLF]
Cc: Paolo Bonzini 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v3:
- new in v3

 OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf |   4 -
 OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c   | 180 
++--
 2 files changed, 18 insertions(+), 166 deletions(-)

diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf 
b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
index b04c028..656dd08 100644
--- a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
+++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
@@ -32,8 +32,4 @@ [Packages]
 [LibraryClasses]
   BaseLib
   PcdLib
-  MemoryAllocationLib
   DebugLib
-
-[Pcd]
-  gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber## 
SOMETIMES_CONSUMES
diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c 
b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
index dd09387..078ea96 100644
--- a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
+++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
@@ -15,46 +15,11 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 
-//
-// Machine Specific Registers (MSRs)
-//
-#define  SMM_FEATURES_LIB_IA32_MTRR_CAP0x0FE
-#define  SMM_FEATURES_LIB_IA32_FEATURE_CONTROL 0x03A
-#define  SMM_FEATURES_LIB_IA32_SMRR_PHYSBASE   0x1F2
-#define  SMM_FEATURES_LIB_IA32_SMRR_PHYSMASK   0x1F3
-#define  SMM_FEATURES_LIB_IA32_CORE_SMRR_PHYSBASE  0x0A0
-#define  SMM_FEATURES_LIB_IA32_CORE_SMRR_PHYSMASK  0x0A1
-#defineEFI_MSR_SMRR_MASK   0xF000
-#defineEFI_MSR_SMRR_PHYS_MASK_VALIDBIT11
-
-//
-// Set default value to assume SMRR is not supported
-//
-BOOLEAN  mSmrrSupported = FALSE;
-
-//
-// Set default value to assume IA-32 Architectural MSRs are used
-//
-UINT32  mSmrrPhysBaseMsr = SMM_FEATURES_LIB_IA32_SMRR_PHYSBASE;
-UINT32  mSmrrPhysMaskMsr = SMM_FEATURES_LIB_IA32_SMRR_PHYSMASK;
-
-//
-// Set default value to assume MTRRs need to be configured on each SMI
-//
-BOOLEAN  mNeedConfigureMtrrs = TRUE;
-
-//
-// Array for state of SMRR enable on all CPUs
-//
-BOOLEAN  *mSmrrEnabled;
-
 /**
   The constructor function 
 
@@ -68,91 +33,9 @@ SmmCpuFeaturesLibConstructor (
   IN EFI_SYSTEM_TABLE  *SystemTable
   )
 {
-  UINT32  RegEax;
-  UINT32  RegEdx;
-  UINTN   FamilyId;
-  UINTN   ModelId;
-
   //
-  // Retrieve CPU Family and Model 
+  // No need to program SMRRs on our virtual platform.
   //
-  AsmCpuid (CPUID_VERSION_INFO, , NULL, NULL, );
-  FamilyId = (RegEax >> 8) & 0xf;
-  ModelId  = (RegEax >> 4) & 0xf;
-  if (FamilyId == 0x06 || FamilyId == 0x0f) {
-ModelId = ModelId | ((RegEax >> 12) & 0xf0);
-  }
-
-  //
-  // Check CPUID(CPUID_VERSION_INFO).EDX[12] for MTRR capability
-  //
-  if ((RegEdx & BIT12) != 0) {
-//
-// Check MTRR_CAP MSR bit 11 for SMRR support
-//
-if ((AsmReadMsr64 (SMM_FEATURES_LIB_IA32_MTRR_CAP) & BIT11) != 0) {
-  mSmrrSupported = TRUE;
-}
-  }
-
-  //
-  // Intel(R) 64 and IA-32 Architectures Software Developer's Manual
-  // Volume 3C, Section 35.3 MSRs in the Intel(R) Atom(TM) Processor Family
-  // 
-  // If CPU Family/Model is 06_1CH, 06_26H, 06_27H, 06_35H or 06_36H, then 
-  // SMRR Physical Base and SMM Physical Mask MSRs are not available.
-  //
-  if (FamilyId == 0x06) {
-if (ModelId == 0x1C || ModelId == 0x26 || ModelId == 0x27 || ModelId == 
0x35 || ModelId == 0x36) {
-  mSmrrSupported = FALSE;
-}
-  }
-
-  //
-  // Intel(R) 64 and IA-32 Architectures Software Developer's Manual
-  // Volume 3C, Section 35.2 MSRs in the Intel(R) Core(TM) 2 Processor Family
-  //
-  // If CPU Family/Model is 06_0F or 06_17, then use Intel(R) Core(TM) 2 
-  // Processor Family MSRs 
-  //
-  if (FamilyId == 0x06) {
-if (ModelId == 0x17 || ModelId == 0x0f) {
-  mSmrrPhysBaseMsr = SMM_FEATURES_LIB_IA32_CORE_SMRR_PHYSBASE;
-  mSmrrPhysMaskMsr = SMM_FEATURES_LIB_IA32_CORE_SMRR_PHYSMASK;
-}
-  }
-  
-  //
-  // Intel(R) 64 and IA-32 Architectures Software Developer's Manual
-  // Volume 3C, Section 34.4.2 SMRAM Caching
-  //   An IA-32 processor does not automatically write back and invalidate its 
-  //   caches before entering SMM or before exiting SMM. Because of this 
behavior, 
-  //   care must be taken in the placement of the SMRAM in system memory and 
in 
-  //   the caching of the SMRAM to prevent cache incoherence when switching 
back 
-  //   and forth between

[edk2] [PATCH v4 19/41] OvmfPkg: set gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection to FALSE

2015-11-03 Thread Laszlo Ersek

Explanation from Michael Kinney:

  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 [instance] 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
  [altogether] can set the PCD to FALSE.

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

Suggested-by: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- This patch replaces the v1 patch "OvmfPkg: import PCDs from
  Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg". That patch overrode the
  default for the PCD just the same, but it used different justification
  (= "Quark's IA32FamilyCpuBasePkg.dsc disables it too"). Plus, the goal
  of that patch was primarily to import PCDs to OvmfPkg.dec, under
  "gQuarkPortCpuTokenSpaceGuid", which is now unnecessary due to Mike's
  work.

 OvmfPkg/OvmfPkgIa32.dsc| 1 +
 OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
 OvmfPkg/OvmfPkgX64.dsc | 1 +
 3 files changed, 3 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 10d494b..6e14604 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -351,6 +351,7 @@ [PcdsFeatureFlag]
 !endif
 !if $(SMM_REQUIRE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection|FALSE
 !endif
 
 [PcdsFixedAtBuild]
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 594b54b..1c9de14 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -356,6 +356,7 @@ [PcdsFeatureFlag]
 !endif
 !if $(SMM_REQUIRE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection|FALSE
 !endif
 
 [PcdsFixedAtBuild]
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 6a4476c..faf123e 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -356,6 +356,7 @@ [PcdsFeatureFlag]
 !endif
 !if $(SMM_REQUIRE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection|FALSE
 !endif
 
 [PcdsFixedAtBuild]
-- 
1.8.3.1


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

[edk2] [PATCH v4 13/41] OvmfPkg: LockBox: -D SMM_REQUIRE excludes our fake lockbox

2015-11-03 Thread Laszlo Ersek

When the user builds OVMF with -D SMM_REQUIRE, our LockBox implementation
must not be used, since it doesn't actually protect data in the LockBox
from the runtime guest OS. Add an according assert to
LockBoxLibInitialize().

Furthermore, since our LockBox must not be selected with -D SMM_REQUIRE,
it makes sense to set aside memory for it only if -D SMM_REQUIRE is
absent. Modify InitializeRamRegions() accordingly.

This patch completes the -D SMM_REQUIRE-related tweaking of the special
OVMF memory areas.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf |  3 ++
 OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf  |  3 ++
 OvmfPkg/Library/LockBoxLib/LockBoxLib.c   |  2 +
 OvmfPkg/PlatformPei/MemDetect.c   | 40 ++--
 4 files changed, 29 insertions(+), 19 deletions(-)

diff --git a/OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf 
b/OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
index 7203d07..81c893e 100644
--- a/OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
+++ b/OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
@@ -42,3 +42,6 @@ [LibraryClasses]
 [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
+
+[FeaturePcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
diff --git a/OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf 
b/OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf
index a4d27a5..08973a4 100644
--- a/OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf
+++ b/OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf
@@ -43,3 +43,6 @@ [LibraryClasses]
 [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
+
+[FeaturePcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
diff --git a/OvmfPkg/Library/LockBoxLib/LockBoxLib.c 
b/OvmfPkg/Library/LockBoxLib/LockBoxLib.c
index 89050ac..45481b9 100644
--- a/OvmfPkg/Library/LockBoxLib/LockBoxLib.c
+++ b/OvmfPkg/Library/LockBoxLib/LockBoxLib.c
@@ -44,6 +44,8 @@ LockBoxLibInitialize (
 {
   UINTN NumEntries;
 
+  ASSERT (!FeaturePcdGet (PcdSmmSmramRequire));
+
   if (PcdGet32 (PcdOvmfLockBoxStorageSize) < sizeof (LOCK_BOX_GLOBAL)) {
 return RETURN_UNSUPPORTED;
   }
diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
index 1bdc2df..455fcbb 100644
--- a/OvmfPkg/PlatformPei/MemDetect.c
+++ b/OvmfPkg/PlatformPei/MemDetect.c
@@ -407,25 +407,27 @@ InitializeRamRegions (
   }
 
   if (mBootMode != BOOT_ON_S3_RESUME) {
-//
-// Reserve the lock box storage area
-//
-// Since this memory range will be used on S3 resume, it must be
-// reserved as ACPI NVS.
-//
-// If S3 is unsupported, then various drivers might still write to the
-// LockBox area. We ought to prevent DXE from serving allocation requests
-// such that they would overlap the LockBox storage.
-//
-ZeroMem (
-  (VOID*)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageBase),
-  (UINTN) PcdGet32 (PcdOvmfLockBoxStorageSize)
-  );
-BuildMemoryAllocationHob (
-  (EFI_PHYSICAL_ADDRESS)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageBase),
-  (UINT64)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageSize),
-  mS3Supported ? EfiACPIMemoryNVS : EfiBootServicesData
-  );
+if (!FeaturePcdGet (PcdSmmSmramRequire)) {
+  //
+  // Reserve the lock box storage area
+  //
+  // Since this memory range will be used on S3 resume, it must be
+  // reserved as ACPI NVS.
+  //
+  // If S3 is unsupported, then various drivers might still write to the
+  // LockBox area. We ought to prevent DXE from serving allocation requests
+  // such that they would overlap the LockBox storage.
+  //
+  ZeroMem (
+(VOID*)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageBase),
+(UINTN) PcdGet32 (PcdOvmfLockBoxStorageSize)
+);
+  BuildMemoryAllocationHob (
+(EFI_PHYSICAL_ADDRESS)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageBase),
+(UINT64)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageSize),
+mS3Supported ? EfiACPIMemoryNVS : EfiBootServicesData
+);
+}
 
 if (FeaturePcdGet (PcdSmmSmramRequire)) {
   UINT32 TsegSize;
-- 
1.8.3.1


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

[edk2] [PATCH v4 31/41] OvmfPkg: import CpuConfigLib header from Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg

2015-11-03 Thread Laszlo Ersek

The next patch added to CpuS3DataDxe will depend on this header file;
import it.

The typedefs for REGISTER_TYPE, CPU_REGISTER_TABLE_ENTRY, and
CPU_REGISTER_TABLE are removed from the imported header file, because
"UefiCpuPkg/Include/AcpiCpuData.h" already provides those. Instead,
"CpuConfigLib.h" is made include "UefiCpuPkg/Include/AcpiCpuData.h".

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- This header file was a common dependency for both PiSmmCpuDxeSmm and
  CpuS3DataDxe in v1; in v2 it is only required by CpuS3DataDxe. Update
  the commit message, and move the patch to a later position in the
  series.
- In this version, the typedefs for REGISTER_TYPE,
  CPU_REGISTER_TABLE_ENTRY, and CPU_REGISTER_TABLE are removed from the
  imported header file, because Mike's
  "UefiCpuPkg/Include/AcpiCpuData.h" already provides those. Instead,
  "CpuConfigLib.h" is made include "UefiCpuPkg/Include/AcpiCpuData.h".

 OvmfPkg/OvmfPkg.dec  |  11 +
 OvmfPkg/QuarkPort/Include/Library/CpuConfigLib.h | 671 
 2 files changed, 682 insertions(+)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 04859b4..f895178 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -21,8 +21,19 @@ [Defines]
 
 [Includes]
   Include
+  QuarkPort/Include
 
 [LibraryClasses]
+  ## Library classes imported from "Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/"
+  #  follow.
+
+  ##  @libraryclass  CPU Configuration Library
+  #
+  CpuConfigLib|QuarkPort/Include/Library/CpuConfigLib.h
+
+  ## OvmfPkg's own library classes are listed below.
+  #
+
   ##  @libraryclass  Loads and boots a Linux kernel image
   #
   LoadLinuxLib|Include/Library/LoadLinuxLib.h
diff --git a/OvmfPkg/QuarkPort/Include/Library/CpuConfigLib.h 
b/OvmfPkg/QuarkPort/Include/Library/CpuConfigLib.h
new file mode 100644
index 000..964b2ee
--- /dev/null
+++ b/OvmfPkg/QuarkPort/Include/Library/CpuConfigLib.h
@@ -0,0 +1,671 @@
+/** @file
+  Public include file for the CPU Configuration Library
+
+  Copyright (c) 2013-2015 Intel Corporation.
+
+  Redistribution and use in source and binary forms, with or without
+  modification, are permitted provided that the following conditions
+  are met:
+
+  * Redistributions of source code must retain the above copyright
+  notice, this list of conditions and the following disclaimer.
+  * Redistributions in binary form must reproduce the above copyright
+  notice, this list of conditions and the following disclaimer in
+  the documentation and/or other materials provided with the
+  distribution.
+  * Neither the name of Intel Corporation nor the names of its
+  contributors may be used to endorse or promote products derived
+  from this software without specific prior written permission.
+
+  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+  Module Name:  CpuConfigLib.h
+
+**/
+
+#ifndef _CPU_CONFIG_LIB_H_
+#define _CPU_CONFIG_LIB_H_
+
+#include 
+
+//
+// Bits definition of PcdProcessorFeatureUserConfiguration,
+// PcdProcessorFeatureCapability, and PcdProcessorFeatureSetting
+//
+#define PCD_CPU_HT_BIT   0x0001
+#define PCD_CPU_CMP_BIT  0x0002
+#define PCD_CPU_L2_CACHE_BIT 0x0004
+#define PCD_CPU_L2_ECC_BIT   0x0008
+#define PCD_CPU_VT_BIT   0x0010
+#define PCD_CPU_LT_BIT   0x0020
+#define PCD_CPU_EXECUTE_DISABLE_BIT  0x0040
+#define PCD_CPU_L3_CACHE_BIT 0x0080
+#define PCD_CPU_MAX_CPUID_VALUE_LIMIT_BIT0x0100
+#define PCD_CPU_FAST_STRING_BIT  0x0200
+#define PCD_CPU_FERR_SIGNAL_BREAK_BIT0x0400
+#define PCD_CPU_PECI_BIT 0x0800
+#define PCD_CPU_HARDWARE_PREFETCHER_BIT  0x1000
+#define PCD_CPU_ADJACENT_CACHE_LINE_PREFETCH_BIT 0x2000
+#define PCD_CPU_DCU_PREFETCHER_BIT   0x4000
+#define PCD_CPU_IP_PREFETCHER_BIT0x8000
+#define PCD_CPU_MACHINE_CHECK_BIT0x0001
+#define PCD_CPU_THERMAL_MANAGEMENT_BIT

[edk2] [PATCH v4 08/41] OvmfPkg: add DXE_DRIVER for providing TSEG-as-SMRAM during boot-time DXE

2015-11-03 Thread Laszlo Ersek

The SMM core depends on EFI_SMM_ACCESS2_PROTOCOL. This small driver (which
is a thin wrapper around "OvmfPkg/SmmAccess/SmramInternal.c" that was
added in the previous patch) provides that protocol.

Notably, EFI_SMM_ACCESS2_PROTOCOL is for boot time only, therefore
our MODULE_TYPE is not DXE_RUNTIME_DRIVER.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32.dsc |   4 +
 OvmfPkg/OvmfPkgIa32X64.dsc  |   4 +
 OvmfPkg/OvmfPkgX64.dsc  |   4 +
 OvmfPkg/OvmfPkgIa32.fdf |   4 +
 OvmfPkg/OvmfPkgIa32X64.fdf  |   4 +
 OvmfPkg/OvmfPkgX64.fdf  |   4 +
 OvmfPkg/SmmAccess/SmmAccess2Dxe.inf |  57 +++
 OvmfPkg/SmmAccess/SmmAccess2Dxe.c   | 156 
 8 files changed, 237 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 0b729ca..d7bc38d 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -672,3 +672,7 @@ [Components]
 !endif
 
   OvmfPkg/PlatformDxe/Platform.inf
+
+!if $(SMM_REQUIRE) == TRUE
+  OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
+!endif
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 7f672d9..e17cbe5 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -679,3 +679,7 @@ [Components.X64]
 !endif
 
   OvmfPkg/PlatformDxe/Platform.inf
+
+!if $(SMM_REQUIRE) == TRUE
+  OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
+!endif
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 986c019..a748fb3 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -677,3 +677,7 @@ [Components]
 !endif
 
   OvmfPkg/PlatformDxe/Platform.inf
+
+!if $(SMM_REQUIRE) == TRUE
+  OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
+!endif
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 650dab1..285720f 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -355,6 +355,10 @@ [FV.DXEFV]
 INF  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
 INF  OvmfPkg/PlatformDxe/Platform.inf
 
+!if $(SMM_REQUIRE) == TRUE
+INF  OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
+!endif
+
 

 
 [FV.FVMAIN_COMPACT]
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 5830401..02e8752 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -355,6 +355,10 @@ [FV.DXEFV]
 INF  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
 INF  OvmfPkg/PlatformDxe/Platform.inf
 
+!if $(SMM_REQUIRE) == TRUE
+INF  OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
+!endif
+
 

 
 [FV.FVMAIN_COMPACT]
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 9dd6171..f04c36b 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -355,6 +355,10 @@ [FV.DXEFV]
 INF  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
 INF  OvmfPkg/PlatformDxe/Platform.inf
 
+!if $(SMM_REQUIRE) == TRUE
+INF  OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
+!endif
+
 

 
 [FV.FVMAIN_COMPACT]
diff --git a/OvmfPkg/SmmAccess/SmmAccess2Dxe.inf 
b/OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
new file mode 100644
index 000..3ce48ae
--- /dev/null
+++ b/OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
@@ -0,0 +1,57 @@
+## @file
+# A DXE_DRIVER providing SMRAM access by producing EFI_SMM_ACCESS2_PROTOCOL.
+#
+# Q35 TSEG is expected to have been verified and set up by the SmmAccessPei
+# driver.
+#
+# Copyright (C) 2013, 2015, Red Hat, Inc.
+#
+# This program and the accompanying materials are licensed and made available
+# under the terms and conditions of the BSD License which accompanies this
+# distribution. The full text of the license may be found at
+# http://opensource.org/licenses/bsd-license.php
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+# WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = SmmAccess2Dxe
+  FILE_GUID  = AC95AD3D-4366-44BF-9A62-E4B29D7A2206
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+  PI_SPECIFICATION_VERSION   = 0x00010400
+  ENTRY_POINT= SmmAccess2DxeEntryPoint
+
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+#  VALID_ARCHITECTURES   = IA32 X64
+#
+
+[Sources]
+  SmmAccess2Dxe.c
+  SmramInternal.c
+
+[Packages]
+  MdeModulePkg/MdeModulePkg.dec
+  MdePkg/MdePkg.dec
+  OvmfPkg/OvmfPkg.dec
+
+[LibraryClasses]
+  DebugLib
+  PcdLib
+  PciLib
+  UefiBootServicesTableLib
+  UefiDriverEntryPoint
+
+[Protocols]
+  gEfiSmmAccess2ProtocolGuid   # PROTOCOL ALWAYS_PRODUCED
+
+[FeaturePcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
+
+[Depex]
+  TRUE
diff --git a/OvmfPkg/SmmAccess/SmmAccess2Dxe.c

[edk2] [PATCH v4 14/41] OvmfPkg: LockBox: use SMM stack with -D SMM_REQUIRE

2015-11-03 Thread Laszlo Ersek

During DXE, drivers save data in the LockBox. A save operation is layered
as follows:

- The unprivileged driver wishing to store data in the LockBox links
  against the "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf"
  library instance.

  The library allows the unprivileged driver to format requests for the
  privileged SMM LockBox driver (see below), and to parse responses.

  We apply this resolution for DXE_DRIVER modules.

- The privileged SMM LockBox driver is built from
  "MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf". This driver
  has module type DXE_SMM_DRIVER and can access SMRAM.

  The driver delegates command parsing and response formatting to
  "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf".

  Therefore we include this DXE_SMM_DRIVER in the build, and apply said
  resolution specifically to it.

  (Including the driver requires us to resolve a few of other library
  classes for DXE_SMM_DRIVER modules.)

- In PEI, the S3 Resume PEIM (UefiCpuPkg/Universal/Acpi/S3Resume2Pei)
  retrieves data from the LockBox. It is capable of searching SMRAM
  itself.

  We resolve LockBoxLib to
  "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" specifically
  for this one PEIM.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32.dsc| 16 
 OvmfPkg/OvmfPkgIa32X64.dsc | 16 
 OvmfPkg/OvmfPkgX64.dsc | 16 
 OvmfPkg/OvmfPkgIa32.fdf|  1 +
 OvmfPkg/OvmfPkgIa32X64.fdf |  1 +
 OvmfPkg/OvmfPkgX64.fdf |  1 +
 6 files changed, 51 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 6cfd58e..a19d4e2 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -106,7 +106,9 @@ [LibraryClasses]
   QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf
   VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
   LoadLinuxLib|OvmfPkg/Library/LoadLinuxLib/LoadLinuxLib.inf
+!if $(SMM_REQUIRE) == FALSE
   LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
+!endif
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
 
 !ifdef $(SOURCE_DEBUG_ENABLE)
@@ -272,7 +274,11 @@ [LibraryClasses.common.DXE_DRIVER]
   DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
   PlatformBdsLib|OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
+!if $(SMM_REQUIRE) == TRUE
+  LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf
+!else
   LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf
+!endif
 !ifdef $(SOURCE_DEBUG_ENABLE)
   DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
 !endif
@@ -292,6 +298,9 @@ [LibraryClasses.common.UEFI_APPLICATION]
 [LibraryClasses.common.DXE_SMM_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
   TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+  
MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf
+  HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
+  SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
   
SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
 !ifdef $(DEBUG_ON_SERIAL_PORT)
   DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
@@ -461,6 +470,9 @@ [Components]
   UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf {
 
   PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
+!if $(SMM_REQUIRE) == TRUE
+  LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf
+!endif
   }
 !if $(SMM_REQUIRE) == TRUE
   OvmfPkg/SmmAccess/SmmAccessPei.inf {
@@ -708,4 +720,8 @@ [Components]
   # Privileged drivers (DXE_SMM_DRIVER modules)
   #
   UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
+  MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf {
+
+  LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
+  }
 !endif
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 6679e8a..d177154 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -111,7 +111,9 @@ [LibraryClasses]
   QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf
   VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
   LoadLinuxLib|OvmfPkg/Library/LoadLinuxLib/LoadLinuxLib.inf
+!if $(SMM_REQUIRE) == FALSE
   LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
+!endif
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
 
 !ifdef $(SOURCE_DEBUG_ENABLE)
@@ -277,7 +279,11 @@ [LibraryClasses.common.DXE_DRIVER]
   DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
   PlatformBdsLib|OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
+!if $(SMM_REQUIRE) == TRUE
+  LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf
+!else

[edk2] [PATCH v4 10/41] OvmfPkg: pull in the SMM IPL and SMM core

2015-11-03 Thread Laszlo Ersek

"MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf" (a DXE_RUNTIME_DRIVER)
implements the SMM Initial Program Loader. It produces
EFI_SMM_BASE2_PROTOCOL and EFI_SMM_COMMUNICATION_PROTOCOL, relying on:
- EFI_SMM_ACCESS2_PROTOCOL
  (provided by OvmfPkg/SmmAccess/SmmAccess2Dxe.inf),
- EFI_SMM_CONTROL2_PROTOCOL
  (provided by OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf).

(The SMM IPL also depends on EFI_SMM_CONFIGURATION_PROTOCOL_GUID, but this
dependency is not enforced in the entry point. A protocol notify callback
is registered instead, hence we can delay providing that protocol via the
PiSmmCpuDxeSmm driver that is (to be) imported from
Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/.)

The SMM IPL loads the SMM core into SMRAM and executes it from there.
Therefore we add the SMM core to the build as well.

For the SMM core, a number of library classes need to be resolved.
Furthermore, each FDF file must provide the GenFds.py BaseTools utility
with a build rule for SMM_CORE; we copy the DXE_CORE's rule.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32.dsc| 21 
 OvmfPkg/OvmfPkgIa32X64.dsc | 21 
 OvmfPkg/OvmfPkgX64.dsc | 21 
 OvmfPkg/OvmfPkgIa32.fdf|  9 +
 OvmfPkg/OvmfPkgIa32X64.fdf |  9 +
 OvmfPkg/OvmfPkgX64.fdf |  9 +
 6 files changed, 90 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index c71a2f4..ca3be30 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -296,6 +296,17 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
   TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+  
SmmCorePlatformHookLib|MdeModulePkg/Library/SmmCorePlatformHookLibNull/SmmCorePlatformHookLibNull.inf
+  
MemoryAllocationLib|MdeModulePkg/Library/PiSmmCoreMemoryAllocationLib/PiSmmCoreMemoryAllocationLib.inf
+  
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
+  HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
+  SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
+  
SmmServicesTableLib|MdeModulePkg/Library/PiSmmCoreSmmServicesTableLib/PiSmmCoreSmmServicesTableLib.inf
+!ifdef $(DEBUG_ON_SERIAL_PORT)
+  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
+!else
+  DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
+!endif
 
 

 #
@@ -676,4 +687,14 @@ [Components]
 !if $(SMM_REQUIRE) == TRUE
   OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
   OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
+
+  #
+  # SMM Initial Program Load (a DXE_RUNTIME_DRIVER)
+  #
+  MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
+
+  #
+  # SMM_CORE
+  #
+  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
 !endif
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index a1e8f0d..60f085a 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -301,6 +301,17 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
   TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+  
SmmCorePlatformHookLib|MdeModulePkg/Library/SmmCorePlatformHookLibNull/SmmCorePlatformHookLibNull.inf
+  
MemoryAllocationLib|MdeModulePkg/Library/PiSmmCoreMemoryAllocationLib/PiSmmCoreMemoryAllocationLib.inf
+  
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
+  HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
+  SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
+  
SmmServicesTableLib|MdeModulePkg/Library/PiSmmCoreSmmServicesTableLib/PiSmmCoreSmmServicesTableLib.inf
+!ifdef $(DEBUG_ON_SERIAL_PORT)
+  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
+!else
+  DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
+!endif
 
 

 #
@@ -683,4 +694,14 @@ [Components.X64]
 !if $(SMM_REQUIRE) == TRUE
   OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
   OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
+
+  #
+  # SMM Initial Program Load (a DXE_RUNTIME_DRIVER)
+  #
+  MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
+
+  #
+  # SMM_CORE
+  #
+  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
 !endif
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 1176629..0621292 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -301,6 +301,17 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
   TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+  
SmmCorePlatformHookLib|MdeModulePkg/Library/SmmCorePlatformHookLibNull/SmmCorePlatformHookLibNull.inf
+

[edk2] [PATCH v4 09/41] OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVER

2015-11-03 Thread Laszlo Ersek

The EFI_SMM_COMMUNICATION_PROTOCOL implementation that is provided by the
SMM core depends on EFI_SMM_CONTROL2_PROTOCOL; see the
mSmmControl2->Trigger() call in the SmmCommunicationCommunicate() function
[MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c].

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- Set (APMC_EN|GBL_SMI_EN) in SMI_EN from the boot script at S3 resume.
  Otherwise, because SMI_EN is cleared during warm reset,
  SmmControl2DxeTrigger() would fail to trigger an SMI, and variable
  access through the runtime services would fail.

  Set SMI_LOCK in GEN_PMCON_1 similarly.

 OvmfPkg/OvmfPkgIa32.dsc   |   1 +
 OvmfPkg/OvmfPkgIa32X64.dsc|   1 +
 OvmfPkg/OvmfPkgX64.dsc|   1 +
 OvmfPkg/OvmfPkgIa32.fdf   |   1 +
 OvmfPkg/OvmfPkgIa32X64.fdf|   1 +
 OvmfPkg/OvmfPkgX64.fdf|   1 +
 OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf |  65 
 OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.c   | 365 
 8 files changed, 436 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index d7bc38d..c71a2f4 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -675,4 +675,5 @@ [Components]
 
 !if $(SMM_REQUIRE) == TRUE
   OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
+  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
 !endif
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index e17cbe5..a1e8f0d 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -682,4 +682,5 @@ [Components.X64]
 
 !if $(SMM_REQUIRE) == TRUE
   OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
+  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
 !endif
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index a748fb3..1176629 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -680,4 +680,5 @@ [Components]
 
 !if $(SMM_REQUIRE) == TRUE
   OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
+  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
 !endif
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 285720f..43c9c30 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -357,6 +357,7 @@ [FV.DXEFV]
 
 !if $(SMM_REQUIRE) == TRUE
 INF  OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
+INF  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
 !endif
 
 

diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 02e8752..9446896 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -357,6 +357,7 @@ [FV.DXEFV]
 
 !if $(SMM_REQUIRE) == TRUE
 INF  OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
+INF  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
 !endif
 
 

diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index f04c36b..b272b76 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -357,6 +357,7 @@ [FV.DXEFV]
 
 !if $(SMM_REQUIRE) == TRUE
 INF  OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
+INF  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
 !endif
 
 

diff --git a/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf 
b/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
new file mode 100644
index 000..bc66a27
--- /dev/null
+++ b/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
@@ -0,0 +1,65 @@
+## @file
+# A DXE_RUNTIME_DRIVER providing synchronous SMI activations via the
+# EFI_SMM_CONTROL2_PROTOCOL.
+#
+# We expect the PEI phase to have covered the following:
+# - ensure that the underlying QEMU machine type be Q35
+#   (responsible: OvmfPkg/SmmAccess/SmmAccessPei.inf)
+# - ensure that the ACPI PM IO space be configured
+#   (responsible: OvmfPkg/PlatformPei/PlatformPei.inf)
+#
+# Our own entry point is responsible for confirming the SMI feature and for
+# configuring it.
+#
+# Copyright (C) 2013, 2015, Red Hat, Inc.
+#
+# This program and the accompanying materials are licensed and made available
+# under the terms and conditions of the BSD License which accompanies this
+# distribution. The full text of the license may be found at
+# http://opensource.org/licenses/bsd-license.php
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+# WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = SmmControl2Dxe
+  FILE_GUID  = 1206F7CA-A475-4624-A83E-E6FC9BB38E49
+  MODULE_TYPE= DXE_RUNTIME_DRIVER
+  VERSION_STRING = 1.0
+  PI_SPECIFICATION_VERSION   = 0x00010400
+  ENTRY_POINT= SmmControl2DxeEntryPoint
+
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+#  VALID_ARCHITECTURES

[edk2] [PATCH v4 05/41] OvmfPkg: PlatformPei: allow caching in AddReservedMemoryBaseSizeHob()

2015-11-03 Thread Laszlo Ersek

AddReservedMemoryBaseSizeHob() should be able to set the same resource
attributes for reserved memory as AddMemoryBaseSizeHob() sets for system
memory. Add a new parameter called "Cacheable" to
AddReservedMemoryBaseSizeHob(), and set it to FALSE in the only caller we
have at the moment.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 
---
 OvmfPkg/PlatformPei/Platform.h | 3 ++-
 OvmfPkg/PlatformPei/Platform.c | 9 -
 OvmfPkg/PlatformPei/Xen.c  | 2 +-
 3 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/PlatformPei/Platform.h b/OvmfPkg/PlatformPei/Platform.h
index 8b6a976..dad3c61 100644
--- a/OvmfPkg/PlatformPei/Platform.h
+++ b/OvmfPkg/PlatformPei/Platform.h
@@ -50,7 +50,8 @@ AddUntestedMemoryBaseSizeHob (
 VOID
 AddReservedMemoryBaseSizeHob (
   EFI_PHYSICAL_ADDRESSMemoryBase,
-  UINT64  MemorySize
+  UINT64  MemorySize,
+  BOOLEAN Cacheable
   );
 
 VOID
diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
index 1171d3a..8252dc9 100644
--- a/OvmfPkg/PlatformPei/Platform.c
+++ b/OvmfPkg/PlatformPei/Platform.c
@@ -88,7 +88,8 @@ AddIoMemoryBaseSizeHob (
 VOID
 AddReservedMemoryBaseSizeHob (
   EFI_PHYSICAL_ADDRESSMemoryBase,
-  UINT64  MemorySize
+  UINT64  MemorySize,
+  BOOLEAN Cacheable
   )
 {
   BuildResourceDescriptorHob (
@@ -96,6 +97,12 @@ AddReservedMemoryBaseSizeHob (
   EFI_RESOURCE_ATTRIBUTE_PRESENT |
   EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
   EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |
+  (Cacheable ?
+   EFI_RESOURCE_ATTRIBUTE_WRITE_COMBINEABLE |
+   EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE |
+   EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE :
+   0
+   ) |
   EFI_RESOURCE_ATTRIBUTE_TESTED,
 MemoryBase,
 MemorySize
diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/PlatformPei/Xen.c
index 1886326..7fa9019 100644
--- a/OvmfPkg/PlatformPei/Xen.c
+++ b/OvmfPkg/PlatformPei/Xen.c
@@ -223,7 +223,7 @@ InitializeXen (
   // Reserve away HVMLOADER reserved memory [0xFC00,0xFD00).
   // This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
   //
-  AddReservedMemoryBaseSizeHob (0xFC00, 0x100);
+  AddReservedMemoryBaseSizeHob (0xFC00, 0x100, FALSE);
 
   PcdSetBool (PcdPciDisableBusEnumeration, TRUE);
 
-- 
1.8.3.1


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

[edk2] [PATCH v4 11/41] OvmfPkg: pull in CpuIo2Smm driver

2015-11-03 Thread Laszlo Ersek

This driver provides EFI_SMM_CPU_IO2_PROTOCOL, which the SMM core depends
on in its gEfiDxeSmmReadyToLockProtocolGuid callback
(SmmReadyToLockHandler(), "MdeModulePkg/Core/PiSmmCore/PiSmmCore.c").

Approached on a higher level, this driver provides the SmmIo member of the
EFI_SMM_SYSTEM_TABLE2 (SMST).

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32.dsc| 11 +++
 OvmfPkg/OvmfPkgIa32X64.dsc | 11 +++
 OvmfPkg/OvmfPkgX64.dsc | 11 +++
 OvmfPkg/OvmfPkgIa32.fdf|  9 +
 OvmfPkg/OvmfPkgIa32X64.fdf |  9 +
 OvmfPkg/OvmfPkgX64.fdf |  9 +
 6 files changed, 60 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index ca3be30..6cfd58e 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -292,6 +292,12 @@ [LibraryClasses.common.UEFI_APPLICATION]
 [LibraryClasses.common.DXE_SMM_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
   TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+  
SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
+!ifdef $(DEBUG_ON_SERIAL_PORT)
+  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
+!else
+  DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
+!endif
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
@@ -697,4 +703,9 @@ [Components]
   # SMM_CORE
   #
   MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
+
+  #
+  # Privileged drivers (DXE_SMM_DRIVER modules)
+  #
+  UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
 !endif
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 60f085a..6679e8a 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -297,6 +297,12 @@ [LibraryClasses.common.UEFI_APPLICATION]
 [LibraryClasses.common.DXE_SMM_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
   TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+  
SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
+!ifdef $(DEBUG_ON_SERIAL_PORT)
+  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
+!else
+  DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
+!endif
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
@@ -704,4 +710,9 @@ [Components.X64]
   # SMM_CORE
   #
   MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
+
+  #
+  # Privileged drivers (DXE_SMM_DRIVER modules)
+  #
+  UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
 !endif
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 0621292..2651042 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -297,6 +297,12 @@ [LibraryClasses.common.UEFI_APPLICATION]
 [LibraryClasses.common.DXE_SMM_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
   TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
+  
SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
+!ifdef $(DEBUG_ON_SERIAL_PORT)
+  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
+!else
+  DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
+!endif
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
@@ -702,4 +708,9 @@ [Components]
   # SMM_CORE
   #
   MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
+
+  #
+  # Privileged drivers (DXE_SMM_DRIVER modules)
+  #
+  UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
 !endif
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index f705918..e908198 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -360,6 +360,7 @@ [FV.DXEFV]
 INF  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
+INF  UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
 !endif
 
 

@@ -495,3 +496,11 @@ [Rule.Common.SMM_CORE]
 UI   STRING="$(MODULE_NAME)" Optional
 VERSION  STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
   }
+
+[Rule.Common.DXE_SMM_DRIVER]
+  FILE SMM = $(NAMED_GUID) {
+SMM_DEPEXSMM_DEPEX Optional  $(INF_OUTPUT)/$(MODULE_NAME).depex
+PE32 PE32$(INF_OUTPUT)/$(MODULE_NAME).efi
+UI   STRING="$(MODULE_NAME)" Optional
+VERSION  STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
+  }
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 93a8d44..5300a71 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -360,6 +360,7 @@ [FV.DXEFV]
 INF  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
+INF  UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
 !endif
 
 

@@ -495,3 +496,11

[edk2] [PATCH v4 16/41] OvmfPkg: resolve CpuExceptionHandlerLib for DXE_SMM_DRIVER modules

2015-11-03 Thread Laszlo Ersek

UefiCpuPkg/PiSmmCpuDxeSmm depends on this library (the
RegisterCpuInterruptHandler() function specifically) to set up its
specialized page fault handler (SmiPFHandler() -> DumpModuleInfoByIp()).
It doesn't hurt to resolve this library class for all DXE_SMM_DRIVER
modules.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- new in v2 (the CpuExceptionHandlerLib dependency  of PiSmmCpuDxeSmm is
  new in Mike's code, relative to Quark)

 OvmfPkg/OvmfPkgIa32.dsc| 1 +
 OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
 OvmfPkg/OvmfPkgX64.dsc | 1 +
 3 files changed, 3 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 6a93fd2..f3de592 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -308,6 +308,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
 !else
   DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
 !endif
+  
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index dbaf8fb..ee97c84 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -313,6 +313,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
 !else
   DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
 !endif
+  
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index a7efe52..6ab7ffe 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -313,6 +313,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
 !else
   DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
 !endif
+  
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
-- 
1.8.3.1


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

[edk2] [Patch] BaseTools: Print PACKAGES_PATH build environment if it is set.

2015-11-03 Thread Liming Gao

Print the optional build environment PACKAGES_PATH and EDK_TOOLS_BIN.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 BaseTools/Source/Python/build/build.py | 4 
 1 file changed, 4 insertions(+)

diff --git a/BaseTools/Source/Python/build/build.py 
b/BaseTools/Source/Python/build/build.py
index 30ff5bb..67bd3b3 100644
--- a/BaseTools/Source/Python/build/build.py
+++ b/BaseTools/Source/Python/build/build.py
@@ -780,10 +780,14 @@ class Build():
 
 # print current build environment and configuration
 EdkLogger.quiet("%-16s = %s" % ("WORKSPACE", os.environ["WORKSPACE"]))
+if "PACKAGES_PATH" in os.environ:
+EdkLogger.quiet("%-16s = %s" % ("PACKAGES_PATH", 
os.path.normcase(os.path.normpath(os.environ["PACKAGES_PATH"]
 EdkLogger.quiet("%-16s = %s" % ("ECP_SOURCE", 
os.environ["ECP_SOURCE"]))
 EdkLogger.quiet("%-16s = %s" % ("EDK_SOURCE", 
os.environ["EDK_SOURCE"]))
 EdkLogger.quiet("%-16s = %s" % ("EFI_SOURCE", 
os.environ["EFI_SOURCE"]))
 EdkLogger.quiet("%-16s = %s" % ("EDK_TOOLS_PATH", 
os.environ["EDK_TOOLS_PATH"]))
+if "EDK_TOOLS_BIN" in os.environ:
+EdkLogger.quiet("%-16s = %s" % ("EDK_TOOLS_BIN", 
os.path.normcase(os.path.normpath(os.environ["EDK_TOOLS_BIN"]
 
 EdkLogger.info("")
 
-- 
1.9.5.msysgit.0

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

[edk2] [Patch] BaseTools: Don't require ECP pkg in WORKSPACE when PACKAGES_PATH is set

2015-11-03 Thread Liming Gao

When PACKAGES_PATH is set, ECP pkg may be in another directory, not exist
in WORKSPACE. So, keep this check in single WORKSPACE.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
---
 BaseTools/Source/Python/build/build.py | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/BaseTools/Source/Python/build/build.py 
b/BaseTools/Source/Python/build/build.py
index b5df773..30ff5bb 100644
--- a/BaseTools/Source/Python/build/build.py
+++ b/BaseTools/Source/Python/build/build.py
@@ -156,16 +156,18 @@ def CheckEnvVariable():
 EdkLogger.error("build", FORMAT_NOT_SUPPORTED, "No space is allowed in 
EFI_SOURCE path",
 ExtraData=EfiSourceDir)
 
-# change absolute path to relative path to WORKSPACE
-if EfiSourceDir.upper().find(WorkspaceDir.upper()) != 0:
-EdkLogger.error("build", PARAMETER_INVALID, "EFI_SOURCE is not under 
WORKSPACE",
-ExtraData="WORKSPACE = %s\nEFI_SOURCE = %s" % 
(WorkspaceDir, EfiSourceDir))
-if EdkSourceDir.upper().find(WorkspaceDir.upper()) != 0:
-EdkLogger.error("build", PARAMETER_INVALID, "EDK_SOURCE is not under 
WORKSPACE",
-ExtraData="WORKSPACE = %s\nEDK_SOURCE = %s" % 
(WorkspaceDir, EdkSourceDir))
-if EcpSourceDir.upper().find(WorkspaceDir.upper()) != 0:
-EdkLogger.error("build", PARAMETER_INVALID, "ECP_SOURCE is not under 
WORKSPACE",
-ExtraData="WORKSPACE = %s\nECP_SOURCE = %s" % 
(WorkspaceDir, EcpSourceDir))
+# check those variables on single workspace case
+if not PackagesPath:
+# change absolute path to relative path to WORKSPACE
+if EfiSourceDir.upper().find(WorkspaceDir.upper()) != 0:
+EdkLogger.error("build", PARAMETER_INVALID, "EFI_SOURCE is not 
under WORKSPACE",
+ExtraData="WORKSPACE = %s\nEFI_SOURCE = %s" % 
(WorkspaceDir, EfiSourceDir))
+if EdkSourceDir.upper().find(WorkspaceDir.upper()) != 0:
+EdkLogger.error("build", PARAMETER_INVALID, "EDK_SOURCE is not 
under WORKSPACE",
+ExtraData="WORKSPACE = %s\nEDK_SOURCE = %s" % 
(WorkspaceDir, EdkSourceDir))
+if EcpSourceDir.upper().find(WorkspaceDir.upper()) != 0:
+EdkLogger.error("build", PARAMETER_INVALID, "ECP_SOURCE is not 
under WORKSPACE",
+ExtraData="WORKSPACE = %s\nECP_SOURCE = %s" % 
(WorkspaceDir, EcpSourceDir))
 
 # check EDK_TOOLS_PATH
 if "EDK_TOOLS_PATH" not in os.environ:
-- 
1.9.5.msysgit.0

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

Re: [edk2] [PATCH v3 2/2] ShellPkg/UefiDpLib: Support dumping cumulative data

2015-11-03 Thread Zeng, Star


On 2015/11/4 0:55, Cinnamon Shia wrote:

Add a new option -c to dump cumulative data.
For example:
shell> dp -c
==[ Cumulative ]
(Times in microsec.) Cumulative   Average ShortestLongest
Name  CountDurationDurationDurationDuration
LoadImage: 200 1007000   0  10
StartImage:2002000   9   0 700
   DB:Start:2002000  10   0 900
DB:Support: 20  10   0   07000

shell> dp -c DXE
==[ Cumulative ]
(Times in microsec.) Cumulative   Average ShortestLongest
Name  CountDurationDurationDurationDuration
LoadImage: 200 1007000   0  10
StartImage:2002000   9   0 700
   DB:Start:2002000  10   0 900
DB:Support: 20  10   0   07000
 DXE  130003000   03000

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia 
---
  ShellPkg/Library/UefiDpLib/Dp.c  |  33 +--
  ShellPkg/Library/UefiDpLib/DpInternal.h  |   9 +++--
  ShellPkg/Library/UefiDpLib/DpTrace.c |  55 ---
  ShellPkg/Library/UefiDpLib/UefiDpLib.uni | Bin 17466 -> 18146 bytes
  4 files changed, 87 insertions(+), 10 deletions(-)


Reviewed-by: Star Zeng 



diff --git a/ShellPkg/Library/UefiDpLib/Dp.c b/ShellPkg/Library/UefiDpLib/Dp.c
index 62a4e7b..4d109d0 100644
--- a/ShellPkg/Library/UefiDpLib/Dp.c
+++ b/ShellPkg/Library/UefiDpLib/Dp.c
@@ -79,6 +79,7 @@ STATIC CONST SHELL_PARAM_ITEM ParamList[] = {
  #endif // PROFILING_IMPLEMENTED
{L"-x", TypeFlag},   // -x   eXclude Cumulative Items
{L"-i", TypeFlag},   // -i   Display Identifier
+  {L"-c", TypeValue},  // -c   Display cumulative data.
{L"-n", TypeValue},  // -n # Number of records to display for A and R
{L"-t", TypeValue},  // -t # Threshold of interest
{NULL, TypeMax}
@@ -164,6 +165,9 @@ ShellCommandRunDp (
BOOLEAN   TraceMode;
BOOLEAN   ProfileMode;
BOOLEAN   ExcludeMode;
+  BOOLEAN   CumulativeMode;
+  CONST CHAR16  *CustomCumulativeToken;
+  PERF_CUM_DATA *CustomCumulativeData;

StringPtr   = NULL;
SummaryMode = FALSE;
@@ -173,6 +177,8 @@ ShellCommandRunDp (
TraceMode   = FALSE;
ProfileMode = FALSE;
ExcludeMode = FALSE;
+  CumulativeMode = FALSE;
+  CustomCumulativeData = NULL;

// Get DP's entry time as soon as possible.
// This is used as the Shell-Phase end time.
@@ -210,6 +216,7 @@ ShellCommandRunDp (
  #endif  // PROFILING_IMPLEMENTED
ExcludeMode = ShellCommandLineGetFlag (ParamPackage, L"-x");
mShowId = ShellCommandLineGetFlag (ParamPackage, L"-i");
+  CumulativeMode = ShellCommandLineGetFlag (ParamPackage, L"-c");

// Options with Values
CmdLineArg  = ShellCommandLineGetValue (ParamPackage, L"-n");
@@ -244,6 +251,20 @@ ShellCommandRunDp (
InitCumulativeData ();

//
+  // Init the custom cumulative data.
+  //
+  CustomCumulativeToken = ShellCommandLineGetValue (ParamPackage, L"-c");
+  if (CustomCumulativeToken != NULL) {
+CustomCumulativeData = AllocateZeroPool (sizeof (PERF_CUM_DATA));
+CustomCumulativeData->MinDur = 0;
+CustomCumulativeData->MaxDur = 0;
+CustomCumulativeData->Count  = 0;
+CustomCumulativeData->Duration = 0;
+CustomCumulativeData->Name   = AllocateZeroPool (StrLen 
(CustomCumulativeToken) + 1);
+UnicodeStrToAsciiStr (CustomCumulativeToken, CustomCumulativeData->Name);
+  }
+
+  //
// Timer specific processing
//
// Get the Performance counter characteristics:
@@ -302,8 +323,10 @@ ShellCommandRunDp (
  !T &&  P  := (2) Only Profile records are displayed
   T &&  P  := (3) Same as Default, both are displayed
  /
-  GatherStatistics();
-  if (AllMode) {
+  GatherStatistics (CustomCumulativeData);
+  if (CumulativeMode) {
+ProcessCumulative (CustomCumulativeData);
+  } else if (AllMode) {
  if (TraceMode) {
DumpAllTrace( Number2Display, ExcludeMode);
  }
@@ -326,7 +349,7 @@ ShellCommandRunDp (
  if ( ! EFI_ERROR( Status)) {
ProcessPeims ();
ProcessGlobal ();
-  ProcessCumulative ();
+  ProcessCumulative (NULL);
  }
}
  }
@@ -339,6 +362,10 @@ ShellCommandRunDp (
}

SHELL_FREE_NON_NULL (StringPtr);
+  if (CustomCumulativeData != NULL) {
+SHELL_FREE_NON_NULL (CustomCumulativeData->Name);
+  }
+  SHELL_FREE_NON_NULL (CustomCumulativeData);

return SHELL_SUCCESS;
  }
diff --git

Re: [edk2] [PATCH v3 1/2] ShellPkg/UefiDpLib: Fix a DP cumulative data issue

2015-11-03 Thread Zeng, Star


On 2015/11/4 0:55, Cinnamon Shia wrote:

The value of PERF_CUM_DATA.Count and PERF_CUM_DATA.Duration field
keep cumulating on every execution of dp.
Initialize the CumData at dp's entry point.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia 
---
  ShellPkg/Library/UefiDpLib/Dp.c | 27 ++-
  1 file changed, 26 insertions(+), 1 deletion(-)


Reviewed-by: Star Zeng 



diff --git a/ShellPkg/Library/UefiDpLib/Dp.c b/ShellPkg/Library/UefiDpLib/Dp.c
index 8270172..62a4e7b 100644
--- a/ShellPkg/Library/UefiDpLib/Dp.c
+++ b/ShellPkg/Library/UefiDpLib/Dp.c
@@ -14,6 +14,7 @@
timer information to calculate elapsed time for each measurement.

Copyright (c) 2009 - 2013, Intel Corporation. All rights reserved.
+  (C) Copyright 2015 Hewlett Packard Enterprise Development LP
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
@@ -110,7 +111,26 @@ DumpStatistics( void )
SHELL_FREE_NON_NULL (StringPtrUnknown);
  }

-/**
+/**
+  Initialize the cumulative data.
+
+**/
+VOID
+InitCumulativeData (
+  VOID
+  )
+{
+  UINTN Index;
+
+  for (Index = 0; Index < NumCum; ++Index) {
+CumData[Index].Count = 0;
+CumData[Index].MinDur = PERF_MAXDUR;
+CumData[Index].MaxDur = 0;
+CumData[Index].Duration = 0;
+  }
+}
+
+/**
Dump performance data.

@param[in]  ImageHandle The image handle.
@@ -219,6 +239,11 @@ ShellCommandRunDp (
}

//
+  // Initialize the pre-defined cumulative data.
+  //
+  InitCumulativeData ();
+
+  //
// Timer specific processing
//
// Get the Performance counter characteristics:



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

Re: [edk2] [Patch] CryptoPkg: Add one new API (Pkcs7GetCertificatesList) for certs retrieving.

2015-11-03 Thread Ye, Ting

Suggest to add a note that this new API is for signed PE/COFF image only. Other 
parts are good to me.

Reviewed-by: Ye Ting  

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Qin Long
Sent: Tuesday, November 03, 2015 2:38 PM
To: Ye, Ting; Zhang, Chao B
Cc: edk2-devel@lists.01.org
Subject: [edk2] [Patch] CryptoPkg: Add one new API (Pkcs7GetCertificatesList) 
for certs retrieving.

Adding one new API (Pkcs7GetCertificatesList) to retrieve and sort all embedded 
certificates from Pkcs7 signedData. This new API will provide the support for 
UEFI 2.5 Secure-Boot AuditMode feature.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long 
---
 CryptoPkg/Include/Library/BaseCryptLib.h   |  30 +++
 .../Library/BaseCryptLib/Pk/CryptPkcs7Verify.c | 288 +
 .../Library/BaseCryptLib/Pk/CryptPkcs7VerifyNull.c |  34 +++
 .../Pk/CryptPkcs7VerifyNull.c  |  34 +++
 4 files changed, 386 insertions(+)

diff --git a/CryptoPkg/Include/Library/BaseCryptLib.h 
b/CryptoPkg/Include/Library/BaseCryptLib.h
index 95b75c9..390e302 100644
--- a/CryptoPkg/Include/Library/BaseCryptLib.h
+++ b/CryptoPkg/Include/Library/BaseCryptLib.h
@@ -1985,6 +1985,36 @@ Pkcs7FreeSigners (
   );
 
 /**
+  Retrieves all embedded certificates from PKCS#7 signed data as described in 
"PKCS #7:
+  Cryptographic Message Syntax Standard", and outputs two certificate 
+ lists chained and  unchained to the signer's certificates.
+  The input signed data could be wrapped in a ContentInfo structure.
+
+  @param[in]  P7DataPointer to the PKCS#7 message.
+  @param[in]  P7Length  Length of the PKCS#7 message in bytes.
+  @param[out] SingerChainCerts  Pointer to the certificates list chained to 
signer's
+certificate. It's caller's responsiblity to 
free the buffer.
+  @param[out] ChainLength   Length of the chained certificates list buffer 
in bytes.
+  @param[out] UnchainCerts  Pointer to the unchained certificates lists. 
It's caller's
+responsiblity to free the buffer.
+  @param[out] UnchainLength Length of the unchained certificates list 
buffer in bytes.
+
+  @retval  TRUE The operation is finished successfully.
+  @retval  FALSEError occurs during the operation.
+
+**/
+BOOLEAN
+EFIAPI
+Pkcs7GetCertificatesList (
+  IN  CONST UINT8  *P7Data,
+  IN  UINTNP7Length,
+  OUT UINT8**SignerChainCerts,
+  OUT UINTN*ChainLength,
+  OUT UINT8**UnchainCerts,
+  OUT UINTN*UnchainLength
+  );
+
+/**
   Creates a PKCS#7 signedData as described in "PKCS #7: Cryptographic Message
   Syntax Standard, version 1.5". This interface is only intended to be used for
   application to perform PKCS#7 functionality validation.
diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Verify.c 
b/CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Verify.c
index fafcf1b..541156e 100644
--- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Verify.c
+++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Verify.c
@@ -428,6 +428,294 @@ Pkcs7FreeSigners (  }
 
 /**
+  Retrieves all embedded certificates from PKCS#7 signed data as described in 
"PKCS #7:
+  Cryptographic Message Syntax Standard", and outputs two certificate 
+ lists chained and  unchained to the signer's certificates.
+  The input signed data could be wrapped in a ContentInfo structure.
+
+  @param[in]  P7DataPointer to the PKCS#7 message.
+  @param[in]  P7Length  Length of the PKCS#7 message in bytes.
+  @param[out] SingerChainCerts  Pointer to the certificates list chained to 
signer's
+certificate. It's caller's responsiblity to 
free the buffer.
+  @param[out] ChainLength   Length of the chained certificates list buffer 
in bytes.
+  @param[out] UnchainCerts  Pointer to the unchained certificates lists. 
It's caller's
+responsiblity to free the buffer.
+  @param[out] UnchainLength Length of the unchained certificates list 
buffer in bytes.
+
+  @retval  TRUE The operation is finished successfully.
+  @retval  FALSEError occurs during the operation.
+
+**/
+BOOLEAN
+EFIAPI
+Pkcs7GetCertificatesList (
+  IN  CONST UINT8  *P7Data,
+  IN  UINTNP7Length,
+  OUT UINT8**SignerChainCerts,
+  OUT UINTN*ChainLength,
+  OUT UINT8**UnchainCerts,
+  OUT UINTN*UnchainLength
+  )
+{
+  BOOLEAN  Status;
+  UINT8*NewP7Data;
+  UINTNNewP7Length;
+  BOOLEAN  Wrapped;
+  UINT8Index;
+  PKCS7*Pkcs7;
+  X509_STORE_CTX   CertCtx;
+  STACK_OF(X509)   *Signers;
+  X509 *Signer;
+  X509 *Cert;
+  X509 *TempCert;
+  X509 *Issuer;
+  UINT8*CertBuf;
+  UINT8*OldBuf;
+

Re: [edk2] RELEASE_DDK3790_X64_DLINK_FLAGS has machine:AMD64

2015-11-03 Thread Gao, Liming

Sathya:
  DDK3790 tool chain matches Microsoft WINDDK version 3790.1830. For this 
version WINDDK, AMD64 is used for X64 Machine type. 

Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
Fish
Sent: Wednesday, November 04, 2015 7:29 AM
To: Sathya Prakash
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] RELEASE_DDK3790_X64_DLINK_FLAGS has machine:AMD64


> On Nov 3, 2015, at 1:38 PM, Sathya Prakash  
> wrote:
> 
> The Link flags are as below in the latest UDK2015 (and in 2014 too).  
> Is the machine type good or should be changed to X64?
> 

I think the flag changed at some point. AMD64 is the old name. 

Thanks,

Andrew Fish

> 
> 
> RELEASE_DDK3790_X64_DLINK_FLAGS  = /NOLOGO /NODEFAULTLIB /IGNORE:4001
> /IGNORE:4078 /OPT:REF /OPT:ICF=10 /MAP /ALIGN:32 /SECTION:.xdata,D 
> /SECTION:.pdata,D */Machine:AMD64* /LTCG /DLL 
> /ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER 
> /SAFESEH:NO /BASE:0 /DRIVER /MERGE:.data=.text /MERGE:.rdata=.text
> 
> 
> 
> Thanks
> 
> Sathya
> ___
> 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-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] C Coding Standards Specification disappeared

2015-11-03 Thread Bruce Cran


On 11/3/15 8:12 PM, Sheng, Cecil (HPS SW) wrote:


The "EDK II C Coding Standards Specification v2" listed on 
http://tianocore.sourceforge.net/wiki/EDK_II_User_Documentation cannot be found.  Is it 
moved to another place or ?


It may have been removed because it's fairly ancient (2008) and listed 
as a draft document - but if you still want to read it I managed to save 
a copy at 
http://www.bluestop.org/edk2/docs/specs/EDK2_C_Coding_Standards_Specification.pdf 
.


Other documents are available at http://www.bluestop.org/edk2/docs (and 
edk2 API documentation for UDK2014 SP1 is at 
http://www.bluestop.org/edk2/docs/UDK2014.SP1/ .


--
Bruce

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

[edk2] C Coding Standards Specification disappeared

2015-11-03 Thread Sheng, Cecil (HPS SW)

Hi,

The "EDK II C Coding Standards Specification v2" listed on 
http://tianocore.sourceforge.net/wiki/EDK_II_User_Documentation cannot be 
found.  Is it moved to another place or ?



Sincerely,

Cecil Sheng
ISS Firmware Development
HP Servers

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

[edk2] [Patch] Add BIOS Item "RTC Battery Present"

2015-11-03 Thread lushifex

Signed-off-by: lushifex 
---
 Vlv2DeviceRefCodePkg/AcpiTablesPCAT/GloblNvs.asl   |   5 +++--
 Vlv2DeviceRefCodePkg/AcpiTablesPCAT/PciTree.asl|  14 --
 Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c  |   3 ++-
 Vlv2TbltDevicePkg/Include/Guid/SetupVariable.h |   2 +-
 Vlv2TbltDevicePkg/Include/Protocol/GlobalNvsArea.h |   3 ++-
 .../PlatformSetupDxe/SouthClusterConfig.vfi|  10 +-
 Vlv2TbltDevicePkg/PlatformSetupDxe/UqiList.uni | Bin 65892 -> 66540 bytes
 Vlv2TbltDevicePkg/PlatformSetupDxe/VfrStrings.uni  | Bin 214666 -> 215420 bytes
 8 files changed, 29 insertions(+), 8 deletions(-)

diff --git a/Vlv2DeviceRefCodePkg/AcpiTablesPCAT/GloblNvs.asl 
b/Vlv2DeviceRefCodePkg/AcpiTablesPCAT/GloblNvs.asl
index fffc829..21e526c 100644
--- a/Vlv2DeviceRefCodePkg/AcpiTablesPCAT/GloblNvs.asl
+++ b/Vlv2DeviceRefCodePkg/AcpiTablesPCAT/GloblNvs.asl
@@ -3,11 +3,11 @@
 ;**;
 ;*Intel Corporation - ACPI Reference Code for the Baytrail*;
 ;*Family of Customer Reference Boards.*;
 ;**;
 ;**;
-;*Copyright (c)  1999  - 2014, Intel Corporation. All rights reserved   *;
+;*Copyright (c)  1999  - 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 that accompanies this 
distribution.
 ; The full text of the license may be found at
 ; http://opensource.org/licenses/bsd-license.php.
@@ -345,8 +345,9 @@ Field(GNVS,AnyAcc,Lock,Preserve)
   UTS,  8,  //(788) Enable Test Device connected to URT for WHCK test.
   SCPE, 8,  //(789) Allow higher performance on AC/USB - Enable/Disable
   Offset(792),
   EDPV, 8,  //(792) Check for eDP display device
   DIDX, 32, //(793) Device ID for eDP device
-  IOT,  8,  //(794) MinnowBoard Max JP1 is configured for MSFT IOT 
project.   
+  IOT,  8,  //(794) MinnowBoard Max JP1 is configured for MSFT IOT 
project.
+  BATT, 8,  //(795) The Flag of RTC Battery Prensent.  
 }
 
diff --git a/Vlv2DeviceRefCodePkg/AcpiTablesPCAT/PciTree.asl 
b/Vlv2DeviceRefCodePkg/AcpiTablesPCAT/PciTree.asl
index 84a7ee2..2a57d0f 100644
--- a/Vlv2DeviceRefCodePkg/AcpiTablesPCAT/PciTree.asl
+++ b/Vlv2DeviceRefCodePkg/AcpiTablesPCAT/PciTree.asl
@@ -3,11 +3,11 @@
 ;**;
 ;*Intel Corporation - ACPI Reference Code for the Sandy Bridge*;
 ;*Family of Customer Reference Boards.*;
 ;**;
 ;**;
-;*Copyright (c) 2012  - 2014, Intel Corporation. All rights reserved*;
+;*Copyright (c) 2012  - 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 that accompanies this 
distribution.
 ; The full text of the license may be found at
 ; http://opensource.org/licenses/bsd-license.php.
@@ -19,20 +19,30 @@
 ;**;
 ;**/
 
 Scope(\_SB)
 {
-
 //RTC
   Device(RTC)// RTC
   {
 Name(_HID,EISAID("PNP0B00"))
 
 Name(_CRS,ResourceTemplate()
 {
   IO(Decode16,0x70,0x70,0x01,0x08)
 })
+
+Method(_STA,0,Serialized) {
+
+  //
+  // Report RTC Battery is Prensent or Not Present.
+  //
+  If (LEqual(BATT, 1)) {
+Return (0xF)
+  }
+  Return (0x0)
+}
   }
 //RTC
 
   Device(HPET)   // High Performance Event Timer
   {
diff --git a/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c 
b/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c
index c39c36d..2ff14ec 100644
--- a/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c
+++ b/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c
@@ -1,8 +1,8 @@
 /** @file
 
-  Copyright (c) 2004  - 2014, Intel Corporation. All rights reserved.
+  Copyright (c) 2004  - 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 that accompanies this 
distribution.  
@@ -966,10 +966,11 @@ AcpiPlatformEntryPoint (
   mGlobalNvsArea.Area->PreviousDeviceList = 0x0F ;
 
   mGlobalNvsArea.Area->UartSelection = mSystemConfiguration.UartInterface;
   mGlobalNvsArea.Area->PcuUart1Enable = mSystemConfiguration.PcuUart1;

Re: [edk2] [Patch] Add BIOS Item "RTC Battery Present"

2015-11-03 Thread He, Tim

Reviewed-by: Tim He 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of lushifex
Sent: Wednesday, November 04, 2015 1:05 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch] Add BIOS Item "RTC Battery Present"

Signed-off-by: lushifex 
---
 Vlv2DeviceRefCodePkg/AcpiTablesPCAT/GloblNvs.asl   |   5 +++--
 Vlv2DeviceRefCodePkg/AcpiTablesPCAT/PciTree.asl|  14 --
 Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c  |   3 ++-
 Vlv2TbltDevicePkg/Include/Guid/SetupVariable.h |   2 +-
 Vlv2TbltDevicePkg/Include/Protocol/GlobalNvsArea.h |   3 ++-
 .../PlatformSetupDxe/SouthClusterConfig.vfi|  10 +-
 Vlv2TbltDevicePkg/PlatformSetupDxe/UqiList.uni | Bin 65892 -> 66540 bytes
 Vlv2TbltDevicePkg/PlatformSetupDxe/VfrStrings.uni  | Bin 214666 -> 215420 bytes
 8 files changed, 29 insertions(+), 8 deletions(-)

diff --git a/Vlv2DeviceRefCodePkg/AcpiTablesPCAT/GloblNvs.asl 
b/Vlv2DeviceRefCodePkg/AcpiTablesPCAT/GloblNvs.asl
index fffc829..21e526c 100644
--- a/Vlv2DeviceRefCodePkg/AcpiTablesPCAT/GloblNvs.asl
+++ b/Vlv2DeviceRefCodePkg/AcpiTablesPCAT/GloblNvs.asl
@@ -3,11 +3,11 @@
 ;**;
 ;*Intel Corporation - ACPI Reference Code for the Baytrail*;
 ;*Family of Customer Reference Boards.*;
 ;**;
 ;**;
-;*Copyright (c)  1999  - 2014, Intel Corporation. All rights reserved   *;
+;*Copyright (c)  1999  - 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 that accompanies this 
distribution.
 ; The full text of the license may be found at  ; 
http://opensource.org/licenses/bsd-license.php.
@@ -345,8 +345,9 @@ Field(GNVS,AnyAcc,Lock,Preserve)
   UTS,  8,  //(788) Enable Test Device connected to URT for WHCK test.
   SCPE, 8,  //(789) Allow higher performance on AC/USB - Enable/Disable
   Offset(792),
   EDPV, 8,  //(792) Check for eDP display device
   DIDX, 32, //(793) Device ID for eDP device
-  IOT,  8,  //(794) MinnowBoard Max JP1 is configured for MSFT IOT 
project.   
+  IOT,  8,  //(794) MinnowBoard Max JP1 is configured for MSFT IOT 
project.
+  BATT, 8,  //(795) The Flag of RTC Battery Prensent.  
 }
 
diff --git a/Vlv2DeviceRefCodePkg/AcpiTablesPCAT/PciTree.asl 
b/Vlv2DeviceRefCodePkg/AcpiTablesPCAT/PciTree.asl
index 84a7ee2..2a57d0f 100644
--- a/Vlv2DeviceRefCodePkg/AcpiTablesPCAT/PciTree.asl
+++ b/Vlv2DeviceRefCodePkg/AcpiTablesPCAT/PciTree.asl
@@ -3,11 +3,11 @@
 ;**;
 ;*Intel Corporation - ACPI Reference Code for the Sandy Bridge*;
 ;*Family of Customer Reference Boards.*;
 ;**;
 ;**;
-;*Copyright (c) 2012  - 2014, Intel Corporation. All rights reserved*;
+;*Copyright (c) 2012  - 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 that accompanies this 
distribution.
 ; The full text of the license may be found at  ; 
http://opensource.org/licenses/bsd-license.php.
@@ -19,20 +19,30 @@
 ;**;
 ;**/
 
 Scope(\_SB)
 {
-
 //RTC
   Device(RTC)// RTC
   {
 Name(_HID,EISAID("PNP0B00"))
 
 Name(_CRS,ResourceTemplate()
 {
   IO(Decode16,0x70,0x70,0x01,0x08)
 })
+
+Method(_STA,0,Serialized) {
+
+  //
+  // Report RTC Battery is Prensent or Not Present.
+  //
+  If (LEqual(BATT, 1)) {
+Return (0xF)
+  }
+  Return (0x0)
+}
   }
 //RTC
 
   Device(HPET)   // High Performance Event Timer
   {
diff --git a/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c 
b/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c
index c39c36d..2ff14ec 100644
--- a/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c
+++ b/Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c
@@ -1,8 +1,8 @@
 /** @file
 
-  Copyright (c) 2004  - 2014, Intel Corporation. All rights reserved.
+  Copyright (c) 2004  - 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 that accompanies this

Re: [edk2] [PATCH 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

2015-11-03 Thread Paolo Bonzini

On 03/11/2015 14:25, Laszlo Ersek wrote:
>   - Agreement between Paolo, Jordan and Mike about implementing
> broadcast SMIs. I am willing to code up whatever design is
> agreed upon. Can everyone involved please prioritize this
> discussion a little?

Actually, I was *de*prioritizing it because things _more or less_ work
without it, especially if the timeout is temporarily reduced.  We
probably agree that timeouts are evil in a virt setting, but even
without this issue you can commit the ~70 patches that bring us to 99%
of the way.

Once the slate is clean and everybody is focused on the few remaining
problems, we can tackle them---including broadcast SMIs.

In fact, the rest of your email lists some more pressing problems than
broadcast SMIs, which I'm quoting below to further remind other readers. :)

Paolo

>   - Solving the MP-related ExitBootServices() handler bug in CpuDxe.
> Patches have been on the list for almost a week. While I've been
> breaking my back testing and reviewing patches for others (not
> just on edk2-devel, mind you), nobody has batted an eye about
> that series.
> 
> [edk2] [PATCH v2 0/4] UefiCpuPkg/CpuDxe: Fix ExitBootServices()
>   callback in the presence of SMIs
> http://thread.gmane.org/gmane.comp.bios.edk2.devel/3518
> 
> Please review it, so that I can include it at the front of my
> upcoming v4 SMM series.
> 
>   - Thirty (30) patches from the SMM series still need reviews. Once
> all of the above is covered, I'll update the OvmfPkg/README
> patch about the status, and post version 4. I wouldn't mind if
> we could commit the series still in 2015, but I'm getting less
> and less hopeful.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 08/10] ArmCacheMaintenanceLib: disallow whole D-cache maintenance operations

2015-11-03 Thread Cohen, Eugene

Please don't remove this functionality.  At times we do want to use this 
library to turn off the cache in preparation for going to another environment 
(say, loading an OS) and this is useful.

Eugene

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
Biesheuvel
Sent: Tuesday, November 03, 2015 3:17 AM
To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; mark.rutl...@arm.com
Cc: ler...@redhat.com; Ard Biesheuvel 
Subject: [edk2] [PATCH 08/10] ArmCacheMaintenanceLib: disallow whole D-cache 
maintenance operations

The ARM architecture provides no reliable way to clean or invalidate the entire 
data cache at runtime. The reason is that such maintenance requires the use of 
set/way maintenance operations, which are suitable only for the kind of 
maintenance that is carried out when the cache is taken offline entirely.

So ASSERT () when any of the CacheMaintenanceLib whole data cache routines are 
invoked rather than pretending we can do anything meaningful here.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c 
b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
index 175d29496c32..8cc1990b3266 100644
--- a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
+++ b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
@@ -14,6 +14,7 @@
 **/
 #include 
 #include 
+#include 
 #include 
 
 VOID
@@ -44,7 +45,6 @@ InvalidateInstructionCache (
   VOID
   )
 {
-  ArmCleanDataCache();
   ArmInvalidateInstructionCache();
 }
 
@@ -54,7 +54,7 @@ InvalidateDataCache (
   VOID
   )
 {
-  ArmInvalidateDataCache();
+  ASSERT (FALSE);
 }
 
 VOID *
@@ -76,7 +76,7 @@ WriteBackInvalidateDataCache (
   VOID
   )
 {
-  ArmCleanInvalidateDataCache();
+  ASSERT (FALSE);
 }
 
 VOID *
@@ -96,7 +96,7 @@ WriteBackDataCache (
   VOID
   )
 {
-  ArmCleanDataCache();
+  ASSERT (FALSE);
 }
 
 VOID *
--
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] [PATCH 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

2015-11-03 Thread Laszlo Ersek

On 11/03/15 14:45, Paolo Bonzini wrote:
> 
> 
> On 03/11/2015 14:25, Laszlo Ersek wrote:
>>   - Agreement between Paolo, Jordan and Mike about implementing
>> broadcast SMIs. I am willing to code up whatever design is
>> agreed upon. Can everyone involved please prioritize this
>> discussion a little?
> 
> Actually, I was *de*prioritizing it because things _more or less_ work
> without it, especially if the timeout is temporarily reduced.  We
> probably agree that timeouts are evil in a virt setting, but even
> without this issue you can commit the ~70 patches that bring us to 99%
> of the way.
> 
> Once the slate is clean and everybody is focused on the few remaining
> problems, we can tackle them---including broadcast SMIs.

Works for me. Keeping your patch "OvmfPkg: use relaxed AP SMM
synchronization mode" in the build (and not broadcasting SMIs in either
component) certainly results in a functional binary. The perf penalty
could be fine-tuned by decimating the timeout. (I don't recall if I
*planned* to divide the current timeout by ten, or actually *tested* it.
In any case, I recall thinking that 1/10th of the otherwise seen lag
would be pretty tolerable.)

So, this works for me definitely.

Thank you
Laszlo

> 
> In fact, the rest of your email lists some more pressing problems than
> broadcast SMIs, which I'm quoting below to further remind other readers. :)
> 
> Paolo
> 
>>   - Solving the MP-related ExitBootServices() handler bug in CpuDxe.
>> Patches have been on the list for almost a week. While I've been
>> breaking my back testing and reviewing patches for others (not
>> just on edk2-devel, mind you), nobody has batted an eye about
>> that series.
>>
>> [edk2] [PATCH v2 0/4] UefiCpuPkg/CpuDxe: Fix ExitBootServices()
>>   callback in the presence of SMIs
>> http://thread.gmane.org/gmane.comp.bios.edk2.devel/3518
>>
>> Please review it, so that I can include it at the front of my
>> upcoming v4 SMM series.
>>
>>   - Thirty (30) patches from the SMM series still need reviews. Once
>> all of the above is covered, I'll update the OvmfPkg/README
>> patch about the status, and post version 4. I wouldn't mind if
>> we could commit the series still in 2015, but I'm getting less
>> and less hopeful.

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

Re: [edk2] [PATCH v2 2/2] ShellPkg/UefiDpLib: Support dumping cumulative data

2015-11-03 Thread Zeng, Star


On 2015/11/3 21:26, Cinnamon Shia wrote:

Add a new option -c to dump cumulative data.
For example:
shell> dp -c
==[ Cumulative ]
(Times in microsec.) Cumulative   Average ShortestLongest
Name  CountDurationDurationDurationDuration
LoadImage: 200 1007000   0  10
StartImage:2002000   9   0 700
   DB:Start:2002000  10   0 900
DB:Support: 20  10   0   07000

shell> dp -c DXE
==[ Cumulative ]
(Times in microsec.) Cumulative   Average ShortestLongest
Name  CountDurationDurationDurationDuration
LoadImage: 200 1007000   0  10
StartImage:2002000   9   0 700
   DB:Start:2002000  10   0 900
DB:Support: 20  10   0   07000
 DXE  130003000   03000

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia 
---
  ShellPkg/Library/UefiDpLib/Dp.c  |  33 +--
  ShellPkg/Library/UefiDpLib/DpInternal.h  |   9 +++--
  ShellPkg/Library/UefiDpLib/DpTrace.c |  55 ---
  ShellPkg/Library/UefiDpLib/UefiDpLib.uni | Bin 17466 -> 18146 bytes
  4 files changed, 87 insertions(+), 10 deletions(-)


If you accept my one minor comment below.
Reviewed-by: Star Zeng 



diff --git a/ShellPkg/Library/UefiDpLib/Dp.c b/ShellPkg/Library/UefiDpLib/Dp.c
index 62a4e7b..4d109d0 100644
--- a/ShellPkg/Library/UefiDpLib/Dp.c
+++ b/ShellPkg/Library/UefiDpLib/Dp.c
@@ -79,6 +79,7 @@ STATIC CONST SHELL_PARAM_ITEM ParamList[] = {
  #endif // PROFILING_IMPLEMENTED
{L"-x", TypeFlag},   // -x   eXclude Cumulative Items
{L"-i", TypeFlag},   // -i   Display Identifier
+  {L"-c", TypeValue},  // -c   Display cumulative data.
{L"-n", TypeValue},  // -n # Number of records to display for A and R
{L"-t", TypeValue},  // -t # Threshold of interest
{NULL, TypeMax}
@@ -164,6 +165,9 @@ ShellCommandRunDp (
BOOLEAN   TraceMode;
BOOLEAN   ProfileMode;
BOOLEAN   ExcludeMode;
+  BOOLEAN   CumulativeMode;
+  CONST CHAR16  *CustomCumulativeToken;
+  PERF_CUM_DATA *CustomCumulativeData;

StringPtr   = NULL;
SummaryMode = FALSE;
@@ -173,6 +177,8 @@ ShellCommandRunDp (
TraceMode   = FALSE;
ProfileMode = FALSE;
ExcludeMode = FALSE;
+  CumulativeMode = FALSE;
+  CustomCumulativeData = NULL;

// Get DP's entry time as soon as possible.
// This is used as the Shell-Phase end time.
@@ -210,6 +216,7 @@ ShellCommandRunDp (
  #endif  // PROFILING_IMPLEMENTED
ExcludeMode = ShellCommandLineGetFlag (ParamPackage, L"-x");
mShowId = ShellCommandLineGetFlag (ParamPackage, L"-i");
+  CumulativeMode = ShellCommandLineGetFlag (ParamPackage, L"-c");

// Options with Values
CmdLineArg  = ShellCommandLineGetValue (ParamPackage, L"-n");
@@ -244,6 +251,20 @@ ShellCommandRunDp (
InitCumulativeData ();

//
+  // Init the custom cumulative data.
+  //
+  CustomCumulativeToken = ShellCommandLineGetValue (ParamPackage, L"-c");
+  if (CustomCumulativeToken != NULL) {
+CustomCumulativeData = AllocateZeroPool (sizeof (PERF_CUM_DATA));
+CustomCumulativeData->MinDur = 0;
+CustomCumulativeData->MaxDur = 0;
+CustomCumulativeData->Count  = 0;
+CustomCumulativeData->Duration = 0;
+CustomCumulativeData->Name   = AllocateZeroPool (StrLen 
(CustomCumulativeToken) + 1);
+UnicodeStrToAsciiStr (CustomCumulativeToken, CustomCumulativeData->Name);
+  }
+
+  //
// Timer specific processing
//
// Get the Performance counter characteristics:
@@ -302,8 +323,10 @@ ShellCommandRunDp (
  !T &&  P  := (2) Only Profile records are displayed
   T &&  P  := (3) Same as Default, both are displayed
  /
-  GatherStatistics();
-  if (AllMode) {
+  GatherStatistics (CustomCumulativeData);
+  if (CumulativeMode) {
+ProcessCumulative (CustomCumulativeData);
+  } else if (AllMode) {
  if (TraceMode) {
DumpAllTrace( Number2Display, ExcludeMode);
  }
@@ -326,7 +349,7 @@ ShellCommandRunDp (
  if ( ! EFI_ERROR( Status)) {
ProcessPeims ();
ProcessGlobal ();
-  ProcessCumulative ();
+  ProcessCumulative (NULL);
  }
}
  }
@@ -339,6 +362,10 @@ ShellCommandRunDp (
}

SHELL_FREE_NON_NULL (StringPtr);
+  if (CustomCumulativeData != NULL) {
+SHELL_FREE_NON_NULL (CustomCumulativeData->Name);
+  }
+  SHELL_FREE_NON_NULL (CustomCumulativeData);

return SHELL_SUCCESS;
  }

Re: [edk2] [PATCH 08/10] ArmCacheMaintenanceLib: disallow whole D-cache maintenance operations

2015-11-03 Thread Ard Biesheuvel

On 3 November 2015 at 14:51, Cohen, Eugene  wrote:
> Please don't remove this functionality.  At times we do want to use this 
> library to turn off the cache in preparation for going to another environment 
> (say, loading an OS) and this is useful.
>

Note that this is not about turning off the caches.

As Mark points out, the set/way operations are not suitable for
ensuring that the OS boot image has made it all the way to memory, and
that it will be visible to the CPU with the MMU off. The cache
maintenance by VA operations do offer those guarantees, so the
architecturally sound method of achieving that is to clean the
region(s) you care about by VA before disabling the MMU.

Under virtualization, these issues are a bit more prominent, and I
have had to add by-VA cache maintenance on several occasions to fix
actual problems.

Note that this patch does not remove any of the functionality. It just
changes the CacheMaintenanceLib implementation so that this
functionality is not exported to generic code. If any non-ARM specific
code in the tree requires the ability to clean and/or invalidate the
whole data cache, it is making incorrect assumptions about the
platform that it runs on.

Regards,
Ard.



> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
> Biesheuvel
> Sent: Tuesday, November 03, 2015 3:17 AM
> To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; mark.rutl...@arm.com
> Cc: ler...@redhat.com; Ard Biesheuvel 
> Subject: [edk2] [PATCH 08/10] ArmCacheMaintenanceLib: disallow whole D-cache 
> maintenance operations
>
> The ARM architecture provides no reliable way to clean or invalidate the 
> entire data cache at runtime. The reason is that such maintenance requires 
> the use of set/way maintenance operations, which are suitable only for the 
> kind of maintenance that is carried out when the cache is taken offline 
> entirely.
>
> So ASSERT () when any of the CacheMaintenanceLib whole data cache routines 
> are invoked rather than pretending we can do anything meaningful here.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c 
> b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> index 175d29496c32..8cc1990b3266 100644
> --- a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> +++ b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> @@ -14,6 +14,7 @@
>  **/
>  #include 
>  #include 
> +#include 
>  #include 
>
>  VOID
> @@ -44,7 +45,6 @@ InvalidateInstructionCache (
>VOID
>)
>  {
> -  ArmCleanDataCache();
>ArmInvalidateInstructionCache();
>  }
>
> @@ -54,7 +54,7 @@ InvalidateDataCache (
>VOID
>)
>  {
> -  ArmInvalidateDataCache();
> +  ASSERT (FALSE);
>  }
>
>  VOID *
> @@ -76,7 +76,7 @@ WriteBackInvalidateDataCache (
>VOID
>)
>  {
> -  ArmCleanInvalidateDataCache();
> +  ASSERT (FALSE);
>  }
>
>  VOID *
> @@ -96,7 +96,7 @@ WriteBackDataCache (
>VOID
>)
>  {
> -  ArmCleanDataCache();
> +  ASSERT (FALSE);
>  }
>
>  VOID *
> --
> 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] [PATCH 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

2015-11-03 Thread Janusz Mocek

W dniu 03.11.2015 o 14:31, Laszlo Ersek pisze:
> On 11/03/15 13:34, Paolo Bonzini wrote:
>>
>> On 03/11/2015 02:14, Laszlo Ersek wrote:
>>> Anyway, with the following host kernel change, the AP startup problem
>>> goes away (tested on top of v4.3):
>>>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 9a9a198..4f978ad 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -622,7 +622,8 @@ int kvm_set_cr0(struct kvm_vcpu *vcpu, unsigned long 
> cr0)
>   if ((cr0 ^ old_cr0) & update_bits)
>   kvm_mmu_reset_context(vcpu);
>
> - if ((cr0 ^ old_cr0) & X86_CR0_CD)
> + if (!kvm_check_has_quirk(vcpu->kvm, KVM_X86_QUIRK_CD_NW_CLEARED) &&
> + (cr0 ^ old_cr0) & X86_CR0_CD)
>   kvm_zap_gfn_range(vcpu->kvm, 0, ~0ULL);
>
>   return 0;
>>> (Honestly I just imitated fb279950ba here; I'm not making any better
>>> argument for this diff. But, independently, I wonder why this hunk
>>> didn't have the noncoherent DMA check either, originally.)
>> Great job.  I look forward to the testing results.
>>
>> It should also have the noncoherent DMA check, in fact, though that's
>> just an optimization and it would have masked the bug on your system.
> Thank you! I'll wait for Janusz's results, and if stuff works, I'll post
> the patch with the update you're suggesting (zap only if the guest has
> noncoherent DMA and lacks the quirk).
>
> Laszlo
>
>> Thanks,
>>
>> Paolo
>>
>>> Janusz, could you rebuild your host kernel with this patch, and share
>>> the results? (I'm also attaching the same as a formatted patch, so you
>>> can apply it with "git am" easily.)
Looks like its working correctly now

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

Re: [edk2] [PATCH 06/10] ArmPkg/ArmLib: retrieve cache line length from CTR not CCSIDR

2015-11-03 Thread Mark Rutland

Hi,

On Tue, Nov 03, 2015 at 11:16:31AM +0100, Ard Biesheuvel wrote:
> The stride used by the cache maintenance by MVA instructions should
> be retrieved from CTR_EL0.DminLine and CTR_EL0.IminLine, whose values
> reflect the actual geometry of the caches. Using CCSIDR for this purpose
> violates the architecture.

Looking around, I think that ArmDataCacheLineLength/CTR_EL0.DminLine is
also mis-used by DMA code to align/pad data for non-coherent DMA, where
I would expect to see CTR_EL0.CWG (effectively the maximum D-cache line
length) being used instead.

That requires some investigation.

> Also, move the line length accessors to common code, since there is no
> need to keep them separate between ARMv7 and AArch64.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 

Regardless of the above, this is most definitely an improvement.

Reviewed-by: Mark Rutland 

Mark.

> ---
>  ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c | 25 --
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.c | 27 
>  ArmPkg/Library/ArmLib/Common/ArmLib.c  | 18 +
>  3 files changed, 18 insertions(+), 52 deletions(-)
> 
> diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c 
> b/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c
> index 4bea20356fa3..dec125f248cd 100644
> --- a/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c
> +++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c
> @@ -21,31 +21,6 @@
>  #include "AArch64Lib.h"
>  #include "ArmLibPrivate.h"
>  
> -UINTN
> -EFIAPI
> -ArmDataCacheLineLength (
> -  VOID
> -  )
> -{
> -  UINT32 CCSIDR = ReadCCSIDR (0) & 7;
> -
> -  // * 4 converts to bytes
> -  return (1 << (CCSIDR + 2)) * 4;
> -}
> -
> -UINTN
> -EFIAPI
> -ArmInstructionCacheLineLength (
> -  VOID
> -  )
> -{
> -  UINT32 CCSIDR = ReadCCSIDR (1) & 7;
> -
> -  // * 4 converts to bytes
> -  return (1 << (CCSIDR + 2)) * 4;
> -}
> -
> -
>  VOID
>  AArch64DataCacheOperation (
>IN  AARCH64_CACHE_OPERATION  DataCacheOperation
> diff --git a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.c 
> b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.c
> index 44edff869eae..b53f455bfad2 100644
> --- a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.c
> +++ b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.c
> @@ -20,33 +20,6 @@
>  #include "ArmV7Lib.h"
>  #include "ArmLibPrivate.h"
>  
> -UINTN
> -EFIAPI
> -ArmDataCacheLineLength (
> -  VOID
> -  )
> -{
> -  UINT32 CCSIDR = ReadCCSIDR (0) & 7;
> -
> -  // * 4 converts to bytes
> -  return (1 << (CCSIDR + 2)) * 4;
> -}
> -
> -UINTN
> -EFIAPI
> -ArmInstructionCacheLineLength (
> -  VOID
> -  )
> -{
> -  UINT32 CCSIDR = ReadCCSIDR (1) & 7;
> -
> -  // * 4 converts to bytes
> -  return (1 << (CCSIDR + 2)) * 4;
> -
> -//  return 64;
> -}
> -
> -
>  VOID
>  ArmV7DataCacheOperation (
>IN  ARM_V7_CACHE_OPERATION  DataCacheOperation
> diff --git a/ArmPkg/Library/ArmLib/Common/ArmLib.c 
> b/ArmPkg/Library/ArmLib/Common/ArmLib.c
> index 4febc45220a3..ad0a265e9f59 100644
> --- a/ArmPkg/Library/ArmLib/Common/ArmLib.c
> +++ b/ArmPkg/Library/ArmLib/Common/ArmLib.c
> @@ -70,3 +70,21 @@ ArmUnsetCpuActlrBit (
>Value &= ~Bits;
>ArmWriteCpuActlr (Value);
>  }
> +
> +UINTN
> +EFIAPI
> +ArmDataCacheLineLength (
> +  VOID
> +  )
> +{
> +  return 4 << ((ArmCacheInfo () >> 16) & 0xf); // CTR_EL0.DminLine
> +}
> +
> +UINTN
> +EFIAPI
> +ArmInstructionCacheLineLength (
> +  VOID
> +  )
> +{
> +  return 4 << (ArmCacheInfo () & 0xf); // CTR_EL0.IminLine
> +}
> -- 
> 1.9.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 08/10] ArmCacheMaintenanceLib: disallow whole D-cache maintenance operations

2015-11-03 Thread Mark Rutland

On Tue, Nov 03, 2015 at 01:51:46PM +, Cohen, Eugene wrote:
> Please don't remove this functionality.  At times we do want to use
> this library to turn off the cache in preparation for going to another
> environment (say, loading an OS) and this is useful.

Could you elaborate on your use-case?

Given the unreliability of Set/Way operations, they may not achieve the
guarantees that you require. They are not guaranted to push data to the
PoC (i.e. memory), cannot drain system caches (e.g. external L3s), etc.

Mark.

> Eugene
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
> Biesheuvel
> Sent: Tuesday, November 03, 2015 3:17 AM
> To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; mark.rutl...@arm.com
> Cc: ler...@redhat.com; Ard Biesheuvel 
> Subject: [edk2] [PATCH 08/10] ArmCacheMaintenanceLib: disallow whole D-cache 
> maintenance operations
> 
> The ARM architecture provides no reliable way to clean or invalidate the 
> entire data cache at runtime. The reason is that such maintenance requires 
> the use of set/way maintenance operations, which are suitable only for the 
> kind of maintenance that is carried out when the cache is taken offline 
> entirely.
> 
> So ASSERT () when any of the CacheMaintenanceLib whole data cache routines 
> are invoked rather than pretending we can do anything meaningful here.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c 
> b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> index 175d29496c32..8cc1990b3266 100644
> --- a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> +++ b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> @@ -14,6 +14,7 @@
>  **/
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  VOID
> @@ -44,7 +45,6 @@ InvalidateInstructionCache (
>VOID
>)
>  {
> -  ArmCleanDataCache();
>ArmInvalidateInstructionCache();
>  }
>  
> @@ -54,7 +54,7 @@ InvalidateDataCache (
>VOID
>)
>  {
> -  ArmInvalidateDataCache();
> +  ASSERT (FALSE);
>  }
>  
>  VOID *
> @@ -76,7 +76,7 @@ WriteBackInvalidateDataCache (
>VOID
>)
>  {
> -  ArmCleanInvalidateDataCache();
> +  ASSERT (FALSE);
>  }
>  
>  VOID *
> @@ -96,7 +96,7 @@ WriteBackDataCache (
>VOID
>)
>  {
> -  ArmCleanDataCache();
> +  ASSERT (FALSE);
>  }
>  
>  VOID *
> --
> 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] [Patch] MdeModulePkg: Fix a PciBusDxe hot plug bug

2015-11-03 Thread Ni, Ruiyu

Leif,
I saw your feedbacks as your opinion if you create patches. I don't think your 
opinion is the *only* right solution.
I can also split 3/4 in your patch serials to two patches: one is to just 
change DumpBridgeResource(), the other is for the remaining changes.
So I think my splitting way is good enough.
OK I will give response to your questions firstly.

Regards,
Ray

-Original Message-
From: Leif Lindholm [mailto:leif.lindh...@linaro.org] 
Sent: Tuesday, November 3, 2015 6:45 PM
To: Ni, Ruiyu 
Cc: Tian, Feng ; Kinney, Michael D 
; edk2-devel@lists.01.org; Fan, Jeff 

Subject: Re: [edk2] [Patch] MdeModulePkg: Fix a PciBusDxe hot plug bug

Hi guys,

I never saw a response to this feedback I sent on the revised patch
set, but I see it has now been committed.
Could you let me know why my feedback was ignored?

Regards,

Leif

On 30 October 2015 at 18:02, Leif Lindholm  wrote:
> Hi Ray,
>
> Many thanks for this.
>
> On Fri, Oct 30, 2015 at 04:53:54AM +, Ni, Ruiyu wrote:
>> Ok I will revert the two patches I committed (big patch + small
>> patch). But I want to clarify one thing that not every big patch can
>> be easily understood by just splitting to small patches.
>
> Certainly, but it is always helpful to split as much as is possible.
> The shorter a patch is to review, the more likely reviewers are to
> spot mistakes - especially when reviewing code they are not already
> very familiar with.
>
> As an example, I have split your set up a little bit further by
> breaking 2/3 into two separate patches.
> https://git.linaro.org/people/leif.lindholm/edk2.git/shortlog/refs/heads/ray-pci
>
> I have also tried to remove modifications completely unrelated to this
> fix - resulting in a difference between the tree with your current
> patch set and my variant as included below. The changes in your set
> are all valid changes, but they are not related to the fix.
>
> The method behind all of this madness is to make the output of "git
> blame" as relevant as possible, as well as making automated "git
> bisect" sessions for tracking down which specific change caused an
> issue more useful.
>
> Best Regards,
>
> Leif
>
>
> Diff between Ray's v2 and my version of it:
>
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c 
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
> index 12647be..523c698 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
> @@ -281,13 +281,13 @@ DumpResourceMap (
>IN UINTN ResourceCount
>)
>  {
> -  EFI_STATUS   Status;
> -  LIST_ENTRY   *Link;
> -  PCI_IO_DEVICE*Device;
> -  UINTNIndex;
> -  CHAR16   *Str;
> -  PCI_RESOURCE_NODE**ChildResources;
> -  UINTNChildResourceCount;
> +  EFI_STATUS   Status;^M
> +  LIST_ENTRY   *Link;^M
> +  PCI_IO_DEVICE*Device;^M
> +  UINTNIndex;^M
> +  CHAR16   *Str;^M
> +  PCI_RESOURCE_NODE**ChildResources;^M
> +  UINTNChildResourceCount;^M
>
>DEBUG ((EFI_D_INFO, "PciBus: Resource Map for "));
>
> @@ -976,7 +976,7 @@ PciScanBus (
>UINT8 Device;
>UINT8 Func;
>UINT64Address;
> -  UINT8 SecondBus;
> +  UINTN SecondBus;^M
>UINT8 PaddedSubBus;
>UINT16Register;
>UINTN HpIndex;
> @@ -1211,7 +1211,7 @@ PciScanBus (
>
>Status = PciScanBus (
>  PciDevice,
> -SecondBus,
> +(UINT8) (SecondBus),^M
>  SubBusNumber,
>  PaddedBusRange
>  );
> @@ -1227,7 +1227,7 @@ PciScanBus (
>if ((Attributes == EfiPaddingPciRootBridge) &&
>(State & EFI_HPC_STATE_ENABLED) != 0&&
>(State & EFI_HPC_STATE_INITIALIZED) != 0) {
> -*PaddedBusRange = (UINT8) ((UINT8) (BusRange) + *PaddedBusRange);
> +*PaddedBusRange = (UINT8) ((UINT8) (BusRange) 
> +*PaddedBusRange);^M
>} else {
>  //
>  // Reserve the larger one between the actual occupied bus
>  // number and padded bus number
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
> index e12d59f..fb6270b 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
> @@ -245,6 +245,7 @@ CalculateApertureIo16 (
>) {
>
>  Node = RESOURCE_NODE_FROM_LINK (CurrentLink);
> +^M
>  if

Re: [edk2] [PATCH 05/10] ArmPkg/ArmLib: remove CCSIDR based cache info routines

2015-11-03 Thread Leif Lindholm

On Tue, Nov 03, 2015 at 11:16:30AM +0100, Ard Biesheuvel wrote:
> The ARM architecture does not allow the actual geometries of the caches
> to be inferred from the CCSIDR cache info system register, since the
> geometry it reports is intended for performing cache maintenance by
> set/way and nothing else. Since the ArmLib cache info routines are
> based solely on CCSIDR contents, they should not be used.

This was introduced by Andrew Fish's original port to BeagleBoard, so
adding him to cc.

/
Leif

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Include/Library/ArmLib.h  |  78 ---
>  ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c   | 141 
> ---
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.c   | 142 
> 
>  ArmPkg/Library/ArmLib/Common/ArmLib.c|  20 ---
>  ArmPkg/Library/ArmLib/Null/NullArmCacheInformation.c | 106 ---
>  ArmPkg/Library/ArmLib/Null/NullArmLib.inf|   1 -
>  6 files changed, 488 deletions(-)
> 
> diff --git a/ArmPkg/Include/Library/ArmLib.h b/ArmPkg/Include/Library/ArmLib.h
> index f1de303d952d..2059a67bbf3c 100644
> --- a/ArmPkg/Include/Library/ArmLib.h
> +++ b/ArmPkg/Include/Library/ArmLib.h
> @@ -26,30 +26,6 @@
>   #error "Unknown chipset."
>  #endif
>  
> -typedef enum {
> -  ARM_CACHE_TYPE_WRITE_BACK,
> -  ARM_CACHE_TYPE_UNKNOWN
> -} ARM_CACHE_TYPE;
> -
> -typedef enum {
> -  ARM_CACHE_ARCHITECTURE_UNIFIED,
> -  ARM_CACHE_ARCHITECTURE_SEPARATE,
> -  ARM_CACHE_ARCHITECTURE_UNKNOWN
> -} ARM_CACHE_ARCHITECTURE;
> -
> -typedef struct {
> -  ARM_CACHE_TYPE  Type;
> -  ARM_CACHE_ARCHITECTURE  Architecture;
> -  BOOLEAN DataCachePresent;
> -  UINTN   DataCacheSize;
> -  UINTN   DataCacheAssociativity;
> -  UINTN   DataCacheLineLength;
> -  BOOLEAN InstructionCachePresent;
> -  UINTN   InstructionCacheSize;
> -  UINTN   InstructionCacheAssociativity;
> -  UINTN   InstructionCacheLineLength;
> -} ARM_CACHE_INFO;
> -
>  /**
>   * The UEFI firmware must not use the 
> ARM_MEMORY_REGION_ATTRIBUTE_NONSECURE_* attributes.
>   *
> @@ -126,66 +102,12 @@ typedef enum {
>  #define GET_MPID(ClusterId, CoreId)   (((ClusterId) << 8) | (CoreId))
>  #define PRIMARY_CORE_ID   (PcdGet32(PcdArmPrimaryCore) & ARM_CORE_MASK)
>  
> -ARM_CACHE_TYPE
> -EFIAPI
> -ArmCacheType (
> -  VOID
> -  );
> -
> -ARM_CACHE_ARCHITECTURE
> -EFIAPI
> -ArmCacheArchitecture (
> -  VOID
> -  );
> -
> -VOID
> -EFIAPI
> -ArmCacheInformation (
> -  OUT ARM_CACHE_INFO  *CacheInfo
> -  );
> -
> -BOOLEAN
> -EFIAPI
> -ArmDataCachePresent (
> -  VOID
> -  );
> -
> -UINTN
> -EFIAPI
> -ArmDataCacheSize (
> -  VOID
> -  );
> -
> -UINTN
> -EFIAPI
> -ArmDataCacheAssociativity (
> -  VOID
> -  );
> -
>  UINTN
>  EFIAPI
>  ArmDataCacheLineLength (
>VOID
>);
>  
> -BOOLEAN
> -EFIAPI
> -ArmInstructionCachePresent (
> -  VOID
> -  );
> -
> -UINTN
> -EFIAPI
> -ArmInstructionCacheSize (
> -  VOID
> -  );
> -
> -UINTN
> -EFIAPI
> -ArmInstructionCacheAssociativity (
> -  VOID
> -  );
> -
>  UINTN
>  EFIAPI
>  ArmInstructionCacheLineLength (
> diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c 
> b/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c
> index f795a2f896b2..4bea20356fa3 100644
> --- a/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c
> +++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c
> @@ -21,86 +21,6 @@
>  #include "AArch64Lib.h"
>  #include "ArmLibPrivate.h"
>  
> -ARM_CACHE_TYPE
> -EFIAPI
> -ArmCacheType (
> -  VOID
> -  )
> -{
> -  return ARM_CACHE_TYPE_WRITE_BACK;
> -}
> -
> -ARM_CACHE_ARCHITECTURE
> -EFIAPI
> -ArmCacheArchitecture (
> -  VOID
> -  )
> -{
> -  UINT32 CLIDR = ReadCLIDR ();
> -
> -  return (ARM_CACHE_ARCHITECTURE)CLIDR; // BugBug Fix Me
> -}
> -
> -BOOLEAN
> -EFIAPI
> -ArmDataCachePresent (
> -  VOID
> -  )
> -{
> -  UINT32 CLIDR = ReadCLIDR ();
> -
> -  if ((CLIDR & 0x2) == 0x2) {
> -// Instruction cache exists
> -return TRUE;
> -  }
> -  if ((CLIDR & 0x7) == 0x4) {
> -// Unified cache
> -return TRUE;
> -  }
> -
> -  return FALSE;
> -}
> -
> -UINTN
> -EFIAPI
> -ArmDataCacheSize (
> -  VOID
> -  )
> -{
> -  UINT32 NumSets;
> -  UINT32 Associativity;
> -  UINT32 LineSize;
> -  UINT32 CCSIDR = ReadCCSIDR (0);
> -
> -  LineSize  = (1 << ((CCSIDR & 0x7) + 2));
> -  Associativity = ((CCSIDR >> 3) & 0x3ff) + 1;
> -  NumSets   = ((CCSIDR >> 13) & 0x7fff) + 1;
> -
> -  // LineSize is in words (4 byte chunks)
> -  return  NumSets * Associativity * LineSize * 4;
> -}
> -
> -UINTN
> -EFIAPI
> -ArmDataCacheAssociativity (
> -  VOID
> -  )
> -{
> -  UINT32 CCSIDR = ReadCCSIDR (0);
> -
> -  return ((CCSIDR >> 3) & 0x3ff) + 1;
> -}
> -
> -UINTN
> -ArmDataCacheSets (
> -  VOID
> -  )
> -{
> -  UINT32 CCSIDR = ReadCCSIDR (0);
> -
> -  return ((CCSIDR >> 13) & 0x7fff) + 1;
> -}
> -

Re: [edk2] [PATCH 07/10] ArmPkg/ArmLib: move cache maintenance sync barriers out of loop

2015-11-03 Thread Mark Rutland

On Tue, Nov 03, 2015 at 11:16:32AM +0100, Ard Biesheuvel wrote:
> There is no need to issue a full data synchronization barrier and an
> instruction synchronization barrier after each and every set/way or
> MVA cache maintenance operation. For the set/way case, we can simply
> remove them, since the set/way outer loop already issues the required
> barriers after completing its traversal over all the cache levels.
> 
> For the MVA case, move the data synchronization barrier out of the
> loop, and add the instruction synchronization barrier to the I-cache
> invalidation by MVA routine.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c |  2 ++
>  ArmPkg/Library/ArmLib/AArch64/AArch64Support.S | 12 
> 
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S | 12 
> 
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.asm   | 12 
> 
>  4 files changed, 2 insertions(+), 36 deletions(-)
> 
> diff --git a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c 
> b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> index d8e53df6096e..175d29496c32 100644
> --- a/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> +++ b/ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.c
> @@ -35,6 +35,7 @@ CacheRangeOperation (
>  LineOperation(AlignedAddress);
>  AlignedAddress += ArmCacheLineLength;
>}
> +  ArmDataSynchronizationBarrier ();
>  }
>  
>  VOID
> @@ -65,6 +66,7 @@ InvalidateInstructionCacheRange (
>  {
>CacheRangeOperation (Address, Length, ArmCleanDataCacheEntryByMVA);
>ArmInvalidateInstructionCache ();
> +  ArmInstructionSynchronizationBarrier ();
>return Address;
>  }

I've just spotted that the ArmInvalidateInstructionCache implementations
already have the requisite DSB; ISB sequence, so we didn't actually need
to introduce an ISB here.

I don't know if it's best to remove the ISB here, or move both the DSB
and ISB here for consistency across all the cache maintenance
primitives.

Either way, with that fixed up:

Reviewed-by: Mark Rutland 

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

Re: [edk2] [PATCH v2 2/2] ShellPkg/UefiDpLib: Support dumping cumulative data

2015-11-03 Thread Shia, Cinnamon

Hi Star,

Thanks for your feedback.
Will address your comments in patch v3.

Thanks,
Cinnamon Shia

-Original Message-
From: Zeng, Star [mailto:star.z...@intel.com] 
Sent: Tuesday, November 3, 2015 10:06 PM
To: Shia, Cinnamon; edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH v2 2/2] ShellPkg/UefiDpLib: Support dumping 
cumulative data

On 2015/11/3 21:26, Cinnamon Shia wrote:
> Add a new option -c to dump cumulative data.
> For example:
> shell> dp -c
> ==[ Cumulative ]
> (Times in microsec.) Cumulative   Average ShortestLongest
> Name  CountDurationDurationDurationDuration
> LoadImage: 200 1007000   0  10
> StartImage:2002000   9   0 700
>DB:Start:2002000  10   0 900
> DB:Support: 20  10   0   07000
>
> shell> dp -c DXE
> ==[ Cumulative ]
> (Times in microsec.) Cumulative   Average ShortestLongest
> Name  CountDurationDurationDurationDuration
> LoadImage: 200 1007000   0  10
> StartImage:2002000   9   0 700
>DB:Start:2002000  10   0 900
> DB:Support: 20  10   0   07000
>  DXE  130003000   03000
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Cinnamon Shia 
> ---
>   ShellPkg/Library/UefiDpLib/Dp.c  |  33 +--
>   ShellPkg/Library/UefiDpLib/DpInternal.h  |   9 +++--
>   ShellPkg/Library/UefiDpLib/DpTrace.c |  55 
> ---
>   ShellPkg/Library/UefiDpLib/UefiDpLib.uni | Bin 17466 -> 18146 bytes
>   4 files changed, 87 insertions(+), 10 deletions(-)

If you accept my one minor comment below.
Reviewed-by: Star Zeng 

>
> diff --git a/ShellPkg/Library/UefiDpLib/Dp.c 
> b/ShellPkg/Library/UefiDpLib/Dp.c index 62a4e7b..4d109d0 100644
> --- a/ShellPkg/Library/UefiDpLib/Dp.c
> +++ b/ShellPkg/Library/UefiDpLib/Dp.c
> @@ -79,6 +79,7 @@ STATIC CONST SHELL_PARAM_ITEM ParamList[] = {
>   #endif // PROFILING_IMPLEMENTED
> {L"-x", TypeFlag},   // -x   eXclude Cumulative Items
> {L"-i", TypeFlag},   // -i   Display Identifier
> +  {L"-c", TypeValue},  // -c   Display cumulative data.
> {L"-n", TypeValue},  // -n # Number of records to display for A and R
> {L"-t", TypeValue},  // -t # Threshold of interest
> {NULL, TypeMax}
> @@ -164,6 +165,9 @@ ShellCommandRunDp (
> BOOLEAN   TraceMode;
> BOOLEAN   ProfileMode;
> BOOLEAN   ExcludeMode;
> +  BOOLEAN   CumulativeMode;
> +  CONST CHAR16  *CustomCumulativeToken;
> +  PERF_CUM_DATA *CustomCumulativeData;
>
> StringPtr   = NULL;
> SummaryMode = FALSE;
> @@ -173,6 +177,8 @@ ShellCommandRunDp (
> TraceMode   = FALSE;
> ProfileMode = FALSE;
> ExcludeMode = FALSE;
> +  CumulativeMode = FALSE;
> +  CustomCumulativeData = NULL;
>
> // Get DP's entry time as soon as possible.
> // This is used as the Shell-Phase end time.
> @@ -210,6 +216,7 @@ ShellCommandRunDp (
>   #endif  // PROFILING_IMPLEMENTED
> ExcludeMode = ShellCommandLineGetFlag (ParamPackage, L"-x");
> mShowId = ShellCommandLineGetFlag (ParamPackage, L"-i");
> +  CumulativeMode = ShellCommandLineGetFlag (ParamPackage, L"-c");
>
> // Options with Values
> CmdLineArg  = ShellCommandLineGetValue (ParamPackage, L"-n"); @@ 
> -244,6 +251,20 @@ ShellCommandRunDp (
> InitCumulativeData ();
>
> //
> +  // Init the custom cumulative data.
> +  //
> +  CustomCumulativeToken = ShellCommandLineGetValue (ParamPackage, 
> + L"-c");  if (CustomCumulativeToken != NULL) {
> +CustomCumulativeData = AllocateZeroPool (sizeof (PERF_CUM_DATA));
> +CustomCumulativeData->MinDur = 0;
> +CustomCumulativeData->MaxDur = 0;
> +CustomCumulativeData->Count  = 0;
> +CustomCumulativeData->Duration = 0;
> +CustomCumulativeData->Name   = AllocateZeroPool (StrLen 
> (CustomCumulativeToken) + 1);
> +UnicodeStrToAsciiStr (CustomCumulativeToken, 
> + CustomCumulativeData->Name);  }
> +
> +  //
> // Timer specific processing
> //
> // Get the Performance counter characteristics:
> @@ -302,8 +323,10 @@ ShellCommandRunDp (
>   !T &&  P  := (2) Only Profile records are displayed
>    T &&  P  := (3) Same as Default, both are displayed
>   
> **
> **/
> -  GatherStatistics();
> -  if (AllMode) {
> +  GatherStatistics (CustomCumulativeData);  if (CumulativeMode) {
> +ProcessCumulative (CustomCumulativeData);  } else if (AllMode) {
>   if (TraceMode) {
>

88 matches

Mail list logo